regarding interrupt latency

[cibinvarghese]

hi,
I got a problem while using interrupts. I am using 3 external interrupts and timer0 interrupt. I use the priority in this order

[Ttelmah]

Remember that interrupts can't override each other. If your code is already _in_ the RTCC interrupt handler, then this handler will carry on executing this handler, complete, restore the registers, return to the main code, and only then call the global interrupt handler, save the registers again, check which interrupt has triggered, and only then call the EXT handler.
On the PIC, there are only two interrupt vectors. All interrupts in the standard handler, are 'polled' to see which one has triggered. #priority determines the order of this polling, but the polling only occurs at the moment the main handler is called. Once a handler is extered, it always completes.
If you want 'EXT', to have hrdware priority, then you need to add the command:
#device HIGH_INTS=TRUE

and change the #INT_EXT defintion, to:

#INT_EXT HIGH

This will then switch this interrupt to the second 'high priority' hardware vector, and it'll be able to interrupt the RTCC handler.

For the ultimate speed, you could change the INT_EXT declaration to:

#INT_EXT FAST

However _you_ then need to save any registers used inside your interrupt code, and handle clearing the interrupt as well.

Best Wishes

[asmboy]

what i learned from life:

NO interrupts - NO problem.
1 interrupt - maybe a problem

more than one interrupt - In my case,
unintended consequences seems to increase with the SQUARE of the
number of INTS enabled.

BTW: if highly stable/repeatable execution time determinism is a requirement for your code - INTS are not for you either.

thats just me - but i find am doing the least debug when INTS =0 or 1

when i get to be a better yet programmer - maybe that will improve