4 ms·

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.

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.