From 21db4d1df4b3a3b7a2a6bf61d96d630abfe4d424 Mon Sep 17 00:00:00 2001
From: Eric Trombly <etrombly@yahoo.com>
Date: Fri, 19 Apr 2019 10:50:43 -0500
Subject: add sandbox example

---
 book/en/src/by-example.md | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'book/en/src')

diff --git a/book/en/src/by-example.md b/book/en/src/by-example.md
index 0e09b03..cafbc86 100644
--- a/book/en/src/by-example.md
+++ b/book/en/src/by-example.md
@@ -14,3 +14,9 @@ program. Check [the embedded Rust book] for instructions on how to set up an
 embedded development environment that includes QEMU.
 
 [the embedded Rust book]: https://rust-embedded.github.io/book/intro/install.html
+
+## Real World Examples
+
+The following are examples of RTFM being used in real world projects.
+
+- [etrombly/sandbox](https://github.com/etrombly/sandbox/tree/4f5a230920ad815c0cfbc0e0ae5e39718d3f58fa). A hardware zen garden that draws patterns in sand. Patterns are sent over serial using G-code.
-- 
cgit v1.2.3


From 19212a9f706b7d66afae7d1e7efa669e24964351 Mon Sep 17 00:00:00 2001
From: Eric Trombly <etrombly@yahoo.com>
Date: Sun, 21 Apr 2019 09:21:33 -0500
Subject: update commit for example link and specify RTFM version

---
 book/en/src/by-example.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

(limited to 'book/en/src')

diff --git a/book/en/src/by-example.md b/book/en/src/by-example.md
index cafbc86..e19f074 100644
--- a/book/en/src/by-example.md
+++ b/book/en/src/by-example.md
@@ -19,4 +19,6 @@ embedded development environment that includes QEMU.
 
 The following are examples of RTFM being used in real world projects.
 
-- [etrombly/sandbox](https://github.com/etrombly/sandbox/tree/4f5a230920ad815c0cfbc0e0ae5e39718d3f58fa). A hardware zen garden that draws patterns in sand. Patterns are sent over serial using G-code.
+### RTFM V0.4.2
+
+- [etrombly/sandbox](https://github.com/etrombly/sandbox/tree/41d423bcdd0d8e42fd46b79771400a8ca349af55). A hardware zen garden that draws patterns in sand. Patterns are sent over serial using G-code.
-- 
cgit v1.2.3


From 163edd7579222560caf6598cf8071f4201c277c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
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')

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 0cc556a75aaee64a90ecab94854b3fc669cb61ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
Date: Thu, 1 Oct 2020 19:12:54 +0000
Subject: Remove all of heterogeneous and homogeneous from the book

---
 book/en/src/SUMMARY.md       | 2 --
 book/en/src/heterogeneous.md | 6 ------
 book/en/src/homogeneous.md   | 6 ------
 3 files changed, 14 deletions(-)
 delete mode 100644 book/en/src/heterogeneous.md
 delete mode 100644 book/en/src/homogeneous.md

(limited to 'book/en/src')

diff --git a/book/en/src/SUMMARY.md b/book/en/src/SUMMARY.md
index 25aef81..a573cbb 100644
--- a/book/en/src/SUMMARY.md
+++ b/book/en/src/SUMMARY.md
@@ -21,5 +21,3 @@
   - [Ceiling analysis](./internals/ceilings.md)
   - [Software tasks](./internals/tasks.md)
   - [Timer queue](./internals/timer-queue.md)
-- [Homogeneous multi-core support](./homogeneous.md)
-- [Heterogeneous multi-core support](./heterogeneous.md)
diff --git a/book/en/src/heterogeneous.md b/book/en/src/heterogeneous.md
deleted file mode 100644
index d2c3d6c..0000000
--- a/book/en/src/heterogeneous.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Heterogeneous multi-core support
-
-This section covers the *experimental* heterogeneous multi-core support provided
-by RTIC behind the `heterogeneous` Cargo feature.
-
-**Content coming soon**
diff --git a/book/en/src/homogeneous.md b/book/en/src/homogeneous.md
deleted file mode 100644
index bcf6d2b..0000000
--- a/book/en/src/homogeneous.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Homogeneous multi-core support
-
-This section covers the *experimental* homogeneous multi-core support provided
-by RTIC behind the `homogeneous` Cargo feature.
-
-**Content coming soon**
-- 
cgit v1.2.3


From 9ca10b0d8c735a06a3a0a3623a7fc5d09b5e948c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
Date: Fri, 2 Oct 2020 09:33:28 +0000
Subject: Add migration to 0.6 along with updated documentation

---
 book/en/src/by-example.md                        |  2 +-
 book/en/src/by-example/resources.md              |  4 +-
 book/en/src/by-example/tasks.md                  |  4 +-
 book/en/src/by-example/tips.md                   |  4 +-
 book/en/src/by-example/types-send-sync.md        |  2 +-
 book/en/src/internals/access.md                  | 12 ++--
 book/en/src/internals/ceilings.md                |  4 +-
 book/en/src/internals/critical-sections.md       | 24 +++----
 book/en/src/internals/interrupt-configuration.md |  4 +-
 book/en/src/internals/late-resources.md          |  8 +--
 book/en/src/internals/non-reentrancy.md          |  8 +--
 book/en/src/internals/tasks.md                   | 24 +++----
 book/en/src/internals/timer-queue.md             | 28 ++++----
 book/en/src/migration.md                         | 85 +++++++++++++++++++++---
 14 files changed, 140 insertions(+), 73 deletions(-)

(limited to 'book/en/src')

diff --git a/book/en/src/by-example.md b/book/en/src/by-example.md
index d452722..38985da 100644
--- a/book/en/src/by-example.md
+++ b/book/en/src/by-example.md
@@ -9,7 +9,7 @@ is required to follow along.
 
 [repository]: https://github.com/rtic-rs/cortex-m-rtic
 
-To run the examples on your laptop / PC you'll need the `qemu-system-arm`
+To run the examples on your computer you'll need the `qemu-system-arm`
 program. Check [the embedded Rust book] for instructions on how to set up an
 embedded development environment that includes QEMU.
 
diff --git a/book/en/src/by-example/resources.md b/book/en/src/by-example/resources.md
index b9e92d1..d63d135 100644
--- a/book/en/src/by-example/resources.md
+++ b/book/en/src/by-example/resources.md
@@ -4,11 +4,11 @@ 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.
 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
diff --git a/book/en/src/by-example/tasks.md b/book/en/src/by-example/tasks.md
index d0b5acb..9fefd02 100644
--- a/book/en/src/by-example/tasks.md
+++ b/book/en/src/by-example/tasks.md
@@ -92,7 +92,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 +113,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..0b6555e 100644
--- a/book/en/src/by-example/tips.md
+++ b/book/en/src/by-example/tips.md
@@ -139,7 +139,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 +152,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.
 
diff --git a/book/en/src/internals/access.md b/book/en/src/internals/access.md
index 6433707..3894470 100644
--- a/book/en/src/internals/access.md
+++ b/book/en/src/internals/access.md
@@ -15,7 +15,7 @@ To achieve the fine-grained access control where tasks can only access the
 static variables (resources) that they have specified in their RTIC attribute
 the RTIC framework performs a source code level transformation. This
 transformation consists of placing the resources (static variables) specified by
-the user *inside* a `const` item and the user code *outside* the `const` item.
+the user *inside* a module and the user code *outside* the module.
 This makes it impossible for the user code to refer to these static variables.
 
 Access to the resources is then given to each task using a `Resources` struct
@@ -29,7 +29,7 @@ happens behind the scenes:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     static mut X: u64: 0;
     static mut Y: bool: 0;
 
@@ -49,7 +49,7 @@ const APP: () = {
     }
 
     // ..
-};
+}
 ```
 
 The framework produces codes like this:
@@ -103,8 +103,8 @@ pub mod bar {
 }
 
 /// Implementation details
-const APP: () = {
-    // everything inside this `const` item is hidden from user code
+mod app {
+    // everything inside this module is hidden from user code
 
     static mut X: u64 = 0;
     static mut Y: bool = 0;
@@ -154,5 +154,5 @@ const APP: () = {
             // ..
         });
     }
-};
+}
 ```
diff --git a/book/en/src/internals/ceilings.md b/book/en/src/internals/ceilings.md
index 49d248a..07bd0ad 100644
--- a/book/en/src/internals/ceilings.md
+++ b/book/en/src/internals/ceilings.md
@@ -28,7 +28,7 @@ An example to illustrate the ceiling analysis:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     struct Resources {
         // accessed by `foo` (prio = 1) and `bar` (prio = 2)
         // -> CEILING = 2
@@ -80,5 +80,5 @@ const APP: () = {
     }
 
     // ..
-};
+}
 ```
diff --git a/book/en/src/internals/critical-sections.md b/book/en/src/internals/critical-sections.md
index f95a5a7..a064ad0 100644
--- a/book/en/src/internals/critical-sections.md
+++ b/book/en/src/internals/critical-sections.md
@@ -32,7 +32,7 @@ The example below shows the different types handed out to each task:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mut app {
     struct Resources {
         #[init(0)]
         x: u64,
@@ -57,7 +57,7 @@ const APP: () = {
     }
 
     // ..
-};
+}
 ```
 
 Now let's see how these types are created by the framework.
