
Discover the world of microcontrollers through Rust - ingve
https://japaric.github.io/discovery/
======
shijie
This is exactly, exactly what I've been looking for. As a software engineer
whose professional career has focused entirely around the web, embedded
systems is a strange, enticing landscape with what seems to be an "old guard,"
that eschews the frenetic pace of web technologies and frameworks, and relies
on old, proven, get-shit-done tooling and technology. Which is amazing. But it
also means that no one is writing blog posts on medium about this stuff, and
beginner tutorials are sparse. For spoiled Elixir devs like me, this is
perfect.

~~~
pjc50
Microcontrollers have got a lot more accessible since Arduino. There's lots of
beginner material out there, although admittedly not on Medium.
(Unsurprisingly, the people involved prefer a more bare metal approach and put
it on blogs or forums instead)

The tooling is nearly always C, so it's interesting to see Rust moving into
this space. Memory management is not so much of an issue, but multitasking
correctness is; perhaps there will be some new micro-RTOS framework with
provably correct interrupt handling. (We have sel4, but that's not quite the
same thing)

As you get more low level, the tutorials get sparser. You move into FPGAs,
where you have a choice of two languages with 1970s design principles, or
third-party tools which work despite the manufacturer's total closedness. As
you go deeper into actual IC design, nobody will attempt it without
supervision from someone experienced to tell you all the little tricks. And
then there's _analog_ IC design, which is basically black magic.

~~~
awelkie
What kinds of things would you want proven correct about your code's interrupt
handling?

