Embedded Rust in Production?

A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.

Without this, using even very simple hardware interfaces (like an SPI/I2C bus) is gonna be a huge pain, because you'll have to comb through reference manuals and register descriptions for your processor and piece everything together yourself instead of just calling a few API functions (this is also very error-prone and using Rust is not really gonna help one bit).

The only chance to get even halfway decent rust integration is to pick one of the like 3 most popular hardware platforms among hobby enthusiasts (think ESP32, raspberry pico), which is simply not viable for a LOT of embedded applications.

So I still think its probably a really bad idea for a typical embedded-shop to fully go for rust right now-- the downsides from lacking tooling/libraries, reduced developer pool and the need to train extant devs appear very hard to overcome to me.

Not a Rust dev, but couldn’t you use FFI to call the C routines from Rust? Of course you‘ll have glue code which is seldom pretty, and depending on the amount of Rust actually involved at runtime it might be questionable to do in the first place.

Absolutely! But this is a huge amount of complexity in build system/linker setup/debugger that you are gonna have to stay on top of. The gains from using Rust need to be overwhelming to justify a setup like that.

Also consider that calling those FFI APIs from Rust is not gonna do anything for you by itself-- you are basically just calling C functions with extra steps... To actually get anything out of it, you'll then likely have to wrap the whole hardware interface in a "rustified" API (which, again, you'll probably have to write and maintain yourself...)

> A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.

If you have a reference implementation in C it's not such a big job to set up something like an I2C or SPI peripheral. At it's core, you're making a sequence of writes to some memory locations. Most of the manufacturer libraries are quite low quality, and very easy to misuse. In my experience trying to do anything that pushes the hardware, you will end up combing through the reference manuals anyway.

I've done a bit of embedded rust, and the huge benefit - just like on desktop - is that code which compiles tends to do what you intended. Obviously there's still scope for logic errors, but that takes away a huge amount of debugging time.

Many years ago, our project had a library that would link our Ada code to the low level operating system calls that are in C (network, shared libraries etc).

Once it was written the code was stable, but you bring back not so pleasant memories of building / testing. It might just be our make files were unnecessarily complex or we were building libraries not executables…

For some complex peripherals (especially wireless) this may be the case, but in my experience it's often much easier to write small abstractions for what you need in the mode you need it in (for serial, timers, IO, DMA, ...) than relying on manufacturer SDKs, which are often so poorly documented that you need the reference manual anyways to understand the peripheral to then understand the abstraction, which is often much more complex to use than it needs to be for my use cases. With abstractions in Rust or, for something quickly thrown together, in uPython you're at least getting "you're holding it wrong errors".

Interfacing with the peripheral registers themselves is also a bit simpler with Rust in my experience, as a proper .svd already contains bitfield setups with enums and R/RW/W1 information to at least set the bits you want instead of the Macro-Hell in C some manufacturers throw at you.

The irony in this article is that even the much lauded ESP32 integration is essentially all of the important stuff like WiFi continuing to run and live in the C world, while they have a little Rust frontend for all the hipsters to believe their great bugfree Rust code is making the world spin.

Even with the vendor libraries last time I had to poke at a CAN bus I ended up having to go to that same level because the C helper libraries omitted key features of the interface.

There's a number of micros these days where the same libraries are provided using SVD[1] that will generate interfaces which is handy.

[1] https://docs.rs/svd2rust/latest/svd2rust/

Rust solved this by autogenning code from mfgr published device xml descriptors. Eg https://embassy.dev/

Better than any C(++) embedded hal I've used

I think it’s a pretty mixed bag, but yeah no one really has a lot of support for rust, but c++ support is quite common and “good enough” for lots of things where you’d like more complicated but zero-cost abstractions. RAII, getting rid of pointers, maps, vectors, etc