Skip to main content

ESP-IDF Portfolio for ESP32-Class Devices

AuroraSOC already ships three firmware lines:

  • Zephyr on ESP32-S3 for the BLE-to-MQTT gateway
  • Rust Embassy on nRF52840 for low-level sentinels
  • Ada/SPARK on STM32 for safety-critical control

This portfolio adds a fourth path: ESP-IDF for ESP32-class devices that need rich peripheral support, strong wireless connectivity, and deeper access to the Espressif vendor stack. It now sits alongside a newer Rust Embassy path for ESP32-C3 and selected ESP32-S3 sensor nodes rather than replacing every other ESP option.

Why ESP-IDF still matters here

ESP-IDF remains a strong fit for nodes that benefit from:

  • legacy ESP32 and ESP8266 compatibility
  • ESP32, ESP32-C3, and ESP32-S3 targets with mature vendor support
  • Wi-Fi, PPPoS, TLS, MQTT, OTA, and NVS
  • common hobbyist and industrial peripherals through stable HAL access
  • straightforward integration with AHT21B, VL6180X, MFRC522, LCD1602, buttons, and SIM800L-class modems

A mixed strategy is intentional. Rust Embassy is strongest for new ESP32-C3 sensor sentinels and a good fit for new C3/S3 sensor nodes when the driver surface is modest. ESP-IDF stays valuable where broader board coverage, richer connectivity, or vendor stack depth matters more than a pure no_std design.

Zephyr remains appropriate for the existing ESP32-S3 gateway in the current firmware tree. The new ESP-IDF portfolio is not a replacement for that gateway, and it is not the only recommended ESP path in AuroraSOC. See the companion ESP firmware strategy page for the split.

Initial projects

ProjectBoardPeripheralsAuroraSOC role
esp32c3_aht21b_env_sentinelESP32-C3 Super MiniAHT21B, buttons, LCD1602Secure environmental telemetry and threshold alerts
esp32_doit_v1_proximity_sentinelESP32 DOIT DEVKIT V1VL6180X or TOF050C, buttons, LCD1602Physical proximity monitoring
esp32_doit_v1_rfid_terminalESP32 DOIT DEVKIT V1MFRC522, buttons, LCD1602RFID access workflow terminal
esp32s3_sim800l_outpostESP32-S3SIM800L, optional AHT21B, buttons, LCD1602Remote cellular telemetry node

Shared structure

The new tree lives under firmware/esp-idf/ and starts with:

  • components/aurora_common/ for shared AuroraSOC topic and payload helpers
  • projects/... for standalone ESP-IDF applications per device role

The first shared component formats payloads that match the current backend expectations used by the MQTT consumer:

  • aurora/sensors/{device_id}/status
  • aurora/sensors/{device_id}/telemetry
  • aurora/sensors/{device_id}/alerts
  • aurora/attestation/{device_id}/response

Next milestones

  1. Add secure Wi-Fi and MQTT client components with mTLS.
  2. Add sensor and peripheral drivers for AHT21B, VL6180X, MFRC522, LCD1602, and buttons.
  3. Add PPPoS transport for the SIM800L outpost.
  4. Add attestation, provisioning, and OTA components that align with the rest of AuroraSOC.
  5. Add hardware-in-the-loop validation for the new boards.