@@ -99,7 +99,7 @@ pub mod bar {
     }
 }
 
-const APP: () = {
+mod app {
     static mut x: u64 = 0;
 
     impl rtic::Mutex for resources::x {
@@ -129,7 +129,7 @@ const APP: () = {
             // ..
         })
     }
-};
+}
 ```
 
 ## `lock`
@@ -225,7 +225,7 @@ Consider this program:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     struct Resources {
         #[init(0)]
         x: u64,
@@ -277,7 +277,7 @@ const APP: () = {
     }
 
     // ..
-};
+}
 ```
 
 The code generated by the framework looks like this:
@@ -315,7 +315,7 @@ pub mod foo {
     }
 }
 
-const APP: () = {
+mod app {
     use cortex_m::register::basepri;
 
     #[no_mangle]
@@ -368,7 +368,7 @@ const APP: () = {
     }
 
     // repeat for resource `y`
-};
+}
 ```
 
 At the end the compiler will optimize the function `foo` into something like
@@ -430,7 +430,7 @@ handler through preemption. This is best observed in the following example:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     struct Resources {
         #[init(0)]
         x: u64,
@@ -484,7 +484,7 @@ const APP: () = {
         // ..
     }
 
-};
+}
 ```
 
 IMPORTANT: let's say we *forget* to roll back `BASEPRI` in `UART1` -- this would
@@ -493,7 +493,7 @@ be a bug in the RTIC code generator.
 ``` rust
 // code generated by RTIC
 
-const APP: () = {
+mod app {
     // ..
 
     #[no_mangle]
@@ -513,7 +513,7 @@ const APP: () = {
         // BUG: FORGOT to roll back the BASEPRI to the snapshot value we took before
         basepri::write(initial);
     }
-};
+}
 ```
 
 The consequence is that `idle` will run at a dynamic priority of `2` and in fact
diff --git a/book/en/src/internals/interrupt-configuration.md b/book/en/src/internals/interrupt-configuration.md
index 278707c..7aec9c9 100644
--- a/book/en/src/internals/interrupt-configuration.md
+++ b/book/en/src/internals/interrupt-configuration.md
@@ -13,7 +13,7 @@ This example gives you an idea of the code that the RTIC framework runs:
 
 ``` rust
 #[rtic::app(device = lm3s6965)]
-const APP: () = {
+mod app {
     #[init]
     fn init(c: init::Context) {
         // .. user code ..
@@ -28,7 +28,7 @@ const APP: () = {
     fn foo(c: foo::Context) {
         // .. user code ..
     }
-};
+}
 ```
 
 The framework generates an entry point that looks like this:
diff --git a/book/en/src/internals/late-resources.md b/book/en/src/internals/late-resources.md
index ad2a5e5..f3a0b0a 100644
--- a/book/en/src/internals/late-resources.md
+++ b/book/en/src/internals/late-resources.md
@@ -10,7 +10,7 @@ initialize late resources.
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     struct Resources {
         x: Thing,
     }
