// the find
esp-rs/esp-hal
no_std Hardware Abstraction Layers for ESP32 microcontrollers
Official Espressif-backed Rust no_std HAL covering essentially the entire ESP32 chip family (11 chips) including async support via embassy. This is the go-to library if you want to write Rust firmware for ESP32 devices without the esp-idf C runtime underneath you.
- Hardware-in-the-loop (HIL) testing infrastructure is real and actually runs on physical hardware in CI, not just simulation — rare for embedded HALs and meaningful for catching chip-specific bugs.
- Peripheral coverage is broad: DMA, I2S, LCD/CAM, MCPWM, MIPI DSI, ETM, parallel I/O, efuse per chip — not just the usual GPIO/SPI/I2C basics you get from early-stage HALs.
- Versioned migration guides (MIGRATING-1.0.0.md, MIGRATING-1.1.0.md) and a documented support policy with backport rules show this is being treated like a product, not a side project.
- The 'unstable' feature flag tier and the tilde-requirement recommendation in the README is honest API maturity signaling that most embedded crates don't bother with.
- The async story depends on embassy, so you're pulling in the whole embassy executor ecosystem; there's no path to a lighter async runtime if embassy's overhead is too large for your target.
- ADC calibration has separate files for esp32, riscv, xtensa with what looks like a lot of duplication — if your chip's calibration isn't well-tested, you may get silently wrong readings with no obvious error.
- ESP32-P4 and newer chips are visibly less mature; features like ethernet and MIPI DSI exist but the HIL coverage for those peripherals on those chips is almost certainly thinner than for the older ESP32/S3.
- Build complexity is non-trivial: per-chip linker scripts, a custom esp-config system, proc-macros, and feature flags mean the first successful build for a newcomer involves a lot of invisible moving parts that fail with opaque errors.