HN Debrief

ESP32-S31

  • Hardware
  • Embedded Systems
  • Open Source
  • Developer Tools
  • AI

The ESP32-S31 is Espressif’s new high-end ESP32-family SoC. It combines dual 320 MHz RISC-V cores, Wi-Fi 6 in 2.4 GHz, Bluetooth 5.4 with LE Audio, Ethernet MAC support, CAN-FD, more motor-control friendly peripherals, and SIMD on one high-performance core. In practice, people read it as the long-awaited successor to the original “default” ESP32: a wireless-capable part with more headroom than the C series, without the P4 tradeoff of losing radios.

If you build connected devices, treat the S31 as a serious candidate for the new baseline ESP32 part, especially if you care about Rust, modern toolchains, Ethernet, or local signal processing. Do not assume the marketing around AI or gigabit translates to vision or router-class performance without checking memory, radio, and peripheral limits first.

Discussion mood

Strongly positive. People trust Espressif to deliver a lot of functionality for very little money, and the shift to RISC-V in a higher-end wireless part felt like a meaningful ecosystem upgrade. The few negative notes were about closed radio blobs, confusing naming, and hype around AI, Bluetooth audio, or gigabit use cases outrunning what a microcontroller can really do.

Key insights

  1. 01

    RISC-V helps, blobs still rule radios

    The cleaner toolchain story is real for CPU-side development, especially with official Rust support through esp-hal. It does not remove the hardest vendor dependencies. Wi-Fi and related blocks still rely on closed pieces, so the gain is a better day-to-day developer experience, not full-stack openness.

    Use S31 if your pain is compiler setup, cross-compiling, or language support. Do not choose it expecting Linux-style transparency around the radio stack or long-term portability away from Espressif’s SDK.

      Attribution:
    • jamesmunns #1
    • kelnos #1
    • amelius #1
  2. 02

    Edge AI means tiny models

    The useful AI workloads here are the boring ones that fit on microcontrollers. Wake-word detection, small audio classifiers, and narrow image classification tasks are plausible. Depth Anything and similar vision models are not even close, because activation memory blows past available SRAM and PSRAM long before compute becomes the bottleneck.

    Read Espressif’s AI claims as TinyML and DSP, not general on-device vision. If your product roadmap depends on image transformers or richer perception models, you need a very different class of hardware.

      Attribution:
    • mattalex #1
    • porridgeraisin #1
    • kcb #1
  3. 03

    BitScrambler could be a sleeper feature

    The BitScrambler peripheral stood out because it looks less like a one-off data mangler and more like a programmable state machine attached to DMA. If it turns out to be as flexible as the datasheet language suggests, it could unlock the same kind of protocol and signal hacks that made Raspberry Pi Pico PIO so useful.

    Watch for early experiments with custom buses, LED drivers, sensor interfaces, and video-ish output. If BitScrambler is as capable as advertised, it may matter more in real projects than another small CPU benchmark gain.

      Attribution:
    • utopcell #1
    • redfast00 #1
  4. 04

    Motor-control appeal depends on fast peripherals

    People excited by CAN-FD and the expanded MCPWM blocks immediately drilled into ADC timing and control-loop latency. For field-oriented control and power electronics, fast conversion and low delay matter more than headline clock speed. The S31 looks promising for these workloads, but anyone doing serious motor control still needs to verify the analog path, not just the CPU and PWM specs.

    If you are considering S31 for motors, inverters, or power conversion, benchmark ADC latency and loop timing first. The right digital peripherals help, but they do not rescue a slow measurement chain.

      Attribution:
    • phkahler #1
    • topspin #1 #2
    • PowerElectronix #1
  5. 05

    Gigabit Ethernet is MAC plus external PHY

    The Ethernet support is useful, but it is not integrated wired networking in the way casual readers may imagine. You still need an external PHY and the usual magnetics or board-level design around it. That makes S31 attractive for embedded products that already tolerate a more complex board, not for people hoping to bolt router-class networking onto an ESP module with a jack.

    Budget board space, BOM cost, and signal-integrity work if Ethernet is part of your design. Treat the S31 as a chip with stronger networking options, not as a one-chip Ethernet appliance.

      Attribution:
    • LeifCarrotson #1
    • BenjiWiebe #1
    • alnwlsn #1
  6. 06

    Family letters track product tier, not ISA

    The naming confusion is mostly a mismatch between outsider intuition and MCU vendor practice. Espressif’s S, C, and P labels map to product categories and feature envelopes more than to CPU architecture. That sounds pedantic until you realize it means future parts can switch ISA without forcing a whole ecosystem rename, because most buyers care more about peripherals, radios, SDK support, and price than the instruction set.

    Pick Espressif parts by feature family and software support, not by trying to infer architecture from the letter. If naming clarity matters inside your team, create your own internal shortlist and compatibility matrix rather than relying on the marketing names.

      Attribution:
    • topspin #1 #2
    • peteforde #1

