Hi Matias, The High-perf Zero Latency Interrupts is a misleading name.
In fact it works like something external to the NuttX: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts You can use it with a timer with highest priority that will interrupt the NuttX and will execute your "external" code, then you can use it to do think very fast periodically, like stepper motors control for instance, etc. It is very powerful, but it is not portable, not all MCUs will support it. BR, Alan On 10/27/20, Matias N. <mat...@imap.cc> wrote: > Zero Latency Interrupts, AFAIK, are to reduce ISR overhead. My problem is > other ISRs being > run delay the execution of time-critical ISRs. > > On Tue, Oct 27, 2020, at 05:09, Xiang Xiao 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. >> >> >> > Best, >> > Matias >> > >> > On Mon, Oct 26, 2020, at 10:21, David Sidrane wrote: >> > > > But the priority difference doesn't imply that the nested interrupt >> > > > happens >> > > automatically, you have to enable the interrupt manually after the >> > critical >> > > CPU register and OS state is saved. >> > > >> > > My recollection is it depends on the priority assigned to the >> > > interrupt >> > and >> > > the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The >> > system >> > > will crash due to reentrancy on the common vector, if the values, and >> > vector >> > > are not managed properly. >> > > >> > > >> > > -----Original Message----- >> > > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] >> > > Sent: Sunday, October 25, 2020 11:27 PM >> > > To: dev@nuttx.apache.org >> > > Subject: Re: interrupt priorities on nRF52 >> > > >> > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. <mat...@imap.cc> wrote: >> > > >> > > > Hi, >> > > > while working on nRF52 BLE link-layer I experienced some problems >> > > > due >> > to >> > > > delayed ISRs. This can be quite problematic >> > > > for handling all the tight timings required by the standard. I >> > eventually >> > > > reached an implementation that can deal with this relatively well >> > > > (BLE >> > > > standard gives some leeway for some small number of dropped packets >> > > > and >> > > > also retransmits missing ones). However, as other peripherals start >> > > > generating more interrupts, this could actually become a problem. >> > Also, I >> > > > think it would be good to know BLE ISRs will always have priority. >> > > > >> > > > I've been looking into how ISRs can be prioritized but I don't have >> > much >> > > > experience with this, so I have some questions: >> > > > * Does nRF52 need explicit support for handling interrupts with >> > different >> > > > priorities or is the support supposed to be taken care of at the >> > > > ARM >> > level >> > > > code? >> > > > * How well supported is this in nRF52/ARM? >> > > > >> > > >> > > You can call up_prioritize_irq(at least Cortex-M implement it) to >> > > change >> > > the ISR priority. >> > > >> > > >> > > > * Do interrupt priorities imply nested interrupts? It isn't clear >> > > > to >> > me if >> > > > priorities only mean which ISR will get served first when they are >> > pending >> > > > together or if it also implies that a low priority >> > > >> > > >> > > But the priority difference doesn't imply that the nested interrupt >> > happens >> > > automatically, you have to enable the interrupt manually after the >> > critical >> > > CPU register and OS state is saved. >> > > >> > > interrupt can be interrupted to handle a higher priority one (I >> > > believe >> > the >> > > > latter is what is usually refered to as "nested interrupts") >> > > > * How does enter_critical_section() deal with priorities? How do I >> > > > know >> > > > which priority is masked and which one isn't? >> > > > >> > > >> > > The critical section always mask all interrupts, but there is a >> > > special >> > > feature(Zero Latency Interrupts) on Cortex-M: >> > > >> > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts >> > > We enable this feature to fix the same issue two years ago. >> > > But many code abuses the critical section and sched lock in many >> > > places, >> > we >> > > should address these problems gradually by: >> > > 1.Replace the critical section to semaphore if suitable >> > > 2.Replace the critical section to spin lock if suitable >> > > 3.Break the large critical section into several small one >> > > These changes not only reduce the interrupt latency, but also >> > > increase >> > the >> > > performance in the SMP case. >> > > >> > > >> > > > * Which configs should I enable to try this? >> > > > >> > > > Thanks, >> > > > Matias >> > > >> > > >> > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. <mat...@imap.cc> wrote: >> > > >> > > > Hi, >> > > > while working on nRF52 BLE link-layer I experienced some problems >> > > > due >> > to >> > > > delayed ISRs. This can be quite problematic >> > > > for handling all the tight timings required by the standard. I >> > eventually >> > > > reached an implementation that can deal with this relatively well >> > > > (BLE >> > > > standard gives some leeway for some small number of dropped packets >> > > > and >> > > > also retransmits missing ones). However, as other peripherals start >> > > > generating more interrupts, this could actually become a problem. >> > Also, I >> > > > think it would be good to know BLE ISRs will always have priority. >> > > > >> > > > I've been looking into how ISRs can be prioritized but I don't have >> > much >> > > > experience with this, so I have some questions: >> > > > * Does nRF52 need explicit support for handling interrupts with >> > different >> > > > priorities or is the support supposed to be taken care of at the >> > > > ARM >> > level >> > > > code? >> > > > * How well supported is this in nRF52/ARM? >> > > > * Do interrupt priorities imply nested interrupts? It isn't clear >> > > > to >> > me if >> > > > priorities only mean which ISR will get served first when they are >> > pending >> > > > together or if it also implies that a low priority interrupt can be >> > > > interrupted to handle a higher priority one (I believe the latter >> > > > is >> > what >> > > > is usually refered to as "nested interrupts") >> > > > * How does enter_critical_section() deal with priorities? How do I >> > > > know >> > > > which priority is masked and which one isn't? >> > > > * Which configs should I enable to try this? >> > > > >> > > > Thanks, >> > > > Matias >> > > >> > >> >> 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. >> > >> > Best, >> > Matias >> > >> > On Mon, Oct 26, 2020, at 10:21, David Sidrane wrote: >> > > > But the priority difference doesn't imply that the nested interrupt >> > > > happens >> > > automatically, you have to enable the interrupt manually after the >> > critical >> > > CPU register and OS state is saved. >> > > >> > > My recollection is it depends on the priority assigned to the >> > > interrupt >> > and >> > > the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The >> > system >> > > will crash due to reentrancy on the common vector, if the values, and >> > vector >> > > are not managed properly. >> > > >> > > >> > > -----Original Message----- >> > > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] >> > > Sent: Sunday, October 25, 2020 11:27 PM >> > > To: dev@nuttx.apache.org >> > > Subject: Re: interrupt priorities on nRF52 >> > > >> > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. <mat...@imap.cc> wrote: >> > > >> > > > Hi, >> > > > while working on nRF52 BLE link-layer I experienced some problems >> > > > due >> > to >> > > > delayed ISRs. This can be quite problematic >> > > > for handling all the tight timings required by the standard. I >> > eventually >> > > > reached an implementation that can deal with this relatively well >> > > > (BLE >> > > > standard gives some leeway for some small number of dropped packets >> > > > and >> > > > also retransmits missing ones). However, as other peripherals start >> > > > generating more interrupts, this could actually become a problem. >> > Also, I >> > > > think it would be good to know BLE ISRs will always have priority. >> > > > >> > > > I've been looking into how ISRs can be prioritized but I don't have >> > much >> > > > experience with this, so I have some questions: >> > > > * Does nRF52 need explicit support for handling interrupts with >> > different >> > > > priorities or is the support supposed to be taken care of at the >> > > > ARM >> > level >> > > > code? >> > > > * How well supported is this in nRF52/ARM? >> > > > >> > > >> > > You can call up_prioritize_irq(at least Cortex-M implement it) to >> > > change >> > > the ISR priority. >> > > >> > > >> > > > * Do interrupt priorities imply nested interrupts? It isn't clear >> > > > to >> > me if >> > > > priorities only mean which ISR will get served first when they are >> > pending >> > > > together or if it also implies that a low priority >> > > >> > > >> > > But the priority difference doesn't imply that the nested interrupt >> > happens >> > > automatically, you have to enable the interrupt manually after the >> > critical >> > > CPU register and OS state is saved. >> > > >> > > interrupt can be interrupted to handle a higher priority one (I >> > > believe >> > the >> > > > latter is what is usually refered to as "nested interrupts") >> > > > * How does enter_critical_section() deal with priorities? How do I >> > > > know >> > > > which priority is masked and which one isn't? >> > > > >> > > >> > > The critical section always mask all interrupts, but there is a >> > > special >> > > feature(Zero Latency Interrupts) on Cortex-M: >> > > >> > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts >> > > We enable this feature to fix the same issue two years ago. >> > > But many code abuses the critical section and sched lock in many >> > > places, >> > we >> > > should address these problems gradually by: >> > > 1.Replace the critical section to semaphore if suitable >> > > 2.Replace the critical section to spin lock if suitable >> > > 3.Break the large critical section into several small one >> > > These changes not only reduce the interrupt latency, but also >> > > increase >> > the >> > > performance in the SMP case. >> > > >> > > >> > > > * Which configs should I enable to try this? >> > > > >> > > > Thanks, >> > > > Matias >> > > >> > > >> > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. <mat...@imap.cc> wrote: >> > > >> > > > Hi, >> > > > while working on nRF52 BLE link-layer I experienced some problems >> > > > due >> > to >> > > > delayed ISRs. This can be quite problematic >> > > > for handling all the tight timings required by the standard. I >> > eventually >> > > > reached an implementation that can deal with this relatively well >> > > > (BLE >> > > > standard gives some leeway for some small number of dropped packets >> > > > and >> > > > also retransmits missing ones). However, as other peripherals start >> > > > generating more interrupts, this could actually become a problem. >> > Also, I >> > > > think it would be good to know BLE ISRs will always have priority. >> > > > >> > > > I've been looking into how ISRs can be prioritized but I don't have >> > much >> > > > experience with this, so I have some questions: >> > > > * Does nRF52 need explicit support for handling interrupts with >> > different >> > > > priorities or is the support supposed to be taken care of at the >> > > > ARM >> > level >> > > > code? >> > > > * How well supported is this in nRF52/ARM? >> > > > * Do interrupt priorities imply nested interrupts? It isn't clear >> > > > to >> > me if >> > > > priorities only mean which ISR will get served first when they are >> > pending >> > > > together or if it also implies that a low priority interrupt can be >> > > > interrupted to handle a higher priority one (I believe the latter >> > > > is >> > what >> > > > is usually refered to as "nested interrupts") >> > > > * How does enter_critical_section() deal with priorities? How do I >> > > > know >> > > > which priority is masked and which one isn't? >> > > > * Which configs should I enable to try this? >> > > > >> > > > Thanks, >> > > > Matias >> > > >> > >> >
