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 > > > > > >
