Scott Mabin

esp-hal 1.0.0 beta - 24-02-2025

Mon, 24 Feb 2025 00:00:00 +0000

This one is a bit different! Instead of writing the post here, I have moved the new esp-rs related content to Espressif's developer portal.</p>

To read the esp-hal 1.0 beta announcement, click here</a>!</p>

Rust on Espressif chips - 21-06-2024

Fri, 21 Jun 2024 00:00:00 +0000

This is the next quarterly update of the esp-rs effort, detailing the progress over Q2 2024.</p>

Xtensa Rust Compiler & LLVM Xtensa</h2>
Quite a few patches have been merged upstream in LLVM regarding Xtensa support (see the tracking issue</a> here), so much so that the latest LLVM main branch can emit Xtensa machine code and assembly! It's not quite enough to build projects with yet, and Rust is still using an older version of LLVM but we're making good progress towards soon being able to use a vanilla toolchain for ESP32, ESP32-S2 and ESP32-S3 projects.</p>

esp-hal</h2>
esp-hal saw two releases, v0.17.0</a> and v0.18.0</a>. The biggest change across the new releases was the switch to run-time interrupt binding, instead of link-time interrupt binding. This means that interrupts are now allocated at runtime, which provides much more flexibility in how they are used. The driving force behind this change was to allow, blocking, interrupt-driven and</em> async drivers to co-exist at the same time. We've spent much of our time since improving our current APIs, removing unnecessary generics, creating consistency between drivers and more. This included a complete overhaul of the GPIO module, to use `struct</code>'s to model pin behavior instead of type states. We took a similar approach for the timers too. We now have one timer driver for a given behavior, PeriodicTimer</code>, OneShotTimer</code> which can take in any kind of timer on each chip.</p>`
Another big change is that we've decided to merge many</em> of the ancillary esp crates, such as esp-wifi</code>, esp-println</code> and esp-backtrace</code> into the esp-hal repository itself. The aim of this is firstly, to simplify the release process, most of the crates and be upgraded in a single PR instead of multiple PRs spanning multiple repositories. Secondly, to allow crates to receive changes at the same time as their dependant crate(s) do, the main example being esp-wifi. There would usually be a gap where the latest esp-hal release wasn't compatible with esp-wifi, which causes all kinds of confusion. Monorepos come with their challenges, but so far we've much preferred this development experience. During this time, we've also extracted the `embassy</a> related code into a new package esp-hal-embassy</a>.</p>`
`For many esp-related crates, having one version of the documentation isn't very useful. Much of the exposed APIs are dependent on the chip you are targeting. We've now started self-hosting some of our docs under docs.esp-rs.org/esp-hal/</a>, namely for esp-hal and esp-wifi, which allows you to view the docs for the specific chip.</p>`

`Tooling</h2> probe-rs</h3> v0.24.0</a> of probe-rs was released during Q2, and apart from a few bug fixes didn't include many Espressif specific changes. One nice fix is that probe-rs erase</code> now works on Espressif chips, see the PR for more details</a>.</p> espflash</h3> espflash saw the v3.1.0</a> release which contained some additional configuration file features and a few bug fixes.</p>`

