
Show HN: Rust, ARM Cortex M, and a Generated HAL - jamesmunns
http://jamesmunns.com/update/2016/09/26/teensy3-rs.html
======
JoshTriplett
I ran into some of the folks behind this at RustConf; they're doing some
really interesting work. They're running Rust on bare-metal with a minimalist
embedded OS, and providing easy ways to get access to twiddle hardware,
without having a dozen intermediate layers between your code and that
hardware.

~~~
yitchelle
With the way rust is developing, it could nudge C as the main programming
language for embedded. Kudos this the team.

~~~
hak8or
Good luck with that. There ain't no way rust is getting a misra complaint
setup anytime soon. Not to mention, the current vendors are entrenched in
their ways to ridiculous levels. Companies like keil for example don't bother
to have a Linux complaint tool chain.

~~~
S_I
I do embedded development (for 8051 8 Bit micro controllers), so IMO it has
nothing to do with entrenched, and everything to do with with the following
(at least from my point of view).

But before i explain my reasoning, i will the define the term 'embedded
development' for this comment as follows: \- No gigahertz (not even close). \-
No multi core. \- No giga- and no megabytes of RAM. \- No OS. \- Micro second
respond time, but truck loads of computation. \- No ARM processors.

So here goes.

1.In my world memory safety is simply not an issue, because we don't allocate
dynamically. So neither the borrow checker nor lifetimes are an advantage.

2.The micro controllers are piloting a complex machine with all kinds of
actuators and sensors. So the code is actually (and that is really a rough
generalization) a big state machine. So the functional elements of Rust don't
help that much because, although functional programming and state machines are
doable, the code is IMO far from ..... let's say elegant.

3.If you do real time systems with micro second respond times (like i do), you
really want to know what kind of code will be generated from a specific line
of code just by looking at it. Maybe experienced Rust developers are able to
do that, input would be appreciated here (looking at you Steve ;-).

4.I'v read about the guaranties the Rust developers give regarding stability
of features, breaking changes etc. This combined with the (at least in this
domain) neck breaking speed of development (i see the Rust community already
talking about optional GC) is pretty much a show stopper in this domain. Why?
Because (warning generalization coming) most embedded developers are already
dealing with really hard problems, they simply don't have the time to keep up.
Furthermore, if you have code that needs to be not only compilable, but also
functionally working after twenty years (yes you read that right), you do not
want things developing that fast. Remember, this kind of code is keeping all
the infrastructure we all rely on working.

5.Rust is a complex language to build a compiler for. You will have to
persuade Keil and friends to invest the time and money to do that. And no,
LLVM is no option, because it does not target enough architectures.

6.Rust is perceived as too complex by my peers. Don't say it is easy. It is
may be easy for you or me, but not for everyone. And you know, those people
are valuable too and need a job too.

So there you have it. Rust just does not buy you enough in that kind of
environment.

~~~
dpc_pw
Embedded dev here too. I worked mostly on bigger (processing power-wise)
systems. Actually as big embedded as you can find (PC-level performance), I
toy with smaller ones as a hobby. :)

1\. That is kind of true but only in tiny systems. Having some lists (with
proven bounded size etc.) is still often necessary, where pointer invalidation
is a problem. But even tiny embedded systems will grow in processing power,
get SMP etc. - it's just a matter of time. And there is way more that Rust has
to offer.

2\. Rust is not functional programming language. Rust allows to write parts of
the code in functional fashion and the resulting code is very efficient
(because it's functional and can be optimized well), so you can employ it when
needed. The thing is: C does not support functional programming well, so you
write code imperative way. But imperative ways are neither inherently faster,
nor easier. In many cases functional style code is both easier to understand
_and_ generates better code. Sometimes because it's easier to understand the
code, you can spent more time optimizing the performance, instead of fixing
bugs.

3\. Actually after couple of years writing Rust code, I can predict the asm
generated by `rustc` almost as well as C compilers. Abstractions provided by
rust map very directly to CPU instructions. Also, there have been numerous
times when working on C code, I had to give up on optimal runtime performance
because lack of C expressiveness, safety and sanity concerns. Rust static
dispatch through generic traits, combined with optimizer and LTO does wonders,
really. People just need to overcome the bias that abstractions are costly.

4\. GC in Rust is going to be optional and "manual". Just like `Vec` does
dynamic allocations, and you can just not use it. The "functionality working
after twenty years" is IMO a wishful thinking. Real C code is ridden with
bugs, especially undefined behaviors dependencies, that after 20 years
compilers tend to expose rather easily as they got better at (ab)using them.
UB is actually my biggest problem with C and C++. I have been working with
very smart people, following all the standards, using static analysis,
carefully testing and reviewing and we still were hit quite often with
C-quirkiness and UB. It's common in embedded to pin the version of the
toolchain for the precisely that reason: changing a toolchain version can
expose new bugs in your code (not to mention bugs in the compiler, but that's
another story). Also, the building system: good luck running `make` (or
something like it) on a project from 20-years ago.

> Remember, this kind of code is keeping all the infrastructure we all rely on
> working.

A lot of human suffering had to been thrown at the problem to make C code do
the job there, and countless list of bugs in critical widely-deployed software
tells much about how well it worked. It is sooo relieving, when you don't have
to debug weird bugs due to UB, data races, pointer invalidation, memory
allocations bugs, and you can actually express your code in a way that is both
fast and impossible to mis-use.

However I agree that Rust is, from serious embedded work perspective,
completely immature.

5\. Agreed. Not to mention that in some application the compiler (and all
toolchain elements), as well as the compiled software needs to be certified.
Good luck building a certified Rust compiler. :)

