Rust on Espressif chips Q1 2022 | Hacker News Reader

Rust on Espressif chips Q1 2022

mabez.dev

109 pointsmabez28 comments

Rust and esp32 was a rough ride for setup. The pthread rwlock thing stumped me for a while because I missed `esp_idf_sys::link_patches()` in main. I eventually found that missing piece and got it going.

It's hard to tell which MCU is pulling ahead for me. Rust/esp32 is so new it's not even merged to mainline llvm and I'm constantly updating esp-* libraries. OTOH, AVR/Arduino has been "just working" for me except you're stuck on a Rust build that's over a year old now due to a bug.

And then both architectures seem to suffer a bit because I stuff all the toolchains in a container, lest they explode all over the filesystem. But then VSCode can't really autocomplete anymore since it doesn't have all the pieces.

That all said, they're both super fun and it's nice to see things moving along.

I've had pretty good luck with rust on stm32. Toolchain was just a matter of `rustup target install thumbv7m-none-eabi` and `cargo-embed`. The little bit of mismatch between the various HAL projects makes switching specific MCUs un-fun, but as long as you're just sticking with one, I would recommend.

The esp32 vs avr split covers a pretty wide range of needs. esp32 for wifi stuff, horsepower, or just more pins. The AVR is for power sipping things: ATtiny pulls 10nA(!) in deep sleep and you don't need a voltage regulator on a 1s lithium cell.

Since this is all hobby projects anyway, I may pick up an stm32 board for the next round just to see what's up.

I'd recommend an STM32 for now as well, it was quite easy to get a project going in Rust on those chips.

I wrote [this STM32-Hal lib](https://github.com/David-OConnor/stm32-hal) that makes switching easy. Switching between and within STM32 families is transparent, with some exceptions like DMA MUX.

This is fantastic! Thanks for sharing. I’m excited to try this on my next project

What's the equivalent step to CubeMX, manually selecting compatible features to turn on in cargo.toml and declaring which pin (if applicable) yourself?

VSCode can run with its backend in a container:

https://code.visualstudio.com/docs/remote/containers

That's pretty cool.

Been learning a lot of rust recently. Can't say it'd be my first choice for application or web server stuff when there's GC'd langs available. But I'm over enough of the learning curve that I prefer it to C or C++.

Yah if this had been out a few years ago I probably would've gone with Rust on the embedded route. Instead I tried Nim since it could compile to the ESP32's. Turned out that I found it more pleasant to read and write and easier to integrate with ESP-IDF. Nim's ARC is fast enough to not be a hindrance 99.5% of the time on the ESP32's -- heap allocation is the real performance/latency killer. Rust can bite you there as well (its easy to forget about free's at the end of a block!).

Still Rust seems nicer than C/C++ for a lot of applications. I'm glad there's a couple of options for better safety / security in embedded.

Just to add to this, I use Nesper (your project) extensively :)

And the experience is exactly as you’ve described

Great to hear!

I'm putting together some pull requests at some point in the near-ish future to bring it up to date with ESP-IDF 4.3 and add some more interfaces for some modules (esp_pthread.h and some others). It's working quite well on Nim v1.6.4 -- though I set my project up with PlatformIO and adjusted the CMakeLists.txt to read nimcache, and wrote my own nim.cfg

I'll likely setup a new template project for all of that, as I think PlatformIO's lib folder allowing people to add C libraries (including their own they write) and manage, build, and flash their boards is quite nice. Its a bit different to how Nesper sets up its project, so I reckon a secondary template project is the way to go.

Wrote my own tasks too, just to be sure.

Honestly one thing I'd love to do is see if I can get Nim calling the ESP32 toolchain itself: compile out to object files and just have CMake link them, rather than the current --compileOnly:on approach. Might be more trouble than it's worth though!

Also, I have full JTAG debugging (including breakpoints in the Nim source) working remarkably well!

That's awesome! I'd definitely be open to PRs for Nesper. Long term I think even a pure Nim RTOS would be awesome too complete with cross compiling and linking.

Let me know if you ever get a chance to do a writeup for using JTAG with Nim and ESP32's. I've never tried it, but it'd be cool to show it to people.

For desktop definitely, but for ESP32 GC is ofc pretty rare. You have ~350KB of ram, and usually 100-200 of that is for the wifi stack, bluetooth stack etc. Normally you want direct control of memory.

Micropython is actually great on ESP32 despite having GC and unless heavy number crunching / camera stuff happening, it feels to be the a really good tool for the job.

There are also the ones with PSRAM, where you seem to be able to ps_malloc() about 4MB of it.

Depends on the “GC”. Reference counting (plus actual memory management) has worked really well for me on the ESP32

More than enough when compared with an IBM 704 mainframe.

I'm with you - I think it's a great fit for low-level things where you'd normally use C. (including embedded), but don't see a compelling reason to use it for a web server.

As someone who is using Nim on the ESP32 for work, I'm curious how external driver binding works. The ESP32 is great on its own, but we rely on so many external peripherals, and I'm not well versed in binding those sorts of things within Rust (and within embedded Rust, specifically)

Nim feels like it would be a great option for interoperability with the existing ecosystem of OSes, LwIP, USB stacks, etc.

OTOH, my experience of those libraries has been decidedly mixed, with it being relatively easy to get things apparently-working only to later sink dozens of hours into debugging that occasional weird crash.

Oh for sure, and there are still some impedance mismatches that absolutely exist while using Nim to target a fair few of those libraries. It's part of why we still use a decent chunk of C.

That said, a lot of those weird crashes we run in to even in pure C itself. ESP-IDF has some... quirks. Don't get me started on heap corruption.

The joys of embedded, I suppose.

If anyone has got PPPoS working with LwIP, I'd love an email haha.

Zephyr has PPPoS, in theory at least [1]. I've wanted to try it but haven't had a reason. Zephyr's heap is better too. Though the esp32 support isn't as complete.

https://docs.zephyrproject.org/latest/reference/networking/p...

Yeah we tried to go the zephyr route! I reckon we’ll revisit it in about six to twelve months when we move to ARM instead of ESP32

Next up should be the xtensa based hifi dsps in NXP imx series socs but those have fewer users and developers I’m sure.

I hope we get a RustDuino IDE or something like it one day. A lot of Arduino's problems(Maybe almost all) might go away with a different language.

It's nice to see Rust on embedded moving beyond being Arm. And, it's tough to beat ESP for wifi.

Reply on news.ycombinator.com