Disable the playground on all of these

Author: datdenkikniet

book/en/deprecated/by_example/monotonic.md

@@ -34,7 +34,7 @@ This activates the monotonics making it possible to use them.
 
 See the following example:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../examples/schedule.rs}}
 ```
 
@@ -54,7 +54,7 @@ which allows canceling or rescheduling of the task scheduled to run in the futur
 If `cancel` or `reschedule_at`/`reschedule_after` returns an `Err` it means that the operation was
 too late and that the task is already sent for execution. The following example shows this in action:
 
-``` rust
+``` rust,noplayground
 {{#include ../../../../examples/cancel-reschedule.rs}}
 ```
 

book/en/deprecated/migration/migration_rtic.md

@@ -27,7 +27,7 @@ cortex-m-rtic = "0.5.3"
 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
+``` rust,noplayground
 //
 // Change this
 //

book/en/deprecated/migration/migration_v4.md

@@ -42,7 +42,7 @@ framework: `resources`, `spawn`, `schedule` -- these variables will become
 fields of the `Context` structure. Each function within the `#[rtfm::app]` item
 gets a different `Context` type.
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */)]
 const APP: () = {
     // change this
@@ -90,7 +90,7 @@ const APP: () = {
 The syntax used to declare resources has changed from `static mut`
 variables to a `struct Resources`.
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */)]
 const APP: () = {
     // change this
@@ -118,7 +118,7 @@ the `device` field of the `init::Context` structure.
 
 Change this:
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */)]
 const APP: () = {
     #[init]
@@ -132,7 +132,7 @@ const APP: () = {
 
 Into this:
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */, peripherals = true)]
 //                    ^^^^^^^^^^^^^^^^^^
 const APP: () = {
@@ -155,7 +155,7 @@ attribute with the `binds` argument instead.
 
 Change this:
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */)]
 const APP: () = {
     // hardware tasks
@@ -175,7 +175,7 @@ const APP: () = {
 
 Into this:
 
-``` rust
+``` rust,noplayground
 #[rtfm::app(/* .. */)]
 const APP: () = {
     #[task(binds = SVCall)]
@@ -212,7 +212,7 @@ ensure it is enabled by the application inside `init`.
 
 Change this:
 
-``` rust
+``` rust,noplayground
 use rtfm::{Duration, Instant, U32Ext};
 
 #[rtfm::app(/* .. */)]
@@ -226,7 +226,7 @@ const APP: () = {
 
 Into this:
 
-``` rust
+``` rust,noplayground
 use rtfm::cyccnt::{Duration, Instant, U32Ext};
 //        ^^^^^^^^
 

book/en/deprecated/migration/migration_v5.md

@@ -12,7 +12,7 @@ With the support of attributes on modules the `const APP` workaround is not need
 
 Change
 
-``` rust
+``` rust,noplayground
 #[rtic::app(/* .. */)]
 const APP: () = {
   [code here]
@@ -21,7 +21,7 @@ const APP: () = {
 
 into
 
-``` rust
+``` rust,noplayground
 #[rtic::app(/* .. */)]
 mod app {
   [code here]
@@ -75,7 +75,7 @@ mod app {
 
 Change
 
-``` rust
+``` rust,noplayground
 #[rtic::app(/* .. */)]
 const APP: () = {
     [code here]
@@ -92,7 +92,7 @@ const APP: () = {
 
 into
 
-``` rust
+``` rust,noplayground
 #[rtic::app(/* .. */, dispatchers = [SSI0, QEI0])]
 mod app {
   [code here]
@@ -106,7 +106,7 @@ This works also for ram functions, see examples/ramfunc.rs
 
 Previously the RTIC resources had to be in in a struct named exactly "Resources":
 
-``` rust
+``` rust,noplayground
 struct Resources {
     // Resources defined in here
 }
@@ -115,7 +115,7 @@ struct Resources {
 With RTIC v1.0.0 the resources structs are annotated similarly like
 `#[task]`, `#[init]`, `#[idle]`: with the attributes `#[shared]` and `#[local]`
 
-``` rust
+``` rust,noplayground
 #[shared]
 struct MySharedResources {
     // Resources shared between tasks are defined here
@@ -136,7 +136,7 @@ In v1.0.0 resources are split between `shared` resources and `local` resources.
 
 In v0.5.x:
 
-``` rust
+``` rust,noplayground
 struct Resources {
     local_to_b: i64,
     shared_by_a_and_b: i64,
@@ -151,7 +151,7 @@ fn b(_: b::Context) {}
 
 In v1.0.0:
 
-``` rust
+``` rust,noplayground
 #[shared]
 struct Shared {
     shared_by_a_and_b: i64,
@@ -176,7 +176,7 @@ to be used for all `shared` resource access.
 In old code one could do the following as the high priority
 task has exclusive access to the resource:
 
-``` rust
+``` rust,noplayground
 #[task(priority = 2, resources = [r])]
 fn foo(cx: foo::Context) {
     cx.resources.r = /* ... */;
@@ -190,7 +190,7 @@ fn bar(cx: bar::Context) {
 
 And with symmetric locks one needs to use locks in both tasks:
 
-``` rust
+``` rust,noplayground
 #[task(priority = 2, shared = [r])]
 fn foo(cx: foo::Context) {
     cx.shared.r.lock(|r| r = /* ... */);
@@ -211,7 +211,7 @@ This is still possible in 1.0: the `#[shared]` resource must be annotated with t
 
 v0.5 code:
 
-``` rust
+``` rust,noplayground
 struct Resources {
     counter: u64,
 }
@@ -229,7 +229,7 @@ fn b(cx: b::Context) {
 
 v1.0 code:
 
-``` rust
+``` rust,noplayground
 #[shared]
 struct Shared {
     #[lock_free]
@@ -254,7 +254,7 @@ Instead of that syntax, use the `local` argument in `#[init]`.
 
 v0.5.x code:
 
-``` rust
+``` rust,noplayground
 #[init]
 fn init(_: init::Context) {
     static mut BUFFER: [u8; 1024] = [0; 1024];
@@ -264,7 +264,7 @@ fn init(_: init::Context) {
 
 v1.0.0 code:
 
-``` rust
+``` rust,noplayground
 #[init(local = [
     buffer: [u8; 1024] = [0; 1024]
 //   type ^^^^^^^^^^^^   ^^^^^^^^^ initial value
@@ -282,7 +282,7 @@ In order to make the API more symmetric the #[init]-task always returns a late r
 
 From this:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = lm3s6965)]
 const APP: () = {
     #[init]
@@ -296,7 +296,7 @@ const APP: () = {
 
 to this:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = lm3s6965)]
 mod app {
     #[shared]
@@ -321,7 +321,7 @@ mod app {
 With the new spawn/spawn_after/spawn_at interface,
 old code requiring the context `cx` for spawning such as:
 
-``` rust
+``` rust,noplayground
 #[task(spawn = [bar])]
 fn foo(cx: foo::Context) {
     cx.spawn.bar().unwrap();
@@ -335,7 +335,7 @@ fn bar(cx: bar::Context) {
 
 Will now be written as:
 
-``` rust
+``` rust,noplayground
 #[task]
 fn foo(_c: foo::Context) {
     bar::spawn().unwrap();

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}}
 ```

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}}
 ```
 

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}}
 ```
 

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}}
 ```
 

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}}
 ```
 

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}}
 ```