6\. That is true. Rust is way more complex, and many people does their job
well using tools they know, goes home and have better things to do then learn
new programming languages.

IMO. Rust won't overtake neither C, nor C++ places any time soon (let's say 20
years), but for some applications and some people is going to be very valuable
proposition. There are some things that C just completely sucks at: it's
ridden with UB instanity, lack of expressiveness, worse performance (yes, I
really believe C performance is going to be worse than Rust one due to
aliasing and static dispatch), lack of integrated building system (yay cargo!)
which to this day makes it really hard to reuse code. As micro-controllers
become more and more powerful (SMP!) and bigger-embedded systems more popular,
Rust might be gaining some traction.

~~~
_pmf_
> People just need to overcome the bias that abstractions are costly.

C++ (which has a lot of zero-cost abstractions) tried to shift this bias since
several decades with very limited success. Languages like Nim (or even Matlab
with Embedded Coder) have the advantage there's intermediate C output that can
be manually inspected for unintended runtime abstractions.

~~~
pjmlp
The irony is that C was in that spot on the 80's and early 90's, but somehow
it became so ingrained in the industry that people forget how it was like when
C only mattered to UNIX workstations.

------
wyager
Sweet! The Teensy might be the most accessible ARM dev board right now, so
this is great news for embedded rust.

Ever since Rust was announced, I've been eagerly awaiting it's practicability
as a replacement for C/C++. The only place you really _have_ to use either of
those these days is embedded systems, so this is kind of the final step
towards getting modern languages in every subfield of software development.

~~~
duskwuff
> The Teensy might be the most accessible ARM dev board right now

Disagree. It's nice enough as an Arduino-alike, but it doesn't have any
debugging capabilities -- the only commands exposed by the loader[1] are
"write block" and "reboot".

As an ARM development board, I'm much more a fan of ST's Discovery series[2].
Most of their boards are in the $10-$20 range, and they all include a USB-
based programmer/debugger compatible with open-source tools.

[1]:
[https://www.pjrc.com/teensy/halfkay_protocol.html](https://www.pjrc.com/teensy/halfkay_protocol.html)

[2]: [http://www.st.com/stm32discovery](http://www.st.com/stm32discovery)

~~~
tbirdz
I second this. The STM32 discovery series boards are really great for messing
around with!

------
bronz
im trying to learn rust right now. its really hard

~~~
bsder
Just so you know and hopefully are encouraged--learning C is really hard, too.
Most people just never _actually_ learn it.

Rust makes you come to grips _immediately_ with the things that will bite you
in C later.

Keep at it. It's a continuing process regardless of language.

~~~
rdtsc
Knowing C, and liking Rust and struggling to learn it. I think Rust is more
like C++ than C in the type of difficulty of learning.

C is more like chess: the rules are not that complicated and you can figure
out how to write code. It will be a long time to learn to write good C code.

With Rust it is hard to figure out the rules, even to get start writing code.
They are more like complicated board games with lots of rules to learn.

As an aside, after I wrote that it reminded me of this map:
[http://goldns.ru/cppmap-2012.png](http://goldns.ru/cppmap-2012.png) C++ devs
will get all the inside jokes there, Alexandrescu's castle, curiously
recurring template, exceptional swamps and others...

~~~
sidlls
Rust seems very much like modern C++. Borrowing, references and the like have
nearly direct analogs to C++ references, unique_ptr and other STL constructs.
Except the compiler enforces them with (my opinion) relatively more clear
error messages most of the time and in some cases the syntax is actually
clearer (others not necessarily).

My biggest struggle so far is overcoming the differences in the implementation
of generics. I have yet to "fight the borrow checker," but the generics
implementation is something of a hurtle for me.

------
splitrocket
Woo-Hoo! This is super exciting! Thanks!

------
anujdeshpande
Dope !

------
goatlover
D seems like an easier language than Rust. It's too bad D didn't catch on.

~~~
toomanybeersies
D is garbage collected, which rules it out for embedded systems.

~~~
pjmlp
Really?! Java doesn't have any problems with that.

[http://www.ptc.com/developer-tools/perc](http://www.ptc.com/developer-
tools/perc)

[https://www.aicas.com/cms/en/JamaicaVM](https://www.aicas.com/cms/en/JamaicaVM)

[http://www-03.ibm.com/software/products/en/real-
time](http://www-03.ibm.com/software/products/en/real-time)

The problem with D's garbage collector is that it just a very old
implementation, with performance problems and they lack contributions to
improve it.

~~~
toomanybeersies
Those are all running on RTOSes such as RT Linux on an X86/PPC or full ARM
platform.

Those won't run on an ARM Cortex M chip, where your current options are
effectively ASM, Ada, or C if you want high performance and low price and
power consumption.

~~~
pjmlp
They also run bare metal.

Do you want commercial products specifically targeted for ARM Cortex M chip
with GC enabled languages?

Bare metal Oberon compilers for ARM Cortex-M4 and Cortex-M3:

[http://www.astrobe.com/default.htm](http://www.astrobe.com/default.htm)

MicroEJ developed in a mix of Java and C.

[http://www.microej.com/products/device-software-
development/...](http://www.microej.com/products/device-software-
development/microej-os/)

