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).
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
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?
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.
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/
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.
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.
BUN in oven
I love that you people can't take a joke from the people actually doing the work.