5 ms·

Rust on Espressif chips

129 points by n8henrie 3y ago

jauntywundrkind 3y ago
Impressive job remaining so fast as the fore, Espressif & friends. The chips have been great & the software keeps improving.
Luker88 3y ago
I hope development continues and gets merged, their Rust support is what made me chose their S3 instead of something else
- abound 3y ago
  Same, I recently picked up a bunch of S2s on the premise of their Rust support. Really just hoping for no_std async I2C at this point.
  - zwirbl 3y ago
    Isn't there a bunch of embassy based async stuff in esp-rs?
    - abound 3y ago
      Good question! As far as I can tell from the docs, it looks like I2C is still synchronous [1], but this will be my first async embedded Rust project, so I'm still unfamiliar with the general shape and functionality of things. For comparison, things like WiFi are definitely async [2] [1] https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.html https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.htm... [2] https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s2/examples/embassy_dhcp.rs https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s...
      - coder543 3y ago
        In esp-hal, they offer both sync and async I2C implementations, depending on what works best for an application. Since the async implementation is gated by a feature, it may not show up in the docs you linked. Async implementation: https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/src/i2c.rs#L317 https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/s... You can also see the async feature mentioned here: https://docs.rs/crate/esp32s2-hal/latest/features https://docs.rs/crate/esp32s2-hal/latest/features There is a very brief example of using async i2c here: https://github.com/esp-rs/esp-hal/blob/main/esp32s3-hal/examples/embassy_i2c.rs https://github.com/esp-rs/esp-hal/blob/main/esp32s3-hal/exam... (you can see that it is using `lis3dh_async`, which requires async i2c) Not specific to the ESP platforms, but Embassy offers a more useful example of async i2c here: https://github.com/embassy-rs/embassy/blob/main/examples/rp/src/bin/i2c_async.rs#L79 https://github.com/embassy-rs/embassy/blob/main/examples/rp/... (and it would work the same on ESP)
      - junon 3y ago
        If there's something missing in Embassy, hop onto the Matrix and chat about it. Dario and company are about as responsive and pleasant to speak to as one could find in the OSS world.
- brianhorakh 3y ago
  The C3 RISC v seems to lead the xtensa architecture.
  - coder543 3y ago
    "Lead" in what way? Is a single-core 160MHz C3 (RISC-V) actually faster than the dual core 240MHz ESP-S3 (Xtensa)? I like the idea of using a more standard architecture, which should have better toolchain support. The C3 “leads” in that aspect. So, I would probably choose the C3 in most cases... but depending on the specific application, the Xtensa cores still seem to have advantages for now.
    - brianhorakh 3y ago
      Fwiw, I use both. I really like both. I said c3 leads was my own experience following this community. As it was explained RISC v has better support because it's open and can be emulated with qemi/llvm/wasm whereas xtensa cannot. Espressif has tried to address this as a licensee, but they don't own xtensa is owned by Tensilica Inc which is owned by cadence. Cadence has not allowed details of the JTAG to be published. Because details of xtensa aren't open source licensed. This makes things such as the openocd debugger, probe rs etc aren't as good, and this situation is unlikely to change. Debuggers are nice. I'm working on the esp32 c3 embassy-rs support this weekend. I personally prefer the RISCv because I think it is easier to emulate and not need to flash a physical device , this means Dev work can move faster with better tests. Just my opinion.
    - brianhorakh 3y ago
      Yeah the C3 is slower than s-series, burns more power. I also miss the twai/can bus support in the C3 series. Long term RISCv might cost less, and I think it will get new features faster. I think it is cheaper to develop for RISCv. RISCv thanks to its outstanding qemu support means it is quickly becoming the reference standard for nascent "brand new" embedded capabilities.
antirez 3y ago
MicroPython offers a great alternative to memory-safe ESP32 programming. It is a battle tested option with a great REPL and many optimization, including the native and Viper code emitters that are quite fast. It has so many available primitives and access to the hardware that if you wish you can write even the drivers for your peripherals directly in Python.
- Kuinox 3y ago
  MicroPython isn't a great choice for these chips, you often want the minimal power consumption since you often run on battery, and MicroPython is extremely slow. https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6 https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6.
  - asyx 3y ago
    The ESP chips are barely power efficient enough to run on battery with C. Like, honestly, I'd not put anything but compiled languages without some sort of runtime on those chips except if I have something like "update an eink display twice a day" use cases.
    - Kuinox 3y ago
      I'm trying to make a natural gas usage live monitoring, I reused a single use e-cig battery (that is rechargeable). From calculation it should last at least a year in deep sleep.
    - jLaForest 3y ago
      >The ESP chips are barely power efficient enough to run on battery with C. Incorrect, Esp32-s3 uses 8 micro amps in deep sleep.
      - doug_life 3y ago
        8uA is still large compared to some other options. I work on medical implants that average 15uA while actively sensing biological signals 24hr/day. This includes the analog front end hardware to condition the signals as well. 8uA of deep sleep current would be a non starter.
robjwells 3y ago
Perhaps worth including the date that was in the original title (29-09-2023), since this is a regular quarterly update.
- n8henrie 3y ago
  I'm 99% sure I included it in the original submission, I think it was edited out.

