Nieuwe ESP32-soc met dualcore-RISC-V-chip kan 62 gpio-pins aan

Espressif heeft een nieuwe ESP32-microcontroller aangekondigd die een dualcore RISC-V-processor heeft. De ESP32-S31 ondersteunt verder Wi-Fi 6, Bluetooth 5.4 en is bedoeld voor onder andere speakers, smarthomeapparatuur en stemapparaten, zegt de Chinese fabrikant.

De ESP32-S31-microcontroller is een soc voor in bijvoorbeeld smarthomeapparaten met als kern een dualcore-RISC-V-chip van 32bit met een maximale kloksnelheid van 320MHz. De soc heeft verder 512kB aan statisch geheugen en ondersteunt maximaal 250MHz aan DDR-pseudostatisch geheugen.

Maker Espressif zegt dat het apparaat geschikt is voor in bijvoorbeeld slimme beeldschermen, onder andere door de ondersteuning voor lcd-schermen en DVP-camera-interfaces. Ook heeft de chip JPEG-codecs voor beeldverwerking.

De chip werkt draadloos met Bluetooth 5.4, zowel standaard als Low Energy, en Wi-Fi 6 op 2,4GHz. Ook zit er een IEEE 802.15.4-radio in de chip voor Thread- en Zigbee-ondersteuning. De soc ondersteunt ook gigabitethernet. Behalve met ethernet kan de soc ook overweg met vrijwel alle belangrijke aansluitingen, waaronder I2C, I2S en SPI. Opvallend is ook dat de S31 ondersteuning heeft voor tot 62 gpio-pinnen, meer dan op de gemiddelde boards zitten.

De ESP32-S31 kan in de toekomst worden verwerkt in ESP32-controllers, maar vooralsnog noemt Espressif geen concrete apparaten waarin het de nieuwe soc verwerkt.

Reacties (49)

[Ablaze]

Welke security ondersteunt het out of the box? Aangezien de EU komende jaren strenge cybersecurity regelgeving krijgt voor de toepassing van dit soort processors in producten

[bugcyber]

hier de voorlopig gekende specs

ESP32-S31 preliminary specifications:

• MCU subsystem
  • RISC-V HP (High-performance) RV32IMAFCP CPU @ 320 MHz with FPU, SIMD, etc. 
  • RISC-V LP (Low-power) MCU core
• Memory & Storage I/F
  • 512 KB SRAM
  • 32 KB RTC SRAM
  • Support for external octal PSRAM and flash up to 64MB @ 250 MHz
• GPU – 2D Pixel Processing Accelerator (PPA) and
• VPU – (M)JPEG codec support
• Peripherals
  • Display I/F – 8-bit to 24-bit Parallel LCD interface
  • Camera I/F – 8-bit/16-bit DVP camera interface
  • Audio – 2x I2S
  • Networking
    • Gigabit Ethernet
    • 2.4 GHz WiFi 6 (802.11ax)
    • Bluetooth 5.4 with support for LE Audio, direction finding, Bluetooth Mesh 1.1, and Classic (BR/EDR)
    • 802.15.4 for Zigbee, Thread, and Matter
  • USB – USB 2.0 OTG (High Speed)
  • Up to 62x GPIOs
  • 4x MCPWM (Motor Control PWM)
  • 4x UART, 2x I2C, 2x SPI
  • ADC
  • 14-channel touch sensor
  • System timer (2 counters, 3 alarms)
  • Low-power core peripherals – Analog input, UART, IC, SPI
• Security
  • eFuse with key-purpose field
  • Flash and PSRAM encryption (XTS-AES-128/256)
  • Physical Memory Protection (PMP) with 128-byte granularity
  • AES, SHA, RSA, ECC
  • RAM-based PUF (Physically Unclonable Functions)
  • Secure boot
  • Digital signature peripheral
  • Protections against side-channel attacks and power glitch manipulation.
  • Trusted Execution Environment (TEE) with Access Permission Management (APM) for software isolation for secure multi-application deployment. 
• Misc – 40 MHz XTAL support

