Hi Nathan, I totally agree! Zero Jitter Interrupt is a better name.
We don't have zero latency, we have zero jitter. BR, Alan On 10/27/20, Nathan Hartman <hartman.nat...@gmail.com> wrote: > 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 >
