esp-hal VS esp-pacs

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

The no-std ecosystem follows the same layering approach that exists within embedded Rust. In embedded Rust, there are several levels of abstraction that are introduced on top of microcontroller hardware as shown in the figure below. The first level is the peripheral access crate (PAC) which gives us access to low-level microcontroller registers at the bit level. It's also worth noting that the PAC is specific to a particular microcontroller series. For ESP devices the different PACs are captured in the esp-pacs repository. The microarchitecture crate is at a similar abstraction level to the PAC but specific to processor core (Ex. RISC-V) functions.