• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 1093 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Fast External Interrupt

Kieran Dobbyn

I need to implement a fast external interrupt with a C167CR micro on a Phytec phyCORE-167 board.
At the moment, I have my external interrupt signal connected to pin P2.15
and program it as follows:

      EXICON = 0x4000;    // Set Ext Trigger Interrupt for rising edge
response
      CC15IC = 0x4c;              // Enables Ext Trigger Interrupt, Global
Level = Lowest, Priority Level = Medium
      IEN = 1 ;                         // Enable Interrupts

When an interrupt occurs, I then want to set another port pin which is done
within the interrupt handler, as shown below:
     void Boxcar_irq (void) interrupt CC15INT = 31
     {
         CC15IC = 0x0;                // Disable further interrupts
         EXTTRIG_GATE = 1;     // Sets pin P2.1 High

         return;
     }
This arrangment works, i.e. the interrupt is trapped and the port pin set
low, but the response time I am getting is 5.4uS.
I have measured this as the time from the rising edge of the external
trigger signal to the rising edge of P2.1.
I do not have any other interrupts running or enabled so I don't set this
interrupt to highest priority.

Can you suggest a way that I can improve the interrupt response time.
I would like to get below 1uS if possible.

My application program is approx 20kB in size and runs from external RAM using.

Any ideas?

Best Regards,
Kieran Dobbyn

  • 0

    Dear Kieran,

    when port pins CCxIO are to be used as external interrupt input pins, bit field CCMODx in the control register of the correspinding capture/compare register CCx must select capture mode.
    This is from infineon data book.
    with best regards
    Uwe

  • 0

    Hi Kieran,

    Probably the fastest response you can get is when the fast external interrupt triggers a PEC transfer to the output port data register. But it is not possible to set individual port bits this way.
    To get the fastest possible response with the interrupt handler you have to make sure that the instruction that sets the output port is as close to the entry point of the interrupt handler as possible. You can always put it right in the interrupt vector table, and that would involve assembler, of course. The other issue is program execution speed from external RAM. If the external bus interface is not in 16-bit demultiplexed mode with no extra delays, than the interrupt handler will run faster from on-chip RAM.
    By the way, 5.4uS sounds like ages. Are you sure you chose the fastest possible CPU clock frequency?

    Regards,
    - Mike

  • 0

    If you're running 20Mhz, the external interrupt latency is still 200usec, I believe. Then the push of registers will use up more. You can speed it up by using a separate register bank for the interrupt, (see 'using' keyword)

    eg.
void boxcar_irq( void ) interrupt CC15NT = 31 using rb_Boxcar { ... }
    This still requires a context save and switch but is faster than a lot of pushes. The best speed will be gotten by writing the whole thing in an assembly module so you can avoid saving anything, since nothing is destroyed.
    Best luck
    Scott

  • 0

    Thanks for the replies.

    Some things I learned which you might find useful for future interrupts.

    I was using Keils uVision2 compilier.
    In the C166 tab of the Target Options I turned off the "Save DPP on Interrupt entry" option. I think this is normally on as default.

    I used idata with all variables that are used by the interrupt or associated functions to have the variables located in the on-chip RAM for faster access.

    Similarly, I changed all boolean flags to bit types rather than chars. Bit variables are stored in on-chip RAM.

    When using the CAPCOM inputs as fast interrupts, I did not program the CCMODx bit for capture mode (as suggested in the user manual) as this actually caused 2 interrupts to occur - one according to the EXICON register and one due to the CCMODx bit I presume, unless I was doing something wrong.

    With these changes I was able to get my system working at an acceptable rate.

    Thanks again,
    Kieran