Rust on Espressif chips - 30-06-2023

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

Rust Compiler

The ESP32-C6 & ESP32-H2 use the riscv32imac compilation target, however, for our standard library port based on esp-idf, only the riscv32imc existed. We now have support for the riscv32imac target #111369 meaning you can use the standard library port on the ESP32-C6 & ESP32-H2. For those using the Xtensa enable compiler, the next release of the Rust compiler will also build and ship the rust-analyzer-proc-macro-srv component, which should fix many issues reported with rust analyzer #215.

esp-hal - no_std

Most of the time spent this quarter has been on ESP32-H2 support. At the end of last quarter, we had some initial support but now we have managed to bring the ESP32-H2s level of support up to the level of our other chips in just a few months which is incredible. You can view the PRs for each driver here.

We've been working hard on adding support for async in esp-hal, this includes enabling async serial read #620 and async serial write operations #510. Additionally, we added async support to the I2C driver #519. We also implemented support for multicore async GPIO #542. Moreover, we made the embassy time driver more flexible by allowing the choice of either timer on chips that support it #609.

We simplified the user-facing GPIO types, hiding the implementation details and only exposing the relevant information #553, which then inspired a similar change in the DMA channel types, making them more user-friendly and intuitive to use #626. Additionally, we enabled SPI3 for DMA on ESP32-S3 #507. In order to provide support for specific boards with PSRAM built-in, we introduced initial PSRAM support for ESP32 #506 and octal PSRAM support for ESP32-S3 #610.

Other noteworthy improvements include the integration of esp-riscv-rt into esp-hal #578. We also simplified the Delay driver and now derive Clone and Copy traits. We also move interrupt handling code to RAM for improved interrupt performance #568 #541. Additionally, we addressed a bug related to setting the vector base for the second core on Xtensa-based CPUs #536.

esp-wifi - no_std

We have removed the hard requirement for timg0 as the main timer, offering more configuration flexibility #199. Additionally, we reworked the initialization process to ensure proper initialization of both the hardware and scheduler #194. To enhance WiFi performance, we made preempt improvements, resulting in better overall performance and responsiveness #185. We also expanded the capabilities of the built-in stack by adding basic IPv6 support #181.

esp-ieee802154 - no_std

The newly introduced ESP32-C6 & ESP32-H2 include an 802.15.4 radio, which is a low-power, low-rate standard intended for embedded devices. The esp-ieee802154 crate implements the low-level driver for the radio in both chips, entirely in Rust and completely open source1! This is a big leap from our WiFi drivers, where we interface with binary blobs over the C FFI. There are some useful examples in the repository, including a sniffer example to receive raw 802.15.4 frames. In the next few months, we will begin working on getting this driver to work with openthread.

esp-idf - std

We added safe abstractions to the CRC functions in ESP ROM in #261. We also introduced support for WakeupReason from Ext0 events, allowing for more fine-grained control over wakeup behavior #259. Additionally, we implemented I2S, enabling communication with I2S peripherals #232. Furthermore, we incorporated changes from the newest embedded-hal release into our drivers, ensuring compatibility and staying up-to-date with the latest improvements in the embedded-hal ecosystem #224.

In esp-idf-svc, we focused on expanding the capabilities of the server examples by adding higher-level server examples, providing more comprehensive and practical usage scenarios #269. We also exposed a simple safe wrapper for querying rssi when using WiFi #245. Additionally, we now support async and blocking adaptors for the WiFi driver #243.



The highlight of this cycle was the release of Version 2.0.0, which marked a major milestone for the project and introduced substantial enhancements #434. Please read the full CHANGELOG before upgrading.

We also invested effort in refining the release and CI workflows, resulting in smoother and more efficient processes #421 #419. We addressed specific issues such as missing imports for linux and musl environments #420 and improved handling of serial ports on BSD systems #415.

In terms of usability and user experience, we eliminated the need for the --partition-table argument when erasing partitions, simplifying the process #413. We also updated to the latest version of addr2line and addressed breaking changes before releasing 2.0.0 #412. Furthermore, we improved error messaging by rewording the "elf too big" error and fixed the Windows installation process for smoother setup #400 #399. Additionally, we introduced a diagnostic feature that informs users about the partition table format, aiding troubleshooting #397. To ensure compatibility and expand our supported targets, we updated the flasher stubs and bootloaders #426 and the supported targets for ESP32-C6/H2 #424.


We've had flashing support in probe-rs for a couple of years now, but it was only possible to flash a direct-boot application, but we now support the esp-idf bootloader format in probe-rs #1629. We also have improved the performance of using the built-in USB-SERIAL-JTAG peripheral available on many Espressif chips, resulting in up to a 10x improvement in flashing times and a better overall debugging experience #1633.


matter is an open-source connectivity standard for smart home and Internet of things devices, that promises to make smart devices work with each other regardless of which company manufactures them. matter-rs is a pure Rust implementation of the matter protocol. @kedars and @ivmarkov have been working hard to bring both no_std support and async support to matter-rs. For more information on the active development branches see this section of the readme.


If you look closer at the individual PRs in this post you will see that many of the contributions are now coming from community members instead of just us at Espressif. This is really exciting and humbling to see, and we can't thank the community enough! If you are interested in getting involved or just want to see what we're up to, come say hi in the esp-rs matrix channel.


phy initialization is still done through binary blobs, but after that, the entire driver is controlled via open-source Rust code.