blijkbaar wordt de Low power MCU core meegerekend en bevat hij 1 RV32IMAFCP core @ 320 MHz

"The ESP32-S31 is a dual-core RISC-V MCU with one high-performance core with FPU and SIMD instructions, and one low-power RISC-V core,"

bron

Edit: het zou toch om een dual core RV32IMAFCP CPU @ 320 MHz + LP MUC core gaan.

[Reactie gewijzigd door bugcyber op 27 maart 2026 18:11]

[Ablaze]

Het antwoord op mijn vraag, bedankt!

[R_Zwart]

Het lijkt me dat die verantwoordelijkheid in dit geval ligt bij degene die er applicaties op gaat zetten.

[Ablaze]

Uiteraard, maar heeft het een secure area? Secure bootloader? Accelereert het encryptie en hashing? Hoe secure/open is de wifi stack?

[latka]

Ik kan me niet voorstellen opstellen dat de regelgeving op dat niveau zal komen. Veel van die zaken zijn tegen local exploits en een hamer wint het dan toch.

[Ablaze]

Die regelgeving is er grotendeels al. Niet voor de microcontroller zelf, wel als je 'm gebruikt in een commercieel apparaat dat op een of andere manier verbonden is met het internet.

https://www.rdi.nl/onderw.../handel-en-apparatuur/cra

[latka]

Damn. Ik ben door een deel van de stukken daar en op EurLex gegaan. Ik zie nergens dat het concreet wordt met maatregelen, maar idd. bootmanagers staan gewoon genoemd. Dat is compleet dwaze regelgeving als ze op dat niveau gaan proberen te micromanagemen op een markt die veel sneller ontwikkeld dat de wetgever teksten kan opschrijven. Wetgeving moet zich op hoofdlijnen focusen en bijsturen waar blijkt dat het misgaat. Heb je toevalig ook een link naar de gedetaileerde eisen per productcategorie? Ben erg benieuwd hoeveel 'illegale' spullen ik heb. Gelukkig is mijn router een PC die ge-repurposed is dus die valt er dan weer buiten ;-)

[Llopigat]

Juist het repurposen gaat lastig worden als alles straks secure boot moet hebben. Ff openwrt flashen is er dan niet meer bij.

[TD-er]

Dat heb je nu ook al met ESP32-xx devices die "Matter" ondersteunen.

Heel vaak hebben die efuses gebrand zodat je er alleen maar firmware versies op kunt zetten die met dezelfde key ondertekend zijn. Daardoor kan je als gebruiker dus niet je eigen firmware erop zetten.

Er zijn diverse variaties mogelijk hierop en in principe zou een fabrikant er zelfs voor kunnen kiezen om de bootloader pas te locken als je een setup-procedure doorloopt.
Maar helaas heb ik dat nog niet zien gebeuren. Wel dat devices dus 'gelocked' zijn.

In principe is dit een hele beroerde methode, want als die key zou uitlekken, kan je het dus niet 'fixen' en is dat apparaat voor altijd exploitable.
En als de fabrikant stopt met de ondersteuning, kun je de devices later dus niet zelf van nieuwe software voorzien.

[Llopigat]

Ja dat komt doordat Matter dit vereist helaas

Echt de bejubelde 'open standaard' die ons zou redden is het niet geworden. helaas. Het is meer lock-in dan tevoren, alleen dan voor een consortium van fabrikanten in plaats van een enkele.

En dat herprogrammeren is soms heel handig. Ik heb hier een heleboel van die bluetooth xiaomi temperatuursensoren die je makkelijk kan omkatten naar zigbee, die draaien nu allemaal zigbee.

[Reactie gewijzigd door Llopigat op 29 maart 2026 07:47]

[Ablaze]

Het gaat ook wel ver. En het lijkt mij sterk dat ze het kunnen controleren en handhaven.

Zo'n beetje alle apparaten vallen eronder, maar klasse 1 apparaten mogen self-certified zijn.

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R2847-20241120

Zie annex iii en iv. Als je product niet in een van de categorieën staat maar wel digitaal is en communicerende software heeft, dan is het categorie 1

