This is the next quarterly update of esp-rs effort, detailing the progress over Q2 2023.
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
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
esp-idf - std
We added safe abstractions to the CRC functions in ESP ROM in #261. We also introduced support for
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
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.