This is the next quarterly update of the esp-rs effort, detailing the progress over Q4 2023.
Over Q4 we saw many improvements to the upstream RISC-V targets. Firstly, all bare metal non-atomic (not
a) targets now have atomic load/store code generation enabled! This was a massive pain point for users of the ESP32C3 and ESP32C2, along with other RISC-V targets in the wild. It's currently still in nightly, but with the 1.76, release it will be available on stable. Secondly, we added the
riscv32imafc-unknown-none-elf target, ready for the ESP32P4, Espressif's first chip without a radio. We also promoted all the current bare metal RISC-V targets to tier 2, and in doing so, filled out the missing platform support document. Finally, we added an
espidf target for the ESP32P4, riscv32imafc-esp-espidf.
The LLVM team at Espressif has continued to improve and rebase the Xtensa LLVM backend, which has recently been rebased on LLVM 17. Unfortunately, we don't have any upstream progress to report at this time.
esp-hal - no_std
Q4 saw the
v0.15 release of esp-hal. Highlights include new async drivers for PARL_IO, I2S and RMT; along with updating to the long-awaited
v1.0 of embedded-hal! We expanded on our low-power support by unifying the API across all chips, as well as adding ULP (Ultra-Low-Powered) core support for the ESP32S2 & ESP32S3. Lastly, one cool feature we implemented was
flip-link for the ESP32C6 and ESP32H2,
flip-link gives zero-cost stack overflow detection, which is really nice for chips like these that don't have an MMU that can catch this in hardware. Check out the full changelog for all the details and changes.
One important breaking change that should be noted is that we no longer support atomic emulation, as upstream Rust now supports atomic load & stores on non-atomic targets. Users with applications using the ESP32S2, ESP32C3 or ESP32C2, please read this to ease upgrading. For CAS-based atomics, you should switch to the portable-atomic crate. A huge thank you to @taiki-e for adding support for our targets in portable-atomic, and supporting crates, as well as pushing the atomic load/store compiler changes through!
esp-wifi - no_std
In Q4 we added support for BLE with the ESP32H2, fixed coexistence support on the ESP32 and added a benchmark example to test WiFi throughput. On top of that, we finally released
esp-wifi on crates.io! We spent a long time refining and documenting to get to this point and we're pleased to have it published.
Q4 saw the release of
v2.1.0 of espflash, a small release with some new functionality for erasing sectors, regions and partitions. We then began the
v3.0 development cycle, which will include the Rust-based flashing stubs by default! Check out the unreleased section of the changelog to see what's been added so far.
There has been a tonne of progress with probe-rs and Espressif chips over Q4. This is all driven by the fact we want to start testing using real hardware in CI, known as Hardware In Loop (HIL) testing.
Newer Espressif chips are all RISC-V based, which probe-rs already has good support for. The ESP32, ESP32S2 and ESP32S3, however, are Xtensa-based, there for to test these in CI, we need Xtensa architecture support in probe-rs and that's what we set out to do. I am happy to report that we have enough Xtensa support in probe-rs to, connect, inspect and flash the ESP32S2 and ESP32S3! This also comes with some huge speed improvements to all chips thanks to improvements in the USB-SERIAL-JTAG and FTDI drivers in probe-rs. All of this would not be possible without the help of the probe-rs team and of course the hard work of one particular individual, Dániel Buga who has been championing this work.
We're looking for input on what to develop next with esp-openthread, if you are looking to use thread in your project or product, please take a look at this RFC issue.
To see what we'll be working on this quarter, check out Jesse Braham's post!