HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
embassy-rs
embassy
Rust2021–2026
embassy-rs / embassy

embassy

Modern embedded framework, using Rust and async.

33Distinct people
33Mentions
0Explicit recommenders
10.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Modern embedded framework, using Rust and async.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year33 dated mentions

Observed mentions: 2021-05-06 19:44:33 UTC to 2026-10-24 21:12:22 UTC.

02462021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC514
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC716
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC615
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC615
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC615

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
Embassy Embassy is the next-generation framework for embedded applications. Write safe, correct, and energy-efficient embedded code faster, using the Rust programming language, its async facilities, and the Embassy libraries. Documentation - API reference - Website - Chat Rust + async ❤️ embedded The Rust programming language is blazingly fast and memory-efficient, with no runtime, garbage collector, or OS. It catches a wide variety of bugs at compile time, thanks to its full memory- and thread-safety, and expressive type system. Rust's async/await allows for unprecedentedly easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is faster and smaller than one! Batteries included Hardware Abstraction Layers HALs implement safe, idiomatic Rust APIs to use the hardware capabilities, so raw register manipulation is not needed. The Embassy project maintains HALs for select hardware, but you can still use HALs from other projects with Embassy. embassy-stm32, for all STM32 microcontroller families. embassy-nrf, for the Nordic Semiconductor nRF52, nRF53, nRF54 and nRF91 series. embassy-rp, for the Raspberry Pi RP2040 and RP23xx microcontrollers. embassy-mspm0, for the Texas Instruments MSPM0 microcontrollers. embassy-mcxa, for NXP's MCX-A series of microcontrollers. esp-rs, for the Espressif Systems ESP32 series of chips. Embassy HAL support for Espressif chips, as well as Async Wi-Fi, Bluetooth, and ESP-NOW, is being developed in the esp-rs/esp-hal repository. ch32-hal, for the WCH 32-bit RISC-V(CH32V) series of chips. mpfs-hal, for the Microchip PolarFire SoC. py32-hal, for the Puya Semiconductor PY32 series of microcontrollers. ra-hal, for the Renesas RA family of microcontrollers. Time that Just Works - No more messing with hardware timers. embassy_time provides Instant, Duration, and Timer types that are globally available and never overflow. Real-time ready - Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones. See the example. Low-power ready - Easily build devices with years of battery life. The async executor automatically puts the core to sleep when there's no work to do. Tasks are woken by interrupts, there is no busy-loop polling while waiting. Networking - The embassy-net network stack implements extensive networking functionality, including Ethernet, IP, TCP, UDP, ICMP, and DHCP. Async drastically simplifies managing timeouts and serving multiple connections concurrently. embassy-ptp-driver provides a network-stack-independent interface for reading and adjusting PTP hardware clocks. Bluetooth The trouble crate provides a Bluetooth Low Energy 4.x and 5.x Host that runs on any microcontroller implementing the bt-hci traits (currently nRF52, nrf54, rp2040, rp23xx and esp32 and serial controllers are supported). The nrf-softdevice crate provides Bluetooth Low Energy 4.x and 5.x support for nRF52 microcontrollers. The embassy-stm32-wpan crate provides Bluetooth Low Energy 5.x support for stm32wb microcontrollers. LoRa - The lora-rs project provides an async LoRa and LoRaWAN stack that works well on Embassy. USB - embassy-usb implements a device-side USB stack. Implementations for common classes such as USB serial (CDC ACM) and USB HID are available, and a rich builder API allows building your own. Bootloader and DFU - embassy-boot is a lightweight bootloader supporting firmware application upgrades in a power-fail-safe way, with trial boots and rollbacks. Sneak peek use defmt::info; use embassy_executor::Spawner; use embassy_time::{Duration, Timer}; use embassy_nrf::gpio::{AnyPin, Input, Level, Output, OutputDrive, Pin, Pull}; use embassy_nrf::{Peri, Peripherals}; // Declare async tasks #[embassy_executor::task] async fn blink(pin: Peri<'static, AnyPin>) { let mut led = Output::new(pin, Level::Low, OutputDrive::Standard); loop { // Timekeeping is globally available, no need to mess with hardware timers. led.set_high(); Timer::after_millis(150).await; led.set_low(); Timer::after_millis(150).await; } } // Main is itself an async task as well. #[embassy_executor::main] async fn main(spawner: Spawner) { let p = embassy_nrf::init(Default::default()); // Spawned tasks run in the background, concurrently. spawner.spawn(blink(p.P0_13.into()).unwrap()); let mut button = Input::new(p.P0_11, Pull::Up); loop { // Asynchronously wait for GPIO events, allowing other tasks // to run, or the core to sleep. button.wait_for_low().await; info!("Button pressed!"); button.wait_for_high().await; info!("Button released!"); } } Examples Examples are found in the examples/ folder separated by the chip manufacturer they are designed to run on. For example: examples/nrf52840 run on the nrf52840-dk board (PCA10056) but should be easily adaptable to other nRF52 chips and boards. examples/nrf5340 run on the nrf5340-dk board (PCA10095). examples/stm32xx for the various STM32 families. examples/rp are for the RP2040 and RP235x chips. examples/mcxa266 run on the FRDM-MCXA266 board. examples/mcxa577 run on the FRDM-MCXA577 board. examples/std are designed to run locally on your PC. Running examples Install probe-rs following the instructions at https://probe.rs. Change directory to the sample's base directory. For example: cd examples/nrf52840 Ensure Cargo.toml sets the right feature for the name of the chip you are programming. If this name is incorrect, the example may fail to run or immediately crash after being programmed. Ensure .cargo/config.toml contains the
Read the full README on GitHub

What Hacker News says

33 sources
I don't use the the builtin testing framework, or std, and I often explicitly use a no-heap crate. Check out Embassy and you'll be free to ignore pretty almost everything suggested here, especially when developing and testing. I create a separate [bin] for each test (I usually run out of flash to fit all the tests into a single binary), and a few lines of bash/python to make a test runner/reporter for all the flashing and running of tests. Sometimes I flash up to 50 times a day and haven't lost an MCU (AVR-Rust, ESP-Rust, STM-Rust) yet due to too many writes. [0] https://github.com/embassy-rs/embassy
In The Rust on ESP Book
I'm intrigued! I was fighting deadlocks in some Java code this week, and I'm working on a Rust project to maybe replace some of that. One thing I didn't see in the post or the repo: does this work with async code? I couldn't find the "search" button on Codeberg, and tests/integration.rs didn't have any async. For embedded, I have had my eye on https://github.com/embassy-rs/embassy (which has an async runtime for embedded) and would love a nice locking crate to go with it.
In Surelock: Deadlock-Free Mutexes for Rust
It's really not so different! In embassy, DMA transfers and interrupts become things that you can .await on, the process is basically: * The software starts a transaction, or triggers some event (like putting data in the fifo) * The software task yields * When the "fifo empty" interrupt or "dma transfer done interrupt" occurs, it wakes the task to resume * the software task checks if it is done, and either reloads/restarts if there's more to do, or returns "done" It's really not different than event driven state machines you would have written before, it's just "in-band" of the language now, and async/await gives you syntax to do it. Even if you don't know Rust, I'd suggest poking around at some of the examples here: https://github.com/embassy-rs/embassy/tree/main/examples And if you want, look into the code behind it.
In Go on Embedded Systems and WebAssembly
(Embassy dev here) You can get preemptive scheduling of async tasks with InterruptExecutor. You create one executor for each priority level, then spawn the tasks in the right one. The latency of the executor and the compiler-generated async state machines is predictable, so you can use Embassy for hard real-time work. See example: https://github.com/embassy-rs/embassy/blob/main/examples/nrf... Additionally the executor has support for scheduling tasks by priority or deadline within a single priority level. (in latest git, will be in next crates.io release)
In Embassy: Modern embedded framework, using Rust and async
FWIW teaching it critical sections is dead simple, and likely already done for you. Ex cortex M: https://github.com/rust-embedded/cortex-m/blob/master/cortex... You can look at asynch and things like https://github.com/rtic-rs/rtic and https://github.com/embassy-rs/embassy for common embedded patterns. You handle DMA the same way as on any other system - e.x. you mark the memory as system/uncached (and pin it if you have virtual memory on), you use memory barriers when you are told data has arrived to get the memory controller up to speed with what happened behind its back, and so on. You’re still writing the same code that controls the hardware in the same way, nothing about that is especially different in C vs Rust. I think there is very much a learning curve, and that friction is real - hiring people and teaching them Rust is harder th
Read the rest
an just hiring C devs. People on HN tend to take this almost like a religious question - “how could you dare to write memory unsafe code in 2025? You’re evil!” But pragmatically this is a real concern.
In Rust in the kernel is no longer experimental
TL;DR: No. Maybe? Depends. It's probably reasonable to make a distinction between "Real Time" desktop/server OS (on CPUs) vs "Real Time" embedded hardware OS (on MCUs). (Even aside from any hard-/soft- real time distinction.) On the embedded side, in addition to FreeRTOS (upon which Pebble OS is built), I'm aware of others with reasonably high profile such as: * Zephyr (Linux Foundation, C): https://en.wikipedia.org/wiki/Zephyr_(operating_system) * NuttX (Apache Software Foundation, C & C++): https://en.wikipedia.org/wiki/NuttX In addition, there's also some "up & coming" Rust language projects which fall somewhere along the "framework" to "OS" spectrum (in part, via https://arewertosyet.com): * Tock: https://github.com/tock/tock * Embassy: https://github.com/embassy-rs/embassy * Hubris: https://hubris.oxide.computer On the desktop side,
Read the rest
I seem to recall in the past, OS such as BeOS & QNX have been presented as a possible future for real time desktop OS that hasn't arrived. As someone else already mentioned, PREEMPT_RT being merged for Linux is a recent development somewhat in this space which could have impact on both desktop & "embedded" situations but suitability varies dependent on, say, whether you're wanting to use it for audio production versus controlling some 10 tonne robot operating next to humans. Hope this at least goes some way to answering your question. :)
In Google open-sources the Pebble OS

Showing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.