Die Weiterentwicklung der Espressif MCUs mit WiFi ist gewaltig: erst vom kleinen ESP8266 hin zum ESP32, und jetzt eine neue Serie mit nativer USB-Unterstützung sowie dem Wechsel von der XTensa CPU hin zur RISV-V CPU. Dennoch bleibt es ein ESP32 mit all seinen Vorteilen, der sich einfach in der Arduino-IDE programmieren lässt.

Dieser Artikel gibt einen Überblick über die verschiedenen MCUs: ESP32, ESP32-S2, ESP32-S3, ESP32-C3 mit ihren Unterschieden, der Leistung und der Peripherie. Es gibt noch zwar noch weitere Unterfamilien der ESP32-Serie, auf diese soll hier aber nicht eingegangen werden. Die MCUs ESP32, ESP32-S und ESP32-C3 habe ich intensiv getestet.

Nativer USB-Support

Endlich ist es soweit, die Modelle S2, S3 und C3 beinhalten USB-Unterstützung. Das bedeutet, ich kann per USB (D+ und D-Leitung) die MCU direkt programmieren. Auch die serielle Konsole (Arduino „Serial Monitor“) funktioniert per nativem USB, somit ist ein USB-zu-Serial-Interface, welches bisher immer verbaut war, nicht mehr notwendig.

USB mit ESP32-S2 Bockschaltbild

Einfacher geht es nicht: nur das ESP32-Modul (S2/S2/C3) mit Spannung versorgen, einen Boot-Taster anschließen, USB D+/D-/GND verbinden und fertig. Die MCU kann mit der Arduino IDE (ab V2.0.0) programmiert werden. Sobald die Programmierung abgeschlossen ist, einfach neu starten (vom Strom trennen, oder einen Reset auslösen) und ab dann läuft das neue Programm (Arduino Sketch). So etwas könnt Ihr auch!

Im Boot-Modus (gedrückte Boot-Taste) prüft die ESP32-MCU (S2/S3/C3) parallel im Boot-ROM, ob eine Programmierung per nativem USB oder per UART durchgeführt wird. Beides funktioniert.

Ich finde die USB-Unterstützung sensationell. Von Anfang an war ich an der USB-Unterstützung dran und konnte beim Arduino-SDK noch Feedback geben, sodass USB ab der Arduino-SDK-Version 2.0.0 richtig funktioniert.

Unterstützung für den USB „Virtual COM“-Port

Den Arduino „Serial Monitor“ kennen wir bereits. Dort werden Meldungen per Serial.print() ausgeben bzw. per Serial.read() gelesen. Das funktioniert inzwischen auch mit nativem USB, per „Virtuell COM“-Port mit dem „USB Communications Device Class“-Protokoll (USB CDC). In der Vergangenheit funktionierte dies schon mit dem Arduino Zero, und wir nutzen das auch bei unseren LoRa-Boards (Turtle und LongRa) zur Programmierung und für den „Serial Monitor“. Toll, dass dies auch mit den ESP32 (S2/S2/C3) MCUs funktioniert.

Auf dem Weg zum RISC-V-Prozessor

Der ehemalige US-Präsident Donald Trump hat mit seinen Sanktionen bewirkt, dass mehrere Hersteller auf den RISC-V-Prozessor gehen. Der RISC-V-Prozessor ist open source, wurde komplett neu definiert und hat somit keine Altlasten. Er wird von immer mehr Herstellern verwendet, auch bei Espressif ist davon auszugehen, dass RISC-V zukünftig in allen MCUs verwenden wird, aktuell bereits in der ESP32-C3-Serie. Ich habe den ESP32-C3 intensiv getestet und kann sagen, dass dieser bei identischer Taktrate nur ca. 10% langsamer als die XTensa-MCU im ESP32-S2 ist. Dieser geringe Unterschied wird sicherlich mit zukünftigen Versionen aufgeholt werden.

