ESP32-S31 in Massenproduktion, MERICRON als ESP32-Alternative uvam

Mit dem ESP32-S31 lancierte Espressif einen sehr leistungsstarken Rechenkern, der auch ein Funkmodul mitbrachte – nun gilt, dass seine Verfügbarkeit beginnt. FreeCAD verliert einen wichtigen Maintainer, während sich die Eclipse Foundation im Bezug auf RISC/V für ThreadX äußert. Was es sonst Neues gibt, vermelden wir hier.

Espressif: Massenverkauf des ESP32-S31 beginnt

Boards mit der „neuesten“ Variante von Espressifs Wireless-Kombinationsprozessor tauchten in der Vergangenheit immer wieder auf AliExpress auf. Von Seiten Espressifs selbst gab es diesbezüglich bisher allerdings keine wirklichen, belastbaren Aussagen. Unter https://www.espressif.com/en/news/ESP32_S31_Mass_Production vermeldet man, dass der Chip nun – endlich – die „Massenreife“ erreicht hat:

1

Espressif Systems (SSE: 688018) announces that its ESP32-S31 has entered mass production and is now available for purchase. Designed for next-generation AIoT applications, ESP32-S31 is a high-performance dual-core RISC-V SoC with comprehensive wireless connectivity, making it ideal for smart home hubs, smart speakers, edge AI devices, industrial automation, and more.

Als „offiziellen Vertriebsweg“ für die Entwicklerkits schlägt man dabei den hauseigenen Store vor, der sich zum Zeitpunkt der Abfassung dieser Newsmeldung wie in der Abbildung gezeigt präsentiert.

Bildquelle: https://www.aliexpress.com/store/1102014060

Interessant ist, dass die „allgemeine“ Verfügbarkeit bei Distributoren derzeit eher langsam anläuft. Eine OEMSecrets-Suche ergibt derzeit zwar schon verschiedenste SKUs, der einzige listende Distributor ist derzeit allerdings Mouser.

Bildquelle: https://www.oemsecrets.com/compare/ESP32-S31

MERICRON MCN-1 – amerikanische ESP32-Variante in Entwicklung

An einem „reichhaltigen“ Topf bleibt man erfahrungsgemäß nicht sonderlich lange allein – das Eintreffen weiterer Futterkonkurrenten ist nur eine Frage der Zeit. Im Fall von Espressif steht mit dem MERICRON MCN-1 nun eine „Made in America“-Variante in Planung, deren „wichtigste“ Spezifikationen sich wie gezeigt präsentieren.

Bildquelle: https://www.mericron.com/mcn-1

Sowohl in den diversen Ankündigungen auf X als auch in den Spezifikationstabellen verbergen sich dabei diverse kleine Hiebe gegen Espressif. Ein Beispiel ist in der folgenden Abbildung gezeigt.

Bildquelle: MERICRON.

In der Diskussion auf X wird besonders hervorgehoben, dass die hauseigene Wireless-Firmware – zumindest teilweise – offen sein soll. Als primäres Hindernis sieht man in diesem Bereich die „Zertifikation“ des Chips an. Schade ist, dass sich auf der offiziellen Homepage hierzu nur vergleichsweise wenige Informationen finden.

Bildquelle: MERICRON.

CircuitPython 10.3.0-alpha.4 verfügbar

Im Hause Limor Fried arbeitet man permanent an der Verbesserung des hauseigenen MicroPython-Derivats. Nun ist eine neue Alpha-Version verfügbar geworden. Unter der URL https://github.com/adafruit/circuitpython/releases/tag/10.3.0-alpha.4 vermeldet man die folgenden „Neuerungen“:

1

• Add audiofilewriter.

2

• Add audiodelays.GranularPitchShift.

3

• Add sdioio, audiodelays, audiofilters, and audiofreeverb on RP2xxx.

4

• Add CIRCUITPY_BLE_WORKFLOW, CIRCUITPY_SAFE_MODE_DELAY, and CIRCUITPY_WIFI_HOSTNAME to settings.toml.

5

• Add storage.unsafe_disable_usb_drive(), to disable the USB CIRCUITPY drive after the host has mounted it.

6

• Lower the default WiFi power from 20 dBm to 15 dBm on all boards with chip antennas.

7

• USB host fixes.

8

• Espressif BLE fixes.

9

• ESP-NOW works again on Espressif.

10

• Update TinyUSB.

Zu beachten ist, dass die neue Version mit „Änderungen“ im Bereich der Ermittlung der SPI-Taktrate einhergeht. Von Vorgängerversionen umsteigende Nutzer sind gut beraten, die folgenden Kompatibilitätswarnungen zumindest im Hinterkopf zu behalten:

1

The baudrate specified in busio.SPI.configure() is now a ceiling, and will not be exceeded. Previously, on some ports, the actual baudrate chosen could have been the nearest available baudrate, but higher than the specified baudrate, sometimes by a substantial amount. Use SPI.frequency to fetch the actual baudrate. Limitations: On Zephyr, SPI.frequency is the specified, not the actual baudrate, and some Zephyr ports may violate the ceiling behavior.

IEEE: Versuch zur „Verhinderung“ von Seitenkanal-Angriffen

Seitenkanal-Angriffe – man denke beispielsweise an Clock Glitching oder das Herumspielen mit der Spannungsversorgung – dürften zu den „häufigsten“ Einfallstoren gehören, über die p. t. Hacker Zugang zu Krypto-Halbleitern bekommen. In einem IEEE-Journal wurde nun eine neue Methode zur Mitigierung derartiger Attacken veröffentlicht. Weitere Informationen finden sich in der Abbildung.