@@ -34,7 +34,7 @@ const APP: () = {
     }
 
     // ..
-};
+}
 ```
 
 The code generated by the framework looks like this:
@@ -69,7 +69,7 @@ pub mod foo {
 }
 
 /// Implementation details
-const APP: () = {
+mod app {
     // uninitialized static
     static mut x: MaybeUninit<Thing> = MaybeUninit::uninit();
 
@@ -101,7 +101,7 @@ const APP: () = {
             // ..
         })
     }
-};
+}
 ```
 
 An important detail here is that `interrupt::enable` behaves like a *compiler
diff --git a/book/en/src/internals/non-reentrancy.md b/book/en/src/internals/non-reentrancy.md
index 0b0e4a7..17b34d0 100644
--- a/book/en/src/internals/non-reentrancy.md
+++ b/book/en/src/internals/non-reentrancy.md
@@ -12,7 +12,7 @@ are discouraged from directly invoking an interrupt handler.
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     #[init]
     fn init(c: init::Context) { .. }
 
@@ -39,7 +39,7 @@ const APP: () = {
         // in aliasing of the static variable `X`
         unsafe { UART0() }
     }
-};
+}
 ```
 
 The RTIC framework must generate the interrupt handler code that calls the user
@@ -57,7 +57,7 @@ fn bar(c: bar::Context) {
     // .. user code ..
 }
 
-const APP: () = {
+mod app {
     // everything in this block is not visible to user code
 
     #[no_mangle]
@@ -69,7 +69,7 @@ const APP: () = {
     unsafe fn USART1() {
         bar(..);
     }
-};
+}
 ```
 
 ## By hardware
diff --git a/book/en/src/internals/tasks.md b/book/en/src/internals/tasks.md
index 995a885..a533dc0 100644
--- a/book/en/src/internals/tasks.md
+++ b/book/en/src/internals/tasks.md
@@ -28,7 +28,7 @@ Consider this example:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     // ..
 
     #[interrupt(binds = UART0, priority = 2, spawn = [bar, baz])]
@@ -51,7 +51,7 @@ const APP: () = {
     extern "C" {
         fn UART1();
     }
-};
+}
 ```
 
 The framework produces the following task dispatcher which consists of an
@@ -62,7 +62,7 @@ fn bar(c: bar::Context) {
     // .. user code ..
 }
 
-const APP: () = {
+mod app {
     use heapless::spsc::Queue;
     use cortex_m::register::basepri;
 
@@ -110,7 +110,7 @@ const APP: () = {
         // BASEPRI invariant
         basepri::write(snapshot);
     }
-};
+}
 ```
 
 ## Spawning a task
@@ -144,7 +144,7 @@ mod foo {
     }
 }
 
-const APP: () = {
+mod app {
     // ..
 
     // Priority ceiling for the producer endpoint of the `RQ1`
@@ -194,7 +194,7 @@ const APP: () = {
             }
         }
     }
-};
+}
 ```
 
 Using `bar_FQ` to limit the number of `bar` tasks that can be spawned may seem
@@ -211,7 +211,7 @@ fn baz(c: baz::Context, input: u64) {
     // .. user code ..
 }
 
-const APP: () = {
+mod app {
     // ..
 
     // Now we show the full contents of the `Ready` struct
@@ -263,13 +263,13 @@ const APP: () = {
             }
         }
     }
-};
+}
 ```
 
 And now let's look at the real implementation of the task dispatcher:
 
 ``` rust
-const APP: () = {
+mod app {
     // ..
 
     #[no_mangle]
@@ -304,7 +304,7 @@ const APP: () = {
         // BASEPRI invariant
         basepri::write(snapshot);
     }
-};
+}
 ```
 
 `INPUTS` plus `FQ`, the free queue, is effectively a memory pool. However,
@@ -357,7 +357,7 @@ Consider the following example:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     #[idle(spawn = [foo, bar])]
     fn idle(c: idle::Context) -> ! {
         // ..
@@ -382,7 +382,7 @@ const APP: () = {
     fn quux(c: quux::Context) {
         // ..
     }
-};
+}
 ```
 
 This is how the ceiling analysis would go:
diff --git a/book/en/src/internals/timer-queue.md b/book/en/src/internals/timer-queue.md
index 0eba106..fcd345c 100644
--- a/book/en/src/internals/timer-queue.md
+++ b/book/en/src/internals/timer-queue.md
@@ -12,7 +12,7 @@ Let's see how this in implemented in code. Consider the following program:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     // ..
 
     #[task(capacity = 2, schedule = [foo])]
@@ -24,7 +24,7 @@ const APP: () = {
     extern "C" {
         fn UART0();
     }
-};
+}
 ```
 
 ## `schedule`
@@ -46,7 +46,7 @@ mod foo {
     }
 }
 
-const APP: () = {
+mod app {
     type Instant = <path::to::user::monotonic::timer as rtic::Monotonic>::Instant;
 
     // all tasks that can be `schedule`-d
@@ -100,7 +100,7 @@ const APP: () = {
             }
         }
     }
-};
+}
 ```
 
 This looks very similar to the `Spawn` implementation. In fact, the same
@@ -123,7 +123,7 @@ is up.
 Let's see the associated code.
 
 ``` rust
-const APP: () = {
+mod app {
     #[no_mangle]
     fn SysTick() {
         const PRIORITY: u8 = 1;
@@ -146,7 +146,7 @@ const APP: () = {
             }
         }
     }
-};
+}
 ```
 
 This looks similar to a task dispatcher except that instead of running the
@@ -197,7 +197,7 @@ able to insert the task in the timer queue; this lets us omit runtime checks.
 
 ## System timer priority
 
-The priority of the system timer can't set by the user; it is chosen by the
+The priority of the system timer can't be set by the user; it is chosen by the
 framework. To ensure that lower priority tasks don't prevent higher priority
 tasks from running we choose the priority of the system timer to be the maximum
 of all the `schedule`-able tasks.
@@ -222,7 +222,7 @@ To illustrate, consider the following example:
 
 ``` rust
 #[rtic::app(device = ..)]