Der ESP32-C3 RISC-V bleibt ein ESP32

In allen ESP32-MCUs (ESP32, S2, S3, C3) bleibt die Peripherie trotz der Unterschiede im Prozessor identisch. Das bedeutet, nur der Prozessor wurde ausgetauscht oder aktualisiert, alles andere ist geblieben (WiFi, SPI, I²C, ADC, RMT, Timer usw.). Somit können auch umfangreiche ESP32-Programme mit einer S2- oder C3-MCU verwendet werden; die Peripherie ist schlichtweg kompatibel. Allerdings sind je nach MCU einige Peripherie-Bausteine kleiner ausgelegt (z. B. zwei zusätzliche Timer beim C3 anstelle der 4 zusätzlichen Timer beim ESP32, S2, S3). Das hat marketingtechnische Gründe und ist gängige Praxis bei allen Herstellern, kostet der C3 schließlich deutlich weniger als ein S2.

Unterschiede in der CPU-Geschwindigkeit (ESP32, S2, C3)

Ich habe einen kleinem CPU-Benchmark entwickelt, welcher in einer Kette eine Addition, eine Multiplikation, eine Subtraktion sowie eine Division durchführt, also vier mathematische Operationen. Hier wird gemessen, wie viele Millionen (Mega) dieser Operationsketten pro Sekunde durchlaufen werden. Das Ganze dann mit unterschiedlichen Datentypen:

(x2) Beim Dual Core ESP32 liefert die zweite CPU die identische Geschwindigkeit wie die erste, daher ist die Geschwindigkeit zweimal vorhanden.

Es ist wichtig zu wissen, dass die S2- und C3-MCUs keine „Floating-Point Unit“ haben, weshalb dort die Float-Performance ca. 8 mal langsamer ist. Double (64-bit Float) sowie 64-bit Integer beherrscht keine der MCUs, daher sind dort alle langsam. Fehlende CPU-Operationen wie für Float, Double und Int64 werden automatisch per Software in der C/C++ Runtime Bibliothek gerechnet, was auch einwandfrei funktioniert, aber halt langsamer ist. Zu beachten ist auch, dass der C3 nur mit 160 MHz läuft, der ESP32 sowie S2/S3 laufen mit 240 MHz.

Die ESP32-Serie braucht sich nicht zu verstecken und ist schneller als preislich vergleichbare ARM MCUs.

ESP32 Bluetooth-Unterstützung

Der ESP32-S3 sowie der ESP32-C3 verfügen über eine neue Bluetooth-Hardware sowie -Software. Das konnte ich leider noch nicht testen und behandle es hier daher auch nicht.

Technische Unterschiede beim ESP32, S2, S3, C3, H2

Hier eine kleine Auflistung der Unterschiede der verschiedenen MCUs aus der ESP32-Serie. Zur einfacheren Gestaltung erfolgt die Aufzählung der Abweichungen gegenüber dem genannten Referenzprozessor in Listenform:

ESP32

(Dual-Core XTensa, WiFi, 512 kB SRAM, etc.)

ESP32-S2 (Abweichung gegenüber ESP32)

• Single-Core XTensa LX7 MCU (statt Dual-Core)
• Keine Floating-Point Unit (Softwareimplementation ist 8x langsamer)
• Mehr Pins (56 GPIOs)
• Mehr Touch-Pins
• USB OTG (on-the-go) integriert
• Bluetooth 5.0
• ULP-RISC-V Co-Prozessor

ESP32-S3 (Abweichung gegenüber ESP32-S2)

• Dual-Core XTensa LX7 MCU
• Floating-Point Unit
• Bluetooth 5.2 (LE)

ESP32-C3 (Abweichung gegenüber ESP32)

