mirror/rtic
1
0
Fork 0
mirror of https://github.com/rtic-rs/rtic.git synced 2024-11-23 20:22:51 +01:00
Code Issues Projects Releases Packages Wiki Activity

Update app.md

Browse source
This commit is contained in:
KENTARO OKUDA 2020-05-13 07:35:51 -04:00
parent 7406f77a4e
commit 6e59dacdc3
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
book/en/src/by-example/app.md
View file

@ -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!