I'm hoping that someone will one day build a RTOS in Rust that can run on M0 (or smaller) devices, comes with decent tooling (so you won't need projects like Platformio to compensate for the horrific tooling that embedded platforms have), and abstractions that are "just so".
I took a class in it at one of the RustConf's and that made me feel, even as a novice in the embedded space, that I would be able to do some great things. If I remember correctly the class was on an M0 board.
What is needed is to get chip manufacturers onboard - and to make them understand that they need to take software seriously. Right now the situation is a bit depressing. The ones that are ahead of the pack choose based more on politics and less based on technical merit. And most see this as a "solved problem" because people are provably able to write software for their devices.
A lot of embedded developers don't really care that the toolchains are awkward because it "works for them". Which isn't helpful. And people easily get annoyed if you suggest that "perhaps this could be done less clumsily". There really isn't any easy way to say "this needs improvement" without provoking a defensive response. And people tend to be fairly frustrated when they get to the point where they reach out to get some help to solve problems.
I still know of companies that skip using any RTOS and create their own OS-like infrastructure because the existing offerings are just too much of a time-waster. (Try to use Zephyr for a year on fairly new chipsets. The amount of time spent getting builds to work after upgrades is astonishing and reveals just how sketchy and fragile the tool chains are - which gives even seasoned embedded-devlopers used to sketchy and/or expensive tool chains pause).
There have been "bare metal rust" initiatives for a while, but I haven't seen any that have gotten critical mass yet. Or buy-in from the hardware industry. I'm not sure why. I suspect the relative newness of Rust might be a factor. Perhaps people that have invested decades in C/C++ are afraid of starting over with a new language because they want to stick to what is familiar.
I think we need to understand better what is needed to make this a success. I'm tempted to think that starting with the tooling might be a good idea. And assume that it needs to support multiple "kernels" (that might not even need compatible interfaces).
One thing that is a bit interesting to look at is the difference in how Espressif and ARM have approached this. Espressif devices became popular in hobbyist segment where Arduino (or rather Wiring) was the "gold standard". Rather than fight it, they embraced and supported it. In not that many years this familiarity lead to lots of commercial grade stuff being made with Espressif chipsets - because they are cheap and there's lots of solutions on the web that can get you prototyping fast. This lead to widespread use of their devices and people "graduating" to using their FreeRTOS-based SDK. An SDK that now has pretty impressive support for anything from Audio to motor control.
(As for ARM: their tooling and them kind of restarting mBed years ago and causing confusion, regressions in tooling usability etc made me ditch them and look elsewhere. Since the "professionals" didn't even use mBed it just wasn't worth the investment in time)
With regard to tooling, it is worth looking at Platformio and ponder why there is a need for a tool to manage embedded toolchains - and what functionality the tool provides. Platformio is perhaps the most convenient system I've used for managing embedded projects. It still has some shortcomings, but it is miles beyond where the industry is right now.
I know you're not excited about ARM, but they are taking an active interest in Rust, going so far as to contribute employee time and company money to the project to get ARM platforms to an equal level of support as X86. They don't make the chips of course, but I'm hoping it trickles down to the manufacturers anyway. Things are already pretty good, I'm excited for them to get even better.
So yeah, they've given us hardware to be able to run CI, which is a huge step. This also includes statements like "Arm intends to further donate newer and more capable hardware to this initiative."
They've had employees doing testing and submitting patches and fixing bugs.
The focus is on aarch64-unknown-linux-gnu to start, but there's a lot of procedural kinks to work out. Future targets should go much more smoothly.
Totally, Rust code has been running on that chip specifically for at least a year. ARM just wanted to start support at the big end of the spectrum. I'm personally working in the M4/M7 range, which is a bit bigger than you...
With Apple moving to ARM it would make sense to focus there first since ARM probably have a decent shot at growing their high end market with Apple's help.
See RTIC (real time interrupt-driven concurrency) formerly known as RTFM (real time for the masses - renamed due to confusion with a similar acronym about reading manuals).
If your c++ code uses the c ABI (application binary interface) then you can call it easily too. There is a tool called rust-bindgen which will automatically generate the required rust code from header files.
Redox (https://www.redox-os.org) is still under heavy development, and isn't intended for widespread use yet, but it is based on a microkernel architecture. I don't know if that's close enough to what you'd like to see.
Isn't that made for somewhat beefier systems? Wouldn't Linux fill much of that niche today (modulo RT properties)?
Remember that a lot of embedded systems run on really constrained chipsets where memory is measured in kilobytes and where the underlying architecture isn't necessarily a von Neuman architecture.
The "just so"-bit is really hard.
Embedded systems need something like Rust.