// the find
esp-rs/esp-idf
embedded-hal implementation for Rust on ESP32 and ESP-IDF
A monorepo bundling three Rust crates — esp-idf-sys (raw bindings + build), esp-idf-hal (embedded-hal drivers), and esp-idf-svc (embedded-svc services like WiFi, BLE, MQTT, HTTP, OTA) — that let you write std Rust on top of Espressif's ESP-IDF/FreeRTOS stack. Aimed at people who want the full ESP-IDF ecosystem (networking, threads, filesystems) rather than a bare-metal no_std HAL.
Merged three previously separate repos into one workspace but kept git history intact (git log --follow for esp-idf-hal, path-rewritten history for sys/svc) instead of squashing and losing blame. Service coverage is wide for a community project: BLE GATT client/server, classic BT (A2DP/AVRCP/HFP/SPP), Thread (including SRP and border router/RCP), MQTT, HTTP client/server with websockets, OTA, mDNS, NVS, and three filesystem backends. Running on ESP-IDF means you get FreeRTOS threads and a real TCP/IP stack for free, which bare-metal no_std HALs don't give you. ~60 runnable examples in examples/src/bin cover most peripherals and services directly via cargo espflash.
The README states plainly that Espressif puts little to no paid developer time into these crates, so they can lag the latest ESP-IDF release, have no HIL tests, and documentation is thin — that's an honest but real liability for production use. No hardware-in-loop testing means peripheral edge cases (GPIO, RMT, timers) are effectively validated by users hitting bugs in the field, not CI. The esp-idf-sys build pulls in ESP-IDF's own CMake/C toolchain, so build times and toolchain fragility are much higher than a pure no_std esp-hal project, and crate-version-to-ESP-IDF-version pinning is a recurring source of build breakage. If you want async or no_std, this is the wrong pick — Espressif's officially supported esp-hal covers that, while this repo commits you to ESP-IDF's startup, panic handling, and threading model instead.