Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embassy: Modern embedded framework, using Rust and async

github.com

Post reply on HN
Print view View original

11–20 of 167 posts

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

#11

Post by rcxdude »

the__alchemist wrote: post #3

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…

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.

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

#13

Post by rcxdude »

the__alchemist wrote: post #9
hannesfur wrote: post #8

Earlier quoted context omitted.

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

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.)

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)

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

#14

Post by the__alchemist »

mrdataesq wrote: post #12

Another reason why async Rust is great: https://rtic.rs/ "The hardware accelerated Rust RTOS" -- it can use your interrupt controller as a scheduler.

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.

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

#15

Post by mrdataesq »

the__alchemist wrote: post #14
mrdataesq wrote: post #12

Another reason why async Rust is great: https://rtic.rs/ "The hardware accelerated Rust RTOS" -- it can use your interrupt controller as a scheduler.

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.

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.

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

#17

Post by alfiedotwtf »

rcxdude wrote: post #11
the__alchemist wrote: post #3

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…

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 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).

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

#18

Post by bfrog »

wrs wrote: post #16
mrdataesq wrote: post #12

Another reason why async Rust is great: https://rtic.rs/ "The hardware accelerated Rust RTOS" -- it can use your interrupt controller as a scheduler.

So can Embassy -- look at InterruptExecutor.

It can, but adds some caveats that rtic does not have like dead locking.
Post reply on HN