• RISC-V CPU
• Bluetooth 5 (LE)
• 160 MHz statt 240 MHz
• 400 kB SRAM (statt 512 kB)
• Weniger Pins (32 GPIOs)
• 8 kB RTC-Speicher (statt 16 kB)
• Keine Floating-Point Unit (Softwareimplementation ist 8x langsamer)
• 56-bit statt 64-bit Timer-Register
• 2 statt 4 verfügbare Timer
• 4 statt 8 RMT-Kanäle
• USB integriert

ESP32-H2 (Abweichung gegenüber ESP32-C3)

• 256 kB SRAM (statt 400 kB)
• 96 MHz statt 160 MHz
• Bluetooth 5.2 (LE)
• Kein WiFi

Tückische Probleme bei der ESP32-Serie

Bei so viel Positivem gibt es Probleme, welche wir als Software und Hardware Entwickler kennen müssen.

a) Flash-Speicher
Der Flash-Speicher ist immer seriell über einen zusätzlichen Flash-Chip angebunden, auch wenn dieser bereits in der MCU integriert ist. Das bedeutet, dass der Programmcode blockweise vom Flash-Speicher ins RAM geladen werden muss und der Code erst danach ausgeführt wird. Auch ein ständiges Nachladen (Swapping) tritt bei großen Programmen auf. Dadurch geht einiges an verfügbarem SRAM verloren, da er für die Ausführung des Codes benötigt wird.

b) Interrupt-Routinen
Da Interrupt-Routinen nicht davon ausgehen können, dass ihre Zieladresse auch aktuell verfügbar ist (siehe a) Flash-Speicher), müssen alle Interrupt-Routinen per Compiler-Attribut IRAM_ATTR deklariert werden. Zusätzlich müssen alle Subroutinen, welche im Interrupt aufgerufen werden, z. B. SPI, GPIO-Subfunktionen oder 64-bit Runtime-Arithmetik, ebenfalls mit IRAM_ATTR deklariert werden, damit diese auch im SRAM verfügbar sind. Das ist sehr fehlerträchtig, da solche Probleme nur per Zufall auftreten.
Hölle, Hölle, Hölle …

c) Deep Sleep
Der ESP32 Deep Sleep benötigt zwar wenig Strom (<7 µA), allerdings wird die interne CPU und das SRAM dafür komplett abgeschaltet, nur der RTC-Speicher (8-16 kB) bleibt erhalten. Bei einem GPIO- oder Timer-Wake-up (nur ein Pin als Wake-up definierbar) aus dem Deep Sleep, bootet die MCU (ESP32, S2, S3, C3) komplett durch. Das dauert ca. 300 ms und man muss mühsam seinen Programmstatus aus dem RTC-Speicher rekonstruieren. Ein echter Deep Sleep ist das also nicht.
Bei MCUs von anderen Herstellern, zum Bespiel die STM32L4-Serie, bleiben Speicher sowie CPU-Status komplett erhalten und eine Interrupt-Routine wird im Deep Sleep innerhalb von ca. 5 µs aufgerufen und alle GPIOs sind auch im Deep Sleep aktiv. So funktioniert ein richtiger Deep Sleep! Daher verwenden wir bei RadioShuttle.de auch STM32L4 MCUs für die Turtle- und LoRa-Boards.

Trotz dieser Probleme und Beschränkungen überwiegen die Geschwindigkeitsvorteile der ESP32-Serie mit integriertem WiFi, sehr viel SRAM und großem Flash. Mit der neuen nativen USB-Unterstützung und dem kleinen C3 mit RISC-V ist wirklich ein großer Schritt getan. Ich bin begeistert!

Ich hoffe, dieser Überblick bringt ein wenig Licht in die ESP32-Serie. Weitere Fragen und Diskussionen gerne persönlich beim Arduino-Hannover-Treffen.

Viel Erfolg bei Euren ESP32 Projekten!

Links

• RISC-V
• Geschwindigkeit und Tücken gängiger MCUs
• Arduino ESP32 SDK
• LoRa Boards & MQTT Push App