mirror of
https://github.com/rtic-rs/rtic.git
synced 2024-12-25 03:19:34 +01:00
book: Update default priority to 0
This commit is contained in:
parent
57be9b0dc9
commit
cc1e7154fc
3 changed files with 4 additions and 4 deletions
|
@ -32,7 +32,7 @@ Overall, the generated code infers no additional overhead in comparison to a han
|
|||
|
||||
## Priority
|
||||
|
||||
Priorities in RTIC are specified using the `priority = N` (where N is a positive number) argument passed to the `#[task]` attribute. All `#[task]`s can have a priority. If the priority of a task is not specified, it is set to the default value of 1.
|
||||
Priorities in RTIC are specified using the `priority = N` (where N is a positive number) argument passed to the `#[task]` attribute. All `#[task]`s can have a priority. If the priority of a task is not specified, it is set to the default value of 0.
|
||||
|
||||
Priorities in RTIC follow a higher value = more important scheme. For examples, a task with priority 2 will preempt a task with priority 1.
|
||||
|
||||
|
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
The `priority` argument declares the static priority of each `task`.
|
||||
|
||||
For Cortex-M, tasks can have priorities in the range `1..=(1 << NVIC_PRIO_BITS)` where `NVIC_PRIO_BITS` is a constant defined in the `device` crate.
|
||||
For Cortex-M, tasks can have priorities in the range `0..=(1 << NVIC_PRIO_BITS)` where `NVIC_PRIO_BITS` is a constant defined in the `device` crate.
|
||||
|
||||
Omitting the `priority` argument the task priority defaults to `1`. The `idle` task has a non-configurable static priority of `0`, the lowest priority.
|
||||
Omitting the `priority` argument the task priority defaults to `0`. The `idle` task has a non-configurable static priority of `0`, the lowest priority.
|
||||
|
||||
> A higher number means a higher priority in RTIC, which is the opposite from what
|
||||
> Cortex-M does in the NVIC peripheral.
|
||||
|
|
|
@ -35,7 +35,7 @@ $ cargo run --target thumbv7m-none-eabi --example spawn
|
|||
```
|
||||
You may `spawn` a *software* task again, given that it has run-to-completion (returned).
|
||||
|
||||
In the below example, we `spawn` the *software* task `foo` from the `idle` task. Since the default priority of the *software* task is 1 (higher than `idle`), the dispatcher will execute `foo` (preempting `idle`). Since `foo` runs-to-completion. It is ok to `spawn` the `foo` task again.
|
||||
In the below example, we `spawn` the *software* task `foo` from the `idle` task. Since the priority of the *software* task is 1 (higher than `idle`), the dispatcher will execute `foo` (preempting `idle`). Since `foo` runs-to-completion. It is ok to `spawn` the `foo` task again.
|
||||
|
||||
Technically the async executor will `poll` the `foo` *future* which in this case leaves the *future* in a *completed* state.
|
||||
|
||||
|
|
Loading…
Reference in a new issue