Espressif announced the ESP32-S31, a new ESP32 family SoC that combines dual high-performance RISC-V cores at 320 MHz with Wi‑Fi 6, Bluetooth 5.4 LE Audio, gigabit Ethernet MAC, more GPIO, CAN-FD, multiple motor-control PWM blocks, crypto accelerators, and a new programmable BitScrambler peripheral. It sits between the older wireless ESP32 parts and the newer ESP32-P4, which has stronger multimedia and MIPI support but no radio. That made many people read it as the first real successor to the original "do-everything" ESP32. The big shift is not raw speed alone. It is that Espressif is moving its higher-end line onto RISC-V while keeping the same SDK and ecosystem that made ESP32 attractive in the first place.
For teams that build connected devices, the S31 strengthens ESP32 as a cheap, standardized embedded platform that can cover more products without moving up to Linux, but it does not solve the usual closed-radio and memory-limit tradeoffs.
Strongly positive. People see the S31 as a high-value, high-capability new default for connected embedded work, with excitement around RISC-V, Rust, motor-control features, and the overall Espressif ecosystem. The main reservations were familiar ones: confusing naming, closed radio blobs, limited memory for anything marketed as AI, and some missing features compared with the P4.
01 RISC-V only partly solves the embedded tooling mess.
The CPU target is easier and more standard, but Wi‑Fi and other complex peripherals still pull in closed pieces. What changes the picture here is that Espressif has put official weight behind Rust support through esp-rs and esp-hal, with dedicated engineers maintaining it. That makes S31 more than a chip spec upgrade. It makes the platform more credible for teams that want a modern language without living on community reverse engineering.
The win is not "RISC-V means fully open." The win is "standard CPU tooling plus official vendor support is finally good enough to build on."
02 The fast ADC and PWM discussion exposed why S31’s motor-control peripherals matter.
In field-oriented control and switching power applications, latency in sensing, conversion, and compute directly eats phase margin and caps stable loop bandwidth. That is why engineers care about microsecond-scale timing and dedicated PWM hardware. The appeal of this chip is not hobby robots. It is that work once reserved for dedicated motor-control ICs, FPGAs, or pricier industrial MCUs is moving into a cheap general-purpose wireless part.
Good motor-control silicon is about control-loop timing, not checkbox peripherals. S31 looks interesting because it gets closer to real control applications, not because it can blink a motor.
03 Espressif’s edge AI pitch should be read as TinyML, not general ML.
Small quantized convolutional neural networks for wake words, simple audio tasks, and low-resolution image classification fit the box. Larger vision models do not, because activation memory blows past available SRAM and even PSRAM becomes a bottleneck. The useful mental model is "micro-wake-word" and tiny classifiers, not on-device camera magic.
If you hear "AI" here, think wake words and tiny classifiers. Do not think modern vision models.
04 The gigabit Ethernet feature is less about turning an ESP32 into a fast network appliance than about connectivity options.
You still need an external PHY and magnetics, and the MCU will not push line-rate encrypted traffic. But gigabit-class Ethernet interfaces make fiber and electrically noisy industrial links easier to reach, which is a more realistic use case than homebrew routers.
Gigabit on this class of MCU is a systems integration feature, not a throughput promise.
05 Espressif’s naming makes more sense if you stop treating the letter as an instruction-set marker.
The S, C, and P labels are product categories tied to performance and feature mix, not Xtensa versus RISC-V. S31 matters because it breaks the accidental shorthand many users had adopted and confirms that Espressif wants one software ecosystem spanning different CPU architectures under the same family umbrella.
The messy naming is deliberate platform thinking. Espressif wants users to buy into ESP32 as an ecosystem, not into any one ISA.
01 RISC-V is not an unambiguous upgrade.
One commenter argued Xtensa was cleaner and more pleasant at the assembly level, while RISC-V is already accumulating the kind of extension sprawl that usually appears only after decades. If that continues, the openness story could be undermined by fragmentation and half-baked optional features.
An open ISA can still become messy. Standardization helps only if the extensions stay coherent.
02 ARM is not the main villain in embedded lock-in.
The ugliness people blame on ARM often comes from SoC vendors that ship bad kernels, weak upstream support, and opaque integration practices. There is no guarantee RISC-V boards will be better. Many already rely on vendor forks and board-specific boot chaos. The business incentives around support are the actual problem.
Switching instruction sets does not fix vendor behavior. Ecosystem quality follows support incentives, not marketing language about openness.
03 Open CPU cores do not eliminate the proprietary parts that matter most in connected devices.
The moment a project depends on Wi‑Fi, Ethernet, USB, or other heavyweight IP blocks, developers are back in the world of vendor-controlled silicon and software interfaces. That limits how much freedom RISC-V alone can buy.
RISC-V improves one layer of the stack. It does not magically open the rest of the chip.