[HN Gopher] Embassy: Modern embedded framework, using Rust and a...
___________________________________________________________________
Embassy: Modern embedded framework, using Rust and async
Author : birdculture
Score : 307 points
Date : 2026-01-08 23:00 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mentar wrote:
| 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.
| apitman wrote:
| Bitchat is BLE right? Are you using a custom LoRa protocol or
| bridging to Meshtastic or something?
| the__alchemist wrote:
| 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.
| hannesfur wrote:
| 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?
| the__alchemist wrote:
| 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!
| hannesfur wrote:
| 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
| the__alchemist wrote:
| I think that's on a case-by-case basis, but from my own
| experiences, it's usually easier to start from scratch. A
| _totaled car_ analogy, where the easier path is not
| modifying something existing. But it depends. Good pt. I
| think if the library is documented with datasheet or RM
| references, things are easier.
|
| (Case in point: An example of the the "It's Async or
| blocking" meme I mentioned.)
| rcxdude wrote:
| In my experience most drivers are simple enough that
| there's not a great loss from them being reimplemented in
| different systems all over the place. They're
| fundamentally interface code, it makes sense for them to
| change as on of the sides of the interface changes.
|
| (which leads to one of my embedded hot takes which is
| that I think striving for a generic HAL is kind of
| misguided. If you're striving for any form of mechanical
| sympathy, your HAL is almost certainly specific to at
| least your framework and probably actually your
| application)
| rcxdude wrote:
| 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.
| alfiedotwtf wrote:
| > 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).
| onjectic wrote:
| 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.
| nagisa wrote:
| This superloop pattern can also appear in more abstract
| scenarios as well.
|
| The wildly popular ESPHome is also driven by a superloop.
| On every iteration the main loop will call an update
| handler for each component which then is supposed to
| check if the timers have elapsed, if there is some data
| coming from a sensor, etc before doing actual work.
|
| This pattern brings with it loads of pitfalls. No
| component ought to do more than a "tick" worth of work or
| they can start interfering with other components who
| expect to be updated at some baseline frequency. Taking
| too long in any one component can result in serial
| buffers overrunning in another component, for example.
| p_l wrote:
| Superloop is arguably how every PLC that is programmed in
| standard way works.
| wahern wrote:
| 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.
| inferiorhuman wrote:
| 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.
| bschwindHN wrote:
| 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.
| the__alchemist wrote:
| 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.
| bschwindHN wrote:
| 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/3905ecf8acd3046d35bf750283
| f...
|
| 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.
| imtringued wrote:
| 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.
| the__alchemist wrote:
| > I honestly don't even understand what you are arguing
| for or against.
|
| The notion that Async is the only right or acceptable way
| to do embedded programming, or embedded programming on
| rust. The Overton window has shifted so much that I have
| to state this explicitly.
| vacuity wrote:
| 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.
| bfrog wrote:
| 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.
| bschwindHN wrote:
| 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.
| bfrog wrote:
| I've read this, and frankly its comparing apples to
| oranges. These are not the same things though naively they
| may appear the same.
| bschwindHN wrote:
| I'd be happy to hear some of the differences if you don't
| mind. Both Embassy and FreeRTOS are often used to
| organize the various tasks you want to perform in an
| embedded context so I think it's fair to compare them.
|
| I know their implementations and behaviors can be quite
| different, but I'd like to hear more about what makes
| this an apples to oranges comparison.
| imtringued wrote:
| Maybe actually post a legitimate criticism instead of
| making people think hard about what you're saying?
|
| If I had to complain, I'd say that usually an RTOS isn't
| really meant for something like button handling. You can
| use it and it will work, but the bread and butter
| workload of an RTOS is multiple simultaneous CPU/time
| intensive tasks that need to complete within a deadline.
|
| The embassy scheduler here could run into a problem
| because long running tasks would block short lived
| interrupts.
| junon wrote:
| 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.
| the__alchemist wrote:
| 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.
| junon wrote:
| I didn't say it wasn't possible. I said it was _the hello
| world from cubeide_.
| 5d41402abc4b wrote:
| >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.
| ComputerGuru wrote:
| 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.)
| jamesmunns wrote:
| 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!
| rhinoceraptor wrote:
| 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!
| hannesfur wrote:
| 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.
| ghotli wrote:
| If you had to pick a MCU to try this out on, do you have a
| preference for a devkit to test this with?
| vablings wrote:
| 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
| inferiorhuman wrote:
| 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.
| progbits wrote:
| 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.
| yonatan8070 wrote:
| You've got boards like the Seeed Studio Xiao with an
| RP2040, that board is absolutely tiny!
| progbits wrote:
| The 2040/2350 ones don't have wireless radio.
| the__alchemist wrote:
| 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.
| unnamedd wrote:
| 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.
| idan wrote:
| Also espressif RISC V mcu's like the ESP32-C3 and -C6 are
| fantastic.
|
| Some Nordic MCUs are easy too, specifically nrf52840.
|
| Have fun!
| apitman wrote:
| 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.
| ecalifornica wrote:
| I'll second this, Embassy on the ESP32-c6 is great.
| inferiorhuman wrote:
| 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.
| 5d41402abc4b wrote:
| > 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.
| inferiorhuman wrote:
| 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.
|
| 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.
|
| > 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.
| 5d41402abc4b wrote:
| >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.
| inferiorhuman wrote:
| I've yet to see a MCU vendor ship without bugs. At least
| with ST, the MCU is very cheap.
|
| 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. This
| feels more like an Apple bug to me considering how they
| work very well on Linux, Windows and Android.
|
| 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.
|
| 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.
| tialaramex wrote:
| 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.
| u8080 wrote:
| > 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.
| 5d41402abc4b wrote:
| Which G0 part is this? Can you point me to one of these
| forum posts?
| u8080 wrote:
| 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.
| baby_souffle wrote:
| 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.
| cat-whisperer wrote:
| 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...
| VorpalWay wrote:
| 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.
| 5d41402abc4b wrote:
| >Watchdogs exist on MCUs but also on some "proper"
| computers
|
| All modern computers have watchdog. You can check your logs
|
| `journalctl -b | grep watchdog`
|
| https://access.redhat.com/articles/7129255
| LtdJorge wrote:
| Yes, but those are done in software
| p_l wrote:
| 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.
| cozzyd wrote:
| https://www.freedesktop.org/software/systemd/man/latest/s
| yst...
| cat-whisperer wrote:
| mac's too?
| throwup238 wrote:
| "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.
| lgas wrote:
| That's a software watchdog. The comment you're replying
| to is talking about hardware watchdogs.
| the__alchemist wrote:
| You don't need to poke the watchdog! Petting or feeding is
| fine too.
| cat-whisperer wrote:
| lol
| kaspar030 wrote:
| Also check out Ariel OS (https://ariel-os.org), which is built on
| top of Embassy.
| inferiorhuman wrote:
| Also Xous which is completely independent of Embassy but
| applicable if you're looking for preemptive multitasking:
|
| https://www.youtube.com/watch?v=DaWkfSmIgRs
| IshKebab wrote:
| But requires an MMU.
| mrdataesq wrote:
| Another reason why async Rust is great: https://rtic.rs/
|
| "The hardware accelerated Rust RTOS" -- it can use your interrupt
| controller as a scheduler.
| the__alchemist wrote:
| 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.
| mrdataesq wrote:
| 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.
| wrs wrote:
| So can Embassy -- look at InterruptExecutor.
| bfrog wrote:
| It can, but adds some caveats that rtic does not have like
| dead locking.
| 5d41402abc4b wrote:
| >it can use your interrupt controller as a scheduler
|
| Isnt' that how schedulers always work?
| bfrog wrote:
| It's also being used by microsoft for EC
| https://opendevicepartnership.org/embedded-controller
| brcmthrowaway wrote:
| Any ESP8266 ports?
| n8henrie wrote:
| I don't believe so. But the esp32c3 is dirt cheap and runs
| embassy projects well!
| adastra22 wrote:
| > It obsoletes the need for a traditional RTOS with kernel
| context switching
|
| Uh, what does async have to do with hard real-time guarantees?
| bfrog wrote:
| It doesn't have anything to do with it. It's some nice syntax
| over cooperative multitasking.
| adastra22 wrote:
| The README should be corrected then. It is currently making a
| very false claim.
| apitman wrote:
| The claim is you can get embedded concurrency without an
| OS. Do you disagree?
|
| I prefer C for embedded but must admit that's pretty
| compelling.
| 5d41402abc4b wrote:
| If it has async and concurrency isnt this an OS?
| zipy124 wrote:
| There isn't much difference between this and an OS. It's
| just that in an OS you switch between processes, whereas
| here they switch between async tasks. One could argue
| this is pretty semantic and that you could easily just
| call this an OS.
| adastra22 wrote:
| The claim is it "obsoletes the need for a traditional
| RTOS with kernel context switching."
|
| I don't think the authors understand what an RTOS is,
| because it has _very little_ to do with concurrency. It
| is about providing hard guarantees about execution timing
| of interrupt events. E.g. you need to poll an input port
| every 20ms, or something like that, because that 's when
| the signal will be on the wire. Not "Please wait at least
| 20ms before resuming" but rather "I must resume execution
| in +0.020 sec from now with timing error constrained to
| no more than +/- 100 nanoseconds"
|
| This is traditionally done by having an operating system
| with deterministic timing in its interrupt handling, so
| that it can schedule preemptive wake-up calls exactly
| when needed. As well as some important edge case handling
| like fast queueing of interrupts for later processing, or
| even dropping them entirely if a hard scheduled interrupt
| is being processed. Preemptive execution and OS threading
| is an absolute requirement.
|
| Async rust doesn't even provide hard interrupts. It's
| cooperative multithreading so if some other event handler
| happens to be running when you need to resume, you're
| boned.
|
| So AFAICT Embassy doesn't do this at all? In which case
| it doesn't "obsolete the need for a traditional RTOS with
| kernel context switching."
| pflanze wrote:
| > So AFAICT Embassy doesn't do this at all?
|
| I haven't used Embassy, but the README mentions "Tasks on
| the same async executor run cooperatively, but you can
| create multiple executors with different priorities so
| that higher priority tasks preempt lower priority ones"
| and links to an example that shows how a higher priority
| task runs even though a lower priority one runs a long
| time job (does not yield), thus understanding and
| infrastructure seems to be there.
|
| So, Embassy may _in its entirety_ replace an RTOS / be
| one, but it's not the _async mechanism_ that can provide
| the RT part (and I guess you 're right to point out the
| dangerous sentence as it could mislead people to use only
| async and believe it's RT).
|
| OTOH the sentence would be right if it were something
| like "async multitasking is an alternative to preemptive
| multitasking, and can replace the use of a preemptive OS
| if real-time guarantees are not needed (note that Embassy
| _separately_ allows running multiple executors to allow
| to pre-empt tasks running in lower-priority executors) ".
| They should probably also describe what the reason for
| not needing per-task stack size tuning is.
| apitman wrote:
| My perspective is that RT is not the most important thing
| for most or all of my projects. Concurrency on the other
| hand is very useful to me, and one of the main reasons I
| would need an RTOS. So for me embassy would potentially
| obselete the need. I agree that's not going to be the
| case for everyone though.
| kahlonel wrote:
| 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.
| adastra22 wrote:
| And you are downvoted for understanding the issue, of course.
| a456463 wrote:
| Yup! Which is also the reason why I distrust projects like
| these in general: bold claims when there is nothing to be
| backed up with. What else is hiding behind such bold
| claims?
| dirbaio wrote:
| (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)
| Svoka wrote:
| 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
| sbt567 wrote:
| His videos are gold! I'm really impressed
| Cyph0n wrote:
| Wow, this dude is good! Thanks for sharing.
| stack_framer wrote:
| 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.
| devilsdata wrote:
| 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/
| superblas wrote:
| 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.
| apitman wrote:
| I'm still a noob but it seems like there's also a
| distinction between bare metal embedded and RTOS, which is
| higher level. I think STMs are more commonly run bare metal
| but esp32s use a version of FreeRTOS.
|
| Also libc is bloat :P
| uxp100 wrote:
| I don't think that is exactly accurate. But you know, like
| close enough, describes all my work. Just pointing out that
| something like an industrial system running win ce on
| PowerPC or x86 has been within the definition of embedded
| for a long time. Embedded Java was/is a thing. Both
| extremely non-central examples, but what's new is how cheap
| the hardware is, embedded has always included more
| sophisticated OS' and more than micros.
| vlovich123 wrote:
| 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.
| Rebelgecko wrote:
| 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.
| leoedin wrote:
| 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.
| the__alchemist wrote:
| 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.
| bschwindHN wrote:
| 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
| guitarbill wrote:
| 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.
| apitman wrote:
| 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.
| 5d41402abc4b wrote:
| 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.
| PPanther wrote:
| 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/
| 5d41402abc4b wrote:
| 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.
| inferiorhuman wrote:
| 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.
| NooneAtAll3 wrote:
| ...how the heck did Apple break a USB port of all the
| things?
| inferiorhuman wrote:
| Considering the USB errata for the F7, I assume they
| didn't.
| junon wrote:
| 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.
| n8henrie wrote:
| 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>
| vablings wrote:
| 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
| n8henrie wrote:
| 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.
| jpgvm wrote:
| 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.
| 5d41402abc4b wrote:
| >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.
| sp0ck wrote:
| 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.
| fried-gluttony wrote:
| 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
| DetroitThrow wrote:
| 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...
| kolektiv wrote:
| 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.
| 5d41402abc4b wrote:
| >why is that a problem
|
| Supply chain attacks. There are also regulatory
| requirements to keep track of your tools.
| MrBuddyCasino wrote:
| 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.
| cyberax wrote:
| 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.
| sgt wrote:
| 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.
| ericwood wrote:
| 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!
| roger_ wrote:
| 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?
| aomix wrote:
| 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.
| aitchnyu wrote:
| Umm, is this an OS with scheduler and process manager etc thats
| running circles around their competitors?
| speed_spread wrote:
| Is there a USB host stack for embassy? I was writing my own and
| had bootkbd working-ish but never got further.
| k__ wrote:
| 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
| devlolz wrote:
| What parts are you missing? (I'm working on the nrf54l support
| so just curious to know what is blocking you).
| k__ wrote:
| Last time I checked, I couldn't get my dmic running.
| Something about PDM being missing.
| unsolved73 wrote:
| 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...).
| carlkcarlk wrote:
| 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.
| bjackman wrote:
| 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 naive 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.
| syncurrent wrote:
| 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
| chaosprint wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-09 23:01 UTC)