3 ms·

Thank you for the elaborate explanation. I understand the definition of real-time. I just don't understand why you need an operating system, compared to build

by sshine 2y ago

Thank you for the elaborate explanation. I understand the definition of real-time. I just don't understand why you need an operating system, compared to building a real-time firmware application with a runtime that contains a scheduler, an allocator, and what else you might want from an OS. > Embedded async Rust (AFAIK) isn't suitable for building applications like these. Could you elaborate why? > in that sense, embedded async Rust is a viable option Gotcha! So whether it's an OS or a runtime is more of an origin story. Like whether a DSL originates as a config file or as a library.

bruckie 2y ago
Async Rust (by default) can allocate memory, which is (almost always) nondeterministic. I'm not sure how hard it is to guarantee that nothing is using it so that all allocations happen deterministically. Async Rust schedules (mostly) cooperatively, which means one errant task, or too many tasks, can block higher-priority, time-critical work from occurring. Embassy has an interrupt executor, which helps somewhat, but it essentially ties each task to a dedicated interrupt, and AFAICT requires that all high-priority work must happen in interrupt context. Usually you want to stay in an ISR for the absolute shortest possible time, and not be forced to choose between either running in an ISR or missing a deadline. I'm not saying it's impossible to build a hard realtime system in async Rust if you're really careful, just that it doesn't provide the usual set of primitives that allow you to easily reason about worst-case execution time, which is a primary concern for such systems. For me—as someone who has written embedded code professionally, but I'm just some guy, so take this with a grain of salt—the line between RTOS and runtime is whether it has a preemptive scheduler and affordances (usually prioritized tasks with support for handling priority inversion) that allow you to easily prioritize different tasks and ensure bounded worst-case runtime. It almost always also comes with synchronization primitives, like mutexes, mailboxes, queues, etc. All facilities provided by the RTOS need to either guarantee (and document) that they run in bounded time, or be easy to identify and avoid if you need bounded worst-case time.
- sshine 2y ago
  > Async Rust (by default) can allocate memory For bare-metal Rust firmware, you would always use no-std, which excludes a default allocator. I understand from what you're saying that the principal difference between embassy-rs and what you'd expect from an RTOS is the choice of scheduling; as far as I can see, embassy-rs'es cooperative scheduler is even defended as highly intended. The advantage of cooperative scheduling is that you don't need threads and context switching, since every yield gives control to the next task. And, as you say, the downside is that you can't reason about when yielding happens, so you can only hope that tasks yield often. > interrupt executor [...] essentially ties each task to a dedicated interrupt, and AFAICT requires that all high-priority work must happen in interrupt context. Hmm, that seems bad. And how so is RTIC disqualified? It seems not classically preemptive. https://rtic.rs/2/book/en/#rtic---the-past-current-and-future https://rtic.rs/2/book/en/#rtic---the-past-current-and-futur... https://interrupt.memfault.com/blog/embedded-async-rust#cooperative-vs-preemptive-scheduling https://interrupt.memfault.com/blog/embedded-async-rust#coop... https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
- steveklabnik 2y ago
  > Async Rust (by default) can allocate memory Strictly speaking, async rust never allocates. In fact, no language features do; allocation is a library concern in Rust. What does allocate memory are the executors created for non-embedded environments. But just like any user-written code, you can use different implementations that do something else instead. Like you’d imagine, ones for embedded environments would use some statically allocated memory that’s bounded in size. Heck, you can go so far as to just leave them on the stack, like lilos: https://github.com/cbiffle/lilos/blob/main/doc/intro.adoc#using-static-for-state https://github.com/cbiffle/lilos/blob/main/doc/intro.adoc#us... Not trying to say this means that you’re incorrect about any of the other things you’re talking about; I haven’t worked on realtime systems so I can’t speak on them.

by sshine 2y ago

bruckie 2y ago

Async Rust (by default) can allocate memory, which is (almost always) nondeterministic. I'm not sure how hard it is to guarantee that nothing is using it so that all allocations happen deterministically. Async Rust schedules (mostly) cooperatively, which means one errant task, or too many tasks, can block higher-priority, time-critical work from occurring. Embassy has an interrupt executor, which helps somewhat, but it essentially ties each task to a dedicated interrupt, and AFAICT requires that all high-priority work must happen in interrupt context. Usually you want to stay in an ISR for the absolute shortest possible time, and not be forced to choose between either running in an ISR or missing a deadline. I'm not saying it's impossible to build a hard realtime system in async Rust if you're really careful, just that it doesn't provide the usual set of primitives that allow you to easily reason about worst-case execution time, which is a primary concern for such systems. For me—as someone who has written embedded code professionally, but I'm just some guy, so take this with a grain of salt—the line between RTOS and runtime is whether it has a preemptive scheduler and affordances (usually prioritized tasks with support for handling priority inversion) that allow you to easily prioritize different tasks and ensure bounded worst-case runtime. It almost always also comes with synchronization primitives, like mutexes, mailboxes, queues, etc. All facilities provided by the RTOS need to either guarantee (and document) that they run in bounded time, or be easy to identify and avoid if you need bounded worst-case time.

sshine 2y ago
> Async Rust (by default) can allocate memory For bare-metal Rust firmware, you would always use no-std, which excludes a default allocator. I understand from what you're saying that the principal difference between embassy-rs and what you'd expect from an RTOS is the choice of scheduling; as far as I can see, embassy-rs'es cooperative scheduler is even defended as highly intended. The advantage of cooperative scheduling is that you don't need threads and context switching, since every yield gives control to the next task. And, as you say, the downside is that you can't reason about when yielding happens, so you can only hope that tasks yield often. > interrupt executor [...] essentially ties each task to a dedicated interrupt, and AFAICT requires that all high-priority work must happen in interrupt context. Hmm, that seems bad. And how so is RTIC disqualified? It seems not classically preemptive. https://rtic.rs/2/book/en/#rtic---the-past-current-and-future https://rtic.rs/2/book/en/#rtic---the-past-current-and-futur... https://interrupt.memfault.com/blog/embedded-async-rust#cooperative-vs-preemptive-scheduling https://interrupt.memfault.com/blog/embedded-async-rust#coop... https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
steveklabnik 2y ago
> Async Rust (by default) can allocate memory Strictly speaking, async rust never allocates. In fact, no language features do; allocation is a library concern in Rust. What does allocate memory are the executors created for non-embedded environments. But just like any user-written code, you can use different implementations that do something else instead. Like you’d imagine, ones for embedded environments would use some statically allocated memory that’s bounded in size. Heck, you can go so far as to just leave them on the stack, like lilos: https://github.com/cbiffle/lilos/blob/main/doc/intro.adoc#using-static-for-state https://github.com/cbiffle/lilos/blob/main/doc/intro.adoc#us... Not trying to say this means that you’re incorrect about any of the other things you’re talking about; I haven’t worked on realtime systems so I can’t speak on them.