Rust on Espressif chips - 12-04-2024 Fri, 12 Apr 2024 00:00:00 +0000 This is the next quarterly update of the esp-rs effort, detailing the progress over Q1 2024.</p> Xtensa Rust Compiler & LLVM Xtensa</h2> 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</a> 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.</p> esp-hal</h2> We've put a lot of focus on esp-hal</code> 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</code>. This effort was months in the making, and the original issue</a> 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</code>, which has now been released on crates.io! Migration is quite straightforward, you can check out the release notes</a> for the details.</p> 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</code> 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</code> in the main esp-hal</code> repository to see what's available.</p> Tooling</h2> probe-rs</h3> 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</em> testing. Whilst we can run some</em> 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</a>, 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</a>. We can't thank the author of embedded-test, Timo</a>, and the probe-rs team</a> enough!</p> espflash</h3> 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</a> and leverages esp-hal</code> under the hood to communicate with espflash. There are of course a tonne of bugfixes, enhancements and changes, so please check out the changelog</a> for all the details. In the spirit of testing, we've also added HIL testing to espflash, to ensure we minimize regressions between releases.</p> Events</h2> I wanted to post this before Embedded World</a>, 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</a> next month, so if you are attending and you see us, come say hi!</p> Rust on Espressif chips - 24-01-2024 Wed, 24 Jan 2024 00:00:00 +0000 This is the next quarterly update of the esp-rs effort, detailing the progress over Q4 2023.</p> Rust Compiler</h2> Upstream</h3> Over Q4 we saw many improvements to the upstream RISC-V targets. Firstly, all bare metal non-atomic (not a</code>) targets now have atomic load/store code generation</a> 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</code> target, ready for the ESP32P4</a>, 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</a>. Finally, we added an espidf</code> target for the ESP32P4, riscv32imafc-esp-espidf</a>.</p> Xtensa</h3> 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.</p> esp-hal - no_std</h2> Q4 saw the v0.13</code>, v0.14</code> and v0.15</code> release of esp-hal. Highlights include new async drivers for PARL_IO, I2S and RMT; along with updating to the long-awaited v1.0</code> 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</code> for the ESP32C6 and ESP32H2, flip-link</code> 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</a> for all the details and changes.</p> 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</a> to ease upgrading. For CAS-based atomics, you should switch to the portable-atomic</a> crate. A huge thank you to @taiki-e</a> for adding support for our targets in portable-atomic, and supporting crates, as well as pushing the atomic load/store compiler changes through!</p> esp-wifi - no_std</h2> 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</code> on crates.io! We spent a long time refining and documenting to get to this point and we're pleased to have it published. </p> Tooling</h2> espflash</h3> Q4 saw the release of v2.1.0</code> of espflash, a small release with some new functionality for erasing sectors, regions and partitions. We then began the v3.0</code> development cycle, which will include the Rust-based flashing stubs</a> by default! Check out the unreleased section of the changelog</a> to see what's been added so far.</p> probe-rs</h3> 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.</p> 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</a> 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</em> 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</a> who has been championing this work.</p> RFC</h2> esp-openthread</h3> 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</a>.</p> Future work</h2> To see what we'll be working on this quarter, check out Jesse Braham's post</a>!</p> Rust on Espressif chips - 29-09-2023 Fri, 29 Sep 2023 00:00:00 +0000 This is the next quarterly update of the esp-rs effort, detailing the progress over Q3 2023.</p> Rust Xtensa Compiler</h2> We had one big bugfix around hardware floating point unit for ESP32 & ESP32-S3</a>, shout out to @zRedShift</a> for finding the bug and providing the fix in llvm-project#76</a>. Along with the bugfix, @zRedShift</a> also contributed two code generation improvement patches, one to improve the performance of cttz</code></a> and another to improve the performance of abs</code>, min</code> and max</code></a>. The Xtensa-related LLVM patches upstream are still in review but are slowly making progress.</p> esp-hal - no_std</h2> Q3 saw the v0.11</code> and v0.12</code> release of esp-hal. Highlights include updating the embedded-hal-*</code> packages to 1.0.0-rc.1</code>, ready for the long awaited 1.0</code> release of embedded-hal</code>; The addition of deep-sleep support for the ESP32-S3</code>, and new cryptographic accelerator support for ECC, HMAC and RSA. We've made a start on adding support for the low-power core of the ESP32-C6, with some basic GPIO drivers and support for loading the LP code from the main core. Check out the full changelog</a> for all the details.</p> esp-wifi - no_std</h2> We added BLE support for the ESP32-C6 in esp-wifi#262</a>, improved the esp-now async API in #232</a> along with a bunch of other smaller fixes and improvements! We're gearing up for our first crates.io release, which is long overdue. We've had all the pieces in place for a release, we just didn't get around to doing it! We're currently in the process of improving the docs, and doing some final testing before the release.</p> esp-idf-hal - std</h2> Async I2S, SPI, ADC and GPIO were added in esp-idf-hal#279</a>, with a follow up PR for UART in esp-idf-hal#306</a>. Huge props to @ivmarkov</a> for the tremendous effort here. From the latest v0.42.0</code> release, ESP-IDF version 4.3 is now deprecated for use with Rust. Please see ESP-IDFs support schedule</a> for upgrade paths. See the full changelog for esp-idf-hal here</a>.</p> esp-idf-svc - std</h2> Bluetooth classic support (for the esp32 only at the moment) has been added, behind the experimental</code> feature flag; BLE is also planned. We are also discussing how to go about adding generic Bluetooth traits in embedded-svc, here</a>. From the latest release, it will no longer be required to depend on the esp-idf-sys crate or the esp-idf-hal crate directly in your project, instead, this crate will be re-exported by esp-idf-svc as esp_idf_svc::sys</code> and esp_idf_svc::hal</code> respectively.</p> matter-rs / rs-matter</h2> rs-matter (previously, matter-rs, but has been renamed due to an existing crate registered on crates.io) has had its first crates.io release! It is now async first (executor agnostic), with support for no_std out of the box, even including QR generation. The rs-matter repo now has some examples</a> which can be run on std platforms, including the espidf std port! For no_std</code> there are two examples of matter usage, one using an esp32c3 (blocking)</a> and another using a rp-2040 (async)</a>.</p> Tooling</h2> espflash</h3> Just a small patch release to report, v2.0.1</code> which added more help text on the CLI commands, and fixed a compilation issue in the cargo</code> dependency.</p> espsegs</h3> espsegs</a> is a tool to see what memory is being used by which sections and where on an esp. Once installed, you can simply point the tool to an elf file, and you'll get an output like below:</p> ❯ espsegs target\riscv32imc-unknown-none-elf\release\examples\embassy_dhcp --chip esp32c3 </span> </span>.text_dummy 3c000000 458784 DROM [█████████████ ] </span>.rodata 3c070020 53060 DROM [ █ ] </span>.rodata.wifi 3c07cf64 21756 DROM [ ▏ ] </span> </span>.rwdata_dumm 3fc80000 16948 DRAM [██████ ] </span>.data 3fc84238 4652 DRAM [ █ ] </span>.bss 3fc85468 121544 DRAM [ ████████████████████████████████████████████ ] </span>.data.wifi 3fca2f30 360 DRAM [ ▏ ] </span> </span>.trap 40380000 3188 IRAM [ ▏ ] </span>.rwtext 40380c74 2080 IRAM [ ▏ ] </span>.rwtext.wifi 40381494 11680 IRAM [ ███ ] </span> </span>.text_init 42000020 244 IROM [▏ ] </span>.text 42000114 402684 IROM [███████████ ] </span></code></pre> RFCs</h2> This section is mainly for users of esp-rs; we have various issues open in which we would like user feedback.</p> esp-hal</h3> We are considering removing direct-boot support: esp-hal#803</a>, if you think this might affect you, please state your case in that issue.</p> Talks</h2> Espressif recently hosted their annual developer conference, Espressif DevCon. Myself and my colleague Juraj Sadel</a> did a short talk on using async in Rust, which you can check out below.</p> </iframe> I also did a talk at the Rust Copenhagen monthly meet up</a> in August. This talk is more focused on introducing embedded programming to those who already know Rust. Check it out below if you are interested.</p> </iframe> Rust on Espressif chips - 30-06-2023 Fri, 30 Jun 2023 00:00:00 +0000 This is the next quarterly update of esp-rs effort, detailing the progress over Q2 2023.</p> Rust Compiler</h2> The ESP32-C6</a> & ESP32-H2</a> use the riscv32imac</code> compilation target, however, for our standard library port based on esp-idf, only the riscv32imc</code> existed. We now have support for the riscv32imac</code> target #111369</a> meaning you can use the standard library port on the ESP32-C6</a> & ESP32-H2</a>. 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</code> component, which should fix many issues reported with rust analyzer #215</a>.</p> esp-hal - no_std</h2> Most of the time spent this quarter has been on ESP32-H2</a> 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</a>.</p> We've been working hard on adding support for async in esp-hal, this includes enabling async serial read #620</a> and async serial write operations #510</a>. Additionally, we added async support to the I2C driver #519</a>. We also implemented support for multicore async GPIO #542</a>. Moreover, we made the embassy time driver more flexible by allowing the choice of either timer on chips that support it #609</a>.</p> We simplified the user-facing GPIO types, hiding the implementation details and only exposing the relevant information #553</a>, which then inspired a similar change in the DMA channel types, making them more user-friendly and intuitive to use #626</a>. Additionally, we enabled SPI3 for DMA on ESP32-S3 #507</a>. In order to provide support for specific boards with PSRAM built-in, we introduced initial PSRAM support for ESP32 #506</a> and octal PSRAM support for ESP32-S3 #610</a>.</p> Other noteworthy improvements include the integration of esp-riscv-rt</code> into esp-hal #578</a>. We also simplified the Delay</code> driver and now derive Clone</code> and Copy</code> traits. We also move interrupt handling code to RAM for improved interrupt performance #568</a> #541</a>. Additionally, we addressed a bug related to setting the vector base for the second core on Xtensa-based CPUs #536</a>.</p> esp-wifi - no_std</h2> We have removed the hard requirement for timg0 as the main timer, offering more configuration flexibility #199</a>. Additionally, we reworked the initialization process to ensure proper initialization of both the hardware and scheduler #194</a>. To enhance WiFi performance, we made preempt</code> improvements, resulting in better overall performance and responsiveness #185</a>. We also expanded the capabilities of the built-in stack by adding basic IPv6 support #181</a>.</p> esp-ieee802154 - no_std</h2> 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</code> crate implements the low-level driver for the radio in both chips, entirely in Rust and completely open source1</a></sup>! 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</code> 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</code></a>.</p> esp-idf - std</h2> We added safe abstractions to the CRC functions in ESP ROM in #261</a>. We also introduced support for WakeupReason</code> from Ext0</code> events, allowing for more fine-grained control over wakeup behavior #259</a>. Additionally, we implemented I2S, enabling communication with I2S peripherals #232</a>. 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</a>.</p> 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</a>. We also exposed a simple safe wrapper for querying rssi when using WiFi #245</a>. Additionally, we now support async and blocking adaptors for the WiFi driver #243</a>. </p> Tooling</h2> espflash</h3> 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</a>. Please read the full CHANGELOG</a> before upgrading. </p> We also invested effort in refining the release and CI workflows, resulting in smoother and more efficient processes #421</a> #419</a>. We addressed specific issues such as missing imports for linux</code> and musl</code> environments #420</a> and improved handling of serial ports on BSD systems #415</a>.</p> In terms of usability and user experience, we eliminated the need for the --partition-table</code> argument when erasing partitions, simplifying the process #413</a>. We also updated to the latest version of addr2line</code> and addressed breaking changes before releasing 2.0.0 #412</a>. Furthermore, we improved error messaging by rewording the "elf too big" error and fixed the Windows installation process for smoother setup #400</a> #399</a>. Additionally, we introduced a diagnostic feature that informs users about the partition table format, aiding troubleshooting #397</a>. To ensure compatibility and expand our supported targets, we updated the flasher stubs and bootloaders #426</a> and the supported targets for ESP32-C6/H2 #424</a>.</p> probe-rs</h3> 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</a>, but we now support the esp-idf bootloader format in probe-rs #1629</a>. 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</a>.</p> matter-rs</h2> matter</a> 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</a> is a pure Rust implementation of the matter protocol. @kedars</a> and @ivmarkov</a> have been working hard to bring both no_std</code> support and async</code> support to matter-rs</a>. For more information on the active development branches see this section of the readme</a>.</p> Community</h2> 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</em> 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</a> channel.</p> ^{1</sup> phy initialization is still done through binary blobs, but after that, the entire driver is controlled via open-source Rust code.</p> </div>} Rust on Espressif chips - 28-04-2023 Fri, 28 Apr 2023 00:00:00 +0000 This is the next quarterly update of esp-rs effort, detailing the progress over Q1 2023.</p> Rust Compiler & LLVM</h2> We have fixed several issues in the LLVM Xtensa backend, mainly relating to the hardware loop optimization feature used on the ESP32 and ESP32-S3 chips #161</a> #164</a>. We spotted an issue with the 1.67 release where debug builds no longer worked on the ESP32, however, this turned out to be a linker script issue in esp-hal #158</a>.</p> In the last post, we mentioned that the first 10 LLVM Xtensa patches had been committed upstream, since then we have been preparing the next set and now have 20 patches in review upstream. You can track the progress, as well as review the patches here</a>.</p> esp-hal - no_std</h2> First, there were updates to the embedded-hal-async</code> and embassy-*</code> dependencies, as well as an update to embedded-hal@1.0.0-alpha.10</code> and embedded-hal-nb@1.0.0-alpha.2</code>, bringing in the latest changes and improvements from the embedded-hal ecosystem #488</a> #487</a>.</p> Initial ESP32-H2 support was added with #482</a> with the addition of soc/efuse methods in #486</a>. Debug assist support was added to aid in debugging stack overflow issues #484</a>. Additional updates were made to fix comparison errors, decoding of wakeup cause using bitflags, as well as adding support for the RSA peripheral #473</a> #472</a> #467</a>.</p> Improvements were made to the linker scripts, documentation, and clock control for peripherals such as timg</code>, wdt</code>, sha</code>, usb-serial-jtag</code>, and uart</code> #470</a> #463</a> #461</a>. Fixes were made to clock enabling for ESP32-C6 and 802.15.4 clock enabling for ESP32-C6 #458</a>.</p> Updates were made to the PACs (Peripheral Access Crates) to the latest versions, and the esp-hal-smartled</code> package was extracted and CI checks were added for it #447</a> #436</a> #429</a>. Other changes included fixing warnings, cleaning up the RTC driver, removing r0 dependency, and unifying linker scripts for better organization and maintenance #440</a> #439</a> #443</a>.</p> esp-wifi - no_std</h2> We have made significant progress in enhancing packet dumps #165</a> and using a more reasonable default MTU, as well as incorporating features to change MTU #164</a>. Additionally, we have implemented async BLE functionality #161</a> and added missing ROM functions for ESP32-S3/ESP32-S2 support #160</a>.</p> We now utilize types from core::ffi::</code> since they have been stabilized #159</a> and incorporated the use of HAL's radio clock control #153</a>. We have also refactored Socket::write</code> to prevent infinite loops during long writes #151</a> and updated examples for better organization and clarity #146</a>.</p> In terms of new features, we have added support for ESP32-C6 WiFi #142</a>, implemented basic AP functionality #134</a>, and incorporated ESP-NOW support #121</a>. We have also made improvements to asynchronous WiFi functionality, including connect/disconnect/scan/wait_for_event</code> capabilities #129</a> and fixed a bug ensuring that internal WiFi buffers are properly freed #128</a>.</p> Furthermore, we have made updates to dependencies, such as upgrading to Smoltcp 0.9 #124</a>, and reorganizing low-level bindings into a separate package for better modularity #117</a>. We have also addressed various bug fixes and optimizations, including disabling LTO for improved performance #116</a> and refactoring the WiFi device for better code structure #115</a>.</p> TLS - no_std</h2> The standard library has had TLS support for a while, but it's not flawless. However, we lacked TLS support for no_std applications. While we're enthusiastic about the potential of the embedded-tls</a> crate, it's not yet suitable for widespread use. As a substitute, we created esp-mbedtls</a>, a crate for using MbedTLS on ESP32s in no_std applications.</p> esp-idf - std</h2> Over the past quarter, we have been busy improving the functionality and usability of the esp-idf-hal library. We fixed thread priority with pull request #235</a>, and improved our CI with pull request #226</a>. Additionally, we added an spi::config::BitOrder</code> enum to make SPI configuration more flexible with pull request #222</a>.</p> We also implemented several new features, such as setting the LedcTimerDriver</code> frequency with pull request #219</a>, and implementing async Wait traits from embedded-hal-async with pull request #218</a>. We also added alerts and modes support for TWAI with pull request #216</a>, and implemented a general purpose delay provider with pull request #210</a>.</p> Finally, we made several improvements to existing functionality, including allowing setting a timeout for i2c to accommodate devices with longer clock stretching with pull request #211</a>, and changing the LEDC Clock enum name/typedef in esp-idf master with pull request #208</a>. We also implemented PCNT for the v4 esp-idf api (which will work for v5 with v4 api) with pull request #157</a>.</p> Tooling</h2> espflash</h3> Over the past quarter, we and the community have been busy making several improvements and fixes to espflash</code>. We started by adding a note about permissions on Linux in pull request #391</a> to ensure that users are aware of the necessary permissions when flashing ESP devices on Linux systems. In pull request #389</a>, we made the default flashing frequency target specific to improve the flashing process. We also generated shell completions in pull request #388</a> to enhance the usability of the espflash</code> tool.</p> In addition to these improvements, we also focused on fixing issues and bugs. We fixed the config file parsing in pull request #382</a> and updated the toml</code> dependency while fixing errors and feature gating ctrlc</code> dependency in pull request #378</a>. We also resolved issues with Raspberry CI in pull request #377</a> to ensure smooth integration and testing. Furthermore, we made image header improvements and bugfixes in pull request #375</a>, fixed chip revision check during flashing for the ESP8266 in pull request #373</a>, and restored the cursor when exiting from serial port selection via Ctrl-C in pull request #372</a>.</p> In terms of new features, we added support for ESP32-H2 in pull request #371</a> and introduced an ESPFLASH_PORT</code> environment variable in pull request #366</a> for added flexibility. We also updated the documentation in pull request #368</a> to provide up-to-date and accurate information to users. Additionally, we made several fixes and improvements in pull requests such as #363</a>, #359</a>, #358</a>, #354</a>, and #353</a> to ensure the stability and reliability of the espflash</code> tool. Overall, our team has been actively working on addressing issues, adding new features, and improving the espflash</code> repository to provide a better experience for our users.</p> matter</h2> matter</a> 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. We at Espressif are very interested in supporting this. ESP-IDF has support for it with the esp-matter</a> repository, which uses the C++ matter SDK, which we could of course write bindings to (we've already played around with this!) but ideally we'd love a pure Rust implementation.</p> Introducing matter-rs</a> a pure Rust implementation of the matter protocol. Espressif's very own @kedars</a> lead the development of this library, and it is now the official implementation adopted by the matter organization. There are many improvements and features to be added such as async</code> and no_std</code> support but it's a great start.</p> Rust on Espressif chips - 2023 Roadmap Fri, 24 Feb 2023 00:00:00 +0000 This is the next quarterly update of esp-rs effort, detailing the progress over Q4 2022 as well as a roadmap for 2023.</p> Rust Compiler & LLVM</h2> Other than the occasional rebase for every Rust release, there is not too much to report on the rust compiler fork. However, we have really exciting news about LLVM. The first 10 Xtensa patches have been approved and committed</em> upstream 🎉, you can view them here</a>. This is exciting for us, Espressif has been pushing this upstreaming effort since 2019! So it's very nice to have something upstream, with plenty more patches to follow. At this point, I'd also like to make it clear that you do not</strong> need the forked compiler for our RISC-V-based chips, esp32c2, esp32c3, esp32c6 etc. You only need the forked compiler for our Xtensa-based chips, esp32, esp32s2 & esp32s3.</p> espup</a>, our custom toolchain manager has seen some nice improvements over the quarter. It now leverages async</code> to improve installation times, by downloading multiple things concurrently. We switched to espup in our CI pipelines and saw a significant improvement in setup time.</p> esp-hal - no_std</h2> esp-hal</a> has seen two releases in the last quarter, adding many features including our first async driver, async GPIO.</p> Async: GPIO - #333</a></li> Rework the CI workflow - #343</a></li> Remove the signals from the GPIO structs - #337</a></li> Fix GPIO interrupts for pins > 31 - #335</a></li> Finish PeripheralRef - #334</a></li> Use the latest PACs - #331</a></li> Fix the CI badge - #330</a></li> pulse counter implementation - #328</a></li> enable TWAI on ESP32-S3 - #325</a></li> Completely remove pac references in hal drivers - #309</a></li> Support ESP32-C2 with 26MHz Xtal - #301</a></li> Add a CI job to verify formatting - #297</a></li> New releases for all HALs - #296</a></li> Fix LEDC duty-cycle updates - #294</a></li> Correct Systimer delay implementation - #293</a></li> Fix ESP32-C2 trap handler - #292</a></li> Embassy init updates - #290</a></li> Add cfg symbols for i2s</code> and mcpwm</code> - #289</a></li> Pass trap frame to CPU interrupt handlers (Xtensa) - #286</a></li> Fix clippy warnings, update READMEs - #284</a></li> remove i2c::SetupError</code> and make i2c::I2C::new</code> infallible - #281</a></li> GPIO module refactoring - #280</a></li> Export InputSignal and OutputSignal - #276</a></li> Finalize I2S RX Implementation - #274</a></li> Update install sections - #273</a></li> PeripheralRef init: uart - #272</a></li> Implemented ability to write bytes in UsbSerialJtag</code> - #271</a></li> Fix example in esp-hal-procmacros::interrupt doc - #270</a></li> Add Rx and interrupts to UsbSerialJtag - #267</a></li> Avoid potential linker error for ESP32-C2 and ESP32-C3 - #266</a></li> New releases for all HALs - #265</a></li> Add more configuration symbols and simplify the build script - #264</a></li> Detangle I2C clock calculation - #263</a></li> Preliminary I2S Implementation - #262</a></li> Fix UART unlisten calls so they clear the interrupt enable - #261</a></li> Add more trait re-exports to prelude module - #260</a></li> Update all PACs to their latest versions - #259</a></li> Add SHA accelerator implementation - #257</a></li> doc: add #[doc(inline)]</code> to esp-hal-common re-exports - #256</a></li> MCPWM MVP implementation - #255</a></li> Add Mcpwm0 and Mcpwm1 to system::Peripheral</code> - #254</a></li> add/correct docs for gpio::OutputSignal and add PWM output signal to ESP32-S3 - #251</a></li> Add LEDC support for ESP32-C2 - #250</a></li> Update to newest PACs for C2/C3/S3 and clean up GDMA implementation - #248</a></li> Add uninit section to bl and mv linker scripts to match db - #246</a></li> ADC: Refactor, join S2 and S3 together and C2 and C3 as well - #245</a></li> ESP32-C2 APB clock is 40MHz, not 80MHz - #244</a></li> </ul> esp-wifi - no_std</h2> esp-wifi</a> saw some nice features over the last quarter, along with some bug fixes, performance improvements and refactors.</p> ESP32-C2 BLE - #110</a></li> WiFi for ESP32-C2 - #107</a></li> Update Drivers - #106</a></li> BTLE for ESP32-S3 - #105</a></li> Add ps_min_modem</code> feature - #103</a></li> Misc improvements - #102</a></li> Update dependencies - #100</a></li> Have a way to yield from a task - #98</a></li> Re-introduce a Queue for TX - #96</a></li> Add static IP and socket listening example - #95</a></li> Fix ESP32-C3 development mode - #90</a></li> Works on ESP32-C3-DevKit-RUST-1 again - #86</a></li> Update embedded svc - #84</a></li> Support multiple sockets, UDP and multicast - #82</a></li> Fix the newest ESP-HALs Alarm's method - #81</a></li> Update README.md wording - #75</a></li> </ul> esp-idf - std</h2> General purpose delay provider - #210</a></li> LEDC Clock enum name/typedef change in esp-idf master - #208</a></li> Update xtensa-toolchain</code> action - #206</a></li> Fix issue #201: Use NonZeroUsize</code> to specify DMA transfer size - #203</a></li> Add queue length to CAN config - #202</a></li> Fix a typo - #196</a></li> Correct endianness of RMT signal in neopixel example - #195</a></li> Add input_delay_ns to config struct - #192</a></li> Add auto_reload functionality to timers - #190</a></li> Use EspError::from_infallible</code> - #189</a></li> #180 ledcdriver redundand timer config - #188</a></li> Adjust for esp-idf-sys</code> size_t -> usize - #185</a></li> Ci for idf 5.0 - #183</a></li> Implement watchdog interface - #182</a></li> Fix typo in doc copy - #181</a></li> Implement exclusive SPI Bus - #174</a></li> Use Cell<Option<NonNull<QueueDefinition>>></code> instead of UnsafeCell<*mut QueueDefinition></code> - #170</a></li> do some clippy/Cargo.toml housekeeping, update st7789</code> example to use a non-deprecated driver - #169</a></li> Add can custom timing - #166</a></li> Overhaul UART to support single wire transmitters/receivers - #164</a></li> PCNT implementation for v4 esp-idf api (will work for on v5 with v4 api) - #157</a></li> Ledc: Add SpeedMode</code> enum, allow lpoint</code> < hpoint</code> < max_duty</code> - #155</a></li> Fix GPIO docstrings - #151</a></li> RFC: Multi CS Spi Implementation - #150</a></li> Add half duplex and 3wire mode support to SPI - #143</a></li> spi/adc_st7789_example - #125</a></li> Add RMT receiver - #104</a></li> </ul> Tooling</h2> espflash</h3> Make Interface</code> constructor public - #354</a></li> Fix CI warnings - #350</a></li> Remove the USB Serial JTAG watchdog workaround now that we use the stub - #345</a></li> No longer build releases for the Windows GNU target - #343</a></li> Organize, simplify, and generally improve the errors - #342</a></li> If a bootloader and/or partition table other than the defaults have been provided, indicate such - #339</a></li> Mark public enums as #[non_exhaustive]</code> for semver compatibility - #338</a></li> Use the flasher stub by default - #337</a></li> CLI improvements and dependency updates - #334</a></li> Add an optional callback trait which can be implemented and provided to most flashing functions - #333</a></li> Fix monitor after flash for ESP32-C2 - #330</a></li> Make the flasher return a struct of device information instead of printing directly - #328</a></li> Mention the bootloader/partition table auto-detection feature of cargo-espflash</code> - #327</a></li> Fix the CI badge in the README - #325</a></li> Reorder ports so that known ports appear first in CLI - #324</a></li> Support ESPFLASH_BAUD env var - #322</a></li> Add support for flashing the ESP32-C6 - #317</a></li> Fix the serial monitor when using 26MHz ESP32-C2 - #315</a></li> Fix crystal frequency detection for ESP32-C2 and ESP8266 - #314</a></li> Version 2.0.0-rc.2 - #309</a></li> Fix typo in ImageFormatKind</code>'s FromStr</code> implementation - #308</a></li> Display the newer 'v{major}.{minor}' chip revision format - #307</a></li> Make command module public - #303</a></li> Clean up unused code, optimize comparison in find_serial_port</code> - #302</a></li> Add support for using custom cargo metadata when in a workspace - #300</a></li> Update dependencies to their latest versions - #299</a></li> Add shortopt -M for --monitor - #296</a></li> Allow SerialPortType::PciPort during port detection - #295</a></li> Report the image and partition size in the error - #293</a></li> Add option to supply the ELF</code> image path in the monitor subcommand - #292</a></li> Version 2.0.0-rc.1 - #288</a></li> Make the interface</code> module public - #287</a></li> Fix FlashSize</code> discrepancy between clap</code>, strum</code> and FromStr</code> - #286</a></li> Only display progress bars when cli</code> feature is enabled, allow passing progress callback - #283</a></li> Print app size when using any image format, cleanup/use new features - #281</a></li> Add updated bootloaders for all chips - #278</a></li> Load stubs from TOML instead of JSON files - #277</a></li> Add a test for the Direct Boot image format - #276</a></li> Extract common functionality for erasing partition tables into a function - #275</a></li> Replace --erase-otadata with --erase-parts and --erase-data-parts - #273</a></li> Print additional information when invoking the save-image</code> subcommand - #272</a></li> Additional docstrings for enums</code>, structs</code>, and traits</code> - #271</a></li> connection: error handling - #270</a></li> connection: Swap error and status in CommandResponse - #269</a></li> Add back the image format tests which had been previously removed - #266</a></li> Remove unneeded attributes and pub(crate)</code>s, old test data - #263</a></li> </ul> The 2023 roadmap</h2> We've been thinking about what we'd like to achieve in the next year, and have put together a roadmap for 2023.</p> Async</h3> Over the last year, we've made a real effort to get blocking implementations available for most peripherals both in our Standard library effort, and no_std efforts. Blocking is generally simpler to implement, as async relies on a good story for interrupts & DMA (direct memory access). This year we'd like to push for more async across both approaches; this includes async peripheral drivers (SPI, UART, I2C etc), including but not limited to the embedded-hal-async</code> traits, as well as async networking solutions. Those of you familiar with the Standard library approach may have noticed there is actually quite a good async networking solution already available using smol-rs</code> but we need to upstream many of our changes. Our main focus for no_std async networking will be on the esp-wifi</code> crate.</p> Chip support</h3> For both approaches, we will be adding support for the newly released ESP32-C6, as well as preparing support for the ESP32-H2 and ESP32-P4 once they are officially released. Support for the ESP32-C6 is in progress for no_std, and for STD, ESP32C6 support will be added with the release of esp-idf v5.1 (expected in May).</p> Low Power modes and co-processor support</h3> Starting from the ESP32-S2, our chips have included a low-power RISC-V coprocessor for handling low-power operations when the main CPU is not needed. We'd like to leverage esp-hal</code> for creating applications that can run on the constrained low-power core, for both no_std and</em> std applications. The low-power core is too resource-constrained to run the full standard library, so using esp-hal</code> makes perfect sense here.</p> STD build times</h3> One of the barriers when developing for the STD platform is build times. We know of several improvements we can make to reduce the build time. One thing we'd like to take a look at this year is slimming down the esp-idf build, currently, we build everything, but esp-idf is made of components, which can be disabled if they're not needed. We're also aware that a lot of the 'build' time is spent downloading esp-idf sources via git, so we'd like to investigate how to reduce this time.</p> Documentation</h3> We've made a lot of progress over the last year, but moving so fast has left the documentation situation in a not-so-great state. We're rewriting the book</a> this year to cut out irrelevant, outdated information as well as fill the gaps created in the last year. We're currently self-hosting our standard library documentation because we need an internet connection to download toolchains/sources not present on the docs.rs runners, if possible we'd like to find a way to host our docs on docs.rs.</p> Rust on Espressif chips - 17-10-2022 Mon, 17 Oct 2022 00:00:00 +0000 This is the next quarterly update of esp-rs effort, detailing the progress over Q3 2022.</p> Rust Compiler & LLVM</h2> The Rust compiler fork and LLVM have seen a few changes and fixes over the last quarter. Firstly, we have a new way to install the Xtensa-enabled toolchain, introducing espup</a>. espup is a new Rust-based installer that replaces the unwieldy bash scripts we were previously using; we're still maintaining those for the time being but the future will be espup.</p> A few issues have been spotted in the last quarter, the first related to the alignment of 128bit arguments on the Xtensa arch which caused #137</a> & #135</a>. The second was a loop miscompilation issue in the code generated by the LLVM backend which caused #134</a> & #127</a>. This has now been fixed in LLVM and will be released with Rust 1.65.0. Finally, there are some code generation issues around printing floats which can be seen in #136</a>, this is an ongoing issue that I haven't gotten to the bottom of.</p> Lastly, we have some progress to report on the LLVM Xtensa upstreaming - it's moving! Eight of the ten initial patches have been approved thanks to some new reviewing effort upstream. Since then Cadence (the IP holder for Xtensa) has publically released an ISA summary</a> which is fantastic news for the open source community in general but especially us as there is now an official document that reviewers can use to review our backend. We started a new RFC</a> to finally get the initial patches merged upstream.</p> esp-hal & bare metal</h2> esp-hal development has been coming along nicely! We even released our first and second releases during this quarter, which is quite the milestone as we now believe that the HAL is in a good enough spot for it to be experimented with.</p> Very basic support for running applications on the other core #96</a></li> ADC support #97</a> #98</a></li> Allow for configuring the UART #99</a> #102</a></li> Vectored interrupts #103</a> #118</a></li> Direct-boot support for the ESP32-S3 #107</a></li> CPU clock settings #110</a> #111</a></li> LEDC support #114</a></li> Critical section implementations #151</a></li> embedded_hal@1.0.0-alpha.x</code> traits implemented for most peripherals (multiple PRs)</li> A large number of bug fixes, smaller features, refactoring, etc. (multiple PRs)</li> </ul> esp-wifi</h2> esp-wifi has had a lot of attention in the last quarter, plenty of fixes and improvements to make it more reliable, as well as adding new target support!</p> Remove global allocator #73</a></li> Reduce project size by using size optimized WiFi blobs #66</a></li> Switch the Bluetooth stack to bleps #65</a></li> Add WiFi support for the ESP32-S2 #62</a></li> Add WiFi support for the ESP32-S3 #55</a></li> Remove bespoke code in favour of relying on esp-hal where possible (multiple PRs)</li> Fix order of magnitude timestamp creation error #44</a></li> </ul> esp-storage</h2> esp-storage</a> is a new crate that implements the embedded-storage</a> traits for Espressif chips. This is useful for writing data to internal flash, which could be paired up with flash aware filesystem.</p> Tooling</h2> espflash</h3> Espflash has seen some great improvements over the last quarter. We're building up to a 2.0 release soon which will feature a much improved, and importantly, consistent CLI.</p> Support for ESP32-C2 added #204</a></li> Support for using stub loaders added #216</a></li> Improved support for ESP-IDF partition tables (multiple PRs)</li> Support for flashing the ESP32-S2 via CDC UART #228</a></li> Support for erasing OTA data #229</a></li> Support flashing via the built-in UART peripherals on Raspberry Pi #234</a></li> Relicensed under MIT/Apache-2.0 #235</a></li> CLI interface redesign #239</a></li> A large number of bug fixes, smaller features, refactoring, etc. (multiple PRs)</li> </ul> Rust flasher stub</h3> Flashing stubs are small programs that the flashing tool uploads to the chip to improve the features or speed of flashing. The stubs available for Espressif chips are currently written in C and can be found here</a>. These stubs have grown organically over the years and we've wanted to rewrite them for a while. We took this opportunity to write them in Rust! You can find the project here</a>, which currently only has a stub for the esp32c3, but esp32 support is being worked on. </p> Wokwi</h3> Wokwi now has in-browser support for building Rust applications for Espressif chips. Check out wokwi.com/rust</a> and play around with some examples in the comfort of your browser!</p> wokwi-server</a>, the cargo runner for running applications in Wokwi has been updated to v0.2.0</code>. This includes bumping Tokio to the latest stable and providing prebuilt binaries on the releases page.</p> Espressif DevCon 2022 </h2> Espressif is excited to be hosting our first-ever conference this year! It's a two-day event starting on the 19th of October! I will be talking about Rust at Espressif along with some of my colleagues. Be sure to register here</a> then drop in and say hi!</p> 19th October 13:05 CEST - Rust on Espressif Chips - Scott Mabin</li> 19th October 14:30 CEST - Your browser is ESP32 - Uri Shaked</li> 20th October 16:45 CEST - Paradigm Shift to Cloud-Based Embedded Development - Juraj Michálek, Sergio Gasquez</li> </ul> What's next?</h2> Continue to improve the Rust Xtensa fork, and push for LLVM upstreaming, maybe we'll see Xtensa (as an experimental target) in upstream Rust sooner than we thought! On a side note, we've started an "awesome" list of awesome esp rust things - check it out here</a>.</p> Rust on Espressif chips - 15-07-2022 Fri, 15 Jul 2022 00:00:00 +0000 This is the next quarterly update of esp-rs effort, detailing the progress over Q2 2022.</p> Standard library</h2> esp-rs/rust#117</a>, failure to list file directories, has been fixed. This issue was two in one; the first applied to any filesystem, used through the libc</code> API. The definition of the dirent</code> structure was incorrect in esp-idf</code>, this int</code> definition</a> should have been a ino_t</code> definition. The size difference between the two types meant that the name ended up with a null terminator at the beginning, hence no output would be printed when listing a directory. The second part was specific to SPIFFS (a flash-based filesystem), listing a directory would emit an internal error number, which was interpreted as a real error, but in reality, was just a signal that the end of the listing had been reached. More details here</a>.</p> esp-hal & bare-metal support</h2> esp-hal</a> has seen much development in the last quarter.</p> Add a serial driver for the USB-SERIAL-JTAG peripheral - esp-hal#56</a></li> Add RMT output support, with a implementation for smart-leds-rs</a> - esp-hal#53</a></li> Use fugit</code> time types in the HALs public API - esp-hal#64</a></li> Add support for the SYSTIMER</code> on the esp32c3</code>, esp32s2</code> & esp32s3</code> - esp-hal#76</a> </li> Add ClockConfig</code> to start to support customizing the chip clocks - esp-hal#77</a></li> Add support for most embedded-hal</code> alpha traits - esp-hal#82</a></li> Add basic EFUSE reading support - esp-hal#85</a></li> Add DAC peripheral support - esp-hal#92</a></li> Add ADC peripheral support - esp-hal#97</a>, esp-hal#98</a></li> Add support for using the second core on the esp32</code> & esp32s3</code> - esp-hal#96</a></li> </ul> WiFi & Bluetooth</h3> esp-wifi</a> has been moved to the esp-rs organization. We now also have support for WiFi on the Xtensa based esp32</code> which was implemented in esp-rs/esp-wifi#4</a>. The radios inside the esp32</code> & esp32c3</code> also support Bluetooth Low Energy, which has now been implemented for the esp32c3</code> in esp-rs/esp-wifi#30</a> & the esp32</code> in esp-rs/esp-wifi#34</a>, which is very exciting! esp-wifi is still experimental, so do expect some issues but it's in a good enough state that bjoernQ</a> rewrote his temperature logging project</a> using bare metal Rust!</p> Async support</h3> On top of the PR's listed above, we have begun working on async</code> support too! The go-to embedded executor right now is embassy</a>, which only supported ARM until we recently added support for RISC-V in embassy#804</a> & support for Xtensa in embassy#805</a>. The next step is to add an embassy::time::Driver</code> implementation inside esp-hal after which we could create the most basic embassy demo, running on an esp32c3! What's nice about this is you get power savings for free, as soon as there are no other tasks or interrupts to process the chip goes to sleep until the next wake-up.</p> static </span>EXECUTOR</span>: Forever<Executor> = Forever::new(); </span> </span>#[</span>riscv_rt</span>::</span>entry</span>] </span>fn </span>main</span>() -> ! { </span> </span>let</span> p = esp32c3_hal::embassy::init(); </span> </span> </span>let</span> executor = </span>EXECUTOR</span>.</span>put</span>(Executor::new()); </span> executor.</span>run</span>(|</span>spawner</span>| { </span> spawner.</span>spawn</span>(</span>run1</span>()).</span>ok</span>(); </span> spawner.</span>spawn</span>(</span>run2</span>()).</span>ok</span>(); </span> }); </span> </span> </span>loop </span>{} </span>} </span> </span>#[</span>embassy</span>::</span>task</span>] </span>async </span>fn </span>run1</span>() { </span> </span>loop </span>{ </span> esp_println::println!("</span>Hello world from embassy on an esp32c3!</span>"); </span> Timer::after(Duration::from_millis(</span>1000</span>)).await; </span> } </span>} </span> </span>#[</span>embassy</span>::</span>task</span>] </span>async </span>fn </span>run2</span>() { </span> </span>loop </span>{ </span> esp_println::println!("</span>Bing!</span>"); </span> Timer::after(Duration::from_millis(</span>3000</span>)).await; </span> } </span>} </span></code></pre> Which results in the following output: </p>

