From 163edd7579222560caf6598cf8071f4201c277c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= Date: Thu, 1 Oct 2020 16:59:27 +0000 Subject: Start updating the book --- book/en/src/by-example/app.md | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) (limited to 'book/en/src/by-example/app.md') diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md index 9a073ac..4262391 100644 --- a/book/en/src/by-example/app.md +++ b/book/en/src/by-example/app.md @@ -7,7 +7,7 @@ This is the smallest possible RTIC application: ``` All RTIC applications use the [`app`] attribute (`#[app(..)]`). This attribute -must be applied to a `const` item that contains items. The `app` attribute has +must be applied to a `mod`-item. The `app` attribute has a mandatory `device` argument that takes a *path* as a value. This path must point to a *peripheral access crate* (PAC) generated using [`svd2rust`] **v0.14.x** or newer. The `app` attribute will expand into a suitable entry @@ -17,16 +17,9 @@ point so it's not required to use the [`cortex_m_rt::entry`] attribute. [`svd2rust`]: https://crates.io/crates/svd2rust [`cortex_m_rt::entry`]: ../../../api/cortex_m_rt_macros/attr.entry.html -> **ASIDE**: Some of you may be wondering why we are using a `const` item as a -> module and not a proper `mod` item. The reason is that using attributes on -> modules requires a feature gate, which requires a nightly toolchain. To make -> RTIC work on stable we use the `const` item instead. When more parts of macros -> 1.2 are stabilized we'll move from a `const` item to a `mod` item and -> eventually to a crate level attribute (`#![app]`). - ## `init` -Within the pseudo-module the `app` attribute expects to find an initialization +Within the `app` module the attribute expects to find an initialization function marked with the `init` attribute. This function must have signature `fn(init::Context) [-> init::LateResources]` (the return type is not always required). @@ -60,7 +53,7 @@ $ cargo run --example init ## `idle` A function marked with the `idle` attribute can optionally appear in the -pseudo-module. This function is used as the special *idle task* and must have +module. This function is used as the special *idle task* and must have signature `fn(idle::Context) - > !`. When present, the runtime will execute the `idle` task after `init`. Unlike -- cgit v1.2.3 From baa2edfe72ec2e33a84dfebc6c4baf2c2b8d55c2 Mon Sep 17 00:00:00 2001 From: Daniel Carosone Date: Fri, 2 Oct 2020 19:38:00 +1000 Subject: close console text blocks on a new line fixes #369 --- book/en/src/by-example/app.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'book/en/src/by-example/app.md') diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md index 9a073ac..344cefc 100644 --- a/book/en/src/by-example/app.md +++ b/book/en/src/by-example/app.md @@ -55,7 +55,8 @@ process. ``` console $ cargo run --example init -{{#include ../../../../ci/expected/init.run}}``` +{{#include ../../../../ci/expected/init.run}} +``` ## `idle` @@ -86,7 +87,8 @@ in LLVM which miss-optimizes empty loops to a `UDF` instruction in release mode. ``` console $ cargo run --example idle -{{#include ../../../../ci/expected/idle.run}}``` +{{#include ../../../../ci/expected/idle.run}} +``` ## Hardware tasks @@ -107,7 +109,8 @@ mut` variables are safe to use within a hardware task. ``` console $ cargo run --example hardware -{{#include ../../../../ci/expected/hardware.run}}``` +{{#include ../../../../ci/expected/hardware.run}} +``` So far all the RTIC applications we have seen look no different than the applications one can write using only the `cortex-m-rt` crate. From this point @@ -139,7 +142,8 @@ The following example showcases the priority based scheduling of tasks. ``` console $ cargo run --example preempt -{{#include ../../../../ci/expected/preempt.run}}``` +{{#include ../../../../ci/expected/preempt.run}} +``` 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 -- cgit v1.2.3 From f0f982facadab2da5d8cdaf214829a9e19f4249e Mon Sep 17 00:00:00 2001 From: Emil Fresk Date: Sat, 3 Oct 2020 15:30:15 +0200 Subject: Updated documentation to include the critical section token in init --- book/en/src/by-example/app.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'book/en/src/by-example/app.md') diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md index 344cefc..23bff68 100644 --- a/book/en/src/by-example/app.md +++ b/book/en/src/by-example/app.md @@ -33,15 +33,16 @@ required). This initialization function will be the first part of the application to run. The `init` function will run *with interrupts disabled* and has exclusive access -to Cortex-M and, optionally, device specific peripherals through the `core` and -`device` fields of `init::Context`. +to Cortex-M where the `bare_metal::CriticalSection` token is available as `cs`. +And optionally, device specific peripherals through the `core` and `device` fields +of `init::Context`. `static mut` variables declared at the beginning of `init` will be transformed into `&'static mut` references that are safe to access. [`rtic::Peripherals`]: ../../api/rtic/struct.Peripherals.html -The example below shows the types of the `core` and `device` 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 available when the `peripherals` argument is set to `true` (it defaults to `false`). -- cgit v1.2.3