Hacker News Reader

Comment by the__alchemist | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com