I think this is the XY problem: people ask/reach for an RTOS because that was the only thing that made sense for any reasonably complex system in C!
* build system
* package manager
* docs tooling
* reusable libraries/components
* safe concurrency primitives
So where do you get these if you're building a system?
Well, sometimes your chip manufacturer provides some of these, to some varying level of quality.
If you want an ecosystem that works across more than one chip/family, what do you do?
But does that mean that your embedded systems needs multiple threads because you like the ecosystem that comes with them?
You need to appropriately allocate stack/other resources. You need to think about how the tasks interact. You STILL need to think about lifetimes and memory safety, even with an MPU!
Well, most of Rust's tooling and "batteries" work just fine for microcontroller targets!
* Compiler toolchain: Cross compile out of the box
* Package Manager: Cargo, same as desktop targets
* Docs/testing: Yup, still Cargo
It's actually EASIER to share code across desktop and embedded targets with Rust, because if a crate is marked `#[no_std]`, it almost certainly will work on either platform, no hacks required!
Interrupt routines are basically threads: They run concurrently (when invoked), so even Send and Sync make sense to have the compiler enforce! This means errors are caught at compile time.
Tools like rtfm.rs, which is a concurrency framework, allows you to schedule tasks based on interrupts. You can use the NVIC as a hardware scheduler!
All while writing code that feels idiomatic to Rust, regardless of whether it's embedded or not.
Entire applications (not just libraries) need to run unmodified on different targets
Fallible on a per-task level
Then you'll probably want an RTOS like @talkingtock! But this is a pretty specific domain.
I think @rustlang is perfect for that.