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.
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 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.
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.