Je kunt ook de normen EN 18031-1 en EN 18031-2 lezen voor de invulling, als je écht tijd over hebt

[Reactie gewijzigd door Ablaze op 27 maart 2026 22:02]

[bramv101]

Dit zal men idd nooit kunnen handhaven.

[laserfreak]

Als fabrikant van IoT toestellen zijn we hier heel hard mee bezig, en volgen we deze wetgeving op de voet. De EN normering die je aanhaalt is nu reeds actief als ammendement aan de RED.

Handhaving gebeurt zowel actief als passief maar net zoals CE compliancy wordt gehandhaafd. Als fabrikant of importeur ben je verantwoordelijk om in-regel te zijn. Soms worden producten aan steekproeven onderworpen of als er iets misloopt wordt gevraagd op basis waarvan je jouw DoC (declaration of conformity) hebt opgesteld. Als dit niet in orde is dan neem je als fabrikant toch wel grote risico's.

[Llopigat]

Er draait geen OS op, dus dat heb je al niet. (Nouja soms FreeRTOS maar dat is niet te vergelijken met iets als Linux). Het is meer een microcontroller dan een Raspberry Pi.

Maar WPA3 kunnen ze bijvoorbeeld al wel, de nieuwste modellen.

[Reactie gewijzigd door Llopigat op 27 maart 2026 17:03]

[Pyronick]

Er draait geen OS op, dus dat heb je al niet. (Nouja soms FreeRTOS maar dat is niet te vergelijken met iets als Linux). Het is meer een microcontroller dan een Raspberry Pi.

Ik ben erg benieuwd of Zephyr RTOS bij de release in april al ondersteuning biedt voor deze nieuwe RISC-V SoC! Want hoewel Zephyr een RTOS blijft, is het door het gebruik van Kconfig en devicetrees wel een hardware abstractie die meer op een volwaardig, Linux-achtig systeem (wat een beetje op een BusyBox omgeving met een interactieve shell) zou moeten lijken. Voor mij is het coden daarvoor al gauw te complex, maar voor bijvoorbeeld projecten zoals ESPHome, WLED of zelfs Arduino zelf zou dit de spaghetti aan Arduino Core, ESP-IDF, LibreTiny en allerlei vage abstracties, hacks en BSP-specifieke code moeten voorkomen, wat de maintainers aanzienlijk zal vrijspelen.

Anders kom je inderdaad al gauw uit op het standaard ESP-IDF (wat overigens onder de motorkap zwaar leunt op FreeRTOS) of de Arduino-route. Daar is an sich niets mis mee, maar dan ben je in de praktijk toch vaak óf hardware registers aan het aftikken, óf een spaghetti van Arduino libraries aan elkaar aan het knopen en debuggen.

[Llopigat]

Oh ja Zephyr heb ik wel eens gezien. Ik gebruik het zelf niet maar het is wel iets om naar te kijken. Bedankt voor de herinnering!

[Amanoo]

Ik heb het wel eens gebruikt, maar dat is wel een paar jaar terug. Maar destijds was ik niet enorm onder de indruk. Je liep al snel tegen beperkingen aan omdat zaken gewoon niet geïmplementeerd waren. Zo was er iets met USB. Ik meen USB host modus dat niet geïmplementeerd was, wat we juist eigenlijk wel wilden gebruiken. Misschien dat het ondertussen wel al erin zit.

[Hans1990]

IMO beperkt. De grootste hazard zit hem wat mij betrreft in de binary blob die benodigd is om radio zaken te doen.

Dat is al jaar en dag een doorn in het oog bij Linux gebruikers als je met een (Intel) WiFi chipset wilt werken. De reden waarom dit "nodig" is omdat radio een gedeeld spectrum is, en je niet zomaar elk pakket op elk moment de lucht in mag slingeren. De blob is dan een homologatie van de RF stack om verstoringen bij andere gebruikers te vermijden. Ook een vereiste om een FCC/CE stickertje te kunnen verdedigen.