Against the grain

  1. 01

    RISC-V is not automatically better

    The pushback on the RISC-V celebration was that Xtensa was a respectable architecture, and RISC-V has already accumulated a messy sprawl of extensions. For teams writing mostly C against vendor SDKs, the practical benefit may be smaller than enthusiasts claim, while the ISA itself is becoming less elegant over time.

    Do not overvalue the ISA switch if your stack lives above the compiler and SDK. Measure the real gain in tooling, libraries, and maintenance before treating RISC-V as a strategic advantage by itself.

      Attribution:
    • v1ne #1
    • MrBuddyCasino #1
  2. 02

    Bluetooth audio is still the wrong target

    The LE Audio bullet point drew interest, but the practical comments were grim. Existing ESP32-class parts struggle to deliver high-quality low-latency wireless audio, especially for music or instrument use. Bandwidth, codec complexity, stack overhead, and buffering all pile up fast, and Espressif’s patchy classic Bluetooth support makes the family an awkward foundation for serious audio products.

    If your product needs tight audio latency, plan around wired links, Wi-Fi, ESP-NOW, or a different silicon choice. Treat Bluetooth audio on ESP32-class parts as experimental until you have end-to-end measurements on your exact codec and client devices.

      Attribution:
    • AshamedCaptain #1
    • oritron #1
    • timothyb89 #1
    • mrandish #1
  3. 03

    Gigabit support may outrun the CPU

    Some readers questioned whether a dual-core 320 MHz MCU can make meaningful use of a gigabit link once routing, VPNs, or packet-heavy workloads enter the picture. The most credible niche offered was electrically noisy environments where fiber modules are easier to source at gigabit than at 100 megabit. Outside that, the port risks looking better on a comparison chart than in deployed throughput.

    Do not assume the Ethernet spec translates into high packet-processing performance. If your use case involves WireGuard, routing, or line-rate traffic, prototype and benchmark before committing the design.

      Attribution:
    • jon-wood #1
    • KZerda #1 #2

In plain english

ADC ↩
Analog-to-digital converter, the hardware that turns an analog sound signal into digital audio data.
BLE ↩
Bluetooth Low Energy, a wireless protocol used for short-range, low-power communication between devices.
CAN-FD ↩
Controller Area Network Flexible Data-rate, a robust industrial and automotive communication bus with higher data rates than classic CAN.
DMA ↩
Direct Memory Access, a method that lets hardware devices read or write memory without going through the CPU.
esp-hal ↩
The Espressif hardware abstraction layer for Rust, which provides low-level support for ESP chips in Rust projects.
LE Audio ↩
Low Energy Audio, a newer Bluetooth audio standard built on Bluetooth Low Energy and the LC3 codec.
MAC ↩
Mandatory Access Control, a security model where system policy centrally restricts what programs can access regardless of user discretion.
MCPWM ↩
Motor Control Pulse Width Modulation, a peripheral designed to generate precise switching signals for motors and power electronics.
PHY ↩
Physical layer chip or interface that handles the electrical signaling for a communications link.
PIO ↩
Programmable Input Output, a Raspberry Pi Pico feature that lets software define custom low-level hardware signaling.
PSRAM ↩
Pseudo-static RAM, an external memory type often used to give microcontrollers more working memory than on-chip SRAM alone.
RISC-V ↩
An open instruction set architecture used to build processors, often discussed as an alternative to Arm and x86.
Rust ↩
A systems programming language designed to provide strong memory safety guarantees through compile-time checks.
SDK ↩
Software Development Kit, a package of libraries, tools, and documentation for building on top of a platform.
SIMD ↩
Single Instruction, Multiple Data, a computing approach where one instruction processes many data elements at once.
SoC ↩
System on a chip, a compact integrated processor and supporting components used in electronic devices.
SRAM ↩
Static Random-Access Memory, a faster but much less space-efficient type of memory often built directly onto processors for caches.
Xtensa ↩
A configurable CPU architecture from Cadence that Espressif used in earlier ESP32 chips.

Reference links

Rust and embedded development

Chip documentation and comparisons

Signal processing and hardware capabilities

Audio and communications projects

  • walkie-talkie over ESP-NOW
    Shared as a work-in-progress example of sending audio between ESP devices over ESP-NOW
  • micro-wake-word
    Provided as a concrete example of the kind of small audio ML workload that fits on a microcontroller

LED and maker ecosystem

  • WLED knowledge base
    Referenced as the home page for the open source ESP-based LED control ecosystem discussed in the comments
  • WLEDMMP4 with native HDMI output
    Shared as an example of ESP32-P4 DSP and image-handling work that may preview what S31 can enable
  • Martin Atomic 3000 LED
    Used as a reference point in a discussion of very high-intensity LED applications that need different controller hardware than WS2812 strips

Hardware availability and manufacturing