Hi Nathan, as I mentioned in my previous email, this isn't about overhead, is about other ISRs delaying mine. 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. On Tue, Oct 27, 2020, at 10:56, Nathan Hartman wrote: > On Tue, Oct 27, 2020 at 4:09 AM Xiang Xiao <xiaoxiang781...@gmail.com> > wrote: > > > On Tue, Oct 27, 2020 at 7:43 AM Matias N. <mat...@imap.cc> wrote: > > > > > As Greg mentioned in the corresponding open issue, TizenRT took Greg's > > > snippets from the Wiki page and mostly implemented that. Couldn't really > > > find more changes than that, so I'm not sure if it is actually used on > > > TizenRT or they managed to make the change relatively simple. > > > > > > I don't quite grasp the complexity (beyond the fact that it requires > > > consideration of what the high priority interrupts will do that may > > affect > > > lower priority interrupts being executed) so I'm not sure if I would be > > the > > > right person to try this, but if anyone feels motivated I could help. > > > > > > Regarding critical sections, shouldn't there then be an argument to > > > enter_critical_section() that specifies which interrupts priorities to > > > disable and which not? > > > > > > And regardless of priorities, now that we talk about this, wouldn't be > > > useful to be able to choose which interrupts to disable for a given > > > critical section? Many uses of enter_critical_section() actually try to > > > protect the enclosed code from changes from a specific ISR so it seems > > > wasteful to disable all interrupts. > > > > > > > > No, it isn't safe to call OS API if enter_critical_section just disables > > some interrupt, because there are many states(e.g. tcb list) is shared by > > other interrupt handlers(or other tasks in SMP case). Without disabling all > > interrupts, other tasks or irq handlers may modify the same state as the > > special irq handler is running. > > Why don't you try Zero Latency Interrupts? It's designed for your case. > > > Zero Latency Interrupts work great and eliminate jitter caused by critical > sections etc throughout the software. However keep in mind: > > * You should make that interrupt code as short as possible. > > * Zero latency interrupts run "outside" the OS and as such cannot make OS > calls from the interrupt handler, including even a call to wake or signal > another thread. If you need to do that, you need to create a "regular" > interrupt that will make those OS calls and trigger it somehow from the > zero latency interrupt. > > A zero latency interrupt should write previously prepared data to hardware > registers, read sampled data from hardware registers, and/or trigger > hardware events, but probably should not do too much more work. Heavy > lifting like complicated math and communication processing should be done > in regular code that runs "in" the OS, if possible. > > Having said all of that, reducing the time spent in critical sections will > improve overall performance and responsiveness of the OS. > > Cheers, > Nathan >