129 points by n8henrie 3y ago

Impressive job remaining so fast as the fore, Espressif & friends. The chips have been great & the software keeps improving.

Luker88 3y ago

I hope development continues and gets merged, their Rust support is what made me chose their S3 instead of something else

abound 3y ago
Same, I recently picked up a bunch of S2s on the premise of their Rust support. Really just hoping for no_std async I2C at this point.
- zwirbl 3y ago
  Isn't there a bunch of embassy based async stuff in esp-rs?
  - abound 3y ago
    Good question! As far as I can tell from the docs, it looks like I2C is still synchronous [1], but this will be my first async embedded Rust project, so I'm still unfamiliar with the general shape and functionality of things. For comparison, things like WiFi are definitely async [2] [1] https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.html https://docs.rs/esp32s2-hal/latest/esp32s2_hal/i2c/index.htm... [2] https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s2/examples/embassy_dhcp.rs https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s...
    - coder543 3y ago
      In esp-hal, they offer both sync and async I2C implementations, depending on what works best for an application. Since the async implementation is gated by a feature, it may not show up in the docs you linked. Async implementation: https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/src/i2c.rs#L317 https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/s... You can also see the async feature mentioned here: https://docs.rs/crate/esp32s2-hal/latest/features https://docs.rs/crate/esp32s2-hal/latest/features There is a very brief example of using async i2c here: https://github.com/esp-rs/esp-hal/blob/main/esp32s3-hal/examples/embassy_i2c.rs https://github.com/esp-rs/esp-hal/blob/main/esp32s3-hal/exam... (you can see that it is using `lis3dh_async`, which requires async i2c) Not specific to the ESP platforms, but Embassy offers a more useful example of async i2c here: https://github.com/embassy-rs/embassy/blob/main/examples/rp/src/bin/i2c_async.rs#L79 https://github.com/embassy-rs/embassy/blob/main/examples/rp/... (and it would work the same on ESP)
    - junon 3y ago
      If there's something missing in Embassy, hop onto the Matrix and chat about it. Dario and company are about as responsive and pleasant to speak to as one could find in the OSS world.
brianhorakh 3y ago
The C3 RISC v seems to lead the xtensa architecture.
- coder543 3y ago
  "Lead" in what way? Is a single-core 160MHz C3 (RISC-V) actually faster than the dual core 240MHz ESP-S3 (Xtensa)? I like the idea of using a more standard architecture, which should have better toolchain support. The C3 “leads” in that aspect. So, I would probably choose the C3 in most cases... but depending on the specific application, the Xtensa cores still seem to have advantages for now.
  - brianhorakh 3y ago
    Fwiw, I use both. I really like both. I said c3 leads was my own experience following this community. As it was explained RISC v has better support because it's open and can be emulated with qemi/llvm/wasm whereas xtensa cannot. Espressif has tried to address this as a licensee, but they don't own xtensa is owned by Tensilica Inc which is owned by cadence. Cadence has not allowed details of the JTAG to be published. Because details of xtensa aren't open source licensed. This makes things such as the openocd debugger, probe rs etc aren't as good, and this situation is unlikely to change. Debuggers are nice. I'm working on the esp32 c3 embassy-rs support this weekend. I personally prefer the RISCv because I think it is easier to emulate and not need to flash a physical device , this means Dev work can move faster with better tests. Just my opinion.
  - brianhorakh 3y ago
    Yeah the C3 is slower than s-series, burns more power. I also miss the twai/can bus support in the C3 series. Long term RISCv might cost less, and I think it will get new features faster. I think it is cheaper to develop for RISCv. RISCv thanks to its outstanding qemu support means it is quickly becoming the reference standard for nascent "brand new" embedded capabilities.

antirez 3y ago

MicroPython offers a great alternative to memory-safe ESP32 programming. It is a battle tested option with a great REPL and many optimization, including the native and Viper code emitters that are quite fast. It has so many available primitives and access to the hardware that if you wish you can write even the drivers for your peripherals directly in Python.

Kuinox 3y ago
MicroPython isn't a great choice for these chips, you often want the minimal power consumption since you often run on battery, and MicroPython is extremely slow. https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6 https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6.
- asyx 3y ago
  The ESP chips are barely power efficient enough to run on battery with C. Like, honestly, I'd not put anything but compiled languages without some sort of runtime on those chips except if I have something like "update an eink display twice a day" use cases.
  - Kuinox 3y ago
    I'm trying to make a natural gas usage live monitoring, I reused a single use e-cig battery (that is rechargeable). From calculation it should last at least a year in deep sleep.
  - jLaForest 3y ago
    >The ESP chips are barely power efficient enough to run on battery with C. Incorrect, Esp32-s3 uses 8 micro amps in deep sleep.
    - doug_life 3y ago
      8uA is still large compared to some other options. I work on medical implants that average 15uA while actively sensing biological signals 24hr/day. This includes the analog front end hardware to condition the signals as well. 8uA of deep sleep current would be a non starter.

robjwells 3y ago

Perhaps worth including the date that was in the original title (29-09-2023), since this is a regular quarterly update.

n8henrie 3y ago
I'm 99% sure I included it in the original submission, I think it was edited out.