Jorge Aparicio writes about embedded programming in Rust, covering ARM Cortex-M microcontrollers, concurrency, real-time frameworks and stack analysis.
HN commenters point to it as the place to learn Rust on bare-metal targets, including the quickstart guide and his cross-compilation tooling.
Write from scratch, maybe. Rewrite, I don't think it will happen anytime soon. In fact, the more time it passes, the more code needs to be rewritten.
Regarding firmware, if the talk was about bare-metal embedded development, then I think Rust is the solution to a problem that no one has.
Since the food on my table comes from firmware development, I passed several days trying to understand the reasons to move to the approach described here: http://blog.japaric.io/brave-new-io/ (Embedded in Rust blog, great reading BTW).
But found little. It's a nice toy but it may be too much.
If that is the trend, then I think Rust for Embedded is the answer to a question no one asked, because in my work, if I need to set a bit into a register, I have to be sure it's fking set; not playing around "just because it may be problematic".
I believe rust's safety guarantees are enough to ensure the soundness of passing data to/from interrupt contexts and interrupt handler re-entrancy. See rtfm[0] for an example and a good explanation. I think DMA handling can be made safe by using the right abstractions, and then you'd just need to trust that any piece of code that accesses the memory uses the abstraction instead of accessing it directly.
Checking interrupt priorities sounds like an interesting problem. What is the state of the art in deadlock prevention? It would also be cool if you could tell the compiler "I need this interrupt handler to return in less than n clock cycles." I wonder if someone could write a rust compiler plugin to check that.
[0]: http://blog.japaric.io/fearless-concurrency/
So, some quick things: every Rust compiler is a cross-compiler, so that's not the tough part. You need to compile 'libcore' for the target, but https://github.com/japaric/xargo makes that pretty straightforward if your chip isn't one of the ones provided by the Rust project, if it is, then you just need to run a command to download it and you're good to go.
https://forge.rust-lang.org/platform-support.html is said target list today. AVR is coming soon, it works but has bugs and is hacky.
Japaric is quite prolific, he writes over at http://blog.japaric.io/ and his latest posts are about his RTOS-like framework.
Finally if you're into ARM, https://www.tockos.org/ might be up your alley.
You can't generally change the direction the stack moves, at least on targets like Cortex-M. Maybe in ASM it'd be feasible to work around, but getting LLVM to do this isn't anything I've ever seen.
The "walk off the edge" technique is what is described here [0], in embedded rust we have a tool that does this automatically (from the author of the post) called `flip-link` [1]. It requires a second linker/re-linking pass to do this sizing automatically (you could also do the same manually with a linker script in one pass, if you hardcode certain sizes).
[0]: https://blog.japaric.io/stack-overflow-protection/
[1]: https://github.com/knurling-rs/flip-link
There are various alternatives, but generally the approach is to know what address you need in advance and create an object for it at compile time that can be accessed type-safely.
e.g. https://zinc.rs/apidocs/ioreg/index.html
or the longer but more detailed http://blog.japaric.io/brave-new-io/ , which covers various approaches. It even points out that you can use the type system to enforce that peripherals are only accessed from multiple threads or parts of the program in a safe manner, which you can't do if you can just reinterpret-cast into anything.
I'm so excited that we're feasibly within a year or two of being able to develop embedded devices in Rust[0] on RISC-V microcontrollers [1] running on open source RTOSes also written in Rust[2]. It's currently already possible but still requires quite a bit of hacking. Plus the RF stacks (Bluetooth in particular) aren't there yet. What a time to be a developer. PS RISC-V on my X220 wouldn't hurt either.
[0] http://blog.japaric.io/quickstart/
[1] https://www.sifive.com/products/hifive1/
[2] https://www.tockos.org/