Live data from Hacker News

Embassy: Modern embedded framework, using Rust and async

github.com

21–30 of 167 posts

Re: Embassy: Modern embedded framework, using Rust and async

#21

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 regu…

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.

Re: Embassy: Modern embedded framework, using Rust and async

#22
post #11

Earlier quoted context omitted.

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 leas…

> 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…

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.

Re: Embassy: Modern embedded framework, using Rust and async

#23

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 regu…

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.

Re: Embassy: Modern embedded framework, using Rust and async

#26
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.

Re: Embassy: Modern embedded framework, using Rust and async

#27

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 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/

Re: Embassy: Modern embedded framework, using Rust and async

#29

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.

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.

Re: Embassy: Modern embedded framework, using Rust and async

#30

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 regu…

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.
Post reply on HN