7 ms·

Rust on the ESP32 (2019)

133 points by lnyan 6y ago

rbtying 6y ago
I’ve been playing with Rust on the ESP32 using these tools on and off over the last couple of months or so, relying more in linking to the existing FreeRTOS/C HAL for accessing the peripherals. One thing I haven’t quite figured out: a substantial number of onboard features are configurable at image build time, which then change the effective C libraries via preprocessor definitions. So, it doesn’t quite work to naively run bindgen on the header file once, and then embed that in a -sys crate and put it on crates.io I think you can hand craft a -sys crate with all the appropriate config options as cargo features, but that seems both very time-consuming and likely to drift from the newest esp-idf versions. The alternative of running bindgen periodically (e.g. as part of the build process) works fine for one project, but then how do you publish reusable libraries online?
- MrBuddyCasino 6y ago
  The ESP32 API surface is huge, and the libraries have many configuration settings. Rust-ifying this is a huge endeavour. One way could be to just interface with the vendor HAL using Rust wrapper, but doing that in a safe way that respects the lifetime rules can't be easy? Also AFAIK some lower level radio APIs are locked and hidden behind a binary blob, so the ESP32 can't be misused as a jammer. Its very tempting to try this due to the huge amount of resources the hardware has, but it is a huge amount of work. Just being able to access the registers isn't very valuable, the ESP is about Wifi, BT and I2S. If there are no ergonomic Rust APIs for those, why even bother?
  - elcritch 6y ago
    It's true and a bit surprising how much of the ESP32's API's are configurable or change based on config options. Espressif has built an impressive amount of functionality on top of FreeRTOS. It'd be nice to see Rust more widely adopted, but it seems to require an entirely rewritten SDK as so much of the API are C macros and defines. Given that I decided to go a middle ground and use Nim with its new ARC (GC reference counting and move semantics). In theory it's less efficient than compile time Rust memory management but it works well in practice. Wrapping the C API is trivial and handles all of the C defines as well as writing in C, since it compiles down to it. And you can use any Nim or C libraries. It's surprisingly effective! Except you still get data races from the C API's which Rust would likely help prevent. So it's cool to see someone toying with an xtensa llvm backend. I wish LLVM still fully supported a C backend so you could compile Rust to C and build that. Hopefully in the long run, more native rust libraries will exist for more full functionality embedded.
    - MrBuddyCasino 6y ago
      Was looking at Zig for the same reason, manual memory management but less error prone due to "defer", and a design ethos that is very reminiscent of C. Can even compile C directly! I really, really like the aesthetics of the language, but there is no xtensa backend yet. Rust might just be a leap too big and can only work in blank-slate scenarios.
      - elcritch 6y ago
        Zig seems promising too! But it’s still LLVM based (?), which seems to be a limitation in the embedded world. Nim’s templates/macros are nice for fiddly stuff. Not sure how Zig handles places where compile time macros can make things nice. Yah I figure in ~5 years Rust might be better positioned in embedded work as a goto solution.
        MrBuddyCasino 6y ago
        If you like macros, Zig might not be for you. Part of its mission statement: "There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros."
