
The Embedded Rust Book - formalsystem
https://rust-embedded.github.io/book/intro/index.html
======
burfog
20 years ago, I did embedded computing with systems that would scale to about
360 processors (PowerPC "G4" MPC7410 @ 500 MHz) and about 70 gigabytes of RAM.

Yes, it really was embedded. It fit in 9U (15.75 inches) and was rugged enough
to fly in a military aircraft. The OS would let users turn off interrupts in
order to squeeze out every bit of performance.

We could also run the OS on the SHARC DSP, which is a word-addressed Harvard-
architecture chip without an MMU. Running on that would allow 3x the CPU
density. One system got up over 1000 cores.

IO would typically come in via DMA, over a 32-bit link running at 40 MHz.
There could be many of these.

The end result was generally something like a radar. The end-user sees a
radar, buys a radar, and uses a radar. They don't see a computer. The computer
is just a component embedded in the radar.

~~~
contingencies
That's an interesting story but you have to admit high bandwidth real time
signal processing is a pretty specialist embedded workload. I guess these days
there'd be FPGAs and/or existing IC packages for the job.

~~~
burfog
There were several companies competing in this space. The main three were
CSPI, Mercury Computing (now Mercury Systems), and SKY Computing. Matrox
briefly tried to join the party.

Even back then, FPGAs and custom ASICs would be part of the compute fabric. I
left that out. For example, there was an FFT accelerator chip. These days the
companies add in a mix of FPGAs and GPUs, but the CPUs are still there. It's
all the same stuff today, but faster.

To the end user, it was never a computer. It was a radar, a video processor,
an MRI scanner, a sonar, an ultrasound, a chip wafer inspection device, a
laser with real-time mirror warping, or some other tool.

~~~
contingencies
You have a good point that people who set out to implement high end
military/medical/high end industrial metrology hardware greenfield projects
today may see value in using Rust and won't have a problem with more expensive
hardware. However, I do think that's a vanishingly small percentage of
embedded development.

------
contingencies
I would absolutely _love_ to throw my lot down behind something other than
C/C++ for embedded development, but after investigating Lua and Rust I could
only come to the conclusion that they're currently inappropriate for resource
constrained commercial development... particularly if you use a broad range of
sensors, have higher-level protocol communication requirements, etc. Re-
implementing this stuff isn't just a minor drag, it's commercial insanity.

1\. Example hardware in this book costs around 98RMB and has a huge form
factor. AVR / ATmega328P based platforms like Arduino Nano are currently
~10RMB, which can be beefed up to full ethernet connectivity with prebuilt
hardware modules for another 20RMB. So in short it is possible to procure over
three(!!!) embedded, ethernet capable AVR platforms for the same price as this
hardware, no soldering required. Why not use something cheaper and more
broadly available? It would help more people get on board (no pun intended).
Oh wait, there's no AVR support. I see...

2\. The nominal target hardware in the book seems overpowered/overpriced/out
of date. For example, the target used in the early book is LM3S6965, which is
NRND (Not Recommended for New Designs). Probably as a result of NRND status (I
guess people buying up stock to keep old designs in manufacturing) it costs
over 125RMB for the chip alone. The manufacturer's recommendation for
replacement is TM4C12x, the cheapest development board for which is
MINI-M4FORTIVA @ 22RMB (which features JTAG). ICs in this series begin at
22RMB or so, still many times AVR chip price, and with IMHO far too much
hardware for novices (64KB flash, 12KB RAM, 12x12bit ADC channels, 49+ GPIO
channels...). A direct quote from later in the book is _In this example, let
's assume we have an Texas Instruments TM4C123 - a middling 80MHz Cortex-M4
with 256 KiB of Flash._ That's not middling, that's ridiculously overpowered
for almost anything embedded.

3\. See example code at [https://rust-
embedded.github.io/book/start/registers.html](https://rust-
embedded.github.io/book/start/registers.html) and compare C and Rust _Volatile
Access_ examples at [https://rust-
embedded.github.io/book/c-tips/index.html](https://rust-
embedded.github.io/book/c-tips/index.html) and see which syntax you prefer...

~~~
Matumio
Is there seriously still a commercial reason to use the ATmega328 (an 8-bit
microcontroller with 2000 bytes of RAM) for new projects? I've been working on
3D printing firmware, and it's so easy and silly to reach the limit of this
CPU. Been shaving bytes of RAM by reducing queue sizes, running into
performance limits even with a few 32bit additions in the stepper loop. That
was 6 years ago.

The only semi-valid reason to use this chip IMO is because people want to keep
using existing firmware as-is.

~~~
howard941
Cost and temperature. Albeit not the ATmega 328 MCUs in the even more resource
constrained ATTINY series go for under $.30 in quantity and run in 125C
environments
[https://octopart.com/search?q=avr%208%20bit&sort=median_pric...](https://octopart.com/search?q=avr%208%20bit&sort=median_price_1000&sort-
dir=asc) . It's going in new products.