probe-rs</h3>
v0.24.0</a> of probe-rs was released during Q2, and apart from a few bug fixes didn't include many Espressif specific changes. One nice fix is that `probe-rs erase</code> now works on Espressif chips, see the` `PR for more details</a>.</p>`

`espflash</h3> espflash saw the v3.1.0</a> release which contained some additional configuration file features and a few bug fixes.</p>`

esp-openthread</h3>
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</a>.</p>

Future work</h2>
To see what we'll be working on this quarter, check out Jesse Braham's post</a>!</p>

espflash</h3>
Just a small patch release to report, `v2.0.1</code> which added more help text on the CLI commands, and fixed a compilation issue in the cargo</code> dependency.</p>`

RFCs</h2>
This section is mainly for users of esp-rs; we have various issues open in which we would like user feedback.</p>

esp-hal</h3>
We are considering removing direct-boot support: esp-hal#803</a>, if you think this might affect you, please state your case in that issue.</p>

Tooling</h2>

The 2023 roadmap</h2>
We've been thinking about what we'd like to achieve in the next year, and have put together a roadmap for 2023.</p>

esp-storage</h2>
esp-storage</a> is a new crate that implements the embedded-storage</a> traits for Espressif chips. This is useful for writing data to internal flash, which could be paired up with flash aware filesystem.</p>

What's next?</h2>
Continue to improve the Rust Xtensa fork, and push for LLVM upstreaming, maybe we'll see Xtensa (as an experimental target) in upstream Rust sooner than we thought! On a side note, we've started an "awesome" list of awesome esp rust things - check it out here</a>.</p>

Scott Mabin

esp-hal 1.0.0 beta - 24-02-2025

Rust on Espressif chips - 21-06-2024

Rust on Espressif chips - 12-04-2024

Rust on Espressif chips - 24-01-2024

Rust Compiler</h2>

Rust on Espressif chips - 29-09-2023

Rust on Espressif chips - 30-06-2023

Rust on Espressif chips - 28-04-2023

Rust on Espressif chips - 2023 Roadmap

Rust on Espressif chips - 17-10-2022

Rust on Espressif chips - 15-07-2022