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?
Embassy: Modern embedded framework, using Rust and async
101–110 of 167 posts
Re: Embassy: Modern embedded framework, using Rust and async
#102I 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.
Re: Embassy: Modern embedded framework, using Rust and async
#103Umm, is this an OS with scheduler and process manager etc thats running circles around their competitors?
Re: Embassy: Modern embedded framework, using Rust and async
#104Is there a USB host stack for embassy? I was writing my own and had bootkbd working-ish but never got further.
Re: Embassy: Modern embedded framework, using Rust and async
#105Earlier quoted context omitted.
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…
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 dif…
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.
Re: Embassy: Modern embedded framework, using Rust and async
#106Earlier quoted context omitted.
The README should be corrected then. It is currently making a very false claim.
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.
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."
Re: Embassy: Modern embedded framework, using Rust and async
#107> It obsoletes the need for a traditional RTOS with kernel context switching Uh, what does async have to do with hard real-time guarantees?
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.
And you are downvoted for understanding the issue, of course.
Re: Embassy: Modern embedded framework, using Rust and async
#108Earlier quoted context omitted.
>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
Yes, but those are done in software
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.
Re: Embassy: Modern embedded framework, using Rust and async
#109Earlier quoted context omitted.
> 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 ideall…
Superloop is arguably how every PLC that is programmed in standard way works.
Re: Embassy: Modern embedded framework, using Rust and async
#110Earlier quoted context omitted.
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 dif…
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.
> 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.