mirror/rtic
1
0
Fork 0
mirror of https://github.com/rtic-rs/rtic.git synced 2024-12-01 16:04:33 +01:00
Code Issues Projects Releases Packages Wiki Activity

book.toml/by-example/app

Browse source
This commit is contained in:
Per Lindgren 2020-11-12 18:20:16 +01:00
parent ad50b54530
commit 91ea1e428b
2 changed files with 9 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
book/en/book.toml
View file

@ -1,5 +1,5 @@
[book] [book]
authors = ["Jorge Aparicio"] authors = ["Jorge Aparicio, Per Lindgren and The Real-Time Interrupt-driven Concurrency developers"]
multilingual = false multilingual = false
src = "src" src = "src"
title = "Real-Time Interrupt-driven Concurrency" title = "Real-Time Interrupt-driven Concurrency"

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

@ -34,14 +34,13 @@ And optionally, device specific peripherals through the `core` and `device` fiel
of `init::Context`. of `init::Context`.
`static mut` variables declared at the beginning of `init` will be transformed `static mut` variables declared at the beginning of `init` will be transformed
into `&'static mut` references that are safe to access. into `&'static mut` references that are safe to access. Notice, this feature may be deprecated in next release, see `task_local` resources.
[`rtic::Peripherals`]: ../../api/rtic/struct.Peripherals.html [`rtic::Peripherals`]: ../../api/rtic/struct.Peripherals.html
The example below shows the types of the `core`, `device` and `cs` fields, and The example below shows the types of the `core`, `device` and `cs` fields, and
showcases safe access to a `static mut` variable. The `device` field is only showcases safe access to a `static mut` variable. The `device` field is only
available when the `peripherals` argument is set to `true` (it defaults to available when the `peripherals` argument is set to `true` (default). In the rare case you want to implement an ultra-slim application you can explicitly set `peripherals` to `false`.
`false`).
``` rust ``` rust
{{#include ../../../../examples/init.rs}} {{#include ../../../../examples/init.rs}}
@ -71,12 +70,12 @@ then sends the microcontroller to sleep after running `init`.
[SLEEPONEXIT]: https://developer.arm.com/docs/100737/0100/power-management/sleep-mode/sleep-on-exit-bit [SLEEPONEXIT]: https://developer.arm.com/docs/100737/0100/power-management/sleep-mode/sleep-on-exit-bit
Like in `init`, `static mut` variables will be transformed into `&'static mut` Like in `init`, `static mut` variables will be transformed into `&'static mut`
references that are safe to access. references that are safe to access. Notice, this feature may be deprecated in the next release, see `task_local` resources.
The example below shows that `idle` runs after `init`. The example below shows that `idle` runs after `init`.
**Note:** The `loop {}` in idle cannot be empty as this will crash the microcontroller due to a bug **Note:** The `loop {}` in idle cannot be empty as this will crash the microcontroller due to
in LLVM which miss-optimizes empty loops to a `UDF` instruction in release mode. LLVM compiling empty loops to an `UDF` instruction in release mode. To avoid UB, the loop needs to imply a "side-effect" by inserting an assembly instruction (e.g., `WFI`) or a `continue`.
``` rust ``` rust
{{#include ../../../../examples/idle.rs}} {{#include ../../../../examples/idle.rs}}
@ -146,9 +145,9 @@ $ 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` returns, the execution of
task, `gpiob` is prioritized over `gpioa` 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` returns.
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