I definitely would like to get involved with Rust’s embedded story. A little bit of background:
- I have been programming for ~10 years, I started self-taught, but now I have one bachelor’s degree in Computer Engineering and another in Electrical Engineering
- I have designed a fair amount of embedded hardware using KiCAD. (from Apollo to a tiny Cortex-M0+ bluetooth breathalyzer, and several things in between)
- I think Rust is awesome
I work as a full-time software engineer these days, and I travel a lot on weekends, so I don’t have a ton of free time, but I would love to find ways to make Rust the embedded language people reach for first. All of these embedded boards that come pre-flashed with Python and Lua interpreters are a cry for help: No one would ever claim those languages are a good fit for resource-starved environments like a microcontroller. Yet, they’re there.
In my opinion, this is because the existing C/C++ toolchains are a nightmare for embedded dev for people who are not SMEs. Even once you have the toolchain up and running, you either use
Arduino or you spend all your time bit-twiddling registers at specific memory addresses, and none of those options are great.
I’ve had huge problems with reproducibility of
mbed builds. Building offline is nearly impossible. Building through the online compiler works really well, 90% of the time. I’ve had several instances where a project simply stops working a few months later, and the only way to get it working again is to create a new project, and copy-and-paste the old code into it. Updating the dependencies didn’t fix it. Nothing would. That is a scary notion for commercial projects.
Arduino APIs, the problem often boils down to performance and AVR-centrism. Reading and writing from pins is monumentally slow through the standard API, for instance. With the AVR-centrism, many libraries only work on AVR, or work suboptimally on non-AVR platforms.
Bit-twiddling on memory mapped registers by reading a 1,000 page datasheet is pretty self-explanatory. No one relishes this task, and there is a number asymptotically close to zero that represents the number of high-level developers that are excited about microcontrollers so much that they get into this. MSP430 in a nutshell is bit-twiddling, from what I’ve seen. Like, no libraries whatsoever. I think after much digging I finally found an official or semi-official MSP430 library that abstracted away more than absolutely nothing, but I had given up by then.
All of this is to preface the idea that Rust is a prime candidate for making embedded development suck less. I didn’t even mention all of the memory unsafety issues that are common in embedded C/C++, which just causes the microcontroller to crash if you’re not careful enough.
My metric library is even designed to work on
#[no_std], so it should be good for embedded applications at zero runtime cost.
I have a Saleae digital logic analyzer, I have a fair chunk of microcontroller dev boards lying around, including an STM32-Nucleo F334R8, an MSP432 (ARM) board or two, Arduino Unos, a PIC 16F1619 Curiosity board, Raspberry Pi 1/2/3/0/0W, among others. I have access to Linux and Windows computers.
I just need direction on what to do to help embedded Rust.
And finally, when can we make embedded Rust development possible from Stable? Even @steveklabnik has mentioned (IIRC) in the past that Embedded development is considered a priority target for the Rust core team, but forgive me if I say that it doesn’t seem that way when embedded development is wholly relegated to Nightly. I can understand wanting to use features Nightly has to offer, but it shouldn’t be mandatory, and there just cannot be any huge obstacles to stabilizing a bare minimum at this point, IMHO. Even the
asm! macro is long overdue on being stabilized. But, I’m sure these things will… eventually… come with time.