RTIC

The hardware accelerated Rust RTOS

A concurrency framework for building real-time systems

Preface

This book contains user level documentation for the Real-Time Interrupt-driven Concurrency (RTIC) framework. The API reference is available here.

This is the documentation for RTIC v2.x.

Older releases: RTIC v1.x | RTIC v0.5.x (unsupported) | RTFM v0.4.x (unsupported)

crates.io docs.rs book matrix Meeting notes

Is RTIC an RTOS?

A common question is whether RTIC is an RTOS or not, and depending on your background the answer may vary. From RTIC's developers point of view; RTIC is a hardware accelerated RTOS that utilizes the hardware such as the NVIC on Cortex-M MCUs, CLIC on RISC-V etc. to perform scheduling, rather than the more classical software kernel.

Another common view from the community is that RTIC is a concurrency framework as there is no software kernel and that it relies on external HALs.

RTIC - The Past, current and Future

This section gives a background to the RTIC model. Feel free to skip to section RTIC the model for a TL;DR.

The RTIC framework takes the outset from real-time systems research at LuleΓ₯ University of Technology (LTU) Sweden. RTIC is inspired by the concurrency model of the Timber language, the RTFM-SRP based scheduler, the RTFM-core language and Abstract Timer implementation. For a full list of related research see RTFM and RTIC publications.

Stack Resource Policy based Scheduling

Stack Resource Policy (SRP) based concurrency and resource management is at heart of the RTIC framework. The SRP model itself extends on Priority Inheritance Protocols, and provides a set of outstanding properties for single core scheduling. To name a few:

  • preemptive deadlock and race-free scheduling
  • resource efficiency
    • tasks execute on a single shared stack
    • tasks run-to-completion with wait free access to shared resources
  • predictable scheduling, with bounded priority inversion by a single (named) critical section
  • theoretical underpinning amenable to static analysis (e.g., for task response times and overall schedulability)

SRP comes with a set of system-wide requirements:

  • each task is associated a static priority,
  • tasks execute on a single-core,
  • tasks must be run-to-completion, and
  • resources must be claimed/locked in LIFO order.

SRP analysis

SRP based scheduling requires the set of static priority tasks and their access to shared resources to be known in order to compute a static ceiling (𝝅) for each resource. The static resource ceiling 𝝅(r) reflects the maximum static priority of any task that accesses the resource r.

Example

Assume two tasks A (with priority p(A) = 2) and B (with priority p(B) = 4) both accessing the shared resource R. The static ceiling of R is 4 (computed from 𝝅(R) = max(p(A) = 2, p(B) = 4) = 4).

A graph representation of the example:

graph LR
    A["p(A) = 2"] --> R
    B["p(B) = 4"] --> R
    R["𝝅(R) = 4"]

RTIC the hardware accelerated real-time scheduler

SRP itself is compatible with both dynamic and static priority scheduling. For the implementation of RTIC we leverage on the underlying hardware for accelerated static priority scheduling.

In the case of the ARM Cortex-M architecture, each interrupt vector entry v[i] is associated a function pointer (v[i].fn), and a static priority (v[i].priority), an enabled- (v[i].enabled) and a pending-bit (v[i].pending).

An interrupt i is scheduled (run) by the hardware under the conditions:

  1. is pended and enabled and has a priority higher than the (optional BASEPRI) register, and
  2. has the highest priority among interrupts meeting 1.

The first condition (1) can be seen a filter allowing RTIC to take control over which tasks should be allowed to start (and which should be prevented from starting).

The SPR model for single-core static scheduling on the other hand states that a task should be scheduled (run) under the conditions:

  1. it is requested to run and has a static priority higher than the current system ceiling (𝜫)
  2. it has the highest static priority among tasks meeting 1.

The similarities are striking and it is not by chance/luck/coincidence. The hardware was cleverly designed with real-time scheduling in mind.

In order to map the SRP scheduling onto the hardware we need to take a closer look at the system ceiling (𝜫). Under SRP 𝜫 is computed as the maximum priority ceiling of the currently held resources, and will thus change dynamically during the system operation.

Example

Assume the task model above. Starting from an idle system, 𝜫 is 0, (no task is holding any resource). Assume that A is requested for execution, it will immediately be scheduled. Assume that A claims (locks) the resource R. During the claim (lock of R) any request B will be blocked from starting (by 𝜫 = max(𝝅(R) = 4) = 4, p(B) = 4, thus SRP scheduling condition 1 is not met).

Mapping

The mapping of static priority SRP based scheduling to the Cortex M hardware is straightforward:

  • each task t are mapped to an interrupt vector index i with a corresponding function v[i].fn = t and given the static priority v[i].priority = p(t).
  • the current system ceiling is mapped to the BASEPRI register or implemented through masking the interrupt enable bits accordingly.

Example

For the running example, a snapshot of the ARM Cortex M Nested Vectored Interrupt Controller (NVIC) may have the following configuration (after task A has been pended for execution.)

IndexFnPriorityEnabledPended
0A2truetrue
1B4truefalse

(As discussed later, the assignment of interrupt and exception vectors is up to the user.)

A claim (lock(r)) will change the current system ceiling (𝜫) and can be implemented as a named critical section:

  • old_ceiling = 𝜫, 𝜫 = 𝝅(r)
  • execute code within critical section
  • old_ceiling = 𝜫

This amounts to a resource protection mechanism requiring only two machine instructions on enter and one on exit the critical section for managing the BASEPRI register. For architectures lacking BASEPRI, we can implement the system ceiling through a set of machine instructions for disabling/enabling interrupts on entry/exit for the named critical section. The number of machine instructions vary depending on the number of mask registers that needs to be updated (a single machine operation can operate on up to 32 interrupts, so for the M0/M0+ architecture a single instruction suffice). RTIC will determine the ceiling values and masking constants at compile time, thus all operations is in Rust terms zero-cost.

In this way RTIC fuses SRP based preemptive scheduling with a zero-cost hardware accelerated implementation, resulting in "best in class" guarantees and performance.

Given that the approach is dead simple, how come SRP and hardware accelerated scheduling is not adopted by any other mainstream RTOS?

The answer is simple, the commonly adopted threading model does not lend itself well to static analysis - there is no known way to extract the task/resource dependencies from the source code at compile time (thus ceilings cannot be efficiently computed and the LIFO resource locking requirement cannot be ensured). Thus, SRP based scheduling is in the general case out of reach for any thread based RTOS.

