ESP-Boards: Warum du dir diesen Mikrocontroller-Zirkus nicht antun solltest

Mon, 12 Oct 2026 00:00:00 +0000

Du hast gehört, ESP32-Boards seien „günstig, leistungsstark und perfekt für IoT". Du hast eins für 4,99 € bestellt. Du dachtest: „Das ist ein Wochenendprojekt." Es ist drei Wochen später, du hast vier Boards, einen Stapel USB-Kabel und die ernsthafte Frage im Kopf, ob dein Leben noch einen Sinn hat.

Willkommen in der Hölle. Ich zeige dir den Weg.

Kapitel 1: Das Flashen, oder „Halte den BOOT-Knopf und bete"

Bei einem normalen Gerät steckst du etwas an, und es funktioniert. Beim ESP gibt es ein Ritual:

Board anstecken.
Auf „Upload" klicken.
Warten.
Connecting........_____.....____
Panik.
BOOT-Taste gedrückt halten, EN kurz tippen, Mondphase prüfen, Hühnerblut auf das Breadboard.
Fehler: A fatal error occurred: Failed to connect to ESP32: No serial data received., ja warum denn nicht?

Beim nächsten Versuch klappt es dann plötzlich, ohne dass du irgendetwas anders gemacht hast. Das ist kein Erfolg, das ist ein Fluch.

Und das USB-Kabel erst. Die Hälfte aller Kabel in deiner Schublade lädt nur Handys und hat keine Datenleitungen. Sie sehen aus wie normale Kabel, sie fühlen sich an wie normale Kabel, und sie lügen dich in jeder Sekunde an. Du verbringst zwei Stunden mit der Fehlersuche im Treiber, bzw. den udev-Rules, bis du merkst, dass das Kabel der Täter war.

Apropos Treiber: Je nach Board steckt ein CP2102, ein CH340 oder ein anderer Chip als USB-Seriell-Wandler drauf. Unter Windows lädst du irgendeinen Treiber von einer Webseite, die aussieht, als würde sie dir gleich einen Krypto-Miner unterjubeln. Und unter Linux? Dazu kommen wir in Kapitel 2. Schnall dich an.

Kapitel 2: Linux, udev und die Kunst, einen Port zu bekommen

Du bist ein vernünftiger Mensch. Du benutzt Linux. Du denkst: „Hier läuft alles einfach, Treiber sind ja im Kernel." Und tatsächlich: Du steckst das Board an, und /dev/ttyUSB0 oder /dev/ttyACM0 erscheint. Ein Wunder!

Du klickst auf Upload.

Permission denied: '/dev/ttyUSB0'

Natürlich. Der Port gehört root:dialout, und du gehörst nicht zu dialout. Also tippst du sudo usermod -aG dialout $USER, loggst dich nicht aus, wunderst dich, dass es immer noch nicht geht, loggst dich aus, loggst dich wieder ein, und es geht. Bis du die Distribution wechselst, denn dort heißt die Gruppe uucp. Oder plugdev. Oder irgendwas anderes, was sich ein Maintainer aus der Hölle ausgedacht hat.

Aber das ist nur die Aufwärmrunde. Jetzt kommen die richtigen Gegner.

Gegner 1: ModemManager, der Port-Dieb

Kaum steckst du dein Board an, wacht ModemManager auf und denkt sich: „Ein serielles Gerät! Das ist bestimmt ein Modem! Ich probiere mal ein paar AT-Kommandos aus!" Mitten in deinem Flash-Vorgang. Dein ESP versteht davon kein Wort, dein Upload bricht ab, und du hast keine Ahnung, warum.

Gegner 2: brltty, die Braille-Mafia

Auf manchen Ubuntu-Versionen schnappt sich der Braille-Dienst brltty den CH340-Chip, weil dessen USB-ID zufällig zu einem Braille-Display passt. Das Gerät erscheint kurz, verschwindet wieder, und du starrst auf lsusb, in dem das Ding steht, während /dev/ttyUSB0 fehlt. Wenn du das einmal erlebt hast, vergisst du es nie wieder.

Gegner 3: Die wandernden Ports

Dein ESP32-S3 mit nativem USB meldet sich im normalen Betrieb als /dev/ttyACM0. Gehst du in den Bootloader-Modus, verschwindet der Port, und dasselbe Board erscheint als ttyACM1, mit anderer USB-ID. In der IDE ist natürlich noch der alte Port eingestellt. Viel Spaß beim Raten.

Die Lösung: udev-Regeln (ja, du musst jetzt Regeln schreiben)

Wer das alles einmal sauber lösen will, schreibt sich eigene udev-Regeln. Zuerst findest du die Hersteller- und Produkt-ID deines Boards heraus:

lsusb
# Bus 001 Device 007: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

Typische Kandidaten sind:

Chip	Vendor:Product
Silicon Labs CP210x	`10c4:ea60`
WCH CH340	`1a86:7523`
WCH CH9102	`1a86:55d4`
Espressif USB-Serial/JTAG (natives USB)	`303a:1001`

