Rust on ESP32 was great at one point. ~1 year ago there was a major HAL re-write and consolidation, and it went for me from working, to very broken, with most of the recent commits revamping it being done by someone who was neither an Espressif employee, nor someone who had written the original code bases. I haven't checked it since then.

I bring this up as for some workflows, Rust is one of the easiest "just works" embedded toolchains/workflows; my experience here was jarringly different, especially as it had been a good workflow prior. On this project, I ended up switching to ESP-Hosted (Official Espressif firmware to let the ESP be a radio co-processor), writing my own Rust lib to interface with it over SPI or UART, and using an STM32 as the primary MCU running my [rust] firmware.

I’d completely agree - the transition to and instability of esp-hal has been a complete nightmare and I’ve also given up on trying to keep up with this.

I have transitioned to using the Nordic NRF chips (nrf52840) for my hobby projects which are very well supported by embassy-nrf and have been a pleasure to use and have great (and stable) BLE support. You can also get really cheap boards from AliExpress (search for nrf-micro).

+10000

I was literally told in one of the comments i made about how difficult a lot of the changes were, for very little practical gain:

"the new API WILL require you to rethink your code

the new API WILL be a bit harder to use for Rust newcomers, as they really need to think about lifetimes, mutable aliasing and so on"

etc

Their argument, of course, was that it was "technically better" anyway, as if that is the bar by which you should make things super painful for your customers and newcomers.

ESP non-rust works pretty darn well.

But ESP-rust feels like it's just a mess run by folks who simply don't value their customers time.

I either use STM32 or NRF exclusively now, and could not be happier.

“the new API WILL require you to rethink your code”

I recall we had roughly the same experience. Tried to use the OTA API that was rewritten and it was a disaster. The contributors opinion was atrocious, and we had deliverables to deliver so we ended up just hacking it and using unsafe globals to workaround how opinionated it was.

Ive been developing rust embedded applications for about 5 years, so im not new to it either.

I get people want to be ideologically biased with how they structure code, but a public API should be flexible enough to work in a wide range of situations, and what irks me about it is that there isn't really much benefit, if at all, for the pain, time and money it takes to adjust it.

Also probe-rs went from barely working to working somewhat to now being back again to barely working for most chips

Oh yikes! What happened? Do you know roughly what version regressed and which chips? (I was tracking Probe-RS as one of the best parts of the ecosystem)

Damn I am not the only one then.

Also entirely on STM32 now too which is rock solid and the easiest embedded programming has ever felt. probe-rs, defmt, embassy w/async HAL. Life is good man.

Would it be possible to fork the previous (good) version?

Yes, but it will be some work, and the most likely outcome is you would be the only person who uses it.

The [page on testing][1] suggests this:

> Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device.

When I have tried this I have encountered multiple problems, first that the Rust test framework requires std, making it convoluted writing test code – but when working around that using conditional compilation, I run into other things like the `esp-hal` depending on crates that won't compile on the host.

What is the recommended way to test on the host?

  [1]: https://docs.espressif.com/projects/rust/book/application-development/testing.html

Especially for embedded work (but for regular software too!) I've bought into the "sans-io pattern" for a lot of the software i write anymore

https://sans-io.readthedocs.io/how-to-sans-io.html

Keeping all of the actual hardware/network/io interface code separate really makes writing unit tests and porting to different computers much simpler

I do something similar. I have all my esp/idf code in one crate and all my business logic in a separate crate. The business crate has no dependencies that won’t compile/run on the host. This is where all my tests live.

This is good advice however it should be noted that many of espressif's other purely software components depend on esp-hal, so you still want it to compile if you use any of espressif's provided components.

Interesting pattern but it sounds like it's fundamentally incompatible with setups using embassy

https://embassy.dev/

Why would that be? one of the nice features of the sans-io pattern is that it seperates your HAL from the program itself; if your state machine says "send a network packet", send it using embassy (or tokio or bsd-sockets or whatever). The underlying libraries have little or no bearing on "write your program as a big synchronous state-machine"

same goes for "wait 10 ms" or "change this gpio pin".

I don't use the the builtin testing framework, or std, and I often explicitly use a no-heap crate. Check out Embassy and you'll be free to ignore pretty almost everything suggested here, especially when developing and testing. I create a separate [bin] for each test (I usually run out of flash to fit all the tests into a single binary), and a few lines of bash/python to make a test runner/reporter for all the flashing and running of tests. Sometimes I flash up to 50 times a day and haven't lost an MCU (AVR-Rust, ESP-Rust, STM-Rust) yet due to too many writes.

[0] https://github.com/embassy-rs/embassy

``` #![cfg_attr(not(test), no_std)] ```

Test code doesn't need to live on the device itself. You can call no_std code from std code and tell the compiler "hey, this code is only ran on hosts that have access to std" without trying to bundle the std library into your no_core code. You're not going to able to test I/O (does this function actually set Pin0 to HIGH or LOW) but you can test logic.

This is a constant issue for me in every facet of embedded development - with the sole exception of devices that can easily be tested in a qemu environment.

I would also love to hear that the authors of this book suggest.

I've got an ESP32-S3 original that was festering in a drawer. Took it out a few weekends back and plugged it into a claude session. Within a morning it was running a custom rust firmware that was showing the monitoring overview for the $WORK network. Considering I've got very minimal rust experience, to be able to spin up a custom firmware in such a short time really was something. Not sure I'd trust in on the network without doing an audit of what it's doing, but as a fun Sunday experiment, it scratched the itch

awesome to see this under espressif.com! that's so fantastic.

not to the point here, but i wonder what Zephyr would have been like if Rust had been more of a thing at the time. that's not really possible, as from my understanding it derived from Wind River Systems' donated Rocket OS, which i think predates Rust (which is not a new language!). still an interesting what if to me: zephyr seems to be the embedded os with the best wireless support by a country mile, have a lot of companies targeting it (often alas forking it rather than going upstream): it holds my interest the most.

I love that you people can't take a joke from the people actually doing the work.