RTIC into the Future

Asynchronous programming in various forms are getting increased popularity and language support. Rust natively provides an async/await API for cooperative multitasking and the compiler generates the necessary boilerplate for storing and retrieving execution contexts (i.e., managing the set of local variables that spans each await).

The Rust standard library provides collections for dynamically allocated data-structures which are useful to manage execution contexts at run-time. However, in the setting of resource constrained real-time systems, dynamic allocations are problematic (both regarding performance and reliability - Rust runs into a panic on an out-of-memory condition). Thus, static allocation is the preferable approach!

From a modelling perspective async/await lifts the run-to-completion requirement of SRP, and each section of code between two yield points (awaits) can be seen as an individual task. The compiler will reject any attempt to await while holding a resource (not doing so would break the strict LIFO requirement on resource usage under SRP).

So with the technical stuff out of the way, what does async/await bring to the table?

The answer is - improved ergonomics! A recurring use case is to have task perform a sequence of requests and then await their results in order to progress. Without async/await the programmer would be forced to split the task into individual sub-tasks and maintain some sort of state encoding (and manually progress by selecting sub-task). Using async/await each yield point (await) essentially represents a state, and the progression mechanism is built automatically for you at compile time by means of Futures.

Rust async/await support is still incomplete and/or under development (e.g., there are no stable way to express async closures, precluding use in iterator patterns). Nevertheless, Rust async/await is production ready and covers most common use cases.

An important property is that futures are composable, thus you can await either, all, or any combination of possible futures (allowing e.g., timeouts and/or asynchronous errors to be promptly handled).

RTIC the model

An RTIC app is a declarative and executable system model for single-core applications, defining a set of (local and shared) resources operated on by a set of (init, idle, hardware and software) tasks. In short the init task runs before any other task returning a set of resources (local and shared). Tasks run preemptively based on their associated static priority, idle has the lowest priority (and can be used for background work, and/or to put the system to sleep until woken by some event). Hardware tasks are bound to underlying hardware interrupts, while software tasks are scheduled by asynchronous executors (one for each software task priority).

At compile time the task/resource model is analyzed under SRP and executable code generated with the following outstanding properties:

  • guaranteed race-free resource access and deadlock-free execution on a single-shared stack (thanks to SRP)
    • hardware task scheduling is performed directly by the hardware, and
    • software task scheduling is performed by auto generated async executors tailored to the application.

The RTIC API design ensures that both SRP requirements and Rust soundness rules are upheld at all times, thus the executable model is correct by construction. Overall, the generated code infers no additional overhead in comparison to a handwritten implementation, thus in Rust terms RTIC offers a zero-cost abstraction to concurrency.

Starting a new project

A recommendation when starting a RTIC project from scratch is to follow RTIC's defmt-app-template.

If you are targeting ARMv6-M or ARMv8-M-base architecture, check out the section Target Architecture for more information on hardware limitations to be aware of.

This will give you an RTIC application with support for RTT logging with defmt and stack overflow protection using flip-link. There is also a multitude of examples provided by the community:

For inspiration, you may look at the RTIC examples.

RTIC by example

This part of the book introduces the RTIC framework to new users by walking them through examples of increasing complexity.

All examples in this part of the book are accessible at the GitHub repository. The examples are runnable on QEMU (emulating a Cortex M3 target), thus no special hardware required to follow along.

Running an example

To run the examples with QEMU you will 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.

To run the examples found in examples/ locally, cargo needs a supported target and either --examples (run all examples) or --example NAME to run a specific example.

Assuming dependencies in place, running:

$ cargo run --target thumbv7m-none-eabi --example locals

Yields this output:

