Hard-Real-Time Embedded in Rust
The Rust programming language is experiencing rapid adoption across the software industry. In this talk, we'll explore the features that make Rust especially suitable for hard-real-time embedded applications. We'll see that Rust's unique approaches to memory management and asynchronous programming provide bare-metal Rust with nearly the same capabilities as a real-time operating system. The developer experience is further improved by Rust's approach to error handling, its package management system, and its interoperability with C and C++. I'll review the major Rust embedded projects under active development, including Embassy, RTIC, and Hubris. The talk will close with recommendations for developers considering the use of Rust in their own real-time hardware projects.
What this presentation is about and why it matters
What does it take to use Rust in embedded systems when hard real-time requirements and existing C and C++ code are in play? David Lawrence approaches this question with a practical comparison of language tradeoffs, then moves into a guided tour of the Rust embedded ecosystem. He also shares his findings from an evaluation of Rust against other options on an actual hardware project.
Who will benefit the most from this presentation
- Firmware engineers who are considering Rust but want to learn more about it
- Teams maintaining C or C++ code who are curious about incremental Rust interoperability
- Engineers comparing bare metal, RTOS-based, and async approaches for device software
- Developers choosing between microcontroller platforms and looking at ecosystem support first
What you need to know
A basic familiarity with embedded development will help, especially these ideas:
- C, C++, and the idea of an RTOS
- What a microcontroller firmware stack typically includes
- Build and debug tooling for embedded targets
Glossary (terms used in this talk)
- RTOS (Real-Time Operating System): An operating system designed to provide predictable timing behavior for real-time applications.
- ABI compatibility: Two components are ABI-compatible when they can link and call each other using the same binary interface. This allows code written in different languages to interoperate without rewriting both sides.
- Executor: An executor is the runtime component that schedules and polls asynchronous tasks. Different executors can run the same async code if they follow the same contract.
- Cooperative multitasking: Multiple tasks share execution by yielding control explicitly rather than being preempted by a scheduler. It is often paired with async code on resource-constrained systems.
- Preemptive multitasking: A scheduler can interrupt one task and switch to another, which helps enforce timing and isolation between tasks. It is commonly associated with operating systems and RTOS designs.
- Ownership: A resource-management model where a value has a single owner at a time, and moves transfer responsibility rather than copying ownership implicitly. This helps make lifetime and aliasing rules explicit in code.
- Borrowing: A way to access data without taking ownership of it, usually through references with a limited scope. Borrowing is used to express safe shared or temporary access while preserving compile-time guarantees.
- Result (Rust): The built-in Rust enum type used for error handling; it is generic over an Ok value type and an Err error type and is used pervasively instead of exceptions.
Toolbox (mentioned in this talk)
- ESP32: A low-cost family of Wi-Fi and Bluetooth-enabled microcontrollers widely used for embedded networking and real-time control. It includes integrated wireless connectivity and is supported by a broad software ecosystem.
- ARM Cortex-M: A family of 32-bit ARM microcontroller cores widely used in embedded systems for real-time control, low-power applications, and general-purpose embedded computing.
- Cargo: Rust's package manager and build tool, used to manage dependencies, build projects, and run tooling in a consistent workflow. It is tightly integrated with the Rust ecosystem.
- Embassy: A Rust embedded framework centered on async execution for bare-metal systems. It also includes common embedded building blocks such as networking, USB, peripheral access, and hardware abstraction layers.
- RTIC: A Rust concurrency framework for interrupt-driven embedded systems. It uses interrupt priorities and compile-time analysis to support low-latency, preemptive workflows without a kernel.
- Hubris: An embedded operating system focused on static resource allocation and compile-time definition of tasks and memory regions. It aims to combine RTOS structure with Rust's safety guarantees.
Final thoughts
Practical and comparative, with a strong bias toward what actually happened on hardware, this talk gives you a useful lens for judging Rust in embedded work. The value is less a slogan about language choice and more a framework for thinking about ecosystem fit, integration, and the tradeoffs between bare metal and RTOS-style designs. It will help firmware engineers, robotics teams, and anyone weighing a gradual move from C or C++ to Rust. The overall feel is cautious optimism grounded in real experience.
This overview is AI-generated from the session transcript. Spot an issue? Let us know.
Unfortunately the details of the study are not public. I can share that everyone writing firmware here has gotten over the learning curve and never wants to go back to C/C++!
Does Rust provide hooks to detect hard real time violations in run-time? I missed this in talk if presented.
It depends on the library being used, as task scheduling is library-dependent rather than a core language feature.
RTIC uses preemptive scheduling via the interrupt servicing hardware, so real-time violations are inherently not possible. There is some ongoing academic work about automating the worst-case execution time analysis, e.g.
https://www.diva-portal.org/smash/get/diva2:1652205/FULLTEXT01.pdf
Embassy (and other async executors) are entirely cooperative, so they cannot provide any real-time guarantees for their async tasks.
I'm not familiar with the scheduling options provided by Hubris and other Rust RTOSes.
Cheers,
David
You mentioned Rust working with nRF devices. How would would I get started running Rust on an nRF device? I am curious to try that as an alternative to the Zephyr/nRF SDK environment.
The embassy_nrf HAL documentation could be a good starting point. It includes links to some example applications for various nRF parts.
https://docs.embassy.dev/embassy-nrf/0.9.0/nrf51/index.html
I also found this Youtube video titled "Nordic nRF52840 Rust Embassy Tutorial: Getting Started from Scratch", which I have not watched in full, but from skimming a few minutes it looks like good and accurate content to me.
https://www.youtube.com/watch?v=_GnU1bThTpc
Cheers,
David
A lot of this EOC is focused on Agentic AI, how well is Rust represented in that community? I don't have enough background in either to even begin to categorize a decision tree.








Is there more data available on the Motor Driver study case? Execution time analysis? Binary sizes? Or some metric on how did it help the team?
Very helpful overview of the ecosystem also, thanks!