q2-2024 (#24)

* draft

* draft 1

* fin

content/blog/posts/esp-rust-21-06-2024.md

@@ -0,0 +1,40 @@
++++
+title="Rust on Espressif chips - 21-06-2024"
+date=2024-06-21
+draft=false
+[taxonomies]
+tags=["rust", "espressif", "esp32", "llvm"]
++++
+
+This is the next quarterly update of the esp-rs effort, detailing the progress over Q2 2024.
+
+## Xtensa Rust Compiler & LLVM Xtensa
+
+Quite a few patches have been merged upstream in LLVM regarding Xtensa support (see the [tracking issue](https://github.com/espressif/llvm-project/issues/4) 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.
+
+## esp-hal
+
+esp-hal saw two releases, [v0.17.0] and [v0.18.0]. 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_ 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`'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`, `OneShotTimer` which can take in any kind of timer on each chip.
+
+Another big change is that we've decided to merge _many_ of the ancillary esp crates, such as `esp-wifi`, `esp-println` and `esp-backtrace` 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](https://github.com/embassy-rs/embassy) related code into a new package [esp-hal-embassy](https://github.com/esp-rs/esp-hal/tree/main/esp-hal-embassy).
+
+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/](https://docs.esp-rs.org/esp-hal/), namely for esp-hal and esp-wifi, which allows you to view the docs for the specific chip.
+
+[v0.17.0]: https://github.com/esp-rs/esp-hal/releases/tag/v0.17.0
+[v0.18.0]: https://github.com/esp-rs/esp-hal/releases/tag/v0.18.0
+
+## Tooling
+
+### probe-rs
+
+[v0.24.0](https://github.com/probe-rs/probe-rs/releases/tag/v0.24.0) 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` now works on Espressif chips, see the [PR for more details](https://github.com/probe-rs/probe-rs/pull/2279).
+
+### espflash
+
+espflash saw the [v3.1.0](https://github.com/esp-rs/espflash/releases/tag/v3.1.0) release which contained some additional configuration file features and a few bug fixes.
+
+<br/>
+
+---
+
+<br/>