8 ms·

I was looking forward to trying Rust on my ESP32 projects but always had a hard time. All the tooling is too complicated. There is flasher coded in python, IDF

by po1nt 5y ago

I was looking forward to trying Rust on my ESP32 projects but always had a hard time. All the tooling is too complicated. There is flasher coded in python, IDF coded in C, you need to run MinWin on Windows which makes it even harder. You can't run all of this in docker because docker for windows doesn't allow mapping COM ports into container and stuff. Everything about just compiling a code seems so tiresome and unstable in comparison with STM or Atmel environment. Yet still I love ESP32 even though I gave up trying to code it in Rust. Even C++ was not working well and had to make several pull requests to add `extern "C"`s into IDF codebase for my code to work. I'm looking forward to improvements on the Rust environment. Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack?

tlamponi 5y ago
I did not liked the old ESP flasher tool much either. FYI: There's already an official rust based rewrite of it: https://github.com/esp-rs/espflash https://github.com/esp-rs/espflash
tlamponi 5y ago
> Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack? I mean, the new one's are already risc-v based and they added tier-3 compiler support for those in rust recently (1.56 IIRC), not sure if they still plan to release xtensa based ones in the future.
- po1nt 5y ago
  Yes but they didn't yet release dual-core RISC-V based or did I miss it? I use it's dual-core capabilities extensively as I heavily utilize WiFi and still have to maintain low-latency processing of IO input. Didn't look much into RISC-V ESP but does it have some interrupts without multiplexor?
  - tlamponi 5y ago
    Yes, esp32-c3 [0] can be bought already, e.g., from mouser [1] or sparkfun [2] either as dev kit or as native module for a self-designed PCB. [0]: https://www.espressif.com/en/products/socs/esp32-c3 https://www.espressif.com/en/products/socs/esp32-c3 [1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02-wifi-ble-module/ https://www.mouser.de/new/espressif/espressif-esp32c3wroom02... [2]: https://www.sparkfun.com/products/18034 https://www.sparkfun.com/products/18034
    - kingosticks 5y ago
      They asked for dual core. The C3 is single core. > ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz https://www.espressif.com/en/news/ESP32_C3 https://www.espressif.com/en/news/ESP32_C3
      - tlamponi 5y ago
        And ESP's rust support provides threads and async supprot nonetheless. With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.
        bri3d 5y ago
        The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations. This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.
        tlamponi 5y ago
        They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.
qbasic_forever 5y ago
If you're up for it there's a lot of fiddly work you can do to make your windows serial device exposed with a RFC2217 network server and then mapped as a serial device inside your container. Can see the basic idea here: https://gist.github.com/DraTeots/e0c669608466470baa6c https://gist.github.com/DraTeots/e0c669608466470baa6c You'd want to use hub4com to go serial device -> network server on windows and then socat or ser2net inside the container to go network server -> serial device. I agree though it is entirely too complicated and much more of a pain than it should be in practice.
tinco 5y ago
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bleeding edge software development tools will never be as good on Windows as they are on Linux or MacOS, just because bleeding edge open source software developers generally do not use Windows.
- the__alchemist 5y ago
  I've found the Rust embedded tooling is equivalent on Windows and Linux. Ie the same tools and programs work, and in (almost) the same way. More broadly, Windows is more popular for embedded. My anecdote here is limited to Cortex-M.
- outside1234 5y ago
  I'm not sure of the situation with ESP but in many embedded environments you HAVE TO use Windows for development.
  - coupdejarnac 5y ago
    I do ESP and ARM (NRF52) dev on Linux with no issues. I haven't had a chance to try the Paduak tools under Wine yet.
  - mlindner 5y ago
    That's only true if you're using the officially supported toolchain. Rust is not that, so there's no point in using Windows.
  - MarkMarine 5y ago
    Not the situation for ESP, but the C++ pain is real. Once that is sorted, it works great on mac.
  - ahepp 5y ago
