16 files changed, 39 insertions, 39 deletions

diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md
index 0d977a1..8450bb9 100644
--- a/book/en/src/by-example/app.md
+++ b/book/en/src/by-example/app.md
@@ -27,6 +27,6 @@ Overall, the generated code infers no additional overhead in comparison to a han
 To give a flavour of RTIC, the following example contains commonly used features.
 In the following sections we will go through each feature in detail.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/common.rs}}
 ```
diff --git a/book/en/src/by-example/app_idle.md b/book/en/src/by-example/app_idle.md
index cbfd7ba..c0b4139 100644
--- a/book/en/src/by-example/app_idle.md
+++ b/book/en/src/by-example/app_idle.md
@@ -11,7 +11,7 @@ Like in `init`, locally declared resources will have `'static` lifetimes that ar
 
 The example below shows that `idle` runs after `init`.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/idle.rs}}
 ```
 
@@ -38,7 +38,7 @@ The following example shows how to enable sleep by setting the
 [WFI]: https://developer.arm.com/documentation/dui0662/b/The-Cortex-M0--Instruction-Set/Miscellaneous-instructions/WFI
 [NOP]: https://developer.arm.com/documentation/dui0662/b/The-Cortex-M0--Instruction-Set/Miscellaneous-instructions/NOP
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/idle-wfi.rs}}
 ```
 
diff --git a/book/en/src/by-example/app_init.md b/book/en/src/by-example/app_init.md
index fb37387..e581ef5 100644
--- a/book/en/src/by-example/app_init.md
+++ b/book/en/src/by-example/app_init.md
@@ -16,7 +16,7 @@ The example below shows the types of the `core`, `device` and `cs` fields, and s
 The `device` field is only available when the `peripherals` argument is set to the default value `true`.
 In the rare case you want to implement an ultra-slim application you can explicitly set `peripherals` to `false`.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/init.rs}}
 ```
 
diff --git a/book/en/src/by-example/app_minimal.md b/book/en/src/by-example/app_minimal.md
index 714f543..2c6f218 100644
--- a/book/en/src/by-example/app_minimal.md
+++ b/book/en/src/by-example/app_minimal.md
@@ -2,7 +2,7 @@
 
 This is the smallest possible RTIC application:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/smallest.rs}}
 ```
 
diff --git a/book/en/src/by-example/app_priorities.md b/book/en/src/by-example/app_priorities.md
index 9d27658..86ff985 100644
--- a/book/en/src/by-example/app_priorities.md
+++ b/book/en/src/by-example/app_priorities.md
@@ -33,7 +33,7 @@ Task Priority
 
 The following example showcases the priority based scheduling of tasks:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/preempt.rs}}
 ```
 
diff --git a/book/en/src/by-example/channel.md b/book/en/src/by-example/channel.md
index 50c3278..75ecbfd 100644
--- a/book/en/src/by-example/channel.md
+++ b/book/en/src/by-example/channel.md
@@ -2,7 +2,7 @@
 
 Channels can be used to communicate data between running tasks. The channel is essentially a wait queue, allowing tasks with multiple producers and a single receiver. A channel is constructed in the `init` task and backed by statically allocated memory. Send and receive endpoints are distributed to *software* tasks:
 
-``` rust
+``` rust,noplayground
 ...
 const CAPACITY: usize = 5;
 #[init]
@@ -22,7 +22,7 @@ Channels can also be used from *hardware* tasks, but only in a non-`async` manne
 
 The `send` method post a message on the channel as shown below:
 
-``` rust
+``` rust,noplayground
 #[task]
 async fn sender1(_c: sender1::Context, mut sender: Sender<'static, u32, CAPACITY>) {
     hprintln!("Sender 1 sending: 1");
@@ -34,7 +34,7 @@ async fn sender1(_c: sender1::Context, mut sender: Sender<'static, u32, CAPACITY
 
 The receiver can `await` incoming messages:
 
-``` rust
+``` rust,noplayground
 #[task]
 async fn receiver(_c: receiver::Context, mut receiver: Receiver<'static, u32, CAPACITY>) {
     while let Ok(val) = receiver.recv().await {
@@ -48,7 +48,7 @@ Channels are implemented using a small (global) *Critical Section* (CS) for prot
 
 For a complete example:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-channel.rs}}
 ```
 
@@ -64,7 +64,7 @@ Also sender endpoint can be awaited. In case the channel capacity has not yet be
 
 In the following example the `CAPACITY` has been reduced to 1, forcing sender tasks to wait until the data in the channel has been received.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-channel-done.rs}}
 ```
 
@@ -81,7 +81,7 @@ $ cargo run --target thumbv7m-none-eabi --example async-channel-done --features
 
 In case all senders have been dropped `await`-ing on an empty receiver channel results in an error. This allows to gracefully implement different types of shutdown operations.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-channel-no-sender.rs}}
 ```
 
