ESP32 Family Reference: Boards, Benchmarks, Use Cases, and Pitfalls

Reference date: 2026-10-01
Audience: makers, embedded developers, and teams selecting hardware for connected products.
Coverage: original ESP32, S2, S3, C2/ESP8684, C3, C5, C6, C61, H2, and P4.

The shortest useful answer: choose C3 for straightforward, inexpensive Wi-Fi/BLE projects; S3 with PSRAM for USB devices, graphics, audio processing, and small vision models; C6 for Wi-Fi plus Thread/Zigbee; C61 with PSRAM for memory-hungry Wi-Fi 6/BLE applications that do not need Thread; C5 when 5 GHz Wi-Fi is a requirement; H2 for Thread/Zigbee devices without Wi-Fi; and P4 for substantially more demanding multimedia, usually with a companion wireless chip.

This is a selection reference, not a substitute for a board schematic or the exact chip/module datasheet. Benchmarks below are published results, not measurements performed for this document. Newer families and silicon revisions may have different availability and software support.

Contents

• 1. Chip, module, and board are different things
• 2. Quick selection guide
• 3. Hardware comparison
• 4. Family profiles and use cases
• 5. Benchmarks and performance interpretation
• 6. Development-board buying guide
• 7. Software and portability
• 8. Memory, power, and radio architecture
• 9. Bad practices and better alternatives
• 10. Practical tips and troubleshooting
• 11. Pre-purchase and production checklists
• 12. Sources and maintenance

Diagrams are rendered from Mermaid at build time. The adjacent tables and descriptions contain the same selection information.

1. Chip, module, and board are different things

People often say “ESP32 board” when they mean an ESP32 chip family. That ambiguity causes purchasing mistakes.

Naming rules worth knowing:

• S3, C6, and C61 are not interchangeable revisions of one pin-compatible chip.
• WROOM does not universally mean “no PSRAM.” Some S3 and C61 WROOM configurations include PSRAM.
• WROVER is strongly associated with PSRAM-equipped original ESP32 modules, but do not apply that naming rule to every family.
• On an ESP32-S3-WROOM-1-N8R8, the module documentation identifies 8 MB flash and 8 MB PSRAM. Suffix conventions are product-specific; read the ordering table.
• A USB-C connector describes a connector, not a USB peripheral capability.
• A module with radio certifications can simplify compliance, but it does not automatically certify the complete finished product.

Source: Espressif board-selection guide, Arduino board guide, and S3 DevKit ordering information.

2. Quick selection guide

Start with the requirement that cannot be added in software

This diagram gives starting points, not mutually exclusive categories. A project needing several capabilities must satisfy all of them.

S3 vs C6 vs C61 vs C5

C61 is not “C6 with more features.” It trades the C6’s 802.15.4 radio and separately programmable LP CPU for a different Wi-Fi/BLE-oriented design with PSRAM support.

3. Hardware comparison

3.1 CPU and memory

Values are silicon capabilities, not the free heap or the memory fitted to every board. “Main SRAM” follows the vendor’s headline memory figure; cache reservations and other dedicated regions can reduce usable application memory.

Interpretation:

• An LP/ULP coprocessor is not another interchangeable FreeRTOS application core.
• C2/C3 memory figures include cache reservations. Do not treat the entire headline number as available heap.
• PSRAM is larger but has different access latency, cache behavior, and allocation/peripheral restrictions from internal SRAM.
• C6 can access ordinary SPI peripherals, including suitable RAM devices managed explicitly by software, but that is not equivalent to supported memory-mapped PSRAM.
• The C5 datasheet v1.5 lists an LP CPU maximum of 48 MHz; Espressif’s overview table lists 40 MHz. For a design, resolve this against the exact silicon revision and SDK clock configuration rather than relying on the overview.

3.2 Radios and native USB

Bluetooth version labels and certifications change as controllers/stacks evolve. Check support for the specific feature you need: coded PHY, advertising extensions, direction finding, LE Audio, or a particular profile. “Bluetooth 5/6” is not a promise that every optional feature is implemented.

USB terms:

• USB-to-UART bridge: an external chip such as CP210x or CH340; the MCU itself may have no USB controller.
• USB Serial/JTAG: a fixed-function controller for programming, console, and debugging. It does not turn a C3/C6/C61/H2 into an arbitrary USB keyboard, mass-storage device, or audio device.
• USB OTG: a programmable USB controller suitable for supported host/device classes, subject to stack and board support.
• Full-speed: 12 Mbit/s signaling. High-speed: 480 Mbit/s signaling. Neither is guaranteed useful application throughput.
• S3’s native OTG and Serial/JTAG normally share its internal USB PHY. Simultaneous use requires checking PHY ownership and, where applicable, an external PHY design.

3.3 Peripheral differences that frequently block a design

Sources: family datasheets linked in Section 3.1. Peripheral counts, pin mappings, and errata must be checked against the exact part.

4. Family profiles and use cases

4.1 ESP32-S3: compute, DSP, graphics, and programmable USB

Choose it for: USB HID/MIDI or other supported USB classes, LVGL displays, microphone processing, voice interfaces, DVP cameras, and small quantized vision models.

Its two application cores, single-precision FPU, vector instructions, native USB OTG, and PSRAM ecosystem make it a strong default for feature-rich maker projects.

Good starting configuration: an S3 board with a documented 8 MB flash / 8 MB PSRAM variant, such as an N8R8 DevKit configuration. Smaller configurations may be sufficient, but graphics and camera applications benefit from RAM headroom.

Do not choose it assuming: Bluetooth Classic, 5 GHz Wi-Fi, Thread/Zigbee, a built-in DAC, or high-speed USB. It has none of those.

Example: a touchscreen device with microphone input, Wi-Fi provisioning, and USB maintenance. Use queues between acquisition and processing tasks, DMA-capable buffers where required, and PSRAM for larger non-critical buffers.

4.2 ESP32-C6: integrated Wi-Fi and 802.15.4

Choose it for: Matter-over-Thread or Matter-over-Wi-Fi devices, Zigbee experiments, connected controls, and low-power monitoring where the LP CPU can reduce main-core wakeups.

Main advantage: Wi-Fi 6, BLE, and an 802.15.4 radio on one SoC, with more main SRAM than C61 and a separately programmable LP CPU.

Limits: one main application core, no supported memory-mapped PSRAM, no programmable USB OTG, and 2.4 GHz-only Wi-Fi.

Example: a connected environmental sensor whose product variant runs either a Thread stack or a Wi-Fi stack. Validate wake sources, protocol stack memory, and coexistence rather than assuming every radio can be used without contention.

4.3 ESP32-C61: Wi-Fi 6/BLE with expandable RAM

Choose it for: Wi-Fi/BLE connectivity adapters, data loggers, POS-style interfaces, and networked applications that need more buffer space than internal SRAM alone allows.

Main advantage: Wi-Fi 6 plus PSRAM support in a single-main-core device.

Important differences from C6: no 802.15.4 radio, no separately programmable LP CPU, and only 320 KB headline main SRAM. Adding PSRAM does not replace all internal-memory requirements.

The official ESP32-C61-DevKitC-1 documentation describes an ESP32-C61-WROOM-1 configuration with up to 8 MB flash and 2 MB PSRAM. Other C61 silicon configurations exist; PSRAM is not guaranteed merely by the C61 name.

Do not choose it for: a standalone Thread/Zigbee endpoint or an arbitrary USB HID device.

Example: a Wi-Fi sensor hub that batches measurements in PSRAM and exposes a BLE provisioning interface.

4.4 ESP32-C5: dual-band Wi-Fi and a broader connectivity mix

Choose it for: products that must use 5 GHz Wi-Fi, connectivity adapters, gateways, or designs combining Wi-Fi, BLE, and 802.15.4.

Main advantage: 2.4/5 GHz Wi-Fi 6, a 240 MHz main CPU, PSRAM-capable variants, and CAN FD controllers.

Limits: still one main application core, no programmable USB OTG, and more revision-dependent details than older families. Its datasheet explicitly identifies revision restrictions for some peripherals.

Do not assume: simultaneous independent operation on both Wi-Fi bands or router-class Wi-Fi throughput. Dual-band capability is not the same as dual concurrent radios.

Example: a mains-powered control gateway on a 5 GHz network, with an external CAN transceiver and an SDK-supported mesh configuration.

4.5 Other useful families

