Set up ESP-IDF
Use this path when you are building firmware that runs on real ESP32 silicon. The SDK is consumed as an ordinary ESP-IDF component, so there is no separate SDK install step — you install ESP-IDF, then point your project at the esp_rmaker_neo component.
If you want to iterate on device logic without hardware, use the POSIX setup instead. Both platforms share the same source tree and the same API.
1. Install ESP-IDF
Follow the official ESP-IDF get-started guide for your host OS: install the prerequisites, clone ESP-IDF at a supported release, run the install script, then source the export script in every shell you build from:
. $IDF_PATH/export.sh
Supported ESP-IDF releases
ESP-IDF v6.0.2 or later. Check out release/v6.0 or a later release branch before you build. Earlier release branches are not supported — v5.5 is still built in CI, but for compile coverage only.
Supported targets
esp32, esp32c2, esp32c3, esp32c5, esp32c6, esp32s3.
Run idf.py set-target <chip> once per project. If you never call it, the build defaults to esp32.
The example partition tables assume 4 MB of flash (two 1920 KB app slots plus NVS and a factory partition). On a 2 MB part you must shrink the app slots or drop the second OTA slot — see Factory NVS.
2. Get the SDK
Clone the firmware SDK repository somewhere alongside your project:
git clone <esp-rainmaker-neo-firmware-repo-url> esp-rainmaker-neo-firmware
Nothing further is needed. There is no install.sh, no submodule fetch, and no Python environment for ESP-IDF builds — third-party dependencies are vendored or pulled by the IDF component manager. (The Python virtual environment in the POSIX setup is only for POSIX builds, and the one in Tools reference is only for the manufacturing and OTA scripts.)
3. Build an example
The in-tree examples are complete ESP-IDF projects. Start with light:
cd esp-rainmaker-neo-firmware/examples/light
idf.py set-target esp32c3
idf.py build flash monitor
The node boots, starts its serial console, and waits for provisioning. It gets its cloud credentials during that provisioning session via assisted claiming, which is enabled by default — so there is nothing to flash first, but you do need a phone app that supports claiming. If you have opted out with CONFIG_ESP_RMAKER_ASSISTED_CLAIM=n, flash a factory NVS image instead.
Continue at Configure and build for the full menuconfig / sdkconfig.defaults story.
4. Add the SDK to your own project
Examples declare the SDK through the component manager. main/idf_component.yml uses path dependencies so no registry lookup happens:
dependencies:
# Neo SDK
esp_rmaker_neo:
path: ../../../components/esp_rmaker_neo
esp_rmaker_neo_ota:
path: ../../../components/esp_rmaker_neo_ota
# Common example components
app_event_loop:
path: ../../common/app_event_loop
app_entry:
path: ../../common/app_entry
app_network:
path: ../../common/app_network
app_led:
path: ../../common/app_led
app_button:
path: ../../common/app_button
Then require the components you use in main/CMakeLists.txt:
idf_component_register(
SRCS "app_main.c" "app_driver.c"
PRIV_REQUIRES esp_rmaker_neo esp_rmaker_neo_ota app_network app_event_loop app_entry esp_wifi
)
Two things to know:
esp_rmaker_neois the only mandatory component.esp_rmaker_neo_otais optional — leave it out and no OTA code is linked in.esp_rmaker_neo_commonand theosalplatform layer come in transitively.EXTRA_COMPONENT_DIRSalso works if you would rather not use the component manager. Point it at the SDK'scomponents/directory andREQUIRES/PRIV_REQUIRESthe components by name.
The app_* components under examples/common/ are example scaffolding, not part of the SDK. They are convenient to start from — app_network in particular collapses the four-call provisioning sequence into one function — but you are free to drop them and drive the SDK directly. See Start your own project.
Next steps
- Configure and build
- Assisted claiming — how the node gets its credentials by default
- Factory NVS — the pre-flashing alternative
- Code basics — what
app_main.cactually does - Troubleshooting