
Should you Rust in embedded yet? - blacksmythe
https://kazlauskas.me/entries/rust-embedded-ready.html
======
_sh
Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an
eye on Rust for the embedded space and although there has been a lot of
movement in that area--particularly in the last couple of months--I'm not sure
the value proposition fits the microcontroller market, where of course C is
king.

While Rust has much to offer as a programming paradigm in general, the main
value is in the borrow-checker (the linked transcript cites 'memory bugs' as
the most common class of bugs). Embedded software practitioners long ago
abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-
of-bounds access' bugs, instead re-defining the problem as one of latency
(e.g. you'll need to process that static buffer before it gets re-used by your
UART interrupt). Take away the borrow-checker, and Rust looks less compelling.

In time, Rust will find its niche in the embedded space, most likely occupying
the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to
microcontrollers. As wiremine points out, it will require vendor support--
moving away from your vendor's toolchain is a world of hurt that seasoned
embedded developers just won't even consider. Pragmatism reigns: time-to-
market and a cheap BoM are the main metrics, programming language a distant
10th.

~~~
pknopf
Why is C king? Why not C++? The difference is just a compiler, and you can use
C in C++.

~~~
Analemma_
I’m not an embedded developer, but my guess is that if they’re not even using
dynamic memory, I doubt they need or want anything that C++ has to offer.

~~~
jwhite
That's more a matter of experience and attitude -- even simple things like
reference types are nice. Also, templates offer a lot of abstraction power
that can be used to model the hardware nicely, without sacrificing efficiency.

Many embedded programmers come from a background that doesn't expose them to
those sorts of ideas though.

~~~
carlmr
Can confirm, C++ has some nice features which I'd even like without malloc.
OTOH I'm already horrified at the code quality problems pretty much every
embedded shop faces. C++ would only make this matter worse.

As a software inclined embedded guy I also often think of what would be
possible if we switched to C++. But then I think of what's probable.

------
kibwen
If anyone out there is an embedded developer curious about how Rust works in
this space in practice, or a non-embedded developer curious about how to
develop on embedded, there's a really fantastic (and free) ebook, "Discover
the world of microcontrollers through Rust"
([https://www.reddit.com/r/rust/comments/80doqg/discovery_disc...](https://www.reddit.com/r/rust/comments/80doqg/discovery_discover_the_world_of_microcontrollers/)
), by Jorge Aparicio (the premier guru of embedded Rust development), and
recently updated for 2018.

------
wiremine
Having Rust support embedded is only half the story: we need to lobby/advocate
for chip makers to support Rust. The article doesn't directly call this out,
but I think it's important for Rust to truly succeed in this space.

Most embedded systems are fairly closed ecosystems built on vendor-specific
stacks, and most professional embedded engineers wouldn't want to use Rust
until the vendors support it.

This isn't to say the hobby world (ala Arduino/Raspberry Pi) wouldn't benefit
from Rust, but I think the long-term viability depends on the ARMs, STs, TIs
and Renesas' of the world starting to embrace Rust. To date I haven't seen
this happen (although I'd love to be proven wrong!)

Edit: just noticed the recommendation to use a Blue Pill for Rust dev. They're
cheap on eBay (just picked up 2 a few days ago)

[https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-
Sys...](https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-
Development-Board-Module-For-Arduino-/201529768817)

Looks like here is a supported Rust BSP, too:

[https://github.com/japaric/stm32f103xx-
hal](https://github.com/japaric/stm32f103xx-hal)

Anybody have any experience with this?

~~~
mtgx
Time to start lobbying Arm. For instance, I think we already missed a big
opportunity to have Arm develop its Firmware-M in Rust. That firmware is going
to be used by _billions_ of IoT devices in the future. Although I'm sure Arm
is trying to make the C code as safe as possible, at that scale there will be
plenty of bugs, especially since OEMs will get to use customized versions of
it, too.

[https://developer.arm.com/products/architecture/platform-
sec...](https://developer.arm.com/products/architecture/platform-security-
architecture)

~~~
carlmr
The last time I used ARM supplied drivers they were nice to get things started
quickly, but they were of terrible quality (at least for the smaller Cortex M
microcontrollers).

------
keithnz
I'm completely in this boat at the moment. We are doing a hardware refresh of
our embedded platform and I'm looking at the feasability of using Rust.

I'm at the point where I think it is close to being viable, but seems very
young. Most likely we will go with a platform that can support rust, and write
the low level modules with the intent of using rust, but not use Rust just
yet, but do a side project to asseses the viability of doing as much of the
software in Rust as we can. ( and get the devs learning Rust ). I am what I
like to call a multi stack developer, so I'm super comfortable with a lot of
languages and platforms, but the embedded devs I work with are microcontroller
focused C devs and it will take some time to be convinced, conceptually they
like the idea, but as soon as they try and write something serious they are
going to feel frustrated and likely make a mess.

But Rust has a LOT to offer the embedded world.

~~~
bb88
Keep in mind that at some level, something has to be unsafe, unless you've got
hard mathematical proofs that your code works as compiled.

~~~
Sylos
Doesn't mean you shouldn't try to lessen the amount of code that's unsafe.
That way you have at least a fighting chance at getting your unsafe code
bugfree.

------
davidw
One definition of "embedded" is: does the user treat it like an appliance or
like a computer? If it's the former, it's 'embedded' even if it uses a
reasonably powerful processor or does not have hard real time requirements.

I use Erlang for that kind of thing and it works well. Rust is, I think, more
performant, so if that works for you and what you need, go for it.

~~~
dnautics
what do you think of nerves?

~~~
davidw
I recall hearing about it a while back; looks like it has made progress? Seems
worth a look!

------
lpasselin
Any progress with ti's c2000 series in rust?

~~~
tov_objorkin
Oh, ti c/c+ compiler is such a joke, not event c99 supported. I was thinking
about rust to C compiler [1], but thats require c11 support.

1\.
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

~~~
lpasselin
C99 is supported but it is not the default.

------
sureaboutthis
I hate, hate, HATE papers or talks or anything of this nature that begin by
justifying the obvious to the knowledgeable! In this case, "Why does embedded
matter?" Sheesh.

Then there is that law of titles with a question where the answer is always,
"no".

>Yes. As long as it supports your hardware and you are willing to put up with
a less stable toolchain and less nature ecosystem in exchange for the safety
guarantees.

