And I just wrote this questions while you were writing the answers =) Thanks, I understand a bit better that this indeed interrupts other ISRs.
On Tue, Oct 27, 2020, at 11:12, Nathan Hartman 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 >
