Modern embedded framework, using Rust and async. Contribute to embassy-rs/embassy development by creating an account on GitHub.
Read the original article
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?
By inferiorhuman 2026-01-095:201 reply 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.
By 5d41402abc4b 2026-01-098:182 reply > The flip side is that their errata is lengthy
Just like security bugs, lengthy errata doesn't mean anything. A popular MCU will have bigger errata sheet because it gets more eyes on it.
>documentation from STM is poorly organized and spread out over a zillion different documents
The spreading out over multiple documents is good organization. You don't want to combine your datasheet, reference manual and appnotes into one.
> lengthy errata doesn't mean anything
In STM32G0 for example, there is "SPIv1" peripheral which has very critical implementation bugs which can get SPI to completely stuck until reset by RCC.
There is very brief mention in STM errata about this, I had to dig up forums and dance up with SWD around this.
By 5d41402abc4b 2026-01-0910:161 reply Which G0 part is this? Can you point me to one of these forum posts?
Sorry, I was digging on that too much time ago and haven't saved any links. AFAIR, there is permanent busy state in certain conditions when functioning in SPI slave mode, unablility to reset TXFIFO/RXFIFO and some edge case with DMA and TXE/BSY when DMA failed and you don't know how many bytes are in RxFIFO.
By inferiorhuman 2026-01-105:40 Someone's in the Embassy matrix channel currently trying to figure out why the SPI driver is preventing the USB peripheral from enumerating on their G0…
By inferiorhuman 2026-01-099:011 reply
Yeah, no. From all outward appearances STM stuff is basically rushed to market, fix the bugs later. We're talking basic shit like xyz clock input or watchdog straight up doesn't work. More advanced stuff like one of their USB controllers straight up doesn't enumerate with ARM Macs — still not in the errata or marketing materials BTW although the workaround may end up beating you with some other bugs. Or the one family that they had to completely rework the USB peripheral while subtly changing the part numbers. Or yeah no.Just like security bugs, lengthy errata doesn't mean anything. A popular MCU will have bigger errata sheet because it gets more eyes on it.> The spreading out over multiple documents is good organization.
No, it's really not. It's things like reading up on a peripheral in the reference manual and then trying to figure out which pins you can use with it. Some vendors will put that in the section with each peripheral, most will include a table within the RM, and STM splits it up into multiple documents — per variant within a family because the families are often loosely related.
None of this stuff is offered up in printed form, they could at least hyperlink it (whether intra- or inter- document).
It's not that surprising really. You've gotta cut costs somewhere.
By 5d41402abc4b 2026-01-099:141 reply >rushed to market, fix the bugs later
I've yet to see a MCU vendor ship without bugs. At least with ST, the MCU is very cheap.
>USB controllers straight up doesn't enumerate with ARM Macs
I've seen USB devices struggling to enumerate on Mac/IOS devices before. This feels more like an Apple bug to me considering how they work very well on Linux, Windows and Android.
By inferiorhuman 2026-01-099:251 reply
Moving the goalposts much? You went from "lengthy errata doesn't mean anything" to "at least it's cheap", which was my point entirely. The STM32 lineup is cheap with a bunch of features, has readily available documentation, and that appeals to a lot of people.I've yet to see a MCU vendor ship without bugs. At least with ST, the MCU is very cheap.
Yep, that's the typical STM fanboi response and part of why I'm not so gung ho on STM products. It just feels… cultish and obnoxious.This feels more like an Apple bug to me considering how they work very well on Linux, Windows and Android.Meanwhile I've been using Macs on and off since before USB came around and this is the first USB device I've found that glitches out like that. Given that Apple uses off the shelf USB silicon (TI) and the complaints about STM's older USB FS peripherals I came across I'd fully believe it's an STM problem.
What is entirely STM's fault is that they still market the F7 based devices (ST Link, Nucleo, etc) as being Mac compatible. They've also skipped out on putting that fun little wart into the F7 errata.
By tialaramex 2026-01-0914:51 I sympathize to some extent but really if popular products work for everybody else but not Mac, that sure seems like Apple ought to make it work even if technically it's not their fault, and I note that you've offered no evidence either way on whose fault this is.
Apple's products being shit in some ways isn't even a weird outlier, the company knows its loyal fans have nowhere else to go.
By baby_souffle 2026-01-0917:11 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
By inferiorhuman 2026-01-095:20 probe-rs is amazing. In ARM land it works with pretty much any CMSIS compliant gear, and yeah you get debugging and logging on pretty much anything as a result.
I wish they had smaller modules with wifi (pico w is too large for many of my usecases). That's the only reason I keep using ESP-C*. It's getting better but the esp-rs tooling has a lot of very rough edges.
By the__alchemist 2026-01-0916:07 Same. Non-Espressif manufacturers have been sleeping on Wi-Fi capability. Nordic now has a chip, but I haven't tried it. I have been using an Esp running Esp-Hosted, connected to the main MCU over SPI.
By unnamedd 2026-01-0918:58 It is a little bit complicated to start and understand how the series ESP-S* works, but as soon you do, everything gets better. It does have Wi-Fi and Bluetooth capabilities and also can be very small. A good example are the Adafruit Qt Py series. I am currently working with the Adafruit Qt Py (ESP-S2) and I am in love to that board. This one, doesn’t have Bluetooth, but the S3 does.
Because of the Xtensa, you need to use a special fork of Rust maintained by Espressif, but worth a try.
By yonatan8070 2026-01-0912:221 reply You've got boards like the Seeed Studio Xiao with an RP2040, that board is absolutely tiny!
By yonatan8070 2026-01-108:291 reply Oh.. my brain completely skipped "with wifi" in your comment, my bad.
By progbits 2026-01-1012:01 You had me excited for a second :)
Also espressif RISC V mcu's like the ESP32-C3 and -C6 are fantastic.
Some Nordic MCUs are easy too, specifically nrf52840.
Have fun!
By apitman 2026-01-094:59 Just got my first esp32-c6 and really excited to start playing with it. The p4 looks like a beast and want to try that out eventually as well. Feels good to be back hacking on embedded again.
By ecalifornica 2026-01-0918:10 I'll second this, Embassy on the ESP32-c6 is great.
By cat-whisperer 2026-01-097:451 reply 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.
By 5d41402abc4b 2026-01-098:153 reply >Watchdogs exist on MCUs but also on some "proper" computers
All modern computers have watchdog. You can check your logs
`journalctl -b | grep watchdog`
By lgas 2026-01-0922:24 That's a software watchdog. The comment you're replying to is talking about hardware watchdogs.
There's generally at least one watchdog device available in most PCs delivered in last decade, but it's not always utilized. Essentially at one point an intel southbridge integrated a basic watchdog on all models, and it started to just... be included.
So these days you can find a variation on the TCO timer watchdog in most PCs, even if the exact implementation varies so we now have a bunch of drivers for the different variants.
Linux doesn't see one on my Ryzen 5600X desktop at least. My Intel Skylake Thinkpad does seem to have two though (iTCO as well as INT3F0D, not sure what that is, but if I interpret the files under /sys correctly it belongs to the LPC/eSPI controller PCIe device, while the TCO watchdog is found under the SMBus PCIe device).
In both cases they do have software watchdogs (NMI based) which relies on a hardware timer triggering an NMI in the kernel. But that relies on the NMI handler still working, which is not as good as a real HW watchdog.
By p_l 2026-01-1315:03 Apparently it depends to a little bit on how the motherboard is designed, theoretically SP5100 watchdog which is part of the CPU logic in recent ryzens, apparently, is supposed to be enabled if the motherboard is designed with IPMI in mind.
For whatever reason, it's enabled on my laptop despite it obviously not having IPMI support :)
By cozzyd 2026-01-0921:46
By cat-whisperer 2026-01-0914:572 reply mac’s too?
By throwup238 2026-01-0915:591 reply “All CPUs” would probably be 99.9999% accurate. It’s just one of those fundamental functions you want in a processor. Whether it’s exposed in the OS is a different matter.
By LtdJorge 2026-01-1311:25 AMD doesn't have it. I just confirmed by grepping through dmesg and journalctl -b, the only time it appears is due to UPS driver notifications (unrelated).
By inferiorhuman 2026-01-102:35 Cortex-A includes a watchdog so yeah.
By the__alchemist 2026-01-0913:361 reply You don't need to poke the watchdog! Petting or feeding is fine too.
By cat-whisperer 2026-01-0914:57 lol
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.
By MrBuddyCasino 2026-01-0910:411 reply 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.
By cyberax 2026-01-0920:50 Absolutely. I'm using it on RP2040, and it's actually superfun to have real low-level code working in parallel.
In my case, one CPU is doing the CAN-based communication and the device control loop, and the other core is providing the IP-based interface with SNMP-based monitoring.
By 5d41402abc4b 2026-01-098:213 reply >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.
By 5d41402abc4b 2026-01-099:02 >why is that a problem
Supply chain attacks. There are also regulatory requirements to keep track of your tools.
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.
By fried-gluttony 2026-01-0912:201 reply Do you have any (soft) evidences, that actually embassy is used in safety-critical applications? I think that is quite more difficult to qualify the whole of embassy with the HAL, executor and the other components used. Ferrous is just the qualified toolchain incl. core std. and some other libraries. Additionally a question is how well it integrates e.g. with ARM self-test libraries for the platform safety.
I know that sonair [0] is actually using Rust in the safety critical path. Toyota Woven [1] is for now just using it in infotainment and non-safety applications.
I am closely monitoring the space, as I am currently evaluating to use Rust and potentially embassy for a safety-critical embedded product myself. I hope to this way also contribute to safety-critical Rust usage. If anyone has further information or just wants to exchange ideas, I'd be super happy to! [0] https://www.sonair.com/journal/leading-the-way-for-safety-ce... [1] https://filtra.io/rust/interviews/woven-by-toyota-nov-25
By DetroitThrow 2026-01-0916:43 A handful of companies participated in this. It seems they all are working already with it or working towards it: https://rustfoundation.org/media/announcing-the-safety-criti...
By rcxdude 2026-01-100:23 A lot of those dependencies are from the same project, though. It's just split into multiple crate so you don't need to pull in one mega-lump of code for everything.
(Also, I am currently using it for an industrial application)
By carlkcarlk 2026-01-0915:061 reply 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.
By syncurrent 2026-01-0921:241 reply A way to implement coroutines in C is via protothreads. I admit that they are a bit hacky - but you can get quite far with them. I used them to implement an Esterel/Blech like environment: https://github.com/frameworklabs/proto_activities
Protothreads are amazing, but really expose you to a lot of subtle bugs. I would not recommend them for any new projects if something like async rust or an RTOS are options.
By bjackman 2026-01-1111:47 Yeah this was exactly my conclusion at the time. It's a cool trick but I just don't think I wanna write a serious system in a special half-language like that.
