mirror of
https://github.com/rtic-rs/rtic.git
synced 2024-11-23 20:22:51 +01:00
Merge #310
310: Update app.md r=korken89 a=lonesometraveler - Fix typos - Improve readability Co-authored-by: KENTARO OKUDA <lonesometraveler@mac.com>
This commit is contained in:
commit
0b3cc87f2d
1 changed files with 4 additions and 4 deletions
|
@ -106,7 +106,7 @@ mut` variables are safe to use within a hardware task.
|
||||||
$ cargo run --example hardware
|
$ cargo run --example hardware
|
||||||
{{#include ../../../../ci/expected/hardware.run}}```
|
{{#include ../../../../ci/expected/hardware.run}}```
|
||||||
|
|
||||||
So far all the RTFM applications we have seen look no different that the
|
So far all the RTFM applications we have seen look no different than the
|
||||||
applications one can write using only the `cortex-m-rt` crate. From this point
|
applications one can write using only the `cortex-m-rt` crate. From this point
|
||||||
we start introducing features unique to RTFM.
|
we start introducing features unique to RTFM.
|
||||||
|
|
||||||
|
@ -115,7 +115,7 @@ we start introducing features unique to RTFM.
|
||||||
The static priority of each handler can be declared in the `task` attribute
|
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 <<
|
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`
|
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
|
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
|
`1`. The `idle` task has a non-configurable static priority of `0`, the lowest
|
||||||
priority.
|
priority.
|
||||||
|
|
||||||
|
@ -140,12 +140,12 @@ $ cargo run --example preempt
|
||||||
|
|
||||||
Note that the task `gpiob` does *not* preempt task `gpioc` because its priority
|
Note that the task `gpiob` does *not* preempt task `gpioc` because its priority
|
||||||
is the *same* as `gpioc`'s. However, once `gpioc` terminates the execution of
|
is the *same* as `gpioc`'s. However, once `gpioc` terminates the execution of
|
||||||
task `gpiob` is prioritized over `gpioa`'s due to its higher priority. `gpioa`
|
task, `gpiob` is prioritized over `gpioa` due to its higher priority. `gpioa`
|
||||||
is resumed only after `gpiob` terminates.
|
is resumed only after `gpiob` terminates.
|
||||||
|
|
||||||
One more note about priorities: choosing a priority higher than what the device
|
One more note about priorities: choosing a priority higher than what the device
|
||||||
supports (that is `1 << NVIC_PRIO_BITS`) will result in a compile error. Due to
|
supports (that is `1 << NVIC_PRIO_BITS`) will result in a compile error. Due to
|
||||||
limitations in the language the error message is currently far from helpful: it
|
limitations in the language, the error message is currently far from helpful: it
|
||||||
will say something along the lines of "evaluation of constant value failed" and
|
will say something along the lines of "evaluation of constant value failed" and
|
||||||
the span of the error will *not* point out to the problematic interrupt value --
|
the span of the error will *not* point out to the problematic interrupt value --
|
||||||
we are sorry about this!
|
we are sorry about this!
|
||||||
|
|
Loading…
Reference in a new issue