6 releases (3 stable)

1.5.0 Jan 10, 2024
1.4.1 Dec 6, 2023
1.3.0 Nov 22, 2023
1.2.0 Sep 19, 2023
1.0.0-alpha.2 Apr 23, 2023

#1075 in Concurrency

Download history 224/week @ 2023-11-01 252/week @ 2023-11-08 199/week @ 2023-11-15 327/week @ 2023-11-22 375/week @ 2023-11-29 417/week @ 2023-12-06 223/week @ 2023-12-13 172/week @ 2023-12-20 154/week @ 2023-12-27 201/week @ 2024-01-03 633/week @ 2024-01-10 449/week @ 2024-01-17 773/week @ 2024-01-24 561/week @ 2024-01-31 2350/week @ 2024-02-07 1005/week @ 2024-02-14

4,811 downloads per month
Used in 2 crates


1.5K SLoC

Real-Time Interrupt-driven Concurrency

The hardware accelerated Rust RTOS

A concurrency framework for building real-time systems.

crates.io docs.rs book matrix Meeting notes


  • Tasks as the unit of concurrency [^1]. Tasks can be event triggered (fired in response to asynchronous stimuli) or spawned by the application on demand.

  • Message passing between tasks. Specifically, messages can be passed to software tasks at spawn time.

  • A timer queue [^2]. Software tasks can be delayed or scheduled to continue running at some time in the future. This feature can be used to implement periodic tasks.

  • Support for prioritization of tasks and, thus, preemptive multitasking.

  • Efficient and data race free memory sharing through fine-grained priority based critical sections [^1].

  • Deadlock free execution guaranteed at compile time. This is a stronger guarantee than what's provided by the standard Mutex abstraction.

  • Minimal scheduling overhead. The task scheduler has minimal software footprint; the hardware does the bulk of the scheduling.

  • Highly efficient memory usage: All the tasks share a single call stack and there's no hard dependency on a dynamic memory allocator.

  • All Cortex-M devices are fully supported.

  • This task model is amenable to known WCET (Worst Case Execution Time) analysis and scheduling analysis techniques.

User documentation

Documentation for the development version.

API reference

Community provided examples repo


Join us and talk about RTIC in the Matrix room.

Weekly meeting minutes can be found over at RTIC HackMD


New features and big changes should go through the RFC process in the dedicated RFC repository.

Running tests locally

To check all Run-pass tests locally on your thumbv6m-none-eabi or thumbv7m-none-eabi target device, run

$ cargo xtask --target <your target>
#                       ˆˆˆˆˆˆˆˆˆˆˆˆ
#                   e.g. thumbv7m-none-eabi


This crate is based on the Real-Time For the Masses language created by the Embedded Systems group at Luleå University of Technology, led by Prof. Per Lindgren.


[^1]: Eriksson, J., Häggström, F., Aittamaa, S., Kruglyak, A., & Lindgren, P. (2013, June). Real-time for the masses, step 1: Programming API and static priority SRP kernel primitives. In Industrial Embedded Systems (SIES), 2013 8th IEEE International Symposium on (pp. 110-113). IEEE.

[^2]: Lindgren, P., Fresk, E., Lindner, M., Lindner, A., Pereira, D., & Pinho, L. M. (2016). Abstract timers and their implementation onto the arm cortex-m family of mcus. ACM SIGBED Review, 13(1), 48-53.


All source code (including code snippets) is licensed under either of

at your option.

The written prose contained within the book is licensed under the terms of the Creative Commons CC-BY-SA v4.0 license (LICENSE-CC-BY-SA or https://creativecommons.org/licenses/by-sa/4.0/legalcode).


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be licensed as above, without any additional terms or conditions.


In-tree implementations of the rtic_time::Monotonic (reexported) trait for timers & clocks found on commonly used microcontrollers.

To enable the implementations, you must enable a feature for the specific MCU you're targeting.

Cortex-M Systick

The systick monotonic works on all cortex-M parts, and requires that the feature cortex-m-systick is enabled.


The RP2040 monotonics require that the rp2040 feature is enabled.


The i.MX RT monotonics require that the feature imxrt_gpt1 or imxrt_gpt2 is enabled.


nRF monotonics require that one of the available nrf52* features is enabled.

All implementations of timers for the nRF52 family are documented here. Monotonics that are not available on all parts in this family will have an Available on crate features X only tag, describing what parts do support that monotonic. Monotonics without an Available on crate features X only tag are available on any nrf52* feature.


~2M SLoC