ESP32-S31
Posted: Tue Mar 31, 2026 3:04 pm
Just very sparsely technical specifications available, mostly marketing speak...
What do we actually know?
It looks like a ESP32-S3 but
- the two Xtensa cores are replaced by RISC-V cores (which was to be expected)
- classic Bluetooth (re-)added
- gigabit PHY added
- MCPWM removed?
- Thread/Zigbee added?
- more GPIO pins (60!?)
- JPEG hardware codec
- a lot of added "security" features (aka: IP protection) that are not interesting at all for us hobbyists
Good that there's full SPI-RAM support now, on a RISC-V based SoC.
The core's speeds are the same as the Xtensa's cores in the S3. I am a bit worried that the processing speed of "normal" code will therefore be less on this SoC.
It's a pity (IMHO) it doesn't support the 5 GHz band. For serious applications, one should really use 5 GHz.
Also the amount of internal RAM remains the same. That's really an issue, because a lot of internal RAM is assigned to all sorts of "internal" things, so there really isn't that much left for an IDF application. In my case I already moved everything possible to SPI-RAM, including LWIP, Bluetooth and the stack of most threads and still I only have ~50 kB left for DMA etc. I also lowered the threshold for the allocator to assign to internal RAM to block to internal RAM to only 32 bytes...
I am very interested whether the known limitations the S3 have been addressed. Like the very limited bit-width of the LED PWM modules. Some limitations of the I2C modules and whether the ULP I2C will be really usable now.
What do we actually know?
It looks like a ESP32-S3 but
- the two Xtensa cores are replaced by RISC-V cores (which was to be expected)
- classic Bluetooth (re-)added
- gigabit PHY added
- MCPWM removed?
- Thread/Zigbee added?
- more GPIO pins (60!?)
- JPEG hardware codec
- a lot of added "security" features (aka: IP protection) that are not interesting at all for us hobbyists
Good that there's full SPI-RAM support now, on a RISC-V based SoC.
The core's speeds are the same as the Xtensa's cores in the S3. I am a bit worried that the processing speed of "normal" code will therefore be less on this SoC.
It's a pity (IMHO) it doesn't support the 5 GHz band. For serious applications, one should really use 5 GHz.
Also the amount of internal RAM remains the same. That's really an issue, because a lot of internal RAM is assigned to all sorts of "internal" things, so there really isn't that much left for an IDF application. In my case I already moved everything possible to SPI-RAM, including LWIP, Bluetooth and the stack of most threads and still I only have ~50 kB left for DMA etc. I also lowered the threshold for the allocator to assign to internal RAM to block to internal RAM to only 32 bytes...
I am very interested whether the known limitations the S3 have been addressed. Like the very limited bit-width of the LED PWM modules. Some limitations of the I2C modules and whether the ULP I2C will be really usable now.