xxxajk
Well-known member
It is still a real shame that the NVIC can't do a reentrant ISR, but only ISR with a greater priority.
In some ways, this is a design mistake, as it can make for more CPU work than it should be.
In other ways, it can be a good thing, you don't have to worry about reentrance...
So, really, it is both a good and bad thing.
Too bad that there is no way to specify that an ISR can be reentrant with some sort of register setting.
I've never had any real problems with using a reentrant ISR, unless the signal was way too fast.
My guess here is that the design idea is to prevent problems such as stack crashing into heap, and possibly other problems...
This design can also allow some really sloppy hardware combinations too, but I always have solved problems like that with hardware.
A flip-flop that sampled the IRQ line in phase with the CPU clock solves the same issue, since your code has to manually clear the hardware.
The NVIC goes one or two steps beyond this, but the concept is very similar.
In some ways, this is a design mistake, as it can make for more CPU work than it should be.
In other ways, it can be a good thing, you don't have to worry about reentrance...
So, really, it is both a good and bad thing.
Too bad that there is no way to specify that an ISR can be reentrant with some sort of register setting.
I've never had any real problems with using a reentrant ISR, unless the signal was way too fast.
My guess here is that the design idea is to prevent problems such as stack crashing into heap, and possibly other problems...
This design can also allow some really sloppy hardware combinations too, but I always have solved problems like that with hardware.
A flip-flop that sampled the IRQ line in phase with the CPU clock solves the same issue, since your code has to manually clear the hardware.
The NVIC goes one or two steps beyond this, but the concept is very similar.