Comment by the__alchemist
1 day ago
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.
Is it _that_ hard? No. Is writing assembly _that_ hard? Also no. It's simple, but not ergonomic and takes time.
In C or "regular" embedded Rust, if I want to compose several tasks together, while sleeping the CPU core while waiting on interrupts, I need to scatter global variables over the code, and write custom state machines for all the "yield" points in my code. Oh and then requirements come in later and I need to add some timeouts to various operations. That gets messy quickly. Yes it's "not that hard" but Embassy is right there and it works. I get the state machines for free, I get CPU sleeps for free, the code is easier for others to jump in and work with, and with async combinators it's significantly easier to rearrange logic when new requirements get added.
Just for a concrete example from a (somewhat esoteric) project I'm working on:
https://gist.github.com/bschwind/3905ecf8acd3046d35bf750283f...
This code is receiving uncompressed video frames over USB High Speed and forwarding them to an OLED display. In this case I have the luxury of having enough SRAM to hold two framebuffers in memory, so it's a classic double-buffering strategy of displaying one buffer while the other is being filled. Using a simple combinator, `join()`, I can kick off two DMA transfers with one filling the back buffer, and the other transmitting the front buffer to the display. I can have timeouts on these operations, the code flows pretty linearly, and no external globals or custom interrupt handlers are needed (obviously these exist, but they're in the Embassy code layer). And while these transfers are happening the core is automatically sleeping, assuming I don't have other async tasks running.
To me, this is beautiful for embedded code, and brings a major ergonomic gain over the equivalent in C or even regular old embedded Rust. Obviously you don't have to use it, but I see a bright future for embedded Rust if Embassy and others (like RTIC) can keep up the momentum.
Rust's async is reminiscent of state machines, which are universal. The issues with the experience come from accidental complexity, in the language or the library ecosystem.
I did this in C and writing the state machines for your interrupts by hand gets old really quickly.
Interrupts map one to one to async execution so I honestly don't even understand what you are arguing for or against.
1 reply →
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).
Superloop is common terminology in the firmware space. They are cruder than a giant-state-machine-like case statements(but may use still them for control flow). They usually involve many non-nested if statements for handling events, and you usually check for every event one by one on every iteration of the loop. They are an abstraction and organizational nightmare once an application gets complex enough and is ideally only used in places where an RTOS won’t fit. I would not consider asynchronous frameworks like Embassy to be superloops.
3 replies →
I'm surprised nobody has put together a cooperative threading C framework using the -fstack-usage (https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#in...) option supported by GCC and clang. With per-function stack usage info, you can statically allocate a stack for a thread according to the entry function, just like async Rust effectively does for determining the size of the future. Context switching can be implemented just like any other scheduling framework (including async Rust executors), where you call the framework's I/O functions, which could just be the normal API if implemented as a drop-in alternative runtime.
Googling I see people attempting to use -fstack-usage and -fcallgraph-info for FreeRTOS, but in an ad hoc manner. It seems there's nothing available that handles things end-to-end, such as generating C source type info to reflect back the computed size of a call graph based on the entry function.
In principle Rust might have a much tighter bound for maximum stack usage, but in an embedded context, especially embedded C, you don't normally stack-allocate large buffers or objects, so the variance between minimum and maximum stack usage of functions should be small. And given Rust's preference for stack allocation, I wouldn't be surprised if a C-based threading framework has similar or even better stack usage.
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.
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!
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!
That’s fair but when there is an async version of the driver or Hal available it should be pretty straightforward to port it to synchronous, right? Maybe Claude code can even do it with minimal supervision…
Edit: Replace blocking with synchronous
2 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.
I didn't say it wasn't possible. I said it was the hello world from cubeide.
>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.
I've read this, and frankly its comparing apples to oranges. These are not the same things though naively they may appear the same.
2 replies →