2023Q4 (#22)

* draft

* draft 1

* fin

content/blog/posts/esp-rust-24-01-2024.md

@@ -0,0 +1,57 @@
++++
+title="Rust on Espressif chips - 24-01-2024"
+date=2024-01-24
+draft=false
+[taxonomies]
+tags=["rust", "espressif", "esp32", "llvm"]
++++
+
+This is the next quarterly update of the esp-rs effort, detailing the progress over Q4 2023.
+
+## Rust Compiler
+
+### Upstream
+
+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](https://github.com/rust-lang/rust/pull/114499) 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](https://www.espressif.com/en/news/ESP32-P4), 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](https://github.com/rust-lang/rust/pull/117874). Finally, we added an `espidf` target for the ESP32P4, [riscv32imafc-esp-espidf](https://github.com/rust-lang/rust/pull/119738).
+
+### Xtensa
+
+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.13`, `v0.14` and `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](https://github.com/esp-rs/esp-hal/blob/main/CHANGELOG.md) 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](https://github.com/esp-rs/esp-hal/blob/main/CHANGELOG.md#breaking-1) to ease upgrading. For CAS-based atomics, you should switch to the [portable-atomic](https://github.com/taiki-e/portable-atomic) crate. A huge thank you to [@taiki-e](https://github.com/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. 
+
+## Tooling
+
+### espflash
+
+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](https://github.com/esp-rs/esp-flasher-stub) by default! Check out the unreleased section of the [changelog](https://github.com/esp-rs/espflash/blob/main/CHANGELOG.md#added) to see what's been added so far.
+
+### probe-rs
+
+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](https://github.com/probe-rs/probe-rs/issues/2001) 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](https://github.com/bugadani) who has been championing this work.
+
+## RFC
+
+### esp-openthread
+
+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](https://github.com/esp-rs/esp-openthread/issues/4).
+
+## Future work
+
+To see what we'll be working on this quarter, check out Jesse Braham's [post](https://beta7.io/posts/esp-rs-quarterly-planning-q1-2024/)!
+
+<br/>
+
+---
+
+<br/>