manaskarekar 6y ago
Follow up post https://mabez.dev/blog/posts/esp32-rust-svd-pac/ https://mabez.dev/blog/posts/esp32-rust-svd-pac/
bborud 6y ago
I would really love to see more interest in Rust from the embedded industry. With the influx of new developers into embedded programming I think there is an opportunity.
- weinzierl 6y ago
  Yes, especially when Rust could be a relief to many pains embedded software suffers from. The counter argument is of course that embedded software is very entrenched. Often we would be happy if we could use a normal C++ compiler like gcc or clang instead of the fragile pieces of art that semiconductor manufacturers give us.
  - bborud 6y ago
    I think the embedded world needs a bit of outside blood. Being able to replace C/C++ with something a bit more conducive to helping people develop correct code would be a great plus. But the tooling also needs some help. Good tooling that isn't a nightmare to set up and maintain is crucial.
    - usrusr 6y ago
      [edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers. I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.
StavrosK 6y ago
Does anyone know what the situation with Rust on the NRF is? It's all so new that there's no "getting started" guide, but even figuring out which repos to check out is hard.
- dutchmartin 6y ago
  There are crates for that [1]. But if you are new to rust and embedded, I would recommend to read through the rust embedded book [2] and practice with the stm32 board. [1] https://github.com/nrf-rs/nrf-hal https://github.com/nrf-rs/nrf-hal [2] https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/
  - StavrosK 6y ago
    Ah, thanks. I'm not new to embedded, just to Rust on embedded. STM32s are a bit too overpowered for me, I usually use ESP8266s, that's why I thought the NRF might be a good bet (and better supported by Rust).
- Avamander 6y ago
  I recommend you check out the PineTime project and Lup Yuen Lee's tutorials. It might give a nice starting point. https://github.com/lupyuen/pinetime-rust-mynewt https://github.com/lupyuen/pinetime-rust-mynewt https://medium.com/swlh/sneak-peek-of-pinetime-smart-watch-and-why-its-perfect-for-teaching-iot-81b74161c159 https://medium.com/swlh/sneak-peek-of-pinetime-smart-watch-a...
  - StavrosK 6y ago
    That's fantastic, thank you!
rkachowski 6y ago
would this presumably also run on the esp8266?
- swsieber 6y ago
  Yes, though IIRC a recent release broke esp8266 support accidentally. I haven't checked back to see if it's working again.
- rbtying 6y ago
  The compiler toolchain can cross compile to esp8266, but I think the pure Rust HAL is less developed there. If you use Rust to write components/code that link against the ESP-IDF, I’d imagine that would work? I have the toolchain in a Docker container if you want to try it out.
ncrmro 6y ago
Was learning a lot of rust and now c and Mabez and everyone else is really helpful on the esp-rs matrix channel.
muska3 6y ago
There's also this guide https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ Although, I'm more interested in learning STM32 development, due to recommendations that it is far superior to ESP32 boards. Anyone have some tips on how to get started on this front as a hobby?
- mdtusz 6y ago
  I ordered one of the STM32 development boards when this was first published. It's fairly straightforwards to get basic blinky demos working, but it was about at this point that I ran out of steam, and you're basically left to fend for yourself, implementing anything more complex from scratch. It may have changed since, but rust embedded definitely isn't hobbyist friendly unless the goal is to make things work, rather than to just make things.
  - muska3 6y ago
    Right, that's ultimately what I am worried about.
jolmg 6y ago
Lol. I was expecting the article to be about how to clean up metal corrosion from the terminals of an ESP32 chip.

133 points by lnyan 6y ago

I’ve been playing with Rust on the ESP32 using these tools on and off over the last couple of months or so, relying more in linking to the existing FreeRTOS/C HAL for accessing the peripherals. One thing I haven’t quite figured out: a substantial number of onboard features are configurable at image build time, which then change the effective C libraries via preprocessor definitions. So, it doesn’t quite work to naively run bindgen on the header file once, and then embed that in a -sys crate and put it on crates.io I think you can hand craft a -sys crate with all the appropriate config options as cargo features, but that seems both very time-consuming and likely to drift from the newest esp-idf versions. The alternative of running bindgen periodically (e.g. as part of the build process) works fine for one project, but then how do you publish reusable libraries online?

MrBuddyCasino 6y ago
The ESP32 API surface is huge, and the libraries have many configuration settings. Rust-ifying this is a huge endeavour. One way could be to just interface with the vendor HAL using Rust wrapper, but doing that in a safe way that respects the lifetime rules can't be easy? Also AFAIK some lower level radio APIs are locked and hidden behind a binary blob, so the ESP32 can't be misused as a jammer. Its very tempting to try this due to the huge amount of resources the hardware has, but it is a huge amount of work. Just being able to access the registers isn't very valuable, the ESP is about Wifi, BT and I2S. If there are no ergonomic Rust APIs for those, why even bother?
- elcritch 6y ago
  It's true and a bit surprising how much of the ESP32's API's are configurable or change based on config options. Espressif has built an impressive amount of functionality on top of FreeRTOS. It'd be nice to see Rust more widely adopted, but it seems to require an entirely rewritten SDK as so much of the API are C macros and defines. Given that I decided to go a middle ground and use Nim with its new ARC (GC reference counting and move semantics). In theory it's less efficient than compile time Rust memory management but it works well in practice. Wrapping the C API is trivial and handles all of the C defines as well as writing in C, since it compiles down to it. And you can use any Nim or C libraries. It's surprisingly effective! Except you still get data races from the C API's which Rust would likely help prevent. So it's cool to see someone toying with an xtensa llvm backend. I wish LLVM still fully supported a C backend so you could compile Rust to C and build that. Hopefully in the long run, more native rust libraries will exist for more full functionality embedded.
  - MrBuddyCasino 6y ago
    Was looking at Zig for the same reason, manual memory management but less error prone due to "defer", and a design ethos that is very reminiscent of C. Can even compile C directly! I really, really like the aesthetics of the language, but there is no xtensa backend yet. Rust might just be a leap too big and can only work in blank-slate scenarios.
    - elcritch 6y ago
      Zig seems promising too! But it’s still LLVM based (?), which seems to be a limitation in the embedded world. Nim’s templates/macros are nice for fiddly stuff. Not sure how Zig handles places where compile time macros can make things nice. Yah I figure in ~5 years Rust might be better positioned in embedded work as a goto solution.
      - MrBuddyCasino 6y ago
        If you like macros, Zig might not be for you. Part of its mission statement: "There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros."

manaskarekar 6y ago

Follow up post https://mabez.dev/blog/posts/esp32-rust-svd-pac/ https://mabez.dev/blog/posts/esp32-rust-svd-pac/

bborud 6y ago

I would really love to see more interest in Rust from the embedded industry. With the influx of new developers into embedded programming I think there is an opportunity.

weinzierl 6y ago
Yes, especially when Rust could be a relief to many pains embedded software suffers from. The counter argument is of course that embedded software is very entrenched. Often we would be happy if we could use a normal C++ compiler like gcc or clang instead of the fragile pieces of art that semiconductor manufacturers give us.
- bborud 6y ago
  I think the embedded world needs a bit of outside blood. Being able to replace C/C++ with something a bit more conducive to helping people develop correct code would be a great plus. But the tooling also needs some help. Good tooling that isn't a nightmare to set up and maintain is crucial.
  - usrusr 6y ago
    [edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers. I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.

StavrosK 6y ago

Does anyone know what the situation with Rust on the NRF is? It's all so new that there's no "getting started" guide, but even figuring out which repos to check out is hard.

dutchmartin 6y ago
There are crates for that [1]. But if you are new to rust and embedded, I would recommend to read through the rust embedded book [2] and practice with the stm32 board. [1] https://github.com/nrf-rs/nrf-hal https://github.com/nrf-rs/nrf-hal [2] https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/
- StavrosK 6y ago
  Ah, thanks. I'm not new to embedded, just to Rust on embedded. STM32s are a bit too overpowered for me, I usually use ESP8266s, that's why I thought the NRF might be a good bet (and better supported by Rust).
Avamander 6y ago
I recommend you check out the PineTime project and Lup Yuen Lee's tutorials. It might give a nice starting point. https://github.com/lupyuen/pinetime-rust-mynewt https://github.com/lupyuen/pinetime-rust-mynewt https://medium.com/swlh/sneak-peek-of-pinetime-smart-watch-and-why-its-perfect-for-teaching-iot-81b74161c159 https://medium.com/swlh/sneak-peek-of-pinetime-smart-watch-a...
- StavrosK 6y ago
  That's fantastic, thank you!

rkachowski 6y ago

would this presumably also run on the esp8266?

swsieber 6y ago
Yes, though IIRC a recent release broke esp8266 support accidentally. I haven't checked back to see if it's working again.
rbtying 6y ago
The compiler toolchain can cross compile to esp8266, but I think the pure Rust HAL is less developed there. If you use Rust to write components/code that link against the ESP-IDF, I’d imagine that would work? I have the toolchain in a Docker container if you want to try it out.

ncrmro 6y ago

Was learning a lot of rust and now c and Mabez and everyone else is really helpful on the esp-rs matrix channel.

muska3 6y ago

There's also this guide https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ Although, I'm more interested in learning STM32 development, due to recommendations that it is far superior to ESP32 boards. Anyone have some tips on how to get started on this front as a hobby?

mdtusz 6y ago
I ordered one of the STM32 development boards when this was first published. It's fairly straightforwards to get basic blinky demos working, but it was about at this point that I ran out of steam, and you're basically left to fend for yourself, implementing anything more complex from scratch. It may have changed since, but rust embedded definitely isn't hobbyist friendly unless the goal is to make things work, rather than to just make things.
- muska3 6y ago
  Right, that's ultimately what I am worried about.

jolmg 6y ago

Lol. I was expecting the article to be about how to clean up metal corrosion from the terminals of an ESP32 chip.