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.
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.
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.
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.
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.
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.
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'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.
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/
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.
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.
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 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.
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'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.
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 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
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.
[+] [-] hannesfur|2 months ago|reply
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.
[+] [-] ghotli|2 months ago|reply
[+] [-] cat-whisperer|2 months ago|reply
never understood what a watchdog is tho...
[+] [-] jpgvm|2 months ago|reply
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.
[+] [-] MrBuddyCasino|2 months ago|reply
UPDATE: it seems so, using a second executor. There is "embassy_sync" to communicate.
[+] [-] 5d41402abc4b|2 months ago|reply
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.
[+] [-] carlkcarlk|2 months ago|reply
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.
[+] [-] bjackman|2 months ago|reply
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.
[+] [-] unsolved73|2 months ago|reply
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...).
[+] [-] stack_framer|2 months ago|reply
[+] [-] 5d41402abc4b|2 months ago|reply
[+] [-] apitman|2 months ago|reply
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.
[+] [-] bschwindHN|2 months ago|reply
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
[+] [-] unknown|2 months ago|reply
[deleted]
[+] [-] Rebelgecko|2 months ago|reply
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.
[+] [-] devilsdata|2 months ago|reply
https://docs.embassy.dev/embassy-rp/git/rp2040/index.html https://www.raspberrypi.com/documentation/microcontrollers/
[+] [-] guitarbill|2 months ago|reply
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.
[+] [-] PPanther|2 months ago|reply
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/
[+] [-] the__alchemist|2 months ago|reply
[+] [-] mentar|2 months ago|reply
[+] [-] apitman|2 months ago|reply
[+] [-] george_atom|2 months ago|reply
[+] [-] Svoka|2 months ago|reply
https://www.youtube.com/@therustybits/videos
[+] [-] sbt567|2 months ago|reply
[+] [-] Cyph0n|2 months ago|reply
[+] [-] rhinoceraptor|2 months ago|reply
[+] [-] bfrog|2 months ago|reply
[+] [-] kaspar030|2 months ago|reply
[+] [-] inferiorhuman|2 months ago|reply
https://www.youtube.com/watch?v=DaWkfSmIgRs
[+] [-] the__alchemist|2 months ago|reply
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.
[+] [-] bschwindHN|2 months ago|reply
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.
[+] [-] rcxdude|2 months ago|reply
[+] [-] junon|2 months ago|reply
[+] [-] chaosprint|2 months ago|reply
[+] [-] sgt|2 months ago|reply
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.
[+] [-] ericwood|2 months ago|reply
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!
[+] [-] n8henrie|2 months ago|reply
My learning project -- using mqtt for HomeAssistant integration: <https://github.com/n8henrie/esp32c3-rust-mqtt>
[+] [-] vablings|2 months ago|reply
[+] [-] aomix|2 months ago|reply
[+] [-] k__|2 months ago|reply
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
[+] [-] devlolz|2 months ago|reply
[+] [-] roger_|2 months ago|reply
But what's the overhead price with Embassy?
[+] [-] speed_spread|2 months ago|reply
[+] [-] brcmthrowaway|2 months ago|reply
[+] [-] n8henrie|2 months ago|reply