
Rust on the ESP32 (2019) - lnyan
https://mabez.dev/blog/posts/esp32-rust/
======
rbtying
I’ve been playing with Rust on the ESP32 using these tools on and off over the
last couple of months or so, relying more in linking to the existing
FreeRTOS/C HAL for accessing the peripherals.

One thing I haven’t quite figured out: a substantial number of onboard
features are configurable at image build time, which then change the effective
C libraries via preprocessor definitions. So, it doesn’t quite work to naively
run bindgen on the header file once, and then embed that in a -sys crate and
put it on crates.io

I think you can hand craft a -sys crate with all the appropriate config
options as cargo features, but that seems both very time-consuming and likely
to drift from the newest esp-idf versions. The alternative of running bindgen
periodically (e.g. as part of the build process) works fine for one project,
but then how do you publish reusable libraries online?

~~~
MrBuddyCasino
The ESP32 API surface is huge, and the libraries have many configuration
settings. Rust-ifying this is a huge endeavour. One way could be to just
interface with the vendor HAL using Rust wrapper, but doing that in a safe way
that respects the lifetime rules can't be easy? Also AFAIK some lower level
radio APIs are locked and hidden behind a binary blob, so the ESP32 can't be
misused as a jammer.

Its very tempting to try this due to the huge amount of resources the hardware
has, but it is a huge amount of work. Just being able to access the registers
isn't very valuable, the ESP is about Wifi, BT and I2S. If there are no
ergonomic Rust APIs for those, why even bother?

~~~
elcritch
It's true and a bit surprising how much of the ESP32's API's are configurable
or change based on config options. Espressif has built an impressive amount of
functionality on top of FreeRTOS. It'd be nice to see Rust more widely
adopted, but it seems to require an entirely rewritten SDK as so much of the
API are C macros and defines.

Given that I decided to go a middle ground and use Nim with its new ARC (GC
reference counting and move semantics). In theory it's less efficient than
compile time Rust memory management but it works well in practice. Wrapping
the C API is trivial and handles all of the C defines as well as writing in C,
since it compiles down to it. And you can use any Nim or C libraries. It's
surprisingly effective!

Except you still get data races from the C API's which Rust would likely help
prevent. So it's cool to see someone toying with an xtensa llvm backend. I
wish LLVM still fully supported a C backend so you could compile Rust to C and
build that. Hopefully in the long run, more native rust libraries will exist
for more full functionality embedded.

~~~
MrBuddyCasino
Was looking at Zig for the same reason, manual memory management but less
error prone due to "defer", and a design ethos that is very reminiscent of C.
Can even compile C directly! I really, really like the aesthetics of the
language, but there is no xtensa backend yet.

Rust might just be a leap too big and can only work in blank-slate scenarios.

~~~
elcritch
Zig seems promising too! But it’s still LLVM based (?), which seems to be a
limitation in the embedded world. Nim’s templates/macros are nice for fiddly
stuff. Not sure how Zig handles places where compile time macros can make
things nice. Yah I figure in ~5 years Rust might be better positioned in
embedded work as a goto solution.

~~~
MrBuddyCasino
If you like macros, Zig might not be for you. Part of its mission statement:

"There is no hidden control flow, no hidden memory allocations, no
preprocessor, and no macros."

------
bborud
I would really love to see more interest in Rust from the embedded industry.
With the influx of new developers into embedded programming I think there is
an opportunity.

~~~
pjmlp
Even C needs more love from the embedded industry, given how many still use
C89 dialects, even if the tooling might already support something better, let
alone languages that attempt to replace C.

~~~
Leherenn
C versions after 89 doesn't bring much to be honest. So either you want more
than what C can offer you, and usually the option is C++, or you're fine with
what you have.

~~~
hak8or
Bieng able to declare variables after statements in a function is huge,
letting you make them const as needed.

Also declaring the index variable in a for loop like for(int i =0; i < 10;
i++) is extremely helpful.

Those two alone are extremely beneficial.

~~~
Leherenn
True, they are however often available as part of compiler extensions.

------
manaskarekar
Follow up post [https://mabez.dev/blog/posts/esp32-rust-svd-
pac/](https://mabez.dev/blog/posts/esp32-rust-svd-pac/)

------
StavrosK
Does anyone know what the situation with Rust on the NRF is? It's all so new
that there's no "getting started" guide, but even figuring out which repos to
check out is hard.

~~~
dutchmartin
There are crates for that [1]. But if you are new to rust and embedded, I
would recommend to read through the rust embedded book [2] and practice with
the stm32 board.

[1] [https://github.com/nrf-rs/nrf-hal](https://github.com/nrf-rs/nrf-hal)

[2] [https://rust-embedded.github.io/book/](https://rust-
embedded.github.io/book/)

~~~
StavrosK
Ah, thanks. I'm not new to embedded, just to Rust on embedded. STM32s are a
bit too overpowered for me, I usually use ESP8266s, that's why I thought the
NRF might be a good bet (and better supported by Rust).

------
jolmg
Lol. I was expecting the article to be about how to clean up metal corrosion
from the terminals of an ESP32 chip.

------
muska3
There's also this guide [https://rust-embedded.github.io/book/](https://rust-
embedded.github.io/book/)

Although, I'm more interested in learning STM32 development, due to
recommendations that it is far superior to ESP32 boards. Anyone have some tips
on how to get started on this front as a hobby?

~~~
mdtusz
I ordered one of the STM32 development boards when this was first published.
It's fairly straightforwards to get basic blinky demos working, but it was
about at this point that I ran out of steam, and you're basically left to fend
for yourself, implementing anything more complex from scratch.

It may have changed since, but rust embedded definitely isn't hobbyist
friendly unless the goal is to make things work, rather than to just make
things.

~~~
muska3
Right, that's ultimately what I am worried about.

------
ncrmro
Was learning a lot of rust and now c and Mabez and everyone else is really
helpful on the esp-rs matrix channel.

------
rkachowski
would this presumably also run on the esp8266?

~~~
rbtying
The compiler toolchain can cross compile to esp8266, but I think the pure Rust
HAL is less developed there. If you use Rust to write components/code that
link against the ESP-IDF, I’d imagine that would work?

I have the toolchain in a Docker container if you want to try it out.

