esp-hal VS esp-wifi

In the esp-hal, they appear to 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

Going another level up the chain, we then have the hardware abstraction layer (HAL) crate. HAL crates are supposed to offer more portability and user-friendly API for a particular processor. For ESP devices the different hals are captured in the esp-hal repository. This occurs by implementing some common traits defined in what is referred to as the embedded-hal. Additionally, the device HAL attempts to incorporate mechanisms, or wrappers around lower-level functions, that are part of the Rust safety model.

There is https://docs.rust-embedded.org/book/design-patterns/hal/index.html but I wonder what OP is missing in https://github.com/esp-rs/esp-hal

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

Among these several abstractions, we can program a microcontroller device at any level we like. Additionally, we can develop code with a mix of low-level and high-level abstractions. Obviously, to make code more portable it's better to stick to higher-level abstractions. Also in addition to the above, there exists other crates supporting other functions in no-std development. These include wifi services in the esp-wifi repository, heap allocators in the esp-alloc repository, logging features in the esp-println repository, exception handlers in the esp-backtrace repository, and finally embedded storage traits in the esp-storage repository.

I haven't done much with it yet, but I'm excited about the bare-metal (no_std) rust support for the esp32c3 (as opposed to some other variants that require a custom toolchain as I understand it).

Lots of details at <https://mabez.dev/blog/posts/>, and some examples of wifi on bare-metal at <https://github.com/esp-rs/esp-wifi>.

I hope to eventually get it working with MQTT (there may be examples already, I haven't yet looked in-depth), at which point I think this will be my go-to for the majority of my IOT projects going forward!

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed.

[0]: https://github.com/esp-rs/esp-wifi#current-support

I previously used the esp32-c3 both with bare-metal and with the idf in rust, but I did not like the experience. With the idf you get poor ide support and poor documentation and with bare metal you used to get no wifi at all, but the experience is a lot better. I have seen the new rust wifi driver https://github.com/esp-rs/esp-wifi and i am very interested, but this is still a sync driver afaik.

Also got an ESP32C3 to connect to my wifi network, which was really exciting: https://github.com/esp-rs/esp-wifi

Check the project https://github.com/esp-rs/esp-wifi, it implement bindings to the official SDK.