Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • BUN in oven
    by effnorwood
  • 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
    by _joel
  • 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.

    by jauntywundrkind
  • This mirrors my experience also. I want to use embassy, and have tried several times. It gets recommended to me by people whose opinions I trust, so I keep trying. But Zephyr just works.
    by bobmcn
  • 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
    by iconara
  • 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.

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

    by waterTanuki
  • 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

    by officialchicken
  • 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

    by bigfishrunning
  • 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.

    by the__alchemist
  • Would it be possible to fork the previous (good) version?
    by speed_spread
  • 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.

    by jpgvm
  • 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).

    by _paulc