You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix included examples and markdown(book)
fixes: #911
* fix footnote pre_init
* more example link updates
* Restore pool example name
* Example: pool: Upgrade to heapless v0.8
* Example: pool: thumbv6 unsupported: wild cfg-if
Experiment with multi-backend example contained in the example
* Example: lm3s6965: Updated cargo.lock
* Book: Use cargo xtask for by-example
* Docs: Contributing: cargo xtask
---------
Co-authored-by: Henrik Tjäder <[email protected]>
INFO xtask > Testing for platform: Lm3s6965, backend: Thumbv7
42
+
INFO xtask::run > 👟 Build example locals (thumbv7m-none-eabi, release, "test-critical-section,thumbv7-backend", in examples/lm3s6965)
43
+
INFO xtask::run > ✅ Success.
44
+
INFO xtask::run > 👟 Run example locals in QEMU (thumbv7m-none-eabi, release, "test-critical-section,thumbv7-backend", in examples/lm3s6965)
45
+
INFO xtask::run > ✅ Success.
46
+
INFO xtask::results > ✅ Success: Build example locals (thumbv7m-none-eabi, release, "test-critical-section,thumbv7-backend", in examples/lm3s6965)
47
+
INFO xtask::results > ✅ Success: Run example locals in QEMU (thumbv7m-none-eabi, release, "test-critical-section,thumbv7-backend", in examples/lm3s6965)
48
+
INFO xtask::results > 🚀🚀🚀 All tasks succeeded 🚀🚀🚀
49
+
```
50
+
51
+
It is great that examples are passing and this is part of the RTIC CI setup too, but for the purposes of this book we must add the `--verbose` flag, or `-v` for short to see the actual program output:
52
+
53
+
```console
54
+
❯ cargo xtask qemu --verbose --example locals
55
+
Finished dev [unoptimized + debuginfo] target(s) in 0.03s
INFO xtask::results > ✅ Success: Run example locals in QEMU (thumbv7m-none-eabi, release, "test-critical-section,thumbv7-backend", in examples/lm3s6965)
71
+
cd examples/lm3s6965 && cargo run --target thumbv7m-none-eabi --features test-critical-section,thumbv7-backend --release --example locals
72
+
DEBUG xtask::results >
73
+
cd examples/lm3s6965 && cargo run --target thumbv7m-none-eabi --features test-critical-section,thumbv7-backend --release --example locals
> **NOTE**: You can choose target device by passing a target
36
-
> triple to cargo (e.g. `cargo run --example init --target thumbv7m-none-eabi`) or
37
-
> configure a default target in `.cargo/config.toml`.
38
-
>
39
-
> For running the examples, we (typically) use a Cortex M3 emulated in QEMU, so the target is `thumbv7m-none-eabi`.
40
-
> Since the M3 architecture is backwards compatible to the M0/M0+ architecture, you may also use the `thumbv6m-none-eabi`, in case you want to inspect generated assembly code for the M0/M0+ architecture.
93
+
> **NOTE**:
94
+
> For other useful options to `cargo xtask`, see:
95
+
> ```
96
+
> cargo xtask qemu --help
97
+
> ```
98
+
>
99
+
> The `--platform` flag allows changing which device examples are run on,
100
+
> currently `lm3s6965` is the best supported, work is ongoing to
101
+
> increase support for other devices, including both ARM and RISC-V
Copy file name to clipboardexpand all lines: book/en/src/by-example/app.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
All RTIC applications use the [`app`] attribute (`#[app(..)]`). This attribute only applies to a `mod`-item containing the RTIC application.
6
6
7
-
The `app` attribute has a mandatory `device` argument that takes a *path* as a value. This must be a full path pointing to a *peripheral access crate* (PAC) generated using [`svd2rust`]**v0.14.x** or newer.
7
+
The `app` attribute has a mandatory `device` argument that takes a _path_ as a value. This must be a full path pointing to a _peripheral access crate_ (PAC) generated using [`svd2rust`]**v0.14.x** or newer.
8
8
9
9
The `app` attribute will expand into a suitable entry point and thus replaces the use of the [`cortex_m_rt::entry`] attribute.
10
10
@@ -14,13 +14,13 @@ The `app` attribute will expand into a suitable entry point and thus replaces th
14
14
15
15
## Structure and zero-cost concurrency
16
16
17
-
An RTIC `app` is an executable system model for single-core applications, declaring a set of `local` and `shared` resources operated on by a set of `init`, `idle`, *hardware* and *software* tasks.
17
+
An RTIC `app` is an executable system model for single-core applications, declaring a set of `local` and `shared` resources operated on by a set of `init`, `idle`, _hardware_ and _software_ tasks.
18
18
19
-
*`init` runs before any other task, and returns the `local` and `shared` resources.
20
-
* Tasks (both hardware and software) run preemptively based on their associated static priority.
21
-
* Hardware tasks are bound to underlying hardware interrupts.
22
-
* Software tasks are schedulied by an set of asynchronous executors, one for each software task priority.
23
-
*`idle` has the lowest priority, and can be used for background work, and/or to put the system to sleep until it is woken by some event.
19
+
-`init` runs before any other task, and returns the `local` and `shared` resources.
20
+
- Tasks (both hardware and software) run preemptively based on their associated static priority.
21
+
- Hardware tasks are bound to underlying hardware interrupts.
22
+
- Software tasks are schedulied by an set of asynchronous executors, one for each software task priority.
23
+
-`idle` has the lowest priority, and can be used for background work, and/or to put the system to sleep until it is woken by some event.
24
24
25
25
At compile time the task/resource model is analyzed under the Stack Resource Policy (SRP) and executable code generated with the following outstanding properties:
26
26
@@ -41,6 +41,6 @@ Priorities in RTIC follow a higher value = more important scheme. For examples,
41
41
To give a taste of RTIC, the following example contains commonly used features.
42
42
In the following sections we will go through each feature in detail.
A function marked with the `idle` attribute can optionally appear in the module. This becomes the special *idle task* and must have signature `fn(idle::Context) -> !`.
3
+
A function marked with the `idle` attribute can optionally appear in the module. This becomes the special _idle task_ and must have signature `fn(idle::Context) -> !`.
4
4
5
-
When present, the runtime will execute the `idle` task after `init`. Unlike `init`, `idle` will run *with interrupts enabled* and must never return, as the `-> !` function signature indicates.
5
+
When present, the runtime will execute the `idle` task after `init`. Unlike `init`, `idle` will run _with interrupts enabled_ and must never return, as the `-> !` function signature indicates.
> **Notice**: The `idle` task cannot be used together with *software* tasks running at priority zero. The reason is that `idle` is running as a non-returning Rust function at priority zero. Thus there would be no way for an executor at priority zero to give control to *software* tasks at the same priority.
53
+
> **Notice**: The `idle` task cannot be used together with _software_ tasks running at priority zero. The reason is that `idle` is running as a non-returning Rust function at priority zero. Thus there would be no way for an executor at priority zero to give control to _software_ tasks at the same priority.
Copy file name to clipboardexpand all lines: book/en/src/by-example/app_init.md
+10-9
Original file line number
Diff line number
Diff line change
@@ -3,30 +3,31 @@
3
3
An RTIC application requires an `init` task setting up the system. The corresponding `init` function must have the
4
4
signature `fn(init::Context) -> (Shared, Local)`, where `Shared` and `Local` are resource structures defined by the user.
5
5
6
-
The `init` task executes after system reset, [after an optionally defined `pre-init` code section][pre-init] and an always occurring internal RTIC initialization.
The `init` task executes after system reset, [after an optionally defined `pre-init` code section][^pre-init] and an always occurring internal RTIC initialization.
8
7
9
-
The `init` and optional `pre-init` tasks runs *with interrupts disabled* and have exclusive access to Cortex-M (the `bare_metal::CriticalSection` token is available as `cs`).
8
+
The `init` and optional `pre-init` tasks runs _with interrupts disabled_ and have exclusive access to Cortex-M (the `bare_metal::CriticalSection` token is available as `cs`).
10
9
11
10
Device specific peripherals are available through the `core` and `device` fields of `init::Context`.
The example below shows the types of the `core`, `device` and `cs` fields, and showcases the use of a `local` variable with `'static` lifetime. Such variables can be delegated from the `init` task to other tasks of the RTIC application.
16
17
17
18
The `device` field is only available when the `peripherals` argument is set to the default value `true`.
18
19
In the rare case you want to implement an ultra-slim application you can explicitly set `peripherals` to `false`.
0 commit comments