Dann legst du eine Datei an, zum Beispiel /etc/udev/rules.d/99-esp32.rules:

# Silicon Labs CP210x
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0660", GROUP="dialout", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="esp32"

# WCH CH340
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0660", GROUP="dialout", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# WCH CH9102
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="55d4", MODE="0660", GROUP="dialout", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# Espressif USB-Serial/JTAG (ESP32-S3, C3, ...)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="303a", ATTRS{idProduct}=="1001", MODE="0660", GROUP="dialout", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

Was die Zeilen tun:

MODE und GROUP setzen die Zugriffsrechte, damit du nicht mehr Root sein musst.
TAG+="uaccess" gibt dem gerade am Rechner angemeldeten Benutzer automatisch Zugriff, auch ohne Gruppenmitgliedschaft.
ENV{ID_MM_DEVICE_IGNORE}="1" sagt ModemManager, dass er seine Finger davon lassen soll.
SYMLINK+="esp32" legt einen stabilen Namen unter /dev/esp32 an. Achtung: Hängen mehrere gleiche Boards am Rechner, gewinnt eins davon zufällig. Dafür brauchst du dann die Seriennummer (ATTRS{serial}).

Danach lädst du die Regeln neu und steckst das Board neu an:

sudo udevadm control --reload-rules
sudo udevadm trigger

Und wenn es trotzdem nicht klappt, helfen diese Befehle beim Detektivspielen:

udevadm monitor --udev --property     # was passiert beim Einstecken?
udevadm info -a -n /dev/ttyUSB0       # welche Attribute kann ich matchen?
ls -l /dev/ttyUSB0                    # wem gehört der Port gerade?

Wer PlatformIO nutzt, kann sich auch deren fertige Regeldatei 99-platformio-udev.rules besorgen und sich das Schreiben sparen. Das ist die bequeme Variante, aber wo bleibt da der Schmerz, und hat dich mal irgendeine Anleitung die dem Board beiliegt, darauf hin gewiesen? Nein natürlich nicht!

Und wenn du die Arduino IDE als Flatpak oder Snap betreibst, darfst du zusätzlich noch mit der Sandbox um Gerätezugriffe verhandeln. Aber das ist ein Thema für ein anderes Kapitel. Oder eine andere Therapiestunde.

Kapitel 3: Die IDE-Frage, oder „Such dir dein Gift aus"

Es gibt nicht die Entwicklungsumgebung. Es gibt mindestens fünf, und alle sind auf ihre eigene Weise ein bisschen kaputt.

Arduino IDE 1.x: Sieht aus, als wäre sie 2007 im Keller eines Elektrotechnik-Instituts entstanden. Kein Autocomplete, kein vernünftiger Editor, aber hey, sie kompiliert (meistens).
Arduino IDE 2.x: Schicker, aber langsam. Sie braucht zum Starten länger als dein Kaffee zum Abkühlen und stürzt gern mal ab, wenn du den Serial Monitor öffnest.
PlatformIO in VS Code: Die „professionelle" Lösung. Du installierst eine Erweiterung, die erst mal eine halbe Ewigkeit Toolchains herunterlädt, dann ein Python-Environment baut und dir schließlich mitteilt, dass irgendeine Abhängigkeit nicht passt. Mächtig, ja. Aber auch ein Hobby für sich.
ESP-IDF: Das offizielle Framework von Espressif. Es ist großartig, wenn du Embedded-Entwickler bist und mit CMake, Kconfig und FreeRTOS-Tasks aufgewachsen bist. Wenn du nur eine Temperatur auslesen wolltest, wird dich idf.py menuconfig mit seinen 4.000 Optionen komplett aus der Bahn werfen, versprochen.
MicroPython / CircuitPython: „Ganz einfach, einfach Python!" Dann merkst du, dass die Hälfte der Bibliotheken fehlt oder anders heißt, dass der Speicher ständig vollläuft und dass die Performance eher an einen Taschenrechner erinnert, der gerade aus dem Winterschlaf erwacht.

Und natürlich ist nichts davon kompatibel zueinander. Dein Projekt in der Arduino IDE kannst du nicht mal eben nach PlatformIO schieben, ohne dass etwas explodiert, ist doch klar, oder?

Kapitel 4: Bibliotheken, oder „Bitte nicht die Version, die du brauchst"

Das ist mein persönlicher Favorit. Die Bibliotheksverwaltung beim ESP ist ein Glücksspiel, bei dem das Haus immer gewinnt.

Szenario A: Du suchst eine Bibliothek für dein Display. Es gibt 14 Stück. Zwei davon sind gut, eine ist seit 2018 nicht mehr gepflegt, und drei heißen fast gleich, funktionieren aber komplett unterschiedlich. Die Tutorials im Netz nutzen natürlich alle eine andere als die, die du installiert hast.

