Quote:
|
Originally Posted by KenWittlief
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!