On Tue, Oct 27, 2020 at 10:03 AM Matias N. <mat...@imap.cc> wrote: > Hi Nathan, > as I mentioned in my previous email, this isn't about overhead, is about > other ISRs delaying mine.
I didn't see your reply until after, but Zero Latency Interrupts should more aptly be called Zero Jitter Interrupt, because jitter is what you would see on an oscilloscope if you turn on a GPIO on entry to the ISR, turn it off on exit from the ISR, and scope that together with whatever signal triggers the interrupt. Sometimes you'll see your interrupt begin very closely to the trigger and other times you'll see a delay. This is due to other interrupts and critical sections that happen to be executing at the time of the trigger. What Zero Latency Interrupts do is run immediately without caring about other interrupts, critical sections, etc. In fact they'll interrupt them immediately, eliminating that jitter I mentioned. It is a lot more work to setup these zero latency interrupts so I only use it for the most crucial things and I do everything else "in" the OS. This happens only so often if I'm unlucky, so it isn't like it breaks the > communication completely. > But I would like to trust the communication more and know that if I start > processing ISRs from more peripherals > I'm not increasing the chances for communication to break. > > I don't see other way around using high-priority interrupts interrupting > lower-priority ones to achieve that. I guess this goes back to what Greg pointed out, which was done in TizenRT. I don't have the link handy (on my phone) but Greg posted it earlier in this thread. Nathan
