I am a big fan of the embassy project and it’s a great example of why async Rust is so great: Because this is possible. It works without a heap, is a really low cost abstraction and you can do stuff concurrently on a single core chip (where you can’t just spawn a new “thread”) and you don’t have the complexity of an RTOS. I believe there is a great future for embassy ahead and it’s so great how far the team has come.
Rust embedded was really never actually better then C or C++ but embassy for me is a big reason why I now make my buying decision based on how well I can use Rust on the MCU.
Nordic nrf series of chips are ubiquitous, cheap, really well documented and have very good support for the Bluetooth side of things in embassy.
If you don't need any of the wireless radio stuff, I think the raspberry pi microcontroller family is also ridiculously well supported in rust and it's possible to get one of the newer raspberry pi microcontroller is complete with ethernet and several megs of flash for not even 10 bucks.
STM is popular because their lineup is cheap, offers a lot of features, and the documentation is readily available. The flip side is that their errata is lengthy, the Rust HAL is complex to support lots of different designs under the same product names, the documentation from STM is poorly organized and spread out over a zillion different documents, and Mac compatibility needs a gigantic asterisk. You can also get a BlackPill (get the F411 version with 8MB flash) off of AliExpress for $0.99 from WeAct's official store. Unlike STM's own dev boards (Nucleo) you'll need a separate debug probe. Nucleos that'll give you a lot of breathing room can be had for $10-15.
RP is also cheap and has that pretty sweet programmable GPIO and documentation that everyone seems to love. Adafruit has an RP2040 Feather for $12, RP2350 for $15, or with an ESP32-C6 (RISC-V) for $15. NXP has chips with similarly programmable GPIO but they're not well supported by Rust. The RP's PIO stuff is bonkers and potentially very interesting if you wanted to make random protocol dongles. VGA out? Why not?
Nordic stuff looks pretty sweet (and their Bluetooth support seems well loved) but is generally a bit expensive. Dev boards are available from micro:bit and Adafruit, among others.
I've been working on a HAL for an older Atmel SoC and absolutely loved the documentation. But Atmel stuff is expensive. Quality of the Chinese clones is iffy. I set myself back a bit by bricking my one board but am hoping to have a beta release in a month or so.
More recent Atmel/Microchip stuff (D21, D51, E51) has a HAL that the Embassy folks seem to have overlooked. You can get them on Adafruit boards at varying price points.
Or just pick something unsupported and start writing a HAL. It's a great way to get up close and personal with how everything fits together.
The one thing I wouldn't do is get some high end thing to start with. Teensy's (NXP i.MXRT) pack a lot of punch but even their native Arduino libs don't really let you exploit the power. STM's H7 series as well, they're way too complex to use as a learning tool even if they are fairly cheap.
A watchdog is a piece of hardware that will automatically restart the chip if it detects the code as being stuck. The way it detects this is that you have to poke a register of the watchdog every so often, and if the register hasn't been poked for a certain timeout (usually configurable), the chip is restarted.
Watchdogs exist on MCUs but also on some "proper" computers. The Raspberry Pi has one for example.
I’ve been enjoying Embassy most at the application pattern layer: long-lived device tasks that hide timing and coordination behind a small, typed async API. For example:
loop {
let btn = ir.wait_for_press().await;
// use btn
}
Meanwhile the compiler builds the state machine for you.
I think this style is an emergent property of async + no-std that hasn’t really been collected or named yet. A lot of discussion focuses on HALs, bring-up, or executors, but less on how people structure applications once those pieces are in place.
This isn't just useful for high-level application logic! (If I'm catching your drift from "the compiler writes the state machines for you).
I used to write extremely low-lebel NIC firmware that was basically a big bundle of state machines. Rust wasn't ready back then but I was desperate for something like coroutines/async. I think it would have been incredibly valuable.
(There are tricks to do coroutines in C but I think they're too hacky. Also, back then we believed that RTOS threads with their own stack were too expensive, in retrospect I'm not sure we ever entirely proved that).
I may be naïve in this case but I think it would also have been super useful for the high level protocol stuff. Like: 802.11 association flows. If we could have just spun up a Tokio task for each peer, I feel the code would have been an order of magnitude smaller and simpler.
Coming from a lot of bare metal C and FreeRTOS it finally feels like embedded is getting a toolchain that is actually modern and better.
Some of that isn't just Embassy but the surrounding ecosystem, some highlights:
* probe-rs w/cargo run integration
* defmt logging (combined with probe-rs and rtt it's very nice)
* embedded_hal (and in my case stm32-rs)
I have also tried RTIC but I decided to keep going with Embassy because I like the async ergonomics more and the few times it's been a downside/missing functionality (no existing async driver for specific peripherals basically) it wasn't to hard to implement what I needed.
I was surprised it just works out of the box on OS X also, generally speaking I would always end up having to use Linux to develop for embedded. Being able to compile on fast Apple M hardware and then run immediately with zero friction is awesome.
It took a little bit to get my head around how to share access to peripherals etc but once I did it's been great and it's nice to know that locking semantics are essentially enforced at compile time so it's actually not possible to have 2 things stomping over the same bus etc which can sometimes be a very hard bug to track down when working with big and fast SOCs.
Other really big aspect Embassy has been good for is really high quality USB and networking stacks. I am using both the USB stack (for PLDM over USB) and Ethernet w/the TCP stack in embassy_net and both have been flawless.
Only real downsides I can think of are it can sometimes be hard to onboard folk that are used to copy/paste from vendor examples and sometimes communicating and debugging with vendors themselves when they aren't familar and won't engage unless you can reproduce on the vendor HAL.
So overall really happy with it and I highly recommend trying it out especially if you are in the STM ecosphere.
>it finally feels like embedded is getting a toolchain that is actually modern and better
Last time i tried embassy, it pulled over 100 dependencies just to build a blinky. Its great for hobbyist programming but i doubt its going to be used in any industrial application any time soon.
In all seriousness, why is that a problem? Surely for embedded, the size and hardware usage of the resultant binary is what matters, not the size/number of tools used to build it? I get that a lot of people worry about supply chain attacks right now (and that's fine, everyone should be thinking about how to mitigate that problem/reduce it) - but going back to a world where code re-use is significantly less usable isn't likely to magically make everything better, that has trade-offs too - particularly if (as plenty of people clearly do) they want a modern dev experience for embedded hardware.
It's already in use at least it automotive. If you are not working with safety critical systems (ADAS type) Rust and to some extent embassy is already in the wild. Companies like ETAS (https://www.etas.com/ww/en/) or Ferrous (https://ferrous-systems.com) are working to certify Rust and some crates (embassy is there) to be used with safety critical components. It's not question if but when it will be used. Volvo, Renault and some Chinese brands already ship cars with Rust embedded components in non safety critical path.
I'm rewriting glicol (https://glicol.org/) with no std, and embassy-rs + 2350 is my go-to choice. Highly recommand this stack if you're planning to start working with embedded systems in 2026.
Probably off topic, but what's the best way to get started with embedded development? I've been a web developer for over a decade, but I'd really love to try something much lower level, and I'm currently making my way through the Rust book. I've got a Raspberry Pi on the way, but I assume that's not truly embedded development.
I would recommend getting a ST nucleo board over raspberry PICO or ESP32. The nucleo boards have integrated SWD programmer which makes flashing easier. You can also use it to debug your code. Try to get one with onboard USB port (like https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) so that you can build USB projects.
Of note neither the debugger nor user USB port on that board work with ARM Macs (guess how I found that out). You can connect it to a hub as a workaround but that may lead to data corruption (per the errata).
Also worth noting that the discrete STLink V3 dongles also use the F7 for USB stuff.
Also also worth noting that not all of the Embassy examples are set up to work with Nucleo boards. It's an odd choice but it is what it is.
I've been really impressed. It's basically a hackable Fitbit with no strap or battery. Full wifi, BLE, 6-axis motion. It's was really easy to get the C demos running. LVGL is awesome. Can't speak to Rust. I get enough of that complexity in my day job.
Other brands that look good for beginners are Elecrow and Makerfabs.
I specifically wanted to get into RISC-V, but they all have boards for other architectures as well.
This one is nice too, it has an enclosure. You could use this for a smart home dashboard. Be careful with the boards with two USB ports, they will backfeed power.
Buy a dev board with an RP2040 in it, an electronics starter kit (resistors, capacitors, LEDs, diodes, breadboard, breadboard cables, etc.) and start writing some code!
If we're talking Rust, rp-hal is great for starting, and of course Embassy is great too, though maybe Embassy is better for later when you start running into the types of problems that it aims to solve.
Raspberry Pi lets you play with GPIO which is a big aspect of embedded (even if it's running Linux instead of FreeRTOS or whatever).
If you want to take things a bit closer to bare metal, check out ESP32 boards. Super cheap from China and you can find them with all sorts of cool form factors with lipo battery chargers, screens, etc.
Using a Raspberry Pi (or anything running Linux) is a completely different experience from bare metal. I wouldn't recommend it for learning fundamentals.
If you want to understand how interacting with peripherals and hardware works, an RP2040 is a good option - it has great documentation and sensible peripherals. Or STM32s have huge numbers of examples in the wild.
Ultimately the biggest difference - the thing you need to learn the most - is peripheral setup. Things like setting up the clock, setting up an I2C or SPI bus, reading and writing bytes from a UART etc. This stuff happens on every computer all the way up to a Raspberry Pi, but the bigger and more powerful the MCU the more it tends to be abstracted away by libraries and middleware.
If you want to truly learn this stuff you have to get low down, strip away all the abstractions and get very familiar with the 1000+ page user manual. Doing that on the simplest microcontroller possible is a benefit, because you're not overwhelmed by complex peripherals and too-many-settings.
I'd also recommend starting with C, rather than trying to mess around with Rust. Rust (and embassy) are great for building apps with very few runtime bugs, but debugging stuff in the Rust async world is a headache, and you've got an abstraction layer sitting between you and the chip.
It's actually really powerful to realise that a peripheral is just 10 memory addresses, and to make it work you just need to define a C struct and point it to the start address. Suddenly you're talking to the peripheral and can configure it. None of that is obvious with layers of middleware and abstractions.
I don't think a regular Raspberry Pi counts as embedded, although from Embassy's documentation, there is a version of embassy for the Rapberry Pi Microcontroller.
I think you’re aware of this already but for everyone else:
There’s different kinds of embedded. What traditionally was referred to as embedded is microcontrollers (e.g., 32-bit ARM Cortex M devices like the STM32 or an NXP IMX106x chip ). A configuration for a Cortex-M7 chip (that some may consider on the high end of traditional embedded) is a 600MHz clock, 1MB of RAM, and 4MB of flash memory. These run either bare metal or a real time operating system but don’t have an MMU.
These days the definition is sometimes expanded to include devices that run full fledged OSes like Linux (embedded Linux) on devices like the RPI with much more memory than an MCU.
To answer the original posters question a bit: get used to C and C++ and not using malloc() / new(), which includes a lot of the standard library.
That’s right, the keyword for embedded development would be “microcontroller”. A normal Pi is an SoC which is more akin to a traditional desktop - embassy would not be the easiest tool to use for that.
I'm a fan of the RP2040 chip. It's a good trade-off between being simple and capable. There are more powerful chips like the STM32's, but frankly there are too many variants and their data-sheets are nightmarish. And there are simpler chips like the Atmel AVRs, but the tooling sucks. ESP chips are also good, but I haven't kept up with them so can't give much advice.
You'll want a dev board, which has the chip plus some supporting components on it. The Raspberry Pi Pico is a good choice because it's so widely used and well documented.
If you care about Rust, you'll also want to get the Debug Probe. Worth the money.
If you don't care about Rust, any Adafruit dev board should run CircuitPython, have good documentation, and likely some projects you can start with. The reason I don't recommend these for Rust is because many of their dev boards do not "break out"/make available the connections for a debug probe.
Edit: Having a project you want to do is good, but just making an LED blink can be magical, too, especially if you haven't done anything with hardware.
Hey! This is broad advice, but I recommend thinking of a problem you find would be interesting. Maybe tangential to a hobby or your job, or just something that sounds fun. Then make it happen.
TLDR:
- get in contact with people programming embedded chips in a local hackerspace
- use https://wokwi.com/ to get started
I was in the same situation. I've been programming high-level languages for decades now and wanted to get my hands on embedded. I've got friends in my local hackerspace and while you can teach yourself programming those chips, it's good to know whom to ask when you get stuck. You can find a hackerspace near you here: https://wiki.hackerspaces.org/Hackerspaces
I've been programming C and Rust on Wokwi. I even simulates electronic components and stuff like switch-bounce-effects. It's very easy and can be used free. You can even use a local IDE like VSCode(ium) and. I've used it with one project and it speed up my project a lot. https://wokwi.com/
Been using this to build a LoRa relay for the Bitchat app running on nrf52, it's actually very smooth for the most part. The only panics I seem to get are from the Nordic's SoftDevice, not for the ebasssy-rust code itself.
I had been using this to try to build a Spark modeling guitar amp pedal controller, controlling the amp via BLE. It seemed pretty promising, and they have their own fully OSS Rust BLE stack. It seemed a little early days with that though, it seemed like the APIs were changing quite a bit and it required pinning git revisions in Cargo. I'm excited to see where the project goes!
This is at the center of a friction point in embedded rust: most of the OSS ecosystem has shifted to this framework, and as a result, is incompatible with, or is high friction if you don't want to make your firmware and control flow Async. This is notable because Rust embedded is nascent and small, so I think splitting the ecosystem along with Async is not ideal. It's also confused some people new to embedded: I regularly hear this dichotomy: "Async vs blocking"; the assumption being if you are not using Embassy, your code blocks the CPU when waiting for I/O, etc.
If you enjoy Async PC rust programming, I think this will be a good starting point. I like how it has unified hardware access to different MCUs, and its hardware support for STM32, for example, is a step up from the initial generation of Trait-based HALs. I seem to be the odd one out as an embedded rust programmer (Personally and professionally) for whom Async is not my cup of tea.
In my experience, most of embassy's HALs support blocking variants as well.
I don't quite understand the opposition to async in this context though. Embassy's executor is quite nice. You get to write much more straightforward linear code, and it's more battery efficient because the CPU core goes to sleep at await points. The various hardware interrupts then wake up the core and notify the executor to continue making progress.
The compiler transformation from async/await to a state machine is a godsend for this. Doing the equivalent by hand would be a major pain to get the same power efficiency and code ergonomics.
My general 2c on this, in context with my observations in rust embedded: I think you are overestimating the difficulty of doing these tasks without Async. I point out again, that the Async vs blocking meme, while widespread, is not accurate. There is nothing about Async that makes it more battery efficient than non Async code. Hardware interrupts, sleep, or non-blocking operations are neither unique to Async, nor difficult without it.
As others have mentioned, ~all of the embassy HALs support nearly 1:1 parity of blocking interfaces for drivers next to the async ones. You really can avoid async entirely while still using embassy hals. The ecosystem is not tightly integrated/locked in.
Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async.
There's no mandate to use async - and helping folks that DO see value in it (which is a LOT of folks), isn't "splitting the ecosystem" - it's people doing things the way they like to do it. Embassy still works very hard to support folks who DON'T want to use async, to avoid duplicated work. There's nothing stopping you from preferring to write and maintain your own HALs, I know you have been for a while! But it's not something that people necessarily have to do, even if they aren't interested or don't prefer async!
I think it's interesting because they seem to have built some vaguely pretty decent interfaces and drivers. Before that there were some attempts to make a rust embedded HAL but I think they were a bit too basic and didn't seem to get much traction. Also async interfaces are probably the most generic, because you can hook them up to superloops, single-threaded applications, and threaded code relatively easily (at least, more easily than the other way around), and IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things at once.
I’ve been doing async non-blocking code for decades, but this is the first time I e seen that word used? I’m assume you’re meaning something like one big ass select!() or is this something else?
> IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things at once.
This. Having to do something like this recently, in C, was not fun and end up writing your own event management layer (and if you’re me, poorly).
Embassy provides some traits, but it's pretty much expected you'll be using traits from embedded-hal (both 0.2 and 1.0).
IMO one of the big reasons Arduino stayed firmly hobbyist tier is because
it was almost entirely stuck in a single-threaded blocking mindset and'
everything kind of fell apart as soon as you had to do two things at once.
I think Arduino also suffered because they picked some super capable ARM chips and weren't really prepared to support people migrating away from AVR. Even the Uno R4 is obscenely complex.
Conversely Embassy suffers from being immature with some traits that haven't really been fleshed out sufficiently.
Maybe stuff has changed a lot in the last year but I didn’t experience that problem so far. For me it was the other way around mostly. Where did you encounter that?
I've had to consistently write my own libraries. HAL for STM32, LoRa support, hardware support for every sensor I use (GPS, IMUs, mag, flash memory etc), ESP-Hosted library, etc. Whenever I design something new or change parts, my assumption is I will have to write my own interface for it. It's not too bad, but is a friction point compared to if I had written the firmware in C or C++.
On the other hand, the rust embedded core tooling including the cargo/rustc/it's target system, probe-rs, defmt, and the PAC project are phenomenal, and make the most important parts one of the lowest-friction embedded workflows around!
I was writing async rust on top of the embedded Hal crate for stm32 before embassy was properly “a thing”. Maybe before it existed. Before async/await were even part of the language. It’s not an embassy exclusive even if its api embraces it.
(I wanted to test a radio library I wrote with two of the modules connected to one MCU, one sending and one receiving. The normally blocking api meant I would need two devices, so I decided to go with async.)
On the flip side, the stm32 firmware hello world from cubeide caused temperature spikes due to spinning. Embassy uses power states efficiently to reduce power draw and temp when nothing is scheduled. It is a huge tangible benefit to use async executors for firmware and I hold the strong belief that it should become the norm for general purpose uC firmware.
There is nothing unique to Async about this: You just put a cortex_m wfi in the main loop, or depending on the STM32 variant, set the sleep or stop bits and related.
How async works with embassy is also interesting. In effect it works like a work queue, when something is waiting on a waker (interrupt) and is woken, the Future (task) is enqueued to be polled (run) by the executor.
There’s good and bad things about this. It’s clever for sure but there can be variable latency between when the hardware event occurs and when the next step in the task starts. This is a lot like zephyr/linux work queues but with linear reading code sprinkled with async/await.
Obviously if you're working on something truly hard real-time you probably wouldn't be reaching for these tools to begin with, but for the average embedded project it seems you will enjoy quite good latency and jitter characteristics by default.
Yes and no, and the answer will depend a little bit on your background. It's Rust, and the learning curve around that still exists. The HAL does a very good job at papering over some annoying details, e.g. if you're working on STM32s you'll be able to get things working without having to dig into the monstrous clock trees and timer peripherals. I found one of the biggest learning curves to be dealing with shared mutable state; embassy offers lots of primitives and tools for dealing with this that are more approachable than you'd encounter with a vanilla embedded Rust project, but there's a little bit of a time investment to learn them and you'll find yourself reading a lot of example code.
Once you get the basics, though, it's very productive and I've found it surprisingly easy to write building blocks I can reuse across a wide range of hardware projects and MCUs!
I haven't had a chance to do embedded work but people damn near fall to their knees and weep when talking about how nice the experience is using embassy. Which makes me want to give it a try.
I never learned any C based languages, so it's been a challenge, but I've enjoyed learning the basics of bare-metal no_std rust on the esp32c3, with esp-rs and its support for embassy to help me get started!
I know bare metal programming is a learning exercise but i can say for 99% of use cases esphome is awesome. I just finished making a cat feeder a esphome smart device
Yes, I have several esphome devices. Very easy to use. Unfortunately the project is not written in a language that I know, and I strongly prefer projects in languages that are familiar to me.
This channel contains videos of journey from setting up environment and busy wait embedded LED blinking, to basically re-inventing and then using Embassy. 4 oldest videos.
I've used RTIC in a few cases. In practice, it's a thin wrapper over interrupt handlers and locks on resources in them. These days, I prefer using macros to simplify the (natively onerous: many <> brackets with Mutex, RefCell etc.!) locking and initialization of global variables.
It also has software tasks, which is presumably the Embassy tie-in you mention.
It's very small and focused, but it fits in places Embassy can't. It reminds me in some ways of coroutines, but it can preempt.
The data-sharing maybe could be nicer, but I do think it's an improvement over C -- you get the ability to do things that you might otherwise need something much bigger like Zephyr for.
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)
99% people in this thread have no idea what you mean. And that’s the reason projects like these make it to frontpage every other day and have hundreds of upvotes/comments.
I am a big fan of the embassy project and it’s a great example of why async Rust is so great: Because this is possible. It works without a heap, is a really low cost abstraction and you can do stuff concurrently on a single core chip (where you can’t just spawn a new “thread”) and you don’t have the complexity of an RTOS. I believe there is a great future for embassy ahead and it’s so great how far the team has come.
I also want to give a shoutout to reqwless (https://github.com/drogue-iot/reqwless) which is a HTTP client for embassy-net that even supports HTTPS!
Rust embedded was really never actually better then C or C++ but embassy for me is a big reason why I now make my buying decision based on how well I can use Rust on the MCU.
If you had to pick a MCU to try this out on, do you have a preference for a devkit to test this with?
Nordic nrf series of chips are ubiquitous, cheap, really well documented and have very good support for the Bluetooth side of things in embassy.
If you don't need any of the wireless radio stuff, I think the raspberry pi microcontroller family is also ridiculously well supported in rust and it's possible to get one of the newer raspberry pi microcontroller is complete with ethernet and several megs of flash for not even 10 bucks.
RP2040 is really great experience. You can get a debug probe (either buy or make yourself with another RP2040)
I cant tell you how awesome it is with minimal setup to get
- Full print logging
- Option to attach a debugger
- cargo r will just flash your code and reset the RP2040
6 replies →
Also espressif RISC V mcu's like the ESP32-C3 and -C6 are fantastic.
Some Nordic MCUs are easy too, specifically nrf52840.
Have fun!
2 replies →
STM is popular because their lineup is cheap, offers a lot of features, and the documentation is readily available. The flip side is that their errata is lengthy, the Rust HAL is complex to support lots of different designs under the same product names, the documentation from STM is poorly organized and spread out over a zillion different documents, and Mac compatibility needs a gigantic asterisk. You can also get a BlackPill (get the F411 version with 8MB flash) off of AliExpress for $0.99 from WeAct's official store. Unlike STM's own dev boards (Nucleo) you'll need a separate debug probe. Nucleos that'll give you a lot of breathing room can be had for $10-15.
RP is also cheap and has that pretty sweet programmable GPIO and documentation that everyone seems to love. Adafruit has an RP2040 Feather for $12, RP2350 for $15, or with an ESP32-C6 (RISC-V) for $15. NXP has chips with similarly programmable GPIO but they're not well supported by Rust. The RP's PIO stuff is bonkers and potentially very interesting if you wanted to make random protocol dongles. VGA out? Why not?
Nordic stuff looks pretty sweet (and their Bluetooth support seems well loved) but is generally a bit expensive. Dev boards are available from micro:bit and Adafruit, among others.
I've been working on a HAL for an older Atmel SoC and absolutely loved the documentation. But Atmel stuff is expensive. Quality of the Chinese clones is iffy. I set myself back a bit by bricking my one board but am hoping to have a beta release in a month or so.
More recent Atmel/Microchip stuff (D21, D51, E51) has a HAL that the Embassy folks seem to have overlooked. You can get them on Adafruit boards at varying price points.
Or just pick something unsupported and start writing a HAL. It's a great way to get up close and personal with how everything fits together.
The one thing I wouldn't do is get some high end thing to start with. Teensy's (NXP i.MXRT) pack a lot of punch but even their native Arduino libs don't really let you exploit the power. STM's H7 series as well, they're way too complex to use as a learning tool even if they are fairly cheap.
8 replies →
I agree. the type safety that it brings to the HAL. it's a like cushion for people entering this space.
never understood what a watchdog is tho...
A watchdog is a piece of hardware that will automatically restart the chip if it detects the code as being stuck. The way it detects this is that you have to poke a register of the watchdog every so often, and if the register hasn't been poked for a certain timeout (usually configurable), the chip is restarted.
Watchdogs exist on MCUs but also on some "proper" computers. The Raspberry Pi has one for example.
7 replies →
I’ve been enjoying Embassy most at the application pattern layer: long-lived device tasks that hide timing and coordination behind a small, typed async API. For example:
loop { let btn = ir.wait_for_press().await; // use btn }
Meanwhile the compiler builds the state machine for you.
I think this style is an emergent property of async + no-std that hasn’t really been collected or named yet. A lot of discussion focuses on HALs, bring-up, or executors, but less on how people structure applications once those pieces are in place.
Brad Gibson and I talked about some of these ideas in this (free) article on how Embassy shines on embedded devices: https://medium.com/@carlmkadie/how-rust-embassy-shine-on-emb...
I’ve also started an open repo to experiment with and document these patterns: https://github.com/carlkcarlk/device-kit
Would love links to other repos that use Embassy at this higher, application-oriented level.
This isn't just useful for high-level application logic! (If I'm catching your drift from "the compiler writes the state machines for you).
I used to write extremely low-lebel NIC firmware that was basically a big bundle of state machines. Rust wasn't ready back then but I was desperate for something like coroutines/async. I think it would have been incredibly valuable.
(There are tricks to do coroutines in C but I think they're too hacky. Also, back then we believed that RTOS threads with their own stack were too expensive, in retrospect I'm not sure we ever entirely proved that).
I may be naïve in this case but I think it would also have been super useful for the high level protocol stuff. Like: 802.11 association flows. If we could have just spun up a Tokio task for each peer, I feel the code would have been an order of magnitude smaller and simpler.
Embassy and async Rust are probably the best things that have happened to the embedded world in the past decade!
C RTOSes are conceptually nice, but such as pain to use in the real world, a lean framework like embassy is the natural evolution.
The best thing is that embassy can actually be considered as a real-time "OS" (you can read more here: https://kerkour.com/introduction-to-embedded-development-wit...).
I'm loving Embassy.
Coming from a lot of bare metal C and FreeRTOS it finally feels like embedded is getting a toolchain that is actually modern and better.
Some of that isn't just Embassy but the surrounding ecosystem, some highlights:
* probe-rs w/cargo run integration
* defmt logging (combined with probe-rs and rtt it's very nice)
* embedded_hal (and in my case stm32-rs)
I have also tried RTIC but I decided to keep going with Embassy because I like the async ergonomics more and the few times it's been a downside/missing functionality (no existing async driver for specific peripherals basically) it wasn't to hard to implement what I needed.
I was surprised it just works out of the box on OS X also, generally speaking I would always end up having to use Linux to develop for embedded. Being able to compile on fast Apple M hardware and then run immediately with zero friction is awesome.
It took a little bit to get my head around how to share access to peripherals etc but once I did it's been great and it's nice to know that locking semantics are essentially enforced at compile time so it's actually not possible to have 2 things stomping over the same bus etc which can sometimes be a very hard bug to track down when working with big and fast SOCs.
Other really big aspect Embassy has been good for is really high quality USB and networking stacks. I am using both the USB stack (for PLDM over USB) and Ethernet w/the TCP stack in embassy_net and both have been flawless.
Only real downsides I can think of are it can sometimes be hard to onboard folk that are used to copy/paste from vendor examples and sometimes communicating and debugging with vendors themselves when they aren't familar and won't engage unless you can reproduce on the vendor HAL.
So overall really happy with it and I highly recommend trying it out especially if you are in the STM ecosphere.
>it finally feels like embedded is getting a toolchain that is actually modern and better
Last time i tried embassy, it pulled over 100 dependencies just to build a blinky. Its great for hobbyist programming but i doubt its going to be used in any industrial application any time soon.
In all seriousness, why is that a problem? Surely for embedded, the size and hardware usage of the resultant binary is what matters, not the size/number of tools used to build it? I get that a lot of people worry about supply chain attacks right now (and that's fine, everyone should be thinking about how to mitigate that problem/reduce it) - but going back to a world where code re-use is significantly less usable isn't likely to magically make everything better, that has trade-offs too - particularly if (as plenty of people clearly do) they want a modern dev experience for embedded hardware.
1 reply →
It's already in use at least it automotive. If you are not working with safety critical systems (ADAS type) Rust and to some extent embassy is already in the wild. Companies like ETAS (https://www.etas.com/ww/en/) or Ferrous (https://ferrous-systems.com) are working to certify Rust and some crates (embassy is there) to be used with safety critical components. It's not question if but when it will be used. Volvo, Renault and some Chinese brands already ship cars with Rust embedded components in non safety critical path.
2 replies →
Can it use multiple cores, eg on the ESP32? It doesn't so say on the landing page.
UPDATE: it seems so, using a second executor. There is "embassy_sync" to communicate.
I'm rewriting glicol (https://glicol.org/) with no std, and embassy-rs + 2350 is my go-to choice. Highly recommand this stack if you're planning to start working with embedded systems in 2026.
Probably off topic, but what's the best way to get started with embedded development? I've been a web developer for over a decade, but I'd really love to try something much lower level, and I'm currently making my way through the Rust book. I've got a Raspberry Pi on the way, but I assume that's not truly embedded development.
I would recommend getting a ST nucleo board over raspberry PICO or ESP32. The nucleo boards have integrated SWD programmer which makes flashing easier. You can also use it to debug your code. Try to get one with onboard USB port (like https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) so that you can build USB projects.
Of note neither the debugger nor user USB port on that board work with ARM Macs (guess how I found that out). You can connect it to a hub as a workaround but that may lead to data corruption (per the errata).
Also worth noting that the discrete STLink V3 dongles also use the F7 for USB stuff.
Also also worth noting that not all of the Embassy examples are set up to work with Nucleo boards. It's an odd choice but it is what it is.
2 replies →
I bought one of these on Amazon last week for $25:
https://www.waveshare.com/esp32-c6-touch-lcd-1.47.htm
I've been really impressed. It's basically a hackable Fitbit with no strap or battery. Full wifi, BLE, 6-axis motion. It's was really easy to get the C demos running. LVGL is awesome. Can't speak to Rust. I get enough of that complexity in my day job.
Other brands that look good for beginners are Elecrow and Makerfabs.
I specifically wanted to get into RISC-V, but they all have boards for other architectures as well.
https://www.waveshare.com/esp32-s3-touch-lcd-4b.htm
This one is nice too, it has an enclosure. You could use this for a smart home dashboard. Be careful with the boards with two USB ports, they will backfeed power.
Buy a dev board with an RP2040 in it, an electronics starter kit (resistors, capacitors, LEDs, diodes, breadboard, breadboard cables, etc.) and start writing some code!
If we're talking Rust, rp-hal is great for starting, and of course Embassy is great too, though maybe Embassy is better for later when you start running into the types of problems that it aims to solve.
rp-hal: https://github.com/rp-rs/rp-hal
Raspberry Pi lets you play with GPIO which is a big aspect of embedded (even if it's running Linux instead of FreeRTOS or whatever).
If you want to take things a bit closer to bare metal, check out ESP32 boards. Super cheap from China and you can find them with all sorts of cool form factors with lipo battery chargers, screens, etc.
Using a Raspberry Pi (or anything running Linux) is a completely different experience from bare metal. I wouldn't recommend it for learning fundamentals.
If you want to understand how interacting with peripherals and hardware works, an RP2040 is a good option - it has great documentation and sensible peripherals. Or STM32s have huge numbers of examples in the wild.
Ultimately the biggest difference - the thing you need to learn the most - is peripheral setup. Things like setting up the clock, setting up an I2C or SPI bus, reading and writing bytes from a UART etc. This stuff happens on every computer all the way up to a Raspberry Pi, but the bigger and more powerful the MCU the more it tends to be abstracted away by libraries and middleware.
If you want to truly learn this stuff you have to get low down, strip away all the abstractions and get very familiar with the 1000+ page user manual. Doing that on the simplest microcontroller possible is a benefit, because you're not overwhelmed by complex peripherals and too-many-settings.
I'd also recommend starting with C, rather than trying to mess around with Rust. Rust (and embassy) are great for building apps with very few runtime bugs, but debugging stuff in the Rust async world is a headache, and you've got an abstraction layer sitting between you and the chip.
It's actually really powerful to realise that a peripheral is just 10 memory addresses, and to make it work you just need to define a C struct and point it to the start address. Suddenly you're talking to the peripheral and can configure it. None of that is obvious with layers of middleware and abstractions.
I don't think a regular Raspberry Pi counts as embedded, although from Embassy's documentation, there is a version of embassy for the Rapberry Pi Microcontroller.
https://docs.embassy.dev/embassy-rp/git/rp2040/index.html https://www.raspberrypi.com/documentation/microcontrollers/
I think you’re aware of this already but for everyone else:
There’s different kinds of embedded. What traditionally was referred to as embedded is microcontrollers (e.g., 32-bit ARM Cortex M devices like the STM32 or an NXP IMX106x chip ). A configuration for a Cortex-M7 chip (that some may consider on the high end of traditional embedded) is a 600MHz clock, 1MB of RAM, and 4MB of flash memory. These run either bare metal or a real time operating system but don’t have an MMU.
These days the definition is sometimes expanded to include devices that run full fledged OSes like Linux (embedded Linux) on devices like the RPI with much more memory than an MCU.
To answer the original posters question a bit: get used to C and C++ and not using malloc() / new(), which includes a lot of the standard library.
1 reply →
That’s right, the keyword for embedded development would be “microcontroller”. A normal Pi is an SoC which is more akin to a traditional desktop - embassy would not be the easiest tool to use for that.
I'm a fan of the RP2040 chip. It's a good trade-off between being simple and capable. There are more powerful chips like the STM32's, but frankly there are too many variants and their data-sheets are nightmarish. And there are simpler chips like the Atmel AVRs, but the tooling sucks. ESP chips are also good, but I haven't kept up with them so can't give much advice.
You'll want a dev board, which has the chip plus some supporting components on it. The Raspberry Pi Pico is a good choice because it's so widely used and well documented.
If you care about Rust, you'll also want to get the Debug Probe. Worth the money.
If you don't care about Rust, any Adafruit dev board should run CircuitPython, have good documentation, and likely some projects you can start with. The reason I don't recommend these for Rust is because many of their dev boards do not "break out"/make available the connections for a debug probe.
Edit: Having a project you want to do is good, but just making an LED blink can be magical, too, especially if you haven't done anything with hardware.
Hey! This is broad advice, but I recommend thinking of a problem you find would be interesting. Maybe tangential to a hobby or your job, or just something that sounds fun. Then make it happen.
TLDR: - get in contact with people programming embedded chips in a local hackerspace - use https://wokwi.com/ to get started
I was in the same situation. I've been programming high-level languages for decades now and wanted to get my hands on embedded. I've got friends in my local hackerspace and while you can teach yourself programming those chips, it's good to know whom to ask when you get stuck. You can find a hackerspace near you here: https://wiki.hackerspaces.org/Hackerspaces
I've been programming C and Rust on Wokwi. I even simulates electronic components and stuff like switch-bounce-effects. It's very easy and can be used free. You can even use a local IDE like VSCode(ium) and. I've used it with one project and it speed up my project a lot. https://wokwi.com/
Been using this to build a LoRa relay for the Bitchat app running on nrf52, it's actually very smooth for the most part. The only panics I seem to get are from the Nordic's SoftDevice, not for the ebasssy-rust code itself.
Bitchat is BLE right? Are you using a custom LoRa protocol or bridging to Meshtastic or something?
I had been using this to try to build a Spark modeling guitar amp pedal controller, controlling the amp via BLE. It seemed pretty promising, and they have their own fully OSS Rust BLE stack. It seemed a little early days with that though, it seemed like the APIs were changing quite a bit and it required pinning git revisions in Cargo. I'm excited to see where the project goes!
Also check out Ariel OS (https://ariel-os.org), which is built on top of Embassy.
Also Xous which is completely independent of Embassy but applicable if you're looking for preemptive multitasking:
https://www.youtube.com/watch?v=DaWkfSmIgRs
But requires an MMU.
It's also being used by microsoft for EC https://opendevicepartnership.org/embedded-controller
This is at the center of a friction point in embedded rust: most of the OSS ecosystem has shifted to this framework, and as a result, is incompatible with, or is high friction if you don't want to make your firmware and control flow Async. This is notable because Rust embedded is nascent and small, so I think splitting the ecosystem along with Async is not ideal. It's also confused some people new to embedded: I regularly hear this dichotomy: "Async vs blocking"; the assumption being if you are not using Embassy, your code blocks the CPU when waiting for I/O, etc.
If you enjoy Async PC rust programming, I think this will be a good starting point. I like how it has unified hardware access to different MCUs, and its hardware support for STM32, for example, is a step up from the initial generation of Trait-based HALs. I seem to be the odd one out as an embedded rust programmer (Personally and professionally) for whom Async is not my cup of tea.
In my experience, most of embassy's HALs support blocking variants as well.
I don't quite understand the opposition to async in this context though. Embassy's executor is quite nice. You get to write much more straightforward linear code, and it's more battery efficient because the CPU core goes to sleep at await points. The various hardware interrupts then wake up the core and notify the executor to continue making progress.
The compiler transformation from async/await to a state machine is a godsend for this. Doing the equivalent by hand would be a major pain to get the same power efficiency and code ergonomics.
My general 2c on this, in context with my observations in rust embedded: I think you are overestimating the difficulty of doing these tasks without Async. I point out again, that the Async vs blocking meme, while widespread, is not accurate. There is nothing about Async that makes it more battery efficient than non Async code. Hardware interrupts, sleep, or non-blocking operations are neither unique to Async, nor difficult without it.
4 replies →
As others have mentioned, ~all of the embassy HALs support nearly 1:1 parity of blocking interfaces for drivers next to the async ones. You really can avoid async entirely while still using embassy hals. The ecosystem is not tightly integrated/locked in.
Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async.
There's no mandate to use async - and helping folks that DO see value in it (which is a LOT of folks), isn't "splitting the ecosystem" - it's people doing things the way they like to do it. Embassy still works very hard to support folks who DON'T want to use async, to avoid duplicated work. There's nothing stopping you from preferring to write and maintain your own HALs, I know you have been for a while! But it's not something that people necessarily have to do, even if they aren't interested or don't prefer async!
I think it's interesting because they seem to have built some vaguely pretty decent interfaces and drivers. Before that there were some attempts to make a rust embedded HAL but I think they were a bit too basic and didn't seem to get much traction. Also async interfaces are probably the most generic, because you can hook them up to superloops, single-threaded applications, and threaded code relatively easily (at least, more easily than the other way around), and IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things at once.
> superloops
I’ve been doing async non-blocking code for decades, but this is the first time I e seen that word used? I’m assume you’re meaning something like one big ass select!() or is this something else?
> IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things at once.
This. Having to do something like this recently, in C, was not fun and end up writing your own event management layer (and if you’re me, poorly).
5 replies →
Embassy provides some traits, but it's pretty much expected you'll be using traits from embedded-hal (both 0.2 and 1.0).
I think Arduino also suffered because they picked some super capable ARM chips and weren't really prepared to support people migrating away from AVR. Even the Uno R4 is obscenely complex.
Conversely Embassy suffers from being immature with some traits that haven't really been fleshed out sufficiently.
Maybe stuff has changed a lot in the last year but I didn’t experience that problem so far. For me it was the other way around mostly. Where did you encounter that?
I've had to consistently write my own libraries. HAL for STM32, LoRa support, hardware support for every sensor I use (GPS, IMUs, mag, flash memory etc), ESP-Hosted library, etc. Whenever I design something new or change parts, my assumption is I will have to write my own interface for it. It's not too bad, but is a friction point compared to if I had written the firmware in C or C++.
On the other hand, the rust embedded core tooling including the cargo/rustc/it's target system, probe-rs, defmt, and the PAC project are phenomenal, and make the most important parts one of the lowest-friction embedded workflows around!
3 replies →
I was writing async rust on top of the embedded Hal crate for stm32 before embassy was properly “a thing”. Maybe before it existed. Before async/await were even part of the language. It’s not an embassy exclusive even if its api embraces it.
(I wanted to test a radio library I wrote with two of the modules connected to one MCU, one sending and one receiving. The normally blocking api meant I would need two devices, so I decided to go with async.)
On the flip side, the stm32 firmware hello world from cubeide caused temperature spikes due to spinning. Embassy uses power states efficiently to reduce power draw and temp when nothing is scheduled. It is a huge tangible benefit to use async executors for firmware and I hold the strong belief that it should become the norm for general purpose uC firmware.
There is nothing unique to Async about this: You just put a cortex_m wfi in the main loop, or depending on the STM32 variant, set the sleep or stop bits and related.
1 reply →
>the stm32 firmware hello world from cubeide caused temperature spikes due to spinning
That should never happen unless you are using a high end 1GHz+ MPUs.Check your GPIOs to make sure there are no shorts.
How async works with embassy is also interesting. In effect it works like a work queue, when something is waiting on a waker (interrupt) and is woken, the Future (task) is enqueued to be polled (run) by the executor.
There’s good and bad things about this. It’s clever for sure but there can be variable latency between when the hardware event occurs and when the next step in the task starts. This is a lot like zephyr/linux work queues but with linear reading code sprinkled with async/await.
Here's a good technical writeup on latency and jitter (latency standard deviation) for interrupts when it comes to Embassy, FreeRTOS, and RTIC:
https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
Obviously if you're working on something truly hard real-time you probably wouldn't be reaching for these tools to begin with, but for the average embedded project it seems you will enjoy quite good latency and jitter characteristics by default.
3 replies →
My only question is - is this tinker friendly? C is tinker friendly, it's not all about correctness and so on.
Not that I mind correctness, but I want to play with this and maybe do some minor hobby projects with limited cognitive load.
Otherwise I'd just do FreeRTOS, which is also a good option.
Yes and no, and the answer will depend a little bit on your background. It's Rust, and the learning curve around that still exists. The HAL does a very good job at papering over some annoying details, e.g. if you're working on STM32s you'll be able to get things working without having to dig into the monstrous clock trees and timer peripherals. I found one of the biggest learning curves to be dealing with shared mutable state; embassy offers lots of primitives and tools for dealing with this that are more approachable than you'd encounter with a vanilla embedded Rust project, but there's a little bit of a time investment to learn them and you'll find yourself reading a lot of example code.
Once you get the basics, though, it's very productive and I've found it surprisingly easy to write building blocks I can reuse across a wide range of hardware projects and MCUs!
Great to see this on HN front page. Have used embassy several times for projects and it's a beautiful work of art. Highly recommend.
I was pretty stoked to find this a month ago.
Sadly, I bought an nRF54L15 board to start my embedded journey, which isn't 100% supported yet :/
Now I have to wait. I'm not gonna go back to C :D
What parts are you missing? (I'm working on the nrf54l support so just curious to know what is blocking you).
Last time I checked, I couldn't get my dmic running. Something about PDM being missing.
I haven't had a chance to do embedded work but people damn near fall to their knees and weep when talking about how nice the experience is using embassy. Which makes me want to give it a try.
Async embedded is something that's always made sense to me and I've been awaiting a long time for it to happen.
But what's the overhead price with Embassy?
I never learned any C based languages, so it's been a challenge, but I've enjoyed learning the basics of bare-metal no_std rust on the esp32c3, with esp-rs and its support for embassy to help me get started!
My learning project -- using mqtt for HomeAssistant integration: <https://github.com/n8henrie/esp32c3-rust-mqtt>
I know bare metal programming is a learning exercise but i can say for 99% of use cases esphome is awesome. I just finished making a cat feeder a esphome smart device
Yes, I have several esphome devices. Very easy to use. Unfortunately the project is not written in a language that I know, and I strongly prefer projects in languages that are familiar to me.
This channel contains videos of journey from setting up environment and busy wait embedded LED blinking, to basically re-inventing and then using Embassy. 4 oldest videos.
https://www.youtube.com/@therustybits/videos
Wow, this dude is good! Thanks for sharing.
His videos are gold! I'm really impressed
Is there a USB host stack for embassy? I was writing my own and had bootkbd working-ish but never got further.
Umm, is this an OS with scheduler and process manager etc thats running circles around their competitors?
Another reason why async Rust is great: https://rtic.rs/
"The hardware accelerated Rust RTOS" -- it can use your interrupt controller as a scheduler.
I've used RTIC in a few cases. In practice, it's a thin wrapper over interrupt handlers and locks on resources in them. These days, I prefer using macros to simplify the (natively onerous: many <> brackets with Mutex, RefCell etc.!) locking and initialization of global variables.
It also has software tasks, which is presumably the Embassy tie-in you mention.
It's very small and focused, but it fits in places Embassy can't. It reminds me in some ways of coroutines, but it can preempt.
The data-sharing maybe could be nicer, but I do think it's an improvement over C -- you get the ability to do things that you might otherwise need something much bigger like Zephyr for.
>it can use your interrupt controller as a scheduler
Isnt' that how schedulers always work?
So can Embassy -- look at InterruptExecutor.
It can, but adds some caveats that rtic does not have like dead locking.
Any ESP8266 ports?
I don't believe so. But the esp32c3 is dirt cheap and runs embassy projects well!
> It obsoletes the need for a traditional RTOS with kernel context switching
Uh, what does async have to do with hard real-time guarantees?
(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)
It doesn't have anything to do with it. It's some nice syntax over cooperative multitasking.
The README should be corrected then. It is currently making a very false claim.
5 replies →
99% people in this thread have no idea what you mean. And that’s the reason projects like these make it to frontpage every other day and have hundreds of upvotes/comments.
And you are downvoted for understanding the issue, of course.
[dead]
[flagged]