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
