Lost cycles in interrupt call

[jackmicro]

Hello,

I am writing a very time sensitive 8 bit MCU application where processor cycles are at premium.

I am trying to replace an interrupt handling routine with assembly, but even before the processor reaches the interrupt service function there are already 50 lost cycles spent determining the source!

Is there a way I can tap into the interrupt control to speed up the redirect for this particular higher priority interrupt?

Many thanks for your input.

[temtronic]

You should use the 'search' option for this forum.
This topic has been covered quite a few times.
Depending in the PIC type 16,18,24,dsPIC you have several options on how to handle the task.
Easiest is to write your own 'global ISR' handler and not use the CCS supplied one.As you've found out about 50 cycles are used to handle the handler.....
Another 'cheat' is to max out the speed of the PIC or change PIC to a faster one.18s generally are faster than 16s.
Obviously do NOT do ANY math,especially FP operations in your ISR, do NOT use 'printf' either.ISR mantra...get in quick, set a flag or two, get out fast.

If you post your code, we may be able to help further..

hth
jay

[Ttelmah]

50 cycles is more than should be lost. Typically 30 if there is only one interrupt handler. However if there are multiple handlers the interrupts are polled in order until you get to the one to be serviced. Each poll involves testing the IE, and the interrupt bit, so takes about five cycles. It sounds as if there is more than one interrupt enabled, and the one you are timing, is quite well down the list.
Temtronic has pointed out that this has been covered many times in the past. Also look at EX_GLINT.C. The 'equivalent' for high priority interrupts, is the 'fast' directive.

Best Wishes

[jackmicro]

thanks. Will do.

Much appreciated.