~~~
pjc50
Mostly whether the mechanism for passing data to and from the main program is
sound; but also whether things like interrupt priority make sense and whether
your re-trigger handling or re-entrancy are going to work properly (an
interrupt happens while you're in the handler for the same interrupt). It
might be sufficient simply to have a good set of primitives for this, rather
than an actual proof.

Basically whether it's going to deadlock or miss interrupts. Deadlock is
immediate disaster, but at least the JTAG will help you .. if the device
hasn't self-destructed. Missing interrupts is worse because it's extremely
hard to debug.

Forcing DMA to behave would also be great, although this isn't strictly a
microcontroller issue. I've seen a few war stories where people are trying to
debug memory corruption where the program is completely correct - but _some
other_ device has simply DMA'd over it. I think this was involved in
[https://googleprojectzero.blogspot.co.uk/2017/04/over-air-
ex...](https://googleprojectzero.blogspot.co.uk/2017/04/over-air-exploiting-
broadcoms-wi-fi_11.html) too.

~~~
awelkie
I believe rust's safety guarantees are enough to ensure the soundness of
passing data to/from interrupt contexts and interrupt handler re-entrancy. See
rtfm[0] for an example and a good explanation. I think DMA handling can be
made safe by using the right abstractions, and then you'd just need to trust
that any piece of code that accesses the memory uses the abstraction instead
of accessing it directly.

Checking interrupt priorities sounds like an interesting problem. What is the
state of the art in deadlock prevention? It would also be cool if you could
tell the compiler "I need this interrupt handler to return in less than n
clock cycles." I wonder if someone could write a rust compiler plugin to check
that.

[0]: [http://blog.japaric.io/fearless-
concurrency/](http://blog.japaric.io/fearless-concurrency/)

------
bluejekyll
At the recent RustConf I got to take a course working with TockOS. I highly
recommend people check it out: [https://www.tockos.org/documentation/getting-
started/](https://www.tockos.org/documentation/getting-started/)

It was a lot of fun to work with and looks to have a growing set of common
drivers, etc.

The OP guide looks to be lower level and wonderful for learning. Reading
through it very quickly, it looks very thorough, well done!

~~~
kfihihc
I like TockOS too. As a hardware product manager, I look forward to use it in
next project.

------
ChuckMcM
This is well done, with lots of explanation around the bits that hang up a lot
of people. Also Windows System for Linux (WSL) has become useful enough for
embedded system development without running virtual machine. That helps
minimize complexity a bit further for Windows users.

------
wlesieutre
Anyone know what would be required to get Rust running on the ESP32 boards? I
picked up a couple for $6 each (Wemos LoLin32), and it's an impressive board
for the price. Wifi and bluetooth built in.

I assume it's non-trivial or someone would have done it already, but I'm
curious if it might happen eventually. Been poking at C which is already a bit
out of my wheelhouse, but it'd be a good excuse to check out Rust too if I
could.

~~~
peller
I don't know about Rust, but MicroPython runs quite well on the ESP8266/ESP32
boards. Might be worth investigating if you're looking for something a bit
more accessible than C.

[https://github.com/micropython/micropython-
esp32](https://github.com/micropython/micropython-esp32)

~~~
MrBuddyCasino
Or this one for the Wrover:
[https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo](https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo)

------
Mister_Snuggles
I've dabbled with microcontrollers on and off.

I started with the Basic STAMP, played around with things like the OOPic,
tried my hand at PIC assembly on the 16F84 and 16F877, enjoyed the AVRs
(ATmega328 and ATmega644) for a while, dabbled a bit with the ultra-low-power
MSP430 (via the Launchpad), backed the MicroPython project and got a
controller out of it, and have some ESP8266 boards that are just waiting to be
played with.

All of that was self-taught via online tutorials and forums. While some of
this stuff is obscure, there's a ton of information out there for anyone to
learn it.

The biggest barrier to entry is money - developing for these platforms
requires buying hardware, both the controllers themselves but also the
programming tools (e.g., I use an AVRISP mkII to program ATmega chips). Many
controller manufacturers make development boards that include a programmer,
controller, and various peripherals to play with - this particular post
focuses on the STM32FDISCOVERY board which seems to include the programming
tool, a button, some LEDs, plus breaks out the controller's pins so that you
can hook up whatever you need.

~~~
fuzzythinker
The biggest barrier to entry is not money but time. Every year the boards get
cheaper while being more powerful. A esp8266 costs just $5 now and it comes
with wifi. A wifi board for older boards that don't come with wifi costs > $5.

The biggest barrier to entry is time because unlike web or other higher level
software stack, blogs and github resources are no where near the level you
feel like you can figure out how to make something work other than Arduino and
RPi platforms. Want to learn how to code Beaglebone's PRU with rproc and not
the deprecated uio? Good luck. Want to learn how to configure TMC2130? Good
luck. In order to drive the micro-controller space forward, the IC
manufacturers really need to produce thorough tutorials that newbies can
understand and get up to speed, and keep them up to date. Just take a look at
Deep Learning, which became popular no sooner than micro-controller world did.
I can easily list 5 top tutorials and MOOCs where a newbie like myself can
follow and get some meaningful understanding or output from it. Deep Learning
is arguably a much tougher and vast topic as well.

~~~
IshKebab
That's because basic deep learning is simpler than the advance microcontroller
features you listed.

There are plenty of Arduino courses too.

Also microcontroller manufacturers don't really make their money from
hobbyists.

~~~
d21d3q
I would place arduino among higher-level programming. Since you are not
touching registers and you don't know what is under the hood of Serial.print()
(buffers? Circular one that can overflow? blocking? Interrupt driven?) It is
more for playing around with prototype.

------
anta40
Is there any significant work to add 8-bit microcontroller support to Rust?

~~~
revelation
Rust is by definition for new projects, so there are simply no more 8-bit
microcontrollers around. Those things are moving into museums. And good
riddance, M0s are soo much better.

~~~
shakna
> so there are simply no more 8-bit microcontrollers around

Atmel still produce a significant number of 8bit AVRs.

~~~
revelation
Atmel have just been bought by Microchip in an industry-wide reorganization
that is sure to swallow the 8 bit micros.

And of course they still make tons of them, it's embedded, you need to supply
these chips for another 10 years for old designs.

But you shouldn't use an 8-bit uC in a new design.

~~~
Kelbit
Microchip's bread and butter is still cheap 8-bit controllers like the
PIC10/12/14/16/18 families. Many devices don't need a 32-bit core, so wasting
a few cents on each unit by specifying one drives up cost at high volume.

While the core of a 32-bit controller doesn't take up much die area at smaller
process nodes, core size has never really been the limiting factor with MCUs.
Look at any MCU die - the flash and RAM both dominate in size over the logic.
Going to a 32 bit controller generally means that your instructions are going
to be wider, so your program space is going to take up more flash. You will
also tend to use more RAM unless you are judicious about word size, and a
context switch on an RTOS will cost more memory since the context contains
much wider registers.

Another pain point with the 32-bit MCUs is that ARM currently dominates the
market, and their licensing fees add a few cents to the cost of each part -
which can be a killer at volume. There have been attempts to break ARM's
monopoly (most notably Microchip's MIPS-based PIC32 series) but it seems like
ARM will continue to dominate this space in the years to come.

As a final note, SiLabs recently introduced an ultra-low power microcontroller
line based on the venerable 8-bit 8051 core, so clearly they think that 8-bit
MCUs have a role to play in the years to come.

------
PascLeRasc
>"But what's this ttyUSB0 thing? It's a file of course! Everything is a file
in *nix."

Isn't this not really true? I remember it was a long point of discussion in an
embedded class I took years ago but can't remember exactly what was said.

~~~
jononor
Many of the APIs for devices are through special ioctls, not through
read/write of the file contents. Possibly what was referred to.

------
dopeboy
Started out with the 8052 in college. Graduated to the PIC. Upgraded to the
AVRs. Last seen with Xilinx FPGAs before being kidnapped by fullstack web
development.

Man do I miss this stuff. Articles like these make me want to get back into
it.

~~~
MrBuddyCasino
Why did you leave? I'm making the opposite journey right now, minus the job
switch.

~~~
tw1010
Not the parent. But I've done a bunch of both hardware and software and
frankly I would go for software any day of the week. It's a lot harder to get
into a flow with hardware. And it just feels a whole lot less free than
software. You can go from pretty vauge idea to a working prototype very
rapidly with software, but with hardware that both takes a lot longer and the
types of things you can imagine is a lot more constrained.

If you want a taste, go build some stuff in pure x86. You'll pretty quickly
get tired of it and will want to build higher order abstractions, and then
you're back in software-land.

~~~
MrBuddyCasino
Interesting, I felt the opposite.

Doing stuff with hardware expands your creative horizon to do things in the
real world, freeing yourself from the confines of the virtual realm. 3D print
what you need, make it come alive with MCUs.

Also much of modern software development feels like just plugging lego bricks,
but in embedded you actually have to know how stuff works, down to the
register level.

But then those were purely hobby projects, maybe it feels very different when
doing it for a living.

------
JustFinishedBSG
I got an STM32 Nucleo board some time ago that is sitting in a drawer. I want
to learn Rust, would it apply?

