Skip to main content

ESP Firmware Strategy for AuroraSOC

AuroraSOC does not need one ESP framework for every board. The current recommendation is mixed by device role and integration surface.

Decision Summary

  • Rust Embassy is strongest today for new ESP32-C3 sensor sentinels.
  • Rust Embassy is also a good fit for new ESP32-S3 sensor nodes when the driver surface stays modest and AuroraSOC benefits from a thin no_std application layer.
  • ESP-IDF still makes sense for legacy ESP32 or ESP8266 boards, cellular-heavy nodes, and cases that lean on Espressif's mature Wi-Fi, TLS, OTA, PPPoS, NVS, and peripheral support.
  • Zephyr stays in place for the existing ESP32-S3 BLE gateway because that role is already established in the current firmware tree.

Where Embassy Is The Best Choice

Embassy is the preferred path when AuroraSOC wants:

  • memory-safe no_std firmware
  • async concurrency without threads or heap pressure
  • host-testable application logic before board bring-up
  • small sensor or sentinel nodes where the board layer should stay thin

The new firmware/embassy-esp/ workspace starts with an ESP32-C3 AHT21B environmental sentinel foundation:

firmware/embassy-esp/
crates/
aurora-firmware-contracts/
aht21b-env-logic/
aht21b-protocol/
projects/
esp32c3_aht21b_env_sentinel/

That split keeps AuroraSOC topic and payload contracts, threshold evaluation, protocol decoding, and the new embedded-hal-async AHT21B transport testable on the host while leaving the board-specific Embassy HAL bring-up, Wi-Fi, and MQTT transport as the next hardware-facing layer.

Where ESP-IDF Still Fits

ESP-IDF remains a pragmatic choice when AuroraSOC needs:

  • legacy ESP32 or ESP8266 compatibility
  • broader vendor networking features
  • quicker access to mature modem, UI, or peripheral integrations
  • projects where vendor stack coverage matters more than a pure no_std design

See the companion ESP-IDF portfolio page for the boards and roles that still fit that path well.

Current AuroraSOC Split

RolePreferred stackWhy
New ESP32-C3 environmental sentinelRust EmbassyBest match for a small async no_std sensor node
New ESP32-S3 sensor nodeRust Embassy when driver needs are modestStrong fit for new C3/S3 sensor sentinels
Existing ESP32-S3 gatewayZephyrAlready owns the deployed gateway role
Legacy ESP32 or ESP8266 nodeESP-IDFBetter vendor support and compatibility
Cellular-heavy ESP32-S3 outpostESP-IDFPPPoS and broader connectivity support remain compelling