Bildquelle: https://x.com/MehdiHacks/status/2081486468627738690

Eclipse Foundation: RISC-V ist First-Class Citizen für ThreadX

Microsoft kaufte ThreadX einst, um FreeRTOS ein Produkt entgegenzusetzen – da sich die Division auf die „Gesamtfinanzzahlen“ nicht sonderlich gut auswirkte, warf man das Betriebssystem später in Richtung der Eclipse Foundation weiter. Bisherige Zielplattformen von ThreadX waren Arm- und sonstige MCUs. Unter https://newsroom.eclipse.org/eclipse-newsletter/2026/july/beyond-basics-elevating-eclipse-threadx-first-class-rtos-risc-v findet sich nun eine durchaus umfangreiche Meldung, die nach folgendem Schema darauf hinweist, dass RISC-V-MCUs in Zukunft ebenfalls „erstklassige“ Teilnehmer des Ökosystems sein werden:

1

The effort to adapt ThreadX for RISC-V required a deep dive into the architectural intricacies of the RISC-V ISA. The collaboration between 10xEngineers and the ThreadX project team focused on resolving the complexities inherent in porting core components to both RV32 and RV64 environments.

2

A primary focus was the optimisation of functions for the RISC-V privileged architecture. This included a rigorous redesign of context switching, interrupt nesting, and timer management. On RISC-V, these operations interact directly with the privileged hardware registers, requiring extreme precision to maintain real-time guarantees. The team found that some register saving, which is often employed in preliminary ports, was insufficient for modern, high-performance extensions like floating-point and vector units. Consequently, the project implemented systematic procedures that ensure integrity across complex execution states.

3

Additionally, the standardisation of existing RISC-V board support packages (BSPs) was improved. By refactoring these packages, the team lowered the effort needed for the ThreadX community to support a diverse range of hardware. The contributions also moved ThreadX away from hardcoded, platform-specific profiles that previously hampered some cross-platform portability.

ROHM – oder: vom Versuch, einen Halbleiterhersteller zu verkaufen

Dass DENSO vor einiger Zeit versuchte, ROHM zu kaufen, hatten wir auf Mikrocontroller.net mehrfach erwähnt. Aufgrund der „Nähe“ von ROHM Semiconductor zu anderen Automobilherstellern erwies sich dies allerdings als sehr „suboptimale“ Kombination. Seither wandert das Unternehmen wie ein Sauerbierverkäufer durch das Gebirge – der in Sachen GaN und SiC im Allgemeinen gut informierte Ralf Higgelke berichtet unter https://www.linkedin.com/pulse/ralfs-gan-sic-news-july-23-2026-ralf-higgelke-05z3c/ umfangreich (und lesenswert) über die Wirrungen und Abenteuer:

1

On paper, the fit is neat, giving one group a foothold in almost every corner of the market, from car inverters to factory drives and grid equipment, writes The Next Web. However, the plan carries an awkward backstory. In February, Toyota Motor Corporation-affiliated DENSO bid approximately ¥1.3 trillion ($8.3 billion) for ROHM Semiconductor, part of Toyota’s drive to localize its EV chip supply. However, Rohm rebuffed the offer to protect its cross-industry customers, and Denso withdrew in late April.

2

That left a horizontal tie-up among peers as the surviving route to scale, rather than absorption by a single carmaker. It also left Rohm free to keep selling to every vehicle-parts group at once, which was rather the point of saying no.

FreeCAD: Maintainer tritt zurück

Dass die „Wartung“ von quelloffener Software ein durchaus interessantes Problem ist, dürften Leser von Mikrocontroller.net im Allgemeinen wissen. Im Hause FreeCAD – das Projekt entwickelt eine quelloffene Alternative zu AutoCAD – gibt es nun den Abgang eines Core-Maintainers zu vermelden. Spezifischerweise findet sich unter https://forum.freecad.org/viewtopic.php?t=106653 eine längere Meldung zum Thema. Die „wichtigste“ Passage ist unten:

1

This is to announce my decision to take a step back from FreeCAD maintaining. I have been part of the core team for almost 20 years now, and the project is taking a direction that is not the one I wish to work with. And this is fine, the FreeCAD project now has a strong, active and united team of maintainers, who are really pushing things forward and putting a ton of mechanisms in place to address the complexity of a project of this size.

EtherCAT: Big in Japan

Im Hause EtherCAT dürfte man Asien wieder ins Herz geschlossen haben – nach dem Erfolg mit dem letzten Plug Fest versendete man eine weitere Pressemeldung, die auf ein asiatisches Event zum Thema des Feldbusses einging. Besonders interessant empfand der Newsautor die folgende Passage, die auf die „geographische Verteilung“ der Implementierer eingeht:

1

Die stark wachsenden Mitgliederzahlen der ETG – insbesondere in Asien – unterstreichen die zunehmende Verbreitung von EtherCAT als führendes Industrial-Ethernet-System: 44 % aller ETG-Mitglieder weltweit sind in Asien ansässig.

Budapest: Kunst am Print

Wer morgen Abend nichts zu tun hat und sich für die Recyclage von übriggebliebenen Platinen in Kunstwerke erwärmen kann, sollte zur in der Abbildung gezeigten Vernissage von Robin Grant Sperling kommen. So der Newsautor den morgen bevorstehenden Eingriff gut übersteht, steht einem Treffen vor Ort nichts im Wege.

Bildquelle: https://www.instagram.com/art_teleportation/p/DbGn-M0oRge/