Real-Time Interrupt-driven Concurrency (RTIC)

RTIC is a hardware-accelerated concurrency framework for building real-time systems in Rust. It provides a model for managing tasks, prioritization, and memory sharing with minimal software overhead by leveraging hardware features for scheduling.

Key characteristics include:

• Deadlock-free execution: Guaranteed at compile time.
• Efficient memory usage: All tasks share a single call stack, and there is no hard dependency on a dynamic memory allocator.
• Preemptive multitasking: Supported through task prioritization.
• Data race free memory sharing: Achieved through fine-grained, priority-based critical sections.

RTIC (Real-Time Interrupt-driven Concurrency) is a concurrency framework for building real-time systems. It is often described as a hardware-accelerated RTOS because it leverages hardware interrupt controllers (like the NVIC on Cortex-M or CLIC on RISC-V) to perform scheduling instead of using a traditional software kernel.

Key characteristics:

• Hardware Accelerated: Uses existing hardware interrupt mechanisms for scheduling.
• Concurrency Framework: Relies on external Hardware Abstraction Layers (HALs) and has no software kernel.
• SRP-based: Built on the Stack Resource Policy (SRP) for efficient, deadlock-free resource management.

A software task can be defined with a divergent return type: async fn task_name(cx: task_name::Context, ...) -> !.

Advantages of divergent tasks (-> !):

• Static Lifetimes: They receive a 'static context, and local resources have a 'static lifetime.
• Explicit Intent: It clearly distinguishes tasks intended to run indefinitely from short-lived tasks.

Warning: You must ensure the task yields control using .await to avoid starving other tasks at the same priority level.

This example demonstrates how to manage hardware resources in RTIC using local and shared resource patterns:

• Local Resources: The Potentiometer struct (holding the analog pin PA1) is assigned as a local resource to the EXTI0 hardware task. Local resources are owned exclusively by a single task, providing efficient, lock-free access.
• Shared Resources: The Adc<ADC1> instance is assigned as a shared resource. This allows multiple tasks to access the single ADC module present on the microcontroller, requiring RTIC's resource management (locks) to ensure safe concurrent access.

When the schedule API is used in RTIC, the internal implementation of spawn is modified to track task baselines. The system uses an INSTANTS buffer to store the specific time at which a task was scheduled to run.

This Instant is captured during the spawn process and is subsequently passed to the task dispatcher. The dispatcher reads this value from the buffer and provides it to the user-defined task code as part of the task's Context.

The timer queue is a priority queue (implemented as a min-heap) that stores tasks sorted by their earliest scheduled time.

1. Scheduling: When schedule is called, the task and its execution Instant are added to the TimerQueue. If the new task is now the earliest, the SysTick interrupt is immediately pended.
2. SysTick Handler: The SysTick interrupt performs two roles:
   • It dequeues tasks from the TimerQueue that have reached their scheduled time and moves them into their respective ready queues.
   • It sets up a new timeout interrupt to fire when the next task in the queue is due.
3. Task Execution: Once a task is in a ready queue, the task dispatcher is triggered to run it at its assigned priority.

When working in an async context within RTIC, you can use the rtic-sync crate to handle communication and shared state without relying on traditional blocking lock mechanisms.

Key primitives include:

• Arbiter: Allows you to await access to a shared resource in an async context. This provides a way to manage resource contention without using the standard RTIC lock method, which is typically used in non-async tasks.
• Channel: Enables message passing between tasks. It is compatible with both async and non-async tasks, making it a versatile tool for inter-task communication.

RTIC v2 async software tasks are permitted to run forever (e.g., using a loop {}). However, you must satisfy one precondition: there must be an .await point within the infinite loop. This ensures the task yields control and allows the executor to run other tasks.

Commonly, this is achieved by awaiting a value from a channel or a timer.

#[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);
    }
}