Rust on Espressif chips - 12-04-2024

This is the next quarterly update of the esp-rs effort, detailing the progress over Q1 2024.

Xtensa Rust Compiler & LLVM Xtensa

LLVM has recently moved away from Phabricator to Github for active development, which meant we had to resubmit some of our patches. We took some time to split up the patches we previously submitted, and resubmitted them; one of which has already been merged! You can follow the tracking issue we have open to follow along. Just a reminder that you only need the Xtensa compiler for the ESP32, ESP32-S2 and ESP32-S3, all other Espressif chips are RISC-V and work well with the upstream compiler.


We've put a lot of focus on esp-hal this quarter, so we have a bunch of updates to share. The biggest update is that we have unified the HAL such that all chips are now supported by a singular package, esp-hal. This effort was months in the making, and the original issue discussing merging it was opened just over a year ago! Previously we had a common library with shared implementations, which was then broken out into a hal package for each chip. With each new chip release by Espressif, we realized this was not scalable. We made the decision merge all the HALs into esp-hal, which has now been released on! Migration is quite straightforward, you can check out the release notes for the details.

If you are a contributor, the workflow within the esp-hal repository has also changed. In unifying the HAL, we realized we had outgrown vanilla cargo as a build tool and needed something more configurable. We have switched to cargo xtask to manage building packages, examples, and running tests on hardware (more on that shortly!). If you are a developer or looking to run some examples, please run cargo xtask help in the main esp-hal repository to see what's available.



In the last post, I mentioned that we now had support for all Espressif chips in probe-rs. Whilst this is an amazing achievement on its own which allows our users to use the wonderful probe-rs tooling, we also have had our eyes on something else, Hardware-In-Loop (HIL) testing. Building any reliable set of libraries and run-times requires testing. Whilst we can run some tests on the host machine to test certain bits of logic, testing drivers requires that they run on the actual intended target. Espressif already does tonnes of HIL testing for other projects such as ESP-IDF, Zephyr and NuttX, so we have the physical infrastructure, but as Rust developers, we wanted native Rust software to write and run our test cases. Enter embedded-test, which is a test harness that can integrate with probe-rs to run test cases on real devices! It has first-class support for Espressif chips, and we're already using it in our ever-growing esp-hal HIL test suite. We can't thank the author of embedded-test, Timo, and the probe-rs team enough!


We have released v3 of espflash, the most notable change with this is that we are now using Rust-based stub (instead of the ones written in C) to flash Espressif chips. What is a stub you ask? It's a small program that is loaded into RAM which espflash talks to over serial to flash new programs to the chip. Espressif chips come with a ROM bootloader, which can manage flashing, but it is very simple and doesn't always leverage the full flashing potential of the chip resulting in slower development cycles. The stub program is available under esp-rs/esp-flasher-stub and leverages esp-hal under the hood to communicate with espflash. There are of course a tonne of bugfixes, enhancements and changes, so please check out the changelog for all the details. In the spirit of testing, we've also added HIL testing to espflash, to ensure we minimize regressions between releases.


I wanted to post this before Embedded World, however I wasn't able to, but I'd like to say thanks to everyone who turned and gave us feedback on Rust support, it was really nice to interact with you all! We will also be attending RustNL next month, so if you are attending and you see us, come say hi!