Battery-device qualification: H2 or C6 is not automatically the “lowest-power board.” Sleep current, wake frequency, protocol role, sensor power, and board electronics determine the result. A Thread router is normally continuously available; a sleepy end device has different requirements.

5. Benchmarks and performance interpretation

5.1 Published CoreMark results

CoreMark measures a small CPU workload. It does not measure Wi-Fi throughput, display refresh, ADC quality, or full application performance.

These are datasheet-reported figures, with the explicitly separate ESP-IDF example below. They are not a controlled cross-family experiment: most datasheet summaries do not disclose a complete toolchain, memory placement, or runtime configuration.

Do not directly compare a two-core score with a one-core score as though both describe a single task. CoreMark/MHz in a dual-core result is also an aggregate figure, not per-core efficiency.

The P4 value is intentionally not multiplied by its maximum clock to manufacture an absolute benchmark result. Its current linked datasheet is preliminary, and the summary does not provide a complete benchmark configuration.

Why different websites give different C3 numbers

Espressif’s CoreMark component example reports 409.249028 at 160 MHz, using GCC 12.2.0, CoreMark code in IRAM, and -O3 -fjump-tables -ftree-switch-conversion.

That is different from the C3 datasheet’s 483.27. Both are published figures from different measurement contexts. The difference is a warning against silently combining benchmark tables from different versions and setups.

5.2 DSP: the instruction set and optimized library matter

Selected ESP-DSP benchmark results, using the published O2 optimized implementation columns. Values are CPU cycles, so lower is better. They are not timings at a common clock.

What this tells you: S3’s optimized vector paths can make a large difference for particular DSP workloads. P4’s higher clock and newer architecture do not make it the fewest-cycle winner for every function.

What it does not tell you: end-to-end audio latency, total energy, or performance of an unoptimized Arduino library. Memory placement, cache configuration, compiler version, and the actual algorithm still need measurement.

5.3 Neural-network inference: published S3 vs P4 examples

Selected ESP-NN model benchmarks from a pinned README revision. These measure model invoke() time, not image capture, preprocessing, drawing, networking, or total camera-to-result latency.

Published conditions include a PSRAM tensor arena; P4 uses 200 MHz HEX PSRAM, while S3 uses 80 MHz octal PSRAM and a 64 KB data cache. Dual-core results explicitly enable the library’s dual-core kernel processing.

Practical conclusion: choose the model, tensor format, optimized kernels, and memory configuration together. The application may spend more time moving pixels than running the model.

5.4 Wireless benchmarks: distinguish PHY rate from useful throughput

No cross-family TCP throughput ranking is invented here. A useful comparison needs the same AP, wired server, firmware settings, band/channel width, RSSI, power-saving mode, and coexistence workload. Test C5’s 2.4 and 5 GHz operation separately.

5.5 Deep-sleep figures are a baseline, not board benchmarks

Selected headline chip deep-sleep figures from the linked datasheets:

These are not a controlled ranking of battery life. Retention settings, temperature, flash/PSRAM configuration, LP execution, and wake circuitry affect the applicable conditions. An LED, USB bridge, regulator, sensor, or voltage-divider path may dominate complete-board sleep current.

5.6 A reproducible benchmark procedure

Use Espressif’s CoreMark example after installing an ESP-IDF release supporting your target:

idf.py create-project-from-example "espressif/coremark:coremark_example"
cd coremark_example
idf.py set-target esp32c6
idf.py menuconfig
idf.py build
idf.py -p /dev/ttyACM0 flash monitor

Replace the target and port with your actual chip and interface. Examples include esp32, esp32s3, esp32c3, esp32c5, esp32c6, esp32c61, esp32h2, and esp32p4.

For a comparison worth keeping:

1. Record the full board/module SKU, silicon revision, flash, PSRAM, and antenna.
2. Pin ESP-IDF, the benchmark component, compiler, and project configuration. Keep the dependency lockfile.
3. Confirm CPU clock, optimization flags, code/data placement, PSRAM mode, and cache configuration.
4. Match participating application cores. Do not count an LP/ULP CPU as another benchmark worker.
5. Separate “radios off” CPU measurements from realistic “radios and application active” measurements.
6. Preserve full output, including validation checks. Repeat runs and report variation, not only the best score.
7. Measure the actual workload too: latency, peak RAM, sustained throughput, dropped samples, and energy per useful operation.