{{#include ../../../rtic/ci/expected/locals.run}}

NOTE: You can choose target device by passing a target triple to cargo (e.g. cargo run --example init --target thumbv7m-none-eabi) or configure a default target in .cargo/config.toml.

For running the examples, we (typically) use a Cortex M3 emulated in QEMU, so the target is thumbv7m-none-eabi. 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.

The #[app] attribute and an RTIC application

Requirements on the app attribute

All RTIC applications use the app attribute (#[app(..)]). This attribute only applies to a mod-item containing the RTIC application.

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.

The app attribute will expand into a suitable entry point and thus replaces the use of the cortex_m_rt::entry attribute.

Structure and zero-cost concurrency

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.

  • init runs before any other task, and returns the local and shared resources.
  • Tasks (both hardware and software) run preemptively based on their associated static priority.
  • Hardware tasks are bound to underlying hardware interrupts.
  • Software tasks are schedulied by an set of asynchronous executors, one for each software task priority.
  • 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.

At compile time the task/resource model is analyzed under the Stack Resource Policy (SRP) and executable code generated with the following outstanding properties:

  • Guaranteed race-free resource access and deadlock-free execution on a single-shared stack.
  • Hardware task scheduling is performed directly by the hardware.
  • Software task scheduling is performed by auto generated async executors tailored to the application.

Overall, the generated code infers no additional overhead in comparison to a hand-written implementation, thus in Rust terms RTIC offers a zero-cost abstraction to concurrency.

Priority

Priorities in RTIC are specified using the priority = N (where N is a positive number) argument passed to the #[task] attribute. All #[task]s can have a priority. If the priority of a task is not specified, it is set to the default value of 0.

Priorities in RTIC follow a higher value = more important scheme. For examples, a task with priority 2 will preempt a task with priority 1.

An RTIC application example

To give a taste of RTIC, the following example contains commonly used features. In the following sections we will go through each feature in detail.

{{#include ../../../../rtic/examples/common.rs}}

Hardware tasks

At its core RTIC is using a hardware interrupt controller (ARM NVIC on cortex-m) to schedule and start execution of tasks. All tasks except pre-init (a hidden "task"), #[init] and #[idle] run as interrupt handlers.

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.

Specifying a non-existing interrupt name will cause a compilation error. The interrupt names are commonly defined by PAC or HAL 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”.

Beware of using interrupt vectors that are used internally by hardware features; RTIC is unaware of such hardware specific details.

Example

The example below demonstrates the use of the #[task(binds = InterruptName)] attribute to declare a hardware task bound to an interrupt handler.

{{#include ../../../../rtic/examples/hardware.rs}}
$ cargo run --target thumbv7m-none-eabi --example hardware
{{#include ../../../../rtic/ci/expected/hardware.run}}

Software tasks & spawn

The RTIC concept of a software task shares a lot with that of hardware tasks. The core difference is that a software task is not explicitly bound to a specific interrupt vector, but rather bound to a β€œdispatcher” interrupt vector running at the intended priority of the software task (see below).

Similarly to hardware tasks, the #[task] attribute used on a function declare it as a task. The absence of a binds = InterruptName argument to the attribute declares the function as a software task.

The static method task_name::spawn() spawns (starts) a software task and given that there are no higher priority tasks running the task will start executing directly.

The software task itself is given as an async Rust function, which allows the user to optionally await future events. This allows to blend reactive programming (by means of hardware tasks) with sequential programming (by means of software tasks).

While hardware tasks are assumed to run-to-completion (and return), software tasks may be started (spawned) once and run forever, on the condition that any loop (execution path) is broken by at least one await (yielding operation).

Dispatchers

All software tasks at the same priority level share an interrupt handler acting as an async executor dispatching the software tasks. This list of dispatchers, dispatchers = [FreeInterrupt1, FreeInterrupt2, ...] is an argument to the #[app] attribute, where you define the set of free and usable interrupts.

Each interrupt vector acting as dispatcher gets assigned to one priority level meaning that the list of dispatchers need to cover all priority levels used by software tasks.

Example: The dispatchers = argument needs to have at least 3 entries for an application using three different priorities for software tasks.

The framework will give a compilation error if there are not enough dispatchers provided, or if a clash occurs between the list of dispatchers and interrupts bound to hardware tasks.

See the following example:

{{#include ../../../../rtic/examples/spawn.rs}}
$ cargo run --target thumbv7m-none-eabi --example spawn
{{#include ../../../../rtic/ci/expected/spawn.run}}

You may spawn a software task again, given that it has run-to-completion (returned).

In the below example, we spawn the software task foo from the idle task. Since the priority of the software task is 1 (higher than idle), the dispatcher will execute foo (preempting idle). Since foo runs-to-completion. It is ok to spawn the foo task again.

Technically the async executor will poll the foo future which in this case leaves the future in a completed state.

{{#include ../../../../rtic/examples/spawn_loop.rs}}
$ cargo run --target thumbv7m-none-eabi --example spawn_loop
{{#include ../../../../rtic/ci/expected/spawn_loop.run}}

An attempt to spawn an already spawned task (running) task will result in an error. Notice, the that the error is reported before the foo task is actually run. This is since, the actual execution of the software task is handled by the dispatcher interrupt (SSIO), which is not enabled until we exit the init task. (Remember, init runs in a critical section, i.e. all interrupts being disabled.)

Technically, a spawn to a future that is not in completed state is considered an error.

{{#include ../../../../rtic/examples/spawn_err.rs}}
$ cargo run --target thumbv7m-none-eabi --example spawn_err
{{#include ../../../../rtic/ci/expected/spawn_err.run}}

Passing arguments

You can also pass arguments at spawn as follows.

{{#include ../../../../rtic/examples/spawn_arguments.rs}}
$ cargo run --target thumbv7m-none-eabi --example spawn_arguments
{{#include ../../../../rtic/ci/expected/spawn_arguments.run}}

Priority zero tasks

In RTIC tasks run preemptively to each other, with priority zero (0) the lowest priority. You can use priority zero tasks for background work, without any strict real-time requirements.

Conceptually, one can see such tasks as running in the main thread of the application, thus the resources associated are not required the Send bound.

{{#include ../../../../rtic/examples/zero-prio-task.rs}}
$ cargo run --target thumbv7m-none-eabi --example zero-prio-task
{{#include ../../../../rtic/ci/expected/zero-prio-task.run}}

Notice: software task at zero priority cannot co-exist with the [idle] task. 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.


Application side safety: Technically, the RTIC framework ensures that poll is never executed on any software task with completed future, thus adhering to the soundness rules of async Rust.

Resource usage

The RTIC framework manages shared and task local resources allowing persistent data storage and safe accesses without the use of unsafe code.

RTIC resources are visible only to functions declared within the #[app] module and the framework gives the user complete control (on a per-task basis) over resource accessibility.

Declaration of system-wide resources is done by annotating two structs within the #[app] module with the attribute #[local] and #[shared]. Each field in these structures corresponds to a different resource (identified by field name). The difference between these two sets of resources will be covered below.

Each task must declare the resources it intends to access in its corresponding metadata attribute using the local and shared arguments. Each argument takes a list of resource identifiers. The listed resources are made available to the context under the local and shared fields of the Context structure.

The init task returns the initial values for the system-wide (#[shared] and #[local]) resources.

#[local] resources

#[local] resources are locally accessible to a specific task, meaning that only that task can access the resource and does so without locks or critical sections. This allows for the resources, commonly drivers or large objects, to be initialized in #[init] and then be passed to a specific task.

Thus, a task #[local] resource can only be accessed by one singular task. Attempting to assign the same #[local] resource to more than one task is a compile-time error.

Types of #[local] resources must implement a Send trait as they are being sent from init to a target task, crossing a thread boundary.

The example application shown below contains three tasks foo, bar and idle, each having access to its own #[local] resource.

{{#include ../../../../rtic/examples/locals.rs}}

Running the example:

$ cargo run --target thumbv7m-none-eabi --example locals
{{#include ../../../../rtic/ci/expected/locals.run}}

Local resources in #[init] and #[idle] have 'static lifetimes. This is safe since both tasks are not re-entrant.

Task local initialized resources

Local resources can also be specified directly in the resource claim like so: #[task(local = [my_var: TYPE = INITIAL_VALUE, ...])]; this allows for creating locals which do no need to be initialized in #[init].

Types of #[task(local = [..])] resources have to be neither Send nor Sync as they are not crossing any thread boundary.

In the example below the different uses and lifetimes are shown:

{{#include ../../../../rtic/examples/declared_locals.rs}}

You can run the application, but as the example is designed merely to showcase the lifetime properties there is no output (it suffices to build the application).

$ cargo build --target thumbv7m-none-eabi --example declared_locals

#[shared] resources and lock

Critical sections are required to access #[shared] resources in a data race-free manner and to achieve this the shared field of the passed Context implements the Mutex trait for each shared resource accessible to the task. This trait has only one method, lock, which runs its closure argument in a critical section.

The critical section created by the lock API is based on dynamic priorities: it temporarily raises the dynamic priority of the context to a ceiling priority that prevents other tasks from preempting the critical section. This synchronization protocol is known as the Immediate Ceiling Priority Protocol (ICPP), and complies with Stack Resource Policy (SRP) based scheduling of RTIC.

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.

{{#include ../../../../rtic/examples/lock.rs}}
$ cargo run --target thumbv7m-none-eabi --example lock
{{#include ../../../../rtic/ci/expected/lock.run}}

Types of #[shared] resources have to be Send.

Multi-lock

As an extension to lock, and to reduce rightward drift, locks can be taken as tuples. The following examples show this in use:

{{#include ../../../../rtic/examples/multilock.rs}}
$ cargo run --target thumbv7m-none-eabi --example multilock
{{#include ../../../../rtic/ci/expected/multilock.run}}

Only shared (&-) access

By default, the framework assumes that all tasks require exclusive mutable access (&mut-) to resources, but it is possible to specify that a task only requires shared access (&-) to a resource using the &resource_name syntax in the shared list.

The advantage of specifying shared access (&-) to a resource is that no locks are required to access the resource even if the resource is contended by more than one task running at different priorities. The downside is that the task only gets a shared reference (&-) to the resource, limiting the operations it can perform on it, but where a shared reference is enough this approach reduces the number of required locks. In addition to simple immutable data, this shared access can be useful where the resource type safely implements interior mutability, with appropriate locking or atomic operations of its own.

Note that in this release of RTIC it is not possible to request both exclusive access (&mut-) and shared access (&-) to the same resource from different tasks. Attempting to do so will result in a compile error.

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.

{{#include ../../../../rtic/examples/only-shared-access.rs}}
$ cargo run --target thumbv7m-none-eabi --example only-shared-access
{{#include ../../../../rtic/ci/expected/only-shared-access.run}}

Lock-free access of shared resources

A critical section is not required to access a #[shared] resource that's only accessed by tasks running at the same priority. In this case, you can opt out of the lock API by adding the #[lock_free] field-level attribute to the resource declaration (see example below).

To adhere to the Rust aliasing rule, a resource may be either accessed through multiple immutable references or a singe mutable reference (but not both at the same time).

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.

{{#include ../../../../rtic/examples/lock-free.rs}}
$ cargo run --target thumbv7m-none-eabi --example lock-free
{{#include ../../../../rtic/ci/expected/lock-free.run}}

App initialization and the #[init] task

An RTIC application requires an init task setting up the system. The corresponding init function must have the signature fn(init::Context) -> (Shared, Local), where Shared and Local are resource structures defined by the user.

The init task executes after system reset, [after an optionally defined pre-init code section][pre-init] and an always occurring internal RTIC initialization. [pre-init]: https://docs.rs/cortex-m-rt/latest/cortex_m_rt/attr.pre_init.html

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).

Device specific peripherals are available through the core and device fields of init::Context.

Example

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.

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.

{{#include ../../../../rtic/examples/init.rs}}

Running the example will print init to the console and then exit the QEMU process.

$ cargo run --target thumbv7m-none-eabi --example init
{{#include ../../../../rtic/ci/expected/init.run}}

The background task #[idle]

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) -> !.

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. The Rust type ! means β€œnever”.

Like in init, locally declared resources will have 'static lifetimes that are safe to access.

The example below shows that idle runs after init.

{{#include ../../../../rtic/examples/idle.rs}}
$ cargo run --target thumbv7m-none-eabi --example idle
{{#include ../../../../rtic/ci/expected/idle.run}}

By default, the RTIC idle task does not try to optimize for any specific targets.

A common useful optimization is to enable the SLEEPONEXIT and allow the MCU to enter sleep when reaching idle.

Caution: some hardware unless configured disables the debug unit during sleep mode.

Consult your hardware specific documentation as this is outside the scope of RTIC.

The following example shows how to enable sleep by setting the SLEEPONEXIT and providing a custom idle task replacing the default nop() with wfi().

{{#include ../../../../rtic/examples/idle-wfi.rs}}
$ cargo run --target thumbv7m-none-eabi --example idle-wfi
{{#include ../../../../rtic/ci/expected/idle-wfi.run}}

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.

Communication over channels.

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:

...
const CAPACITY: usize = 5;
#[init]
    fn init(_: init::Context) -> (Shared, Local) {
        let (s, r) = make_channel!(u32, CAPACITY);
        receiver::spawn(r).unwrap();
        sender1::spawn(s.clone()).unwrap();
        sender2::spawn(s.clone()).unwrap();
        ...

In this case the channel holds data of u32 type with a capacity of 5 elements.

Channels can also be used from hardware tasks, but only in a non-async manner using the Try API.

Sending data

The send method post a message on the channel as shown below:

#[task]
async fn sender1(_c: sender1::Context, mut sender: Sender<'static, u32, CAPACITY>) {
    hprintln!("Sender 1 sending: 1");
    sender.send(1).await.unwrap();
}

Receiving data

The receiver can await incoming messages:

#[task]
async fn receiver(_c: receiver::Context, mut receiver: Receiver<'static, u32, CAPACITY>) {
    while let Ok(val) = receiver.recv().await {
        hprintln!("Receiver got: {}", val);
        ...
    }
}

Channels are implemented using a small (global) Critical Section (CS) for protection against race-conditions. The user must provide an CS implementation. Compiling the examples given the --features test-critical-section gives one possible implementation.

For a complete example:

{{#include ../../../../rtic/examples/async-channel.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-channel --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-channel.run}}

Also sender endpoint can be awaited. In case the channel capacity has not yet been reached, await-ing the sender can progress immediately, while in the case the capacity is reached, the sender is blocked until there is free space in the queue. In this way data is never lost.

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.

{{#include ../../../../rtic/examples/async-channel-done.rs}}

Looking at the output, we find that Sender 2 will wait until the data sent by Sender 1 as been received.

NOTICE Software tasks at the same priority are executed asynchronously to each other, thus NO strict order can be assumed. (The presented order here applies only to the current implementation, and may change between RTIC framework releases.)

$ cargo run --target thumbv7m-none-eabi --example async-channel-done --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-channel-done.run}}

Error handling

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.

{{#include ../../../../rtic/examples/async-channel-no-sender.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-channel-no-sender --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-channel-no-sender.run}}

Similarly, await-ing on a send channel results in an error in case the receiver has been dropped. This allows to gracefully implement application level error handling.

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).

{{#include ../../../../rtic/examples/async-channel-no-receiver.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-channel-no-receiver --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-channel-no-receiver.run}}

Try API

Using the Try API, you can send or receive data from or to a channel without requiring that the operation succeeds, and in non-async contexts.

This API is exposed through Receiver::try_recv and Sender::try_send.

{{#include ../../../../rtic/examples/async-channel-try.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-channel-try --features test-critical-section
{{#include ../../../../rtic/ci/expected/async-channel-try.run}}

Tasks with delay

A convenient way to express miniminal timing requirements is by delaying progression.

This can be achieved by instantiating a monotonic timer (for implementations, see rtic-monotonics):

...
{{#include ../../../../rtic/examples/async-timeout.rs:init}}
        ...

A software task can await the delay to expire:

#[task]
async fn foo(_cx: foo::Context) {
    ...
    Systick::delay(100.millis()).await;
    ...
}
A complete example
{{#include ../../../../rtic/examples/async-delay.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-delay --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-delay.run}}

Interested in contributing new implementations of Monotonic, or more information about the inner workings of monotonics? Check out the Implementing a Monotonic chapter!

Timeout

Rust Futures (underlying Rust async/await) are composable. This makes it possible to select in between Futures that have completed.

A common use case is transactions with an associated timeout. In the examples shown below, we introduce a fake HAL device that performs some transaction. We have modelled the time it takes based on the input parameter (n) as 350ms + n * 100ms.

Using the select_biased macro from the futures crate it may look like this:

{{#include ../../../../rtic/examples/async-timeout.rs:select_biased}}

Assuming the hal_get will take 450ms to finish, a short timeout of 200ms will expire before hal_get can complete.

Extending the timeout to 1000ms would cause hal_get will to complete first.

Using select_biased any number of futures can be combined, so its very powerful. However, as the timeout pattern is frequently used, more ergonomic support is baked into RTIC, provided by the rtic-monotonics and rtic-time crates.

Rewriting the second example from above using timeout_after gives:

{{#include ../../../../rtic/examples/async-timeout.rs:timeout_at_basic}}

In cases where you want exact control over time without drift we can use exact points in time using Instant, and spans of time using Duration. Operations on the Instant and Duration types come from the [fugit] crate.

let mut instant = Systick::now() sets the starting time of execution.

We want to call hal_get after 1000ms relative to this starting time. This can be accomplished by using Systick::delay_until(instant).await.

Then, we define a point in time called timeout, and call Systick::timeout_at(timeout, hal_get(n)).await.

For the first iteration of the loop, with n == 0, the hal_get will take 350ms (and finishes before the timeout).

For the second iteration, with n == 1, the hal_get will take 450ms (and again succeeds to finish before the timeout).

For the third iteration, with n == 2, hal_get will take 550ms to finish, in which case we will run into a timeout.

A complete example
{{#include ../../../../rtic/examples/async-timeout.rs}}
$ cargo run --target thumbv7m-none-eabi --example async-timeout --features test-critical-section 
{{#include ../../../../rtic/ci/expected/async-timeout.run}}

The minimal app

This is the smallest possible RTIC application:

{{#include ../../../../rtic/examples/smallest.rs}}

RTIC is designed with resource efficiency in mind. RTIC itself does not rely on any dynamic memory allocation, thus RAM requirement is dependent only on the application. The flash memory footprint is below 1kB including the interrupt vector table.

For a minimal example you can expect something like:

$ cargo size --example smallest --target thumbv7m-none-eabi --release
Finished release [optimized] target(s) in 0.07s
   text    data     bss     dec     hex filename
    924       0       0     924     39c smallest

Tips & tricks

In this section we will explore common tips & tricks related to using RTIC.

Resource de-structure-ing

Destructuring task resources might help readability if a task takes multiple resources. Here are two examples on how to split up the resource struct:

{{#include ../../../../../rtic/examples/destructure.rs}}
$ cargo run --target thumbv7m-none-eabi --example destructure
{{#include ../../../../../rtic/ci/expected/destructure.run}}

Using indirection for faster message passing

Message passing always involves copying the payload from the sender into a static variable and then from the static variable into the receiver. Thus sending a large buffer, like a [u8; 128], as a message involves two expensive memcpys.

Indirection can minimize message passing overhead: instead of sending the buffer by value, one can send an owning pointer into the buffer.

One can use a global memory allocator to achieve indirection (alloc::Box, alloc::Rc, etc.), which requires using the nightly channel as of Rust v1.37.0, or one can use a statically allocated memory pool like heapless::Pool.

As this example of approach goes completely outside of RTIC resource model with shared and local the program would rely on the correctness of the memory allocator, in this case heapless::pool.

Here's an example where heapless::Pool is used to "box" buffers of 128 bytes.

{{#include ../../../../../rtic/examples/pool.rs}}
$ cargo run --target thumbv7m-none-eabi --example pool
{{#include ../../../../../rtic/ci/expected/pool.run}}

'static super-powers

In #[init] and #[idle] local resources have 'static lifetime.

Useful when pre-allocating and/or splitting resources between tasks, drivers or some other object. This comes in handy when drivers, such as USB drivers, need to allocate memory and when using splittable data structures such as heapless::spsc::Queue.

In the following example two different tasks share a heapless::spsc::Queue for lock-free access to the shared queue.

{{#include ../../../../../rtic/examples/static.rs}}

Running this program produces the expected output.

$ cargo run --target thumbv7m-none-eabi --example static
{{#include ../../../../../rtic/ci/expected/static.run}}

Inspecting generated code

#[rtic::app] is a procedural macro that produces support code. If for some reason you need to inspect the code generated by this macro you have two options:

You can inspect the file rtic-expansion.rs inside the target directory. This file contains the expansion of the #[rtic::app] item (not your whole program!) of the last built (via cargo build or cargo check) RTIC application. The expanded code is not pretty printed by default, so you'll want to run rustfmt on it before you read it.

$ cargo build --example smallest --target thumbv7m-none-eabi
$ rustfmt target/rtic-expansion.rs
$ tail target/rtic-expansion.rs
#[doc = r" Implementation details"]
mod app {
    #[doc = r" Always include the device crate which contains the vector table"]
    use lm3s6965 as _;
    #[no_mangle]
    unsafe extern "C" fn main() -> ! {
        rtic::export::interrupt::disable();
        let mut core: rtic::export::Peripherals = core::mem::transmute(());
        core.SCB.scr.modify(|r| r | 1 << 1);
        rtic::export::interrupt::enable();
        loop {
            rtic::export::wfi()
        }
    }
}

Or, you can use the cargo-expand sub-command. This sub-command will expand all the macros, including the #[rtic::app] attribute, and modules in your crate and print the output to the console.

# produces the same output as before
cargo expand --example smallest | tail

The magic behind Monotonics

Internally, all monotonics use a Timer Queue, which is a priority queue with entries describing the time at which their respective Futures should complete.

Implementing a Monotonic timer for scheduling

The rtic-time framework is flexible because it can use any timer which has compare-match and optionally supporting overflow interrupts for scheduling. The single requirement to make a timer usable with RTIC is implementing the rtic-time::Monotonic trait.

For RTIC 2.0, we assume that the user has a time library, e.g. fugit, as the basis for all time-based operations when implementing Monotonic. These libraries make it much easier to correctly implement the Monotonic trait, allowing the use of almost any timer in the system for scheduling.

The trait documents the requirements for each method. There are reference implementations available in rtic-monotonics that can be used for inspriation.

  • Systick based, runs at a fixed interrupt (tick) rate - with some overhead but simple and provides support for large time spans
  • RP2040 Timer, a "proper" implementation with support for waiting for long periods without interrupts. Clearly demonstrates how to use the TimerQueue to handle scheduling.
  • nRF52 timers implements monotonic & Timer Queue for the RTC and normal timers in nRF52's

Contributing

Contributing new implementations of Monotonic can be done in multiple ways:

  • Implement the trait behind a feature flag in rtic-monotonics, and create a PR for them to be included in the main RTIC repository. This way, the implementations of are in-tree, RTIC can guarantee their correctness, and can update them in the case of a new release.
  • Implement the changes in an external repository. Doing so will not have them included in rtic-monotonics, but may make it easier to do so in the future.

The timer queue

The timer queue is implemented as a list based priority queue, where list-nodes are statically allocated as part of the Future created when await-ing a Future created when waiting for the monotonic. Thus, the timer queue is infallible at run-time (its size and allocation are determined at compile time).

Similarly the channels implementation, the timer-queue implementation relies on a global Critical Section (CS) for race protection. For the examples a CS implementation is provided by adding --features test-critical-section to the build options.

RTIC vs. the world

RTIC aims to provide the lowest level of abstraction needed for developing robust and reliable embedded software.

It provides a minimal set of required mechanisms for safe sharing of mutable resources among interrupts and asynchronously executing tasks. The scheduling primitives leverages on the underlying hardware for unparalleled performance and predictability, in effect RTIC provides in Rust terms a zero-cost abstraction to concurrent real-time programming.

Comparison regarding safety and security

Comparing RTIC to traditional a Real-Time Operating System (RTOS) is hard. Firstly, a traditional RTOS typically comes with no guarantees regarding system safety, even the most hardened kernels like the formally verified seL4 kernel. Their claims to integrity, confidentiality, and availability regards only the kernel itself (under additional assumptions its configuration and environment). They even state:

"An OS kernel, verified or not, does not automatically make a system secure. In fact, any system, no matter how secure, can be used in insecure ways." - seL4 FAQ

Security by design

In the world of information security we commonly find:

  • confidentiality, protecting the information from being exposed to an unauthorized party,
  • integrity, referring to accuracy and completeness of data, and
  • availability, referring to data being accessible to authorized users.

Obviously, a traditional OS can guarantee neither confidentiality nor integrity, as both requires the security critical code to be trusted. Regarding availability, this typically boils down to the usage of system resources. Any OS that allows for dynamic allocation of resources, relies on that the application correctly handles allocations/de-allocations, and cases of allocation failures.

Thus their claim is correct, security is completely out of hands for the OS, the best we can hope for is that it does not add further vulnerabilities.

RTIC on the other hand holds your back. The declarative system wide model gives you a static set of tasks and resources, with precise control over what data is shared and between which parties. Moreover, Rust as a programming language comes with strong properties regarding integrity (compile time aliasing, mutability and lifetime guarantees, together with ensured data validity).

Using RTIC these properties propagate to the system wide model, without interference of other applications running. The RTIC kernel is internally infallible without any need of dynamically allocated data.

RTIC vs. Embassy

Differences

Embassy provides both Hardware Abstraction Layers, and an executor/runtime, while RTIC aims to only provide an execution framework. For example, embassy provides embassy-stm32 (a HAL), and embassy-executor (an executor). On the other hand, RTIC provides the framework in the form of rtic, and the user is responsible for providing a PAC and HAL implementation (generally from the stm32-rs project).

Additionally, RTIC aims to provide exclusive access to resources on as low a level of possible, ideally guarded by some form of hardware protection. This allows for access to hardware while not necessarily requiring locking mechanisms on the software level.

Mixing use of Embassy and RTIC

Since most Embassy and RTIC libraries are runtime agnostic, many details from one project can be used in the other. For example, using rtic-monotonics in an embassy-executor powered project works, and using embassy-sync (though rtic-sync is recommended) in an RTIC project works.

Awesome RTIC examples

See the rtic-rs/rtic/examples repository for complete examples.

Pull-requests are welcome!

Migrating from v1.0.x to v2.0.0

Migrating a project from RTIC v1.0.x to v2.0.0 involves the following steps:

  1. v2.1.0 works on Rust Stable from 1.75 (recommended), while older versions require a nightly compiler via the use of #![type_alias_impl_trait].
  2. Migrating from the monotonics included in v1.0.x to rtic-time and rtic-monotonics, replacing spawn_after, spawn_at.
  3. Software tasks are now required to be async, and using them correctly.
  4. Understanding and using data types provided by rtic-sync.

For a detailed description of the changes, refer to the subchapters.

If you wish to see a code example of changes required, you can check out the full example migration page.

TL;DR (Too Long; Didn't Read)

  1. Instead of spawn_after and spawn_at, you now use the async functions delay, delay_until (and related) with impls provided by rtic-monotonics.
  2. Software tasks must be async fns now. Not returning from a task is allowed so long as there is an await in the task. You can still lock shared resources.
  3. Use rtic_sync::arbiter::Arbiter to await access to a shared resource, and rtic_sync::channel::Channel to communicate between tasks instead of spawn-ing new ones.

Migrating to rtic-monotonics

In previous versions of rtic, monotonics were an integral, tightly coupled part of the #[rtic::app]. In this new version, rtic-monotonics provides them in a more decoupled way.

The #[monotonic] attribute is no longer used. Instead, you use a create_X_token from rtic-monotonics. An invocation of this macro returns an interrupt registration token, which can be used to construct an instance of your desired monotonic.

spawn_after and spawn_at are no longer available. Instead, you use the async functions delay and delay_until provided by ipmlementations of the rtic_time::Monotonic trait, available through rtic-monotonics.

Check out the code example for an overview of the required changes.

For more information on current monotonic implementations, see the rtic-monotonics documentation, and the examples.

Using async softare tasks.

There have been a few changes to software tasks. They are outlined below.

Software tasks must now be async.

All software tasks are now required to be async.

Required changes.

All of the tasks in your project that do not bind to an interrupt must now be an async fn. For example:

#[task(
    local = [ some_resource ],
    shared = [ my_shared_resource ],
    priority = 2
)]
fn my_task(cx: my_task::Context) {
    cx.local.some_resource.do_trick();
    cx.shared.my_shared_resource.lock(|s| s.do_shared_thing());
}

becomes

#[task(
    local = [ some_resource ],
    shared = [ my_shared_resource ],
    priority = 2
)]
async fn my_task(cx: my_task::Context) {
    cx.local.some_resource.do_trick();
    cx.shared.my_shared_resource.lock(|s| s.do_shared_thing());
}

Software tasks may now run forever

The new async software tasks are allowed to run forever, on one precondition: there must be an await within the infinite loop of the task. An example of such a task:

#[task(local = [ my_channel ] )]
async fn my_task_that_runs_forever(cx: my_task_that_runs_forever::Context) {
    loop {
        let value = cx.local.my_channel.recv().await;
        do_something_with_value(value);
    }
}

spawn_after and spawn_at have been removed.

As discussed in the Migrating to rtic-monotonics chapter, spawn_after and spawn_at are no longer available.

Using rtic-sync

rtic-sync provides primitives that can be used for message passing and resource sharing in async context.

The important structs are:

  • The Arbiter, which allows you to await access to a shared resource in async contexts without using lock.
  • Channel, which allows you to communicate between tasks (both async and non-async).

For more information on these structs, see the rtic-sync docs

A complete example of migration

Below you can find the code for the implementation of the stm32f3_blinky example for v1.0.x and for v2.0.0. Further down, a diff is displayed.

v1.0.X

#![allow(unused)]
#![deny(unsafe_code)]
#![deny(warnings)]
#![no_main]
#![no_std]

fn main() {
use panic_rtt_target as _;
use rtic::app;
use rtt_target::{rprintln, rtt_init_print};
use stm32f3xx_hal::gpio::{Output, PushPull, PA5};
use stm32f3xx_hal::prelude::*;
use systick_monotonic::{fugit::Duration, Systick};

#[app(device = stm32f3xx_hal::pac, peripherals = true, dispatchers = [SPI1])]
mod app {
    use super::*;

    #[shared]
    struct Shared {}

    #[local]
    struct Local {
        led: PA5<Output<PushPull>>,
        state: bool,
    }

    #[monotonic(binds = SysTick, default = true)]
    type MonoTimer = Systick<1000>;

    #[init]
    fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {
        // Setup clocks
        let mut flash = cx.device.FLASH.constrain();
        let mut rcc = cx.device.RCC.constrain();

        let mono = Systick::new(cx.core.SYST, 36_000_000);

        rtt_init_print!();
        rprintln!("init");

        let _clocks = rcc
            .cfgr
            .use_hse(8.MHz())
            .sysclk(36.MHz())
            .pclk1(36.MHz())
            .freeze(&mut flash.acr);

        // Setup LED
        let mut gpioa = cx.device.GPIOA.split(&mut rcc.ahb);
        let mut led = gpioa
            .pa5
            .into_push_pull_output(&mut gpioa.moder, &mut gpioa.otyper);
        led.set_high().unwrap();

        // Schedule the blinking task
        blink::spawn_after(Duration::<u64, 1, 1000>::from_ticks(1000)).unwrap();

        (
            Shared {},
            Local { led, state: false },
            init::Monotonics(mono),
        )
    }

    #[task(local = [led, state])]
    fn blink(cx: blink::Context) {
        rprintln!("blink");
        if *cx.local.state {
            cx.local.led.set_high().unwrap();
            *cx.local.state = false;
        } else {
            cx.local.led.set_low().unwrap();
            *cx.local.state = true;
        }
        blink::spawn_after(Duration::<u64, 1, 1000>::from_ticks(1000)).unwrap();
    }
}

}

V2.0.0

#![deny(unsafe_code)]
#![deny(warnings)]
#![no_main]
#![no_std]

use panic_rtt_target as _;
use rtic::app;
use rtic_monotonics::systick::*;
use rtt_target::{rprintln, rtt_init_print};
use stm32f3xx_hal::gpio::{Output, PushPull, PA5};
use stm32f3xx_hal::prelude::*;

#[app(device = stm32f3xx_hal::pac, peripherals = true, dispatchers = [SPI1])]
mod app {
    use super::*;

    #[shared]
    struct Shared {}

    #[local]
    struct Local {
        led: PA5<Output<PushPull>>,
        state: bool,
    }

    #[init]
    fn init(cx: init::Context) -> (Shared, Local) {
        // Setup clocks
        let mut flash = cx.device.FLASH.constrain();
        let mut rcc = cx.device.RCC.constrain();

        // Initialize the systick interrupt & obtain the token to prove that we did
        let systick_mono_token = rtic_monotonics::create_systick_token!();
        Systick::start(cx.core.SYST, 36_000_000, systick_mono_token); // default STM32F303 clock-rate is 36MHz

        rtt_init_print!();
        rprintln!("init");

        let _clocks = rcc
            .cfgr
            .use_hse(8.MHz())
            .sysclk(36.MHz())
            .pclk1(36.MHz())
            .freeze(&mut flash.acr);

        // Setup LED
        let mut gpioa = cx.device.GPIOA.split(&mut rcc.ahb);
        let mut led = gpioa
            .pa5
            .into_push_pull_output(&mut gpioa.moder, &mut gpioa.otyper);
        led.set_high().unwrap();

        // Schedule the blinking task
        blink::spawn().ok();

        (Shared {}, Local { led, state: false })
    }

    #[task(local = [led, state])]
    async fn blink(cx: blink::Context) {
        loop {
            rprintln!("blink");
            if *cx.local.state {
                cx.local.led.set_high().unwrap();
                *cx.local.state = false;
            } else {
                cx.local.led.set_low().unwrap();
                *cx.local.state = true;
            }
            Systick::delay(1000.millis()).await;
        }
    }
}

A diff between the two projects

Note: This diff may not be 100% accurate, but it displays the important changes.

#![no_main]
 #![no_std]
 
 use panic_rtt_target as _;
 use rtic::app;
 use stm32f3xx_hal::gpio::{Output, PushPull, PA5};
 use stm32f3xx_hal::prelude::*;
-use systick_monotonic::{fugit::Duration, Systick};
+use rtic_monotonics::Systick;
 
 #[app(device = stm32f3xx_hal::pac, peripherals = true, dispatchers = [SPI1])]
 mod app {
@@ -20,16 +21,14 @@ mod app {
         state: bool,
     }
 
-    #[monotonic(binds = SysTick, default = true)]
-    type MonoTimer = Systick<1000>;
-
     #[init]
     fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {
         // Setup clocks
         let mut flash = cx.device.FLASH.constrain();
         let mut rcc = cx.device.RCC.constrain();
 
-        let mono = Systick::new(cx.core.SYST, 36_000_000);
+        let mono_token = rtic_monotonics::create_systick_token!();
+        let mono = Systick::start(cx.core.SYST, 36_000_000, mono_token);
 
         let _clocks = rcc
             .cfgr
@@ -46,7 +45,7 @@ mod app {
         led.set_high().unwrap();
 
         // Schedule the blinking task
-        blink::spawn_after(Duration::<u64, 1, 1000>::from_ticks(1000)).unwrap();
+        blink::spawn().unwrap();
 
         (
             Shared {},
@@ -56,14 +55,18 @@ mod app {
     }
 
     #[task(local = [led, state])]
-    fn blink(cx: blink::Context) {
-        rprintln!("blink");
-        if *cx.local.state {
-            cx.local.led.set_high().unwrap();
-            *cx.local.state = false;
-        } else {
-            cx.local.led.set_low().unwrap();
-            *cx.local.state = true;
-        blink::spawn_after(Duration::<u64, 1, 1000>::from_ticks(1000)).unwrap();
-    }
+    async fn blink(cx: blink::Context) {
+        loop {
+            // A task is now allowed to run forever, provided that
+            // there is an `await` somewhere in the loop.
+            SysTick::delay(1000.millis()).await;
+            rprintln!("blink");
+            if *cx.local.state {
+                cx.local.led.set_high().unwrap();
+                *cx.local.state = false;
+            } else {
+                cx.local.led.set_low().unwrap();
+                *cx.local.state = true;
+            }
+        }
+    }
 }

Under the hood

This is chapter is currently work in progress, it will re-appear once it is more complete

This section describes the internals of the RTIC framework at a high level. Low level details like the parsing and code generation done by the procedural macro (#[app]) will not be explained here. The focus will be the analysis of the user specification and the data structures used by the runtime.

We highly suggest that you read the embedonomicon section on concurrency before you dive into this material.

Target Architecture

While RTIC can currently target all Cortex-m devices there are some key architecture differences that users should be aware of. Namely, the absence of Base Priority Mask Register (BASEPRI) which lends itself exceptionally well to the hardware priority ceiling support used in RTIC, in the ARMv6-M and ARMv8-M-base architectures, which forces RTIC to use source masking instead. For each implementation of lock and a detailed commentary of pros and cons, see the implementation of lock in src/export.rs.

These differences influence how critical sections are realized, but functionality should be the same except that ARMv6-M/ARMv8-M-base cannot have tasks with shared resources bound to exception handlers, as these cannot be masked in hardware.

Table 1 below shows a list of Cortex-m processors and which type of critical section they employ.

Table 1: Critical Section Implementation by Processor Architecture

ProcessorArchitecturePriority CeilingSource Masking
Cortex-M0ARMv6-Mβœ“
Cortex-M0+ARMv6-Mβœ“
Cortex-M3ARMv7-Mβœ“
Cortex-M4ARMv7-Mβœ“
Cortex-M7ARMv7-Mβœ“
Cortex-M23ARMv8-M-baseβœ“
Cortex-M33ARMv8-M-mainβœ“

Priority Ceiling

This is covered by the Resources page of this book.

Source Masking

Without a BASEPRI register which allows for directly setting a priority ceiling in the Nested Vectored Interrupt Controller (NVIC), RTIC must instead rely on disabling (masking) interrupts. Consider Figure 1 below, showing two tasks A and B where A has higher priority but shares a resource with B.

Figure 1: Shared Resources and Source Masking

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚                                                                β”‚
  β”‚                                                                β”‚
3 β”‚                   Pending    Preempts                          β”‚
2 β”‚             ↑- - -A- - - - -↓A─────────►                       β”‚
1 β”‚          B───────────────────► - - - - B────────►              β”‚
0 β”‚Idleβ”Œβ”€β”€β”€β”€β”€β–Ί                             Resumes  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β–Ί     β”‚
  β”œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚                                                                β”‚
  └────────────────────────────────────────────────────────────────┴──► Time
                t1    t2        t3         t4

At time t1, task B locks the shared resource by selectively disabling (using the NVIC) all other tasks which have a priority equal to or less than any task which shares resources with B. In effect this creates a virtual priority ceiling, mirroring the BASEPRI approach. Task A is one such task that shares resources with task B. At time t2, task A is either spawned by task B or becomes pending through an interrupt condition, but does not yet preempt task B even though its priority is greater. This is because the NVIC is preventing it from starting due to task A being disabled. At time t3, task B releases the lock by re-enabling the tasks in the NVIC. Because task A was pending and has a higher priority than task B, it immediately preempts task B and is free to use the shared resource without risk of data race conditions. At time t4, task A completes and returns the execution context to B.

Since source masking relies on use of the NVIC, core exception sources such as HardFault, SVCall, PendSV, and SysTick cannot share data with other tasks.