Rusty ARM

You’ve probably heard that Rust is a systems programming language that has quite the following growing. It purports to be fast like C, but has features like guaranteed memory and thread safety, generics, and it prevents segmentation faults. Sounds like just the thing for an embedded system, right? [Jorge Aparicio] was frustrated because his CPU of choice, an STM32 ARM Cortex-M didn’t have native support for Rust.

Apparently, you can easily bind C functions into a Rust program but that wasn’t what he was after. So he set out to build pure Rust programs that could access the device’s hardware and he documented the effort.

Not only does the post show you the tools you need and the software versions, but using OpenOCD, [Jorge] even managed to do some debugging. The technique seems to pretty generally applicable, too, as he says he’s done the same trick on six different controllers from three different vendors with no problem. You do have to configure the project by changing some values in a template.

Although it isn’t a Rust tutorial, following along with [Jorge’s] code and his explanations will give you a pretty good idea of what Rust looks like. He also shows off a neat tool, gdb-dashboard. To build the API to the ARM’s special memory regions, [Jorge] uses a tool called svd2rust to process the vendor’s SVD files. These are usually used for JTAG programming and testing, so we thought that was a novel way to automatically build support for the processor.

A lot of languages that offer safety features tend to compile fat code. [Jorge] shows a blinking LED example and disassembles it and it looks quite compact about 127 bytes. He then abstracted away the timer registers and the code is almost the exact same size when compiled.

We covered Rust briefly a while back. We’ve also seen Rust on some WiFi gear more recently.

16 thoughts on “Rusty ARM

      1. I think everyones math here is quite off. I challenge you to do a anything on even a lowly Cortex-M0 in under 192 bytes; that’s the size of the exception and interrupt table. Maybe it’s possible to dual-use it but that’s certainly not a proper program.

        Also you’re most likely not only ignoring proper initialisation here, I’m pretty sure you’d use a dumb busy loop to achieve your Blinky and not a timer like it is done here… So it’s classic apples vs oranges comparison…

    1. It is my understanding that golang does not compile down or run nearly as efficiently, which IMO makes it less friendly for MCUs. That being said, both languages are pretty sweet, and I would love to see a golang implementation on an ARM micro

      1. Go is garbage collected and has a sizable runtime containing symbol tables/type info for runtime reflection and the like – hello world on linux/amd64 is 968k as of 1.8.1. Unlike Rust, which guarantees safety through a complicated type system proven at compile time, Go avoids unsafe behavior via the runtime (GC, bounds checks, etc). I don’t doubt that it would be possible to strip the language down, but I would be very interested to see how much would need to be removed and if the language would still be useful when it can fit on a high end Cortex-M. I suspect that if Python can be made to run on a MCU, Go probably has a good chance.

          1. If you can python and frickin javascript running on a microcontroller, you most definitely can get golang running on an microcontroller. Even if it is impractical.

            I remember when C used to be looked as unnecessary in embedded development and assembly was the place to be. I also remember when the PIC16C84 was the baddest (in a good way) MCU in town

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.