pfes 5y ago
I had an easy time getting setup with the esp32c3 with this repository (linked to in author's first post): https://github.com/ivmarkov/rust-esp32-std-demo https://github.com/ivmarkov/rust-esp32-std-demo Also got it working on WSL2. I could install flashing and monitoring tools as Windows binaries, which have access to Windows ports. https://pfesenmeier.github.io/wsl2-and-embedded-development/ https://pfesenmeier.github.io/wsl2-and-embedded-development/
- dljsjr 5y ago
  That's because the c3 is a RISC-V chip and so doesn't require all of the annoying tooling that parent comment is referring to. The rest of Espressif's product line, including the extremely popular original ESP32 and the older 8266, use different chip architecture (xtensa) that requires a more annoying setup.
  - pfes 5y ago
    It was easy because of ivmarkov's tooling (see linked repo in previous comment). The "flasher coded in python, IDF coded in C" is installable through cargo. I did not have to install "MinWin". Docker does not having access to ports, but WSL2 does have access to the computers ports (through cross-compiling build tools). Not having to install custom Rust toolchain for Xtensa chips was nice, too.
    - dljsjr 5y ago
      I stand corrected, that's a useful template project. Thanks for linking!
conk 5y ago
It takes at most an hour to setup the tooling on windows. My first intro into embedded development was setting up the esp32 IDF. While there may be simpler platforms out there, it’s not overly complex for anyone doing embedded development.

by po1nt 5y ago

tlamponi 5y ago

I did not liked the old ESP flasher tool much either. FYI: There's already an official rust based rewrite of it: https://github.com/esp-rs/espflash https://github.com/esp-rs/espflash

tlamponi 5y ago

> Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack? I mean, the new one's are already risc-v based and they added tier-3 compiler support for those in rust recently (1.56 IIRC), not sure if they still plan to release xtensa based ones in the future.

po1nt 5y ago
Yes but they didn't yet release dual-core RISC-V based or did I miss it? I use it's dual-core capabilities extensively as I heavily utilize WiFi and still have to maintain low-latency processing of IO input. Didn't look much into RISC-V ESP but does it have some interrupts without multiplexor?
- tlamponi 5y ago
  Yes, esp32-c3 [0] can be bought already, e.g., from mouser [1] or sparkfun [2] either as dev kit or as native module for a self-designed PCB. [0]: https://www.espressif.com/en/products/socs/esp32-c3 https://www.espressif.com/en/products/socs/esp32-c3 [1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02-wifi-ble-module/ https://www.mouser.de/new/espressif/espressif-esp32c3wroom02... [2]: https://www.sparkfun.com/products/18034 https://www.sparkfun.com/products/18034
  - kingosticks 5y ago
    They asked for dual core. The C3 is single core. > ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz https://www.espressif.com/en/news/ESP32_C3 https://www.espressif.com/en/news/ESP32_C3
    - tlamponi 5y ago
      And ESP's rust support provides threads and async supprot nonetheless. With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.
      - bri3d 5y ago
        The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations. This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.
        tlamponi 5y ago
        They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.

qbasic_forever 5y ago

If you're up for it there's a lot of fiddly work you can do to make your windows serial device exposed with a RFC2217 network server and then mapped as a serial device inside your container. Can see the basic idea here: https://gist.github.com/DraTeots/e0c669608466470baa6c https://gist.github.com/DraTeots/e0c669608466470baa6c You'd want to use hub4com to go serial device -> network server on windows and then socat or ser2net inside the container to go network server -> serial device. I agree though it is entirely too complicated and much more of a pain than it should be in practice.

tinco 5y ago

Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bleeding edge software development tools will never be as good on Windows as they are on Linux or MacOS, just because bleeding edge open source software developers generally do not use Windows.

the__alchemist 5y ago
I've found the Rust embedded tooling is equivalent on Windows and Linux. Ie the same tools and programs work, and in (almost) the same way. More broadly, Windows is more popular for embedded. My anecdote here is limited to Cortex-M.
outside1234 5y ago
I'm not sure of the situation with ESP but in many embedded environments you HAVE TO use Windows for development.
- coupdejarnac 5y ago
  I do ESP and ARM (NRF52) dev on Linux with no issues. I haven't had a chance to try the Paduak tools under Wine yet.
- mlindner 5y ago
  That's only true if you're using the officially supported toolchain. Rust is not that, so there's no point in using Windows.
- MarkMarine 5y ago
  Not the situation for ESP, but the C++ pain is real. Once that is sorted, it works great on mac.
- ahepp 5y ago

pfes 5y ago

I had an easy time getting setup with the esp32c3 with this repository (linked to in author's first post): https://github.com/ivmarkov/rust-esp32-std-demo https://github.com/ivmarkov/rust-esp32-std-demo Also got it working on WSL2. I could install flashing and monitoring tools as Windows binaries, which have access to Windows ports. https://pfesenmeier.github.io/wsl2-and-embedded-development/ https://pfesenmeier.github.io/wsl2-and-embedded-development/

dljsjr 5y ago
That's because the c3 is a RISC-V chip and so doesn't require all of the annoying tooling that parent comment is referring to. The rest of Espressif's product line, including the extremely popular original ESP32 and the older 8266, use different chip architecture (xtensa) that requires a more annoying setup.
- pfes 5y ago
  It was easy because of ivmarkov's tooling (see linked repo in previous comment). The "flasher coded in python, IDF coded in C" is installable through cargo. I did not have to install "MinWin". Docker does not having access to ports, but WSL2 does have access to the computers ports (through cross-compiling build tools). Not having to install custom Rust toolchain for Xtensa chips was nice, too.
  - dljsjr 5y ago
    I stand corrected, that's a useful template project. Thanks for linking!

conk 5y ago

It takes at most an hour to setup the tooling on windows. My first intro into embedded development was setting up the esp32 IDF. While there may be simpler platforms out there, it’s not overly complex for anyone doing embedded development.