395: Made relation between priority and number explicit r=korken89 a=diondokter

When quickly reading through the priorities chapter, I couldn't find in which order the priorities were, so I assumed it was the same as in the hardware.
In the cortex-m hardware, interrupts with the **lower** priority number will preempt the other interrupts.
RTIC does the reverse, so I think it's good to be more explicit about it.

Co-authored-by: Dion Dokter <diondokter@gmail.com>
This commit is contained in:
bors[bot] 2020-10-15 16:05:45 +00:00 committed by GitHub
commit f9303cef1c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -119,10 +119,13 @@ The static priority of each handler can be declared in the `task` attribute
using the `priority` argument. Tasks can have priorities in the range `1..=(1 <<
NVIC_PRIO_BITS)` where `NVIC_PRIO_BITS` is a constant defined in the `device`
crate. When the `priority` argument is omitted, the priority is assumed to be
`1`. The `idle` task has a non-configurable static priority of `0`, the lowest
priority.
`1`. The `idle` task has a non-configurable static priority of `0`, the lowest priority.
When several tasks are ready to be executed the one with *highest* static
> A higher number means a higher priority in RTIC, which is the opposite from what
> Cortex-M does in the NVIC peripheral.
> Explicitly, this means that number `10` has a **higher** priority than number `9`.
When several tasks are ready to be executed the one with highest static
priority will be executed first. Task prioritization can be observed in the
following scenario: an interrupt signal arrives during the execution of a low
priority task; the signal puts the higher priority task in the pending state.