Today I’m here to ask a favor: I would like you to help me identify the areas where the embedded Rust tooling and ecosystem need more work before Rust can be more widely used in embedded systems. This information will help me prioritize my work on the embedded Rust space during the following months.
(Full disclosure: I’m under a contract to improve Rust’s embedded support. Yay!)
My current focus is on the ARM Cortex-M microcontroller space as the tooling and crate ecosystem has been shaping up quite well for some time, and it’s close to being usable in production or it’s already being used in production but not as extensively as it could be. But I’d be happy to help with other areas (e.g. AVR, MSP430, etc.) as time allows.
My goal is unblocking you from building embedded applications with Rust by improving the tooling, the development workflows, documentation and the crate ecosystem. So feel free to message me on IRC (japaric on #rust-embedded @ irc.mozilla.org) or via e-mail (see GitHub profile) if you need help.
Here are some questions for you to get an idea of what the existing blockers are:
If you are planning, contemplating or discarded the idea of using Rust for your next embedded application, I have two questions for you:
How do you plan to use Rust in your embedded application? Some alternatives:
- I want to write pure Rust applications
- I want to write Rust code on top of a C/C++ framework
- I want to use Rust as a component of a C/C++ application
And, what’s preventing you from using Rust? Some possible reasons:
- I don’t know where to start
- Rust doesn’t support my target device architecture (e.g. AVR, Xtensa)
- There’s no support on crates.io for my development board / device
- Key tooling is missing:
- How do I test my code?
- How do I manage several build configurations (different boards, different devices, etc.)?
- I want to see more successful applications before I hop on the bandwagon
- I want to use stable Rust for embedded development
And if you are using or have used Rust on an embedded system please share your story! I’m sure it will encourage others to give Rust a try, and I would love to hear what difficulties you ran into.
This is where we are now. What do you think is missing in the ecosystem and tooling?
Existing frameworks and supported hardware
- Framework for building concurrent applications
- Status: You can build robots with it
- Application space: real time systems, control systems, robotics
- Supported hardware:
Getting started guides
- For Tock.
- cortex-m-quickstart. Template for building bare metal applications; not tied to any framework.
- For the Real Time for The Masses framework. Builds on top of the cortex-m-quickstart so check that first.
- For the Rust on the Photon.
Xargo. Cargo drop-in replacement that compiles
coreon the fly. Required for almost all embedded development as there’s no rustup target /
rust-stdcomponent for most embedded targets.
svd2rust. Generates a Rust API to access a device hardware from a System View Description file. Simplest way to bootstrap support for a device.
dslite2svd. Converts TI’s version of SVD files into standard SVD files which then you can feed into svd2rust.
utest. no-std unit testing framework. You can run the unit tests on real hardware or simulated hardware (QEMU).
What’s in the pipeline
Rust support for existing development boards
One of my tasks is making embedded development for these 4 boards as easy and painless as possible:
- Blue Pill + Real Time For the Masses
- Hail + Tock OS
- Particle Photon + Rust on top of the Spark firmware
- BLE400 + Rust on top of ??? (one of nRF51 SDK, MyNewt, Zephyr, etc.)
This board selection tries to exercise different frameworks (TockOS and Real Time For the Masses) and different approaches to development (pure Rust vs Rust on top of C/C++).
This past week I have been working on the photon, and I’ve created a Cargo project template that works on Linux and Windows (and likely on macOS too), plus I have created some safe bindings to their C HAL. Future work involves extending the safe HAL.
I have a sizable HAL for the Blue Pill on my hard drive that I haven’t published yet. Future work involves documenting the process of developing a robotic application with this board and the Real Time For the Masses framework.
Work on the Hail is blocked on getting my hands on some hardware, but I want to take a close look at their kernel and userland development workflows.
And I have a BLE400 board but I haven’t tried anything with it yet.
Getting rid of Xargo
If we start producing binary releases of
core for the
thumbv*m-none-eabi targets installable via rustup then we can use those (
rustup target add) with normal Cargo instead of having to use Xargo. That should make development for those targets more similar to development for
std targets. I hope to start work on this soon-ish.
I will be using the rust-embedded/rfcs issue tracker to track progress on the problems raised here so keep an eye on that.
Let’s improve the state of embedded Rust!