From d209ac2c1c6afffad6766ce8acb65c43b292f7e1 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Thu, 30 Jan 2025 16:59:49 +0000 Subject: [PATCH 01/15] draft of beta announcement post --- content/blog/rust-esp-hal-beta/index.md | 148 ++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 content/blog/rust-esp-hal-beta/index.md diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md new file mode 100644 index 000000000..b859f28c4 --- /dev/null +++ b/content/blog/rust-esp-hal-beta/index.md @@ -0,0 +1,148 @@ +--- +title: "esp-hal 1.0.0 beta announcement" +date: 2024-02-11 +showAuthor: true +featureAsset: "img/featured/featured-espressif.webp" +authors: + - scott-mabin +tags: + - Esp32 + - Rust + - Xtensa + - RISCV + - Announcement + +--- + +We're extremely excited to announce the `1.0.0-beta.0` release for esp-hal, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the the journey of how we got here. If you're just interested in what we're stabilizing today [click here](#targeting-stability) to jump to it. + +### Where it all started + +In 2019 I created the esp-rs org which laid dormant for some time. At the time, [Espressif] was still using the [Xtensa] architecture for it's chip lineup which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far to cumbersome. Fast-forward to 2020 and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was extremely excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had fortunately been merged just a bit earlier. I had to set this project aside for a while, but I got back to it and managed to write the worlds first Rust blinky on an esp32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post really stood out to me. + +> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. + +I think it's safe to say the ball definitely rolled. + +### Espressif's official support for Rust + +Not long after that initial blog post Espressif started sponsoring my work and allowed me continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Whilst myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things, [@reitermarkus] initially and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF] which was not only an amazing technical feat, but also gave users a big head start because we could use the stable and tested code from esp-idf without having to write all the drivers from scratch for `no_std` immediately. + +Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they we're keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team and I along with [@jessebraham] gladly accepted. + +### Bringing up the ecosystem + +It has been possible to write embedded Rust applications on stable since 2018, but most of the ecosystem revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us given that Espressif has just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are arch independent, the tooling is a different story, and over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. + +Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, they have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we had is that we we're the primary users of the LLVM Xtensa fork, which meant when there was a bug in some code-gen we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it as the backend is in very good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long long time), most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel. + +### Focussing on `no_std` crates + +In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` WiFi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! + +We spent the entirety of 2022 and most of 2023 working exclusively on chip support. Making sure new chips were supported, and trying to support as many peripherals as possible. During this time we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. This seemed like a good idea at the time (and I wouldn't say it was a bad idea), but by the end of 2023 we realized that trying to support everything that the chips can do (and trust me, there is _a lot_ try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time frame with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. + +### Targeting stability + +The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which worked in a very similar way to [defmt-test] but has a couple of advantages: + + * It supports ARM, RISC-V and Xtensa (thanks to some great work by [@bugadani] to add Xtensa support to [probe-rs]) + * It supported `async` tests + +Its been working extremely well for us, and we've been amassing an ever growing list of test cases in the [hil-test](https://github.com/esp-rs/esp-hal/tree/main/hil-test/tests) crate. + +The next step, was figuring out what our APIs should look like after all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which I suppose is why many HALs including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. + +The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead starting self-hosting our docs, with a chip and version selector to combat this. Once again, this was heavily inspired by [embassy]'s prior work in this area. + +### Our stabilization strategy + +Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabilization to: + +- Initializing the hal, `esp_hal::init` and the relevant configuration associated with that. +- Four "core" drivers to start + - GPIO + - UART + - SPI + - I2C +- A couple of miscellaneous system APIs (SoC reset, etc), +- `#[main]` macro +- How esp-hal and friends are configured via [esp-config] + +With the exception of the list above, everything in else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. + +### What about the other no_std esp crates? + +esp-hal is the foundation of many of the esp-rs ecosystem crates, [esp-wifi] is our next stabilization target, and builds directly on top of esp-hal. The end goal is of course to have every `esp-*` crate with a 1.0+ release. + +### Do you plan on releasing esp-hal 2.0.0 at some point? + +As of right now, we don't have plans to ever release a esp-hal 2.0 release. If we do need to, we have done some [semver experiments](https://github.com/MabezDev/semver-playground/tree/master) and we've determined that we can release a 2.0 release without breaking our ecosystem, provided we've got driver construction nailed. We've spent quite a lot of time and resources in this area, and we think we're in a good place. + +### Call for testing + +As this is a beta release, we'd absolutely love to hear your feedback on esp-hal as it currently stands! Whether you've used it before, or you're about to try it out for the first time, any feedback is most welcome! + +* Please open issues for anything that should be working that isn't +* Please open discussions to discuss API decisions that perhaps aren't quite as ergonomic or thought through as we intended + +We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to setup in embedded, please do give it a try by first installing the tool with + +```rust +cargo install esp-generate +``` + +then, to generate a project for the ESP32-C6, run + +```rust +esp-generate --chip esp32c6 NAME_OF_PROJECT +``` + +We're currently rewriting the [book], but in the meantime it can still be helpful to read it to get an overview of the ecosystem. + +### Where does this leave the standard library port? + +At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's silently been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to esp-hal and the other no_std crates. + +### What's next? + +Our focus now is to keep pushing until esp-hal 1.0, at which point we'll split our efforts and try to stabilize more things in esp-hal, as well as push for a stable WiFi/BLE story. Preparing for the full esp-hal 1.0 release requires a overhaul of the [book], along with a bunch of documentation and polish all round. Finally we need to ensure our tooling is in a good place and we plan to make a new [espflash] release to accomplish that. + +This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also cannot thank the Rust team at Espressif, they're awesome to work with a oh so very talented! If you're attending RustNL this year come say hi! + +If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! + +--- + +[^1]: There are some binary blobs to run the WiFi driver which we link to. + + +[mrustc]: https://github.com/thepowersgang/mrustc +[Espressif]: https://www.espressif.com/ +[Xtensa]: https://en.wikipedia.org/wiki/Tensilica +[Xtensa enabled LLVM fork]: https://esp32.com/viewtopic.php?t=9226&p=38466 +[posts on my personal website]: https://mabez.dev/blog/posts/ +[ESP-IDF]: https://github.com/espressif/esp-idf +[probe-rs]: https://probe.rs/ +[embedded-test]: https://github.com/probe-rs/embedded-test +[embassy]: https://github.com/embassy-rs +[defmt-test]: https://github.com/knurling-rs/defmt/tree/main/firmware/defmt-test +[official Rust embedded book]: https://docs.rust-embedded.org/book/static-guarantees/typestate-programming.html +[DEVELOPER-GUIDELINES]: https://github.com/esp-rs/esp-hal/blob/main/documentation/DEVELOPER-GUIDELINES.md + +[espflash]: https://github.com/esp-rs/espflash +[esp-hal]: https://github.com/esp-rs/esp-hal/tree/main/esp-hal +[esp-wifi]: https://github.com/esp-rs/esp-hal/tree/main/esp-wifi +[ESP-NOW]: https://www.espressif.com/en/solutions/low-power-solutions/esp-now +[xtensa-lx and xtensa-lx-rt]: https://github.com/esp-rs/esp-hal/tree/main/xtensa-lx-rt +[esp-generate]: https://github.com/esp-rs/esp-generate +[book]: https://github.com/esp-rs/book +[esp-config]: https://crates.io/crates/esp-config + +[@reitermarkus]: https://github.com/reitermarkus +[@ivmarkov]: https://github.com/ivmarkov +[@jessebraham]: https://github.com/jessebraham +[@BjoernQ]: https://github.com/BjoernQ +[@arjanmels]: https://github.com/arjanmels +[@t-moe]: https://github.com/t-moe +[@bugadani]: https://github.com/bugadani \ No newline at end of file From d178c34e69de5493e3c0cfd7af15e021735761c5 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Wed, 19 Feb 2025 20:28:05 +0800 Subject: [PATCH 02/15] Review comments --- content/blog/rust-esp-hal-beta/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index b859f28c4..1cb3d1b13 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -14,11 +14,11 @@ tags: --- -We're extremely excited to announce the `1.0.0-beta.0` release for esp-hal, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the the journey of how we got here. If you're just interested in what we're stabilizing today [click here](#targeting-stability) to jump to it. +We're extremely excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the the journey of how we got here. If you're just interested in what we're stabilizing today [click here](#targeting-stability) to jump to it. ### Where it all started -In 2019 I created the esp-rs org which laid dormant for some time. At the time, [Espressif] was still using the [Xtensa] architecture for it's chip lineup which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far to cumbersome. Fast-forward to 2020 and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was extremely excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had fortunately been merged just a bit earlier. I had to set this project aside for a while, but I got back to it and managed to write the worlds first Rust blinky on an esp32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post really stood out to me. +In 2019 I created the esp-rs org which laid dormant for some time. At the time, [Espressif] was still using the [Xtensa] architecture for it's chip lineup which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far to cumbersome. Fast-forward to 2020 and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was extremely excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had fortunately been merged just a bit earlier. I had to set this project aside for a while, but I got back to it and managed to write the worlds first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post really stood out to me. > Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. @@ -32,7 +32,7 @@ Espressif had been observing our work (and may I add, were _extremely_ helpful i ### Bringing up the ecosystem -It has been possible to write embedded Rust applications on stable since 2018, but most of the ecosystem revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us given that Espressif has just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are arch independent, the tooling is a different story, and over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. +It has been possible to write embedded Rust applications on stable since 2018, but most of the ecosystem revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us given that Espressif has just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are arch independent, the tooling is a different story, and over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, they have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we had is that we we're the primary users of the LLVM Xtensa fork, which meant when there was a bug in some code-gen we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it as the backend is in very good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long long time), most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel. @@ -69,7 +69,7 @@ Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabi - `#[main]` macro - How esp-hal and friends are configured via [esp-config] -With the exception of the list above, everything in else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. +With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. ### What about the other no_std esp crates? @@ -88,13 +88,13 @@ As this is a beta release, we'd absolutely love to hear your feedback on esp-hal We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to setup in embedded, please do give it a try by first installing the tool with -```rust +```bash cargo install esp-generate ``` then, to generate a project for the ESP32-C6, run -```rust +```bash esp-generate --chip esp32c6 NAME_OF_PROJECT ``` @@ -102,7 +102,7 @@ We're currently rewriting the [book], but in the meantime it can still be helpfu ### Where does this leave the standard library port? -At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's silently been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to esp-hal and the other no_std crates. +At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's silently been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to `esp-hal` and the other `no_std` crates. ### What's next? From d5da144e025902b33d4c26aeafb520bd7dede39f Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Wed, 19 Feb 2025 15:38:12 +0000 Subject: [PATCH 03/15] revision 2 --- content/blog/rust-esp-hal-beta/index.md | 69 +++++++++++++------------ 1 file changed, 37 insertions(+), 32 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 1cb3d1b13..fcb05fb28 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -1,6 +1,6 @@ --- title: "esp-hal 1.0.0 beta announcement" -date: 2024-02-11 +date: 2025-02-25 showAuthor: true featureAsset: "img/featured/featured-espressif.webp" authors: @@ -14,35 +14,35 @@ tags: --- -We're extremely excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the the journey of how we got here. If you're just interested in what we're stabilizing today [click here](#targeting-stability) to jump to it. +We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. -### Where it all started +### Where It All Started -In 2019 I created the esp-rs org which laid dormant for some time. At the time, [Espressif] was still using the [Xtensa] architecture for it's chip lineup which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far to cumbersome. Fast-forward to 2020 and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was extremely excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had fortunately been merged just a bit earlier. I had to set this project aside for a while, but I got back to it and managed to write the worlds first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post really stood out to me. +In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was still producing new [Xtensa] architecture based chips which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. > Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. -I think it's safe to say the ball definitely rolled. +It's safe to say the ball definitely rolled. -### Espressif's official support for Rust +### Espressif’s Official Support for Rust -Not long after that initial blog post Espressif started sponsoring my work and allowed me continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Whilst myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things, [@reitermarkus] initially and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF] which was not only an amazing technical feat, but also gave users a big head start because we could use the stable and tested code from esp-idf without having to write all the drivers from scratch for `no_std` immediately. +Not long after that initial blog post Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. -Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they we're keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team and I along with [@jessebraham] gladly accepted. +Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I along with [@jessebraham] gladly accepted. -### Bringing up the ecosystem +### Bringing Up the Ecosystem -It has been possible to write embedded Rust applications on stable since 2018, but most of the ecosystem revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us given that Espressif has just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are arch independent, the tooling is a different story, and over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. +It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. -Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, they have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we had is that we we're the primary users of the LLVM Xtensa fork, which meant when there was a bug in some code-gen we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it as the backend is in very good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long long time), most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel. +Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we had is that we were the primary users of the LLVM Xtensa fork, which meant when there was a bug in some code-gen we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in very good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue]. -### Focussing on `no_std` crates +### Focussing on `no_std` Crates -In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` WiFi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! +In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! -We spent the entirety of 2022 and most of 2023 working exclusively on chip support. Making sure new chips were supported, and trying to support as many peripherals as possible. During this time we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. This seemed like a good idea at the time (and I wouldn't say it was a bad idea), but by the end of 2023 we realized that trying to support everything that the chips can do (and trust me, there is _a lot_ try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time frame with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. +We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. -### Targeting stability +### Targeting Stability The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which worked in a very similar way to [defmt-test] but has a couple of advantages: @@ -51,11 +51,18 @@ The first step to stability, and something that had been on our backlog for a wh Its been working extremely well for us, and we've been amassing an ever growing list of test cases in the [hil-test](https://github.com/esp-rs/esp-hal/tree/main/hil-test/tests) crate. -The next step, was figuring out what our APIs should look like after all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which I suppose is why many HALs including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. +The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! -The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead starting self-hosting our docs, with a chip and version selector to combat this. Once again, this was heavily inspired by [embassy]'s prior work in this area. +```rust +- GpioPin, RA, IRA, PINTYPE, SIG, GPIONUM> ++ Output +``` + +The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. + +The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead starting self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. -### Our stabilization strategy +### Our Stabilization Strategy Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabilization to: @@ -65,28 +72,24 @@ Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabi - UART - SPI - I2C -- A couple of miscellaneous system APIs (SoC reset, etc), +- A couple of miscellaneous system APIs (SoC reset, etc.) - `#[main]` macro - How esp-hal and friends are configured via [esp-config] With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. -### What about the other no_std esp crates? +### What About the Other `no_std` `esp-*` Crates? esp-hal is the foundation of many of the esp-rs ecosystem crates, [esp-wifi] is our next stabilization target, and builds directly on top of esp-hal. The end goal is of course to have every `esp-*` crate with a 1.0+ release. -### Do you plan on releasing esp-hal 2.0.0 at some point? - -As of right now, we don't have plans to ever release a esp-hal 2.0 release. If we do need to, we have done some [semver experiments](https://github.com/MabezDev/semver-playground/tree/master) and we've determined that we can release a 2.0 release without breaking our ecosystem, provided we've got driver construction nailed. We've spent quite a lot of time and resources in this area, and we think we're in a good place. - -### Call for testing +### Call for Testing As this is a beta release, we'd absolutely love to hear your feedback on esp-hal as it currently stands! Whether you've used it before, or you're about to try it out for the first time, any feedback is most welcome! * Please open issues for anything that should be working that isn't * Please open discussions to discuss API decisions that perhaps aren't quite as ergonomic or thought through as we intended -We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to setup in embedded, please do give it a try by first installing the tool with +We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to set up in embedded, please do give it a try by first installing the tool with ```bash cargo install esp-generate @@ -100,21 +103,21 @@ esp-generate --chip esp32c6 NAME_OF_PROJECT We're currently rewriting the [book], but in the meantime it can still be helpful to read it to get an overview of the ecosystem. -### Where does this leave the standard library port? +### Where Does This Leave the Standard Library Port? At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's silently been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to `esp-hal` and the other `no_std` crates. -### What's next? +### What’s Next? -Our focus now is to keep pushing until esp-hal 1.0, at which point we'll split our efforts and try to stabilize more things in esp-hal, as well as push for a stable WiFi/BLE story. Preparing for the full esp-hal 1.0 release requires a overhaul of the [book], along with a bunch of documentation and polish all round. Finally we need to ensure our tooling is in a good place and we plan to make a new [espflash] release to accomplish that. +Our focus now is to keep pushing until esp-hal 1.0. We'll then split our efforts and try to stabilize more things in esp-hal whilst also pushing for a stable Wi-Fi/BLE story. Preparing for the full esp-hal 1.0 release requires an overhaul of the [book], along with a bunch of documentation and polish all round. Finally, we need to ensure our tooling is in a good place, so we plan to make a new [espflash] release to accomplish that. -This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also cannot thank the Rust team at Espressif, they're awesome to work with a oh so very talented! If you're attending RustNL this year come say hi! +This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! --- -[^1]: There are some binary blobs to run the WiFi driver which we link to. +[^1]: There are some binary blobs to run the Wi-Fi driver which we link to. [mrustc]: https://github.com/thepowersgang/mrustc @@ -129,7 +132,7 @@ If you're a company using (or considering) Rust on our chips, please do contact [defmt-test]: https://github.com/knurling-rs/defmt/tree/main/firmware/defmt-test [official Rust embedded book]: https://docs.rust-embedded.org/book/static-guarantees/typestate-programming.html [DEVELOPER-GUIDELINES]: https://github.com/esp-rs/esp-hal/blob/main/documentation/DEVELOPER-GUIDELINES.md - +[the tracking issue]: https://github.com/espressif/llvm-project/issues/4 [espflash]: https://github.com/esp-rs/espflash [esp-hal]: https://github.com/esp-rs/esp-hal/tree/main/esp-hal [esp-wifi]: https://github.com/esp-rs/esp-hal/tree/main/esp-wifi @@ -138,6 +141,8 @@ If you're a company using (or considering) Rust on our chips, please do contact [esp-generate]: https://github.com/esp-rs/esp-generate [book]: https://github.com/esp-rs/book [esp-config]: https://crates.io/crates/esp-config + +[docs.espressif.com/projects/rust]: https://preview-docs.espressif.com/projects/rust/ [@reitermarkus]: https://github.com/reitermarkus [@ivmarkov]: https://github.com/ivmarkov From c93d27f02aa3b6c2178f5eba79e49d04e4ddc274 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Thu, 20 Feb 2025 11:16:10 +0000 Subject: [PATCH 04/15] revision 3 --- content/blog/rust-esp-hal-beta/index.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index fcb05fb28..cc847e8e6 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -34,7 +34,7 @@ Espressif had been observing our work (and may I add, were _extremely_ helpful i It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. -Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we had is that we were the primary users of the LLVM Xtensa fork, which meant when there was a bug in some code-gen we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in very good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue]. +Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. ### Focussing on `no_std` Crates @@ -115,8 +115,6 @@ This release would not have been possible without the help from the embedded Rus If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! ---- - [^1]: There are some binary blobs to run the Wi-Fi driver which we link to. From 9e6e1b246fb44cf9d4ad02ed1256c05ebc2e4ad6 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Thu, 20 Feb 2025 11:18:12 +0000 Subject: [PATCH 05/15] revision 4 --- content/blog/rust-esp-hal-beta/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index cc847e8e6..7057bb8a6 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -89,7 +89,7 @@ As this is a beta release, we'd absolutely love to hear your feedback on esp-hal * Please open issues for anything that should be working that isn't * Please open discussions to discuss API decisions that perhaps aren't quite as ergonomic or thought through as we intended -We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to set up in embedded, please do give it a try by first installing the tool with +We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to set up in embedded. Please do give it a try by first installing the tool with ```bash cargo install esp-generate @@ -105,7 +105,7 @@ We're currently rewriting the [book], but in the meantime it can still be helpfu ### Where Does This Leave the Standard Library Port? -At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's silently been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to `esp-hal` and the other `no_std` crates. +At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to `esp-hal` and the other `no_std` crates. ### What’s Next? From 176c326348dc7b7c28ce7359fb6474878a285743 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Thu, 20 Feb 2025 15:04:29 +0000 Subject: [PATCH 06/15] revision 5 --- content/blog/rust-esp-hal-beta/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 7057bb8a6..09dd95742 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -72,6 +72,7 @@ Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabi - UART - SPI - I2C +- The `time` module, which provides `Instant`, `Duration` and `Rate` - A couple of miscellaneous system APIs (SoC reset, etc.) - `#[main]` macro - How esp-hal and friends are configured via [esp-config] From c5b2fd14b8fb25dcbdd2b5aa79d006255fe147b7 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Fri, 21 Feb 2025 15:19:14 +0000 Subject: [PATCH 07/15] esp-rs logo for feature image --- content/blog/rust-esp-hal-beta/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 09dd95742..1c5419632 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -2,7 +2,7 @@ title: "esp-hal 1.0.0 beta announcement" date: 2025-02-25 showAuthor: true -featureAsset: "img/featured/featured-espressif.webp" +featureAsset: "img/featured/featured-rust.webp" authors: - scott-mabin tags: From 71bcf25795b971b9aca4cf8f3c2e084c2542e38f Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Fri, 21 Feb 2025 15:21:06 +0000 Subject: [PATCH 08/15] rework xtensa sentence --- content/blog/rust-esp-hal-beta/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 1c5419632..2002a1326 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -18,7 +18,7 @@ We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ ### Where It All Started -In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was still producing new [Xtensa] architecture based chips which whilst powerful had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. +In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. > Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. From ec4b91a681f48699f2ea564cbc5225575a68da9f Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Mon, 24 Feb 2025 13:38:52 +0000 Subject: [PATCH 09/15] revision 6 --- content/blog/rust-esp-hal-beta/index.md | 58 ++++++++++++++++--------- 1 file changed, 38 insertions(+), 20 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 2002a1326..56d29eeb5 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -14,44 +14,62 @@ tags: --- -We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. +We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. + +Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. ### Where It All Started -In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. +In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. + +Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. -> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. +> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe code and there are no real abstractions here, and you are right; but it's something to get the ball rolling. It's safe to say the ball definitely rolled. ### Espressif’s Official Support for Rust -Not long after that initial blog post Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. +Not long after that initial blog post, Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. -Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I along with [@jessebraham] gladly accepted. +Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I, along with [@jessebraham] gladly accepted. ### Bringing Up the Ecosystem -It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. +It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. + +Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. + +Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. + +Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. -Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. +### Focusing on `no_std` Crates -### Focussing on `no_std` Crates +In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). -In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! +Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! -We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. +We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. + +This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. ### Targeting Stability -The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which worked in a very similar way to [defmt-test] but has a couple of advantages: +The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. + +We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which works in a similar way to [defmt-test] but has a couple of advantages: * It supports ARM, RISC-V and Xtensa (thanks to some great work by [@bugadani] to add Xtensa support to [probe-rs]) * It supported `async` tests Its been working extremely well for us, and we've been amassing an ever growing list of test cases in the [hil-test](https://github.com/esp-rs/esp-hal/tree/main/hil-test/tests) crate. -The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! +The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. + +This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. + +Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! ```rust - GpioPin, RA, IRA, PINTYPE, SIG, GPIONUM> @@ -60,24 +78,24 @@ The next step, was figuring out what our APIs should look like. After all we can The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. -The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead starting self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. +The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead started self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. ### Our Stabilization Strategy Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabilization to: - Initializing the hal, `esp_hal::init` and the relevant configuration associated with that. -- Four "core" drivers to start +- Four "core" drivers to start: - GPIO - UART - SPI - I2C -- The `time` module, which provides `Instant`, `Duration` and `Rate` -- A couple of miscellaneous system APIs (SoC reset, etc.) -- `#[main]` macro -- How esp-hal and friends are configured via [esp-config] +- The `time` module, which provides `Instant`, `Duration`, and `Rate`. +- A couple of miscellaneous system APIs (SoC reset, etc.). +- `#[main]` macro. +- How esp-hal and friends are configured via [esp-config]. -With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. +With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates, users will be able to remove the `unstable` feature from their `Cargo.toml` files. ### What About the Other `no_std` `esp-*` Crates? @@ -112,7 +130,7 @@ At this time we're officially marking the `std` _crates_ as community supported, Our focus now is to keep pushing until esp-hal 1.0. We'll then split our efforts and try to stabilize more things in esp-hal whilst also pushing for a stable Wi-Fi/BLE story. Preparing for the full esp-hal 1.0 release requires an overhaul of the [book], along with a bunch of documentation and polish all round. Finally, we need to ensure our tooling is in a good place, so we plan to make a new [espflash] release to accomplish that. -This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! +This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year (2025) come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! From 715079c787fcd8d7c9946efa1bfaa70fbdbca6a6 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Mon, 24 Feb 2025 13:41:48 +0000 Subject: [PATCH 10/15] revision 7 --- content/blog/rust-esp-hal-beta/index.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 56d29eeb5..02f4720fd 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -1,6 +1,6 @@ --- title: "esp-hal 1.0.0 beta announcement" -date: 2025-02-25 +date: 2025-02-24 showAuthor: true featureAsset: "img/featured/featured-rust.webp" authors: @@ -158,8 +158,7 @@ If you're a company using (or considering) Rust on our chips, please do contact [esp-generate]: https://github.com/esp-rs/esp-generate [book]: https://github.com/esp-rs/book [esp-config]: https://crates.io/crates/esp-config - -[docs.espressif.com/projects/rust]: https://preview-docs.espressif.com/projects/rust/ +[docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/ [@reitermarkus]: https://github.com/reitermarkus [@ivmarkov]: https://github.com/ivmarkov From 9a8bdb42062ede50b725d332e5863d753fdaf571 Mon Sep 17 00:00:00 2001 From: Scott Mabin Date: Mon, 24 Feb 2025 15:29:15 +0000 Subject: [PATCH 11/15] Update docs link --- content/blog/rust-esp-hal-beta/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md index 02f4720fd..ee2145dad 100644 --- a/content/blog/rust-esp-hal-beta/index.md +++ b/content/blog/rust-esp-hal-beta/index.md @@ -158,7 +158,8 @@ If you're a company using (or considering) Rust on our chips, please do contact [esp-generate]: https://github.com/esp-rs/esp-generate [book]: https://github.com/esp-rs/book [esp-config]: https://crates.io/crates/esp-config -[docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/ + +[docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/index.html [@reitermarkus]: https://github.com/reitermarkus [@ivmarkov]: https://github.com/ivmarkov From 2b0014dfdbb4cb21b45149b27a0a553fed1a3d77 Mon Sep 17 00:00:00 2001 From: Pedro Minatel Date: Mon, 24 Feb 2025 21:06:13 +0000 Subject: [PATCH 12/15] Fix folder duplicated --- .../blog/2025/02/rust-esp-hal-beta/index.md | 62 ++++--- content/blog/rust-esp-hal-beta/index.md | 170 ------------------ 2 files changed, 40 insertions(+), 192 deletions(-) delete mode 100644 content/blog/rust-esp-hal-beta/index.md diff --git a/content/blog/2025/02/rust-esp-hal-beta/index.md b/content/blog/2025/02/rust-esp-hal-beta/index.md index aae527c72..ee2145dad 100644 --- a/content/blog/2025/02/rust-esp-hal-beta/index.md +++ b/content/blog/2025/02/rust-esp-hal-beta/index.md @@ -14,44 +14,62 @@ tags: --- -We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. +We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. + +Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. ### Where It All Started -In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. +In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. + +Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. -> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe and there are no real abstractions here, and you are right; but it's something to get the ball rolling. +> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe code and there are no real abstractions here, and you are right; but it's something to get the ball rolling. It's safe to say the ball definitely rolled. ### Espressif’s Official Support for Rust -Not long after that initial blog post Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. +Not long after that initial blog post, Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. -Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I along with [@jessebraham] gladly accepted. +Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I, along with [@jessebraham] gladly accepted. ### Bringing Up the Ecosystem -It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. +It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. + +Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. + +Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. + +Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. -Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. +### Focusing on `no_std` Crates -### Focussing on `no_std` Crates +In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). -In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! +Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! -We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. +We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. + +This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. ### Targeting Stability -The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which worked in a very similar way to [defmt-test] but has a couple of advantages: +The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. + +We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which works in a similar way to [defmt-test] but has a couple of advantages: * It supports ARM, RISC-V and Xtensa (thanks to some great work by [@bugadani] to add Xtensa support to [probe-rs]) * It supported `async` tests Its been working extremely well for us, and we've been amassing an ever growing list of test cases in the [hil-test](https://github.com/esp-rs/esp-hal/tree/main/hil-test/tests) crate. -The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! +The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. + +This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. + +Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! ```rust - GpioPin, RA, IRA, PINTYPE, SIG, GPIONUM> @@ -60,24 +78,24 @@ The next step, was figuring out what our APIs should look like. After all we can The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. -The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead starting self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. +The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead started self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. ### Our Stabilization Strategy Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabilization to: - Initializing the hal, `esp_hal::init` and the relevant configuration associated with that. -- Four "core" drivers to start +- Four "core" drivers to start: - GPIO - UART - SPI - I2C -- The `time` module, which provides `Instant`, `Duration` and `Rate` -- A couple of miscellaneous system APIs (SoC reset, etc.) -- `#[main]` macro -- How esp-hal and friends are configured via [esp-config] +- The `time` module, which provides `Instant`, `Duration`, and `Rate`. +- A couple of miscellaneous system APIs (SoC reset, etc.). +- `#[main]` macro. +- How esp-hal and friends are configured via [esp-config]. -With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates users will be able to remove the `unstable` feature from their `Cargo.toml` files. +With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates, users will be able to remove the `unstable` feature from their `Cargo.toml` files. ### What About the Other `no_std` `esp-*` Crates? @@ -112,7 +130,7 @@ At this time we're officially marking the `std` _crates_ as community supported, Our focus now is to keep pushing until esp-hal 1.0. We'll then split our efforts and try to stabilize more things in esp-hal whilst also pushing for a stable Wi-Fi/BLE story. Preparing for the full esp-hal 1.0 release requires an overhaul of the [book], along with a bunch of documentation and polish all round. Finally, we need to ensure our tooling is in a good place, so we plan to make a new [espflash] release to accomplish that. -This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! +This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year (2025) come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! @@ -140,8 +158,8 @@ If you're a company using (or considering) Rust on our chips, please do contact [esp-generate]: https://github.com/esp-rs/esp-generate [book]: https://github.com/esp-rs/book [esp-config]: https://crates.io/crates/esp-config - -[docs.espressif.com/projects/rust]: https://preview-docs.espressif.com/projects/rust/ + +[docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/index.html [@reitermarkus]: https://github.com/reitermarkus [@ivmarkov]: https://github.com/ivmarkov diff --git a/content/blog/rust-esp-hal-beta/index.md b/content/blog/rust-esp-hal-beta/index.md deleted file mode 100644 index ee2145dad..000000000 --- a/content/blog/rust-esp-hal-beta/index.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -title: "esp-hal 1.0.0 beta announcement" -date: 2025-02-24 -showAuthor: true -featureAsset: "img/featured/featured-rust.webp" -authors: - - scott-mabin -tags: - - Esp32 - - Rust - - Xtensa - - RISCV - - Announcement - ---- - -We're excited to announce the `1.0.0-beta.0` release for `esp-hal`, the _first_ vendor-backed Rust SDK! This has been a nearly 6 year long process to get to this point, and we now feel we have a solid 1.0 strategy. - -Let us take you on the journey of how we got here. If you're just interested in what we're stabilizing today, [click here](#targeting-stability) to jump to it. - -### Where It All Started - -In 2019, I created the esp-rs organization, which laid dormant for some time. At the time, [Espressif] was exclusively using the [Xtensa] architecture for their chips which, whilst powerful, had one big caveat for Rust support: there was no LLVM backend for Xtensa. I tried to use [mrustc] to cross-compile Rust to C, and then use the GCC Xtensa toolchain but whilst I had some minor success the workflow was far too cumbersome. - -Fast-forward a few months and Espressif announced the first iteration of their [Xtensa enabled LLVM fork] with the intention of getting it upstreamed. I was excited about this, and I got to work integrating this Xtensa enabled LLVM into the Rust compiler. I succeeded, with a lot of help from members of the Rust community and a reference set of PRs for RISC-V which had been merged just a bit earlier in the year. This project was set aside for a while, but I got back to it and managed to write the world's first Rust blinky on an ESP32! I documented my early findings in a series of [posts on my personal website]. I read these posts again (mostly to remind myself what on earth I was doing 5 years ago), and one quote from my first post stood out to me. - -> Now I know what most of you are thinking at this point, it's not very Rusty; it contains bundles of unsafe code and there are no real abstractions here, and you are right; but it's something to get the ball rolling. - -It's safe to say the ball definitely rolled. - -### Espressif’s Official Support for Rust - -Not long after that initial blog post, Espressif started sponsoring my work and allowed me to continue working on it in my spare time. At the same time, the community around esp-rs was starting to grow, and I really can't thank these early contributors enough. Myself and a few early contributors, namely [@jessebraham], and [@arjanmels] mostly focussed on the `no_std` side of things. Initially [@reitermarkus] and eventually [@ivmarkov] ported the Rust standard library which built on [ESP-IDF]. This was a great addition as it gave us a big head start because we could use the stable and tested code from ESP-IDF without having to write all the drivers from scratch for `no_std` immediately. - -Espressif had been observing our work (and may I add, were _extremely_ helpful in answering any questions we had) and by 2021, they were keen to adopt it officially. They reached out to me and some other community contributors about a position in a newly forming Rust team, and I, along with [@jessebraham] gladly accepted. - -### Bringing Up the Ecosystem - -It has been possible to write embedded Rust applications on stable since 2018. Most of the ecosystem, however, revolved around chips using the ARM architecture, which posed a bit of an uphill battle for us. Espressif had just released its last Xtensa chip (the ESP32-S3) and was now bringing out RISC-V based chips. - -Whilst most crates in the embedded Rust ecosystem are architecture independent, the tooling is a different story. Over the years we've spent _a lot_ of time contributing to various open source projects, like [probe-rs] to either improve, or in the case of Xtensa, add support. This work is still on going, but we're quite happy with the usability of the tooling on our chips now. - -Xtensa based chips posed many challenges for us. We ended up writing [xtensa-lx and xtensa-lx-rt] using the proprietary (at the time, Cadence, the owners of the Xtensa IP have since released an open version) Xtensa instruction set manual. There was at least _some_ runtime/startup support for RISC-V, but absolutely nothing for Xtensa in the Rust ecosystem. - -Another challenge we faced is that we were the primary users of the LLVM Xtensa fork. This meant when there was a bug in code-generation we were the unfortunate souls to run into it. This ate copious amounts of developer time, but in the end it was worth it, as the backend is in good shape now. There is also a huge amount of progress to report on the upstreaming front for LLVM (which was stalled for a long, long time). Most of the base ISA is now in LLVM proper, and the remaining patches can be submitted in parallel, see [the tracking issue] for more details. - -### Focusing on `no_std` Crates - -In late 2021, [@jessebraham] started [esp-hal] with the aims of replacing the chip specific `esp32-hal` which was currently being worked on. It worked out amazingly well, and we had a setup where we could share driver code across multiple chips! It wasn't long before most of Espressif's Rust team started to contributing to it whilst also maintaining the standard library port (more on that later). - -Not long after, [@BjoernQ] joined the team and set out to add support for arguably the most important peripheral in an ESP32, the radio. He achieved success, and we've had `no_std` Wi-Fi, BLE and [ESP-NOW] support ever since! I cannot state how important these steps were, as it gave us confidence that we could build a fully functioning SDK supporting a whole lineup of chips, in pure Rust[^1]! - -We spent the entirety of 2022 and most of 2023 working exclusively on chip support; making sure new chips were supported, and trying to support as many peripherals as possible. During this time, we also experimented with adding `async` versions of some drivers, as the [embassy] project began to flourish. - -This seemed like a good idea at the time but by the end of 2023 we realized that trying to support everything that the chips can do (there is _a lot_, try looking at a reference manual if you're curious) whilst an admirable goal is likely unachievable in a reasonable time with the size of our team. We soon realized that API stability is far more important than having _everything_ supported. - -### Targeting Stability - -The first step to stability, and something that had been on our backlog for a while was getting hardware in loop testing (HIL) working. This would be crucial to ensure that we ship reliable, bug-free software. HIL testing works by running tests on the device itself, through a debugger interface to talk to the host machine. - -We initially planned on using [defmt-test] to run tests on our devices, but sadly it only supports ARM. Fortunately around this time, [@t-moe] created [embedded-test] which works in a similar way to [defmt-test] but has a couple of advantages: - - * It supports ARM, RISC-V and Xtensa (thanks to some great work by [@bugadani] to add Xtensa support to [probe-rs]) - * It supported `async` tests - -Its been working extremely well for us, and we've been amassing an ever growing list of test cases in the [hil-test](https://github.com/esp-rs/esp-hal/tree/main/hil-test/tests) crate. - -The next step, was figuring out what our APIs should look like. After all we can't stabilize something unless we're sure we're going in the right direction. We spent some time reviewing the ecosystem and our own issue tracker for usability issues and found that many of the usability difficulties come from too many generic parameters on drivers. - -This was not the only thing we found of course, but it was the biggest shift in our visible API. This was mostly inspired by the [embassy] project's in-tree HALs. The [official Rust embedded book] actually promotes the use of typestating etc, which is why many HALs, including esp-hal ended up in this situation, but in our opinion the less generics the better, for reasons beyond just usability; there are also some nice code size improvements which are really important for small constrained resources devices. - -Here is a `diff` of type information of our old pin types, versus the new ones. Everything is now hidden within the type itself, **seven** generic paramters to zero. This makes storing a array of pins trivial, as they are all the same type! - -```rust -- GpioPin, RA, IRA, PINTYPE, SIG, GPIONUM> -+ Output -``` - -The remainder of our findings we placed in a living document, [DEVELOPER-GUIDELINES] which we used, and will continue to use to stabilize parts of the HAL. - -The final step, was figuring out how we were going to document this. Supporting multiple chips from one crate poses an interesting challenge. We can no longer use docs.rs for our documentation (we can, and do, but only for one chip) so we've instead started self-hosting our docs, with a chip and version selector to combat this. You can view the docs on the official [docs.espressif.com/projects/rust] site. Once again, this was heavily inspired by [embassy]'s prior work in this area. - -### Our Stabilization Strategy - -Our stabilization strategy is quite simple, we've limited the scope of 1.0 stabilization to: - -- Initializing the hal, `esp_hal::init` and the relevant configuration associated with that. -- Four "core" drivers to start: - - GPIO - - UART - - SPI - - I2C -- The `time` module, which provides `Instant`, `Duration`, and `Rate`. -- A couple of miscellaneous system APIs (SoC reset, etc.). -- `#[main]` macro. -- How esp-hal and friends are configured via [esp-config]. - -With the exception of the list above, everything else in esp-hal is now feature gated behind the `unstable` feature. With the scope limited, post 1.0 we can incrementally stabilize drivers, much like the Rust project itself does. This is quite a small amount to stabilize initially, however we feel it's enough to build a foundation on. It's expected that for most complex projects users will opt-in to the `unstable` feature. Over time, as we stabilize more drivers, and eventually more crates, users will be able to remove the `unstable` feature from their `Cargo.toml` files. - -### What About the Other `no_std` `esp-*` Crates? - -esp-hal is the foundation of many of the esp-rs ecosystem crates, [esp-wifi] is our next stabilization target, and builds directly on top of esp-hal. The end goal is of course to have every `esp-*` crate with a 1.0+ release. - -### Call for Testing - -As this is a beta release, we'd absolutely love to hear your feedback on esp-hal as it currently stands! Whether you've used it before, or you're about to try it out for the first time, any feedback is most welcome! - -* Please open issues for anything that should be working that isn't -* Please open discussions to discuss API decisions that perhaps aren't quite as ergonomic or thought through as we intended - -We've created our own project generation tool, [esp-generate] to bootstrap starting a project, which is often a bit of a tricky thing to set up in embedded. Please do give it a try by first installing the tool with - -```bash -cargo install esp-generate -``` - -then, to generate a project for the ESP32-C6, run - -```bash -esp-generate --chip esp32c6 NAME_OF_PROJECT -``` - -We're currently rewriting the [book], but in the meantime it can still be helpful to read it to get an overview of the ecosystem. - -### Where Does This Leave the Standard Library Port? - -At this time we're officially marking the `std` _crates_ as community supported, which we've reflected on the [organization landing page](https://github.com/esp-rs/). We will still maintain the upstream compiler targets, and ensure that those targets continue to function, but `esp-idf-sys`, `esp-idf-hal` and `esp-idf-svc` are now community projects. It's been moving this way for a while, but we'd like to officially announce it here. Users wanting a more stable (and official) development environment should transition to `esp-hal` and the other `no_std` crates. - -### What’s Next? - -Our focus now is to keep pushing until esp-hal 1.0. We'll then split our efforts and try to stabilize more things in esp-hal whilst also pushing for a stable Wi-Fi/BLE story. Preparing for the full esp-hal 1.0 release requires an overhaul of the [book], along with a bunch of documentation and polish all round. Finally, we need to ensure our tooling is in a good place, so we plan to make a new [espflash] release to accomplish that. - -This release would not have been possible without the help from the embedded Rust community, the embedded working group, and of course the esp-rs community and contributors which have heavily impacted how we've developed our Rust offering. I also can't thank the Rust team at Espressif, they're awesome to work with and oh so very talented! If you're attending RustNL this year (2025) come say hi! We'll have an Espressif booth setup, and you can catch us walking around the event too! - -If you're a company using (or considering) Rust on our chips, please do contact rust-support@espressif.com, we'd love to hear from you! - -[^1]: There are some binary blobs to run the Wi-Fi driver which we link to. - - -[mrustc]: https://github.com/thepowersgang/mrustc -[Espressif]: https://www.espressif.com/ -[Xtensa]: https://en.wikipedia.org/wiki/Tensilica -[Xtensa enabled LLVM fork]: https://esp32.com/viewtopic.php?t=9226&p=38466 -[posts on my personal website]: https://mabez.dev/blog/posts/ -[ESP-IDF]: https://github.com/espressif/esp-idf -[probe-rs]: https://probe.rs/ -[embedded-test]: https://github.com/probe-rs/embedded-test -[embassy]: https://github.com/embassy-rs -[defmt-test]: https://github.com/knurling-rs/defmt/tree/main/firmware/defmt-test -[official Rust embedded book]: https://docs.rust-embedded.org/book/static-guarantees/typestate-programming.html -[DEVELOPER-GUIDELINES]: https://github.com/esp-rs/esp-hal/blob/main/documentation/DEVELOPER-GUIDELINES.md -[the tracking issue]: https://github.com/espressif/llvm-project/issues/4 -[espflash]: https://github.com/esp-rs/espflash -[esp-hal]: https://github.com/esp-rs/esp-hal/tree/main/esp-hal -[esp-wifi]: https://github.com/esp-rs/esp-hal/tree/main/esp-wifi -[ESP-NOW]: https://www.espressif.com/en/solutions/low-power-solutions/esp-now -[xtensa-lx and xtensa-lx-rt]: https://github.com/esp-rs/esp-hal/tree/main/xtensa-lx-rt -[esp-generate]: https://github.com/esp-rs/esp-generate -[book]: https://github.com/esp-rs/book -[esp-config]: https://crates.io/crates/esp-config - -[docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/index.html - -[@reitermarkus]: https://github.com/reitermarkus -[@ivmarkov]: https://github.com/ivmarkov -[@jessebraham]: https://github.com/jessebraham -[@BjoernQ]: https://github.com/BjoernQ -[@arjanmels]: https://github.com/arjanmels -[@t-moe]: https://github.com/t-moe -[@bugadani]: https://github.com/bugadani \ No newline at end of file From 33fd0bfddd5dfcd8970373c1e3f162cd56cb5f2b Mon Sep 17 00:00:00 2001 From: Pedro Minatel Date: Mon, 24 Feb 2025 21:30:09 +0000 Subject: [PATCH 13/15] Fix the link check --- content/blog/2025/02/rust-esp-hal-beta/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/blog/2025/02/rust-esp-hal-beta/index.md b/content/blog/2025/02/rust-esp-hal-beta/index.md index ee2145dad..366093bcd 100644 --- a/content/blog/2025/02/rust-esp-hal-beta/index.md +++ b/content/blog/2025/02/rust-esp-hal-beta/index.md @@ -158,9 +158,7 @@ If you're a company using (or considering) Rust on our chips, please do contact [esp-generate]: https://github.com/esp-rs/esp-generate [book]: https://github.com/esp-rs/book [esp-config]: https://crates.io/crates/esp-config - [docs.espressif.com/projects/rust]: https://docs.espressif.com/projects/rust/index.html - [@reitermarkus]: https://github.com/reitermarkus [@ivmarkov]: https://github.com/ivmarkov [@jessebraham]: https://github.com/jessebraham From 6a435328c628a76b8da4f0d9ed933365677bfdb7 Mon Sep 17 00:00:00 2001 From: Pedro Minatel Date: Mon, 24 Feb 2025 21:41:08 +0000 Subject: [PATCH 14/15] Add extra line --- content/blog/2025/02/rust-esp-hal-beta/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/2025/02/rust-esp-hal-beta/index.md b/content/blog/2025/02/rust-esp-hal-beta/index.md index 366093bcd..af3610c5c 100644 --- a/content/blog/2025/02/rust-esp-hal-beta/index.md +++ b/content/blog/2025/02/rust-esp-hal-beta/index.md @@ -165,4 +165,4 @@ If you're a company using (or considering) Rust on our chips, please do contact [@BjoernQ]: https://github.com/BjoernQ [@arjanmels]: https://github.com/arjanmels [@t-moe]: https://github.com/t-moe -[@bugadani]: https://github.com/bugadani \ No newline at end of file +[@bugadani]: https://github.com/bugadani From e7c7e55a17fc073d74c81cf4f253c10327ce0ec2 Mon Sep 17 00:00:00 2001 From: Pedro Minatel Date: Mon, 24 Feb 2025 21:51:54 +0000 Subject: [PATCH 15/15] Link issue --- content/blog/2025/02/rust-esp-hal-beta/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/2025/02/rust-esp-hal-beta/index.md b/content/blog/2025/02/rust-esp-hal-beta/index.md index af3610c5c..366093bcd 100644 --- a/content/blog/2025/02/rust-esp-hal-beta/index.md +++ b/content/blog/2025/02/rust-esp-hal-beta/index.md @@ -165,4 +165,4 @@ If you're a company using (or considering) Rust on our chips, please do contact [@BjoernQ]: https://github.com/BjoernQ [@arjanmels]: https://github.com/arjanmels [@t-moe]: https://github.com/t-moe -[@bugadani]: https://github.com/bugadani +[@bugadani]: https://github.com/bugadani \ No newline at end of file