// the find
esp-rs/esp-idf-svc
Type-Safe Rust Wrappers for various ESP-IDF services (WiFi, Network, Httpd, Logging, etc.)
Safe Rust wrappers over the ESP-IDF C SDK for ESP32 family chips — WiFi, BLE, MQTT, HTTP, OTA, NVS, the works. Targets developers who want std Rust on ESP32 rather than the bare-metal no_std path that esp-hal takes. If you want to write an ESP32 app that feels like writing a normal Rust network service, this is the entry point.
1. Coverage is genuinely broad: Bluetooth Classic + BLE (including GATT client/server and SPP), Thread/OpenThread, multiple filesystems (FAT, LittleFS, SPIFFS), and OTA are all there — not just the easy WiFi+HTTP path. 2. Both blocking and async APIs are provided for most services, so you're not forced into one concurrency model. 3. Implements embedded-svc traits, which means code written against this can theoretically target other HALs — the abstraction is real, not just cosmetic. 4. The example set is unusually complete: BLE GAP scanner, GATT server, async WebSocket, WPS, static IP, DHCP with hostname — most edge cases you'd hit in a real project have an example.
1. Community-maintained, not Espressif-paid — the README says this plainly. That means it will lag behind new ESP-IDF releases, and there's no HIL (hardware-in-the-loop) testing, so regressions on real chips can slip through. 2. The `std` dependency on ESP-IDF means your binary is substantially heavier than the no_std esp-hal path; not a dealbreaker but it is a meaningful flash/RAM cost on lower-end variants like ESP32-C2. 3. Documentation is thin — the README says so itself. You'll be reading source and examples more than docs, which is workable but annoying when the ESP-IDF C API you're wrapping has surprising behavior. 4. BLE and Bluetooth Classic features are gated behind feature flags and require the right ESP-IDF version; the interaction between Cargo features and ESP-IDF SDK version is not well documented and can produce confusing build failures.