Merge branch 'master' into always_late_resources

6 files changed, 48 insertions, 36 deletions

diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md
index 9a073ac..ab6f452 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,31 +17,25 @@ 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).
 
 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`).
@@ -55,12 +49,13 @@ process.
 
 ```  console
 $ cargo run --example init
-{{#include ../../../../ci/expected/init.run}}```
+{{#include ../../../../ci/expected/init.run}}
+```
 
 ## `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
@@ -86,7 +81,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 +103,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 +136,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
diff --git a/book/en/src/by-example/new.md b/book/en/src/by-example/new.md
index abcc36d..866a9fa 100644
--- a/book/en/src/by-example/new.md
+++ b/book/en/src/by-example/new.md
@@ -63,4 +63,5 @@ $ cargo add panic-semihosting
 ``` console
 $ # NOTE: I have uncommented the `runner` option in `.cargo/config`
 $ cargo run
-{{#include ../../../../ci/expected/init.run}}```
+{{#include ../../../../ci/expected/init.run}}
+```
diff --git a/book/en/src/by-example/resources.md b/book/en/src/by-example/resources.md
index b9e92d1..d082dfc 100644
--- a/book/en/src/by-example/resources.md
+++ b/book/en/src/by-example/resources.md
@@ -4,11 +4,13 @@ The framework provides an abstraction to share data between any of the contexts
 we saw in the previous section (task handlers, `init` and `idle`): resources.
 
 Resources are data visible only to functions declared within the `#[app]`
-pseudo-module. The framework gives the user complete control over which context
+module. The framework gives the user complete control over which context
 can access which resource.
 
 All resources are declared as a single `struct` within the `#[app]`
-pseudo-module. Each field in the structure corresponds to a different resource.
+module. Each field in the structure corresponds to a different resource.
+The `struct` must be annotated with the following attribute: `#[resources]`.
+
 Resources can optionally be given an initial value using the `#[init]`
 attribute. Resources that are not given an initial value are referred to as
 *late* resources and are covered in more detail in a follow-up section in this
@@ -29,7 +31,8 @@ access to a resource named `shared`.
 
 ``` console
 $ cargo run --example resource
-{{#include ../../../../ci/expected/resource.run}}```
+{{#include ../../../../ci/expected/resource.run}}
+```
 
 Note that the `shared` resource cannot be accessed from `idle`. Attempting to do
 so results in a compile error.
@@ -71,7 +74,8 @@ lowest priority handler.
 
 ``` console
 $ cargo run --example lock
-{{#include ../../../../ci/expected/lock.run}}```
+{{#include ../../../../ci/expected/lock.run}}
+```
 
 ## Late resources
 
@@ -97,7 +101,8 @@ the consumer resource.
 
 ``` console
 $ cargo run --example late
-{{#include ../../../../ci/expected/late.run}}```
+{{#include ../../../../ci/expected/late.run}}
+```
 
 ## Only shared access
 
@@ -127,4 +132,5 @@ any kind of lock.
 
 ``` console
 $ cargo run --example only-shared-access
-{{#include ../../../../ci/expected/only-shared-access.run}}```
+{{#include ../../../../ci/expected/only-shared-access.run}}
+```
diff --git a/book/en/src/by-example/tasks.md b/book/en/src/by-example/tasks.md
index d0b5acb..ba16404 100644
--- a/book/en/src/by-example/tasks.md
+++ b/book/en/src/by-example/tasks.md
@@ -25,7 +25,8 @@ priorities. The three software tasks are mapped to 2 interrupts handlers.
 
 ``` console
 $ cargo run --example task
-{{#include ../../../../ci/expected/task.run}}```
+{{#include ../../../../ci/expected/task.run}}
+```
 
 ## Message passing
 
@@ -41,7 +42,8 @@ The example below showcases three tasks, two of them expect a message.
 
 ``` console
 $ cargo run --example message
-{{#include ../../../../ci/expected/message.run}}```
+{{#include ../../../../ci/expected/message.run}}
+```
 
 ## Capacity
 
@@ -63,7 +65,8 @@ fail (panic).
 
 ``` console
 $ cargo run --example capacity
-{{#include ../../../../ci/expected/capacity.run}}```
+{{#include ../../../../ci/expected/capacity.run}}
+```
 
 ## Error handling
 
@@ -92,7 +95,7 @@ following snippet:
 
 ``` rust
 #[rtic::app(..)]
-const APP: () = {
+mod app {
     #[init(spawn = [foo, bar])]
     fn init(cx: init::Context) {
         cx.spawn.foo().unwrap();
@@ -113,5 +116,5 @@ const APP: () = {
     fn bar(cx: bar::Context, payload: i32) {
         // ..
     }
-};
+}
 ```
diff --git a/book/en/src/by-example/tips.md b/book/en/src/by-example/tips.md
index b191b9d..d8264c9 100644
--- a/book/en/src/by-example/tips.md
+++ b/book/en/src/by-example/tips.md
@@ -24,7 +24,8 @@ Here's one such example:
 
 ``` console
 $ cargo run --example generics
-{{#include ../../../../ci/expected/generics.run}}```
+{{#include ../../../../ci/expected/generics.run}}
+```
 
 Using generics also lets you change the static priorities of tasks during
 development without having to rewrite a bunch code every time.
@@ -47,7 +48,8 @@ the program has been compiled using the `dev` profile.
 $ cargo run --example cfg --release
 
 $ cargo run --example cfg
-{{#include ../../../../ci/expected/cfg.run}}```
+{{#include ../../../../ci/expected/cfg.run}}
+```
 
 ## Running tasks from RAM
 
@@ -78,7 +80,8 @@ Running this program produces the expected output.
 
 ``` console
 $ cargo run --example ramfunc
-{{#include ../../../../ci/expected/ramfunc.run}}```
+{{#include ../../../../ci/expected/ramfunc.run}}
+```
 
 One can look at the output of `cargo-nm` to confirm that `bar` ended in RAM
 (`0x2000_0000`), whereas `foo` ended in Flash (`0x0000_0000`).
@@ -115,7 +118,8 @@ Here's an example where `heapless::Pool` is used to "box" buffers of 128 bytes.
 ```
 ``` console
 $ cargo run --example pool
-{{#include ../../../../ci/expected/pool.run}}```
+{{#include ../../../../ci/expected/pool.run}}
+```
 
 ## Inspecting the expanded code
 
@@ -139,7 +143,7 @@ $ tail target/rtic-expansion.rs
 
 ``` rust
 #[doc = r" Implementation details"]
-const APP: () = {
+mod app {
     #[doc = r" Always include the device crate which contains the vector table"]
     use lm3s6965 as _;
     #[no_mangle]
@@ -152,7 +156,7 @@ const APP: () = {
             rtic::export::wfi()
         }
     }
-};
+}
 ```
 
 Or, you can use the [`cargo-expand`] sub-command. This sub-command will expand
diff --git a/book/en/src/by-example/types-send-sync.md b/book/en/src/by-example/types-send-sync.md
index 41cd9ba..9cdb889 100644
--- a/book/en/src/by-example/types-send-sync.md
+++ b/book/en/src/by-example/types-send-sync.md
@@ -1,6 +1,6 @@
 # Types, Send and Sync
 
-Every function within the `APP` pseudo-module has a `Context` structure as its
+Every function within the `app` module has a `Context` structure as its
 first parameter. All the fields of these structures have predictable,
 non-anonymous types so you can write plain functions that take them as arguments.