nuttx/nuttx-update
1
2
Fork 1
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Documentation: Tweak text about Zero Latency Interrupts

Browse source 
This is a follow-up to 366c8a5d94 (PR-15102).

* Documentation/guides/zerolatencyinterrupts.rst
  (Title): Make title case consistent.
  (Getting Back into the Game, Maskable Nested Interrupts): Clarify discussion
   about priorities.
  (Cortex-M3/4 Implementation): The first half of a sentence was deleted in
   366c8a5d9 because the Kconfig that was described there no longer exists:
   CONFIG_ARMV7M_USEBASEPRI. Write a new beginning for this sentence that
   matches current implementation.
  (Disabling the High Priority Interrupt): Change "cannot" to "must not be
   allowed to" to improve clarity.
  (Configuring High Priority Interrupts): Change "to NVIC" to "in NVIC" to
   improve clarity.
This commit is contained in:
Nathan Hartman 2024-12-10 11:50:59 -05:00 committed by Xiang Xiao
parent 34d1a7fd54
commit 532bf64515
1 changed files with 14 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
Documentation/guides/zerolatencyinterrupts.rst
View file

@ -1,5 +1,5 @@
===================================================================== =====================================================================
High Performance: Zero Latency Interrupts, Maskable nested interrupts High Performance: Zero Latency Interrupts, Maskable Nested Interrupts
===================================================================== =====================================================================
Generic Interrupt Handling Generic Interrupt Handling
@ -125,9 +125,11 @@ The following table shows the priority levels of the Cortex-M family:
Low prio IRQ 0xB0 Low prio IRQ 0xB0
PendSV 0xE0 PendSV 0xE0
As you can see, the priority levels of the zero-latency interrupts can Lower priority *numbers* mean a higher priority on this architecture.
beyond the critical section and SVC.
But High prio IRQ can't call OS API. As you can see, the zero-latency interrupts have higher priority than
the critical section and SVC, but with the tradeoff that High prio IRQ
can't call OS APIs in ISR.
Maskable Nested Interrupts Maskable Nested Interrupts
@ -162,9 +164,11 @@ The following table shows the priority levels of the Cortex-M family:
Low prio IRQ 0xB0 Low prio IRQ 0xB0
PendSV 0xE0 PendSV 0xE0
Lower priority *numbers* mean a higher priority on this architecture.
As you can see, the priority levels of the maskable nested interrupts As you can see, the priority levels of the maskable nested interrupts
are between the critical section and the low-priority interrupts. are between the critical section and the low-priority interrupts. In
And High prio IRQ can call OS API in ISR. this case, High prio IRQ can call OS APIs in ISR.
Nested Interrupt Handling Nested Interrupt Handling
@ -216,6 +220,7 @@ Configuration Options
``CONFIG_ARCH_HIPRI_INTERRUPT`` ``CONFIG_ARCH_HIPRI_INTERRUPT``
The OS disables interrupts by setting the *BASEPRI* register to
``NVIC_SYSH_DISABLE_PRIORITY`` so that most interrupts will not have ``NVIC_SYSH_DISABLE_PRIORITY`` so that most interrupts will not have
execution priority. *SVCall* must have execution priority in all execution priority. *SVCall* must have execution priority in all
cases. cases.
@ -253,8 +258,8 @@ priority interrupt response time.
Hence, if you need to disable the high priority interrupt, you will Hence, if you need to disable the high priority interrupt, you will
have to disable the interrupt either at the peripheral that generates have to disable the interrupt either at the peripheral that generates
the interrupt or at the interrupt controller, the *NVIC*. Disabling the interrupt or at the interrupt controller, the *NVIC*. Disabling
global interrupts via the *BASEPRI* register cannot affect high global interrupts via the *BASEPRI* register must not be allowed to
priority interrupts. affect high priority interrupts.
Dependencies Dependencies
------------ ------------
@ -285,7 +290,7 @@ There are two ways to do this:
* Alternatively, you could keep your vectors in FLASH but in order to * Alternatively, you could keep your vectors in FLASH but in order to
this, you would have to develop your own custom vector table. this, you would have to develop your own custom vector table.
Second, you need to set the priority of your interrupt to *NVIC* to Second, you need to set the priority of your interrupt in *NVIC* to
``NVIC_SYSH_HIGH_PRIORITY`` using the standard interface: ``NVIC_SYSH_HIGH_PRIORITY`` using the standard interface:
``int up_prioritize_irq(int irq, int priority);`` ``int up_prioritize_irq(int irq, int priority);``