6. Development-board buying guide

6.1 Useful starting points

These are reference examples, not claims that every retailer has the same revision or stock.

The documented P4 Function EV Board includes an ESP32-C6 companion module for Wi-Fi/BLE. That is a board-level feature, not wireless hardware inside P4.

6.2 Do not buy by the thumbnail alone

“DevKit V1,” “SuperMini,” “ESP32 camera,” and similar marketplace names are not reliable hardware specifications. Different sellers can use different modules, regulators, antennas, LEDs, and pin assignments under nearly identical names.

Before buying, obtain:

• A readable module marking and exact SKU, not just “ESP32.”
• The schematic and pinout for the actual board revision.
• Confirmed flash and PSRAM, including the memory bus mode where relevant.
• An explanation of each USB connector: power only, UART bridge, native Serial/JTAG, or OTG.
• Sleep-current measurements and regulator information if battery life matters.
• Antenna type and placement requirements, plus whether an external antenna is included.
• Battery charging/protection information; a connector does not prove either exists.

Price guidance: compare total system cost, not only the bare board price. A cheaper chip may need an external USB controller, more glue logic, another radio, or additional development work. Prices vary too much by supplier, region, and volume to treat a static dollar table as a dependable reference.

7. Software and portability

7.1 Framework selection

The Arduino-ESP32 support table lists stable support for ESP32, S2, S3, C3, C5, C6, H2, and P4. It explicitly notes that C2 and C61 require Arduino as an ESP-IDF component or rebuilding the static libraries. That distinction matters if you expect a normal Boards Manager workflow.

The C61 ESP-IDF getting-started guide has a stable target guide. This does not mean every older ESP-IDF release supports C61.

7.2 Porting traps

Keep board-specific pin definitions and capabilities separate from application logic. Use documented driver APIs instead of hard-coded peripheral registers when portability matters.

8. Memory, power, and radio architecture

8.1 Flash, internal SRAM, and PSRAM are not interchangeable

Example: one 800 by 480 RGB565 framebuffer needs 768,000 bytes, about 750 KiB, before GUI objects, stacks, radio buffers, or other allocations. Double buffering needs about 1.46 MiB just for the pixels.

That is why a seemingly powerful chip can still be the wrong choice for a large GUI without PSRAM or a suitable streaming/buffering strategy.

Memory tips:

• Put large, less latency-sensitive buffers in PSRAM when the target and driver support it.
• Preserve internal memory for stacks, hot data, and allocations with specific DMA/driver requirements.
• Do not assume either that every DMA transfer supports PSRAM or that none do. Capabilities vary by chip, peripheral, and driver.
• Track minimum free heap and largest free block, not only total free memory.
• Budget OTA partitions in flash, not RAM. Two firmware slots, rollback metadata, NVS, and assets need a realistic partition table.
• A 4 MB flash board can work well for a simple app, but may be restrictive for larger firmware plus dual-slot OTA and embedded web assets.

8.2 Battery life: optimize the full cycle

For a periodically reporting Wi-Fi device, the expensive phase is often reconnecting and transmitting, not taking the sensor reading.

Practical priorities:

• Measure at the battery or complete-device supply input, not just the SoC rail.
• Remove or gate unnecessary LEDs, sensors, USB bridges, and high-leakage paths.
• Compare energy per completed report, including connection failures and retries.
• Consider batching, reducing report frequency, or a different network protocol.
• Use light sleep/modem sleep when maintaining connectivity is more appropriate than repeated cold reconnects.
• Select wake-capable pins and retention settings for the exact family.
• Use C6/C5 LP execution or S2/S3 ULP features only after verifying what sensors/peripherals can actually run while the main system sleeps.

8.3 Matter, Thread, Zigbee, and BLE are different layers

Consequences:

• S3/C3/C61 can be candidates for Matter over Wi-Fi without having a Thread radio, subject to SDK/resource support.
• H2 can be a Matter-over-Thread endpoint despite having no Wi-Fi.
• Supporting 802.15.4 does not guarantee a firmware can run Zigbee and Thread simultaneously.
• A Thread border router needs a Thread interface, a backbone interface, and border-router software; it is not merely a Thread-capable chip.
• Multiple wireless protocols can contend for shared RF resources. Read the target’s supported coexistence combinations.