@@ -97,7 +97,7 @@ Similarly, `await`-ing on a send channel results in an error in case the receive
 
 The resulting error returns the data back to the sender, allowing the sender to take appropriate action (e.g., storing the data to later retry sending it).
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-channel-no-receiver.rs}}
 ```
 
@@ -115,7 +115,7 @@ Using the Try API, you can send or receive data from or to a channel without req
 
 This API is exposed through `Receiver::try_recv` and `Sender::try_send`.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-channel-try.rs}}
 ```
 
diff --git a/book/en/src/by-example/delay.md b/book/en/src/by-example/delay.md
index 479fd42..a6ad0e0 100644
--- a/book/en/src/by-example/delay.md
+++ b/book/en/src/by-example/delay.md
@@ -7,7 +7,7 @@ This can be achieved by instantiating a monotonic timer (for implementations, se
 [`rtic-monotonics`]: https://github.com/rtic-rs/rtic/tree/master/rtic-monotonics
 [`rtic-time`]: https://github.com/rtic-rs/rtic/tree/master/rtic-time
 
-``` rust
+``` rust,noplayground
 ...
 {{#include ../../../../rtic/examples/async-timeout.rs:init}}
         ...
@@ -15,7 +15,7 @@ This can be achieved by instantiating a monotonic timer (for implementations, se
 
 A *software* task can `await` the delay to expire:
 
-``` rust
+``` rust,noplayground
 #[task]
 async fn foo(_cx: foo::Context) {
     ...
@@ -34,7 +34,7 @@ Similarly the channels implementation, the timer-queue implementation relies on
 <details>
 <summary>A complete example</summary>
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-delay.rs}}
 ```
 
@@ -58,7 +58,7 @@ A common use case is transactions with an associated timeout. In the examples sh
 
 Using the `select_biased` macro from the `futures` crate it may look like this:
 
-``` rust,noplayground
+``` rust,noplayground,noplayground
 {{#include ../../../../rtic/examples/async-timeout.rs:select_biased}}
 ```
 
@@ -70,7 +70,7 @@ Using `select_biased` any number of futures can be combined, so its very powerfu
 
 Rewriting the second example from above using `timeout_after` gives:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-timeout.rs:timeout_at_basic}}
 ```
 
@@ -78,7 +78,7 @@ In cases where you want exact control over time without drift we can use exact p
 
 [fugit]: https://crates.io/crates/fugit
 
-``` rust
+``` rust,noplayground
 
 {{#include ../../../../rtic/examples/async-timeout.rs:timeout_at}}
 
@@ -99,7 +99,7 @@ For the third iteration, with `n == 2`, `hal_get` will take 550ms to finish, in
 <details>
 <summary>A complete example</summary>
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/async-timeout.rs}}
 ```
 
diff --git a/book/en/src/by-example/hardware_tasks.md b/book/en/src/by-example/hardware_tasks.md
index 75dd1a4..bf00dc4 100644
--- a/book/en/src/by-example/hardware_tasks.md
+++ b/book/en/src/by-example/hardware_tasks.md
@@ -19,7 +19,7 @@ Beware of using interrupt vectors that are used internally by hardware features;
 
 The example below demonstrates the use of the `#[task(binds = InterruptName)]` attribute to declare a hardware task bound to an interrupt handler.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/hardware.rs}}
 ```
 
diff --git a/book/en/src/by-example/message_passing.md b/book/en/src/by-example/message_passing.md
index 5665c36..02fd298 100644
--- a/book/en/src/by-example/message_passing.md
+++ b/book/en/src/by-example/message_passing.md
@@ -10,7 +10,7 @@ pending spawns of `foo`. Exceeding this capacity is an `Error`.
 
 The number of arguments to a task is not limited:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../examples/message_passing.rs}}
 ```
 
diff --git a/book/en/src/by-example/resources.md b/book/en/src/by-example/resources.md
index 0bf5d11..c2472bc 100644
--- a/book/en/src/by-example/resources.md
+++ b/book/en/src/by-example/resources.md
@@ -25,7 +25,7 @@ Types of `#[local]` resources must implement a [`Send`] trait as they are being
 
 The example application shown below contains three tasks `foo`, `bar` and `idle`, each having access to its own `#[local]` resource.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/locals.rs}}
 ```
 
@@ -51,7 +51,7 @@ Types of `#[task(local = [..])]` resources have to be neither [`Send`] nor [`Syn
 
 In the example below the different uses and lifetimes are shown:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/declared_locals.rs}}
 ```
 
@@ -76,7 +76,7 @@ The critical section created by the `lock` API is based on dynamic priorities: i
 
 In the example below we have three interrupt handlers with priorities ranging from one to three. The two handlers with the lower priorities contend for a `shared` resource and need to succeed in locking the resource in order to access its data. The highest priority handler, which does not access the `shared` resource, is free to preempt a critical section created by the lowest priority handler.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/lock.rs}}
 ```
 
@@ -94,7 +94,7 @@ Types of `#[shared]` resources have to be [`Send`].
 
 As an extension to `lock`, and to reduce rightward drift, locks can be taken as tuples. The following examples show this in use:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/multilock.rs}}
 ```
 
@@ -116,7 +116,7 @@ Note that in this release of RTIC it is not possible to request both exclusive a
 
 In the example below a key (e.g. a cryptographic key) is loaded (or created) at runtime (returned by `init`) and then used from two tasks that run at different priorities without any kind of lock.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/only-shared-access.rs}}
 ```
 
