Can the PIC nest low interrupts? I.e. can I re-enable interrupts while in an interrupt handler and have the chip do the right thing?
I actually have a good reason for doing this, but I suspect the chip can’t handle re-entrant code.
Thanks In Advance for your wisdom.
Yes, with low-priority interrupts it can. If you don’t know what a low priority interrupt is, then jsut take my word and know it will work. Just don’t try too many interrupts inside interrupts, as these are added to the stack, which will eventually overflow if you do.
Also something to keep in mind. The less stuff you have on the stack the more efficient the code will be. So recursion is out of the question.
Thanks. This actually might be useful. I have some tasks that are (relatively) infrequent, but could easily be done in the interrupt handler as long as I don’t shut the frequent, high speed stuff down (e.g. quadrature encoder input). The design requires only one level of nesting.
So, to conclude, to enable interrupts, within the low priority handler, I simply write a 1 to the global interrupt enable flag?
I am not 100% sure, but am fairly sure that it is never disabled to begin with, and you should be able to nest interrupts as is.
I need to dig into the manual a bit more. Clearly global interrupts are not disabled, because the system needs to service high priority interrupts. However, to nest low priority interrupts I would need to re-enable the low interrupt - and clear whatever interrupt I am servicing & so forth.
There are high and low priority interrupts. We are to only use low priority interrupts.
High priority interrupts can interupt low priority interrupts (call it nesting if you would like). BUT low priority interrupts can not interrupt other low priority interrupts. In you are servicing a low priority interrupt and do not clear the interrupt flag for another interrupt then as soon as you exit the interrupt service routine then another interrupt will occur - no nesting.
I discussed this with Dave at IFI while writing Interrupts for Dummies. The C Compiler Usrs guide can get you a bit confused.
what could your code be doing with an interrupt coming along that is SO imporant it cant wait a few microseconds for the current interrupt to finish?
in general its not a good idea, because it adds overhead to the tasks being performed, you have to save your context registers and then switch to the new interrupt, then switch back, then finish the one that was running
from a throughput perspective is best not to interrupt someone who just interrruped someone - your code will run like mud.
Oh, really? How can nesting be any less efficient than serializing the context switches? Does it cost more to save an interrupt handlers context than the top level code?
Anyway, it is good to finally understand that one cannot nest interrupts within a prioprity level. In practice two levels and being able to assign individual sources to either level is probably more control than most folks need.
As it turned out, in the code in our teams robot used only two interrupt sources: the change of portB for quadrature encoders and timer2 (or one or zero, I don’t remember) for a 1khz system clock. The timer code just incremented a global and the quadrature code just did it’s quadrature thing. Everything else was driven off the timer global which incremented once every millisecond.
Cheers!
We use several interrupts in our code, and it really isn’t a problem. Even if the millisecond timer fires during the handling of another interrupt, the function will finish before the timer fires again, so the timer stays on schedule.
in this pic chip when an interupt occurs a flag is set for that interrupt - so even if a higher priority interrupt is being processed at the time
and the source of the second interrupt goes away
it will not be lost, the flag will remain set until that interrupt is serviced.
Its very rare that you need to allow interrupts to be interrupted
SW should be designed as if all these things will be polled - if you dont have time to poll the conditions, you dont have time to service interrupts either
and if you dont know how often all your different interrupts can happen, your code is likely to be buggy and unpredicable.
Design your system (SW) as if you dont have interrupts, and then use the interrupts as a convience only.