• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 1095 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

Parents
  • 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

Reply
  • 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

Children
No data