The chip you learned on probably is not the one you think
The ESP32 RISC-V story trips up more developers than any other corner of this architecture, because the famous ESP32 in your drawer runs a proprietary Xtensa core, while Espressif’s newer parts have quietly switched to the open RISC-V instruction set. Here is what is RISC-V, what is not, and what the change means for your firmware.
The ESP32 you know is not RISC-V
Say “ESP32” to most people who build connected things and they picture the dual-core board they wired up a Wi-Fi sensor on a few years back. That chip, the original ESP32 from 2016, runs on Tensilica Xtensa cores. So does its predecessor the ESP8266, and so do the later S-series parts, the ESP32-S2 and ESP32-S3. Xtensa is a licensed, proprietary architecture. There is not a byte of RISC-V doing the main work in any of them.
So when the series thesis says RISC-V is taking over embedded, the ESP32 range is not the counter-example it looks like. It is one of the clearest pieces of evidence, because Espressif has spent the last few years moving its new silicon off Xtensa and onto the open ISA. The trick is knowing which parts made the jump.
Where RISC-V actually shows up in the range
The dividing line is the letter after the dash. The C, H and P families are RISC-V. The plain ESP32 and the S-series are Xtensa. The first RISC-V part Espressif shipped was the ESP32-C3, a single-core, cost-optimised chip with Wi-Fi and Bluetooth Low Energy aimed squarely at replacing the ESP8266 and the entry-level ESP32 in high-volume, price-sensitive designs.
From there the RISC-V line has widened fast. The ESP32-C6 pairs a high-performance RISC-V core with a separate low-power RISC-V core and adds Wi-Fi 6, BLE and an 802.15.4 radio, which is what makes it the go-to part for Matter and Thread work. The ESP32-H2 drops Wi-Fi entirely and leans on 802.15.4 and BLE for low-power Thread and Zigbee mesh nodes. At the top sits the ESP32-P4, a dual-core RISC-V application processor with AI instruction extensions and no on-chip radio at all, built for human-machine interfaces, camera work and edge compute where you bolt on a companion radio for the link.
The one thing to take away: if the part number reads ESP32, ESP32-S2 or ESP32-S3, it is Xtensa. If it reads ESP32-C, ESP32-H or ESP32-P, it is RISC-V. Espressif is not converting the old chips, it is building the new ones open.
The range at a glance
| Part | Core | Connectivity | Where it fits |
|---|---|---|---|
| ESP32 (classic) | Xtensa LX6 | Wi-Fi 4, Bluetooth Classic, BLE | Proven legacy designs, Bluetooth Classic |
| ESP32-S3 | Xtensa LX7 (with RISC-V low-power coprocessor) | Wi-Fi 4, BLE 5 | Vector/AI workloads, camera, richer compute |
| ESP32-C3 | RISC-V, single core (first RISC-V part) | Wi-Fi 4, BLE 5 | Low-cost secure IoT, ESP8266 replacement |
| ESP32-C6 | RISC-V, HP core plus LP core | Wi-Fi 6, BLE 5, 802.15.4 | Matter, Thread, next-gen smart home |
| ESP32-H2 | RISC-V | BLE 5, 802.15.4 (no Wi-Fi) | Low-power Thread and Zigbee mesh nodes |
| ESP32-P4 | RISC-V, dual core, AI extensions | None on-chip (pair a radio) | HMI, edge compute, camera pipelines |
The C2, C5 and C61 fill in around the edges of that line, all RISC-V, but the six above are the ones most IoT designs actually land on.
What the ISA switch means for your code
Here is the part that matters and the reason most people never notice the change under the bonnet: the whole ESP32 family, Xtensa and RISC-V alike, runs on the same ESP-IDF framework and is largely code-compatible. Your application logic, the Wi-Fi and BLE stacks, FreeRTOS, the driver model, all of it carries across. The instruction set is an implementation detail that ESP-IDF abstracts away.
In practice, moving a project from an Xtensa part to a RISC-V one is mostly a recompile against a different toolchain, riscv32-esp-elf in place of xtensa-esp32-elf, rather than a firmware rewrite. Where it bites is the low-level corners: hand-written assembly, cycle-counting timing loops, or a dependency that shipped a precompiled Xtensa blob. If your code lives in C against the ESP-IDF APIs, and most of it does, the ISA under it is close to invisible. This is the same reason RISC-V travels so well across the wider embedded world, a point worth reading alongside the RISC-V microcontrollers explainer.
Which one for which job
For a cheap, connected sensor or a smart plug that just needs Wi-Fi and BLE, the ESP32-C3 is the workhorse and undercuts almost everything else on bill of materials. For anything touching the smart home standards, Matter over Thread or Zigbee, the ESP32-C6 or the radio-focused ESP32-H2 are the parts to design around, because the 802.15.4 radio is on the die. If the product has a screen, a camera or any real on-device inference, the ESP32-P4 is the compute-heavy option, though you will need to add connectivity alongside it.
If you are choosing an RTOS to sit on top rather than staying on bare ESP-IDF, the same RISC-V portability argument applies to RISC-V and Zephyr RTOS, which Espressif supports across the range. And for the wider question of how RISC-V fits the whole intelligent-edge shift, the RISC-V and IoT cornerstone sets out the full picture.
Last updated 23 August 2026. Sources: Espressif product pages for the ESP32-C3, C6, H2 and P4 SoCs; ESP32-C3 confirmed as Espressif’s first RISC-V microcontroller (Espressif, 2020). ESP-IDF supports the full ESP32 family across both Xtensa and RISC-V cores.