~~~
contingencies
Only $0.13 for 2000+ ATTINY25-20SU according to
[http://www.hqchip.com/search/ATTINY.html](http://www.hqchip.com/search/ATTINY.html)

~~~
hajile
A rather small team of 10 people (with only 4-5 devs) will cost 10K per week
at some generic corporation. Let's say your project takes 12 months to make on
a beefy processor ($2 per unit) and 15 months on a cheap processor ($1 per
unit). That extra dev time to deal with those issues directly costs 120K.

That automatically means you have to be shipping at least 120K units just to
break even with those costs. But you are also getting to market 3 months later
which itself has huge business costs which means you probably need to be
shipping 200K or more units. That's a pretty big number for a lot of embedded
device designers.

If you double your chip constraint from $0.13 to $0.26, then that same team
must now ship a million devices to break even.

------
gaze
Is there a good STM32 USB library for Rust? I've seen some preliminary work on
some stuff in the past but I'm not sure where it's at. If it's not
particularly developed, has anyone had success calling into the ST provided
libraries from rust to get USB up and running?

Rust for embedded stuff seems like an absolute dream. I'd love to make use of
all the excellent work that's gone into it. Most of my work just needs USB.

~~~
wezm
There is this one, [https://github.com/mvirkkunen/usb-
device/blob/master/README....](https://github.com/mvirkkunen/usb-
device/blob/master/README.md) which apparently works well enough to power a
keyboard:
[https://github.com/TeXitoi/keyberon](https://github.com/TeXitoi/keyberon)

------
yitchelle
This book focuses on the ARM Cortex-M archtectured microcontrollers..

Is there a comprehensive list which other microcontroller is supported by
Rust?

I really like the direction that Rust is heading in regards to embedded but I
wish that when folks mentioned embedded, they should also indicate which
microcontrollers are relevant. There are so many varieties around.

~~~
steveklabnik
[https://forge.rust-lang.org/platform-support.html](https://forge.rust-
lang.org/platform-support.html) is mostly accurate.

~~~
robocat
Wow: tier 1 contains no ARM or other CPU arch. Tier 1 is only 32bit i686 and
64bit x86_64.

Tier 2 platforms can be thought of as “guaranteed to build”. Automated tests
are not run so it’s not guaranteed to produce a working build.

~~~
steveklabnik
We’ve been thinking about re-doing the tier system, as it misses some
important points. For example, Firefox has ARM as a tier 1 platform, so if we
find bugs, they tend to get fixed up pretty quick. We’re not sure the current
way of defining stuff really maps to the reality.

------
wyldfire
Thanks much to japaric (Jorge Aparicio IIRC), he's contributed heavily to
projects which support embedded use cases.

------
bsder
Okay, can we _please_ get a primer that an intern can follow that starts from
an empty Windows 10 install, installs everything including VSCode, flashes the
boards with a Segger J-Link, blinks the LED, and single steps the debugger?

I'm serious. I will _go buy any board_ in order to check that tutorial out.

I'll go further. I would buy the Rust folks a couple boards and Seggers to get
that.

~~~
jamesmunns
Hey, my company has this. We do consulting and training for embedded rust, and
our material is open source.

Check out [https://github.com/ferrous-systems/embedded-
trainings/blob/m...](https://github.com/ferrous-systems/embedded-
trainings/blob/master/INSTALL.md)

~~~
2wrist
Thats ace!

BTW It is really cool that your company does this. It has a cracking name too!

------
sitzkrieg
This is great, but unfortunately embedded doesnt always = ARM. Does anyone
know if it would be possible to target mips32 since LLVM supports it? Is there
any effort in rust for other arches? The mplabx + xc32 +harmony toolchain has
got pretty darn awful so that would be amazing for the MIPS community

------
neilv
Maybe using an ARM dev board boosts acceptance of this book among its target
audience, at the moment. But, for open source hardware goals, a RISC-V board,
such as the HiFive1, would be good cross-promotion/support.

~~~
neilv
Imagine Rust being considered _the_ way to develop for embedded RISC-V, from
almost the start.

Similarly, as long as Rust is already shaking up C/C++ a bit, they could nudge
some hobby/education and professional development towards RISC-V. (Especially
on embedded, right now, as I've heard the open ISA is attractive to some
projects.)

~~~
johnisgood
I feel the same way about Ada and RISC-V, to be honest.

[https://blog.adacore.com/ada-on-the-first-risc-v-
microcontro...](https://blog.adacore.com/ada-on-the-first-risc-v-
microcontroller)

[https://hackaday.com/2018/10/08/programming-a-risc-v-
softcor...](https://hackaday.com/2018/10/08/programming-a-risc-v-softcore-
with-ada/)

[https://riscv.org/2019/01/adacore-joins-the-risc-v-
foundatio...](https://riscv.org/2019/01/adacore-joins-the-risc-v-foundation-
to-provide-c-and-ada-compilation-support/)

------
jwr
So, Nordic Semiconductor, when do we get Rust support in your SDKs? Please?

~~~
childintime
At least the soon to be released ESP32 successor seems to get this, by virtue
of adopting a RISC-V core. Kind of a big deal really.

~~~
jrrrr
[citation needed]

~~~
childintime
My info is mainly from:
[https://www.esp32.com/viewtopic.php?f=2&t=9768](https://www.esp32.com/viewtopic.php?f=2&t=9768)

I was incorrect, citation: d) it is a Tensilica / RISC V are in the pipelines.

So not "big deal" RISC-V yet, probably later.

------
truebosko
Would love to learn Rust and currently debating on a few home applications.

Any ideas from the HN crowd? I'm currently looking at a Pi-based weather
station where I would use Rust as the processing server for all the data each
day. Nothing fancy, but perhaps a fun way to learn.

------
k__
I know some embedded devs who say Rust is still too slow compared to C.

What do they mean?

~~~
jononor
That they are happy with C and are sick of others trying to convince them to
use something else. Only halfway joking... But if you really want to know what
those people mean, then you should ask _them_.

