[Rickertsen2]

Originally Posted by Kris Verdeyen

We had some issues keeping track of an encoder we used to close the loop around our steering control. It got to be very resource-intensive to count every edge transition, so we modified the code to only count every fourth encoder transition, which worked fine.

The problem, as Mark noted, is that the program hasn't returned from the interrupt service routine by the time that another interrupt comes along. This causes the processor to miss a count, which over time will lead to a large position error.

This will be the main type of problem that you'll see, especially if you try to close any high speed loops.

Nested interrupts are not a problem if you take special consideration and re-enable the GIE flag. The processor has a 31 level deep hardware stack. As long as you don't overflow that you are fine. The problem is not with nested interrupts but in too many of them overflowing the stack. Note: the way the default code it setup, nested interrupts will be ignored. You will have to rewrite it to determine the source of the interrupt, clear the appropriate flag, reset the GIE flag, and then do you interrupt processing. Just be careful to avoid odd race condiditions etc. Everything I said above applies only to low priority interrupts. If you do not know the difference then you are using low priority interrupts and everything i jsut said applies.