Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust on ESP Book

docs.espressif.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: The Rust on ESP Book

#11

Post by the__alchemist »

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.

Re: The Rust on ESP Book

#12

Post by _paulc »

the__alchemist wrote: post #11

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"…

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).

Re: The Rust on ESP Book

#13

Post by DannyBee »

_paulc wrote: post #12
the__alchemist wrote: post #11

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"…

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 n…

+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.

Re: The Rust on ESP Book

#14

Post by waterTanuki »

iconara wrote: post #2

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 `…

``` #![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.

Re: The Rust on ESP Book

#15

Post by waterTanuki »

bigfishrunning wrote: post #4
iconara wrote: post #2

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 `…

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

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

https://embassy.dev/

Re: The Rust on ESP Book

#17

Post by jpgvm »

the__alchemist wrote: post #11

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"…

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.

Re: The Rust on ESP Book

#18

Post by _joel »

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

Re: The Rust on ESP Book

#19

Post by ost-ing »

DannyBee wrote: post #13
_paulc wrote: post #12

Earlier quoted context omitted.

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 n…

+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…

“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.

Re: The Rust on ESP Book

#20

Post by speed_spread »

the__alchemist wrote: post #11

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"…

Would it be possible to fork the previous (good) version?
Post reply on HN