@@ -142,7 +142,7 @@ To adhere to the Rust [aliasing] rule, a resource may be either accessed through
 
 Using `#[lock_free]` on resources shared by tasks running at different priorities will result in a *compile-time* error -- not using the `lock` API would violate the aforementioned alias rule. Similarly, for each priority there can be only a single *software* task accessing a shared resource (as an `async` task may yield execution to other *software* or *hardware* tasks running at the same priority). However, under this single-task restriction, we make the observation that the resource is in effect no longer `shared` but rather `local`. Thus, using a `#[lock_free]` shared resource will result in a *compile-time* error -- where applicable, use a `#[local]` resource instead.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/lock-free.rs}}
 ```
 
diff --git a/book/en/src/by-example/software_tasks.md b/book/en/src/by-example/software_tasks.md
index 0efc57b..ddf88fd 100644
--- a/book/en/src/by-example/software_tasks.md
+++ b/book/en/src/by-example/software_tasks.md
@@ -23,7 +23,7 @@ The framework will give a compilation error if there are not enough dispatchers
 
 See the following example:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/spawn.rs}}
 ```
 
@@ -40,7 +40,7 @@ In the below example, we `spawn` the *software* task `foo` from the `idle` task.
 
 Technically the async executor will `poll` the `foo` *future* which in this case leaves the *future* in a *completed* state. 
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/spawn_loop.rs}}
 ```
 
@@ -56,7 +56,7 @@ An attempt to `spawn` an already spawned task (running) task will result in an e
 
 Technically, a `spawn` to a *future* that is not in *completed* state is considered an error.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/spawn_err.rs}}
 ```
 
@@ -71,7 +71,7 @@ $ cargo run --target thumbv7m-none-eabi --example spawn_err
 ## Passing arguments
 You can also pass arguments at spawn as follows.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/spawn_arguments.rs}}
 ```
 
@@ -92,7 +92,7 @@ Conceptually, one can see such tasks as running in the `main` thread of the appl
 [Send]: https://doc.rust-lang.org/nomicon/send-and-sync.html
 
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../rtic/examples/zero-prio-task.rs}}
 ```
 
diff --git a/book/en/src/by-example/tips/destructureing.md b/book/en/src/by-example/tips/destructureing.md
index 6e1d796..752311d 100644
--- a/book/en/src/by-example/tips/destructureing.md
+++ b/book/en/src/by-example/tips/destructureing.md
@@ -3,7 +3,7 @@
 Destructuring task resources might help readability if a task takes multiple
 resources. Here are two examples on how to split up the resource struct:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../../rtic/examples/destructure.rs}}
 ```
 
diff --git a/book/en/src/by-example/tips/from_ram.md b/book/en/src/by-example/tips/from_ram.md
index 7306e12..a153139 100644
--- a/book/en/src/by-example/tips/from_ram.md
+++ b/book/en/src/by-example/tips/from_ram.md
@@ -11,7 +11,7 @@ improve performance in some cases.
 
 The example below shows how to place the higher priority task, `bar`, in RAM.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../../rtic/examples/ramfunc.rs}}
 ```
 
diff --git a/book/en/src/by-example/tips/indirection.md b/book/en/src/by-example/tips/indirection.md
index eef0d8e..58b3bde 100644
--- a/book/en/src/by-example/tips/indirection.md
+++ b/book/en/src/by-example/tips/indirection.md
@@ -13,7 +13,7 @@ As this example of approach goes completely outside of RTIC resource model with
 
 Here's an example where `heapless::Pool` is used to "box" buffers of 128 bytes.
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../../rtic/examples/pool.rs}}
 ```
 
diff --git a/book/en/src/by-example/tips/static_lifetimes.md b/book/en/src/by-example/tips/static_lifetimes.md
index b1fd606..f4e4829 100644
--- a/book/en/src/by-example/tips/static_lifetimes.md
+++ b/book/en/src/by-example/tips/static_lifetimes.md
@@ -8,7 +8,7 @@ In the following example two different tasks share a [`heapless::spsc::Queue`] f
 
 [`heapless::spsc::Queue`]: https://docs.rs/heapless/0.7.5/heapless/spsc/struct.Queue.html
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../../rtic/examples/static.rs}}
 ```
 
diff --git a/book/en/src/by-example/tips/view_code.md b/book/en/src/by-example/tips/view_code.md
index b4a9066..64af7ad 100644
--- a/book/en/src/by-example/tips/view_code.md
+++ b/book/en/src/by-example/tips/view_code.md
@@ -16,7 +16,7 @@ $ rustfmt target/rtic-expansion.rs
 $ tail target/rtic-expansion.rs
 ```
 
-``` rust
+``` rust,noplayground
 #[doc = r" Implementation details"]
 mod app {
     #[doc = r" Always include the device crate which contains the vector table"]