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 >
