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.
“compact about 1bout 127 bytes.”
Fixed.
damn 127 bytes blinky…that beats C!!!!
I was hoping that one could use golang in a similar manner.
How? C blinky on STM32 can fit in ~30 bytes
Maybe, if you’re a C genius who knows STM32 like the back of his hand, and can use every trick in the book. In my case a minimal Blinky made with gnu-as takes 104 bytes.
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…
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
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.
Go on an MCU would probably be very impractical. But hey, an AK47 made of solid gold would be very impractical, but I would still LOVE to play with one :P
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
You may be interested in https://github.com/ziutek/emgo
Have a look at https://github.com/hackndev/zinc , they support the ST STM32f4
From the author: “Zinc, in the way it is now, is dead, and that’s a horse I stopped beating”
https://users.rust-lang.org/t/zinc-mini-post-mortem/7079
If you’re a fan of TI TM4C series, here’s an example Rust project that runs on TI Launchpad devboard: https://github.com/m-labs/ek-tm4c1294xl-demo
Good to see newer languages (like Rust and Javascript) running inside memory-limited embedded devices. I love to see Lisp and assembly as well, but nothing beats the modern!
Running ASM inside a microcontroller is just a matter of assembling opcodes on-the-fly into RAM and jumping to them (unfortunately not possible on some chips like AVRs). For Lisp, there’s an AVR implementation, so it should be fully doable on any CPU.
Here’s Lisp for AVR: http://www.technoblogy.com/show?1INT
And JS for microcontrollers if anyone is interested (I use it on STM32 and ESP8266): http://www.espruino.com