From 53ed7bf7edb21180cb18c0bf6a7dbe6168331879 Mon Sep 17 00:00:00 2001 From: Franz Dietrich Date: Thu, 4 Apr 2024 00:01:46 +0200 Subject: fix included examples and markdown(book) (#912) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 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 --- book/en/src/by-example/hardware_tasks.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'book/en/src/by-example/hardware_tasks.md') diff --git a/book/en/src/by-example/hardware_tasks.md b/book/en/src/by-example/hardware_tasks.md index ded488c..4cd30b7 100644 --- a/book/en/src/by-example/hardware_tasks.md +++ b/book/en/src/by-example/hardware_tasks.md @@ -4,11 +4,11 @@ At its core RTIC is using a hardware interrupt controller ([ARM NVIC on cortex-m To bind a task to an interrupt, use the `#[task]` attribute argument `binds = InterruptName`. This task then becomes the interrupt handler for this hardware interrupt vector. -All tasks bound to an explicit interrupt are called *hardware tasks* since they start execution in reaction to a hardware event. +All tasks bound to an explicit interrupt are called _hardware tasks_ since they start execution in reaction to a hardware event. Specifying a non-existing interrupt name will cause a compilation error. The interrupt names are commonly defined by [PAC or HAL][pacorhal] crates. -Any available interrupt vector should work. Specific devices may bind specific interrupt priorities to specific interrupt vectors outside user code control. See for example the [nRF “softdevice”](https://github.com/rtic-rs/rtic/issues/434). +Any available interrupt vector should work. Specific devices may bind specific interrupt priorities to specific interrupt vectors outside user code control. See for example the [nRF “softdevice”](https://github.com/rtic-rs/rtic/issues/434). Beware of using interrupt vectors that are used internally by hardware features; RTIC is unaware of such hardware specific details. @@ -19,14 +19,14 @@ 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,noplayground -{{#include ../../../../rtic/examples/hardware.rs}} +```rust,noplayground +{{#include ../../../../examples/lm3s6965/examples/hardware.rs}} ``` -``` console -$ cargo run --target thumbv7m-none-eabi --example hardware +```console +$ cargo xtask qemu --verbose --example hardware ``` -``` console -{{#include ../../../../rtic/ci/expected/hardware.run}} +```console +{{#include ../../../../ci/expected/lm3s6965/hardware.run}} ``` -- cgit v1.2.3