Espressif's ESP32-C5 Is Now in Mass Production

Original Article ↗ Hacker News Discussion ↗

Shift to RISC‑V and core trade‑offs

  • ESP32-C5 continues Espressif’s move from Xtensa to RISC‑V; S3 is widely seen as the last Xtensa-based chip from them.
  • Benefits noted: better upstream compiler support (especially for Rust/LLVM) and no ISA royalties.
  • Downsides discussed: shorter pipelines than older Xtensa cores make flash cache misses more painful; lack of ALU carry bit hurts 64‑bit integer performance vs Cortex‑M.
  • Impact is project‑dependent: mostly‑idle Wi‑Fi/IO devices don’t care, but timing‑sensitive or DSP‑heavy work might.

Wireless features and product confusion

  • Users welcome integrated 802.15.4 (Zigbee/Thread), but several complain Espressif’s lineup is hard to track.
  • Official comparison tools and a portfolio PDF are shared; some doubt details (e.g., whether C5 really has CAN‑FD, Zigbee support accuracy).
  • Clarification: any 802.15.4 radio can carry Zigbee frames; the real issue is full stack/software support.
  • For LoRa, commenters say ESP32 is overkill if you don’t need Wi‑Fi; cheaper MCUs or LoRa‑focused modules (STM32WLE5, SX1262, LoRa‑E5) may be better.

5 GHz vs 2.4 GHz Wi‑Fi

  • Some question why 5 GHz matters for IoT given lower 2.4 GHz range.
  • Others argue 2.4 GHz is saturated (especially in apartments); 5 GHz’s wider, less-crowded spectrum improves reliability even for low‑bandwidth IoT.
  • In dense multi‑AP or mesh environments, operators often reduce 2.4 GHz power and prefer dual‑5 GHz setups; 2.4‑only IoT forces legacy support.

Tooling and build system issues

  • ESP‑IDF’s move to CMake is controversial; some dislike CMake generally, others note it should ease BSD support.
  • Complaint: current IDF embeds unnecessary Linux‑specific assumptions, making BSD support painful, independent of CMake itself.

Power consumption and hardware behavior

  • Multiple comments note ESP32s draw very high peak current (up to ~600 mA at 3.3 V on wake/Wi‑Fi), requiring substantial local capacitance (e.g., ≥220 µF) to avoid brownouts.
  • Deep sleep current is very low, allowing multi‑year CR2032 lifetimes if radio use is infrequent, but Wi‑Fi is still considered unsuited to many primary‑battery, low‑duty applications versus nRF‑class radios.

Pricing, tariffs, and availability

  • Dev board pricing varies: $15–$35+ after shipping/taxes in the US, ~€4–€8 for some C6/C‑series alternatives elsewhere.
  • Concern over tariffs and shipping costs vs direct‑from‑China buying; microcontrollers themselves are noted as tariff‑exempt under current rules.
  • Modules (WROOM‑style) and high‑volume pricing are not yet clearly available; some report Espressif is still limiting quantities.

USB HID, memory, and misc. technical points

  • Developers want better USB host HID support for non‑boot‑protocol devices (e.g., complex game controllers), which the hardware could support but ESP‑IDF currently doesn’t.
  • Devkit info: ~384 KB RAM, ~320 KB ROM, typically 8 MB flash plus optional PSRAM.
  • Some interest in CAN/TWAI and FPU presence; preliminary docs suggest dual CAN, FPU is unclear; lack of multi‑core RISC‑V from Espressif is noted.

Security, lock‑down, and e‑waste

  • A long subthread debates secure boot and the ability to permanently lock flashing.
  • One side criticizes this as anti‑repair and e‑waste‑generating, especially for smart‑home devices that might otherwise be reflashed with ESPHome or similar.
  • The other side cites security/liability, anti‑cloning, and regulatory pressure (EU RED/CRA) pushing toward hardware‑enforced secure update mechanisms.
  • There is concern that regulations intended to enforce updates may, in practice, incentivize locking devices and reducing user control.