Echter het vereist ook vertrouwen dat die binary blob geen eigenaardigheden bevat. Als EU hier hoog op in zet, dan zouden ze er goed aan doen om te kijken welke partijen ze in het huidige wereld klimaat wel toevertrouwen hierin. De VS verbood "buitenlandse routers" onlangs. En om eerlijk te zijn? Ik geef ze op sommige technische vlakken geen ongelijk. Daarintegen knutselt elke provider vaak ook z'n eigen schil over een router, en is dat dan altijd zo waterdicht?

Imo valt bovendien serieus te overwegen of je tegenwoordig nog liever VS of CN apparatuur hebt draaien. VS heeft ook z'n kanttekeningen met de hoeveelheid touwtjes die ze graag in handen (willen) hebben in de techwereld, met bij sommige bedrijven remote kill switches aan toe.

Ik ben bang dat de EU op dit moment niet genoeg (betaalbare) alternatieven heeft om echt kracht bij zo'n security roadmap te zetten. Er zijn een paar alternatieven voor zo'n ESP32 chip, waaronder Nordic Semiconductor. Maar het lijstje is niet bijzonder lang, en bovendien, op prijs niet echt een vervanger.

[Reactie gewijzigd door Hans1990 op 27 maart 2026 22:59]

[Chromebooks.nl]

Waarom geen wifi7? Dit is echt een gemiste kans lijkt mij.

[BRAINLESS01]

Zelfs wifi6 is bij ESP32 relatief nieuw, het grootste deel van de ESP32-socs kan nog niet eens met 5GHz wifi netwerken verbinden. Het kan nog jaren duren voordat ze wifi7 gaan ondersteunen, maar het is goed mogelijk dat ze wifi7 helemaal overslaan. Snelheid is voor dit soort apparatuur niet echt relevant, het is veel belangrijker dat de verbinding stabiel is. Gigabit ethernet is trouwens ook nieuw, 100mbit is voor dit soort apparatuur snel genoeg.

[.MaT]

Snelheid is voor dit soort apparatuur niet echt relevant, het is veel belangrijker dat de verbinding stabiel is.

Jammer dat nieuwe ontwikkelingen vaak gereduceerd worden tot 1 aspect, vaak het meest bekende: in dit geval weer snelheid.

Naast hogere doorvoersnelheden komen nieuwe wifi standaarden meestal ook met vernieuwingen die efficientie, stabiliteit, latency, energieverbruik, beveiliging,... enz verbeteren waar ook IOT sensoren voordeel kunnen uithalen.

Wifi vandaag is ook anders dan wifi 20 jaar geleden waar je enkele laptops en telefoons/tablets had. Vandaag moeten die data hongerige toestellen samenleven met tientallen of zelf honderden IOT toestellen, dat vraagt een licht andere aanpak. Wifi7 houdt hier al rekening mee.

[StormRider]

Welke voordelen heeft dit? Rekening houdend met de rekenkracht van dit kleine printplaatje.

Volgens mij is wifi 2.4GHZ perfect voor toepassingen als dit. Echter wordt dat steeds minder compatibel.

[Reactie gewijzigd door StormRider op 27 maart 2026 16:27]

[Indy81]

2.4Ghz is inderdaad perfect, maar ik kan me indenken dat sommigen gewoon liever de 2.4 wifi uitzetten in huis om verschillende redenen.

[Wouterie]

Perfect voor een IoT-netwerk. Hoeft nier per se snel te zijn.

[RobertMe]

Als het niet snel hoeft te zijn kun je net zo goed Thread gebruiken. Dat is ook IP based waardoor je alle "internet communicatie" dingen kunt doen. Waarbij Thread Border Routers ook een verplichting hebben om internet te ondersteunen, dus je kunt ook prima met een cloud verbinden over Thread. Maar dat is uiteraard niet geschikt voor de voorbeelden die bij deze ESP32-31 staan. Je gaat hiermee geen smart speaker bouwen waarbij je audio over Thread moet sturen.

