Hacker News Reader

Comment by Luker88 | Hacker News Reader

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

View on HN

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.

Isn't there a bunch of embassy based async stuff in esp-rs?

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.htm...

[2] https://github.com/esp-rs/esp-wifi/blob/main/examples-esp32s...

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/s...

You can also see the async feature mentioned here: 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/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/... (and it would work the same on ESP)

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.

The C3 RISC v seems to lead the xtensa architecture.

"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.

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.

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.

Reply on news.ycombinator.com