8.4 A common Thread border-router architecture

Espressif’s Thread Border Router SDK uses a host processor plus a separate radio coprocessor in its documented reference architecture.

The official border-router board uses S3 + H2. Supported host/RCP combinations and their exact transport wiring are SDK-specific. A P4-based system still needs an appropriate backbone interface, such as Ethernet or a wireless companion.

9. Bad practices and better alternatives

Original ESP32-specific pin and ADC warnings are not universal pin rules for every ESP32 family. Each target has its own restrictions and errata.

10. Practical tips and troubleshooting

10.1 Hardware bring-up

Espressif’s original ESP32 hardware-design guide recommends a 3.3 V supply capable of at least 500 mA, appropriate local decoupling, and bulk capacitance at the supply entrance. This is a target-specific starting point, not a complete power specification for every ESP32 board or peripheral combination.

Useful habits:

• Test power during Wi-Fi transmission, not only at idle.
• Separate noisy/high-current loads from the MCU supply path as appropriate; route returns carefully.
• Keep a documented BOOT/RESET recovery method and an accessible programming/debug interface.
• Identify USB data-capable cables before blaming firmware.
• Do not connect external power and USB in an unsupported combination; inspect the board’s power-path schematic.
• For antenna validation, test with the real enclosure, cable routing, display, and battery.

10.2 Pin planning before writing drivers

Make a pin-allocation table that reserves:

On original ESP32 modules, GPIO6-11 are normally tied to flash, GPIO34-39 are input-only, and WROVER configurations can reserve additional pins for PSRAM. Never transfer that list blindly to another family.

10.3 Firmware performance

• Use the optimized ESP-DSP/ESP-NN path when your workload matches it; confirm it is actually enabled.
• Measure before pinning tasks to cores. Dual-core hardware does not automatically parallelize a single-threaded algorithm.
• Avoid blocking a high-priority task on slow I/O; use queues, timeouts, and backpressure.
• Size buffers from worst-case producer/consumer timing, not only average rates.
• Profile with logging reduced; serial output can dominate short timing measurements.
• Monitor stack high-water marks, minimum heap, fragmentation, and reset reasons.
• For critical interrupt paths, follow the target’s IRAM/cache-safety rules rather than adding IRAM_ATTR indiscriminately.

10.4 Symptom-to-cause reference

11. Pre-purchase and production checklists

Before buying a board

• List non-negotiable radio, USB, analog, display/camera, and peripheral requirements.
• Confirm the exact chip, module SKU, and board revision.
• Confirm flash/PSRAM capacity and a compatible firmware configuration.
• Check available GPIOs after memory, USB, straps, and onboard peripherals.
• Confirm the chosen SDK/framework release supports the target and required components.
• Check whether Arduino support is standard packaging or a custom component/library build.
• Obtain the schematic, pinout, and programming recovery procedure.
• Verify antenna, voltage, battery/power-path, and connector details.
• Prefer measured complete-board sleep current for a battery project.

Before freezing a production design

• Check the exact part’s NRND/EOL status, availability, longevity commitment, and errata.
• Pin toolchains/components and retain reproducible builds.
• Exercise maximum radio traffic, memory use, peripheral load, and supply transients together.
• Validate final-enclosure RF performance and applicable regulatory requirements.
• Measure minimum/maximum operating conditions relevant to the product.
• Test loss of AP/broker/Thread infrastructure, failed provisioning, and recovery.
• Verify secure provisioning, trust anchors, secret handling, and a deliberate eFuse policy.
• Test OTA interruption, invalid images, rollback, and factory recovery.
• Record application-level benchmark results and full-device energy consumption.
• Keep manufacturing programming, hardware revision, and calibration records.

12. Sources and maintenance

Primary references

Scope note: Espressif’s current portfolio also includes newer/additional names such as S31, H4, H21, and E22. They are not folded into the main tables as if they were established, interchangeable maker-board choices. Check their individual documentation, intended role, SDK support, and actual board availability. In particular, the original ESP32’s Classic Bluetooth distinction here is within the covered mainstream families, not a claim that no other Espressif product can support Classic Bluetooth.

Maintenance rule: when updating this guide, recheck datasheet revisions, silicon errata, board SKUs, framework packaging, and benchmark provenance. Keep published measurements separate from estimates and locally measured results.