Embassy: Async Rust Framework for Embedded Systems Without an RTOS

What Embassy is and who it is for

Embassy is a framework for embedded applications written in Rust, built around the language's async/await facility. The README describes it as the next-generation framework for embedded applications, positioning it as an alternative to traditional real-time operating systems. The target audience is embedded developers who want memory safety, compile-time bug detection, and efficient multitasking without a kernel. Rust catches memory and thread safety bugs at compile time through its type system, which addresses a class of bugs that are common in embedded C code. Embassy adds to Rust's safety guarantees by handling the parts of embedded development that typically require an RTOS: task scheduling, hardware timers, networking, USB, and bootloading. The project is hosted at embassy.dev and the Matrix channel #embassy-rs:matrix.org is the official support community.

How async/await replaces RTOS context switching

A traditional RTOS runs tasks on separate stacks and uses kernel context switching to move between them. Each task requires a dedicated stack allocation, and the kernel must save and restore CPU registers on every switch. Embassy takes a different approach: the Rust compiler transforms async tasks into state machines at compile time. All tasks share a single stack, and no dynamic memory allocation is required. The async executor runs tasks cooperatively; when a task awaits a timer or an IO event, the executor picks up the next ready task without a kernel switch. According to the README, this approach is faster and smaller than a traditional RTOS. Multi-priority execution is available: multiple executors can run at different priorities, so higher-priority tasks preempt lower-priority ones through interrupt-based executor nesting, not kernel context switching.

The HAL catalog: hardware support across chip families

Embassy maintains HALs for several microcontroller families directly. embassy-stm32 covers all STM32 families. embassy-nrf covers the Nordic Semiconductor nRF52, nRF53, nRF54, and nRF91 series. embassy-rp covers the Raspberry Pi RP2040 and RP235x. embassy-mspm0 covers Texas Instruments MSPM0. embassy-mcxa covers the NXP MCX-A series. For Espressif ESP32 chips, Async Wi-Fi, Bluetooth, and ESP-NOW support is developed in the esp-rs/esp-hal repository rather than in the Embassy repository itself. Additional community-maintained HALs cover WCH CH32 RISC-V chips, Microchip PolarFire SoC, Puya PY32 series, and Renesas RA family. The README states that HALs from other projects can also be used with Embassy, making the executor and library components independent of the official HAL set.

Writing and running an Embassy application

An Embassy task is declared with the #[embassy_executor::task] attribute and an async function signature. The task body calls .await on timers, I/O events, and other async operations without blocking other tasks. The README includes a blink example for the nRF52840 that demonstrates globally available timers: the led.set_high() and led.set_low() calls are separated by Timer::after_millis(150).await, which pauses the task for 150 milliseconds without blocking the executor. To run the examples, install probe-rs (the flashing and debugging tool) and navigate to the example directory:

cd examples/nrf52840

Then build and flash with:

cargo run --release --bin blinky

The Cargo.toml for each example directory must set the correct chip feature flag. The README notes that an incorrect chip name causes the example to fail or crash immediately after being programmed. Examples are organized by chip manufacturer: nrf52840, nrf5340, stm32 variants, rp, and a std directory for running locally on a PC.

Built-in libraries beyond the executor: time, networking, USB, Bluetooth, and boot

Embassy ships several libraries alongside the HALs. embassy-time provides globally available Instant, Duration, and Timer types that the README says never overflow, removing the need for per-task timer management. embassy-net implements Ethernet, IP, TCP, UDP, ICMP, and DHCP; the async model simplifies managing timeouts and concurrent connections. embassy-usb implements a device-side USB stack with CDC ACM (USB serial) and USB HID classes, plus a builder API for custom classes. embassy-boot is a lightweight bootloader that handles firmware application upgrades in a power-fail-safe way, with trial boots and automatic rollbacks if the new firmware fails. Bluetooth Low Energy is provided through the trouble crate for nRF52, nRF54, RP2040, RP235x, ESP32, and serial controllers. LoRa and LoRaWAN support comes from the external lora-rs project.

Limitations: Rust learning curve and chip feature flag configuration

The primary limitation for teams coming from C is the Rust learning curve. Rust's ownership, borrowing, and lifetime system requires a significant investment to use correctly. Embassy's use of async adds a second layer of complexity: users must understand both Rust's memory model and the async executor's cooperative model before debugging non-trivial programs. The chip feature flag is a practical constraint: Cargo.toml for each example must name the exact chip. The README explicitly warns that an incorrect chip name causes the example to fail or crash immediately after being programmed. There are no GitHub releases for the Embassy repository; the project distributes via crates.io for the individual library crates. The repository has no single release that covers all libraries. The last push to the repository was on 2026-09-27, reflecting active development.

Embassy versus FreeRTOS: async state machines versus kernel context switching

FreeRTOS is a widely used open source RTOS written in C. It runs tasks on separate stacks, uses kernel context switching to move between tasks, and requires the developer to configure a stack size for each task at creation time. On small microcontrollers, choosing the wrong stack size leads to stack overflow or wasted RAM. Embassy eliminates this problem: all tasks share a single stack and the compiler manages the state machine transitions. FreeRTOS uses preemptive scheduling; Embassy tasks are cooperative within a priority level and preemptive across priority levels via multiple executors. FreeRTOS has a larger ecosystem of existing C libraries and vendor SDKs. Embassy has better integration with Rust's type system for memory safety, but requires the entire application to be written in Rust. A team with a large existing C codebase will find FreeRTOS easier to adopt; a team starting a new embedded project with Rust should consider Embassy as the default choice for the scheduling and hardware abstraction layer.

Editorial conclusion

Embassy is the right choice for embedded developers who already know Rust, or who are willing to learn it, and who want to avoid the overhead of an RTOS while keeping code-level multitasking. The chip feature flag in Cargo.toml must be set correctly for the target before running cargo run; using the wrong flag causes examples to fail at flash time. Developers coming from C or C++ who are not ready for Rust's ownership model will find FreeRTOS a more direct path to the same hardware targets.

Frequently asked questions

Official sources

1. embassy-rs/embassy on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README