This Skill only performs chip capability comparison and selection decisions.High-frequency error points (clear baseline): P4 has no on-chip RF, H2 has no Wi-Fi, S2 has no Bluetooth. Each chip's "minimum IDF version" is UNVERIFIED—this Skill refuses to hardcode it, and only provides the official verification method.
Determine Task Type
- Selection from scratch — Requirements (wireless/compute power/core count/cost) → chip → follow the Workflow.
- Chip replacement evaluation — Migrating an existing project to another ESP32 chip → first rule out hard blockers (RF/core count) using the matrix, then hand over to
esp32-idfto evaluate project migration. - Identify the chip in hand — The user describes the board/module, help confirm the target → cross-check with the physical silkscreen, do not guess based on the description.
- Chip already decided → hand over directly to
esp32-idf(project) or the corresponding specialized Skill.
Preflight (verify at runtime first)
idf.py --version # 本机 IDF 版本
grep -m1 "CONFIG_IDF_TARGET" sdkconfig 2>/dev/null # 已有工程的 target
- Clarify the three key requirements:What wireless capability is needed (Wi-Fi/BLE/802.15.4/none), compute power and core count, cost and package constraints。
- Whether the candidate chip can be supported by the local/target IDF: confirm using the official verification method in selection-tree ,do not rely on memory。
Offline Baseline
- Chip capability facts are based on the dated baseline (official product pages and each chip's get-started page); walk through 2026-09-02, do not auto-update.
- New chips (such as ESP32-C5, ESP32-S31) are mentioned in the v6.1 release notes (medium confidence), capability details are UNVERIFIED—only mention their existence, do not describe details, defer to the official selection page.
Contracts
- Requirements must be confirmed with the user, do not decide wireless capability on the user's behalf based on "common scenarios" (for example, defaulting to BLE).
- RF capability is a hard boundary: what the matrix says it lacks (P4 RF, H2 Wi-Fi, S2 Bluetooth) is simply lacking; "external/companion chip" solutions must be explicitly stated (P4 uses C/S series as a companion chip via ESP-Hosted/ESP-AT).
- Before the selection conclusion is finalized, the chip's package/peripherals/supply must be confirmed by the user according to the official selection page and module datasheets—this Skill does not lock in the model on the user's behalf.
Capability Matrix (baseline high confidence, see chip-matrix for details)
| Chip | Architecture | Wireless |
|---|---|---|
| ESP32 | Dual-core Xtensa LX6 240 MHz | Wi-Fi 2.4G + Bluetooth（Classic+BLE） |
| ESP32-S2 | Single-core Xtensa LX7 240 MHz | Wi-Fi only,no Bluetooth |
| ESP32-S3 | Dual-core Xtensa LX7 240 MHz | Wi-Fi 2.4G + BLE only |
| ESP32-C3 | Single-core RISC-V 160 MHz | Wi-Fi 2.4G + BLE only |
| ESP32-C6 | Single-core RISC-V 160 MHz (+LP core) | Wi-Fi 6 (802.11ax) + BLE 5 + 802.15.4（Thread/Zigbee） |
| ESP32-H2 | Single-core RISC-V 96 MHz | No Wi-Fi; BLE 5 + 802.15.4 (Thread 1.3 / Zigbee certified) |
| ESP32-P4 | Dual-core RISC-V 400 MHz (+LP core) | No on-chip RF; via ESP-Hosted/ESP-AT with a companion chip |
Capability Boundaries + Hand-off
| User Intent | Skill |
|---|---|
| Create a project/migrate the build after selecting the chip | esp32-idf |
| Low-power battery life design (after selecting for battery devices) | esp32-lowpower |
| Thread/Zigbee protocol stack implementation details | Official ESP-IDF documentation (explain when beyond the scope of this package) |
| Secure boot/provisioning/peripherals/concurrency | esp32-secureboot / esp32-wifi-provision / esp32-peripherals / esp32-freertos |
| Rust no_std（esp-hal） | Out of package rust-skills/rust-embedded(refuse and hand over) |
Workflow: Four steps for selection
- List requirements: wireless (including protocol version), compute power, core count, power consumption, cost; confirm each item.
- Hard filtering: eliminate RF dealbreakers per the matrix (e.g., need Thread/Zigbee → only C6/H2 remain; need Wi-Fi + Bluetooth Classic → only classic ESP32).
- Decision tree convergence(see selection-tree.md): single-core low cost → C3; AI vector instructions → S3; Thread/Zigbee → C6/H2; dual-core high performance → S3/P4.
- Runtime verification: perform official support verification for candidate chips (the method in selection-tree.md), confirm the local IDF version is usable, then hand over to
esp32-idfto create the project.
Validation Gates
- The selection conclusion must be traceable to a specific row of the matrix + a specific path of the decision tree, with all three requirement elements matched item by item.
- "This chip requires a minimum of IDF vX.Y"-type conclusionsmust not appear—only the verification method and verification result may be output.
- For claims involving "can actually run": when there is no hardware evidence, mark
Pending HIL。
Pitfalls
- Do nothard-code the minimum IDF version number for each chip—the baseline is explicitly UNVERIFIED, there is no official merged comparison table, only provide the verification method.
- Do notsay "P4 can connect to Wi-Fi by itself"—P4 has no on-chip RF and must be paired with a companion chip (ESP-Hosted/ESP-AT).
- Do nottreat H2 as a Wi-Fi chip or S2 as a Bluetooth chip—baseline high-frequency error points.
- Do notgroup by "similar-sounding names" (C3 and C6 differ greatly in capabilities: 802.11ax and 802.15.4 are only available on C6).
- Do notuse medium-confidence entries (C5/S31) to give conclusions—only indicate "newer chips exist; details are subject to official information".
Official Sources
- Espressif ESP32 product selection (SoC matrix)
- ESP-IDF stable documentation (switch by target)
- ESP-IDF Releases
Privacy
This Skill only performs local requirements analysis and static comparison; it does not collect or send user data externally; accessing official links complies with the user's environment network policy.