Zie bv dus ook ESPHome, om laag drempelig firmwares te maken voor (intussen "o.a." en niet meer "alleen maar") deze Espressif microcontrollers. Traditioneel hebben die hun eigen API om "over wifi" met Home Assistant te babbelen. Maar sinds kort ondersteunen ze ook Thread, op de bordjes die dat ondersteunen (H2 en C6 uit mijn hoofd verkrijgbaar, daarnaast de aangekondigde C5, en nu deze S31). En daarbij sturen ze hun eigen API gewoon over Thread heen. Waarbij de API zelf etc niet gewijzigd hoefde te worden. Het blijft immers IP.

En uiteraard heb je ook nog de keuze voor Zigbee. Nog iets "beperkter" maar ook nog net wat zuiniger. Daarover kun je dan geen IP sturen. Maar nv voor simpele sensoren (of actoren) is Zigbee ook ruim voldoende. En Zigbee support in ESPHome voor de ESP32 (H2 / C6) wordt ook aan gewerkt. En de ondersteuning is er al voor een of andere NRF??? chip. Maar dat gebruikt dan uiteraard geen "ESPHome API" om met Home Assistant te babbelen.

[Ablaze]

In dat geval heb je alsnog geen Wifi 7 nodig.

[Fuss!]

Efficiëntie op power-gebied: WiFi 7 biedt een verbeterde versie van TWT (gekend van WiFi 6): Restricted Target Wake Time (R-TWT). Of het érg veel uit zal maken weet ik niet.

[Reactie gewijzigd door Fuss! op 27 maart 2026 17:12]

[Llopigat]

Interessant. Hopelijk kan de prijs dan ook wat omlaag ten opzichte van de oude S3. (Die nog op ARM draaide).

De C3 en C6 (beiden RISC-V) waren al een heel stuk goedkoper maar ik miste daar toch net wat power met dingen als FFT.

[RoyD]

Op Ali heb je S3 bordjes met 16 MB RAM Flash voor aanbiedingsprijzen lager dan 4 Euro. Vind je dat duur?

[Reactie gewijzigd door RoyD op 27 maart 2026 16:50]

[Llopigat]

Een stuk duurder dan de C3 ja die ik voor 1,50 per stuk koop (15€ per 10)

Ik stop ze in projecten dus ik ga er nogal snel doorheen. Maar ik doe de laatste tijd meer met muziek sync en daar heb ik FFT voor nodig (en een MEMS microfoon met SPI). Dan tikken die extra kosten wel aan.

Ps het is 16MB Flash niet RAM.

[Reactie gewijzigd door Llopigat op 27 maart 2026 16:50]

[RoyD]

Inderdaad Flash

[TD-er]

De ESP32P4 heeft wel 32 MB PSRAM en 16MB flash.

Dus als je een projectje hebt waarbij je dat ook echt nodig hebt, hoor ik het graag

Die budget C3 bordjes zijn trouwens wel een loterij geworden.
QC is niet aanwezig en er zijn er zelfs waar geen flash op zit en daardoor dus compleet onbruikbaar zijn.
De chip-antenna die erop zit is compleet verkeerd geplaatst waardoor de RF-performance om te huilen is en je soms de TX-power behoorlijk moet terugschroeven om uberhaupt niet te crashen omdat vrijwel alle uitgezonden vermogen rechtstreeks weer de chip in gaat door de verkeerd afgestemde antenne.

En dan heb ik het nog niet eens over missende componenten waardoor het bordje helemaal niets doet, of sluiting in de soldering of tin korrels van slechte soldeerpasta die ineens sluiting kunnen geven.

[Llopigat]

Oh ja ik gebruik eigenlijk nooit de WiFi kant ervan. Soms wel bluetooth maar zeer lokaal. Ik heb altijd die "SuperMini". Lijkt een beetje op de waveshare maar dan een goedkope kloon.

De kwaliteit is inderdaad niet geweldig nee maar ik gebruik ze meestal in wearables die ik 1x draag een daarna niet meer, of misschien na een jaar weer eens. Het is wel prima.

[Reactie gewijzigd door Llopigat op 29 maart 2026 08:57]

[laserfreak]

De ESP32-S3 heeft geen ARM core aan boord maar draait op twee Xtensa cores van Tensilica, naast deze twee hoofd cores is er ook een ultra-low power SoC aanwezig die RISC-V gebaseerd is.

