Mabez Rust on Espressif chips – Q4 update | Hacker News Reader

Mabez Rust on Espressif chips – Q4 update

mabez.dev

58 pointschildintime17 comments

For anyone interested in trying rust on Espressif and/or Risc-V: Support is rapidly improving. Right now (Or at least CAO 2 weeks ago), the (semi?) official packages had dependency mismatches making getting started a pain. (Think pinning Git dependency patches), but overall, not a bad experience.

The IDF is interesting, in that it works with the standard library; not the usual embedded experience, but I don't understand the mechanisms by how they made it work, or how much of the networking etc would work the same was it would does on a PC.

I was unable to get probe-rs and defmt working with it; maybe will give another try, as this article points to it working.

Note: Note all the the official dev boards have JTAG connected to USB. Check for that specifically.

The rust standard library support was not that complicated to add because a) esp-idf ( with the FreeRTOS kernel) is used underneath b) esp-idf has unix like features and exposes a posix layer for stuff like networking and filesytem. If you want to look at the full initial PR on rust-lang github look for PR number 87666.

Regarding defmt and probe-rs, here are some resources: https://esp-rs.github.io/no_std-training/03_6_defmt.html and https://esp-rs.github.io/book/tooling/debugging/probe-rs.htm...

I've looked at Rust-on-ESP a number of times in the past, but it's never been at a level of "I can make an LED blink within an hour or so". Is there a write-up for interested but not deeply involved people somewhere? How far are we from "clone this, run ./flash and the LED will blink"? How hard is it to use existing Arduino libs (e.g. MQTT, popular sensors, FastLed), or what would the ecosystem look like? I keep daydreaming about replacing my C-IoT-home mess in Rust in the meantime. :-)

This is what I threw together: https://github.com/David-OConnor/esp32c3_quickstart

In theory, there is a quickstart CLI tool that should generate a project, but it is currently broken. This is the repo I set up that "just works" for C3.

Ya, the tooling is improving (e.g. https://github.com/esp-rs/espup) - but still, the experience with Rust is always interesting; I try it every few months, then give up as it breaks, sometimes check tinygo, then realize it's still missing wifi/bt support, and go back to c. Micropython is interesting, but also the developer experience around the tooling isn't great. I was spoiled with rails imho.

(if tinygo supported more than one core, and had wifi/bt support on esp32, I'd not be looking back that often)

Hopefully it will continually improve given that at least one person is paid to work on it full time. It's come a long long way over the past few years.

> In theory, there is a quickstart CLI tool that should generate a project, but it is currently broken.

Which tool do you mean? `cargo-generate` it's working fine for both templates:

- esp-idf-template(std): https://github.com/esp-rs/esp-idf-template)

- esp-template (no_std): https://github.com/esp-rs/esp-template

Yep - that's what I'm referring to. Broken as of when I tried 2 weeks ago; can't speak to it currently.

If you are using esp-idf-sys you can include external C library's. Beside it providing all the original esp-idf C bindings, it can include either locally vendored library's or (using the esp-idf component manager) remote components.

You just need to declare them correctly inside your Cargo.toml and it will automatically expose it all inside Rust. Though i have to say using C api's can be a hazard and to effectively using it you now have two problems as a potential rust beginner. First you need a good rust unsafe understanding and second you need good C understanding. So nothing i would recommend to a beginner, in either of this fields.

Don't do esp-idf-* with rust.

Really.

ESP-RS (baremetal) is usable, and nice.

I would happily recommend it if you can live with the state of bluetooth/wifi not being awesome quite yet.

ESP-IDF-* is a consistent mess. APIs break continuously and in ways that are often hard to upgrade.

It is very difficult to find a combination of library versions that work with anything else in the ecosystem (embedded-), mainly due to esp-idf not keeping up or doing weird things. This is deliberate - they want to move esp- everything forward together, which is nice, except nobody else in the entire embedded ecosystem is on their release schedule so the result is things are always broken. Even funnier is that this all happens while esp-idf itself is rather stable and usable.

In fact, at various times, it has been in a known-broken state with the latest stable ESP-IDF for months. Known broken here doesn't mean "some stuff doesn't work". It means "it doesn't build at all and requires you hand-patch git checkouts to make it work".

You can read how at least one main maintainer responds to issues (which basically amount to explaining why everyone else is wrong and they are right. It's fun to watch them recommend their own libraries as the one-true-way and tell people that they think it's a mistake to use loops so they don't care that something doesn't work), and get a good feeling for why all the above is true.

Everyone else in the community is quite nice and reasonable, and seems to care about users.

But at this point, i'm literally taking projects I wrote in ESP rust and moving them back to C++ (one right now, in fact, i'm taking a break to write this comment) and will try again for years.

Given how it has gone, and the direction that certain folks push in, i don't have a lot of faith it will get significantly better.

If you want to do baremetal, do it and live with it. If you want to try to use esp-idf, i would highly recommend you don't do it.

I literally have to keep copies of patched, pinned, libraries and sdks to something that works in the esp rust things i have.

For future rust work, i will only use things supported by embassy.

Great info, with this caveat:

> I would happily recommend it if you can live with the state of bluetooth/wifi not being awesome quite yet.

ESP32's main niche is embedded WiFi and Btle. With Bluetooth there are some alternatives, but Espressif is the nicest. For Wi-Fi, there are no integrated alternatives I'm aware of. So, if I'm on ESP, it's probably because of WiFi and/or Btle, which makes IDF appealing.

I know. I actually use to get easily integrated lora without hats, etc (through heltec's ESP stuff), along with bluetooth for updates.

But the state is why i couldn't use baremetal at the time - the firmware kept crashing.

For this kind of thing, NRF's softdevices are a much nicer alternative and work fine in embassy.

I was just blown away looking at code for Embassy, some sort of Rust embedded framework. Are these competing projects? Complimentary ones?

Embassy is a separate project, but you can use it's framework directly on either the no_std or the std(esp-idf) esp projects. For the no_std variant they provide a special version of a embassy_executor tied to the esp's and for the std case you can use whatever runtime fits your bill from tokio to smol to embassy.

That sounds promising but probably another quarters wait for good measure given my decidedly modest rust skill

The learning curve is quite step especially if you don't already have a good understanding of embedded systems.Funnily enough we see many rust beginners + embedded beginners directly jumping on the bandwagon and joining the Matrix channel playing around. I think there is no right or wrong answer to the question of when to start trying it out, or leave it be.

Reply on news.ycombinator.com