It has literally split the ecosystem I’m not sure why people think it hasn’t. There’s basically embassy then everything else. Embassy has been quite successful in large part because its primary author took the time to make it good.
If you look at espressif and how they support rust they have to offer both blocking and non blocking options, they also offer using rust on their freertos and C library setup. It’s quite an undertaking to do all of this.
I think you had the wrong idea on security here, the security is for the device manufacturers benefit to obsolete the hardware and force you to buy a new one not for your benefit. All the data is already being shipped off to where the hell ever for building models of you for advertising and more.
NPU is space that would've probably been better put into something like a low power programmable DSP core, which they more or less are depending on which one you are looking at but with some preconceived ideas on how to feed the DSP its data and get the hardware working. You don't get to simply write programs on them usually from what I've seen.
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."
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.
Nothing prevents you from attaching your async code to a high-priority interrupt (you will need to be careful about synchronization, but no more so than in a regular RTOS). You can 100% do this kind of thing, and you'll probably get better latencies as well.
(interrupt queuing and prioritization can be handled by the hardware nowadays. RTIC, a similar project, uses this to drop the need for a scheduler altogether and just runs all code in interrupt handlers, something which 'traditional' realtime wisdom would forbid because it's from an era where you didn't have something like an NVIC.)
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.
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.
It’s more like you need to program a dataflow rather than a program with instructions or vliw type processors. They still have operations but for example I don’t think ethos has any branch operations.
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.
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.
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.
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.
Show me how time slicing or deadline scheduling would work with multiple priorities (InterruptExecutor's) involved. Show me how a task in an InterruptExecutor would priority boost a task of a lower priority, switch to it, then switch back to free up a locked resource. I don't see how these things are feasible in Embassy.
There's a large number of things that the cooperative scheduler can't do. Maybe you don't need those things, that's fine! Embassy really is quite nice for cooperative task scheduling. But to benchmark a context swapping RTOS which can and pays the cost for doing so, against a cooperative task queue scheduler... these are not at all the same things, and won't have the same performance characteristics in simple scenarios like the one in the blog post.
With an NVIC you essentially have a context switching realtime scheduler in hardware. With appropriate configuration of it you can achieve all things you mention here (though I don't know if embassy has a mechanism for priority inheritance in its current primitives for this kind of thing).
If you look at espressif and how they support rust they have to offer both blocking and non blocking options, they also offer using rust on their freertos and C library setup. It’s quite an undertaking to do all of this.
reply