-const APP: () = {
+mod app {
     #[task(priority = 3, spawn = [baz])]
     fn foo(c: foo::Context) {
         // ..
@@ -237,7 +237,7 @@ const APP: () = {
     fn baz(c: baz::Context) {
         // ..
     }
-};
+}
 ```
 
 The ceiling analysis would go like this:
@@ -246,7 +246,7 @@ The ceiling analysis would go like this:
   `SysTick` must run at the highest priority between these two, that is `3`.
 
 - `foo::Spawn` (prio = 3) and `bar::Schedule` (prio = 2) contend over the
-  consumer endpoind of `baz_FQ`; this leads to a priority ceiling of `3`.
+  consumer endpoint of `baz_FQ`; this leads to a priority ceiling of `3`.
 
 - `bar::Schedule` (prio = 2) has exclusive access over the consumer endpoint of
 `foo_FQ`; thus the priority ceiling of `foo_FQ` is effectively `2`.
@@ -270,7 +270,7 @@ run; this `Instant` is read in the task dispatcher and passed to the user code
 as part of the task context.
 
 ``` rust
-const APP: () = {
+mod app {
     // ..
 
     #[no_mangle]
@@ -303,7 +303,7 @@ const APP: () = {
         // BASEPRI invariant
         basepri::write(snapshot);
     }
-};
+}
 ```
 
 Conversely, the `spawn` implementation needs to write a value to the `INSTANTS`
@@ -333,7 +333,7 @@ mod foo {
     }
 }
 
-const APP: () = {
+mod app {
     impl<'a> foo::Spawn<'a> {
         /// Spawns the `baz` task
         pub fn baz(&self, message: u64) -> Result<(), u64> {
@@ -364,5 +364,5 @@ const APP: () = {
             }
         }
     }
-};
+}
 ```
diff --git a/book/en/src/migration.md b/book/en/src/migration.md
index 6cca64d..ab45c29 100644
--- a/book/en/src/migration.md
+++ b/book/en/src/migration.md
@@ -1,14 +1,81 @@
-# Migrating from v0.4.x to v0.5.0
+# Migration of RTIC
+
+## Migrating from v0.5.x to v0.6.0
+
+This section describes how to upgrade from v0.5.x to v0.6.0 of the RTIC framework.
+
+### `Cargo.toml` - version bump
+
+Change the version of `cortex-m-rtic` to `"0.6.0"`.
+
+### Module instead of Const
+
+With the support of attributes on modules the `const APP` workaround is not needed.
+
+Change
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+  [code here]
+};
+```
+
+into
+
+``` rust
+#[rtic::app(/* .. */)]
+mod app {
+  [code here]
+}
+```
+
+Now that a regular Rust module is used it means it is possible to have custom
+user code within that module.
+Additionally, it means that `use`-statements for resources etc may be required.
+
+### Init always returns late resources
+
+In order to make the API more symmetric the #[init]-task always returns a late resource.
+
+From this:
+
+``` rust
+#[rtic::app(device = lm3s6965)]
+mod app {
+    #[init]
+    fn init(_: init::Context) {
+        rtic::pend(Interrupt::UART0);
+    }
+    [more code]
+}
+```
+
+to this:
+
+``` rust
+#[rtic::app(device = lm3s6965)]
+mod app {
+    #[init]
+    fn init(_: init::Context) -> init::LateResources {
+        rtic::pend(Interrupt::UART0);
+
+        init::LateResources {}
+    }
+    [more code]
+}
+```
+
+## Migrating from v0.4.x to v0.5.0
 
 This section covers how to upgrade an application written against RTIC v0.4.x to
 the version v0.5.0 of the framework.
 
-## `Cargo.toml`
+### `Cargo.toml`
 
 First, the version of the `cortex-m-rtic` dependency needs to be updated to
 `"0.5.0"`. The `timer-queue` feature needs to be removed.
 
-
 ``` toml
 [dependencies.cortex-m-rtic]
 # change this
@@ -22,7 +89,7 @@ features = ["timer-queue"]
 #           ^^^^^^^^^^^^^
 ```
 
-## `Context` argument
+### `Context` argument
 
 All functions inside the `#[rtic::app]` item need to take as first argument a
 `Context` structure. This `Context` type will contain the variables that were
@@ -74,7 +141,7 @@ const APP: () = {
 };
 ```
 
-## Resources
+### Resources
 
 The syntax used to declare resources has been changed from `static mut`
 variables to a `struct Resources`.
@@ -98,7 +165,7 @@ const APP: () = {
 };
 ```
 
-## Device peripherals
+### Device peripherals
 
 If your application was accessing the device peripherals in `#[init]` through
 the `device` variable then you'll need to add `peripherals = true` to the
@@ -136,7 +203,7 @@ const APP: () = {
 };
 ```
 
-## `#[interrupt]` and `#[exception]`
+### `#[interrupt]` and `#[exception]`
 
 The `#[interrupt]` and `#[exception]` attributes have been removed. To declare
 hardware tasks in v0.5.x use the `#[task]` attribute with the `binds` argument.
@@ -182,7 +249,7 @@ const APP: () = {
 };
 ```
 
-## `schedule`
+### `schedule`
 
 The `timer-queue` feature has been removed. To use the `schedule` API one must
 first define the monotonic timer the runtime will use using the `monotonic`
@@ -194,7 +261,7 @@ Also, the `Duration` and `Instant` types and the `U32Ext` trait have been moved
 into the `rtic::cyccnt` module. This module is only available on ARMv7-M+
 devices. The removal of the `timer-queue` also brings back the `DWT` peripheral
 inside the core peripherals struct, this will need to be enabled by the application
-inside `init`. 
+inside `init`.
 
 Change this:
 
-- 
cgit v1.2.3


From e6bc673621093c72f932cc38043c9fa951745450 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
Date: Fri, 2 Oct 2020 09:42:50 +0000
Subject: Clarify the need for resources-attribute

---
 book/en/src/by-example/resources.md | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'book/en/src')

diff --git a/book/en/src/by-example/resources.md b/book/en/src/by-example/resources.md
index d63d135..62efdc6 100644
--- a/book/en/src/by-example/resources.md
+++ b/book/en/src/by-example/resources.md
@@ -9,6 +9,8 @@ can access which resource.
 
 All resources are declared as a single `struct` within the `#[app]`
 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
-- 
cgit v1.2.3


From 1482a251867bfb31708e8c7273db4bee1e67df36 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
Date: Fri, 2 Oct 2020 09:55:25 +0000
Subject: Describe the resource struct attribute migration steps

---
 book/en/src/migration.md | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

(limited to 'book/en/src')

diff --git a/book/en/src/migration.md b/book/en/src/migration.md
index ab45c29..7be3094 100644
--- a/book/en/src/migration.md
+++ b/book/en/src/migration.md
@@ -66,6 +66,37 @@ mod app {
 }
 ```
 
+### Resources struct - #[resources]
+
+Previously the RTIC resources had to be in in a struct named exactly "Resources":
+
+``` rust
+struct Resources {
+    // Resources defined in here
+}
+```
+
+With RTIC v0.6.0 the resources struct is annotated similarly like
+`#[task]`, `#[init]`, `#[idle]`: with an attribute `#[resources]`
+
+``` rust
+#[resources]
+struct Resources {
+    // Resources defined in here
+}
+```
+
+In fact, the name of the struct is now up to the developer:
+
+``` rust
+#[resources]
+struct whateveryouwant {
+    // Resources defined in here
+}
+```
+
+would work equally well.
+
 ## Migrating from v0.4.x to v0.5.0
 
 This section covers how to upgrade an application written against RTIC v0.4.x to
-- 
cgit v1.2.3


From 40c7119d7a3bf4dc7cd67be629cfe874d1c04851 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Henrik=20Tj=C3=A4der?= <henrik@tjaders.com>
Date: Fri, 2 Oct 2020 12:36:34 +0000
Subject: Prepare the book for v0.6

---
 book/en/src/preface.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

(limited to 'book/en/src')

diff --git a/book/en/src/preface.md b/book/en/src/preface.md
index 419f067..041b3bd 100644
--- a/book/en/src/preface.md
+++ b/book/en/src/preface.md
@@ -13,8 +13,10 @@ There is a translation of this book in [Russian].
 
 [Russian]: ../ru/index.html
 
-This is the documentation of v0.5.x of RTIC; for the documentation of version
-v0.4.x go [here](/0.4).
+This is the documentation of v0.6.x of RTIC; for the documentation of version
+
+* v0.5.x go [here](/0.5).
+* v0.4.x go [here](/0.4).
 
 {{#include ../../../README.md:7:46}}
 
-- 
cgit v1.2.3


From f0f982facadab2da5d8cdaf214829a9e19f4249e Mon Sep 17 00:00:00 2001
From: Emil Fresk <emil.fresk@gmail.com>
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')

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


From 71a279f6d0a2fa4f0e51d09eda47bd422a1b0240 Mon Sep 17 00:00:00 2001
From: Emil Fresk <emil.fresk@gmail.com>
Date: Mon, 5 Oct 2020 20:38:52 +0200
Subject: Split up migration guides into its own sections

---
 book/en/src/SUMMARY.md                  |   6 +-
 book/en/src/migration.md                | 333 +-------------------------------
 book/en/src/migration/migration_rtic.md |  54 ++++++
 book/en/src/migration/migration_v4.md   | 232 ++++++++++++++++++++++
 book/en/src/migration/migration_v5.md   |  96 +++++++++
 book/en/src/migration_rtic.md           |  54 ------
 6 files changed, 389 insertions(+), 386 deletions(-)
 create mode 100644 book/en/src/migration/migration_rtic.md
 create mode 100644 book/en/src/migration/migration_v4.md
 create mode 100644 book/en/src/migration/migration_v5.md
 delete mode 100644 book/en/src/migration_rtic.md

(limited to 'book/en/src')

diff --git a/book/en/src/SUMMARY.md b/book/en/src/SUMMARY.md
index a573cbb..e1a4a33 100644
--- a/book/en/src/SUMMARY.md
+++ b/book/en/src/SUMMARY.md
@@ -10,8 +10,10 @@
   - [Types, Send and Sync](./by-example/types-send-sync.md)
   - [Starting a new project](./by-example/new.md)
   - [Tips & tricks](./by-example/tips.md)
-- [Migrating from v0.4.x to v0.5.0](./migration.md)
-- [Migrating from RTFM to RTIC](./migration_rtic.md)
+- [Migration Guides](./migration.md)
+  - [v0.5.x to v0.6.x](./migration/migration_v5.md)
+  - [v0.4.x to v0.5.x](./migration/migration_v4.md)
+  - [RTFM to RTIC](./migration/migration_rtic.md)
 - [Under the hood](./internals.md)
   - [Interrupt configuration](./internals/interrupt-configuration.md)
   - [Non-reentrancy](./internals/non-reentrancy.md)
diff --git a/book/en/src/migration.md b/book/en/src/migration.md
index 7be3094..08feb81 100644
--- a/book/en/src/migration.md
+++ b/book/en/src/migration.md
@@ -1,331 +1,4 @@
-# Migration of RTIC
+# Migration Guides
 
-## Migrating from v0.5.x to v0.6.0
-
-This section describes how to upgrade from v0.5.x to v0.6.0 of the RTIC framework.
-
-### `Cargo.toml` - version bump
-
-Change the version of `cortex-m-rtic` to `"0.6.0"`.
-
-### Module instead of Const
-
-With the support of attributes on modules the `const APP` workaround is not needed.
-
-Change
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-  [code here]
-};
-```
-
-into
-
-``` rust
-#[rtic::app(/* .. */)]
-mod app {
-  [code here]
-}
-```
-
-Now that a regular Rust module is used it means it is possible to have custom
-user code within that module.
-Additionally, it means that `use`-statements for resources etc may be required.
-
-### Init always returns late resources
-
-In order to make the API more symmetric the #[init]-task always returns a late resource.
-
-From this:
-
-``` rust
-#[rtic::app(device = lm3s6965)]
-mod app {
-    #[init]
-    fn init(_: init::Context) {
-        rtic::pend(Interrupt::UART0);
-    }
-    [more code]
-}
-```
-
-to this:
-
-``` rust
-#[rtic::app(device = lm3s6965)]
-mod app {
-    #[init]
-    fn init(_: init::Context) -> init::LateResources {
-        rtic::pend(Interrupt::UART0);
-
-        init::LateResources {}
-    }
-    [more code]
-}
-```
-
-### Resources struct - #[resources]
-
-Previously the RTIC resources had to be in in a struct named exactly "Resources":
-
-``` rust
-struct Resources {
-    // Resources defined in here
-}
-```
-
-With RTIC v0.6.0 the resources struct is annotated similarly like
-`#[task]`, `#[init]`, `#[idle]`: with an attribute `#[resources]`
-
-``` rust
-#[resources]
-struct Resources {
-    // Resources defined in here
-}
-```
-
-In fact, the name of the struct is now up to the developer:
-
-``` rust
-#[resources]
-struct whateveryouwant {
-    // Resources defined in here
-}
-```
-
-would work equally well.
-
-## Migrating from v0.4.x to v0.5.0
-
-This section covers how to upgrade an application written against RTIC v0.4.x to
-the version v0.5.0 of the framework.
-
-### `Cargo.toml`
-
-First, the version of the `cortex-m-rtic` dependency needs to be updated to
-`"0.5.0"`. The `timer-queue` feature needs to be removed.
-
-``` toml
-[dependencies.cortex-m-rtic]
-# change this
-version = "0.4.3"
-
-# into this
-version = "0.5.0"
-
-# and remove this Cargo feature
-features = ["timer-queue"]
-#           ^^^^^^^^^^^^^
-```
-
-### `Context` argument
-
-All functions inside the `#[rtic::app]` item need to take as first argument a
-`Context` structure. This `Context` type will contain the variables that were
-magically injected into the scope of the function by version v0.4.x of the
-framework: `resources`, `spawn`, `schedule` -- these variables will become
-fields of the `Context` structure. Each function within the `#[rtic::app]` item
-gets a different `Context` type.
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-    // change this
-    #[task(resources = [x], spawn = [a], schedule = [b])]
-    fn foo() {
-        resources.x.lock(|x| /* .. */);
-        spawn.a(message);
-        schedule.b(baseline);
-    }
-
-    // into this
-    #[task(resources = [x], spawn = [a], schedule = [b])]
-    fn foo(mut cx: foo::Context) {
-        // ^^^^^^^^^^^^^^^^^^^^
-
-        cx.resources.x.lock(|x| /* .. */);
-    //  ^^^
-
-        cx.spawn.a(message);
-    //  ^^^
-
-        cx.schedule.b(message, baseline);
-    //  ^^^
-    }
-
-    // change this
-    #[init]
-    fn init() {
-        // ..
-    }
-
-    // into this
-    #[init]
-    fn init(cx: init::Context) {
-        //  ^^^^^^^^^^^^^^^^^
-        // ..
-    }
-
-    // ..
-};
-```
-
-### Resources
-
-The syntax used to declare resources has been changed from `static mut`
-variables to a `struct Resources`.
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-    // change this
-    static mut X: u32 = 0;
-    static mut Y: u32 = (); // late resource
-
-    // into this
-    struct Resources {
-        #[init(0)] // <- initial value
-        X: u32, // NOTE: we suggest changing the naming style to `snake_case`
-
-        Y: u32, // late resource
-    }
-
-    // ..
-};
-```
-
-### Device peripherals
-
-If your application was accessing the device peripherals in `#[init]` through
-the `device` variable then you'll need to add `peripherals = true` to the
-`#[rtic::app]` attribute to continue to access the device peripherals through
-the `device` field of the `init::Context` structure.
-
-Change this:
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-    #[init]
-    fn init() {
-        device.SOME_PERIPHERAL.write(something);
-    }
-
-    // ..
-};
-```
-
-Into this:
-
-``` rust
-#[rtic::app(/* .. */, peripherals = true)]
-//                    ^^^^^^^^^^^^^^^^^^
-const APP: () = {
-    #[init]
-    fn init(cx: init::Context) {
-        //  ^^^^^^^^^^^^^^^^^
-        cx.device.SOME_PERIPHERAL.write(something);
-    //  ^^^
-    }
-
-    // ..
-};
-```
-
-### `#[interrupt]` and `#[exception]`
-
-The `#[interrupt]` and `#[exception]` attributes have been removed. To declare
-hardware tasks in v0.5.x use the `#[task]` attribute with the `binds` argument.
-
-Change this:
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-    // hardware tasks
-    #[exception]
-    fn SVCall() { /* .. */ }
-
-    #[interrupt]
-    fn UART0() { /* .. */ }
-
-    // software task
-    #[task]
-    fn foo() { /* .. */ }
-
-    // ..
-};
-```
-
-Into this:
-
-``` rust
-#[rtic::app(/* .. */)]
-const APP: () = {
-    #[task(binds = SVCall)]
-    //     ^^^^^^^^^^^^^^
-    fn svcall(cx: svcall::Context) { /* .. */ }
-    // ^^^^^^ we suggest you use a `snake_case` name here
-
-    #[task(binds = UART0)]
-    //     ^^^^^^^^^^^^^
-    fn uart0(cx: uart0::Context) { /* .. */ }
-
-    #[task]
-    fn foo(cx: foo::Context) { /* .. */ }
-
-    // ..
-};
-```
-
-### `schedule`
-
-The `timer-queue` feature has been removed. To use the `schedule` API one must
-first define the monotonic timer the runtime will use using the `monotonic`
-argument of the `#[rtic::app]` attribute. To continue using the cycle counter
-(CYCCNT) as the monotonic timer, and match the behavior of version v0.4.x, add
-the `monotonic = rtic::cyccnt::CYCCNT` argument to the `#[rtic::app]` attribute.
-
-Also, the `Duration` and `Instant` types and the `U32Ext` trait have been moved
-into the `rtic::cyccnt` module. This module is only available on ARMv7-M+
-devices. The removal of the `timer-queue` also brings back the `DWT` peripheral
-inside the core peripherals struct, this will need to be enabled by the application
-inside `init`.
-
-Change this:
-
-``` rust
-use rtic::{Duration, Instant, U32Ext};
-
-#[rtic::app(/* .. */)]
-const APP: () = {
-    #[task(schedule = [b])]
-    fn a() {
-        // ..
-    }
-};
-```
-
-Into this:
-
-``` rust
-use rtic::cyccnt::{Duration, Instant, U32Ext};
-//        ^^^^^^^^
-
-#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]
-//                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-const APP: () = {
-    #[init]
-    fn init(cx: init::Context) {
-        cx.core.DWT.enable_cycle_counter();
-        // optional, configure the DWT run without a debugger connected
-        cx.core.DCB.enable_trace();
-    }
-    #[task(schedule = [b])]
-    fn a(cx: a::Context) {
-        // ..
-    }
-};
-```
+This section describes how to migrate between different version of RTIC.
+It also acts as a comparing reference between versions.
diff --git a/book/en/src/migration/migration_rtic.md b/book/en/src/migration/migration_rtic.md
new file mode 100644
index 0000000..555f1bb
--- /dev/null
+++ b/book/en/src/migration/migration_rtic.md
@@ -0,0 +1,54 @@
+# Migrating from RTFM to RTIC
+
+This section covers how to upgrade an application written against RTFM v0.5.x to
+the same version of RTIC. This applies since the renaming of the framework as per [RFC #33].
+
+**Note:** There are no code differences between RTFM v0.5.3 and RTIC v0.5.3, it is purely a name
+change.
+
+[RFC #33]: https://github.com/rtic-rs/rfcs/pull/33
+
+
+
+## `Cargo.toml`
+
+First, the `cortex-m-rtfm` dependency needs to be updated to
+`cortex-m-rtic`.
+
+
+``` toml
+[dependencies]
+# change this
+cortex-m-rtfm = "0.5.3"
+
+# into this
+cortex-m-rtic = "0.5.3"
+```
+
+## Code changes
+
+The only code change that needs to be made is that any reference to `rtfm` before now need to point
+to `rtic` as follows:
+
+``` rust
+//
+// Change this
+//
+
+#[rtfm::app(/* .. */, monotonic = rtfm::cyccnt::CYCCNT)]
+const APP: () = {
+    // ...
+
+};
+
+//
+// Into this
+//
+
+#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]
+const APP: () = {
+    // ...
+
+};
+```
+
diff --git a/book/en/src/migration/migration_v4.md b/book/en/src/migration/migration_v4.md
new file mode 100644
index 0000000..2c4e3ad
--- /dev/null
+++ b/book/en/src/migration/migration_v4.md
@@ -0,0 +1,232 @@
+# Migrating from v0.4.x to v0.5.0
+
+This section covers how to upgrade an application written against RTIC v0.4.x to
+the version v0.5.0 of the framework.
+
+### `Cargo.toml`
+
+First, the version of the `cortex-m-rtic` dependency needs to be updated to
+`"0.5.0"`. The `timer-queue` feature needs to be removed.
+
+``` toml
+[dependencies.cortex-m-rtic]
+# change this
+version = "0.4.3"
+
+# into this
+version = "0.5.0"
+
+# and remove this Cargo feature
+features = ["timer-queue"]
+#           ^^^^^^^^^^^^^
+```
+
+### `Context` argument
+
+All functions inside the `#[rtic::app]` item need to take as first argument a
+`Context` structure. This `Context` type will contain the variables that were
+magically injected into the scope of the function by version v0.4.x of the
+framework: `resources`, `spawn`, `schedule` -- these variables will become
+fields of the `Context` structure. Each function within the `#[rtic::app]` item
+gets a different `Context` type.
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+    // change this
+    #[task(resources = [x], spawn = [a], schedule = [b])]
+    fn foo() {
+        resources.x.lock(|x| /* .. */);
+        spawn.a(message);
+        schedule.b(baseline);
+    }
+
+    // into this
+    #[task(resources = [x], spawn = [a], schedule = [b])]
+    fn foo(mut cx: foo::Context) {
+        // ^^^^^^^^^^^^^^^^^^^^
+
+        cx.resources.x.lock(|x| /* .. */);
+    //  ^^^
+
+        cx.spawn.a(message);
+    //  ^^^
+
+        cx.schedule.b(message, baseline);
+    //  ^^^
+    }
+
+    // change this
+    #[init]
+    fn init() {
+        // ..
+    }
+
+    // into this
+    #[init]
+    fn init(cx: init::Context) {
+        //  ^^^^^^^^^^^^^^^^^
+        // ..
+    }
+
+    // ..
+};
+```
+
+### Resources
+
+The syntax used to declare resources has been changed from `static mut`
+variables to a `struct Resources`.
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+    // change this
+    static mut X: u32 = 0;
+    static mut Y: u32 = (); // late resource
+
+    // into this
+    struct Resources {
+        #[init(0)] // <- initial value
+        X: u32, // NOTE: we suggest changing the naming style to `snake_case`
+
+        Y: u32, // late resource
+    }
+
+    // ..
+};
+```
+
+### Device peripherals
+
+If your application was accessing the device peripherals in `#[init]` through
+the `device` variable then you'll need to add `peripherals = true` to the
+`#[rtic::app]` attribute to continue to access the device peripherals through
+the `device` field of the `init::Context` structure.
+
+Change this:
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+    #[init]
+    fn init() {
+        device.SOME_PERIPHERAL.write(something);
+    }
+
+    // ..
+};
+```
+
+Into this:
+
+``` rust
+#[rtic::app(/* .. */, peripherals = true)]
+//                    ^^^^^^^^^^^^^^^^^^
+const APP: () = {
+    #[init]
+    fn init(cx: init::Context) {
+        //  ^^^^^^^^^^^^^^^^^
+        cx.device.SOME_PERIPHERAL.write(something);
+    //  ^^^
+    }
+
+    // ..
+};
+```
+
+### `#[interrupt]` and `#[exception]`
+
+The `#[interrupt]` and `#[exception]` attributes have been removed. To declare
+hardware tasks in v0.5.x use the `#[task]` attribute with the `binds` argument.
+
+Change this:
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+    // hardware tasks
+    #[exception]
+    fn SVCall() { /* .. */ }
+
+    #[interrupt]
+    fn UART0() { /* .. */ }
+
+    // software task
+    #[task]
+    fn foo() { /* .. */ }
+
+    // ..
+};
+```
+
+Into this:
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+    #[task(binds = SVCall)]
+    //     ^^^^^^^^^^^^^^
+    fn svcall(cx: svcall::Context) { /* .. */ }
+    // ^^^^^^ we suggest you use a `snake_case` name here
+
+    #[task(binds = UART0)]
+    //     ^^^^^^^^^^^^^
+    fn uart0(cx: uart0::Context) { /* .. */ }
+
+    #[task]
+    fn foo(cx: foo::Context) { /* .. */ }
+
+    // ..
+};
+```
+
+### `schedule`
+
+The `timer-queue` feature has been removed. To use the `schedule` API one must
+first define the monotonic timer the runtime will use using the `monotonic`
+argument of the `#[rtic::app]` attribute. To continue using the cycle counter
+(CYCCNT) as the monotonic timer, and match the behavior of version v0.4.x, add
+the `monotonic = rtic::cyccnt::CYCCNT` argument to the `#[rtic::app]` attribute.
+
+Also, the `Duration` and `Instant` types and the `U32Ext` trait have been moved
+into the `rtic::cyccnt` module. This module is only available on ARMv7-M+
+devices. The removal of the `timer-queue` also brings back the `DWT` peripheral
+inside the core peripherals struct, this will need to be enabled by the application
+inside `init`.
+
+Change this:
+
+``` rust
+use rtic::{Duration, Instant, U32Ext};
+
+#[rtic::app(/* .. */)]
+const APP: () = {
+    #[task(schedule = [b])]
+    fn a() {
+        // ..
+    }
+};
+```
+
+Into this:
+
+``` rust
+use rtic::cyccnt::{Duration, Instant, U32Ext};
+//        ^^^^^^^^
+
+#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]
+//                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+const APP: () = {
+    #[init]
+    fn init(cx: init::Context) {
+        cx.core.DWT.enable_cycle_counter();
+        // optional, configure the DWT run without a debugger connected
+        cx.core.DCB.enable_trace();
+    }
+    #[task(schedule = [b])]
+    fn a(cx: a::Context) {
+        // ..
+    }
+};
+```
diff --git a/book/en/src/migration/migration_v5.md b/book/en/src/migration/migration_v5.md
new file mode 100644
index 0000000..749ddec
--- /dev/null
+++ b/book/en/src/migration/migration_v5.md
@@ -0,0 +1,96 @@
+# Migrating from v0.5.x to v0.6.0
+
+This section describes how to upgrade from v0.5.x to v0.6.0 of the RTIC framework.
+
+### `Cargo.toml` - version bump
+
+Change the version of `cortex-m-rtic` to `"0.6.0"`.
+
+### Module instead of Const
+
+With the support of attributes on modules the `const APP` workaround is not needed.
+
+Change
+
+``` rust
+#[rtic::app(/* .. */)]
+const APP: () = {
+  [code here]
+};
+```
+
+into
+
+``` rust
+#[rtic::app(/* .. */)]
+mod app {
+  [code here]
+}
+```
+
+Now that a regular Rust module is used it means it is possible to have custom
+user code within that module.
+Additionally, it means that `use`-statements for resources etc may be required.
+
+### Init always returns late resources
+
+In order to make the API more symmetric the #[init]-task always returns a late resource.
+
+From this:
+
+``` rust
+#[rtic::app(device = lm3s6965)]
+mod app {
+    #[init]
+    fn init(_: init::Context) {
+        rtic::pend(Interrupt::UART0);
+    }
+    [more code]
+}
+```
+
+to this:
+
+``` rust
+#[rtic::app(device = lm3s6965)]
+mod app {
+    #[init]
+    fn init(_: init::Context) -> init::LateResources {
+        rtic::pend(Interrupt::UART0);
+
+        init::LateResources {}
+    }
+    [more code]
+}
+```
+
+### Resources struct - #[resources]
+
+Previously the RTIC resources had to be in in a struct named exactly "Resources":
+
+``` rust
+struct Resources {
+    // Resources defined in here
+}
+```
+
+With RTIC v0.6.0 the resources struct is annotated similarly like
+`#[task]`, `#[init]`, `#[idle]`: with an attribute `#[resources]`
+
+``` rust
+#[resources]
+struct Resources {
+    // Resources defined in here
+}
+```
+
+In fact, the name of the struct is now up to the developer:
+
+``` rust
+#[resources]
+struct whateveryouwant {
+    // Resources defined in here
+}
+```
+
+would work equally well.
diff --git a/book/en/src/migration_rtic.md b/book/en/src/migration_rtic.md
deleted file mode 100644
index 555f1bb..0000000
--- a/book/en/src/migration_rtic.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Migrating from RTFM to RTIC
-
-This section covers how to upgrade an application written against RTFM v0.5.x to
-the same version of RTIC. This applies since the renaming of the framework as per [RFC #33].
-
-**Note:** There are no code differences between RTFM v0.5.3 and RTIC v0.5.3, it is purely a name
-change.
-
-[RFC #33]: https://github.com/rtic-rs/rfcs/pull/33
-
-
-
-## `Cargo.toml`
-
-First, the `cortex-m-rtfm` dependency needs to be updated to
-`cortex-m-rtic`.
-
-
-``` toml
-[dependencies]
-# change this
-cortex-m-rtfm = "0.5.3"
-
-# into this
-cortex-m-rtic = "0.5.3"
-```
-
-## Code changes
-
-The only code change that needs to be made is that any reference to `rtfm` before now need to point
-to `rtic` as follows:
-
-``` rust
-//
-// Change this
-//
-
-#[rtfm::app(/* .. */, monotonic = rtfm::cyccnt::CYCCNT)]
-const APP: () = {
-    // ...
-
-};
-
-//
-// Into this
-//
-
-#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]
-const APP: () = {
-    // ...
-
-};
-```
-
-- 
cgit v1.2.3