For what it's worth, the entire esp32 family is officially supported in Rust by espressif themselves [1], and the stm32 family is probably one of the most widely used cortex-m families in embedded Rust as well[2].

[1]: https://github.com/esp-rs

[2]: https://github.com/stm32-rs

Right, though Espressif's official support for anything should be taken somewhat with a grain of salt ;)

Having used their tools at work in anger for years at this point, there is a lot of gotchas, issues and bugs with their bindings at this point -- not all of which is Rust's fault, but the underlying problems with ESP-IDF itself.

That said, its getting better over time, so I'm keeping a close eye on it (and we keep some experimental projects up to test it every couple of months).

The upside of Nim is that "it's just C" at the end, with all the upsides and downsides that comes with.

I'm very hopeful though!

Edit to add: We started this project quite a while ago, too, which forced our hands. Writing unsafe Rust is a pain, so I didn't want to take the burden on for managing bindings myself at the start. If we were to start again, maybe we'd have made a different choice, but Nim at least eased the pain quite a bit.

Doesn't the ESP32C3 have native rust support -- no esp-idf or espressif official support concerns need apply? Are you stuck on the S3 exclusively?

We are stuck on the S3, yeah. The C3 is lovely, but doesn’t have everything we require, at least currently. Might change in the future but not right now.

Esp-rs has come a long way although it's still very much in a beta phase.

Ah I was writing a reply to someone else as you commented this :) We've got experimental projects with some ports of our firmware to it already, but there are lots of showstoppers that we've run into (some of which are ESP-IDF's fault more-so than esp-rs directly). In the medium-to-long-term, I'm really hopeful we can move to it. Not quite there yet for our production use cases though unfortunately.

If the lack of some services allows it (maybe not given the chip, but it was enough for me) I recommend using esp-hal+esp-wifi rather than esp-idf-hal, it is a pure rust 'rewrite' and it's been a great experience compared to esp-idf(c++). Default is bare-metal but embassy resolves most of the need of an rtos.

I'll check it out! While it's unlikely that we're going to rewrite this firmware anytime soon, being able to leverage Rust for future projects would be nice. The big thing for us is, we use basically every peripheral and driver that ESP-IDF has, along with some extra third-party ones for some other peripheral chips we run via our daughterboard setup -- and currently today, a lot of that isn't supported yet.

Definitely keeping an eye on it though. The future of Rust on the ESP32 chips is promising!

I don't know what the issue is but I've tried esp-wifi on the ESP32-C3 with the examples and nothing would run. It's a bummer since I'd have liked to leverage the Bluetooth support for my project.

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed.

[0]: https://github.com/esp-rs/esp-wifi#current-support [1]: https://github.com/esp-rs/esp-wifi#ble

Thanks for mentioning it. I already tried using it a few months ago and brushed it off as still being a WIP, but it still didn't work when I tried again just a few days ago. Asking in the Matrix chat when first trying it sadly only got me a "works for me" from the developers.

What Espressif is doing with their esp-idf and porting it to Rust is promising, but overall it still needs work. Using the toolchain to develop on the ESP32 was at least slightly painful half a year ago before they introduced espup[1], having to keep a patched LLVM around etc., and supposedly support for their Xtensa architecture is coming to LLVM soon[2] so this will improve in the future.

I'd also love to see Bluetooth support in esp-idf-svc[3], but they seem to be lacking people with the required knowledge to design and implement an abstraction for it[4].

[1]: https://github.com/esp-rs/espup [2]: https://mabez.dev/blog/posts/esp-rust-24-02-2023/ [3]: https://github.com/esp-rs/esp-idf-svc [4]: https://github.com/esp-rs/esp-idf-svc/issues/55#issuecomment...

That’s about my experience too. Which is far too fiddly for us to rely on at work for production tasks. I basically keep checking back every six months or so: I’m hopeful that in a year, year and a half, I could replicate what we’ve done with our project on esp-rs entirely. Fingers crossed anyway, but right now there are quite a few showstoppers.

Do you really need CMake? Are clean compilation times very slow?

ESP-IDF is pretty dependant on it, sadly. I’m halfway through getting to the point where I can build it without!