Szenario B: Das Tutorial ist von 2021. Die Bibliothek wurde seitdem dreimal umgebaut. Der Beispielcode kompiliert nicht mehr, und das GitHub-Issue dazu hat 83 Kommentare, davon 80 mit „+1" und einer mit „Fixed in my fork" (die Fork ist selbst seit zwei Jahren tot).

Szenario C: Du aktualisierst das ESP32-Board-Paket, weil eine Bibliothek es verlangt. Zack, eine andere Bibliothek, die gestern noch lief, kompiliert nicht mehr. Willkommen im Versionsroulette. Core 2.x gegen Core 3.x, ein Schisma, das Familien entzweit hat.

Szenario D: Die Bibliothek existiert für den ESP8266, für den ESP32 aber nicht. Oder für den ESP32, aber nicht für den ESP32-S3. Oder für den S3, aber nicht für den C3. Espressif bringt gefühlt monatlich einen neuen Chip heraus, und die Community kommt mit dem Portieren nicht hinterher.

Und dann gibt es noch die Klassiker:

fatal error: Something.h: No such file or directory

Ich habe diese Fehlermeldung inzwischen öfter gesehen als meine eigene Frau.

Kapitel 5: Der Rest, oder „Was sonst noch nervt"

Weil dieser Artikel sonst nur 40 Seiten lang wäre, hier die Schnellübersicht des Grauens:

Die Pinbelegung ist ein Minenfeld. Manche GPIOs darfst du beim Booten nicht auf HIGH ziehen. Manche sind nur Eingang. Manche hängen am Flash. Manche gehen nicht, wenn WLAN aktiv ist (ADC2, ich schaue dich an). Auf dem Board steht nichts davon, aber es steht in einem PDF mit 700 Seiten.

Jeder Hersteller baut sein eigenes Board. Das DevKitC von Espressif, das von AZ-Delivery, der NodeMCU-Klon, das Wemos-Dings, das T-Display von LilyGo. Alle haben leicht andere Pinouts, aber alle heißen irgendwie „ESP32". Der Schaltplan im Tutorial stimmt nie mit deinem Board überein.

Der Brownout-Detector. Dein ESP startet ständig neu, weil das USB-Netzteil nicht genug Strom liefert, sobald WLAN aktiv wird. Die Fehlermeldung: Brownout detector was triggered. Die Lösung: Ein besseres Kabel, ein besseres Netzteil, oder ein Kondensator, den du gerade nicht hast.

WLAN und Bluetooth gleichzeitig. Technisch geht das. Praktisch zerlegt es deinen Speicher, deine Stabilität und deine Nerven.

Der Stromverbrauch. „Perfekt für Batteriebetrieb!" stand auf der Produktseite. Dein Board saugt die Zelle in zwei Tagen leer. Deep Sleep funktioniert theoretisch, aber der Spannungsregler und die Power-LED auf dem Entwicklungsboard fressen im Schlafmodus mehr als der Chip selbst.

Die Dokumentation. Sie existiert, ja. Es gibt sogar viel davon. Nur steht die Antwort auf deine Frage immer genau in dem Teil, der fehlt, veraltet ist oder auf Chinesisch im Forum steht.

Over-the-Air-Updates. Super Feature! Bis du die Partitionstabelle verkonfiguriert hast und dein Board nur noch mit Kabel und Tränen zu retten ist.

Die Qualität der Billig-Boards. Du kaufst fünf. Eins hat einen kaputten Spannungsregler, eins hat kein funktionierendes WLAN, eins wird beim Anfassen heiß wie ein Toaster. Und bei der Reklamation fragt dich der Händler, ob du es schon mal aus- und wieder eingesteckt hast.

Fazit: Und trotzdem…

Und jetzt kommt das Schlimmste: Du wirst es trotzdem wieder tun.

Denn irgendwann, nach vier Stunden Fehlersuche und drei Tassen Kaffee, blinkt sie plötzlich. Die LED. Diese eine kleine, dumme LED. Und für einen Moment fühlst du dich wie ein Gott. Dann kommt das Dopamin, und du bestellst gleich drei neue Boards, weil du ja noch dieses eine Projekt umsetzen wolltest.

Der ESP ist wie eine toxische Beziehung: Er ist billig, unzuverlässig und macht dich wahnsinnig, aber er ist eben auch irgendwie überall und kann so verdammt viel für so wenig Geld.

Wer also trotz aller Warnungen einsteigen will: Kauf gute Datenkabel, schreib dir deine udev-Regeln, nimm PlatformIO oder ESP-IDF, wenn du es ernst meinst, pinne deine Bibliotheksversionen fest und lies das Datenblatt, bevor du einen Pin anfasst. Und wenn alles nichts hilft: Aus- und wieder einstecken.

Diesen Artikel habe ich geschrieben während ich wieder mal bei „Connecting……" hängen geblieben bin, obwohl ich nur schnell eine .bin flashen wollte. Er ist natürlich nicht so Ernst gemeint, aber ein wenig Frust, wollte ich damit schon mal ablassen :-) - Wir lesen uns, euer JohnJayMcKaye!

ESP32 on