[Llopigat]

Oh ja ik zie het. Ik dacht dat het een ARM was om de een of andere reden. Oeps. Ik programmeer ze normaal met hogere talen dus ik heb er niet zoveel mee te maken maar de dual core helpt enorm.

[laserfreak]

Ze zijn heel krachtig en het is ook een RISC instructieset. Ze worden goed ondersteund door GCC en dus kan je inderdaad goed uit de voeten met hogere talen. Wij maken de Walter module en onderhouden dan ook de WalterModem library https://github.com/QuickSpot voor zowel C/C++ binnen ESP-IDF en Arduino als MicroPython. Het feit dat zelfs scriptingtalen als Python zo snel werken toont aan hoe krachtig ze zijn.

Onderbelicht/gebruikt in de ESP32-S3 is de RISC-V ULP core, die kan met zeer weinig stroom toch basis taken uitrekenen. Zeer interessant voor batterijgevoedde toestellen.

[Llopigat]

Bedankt, ik zal daar eens induiken. Ik zocht laatst nog een goed batterij gevoed 4G boardje! Ik had nog een pycom module maar die zijn niet meer beschikbaar (en het bleek er ook eentje zonder 4G, alleen sigfox)

[Reactie gewijzigd door Llopigat op 29 maart 2026 09:04]

[thijspomper]

Kleine correctie: de S3 gebruikt Xtensa cores geen ARM.

Het prijsverschil tussen de C3 en S3 komt niet door de cores, maar door de peripherals en features.
De S31 zal waarschijnlijk dus duurder zijn.

[freshy98]

Dus SRAM/PSRAM zoals in de foto staat en niet DDR-pseudostatisch geheugen?

[Prince]

Mooie chip voor AI-on-the-edge, maar de specs zijn voor veel IoT zwaar overdreven.
Ik denk dat dit soort chips meer in fotokaders kan komen te zitten, smart mirrors, etc...
JPEG is overigens decoding én encoding.

[mawashigeri]

Zelfs M-JPEG 1080p@30FPS, in mijn jeugd moest je voor een kastje die dat in PAL resolutie kon een fortuin neertellen!

Voor wie het niet kent: M-JPEG is een soort MPEG stream met alleen maar key-frames, ideaal voor editing dus maar beduidend minder efficiënt dan MPEG.

[quazar]

Vooral Zigbee en Wifi>4 zijn voor mij een groot voordeel. Gebrek aan gpio-pinnen heb ik nog niet gehad. Voor iedereen wat wils tijdens deze upgrade blijkbaar!

[komododraak]

inderdaad: smart devices met een ESP kan je direct herkennen omdat ze bijna nergens met moderne wifi werken. die vereisen 5 kHz. leuk dat 2.4 leuk bereik heeft, maar door geen 5ghz te doen zijn ze niet te gebruiken in normale bedrijven

[Llopigat]

Het is juist fijn want je hebt dan je IoT spullen op een totaal apart netwerk. Geen last van vertraging van je PC netwerk met lage datarates.

Maar voor wie het graag wil is er wel de ESP32-C5.

Meestal is dat niet iets waar je extra voor wil betalen.

[Reactie gewijzigd door Llopigat op 27 maart 2026 16:59]

[joker1977]

"normale bedrijven"

De definitie van normale bedrijven is afhankellijk van de frequentie van hun WiFi signaal ?

[thijspomper]

Geen 2.4Ghz?
Persoonlijk ben ik nog geen bedrijven tegen gekomen zonder 2.4Ghz. (of zijn deze bedrijven niet normaal?)
2.4Ghz blijft namelijk stukken beter in bereik en penetratie van muren/objecten.

Voor vreemde gevallen is er ook de ESP32-C5 met 5Ghz.

[svenk91]

Normale bedrijven stellen toch hun netwerk in op basis van wat hun apparaten nodig hebben? Als je veel IoT hebt is het al niet gek om meerdere vlans voor IoT te hebben, zou 2,4GHz ondersteunen dan veel impact hebben?

[Jau2]

gpio = general purpose input output