Wer mit ePaper/eInk-Displays, kleinen TFTs oder Raspberry-Pi-HATs bastelt, stolpert fast automatisch über Waveshare und GoodDisplay. In Shops wirkt das wie „gleiche Liga, gleicher Use-Case“. In der Praxis sind es aber zwei völlig unterschiedliche Welten – und genau deshalb entstehen die typischen Fehlerbilder: Display bleibt weiß, Upload bricht ab, serielle Schnittstelle taucht nicht auf, Demo-Code kompiliert nur mit einer uralten Toolchain. Viele Projekte scheitern nicht an der Idee, sondern an den Details rund um Hardware-Qualität, Softwarepflege und Schnittstellen.
Waveshare: riesiges Sortiment, aber oft mit Altlasten und halbgarer Software
Waveshare ist vor allem ein Anbieter von Modulen, Adapterboards und HATs. Die Auswahl ist groß, die Teile sind meist schnell zu bekommen, und der Preis ist oft so niedrig, dass man „einfach mal probiert“. Genau da liegt der Haken: Diese Produktstrategie funktioniert nur, wenn Dokumentation und Software sauber nachgezogen werden. Und genau das ist bei Waveshare ein häufiger Kritikpunkt. Viele Libraries und Demos wirken wie „gerade genug, damit es auf irgendeinem Setup irgendwie läuft“. Wenn du Pech hast, sind Beispiele auf alte SDK-Stände zugeschnitten, nutzen veraltete Abhängigkeiten oder erwarten exakt die eine Boardrevision, die du nicht bekommen hast.
Das führt zu dem Gefühl, Waveshare liefere regelmäßig veraltete oder schlecht gepflegte Sachen aus. Nicht alles ist schlecht – es gibt ordentliche Produkte – aber die Streuung ist groß. Bei einem Projekt läuft alles beim ersten Versuch, beim nächsten verbringst du Stunden damit, Pinouts zu vergleichen, Timing anzupassen, Pegel zu prüfen und am Ende doch eine Community-Library zu nehmen, weil die „offizielle“ Lösung nicht mehr zum aktuellen Toolchain-Stand passt.
GoodDisplay: oft bessere Basis beim Panel, weniger „Plug & Play“ beim Drumherum
GoodDisplay ist in vielen Fällen näher am eigentlichen Display-Panel. Das merkt man daran, dass Spezifikationen und Produktinfos häufig strukturierter wirken als bei typischen Modul-Anbietern. Dafür bekommst du nicht automatisch ein Komplettgefühl wie „auspacken, aufstecken, Demo starten“. Bei GoodDisplay ist die Realität eher: gutes Panel, klare technische Eckdaten – und du kümmerst dich selbst darum, wie du es sauber an den Mikrocontroller bringst (Adapterboard, Levelshifting, passende Library, sauberes Refresh-Handling bei ePaper).
Der Unterschied ist wichtig: Viele „Waveshare-ePaper“ basieren in der Praxis auf Panels, die aus der GoodDisplay-Welt stammen oder sehr ähnlich sind. Das Panel kann also völlig okay sein, während das Ärgernis aus Carrierboard, Kabel, Treiberchip oder Demo-Code kommt. Genau deshalb kann GoodDisplay im Kern stabil wirken, während Waveshare drumherum für Frust sorgt – obwohl am Ende ein sehr ähnliches Display leuchtet.
Micro-USB ist nicht nur alt, sondern eine Fehlerquelle – vor allem wegen der Kabel
Ein Punkt, der bei Waveshare immer wieder auffällt: Micro-USB taucht auch dort noch auf, wo man 2026 eigentlich USB-C erwarten würde. Das ist mehr als ein Komfortthema. Micro-USB bringt zwei praktische Probleme mit, die in Bastelprojekten regelmäßig Zeit verbrennen.
Erstens: Micro-USB-Kabel ist nicht gleich Micro-USB-Kabel. Es gibt Kabel, die nur zum Laden gedacht sind und intern schlicht keine Datenleitungen haben oder miserabel umgesetzt sind. Von außen sehen die identisch aus. Du steckst ein Board an, es bekommt Strom, LEDs leuchten – aber am Rechner taucht nichts auf. Dann beginnt die Fehlersuche: Treiber, Port, Firmware, Boot-Mode. Dabei ist es nur ein „Ladekabel“. Zusätzlich gibt es Kabel, die zwar Datenleitungen haben, aber so schlecht geschirmt oder so dünn sind, dass Verbindungen instabil werden. Gerade bei seriellen Uploads oder schnellen Reset-Sequenzen kann das reichen, um „sporadische“ Fehler zu erzeugen, die sich wie Softwarebugs anfühlen.
Zweitens: Spannungsabfall und Wackelkontakt. Micro-USB-Stecker und Buchsen sind mechanisch empfindlicher als USB-C. Ein leicht ausgeleierter Port oder ein Kabel mit dünnen Adern sorgt dafür, dass unter Last die Spannung einbricht. Mikrocontroller reagieren darauf gern mit Brownout-Resets oder komischen Boot-Zuständen. Ergebnis: Upload bricht ab, Board startet nicht sauber, Display initialisiert manchmal, manchmal nicht. Solche Effekte sind pures Gift für Fehlersuche, weil sie sich nicht reproduzierbar anfühlen.
Unterm Strich ist Micro-USB in diesem Umfeld nicht nur „alt“, sondern ein Multiplikator für unnötige Probleme. Wenn du die Wahl hast, ist USB-C in der Praxis schlicht stressfreier.
CH340: billig, verbreitet – am Mac oft ein unnötiges Risiko
Ein weiterer Klassiker, gerade bei günstigen Boards: CH340 als USB-zu-Seriell-Chip. Der CH340 ist nicht grundsätzlich schlecht. Unter Windows und Linux läuft er häufig problemlos, und genau deshalb wird er so gern verbaut: Er ist günstig, verfügbar, und für viele Hersteller reicht das als „Haken dran“.
Am Mac ist die Lage häufig unangenehmer. Je nach macOS-Version, Sicherheitsmechanismen und Architektur kann es sein, dass du zusätzliche Treiber brauchst, dass Treiber nicht sauber signiert/notarisiert sind oder dass es nach Updates wieder klemmt. Dazu kommt: Wenn du mehrere USB-Seriell-Geräte nutzt, willst du vor allem eines – dass die Schnittstelle jedes Mal zuverlässig auftaucht und sich nicht wie ein Glücksspiel anfühlt. Genau aus dem Grund würde ich Mac-Nutzern vom CH340 eher abraten, wenn es vermeidbar ist. Der Chip spart am falschen Ende: Was du beim Einkauf sparst, zahlst du gern in Zeit zurück.
Wenn du am Mac möglichst entspannt arbeiten willst, sind Boards mit CP2102/CP210x, FTDI oder direkt mit nativer USB-Schnittstelle (je nach Mikrocontroller) in der Praxis oft die bessere Wahl. Das ist nicht „Luxus“, sondern schlicht Zuverlässigkeit. Für Projekte, die du öfter ansteckst, debugst und aktualisierst, ist das Gold wert.
Libraries und Doku: Der Unterschied zwischen „Demo läuft“ und „Projekt hält“
Bei Displays entscheidet die Library über Lebensqualität. Hersteller-Demos sind oft okay, um ein erstes Bild zu bekommen. Aber bei Waveshare wirkt es regelmäßig so, als ob Demo-Code eher als Beilage betrachtet wird: Hauptsache irgendwas zeigt Pixel. Sobald du es in ein echtes Projekt integrieren willst – mit sauberem Update-Zyklus, Stromsparmodi, Teilupdates, Rotationslogik, mehreren Targets – zeigt sich, ob eine Library gepflegt wird oder nicht.
Gerade bei ePaper ist das wichtig, weil Timing, Refresh-Modi und Controller-Details eine Rolle spielen. Wenn du hier eine solide, aktiv gepflegte Library nimmst, sparst du dir sehr viel Ärger. Das ist auch der Grund, warum viele am Ende bewusst auf Community-Libraries setzen, selbst wenn Hersteller-Code existiert: weniger Altlasten, klarere APIs, bessere Kompatibilität mit aktuellen Arduino-/PlatformIO-/SDK-Ständen.
Fazit: Welche Marke „besser“ ist, hängt weniger vom Logo ab als vom Ökosystem
Waveshare ist nicht automatisch schlecht. Die Firma macht viele Produkte überhaupt erst leicht zugänglich. Aber genau diese Breite führt oft zu dem Eindruck von veralteten Boards, wechselnder Qualität und halb gepflegten Libraries. Dazu kommen handfeste Praxisbremsen: Micro-USB statt USB-C, dazu die Kabelproblematik („lädt, aber keine Daten“), und der gern verbaute CH340, der am Mac unnötig oft zum Stolperstein wird.
GoodDisplay wirkt häufig solider auf der Panel-Ebene und bei technischen Eckdaten, aber du bekommst nicht immer das „fertige Bastelpaket“. Dafür ist die Basis oft dankbar: Wenn du Adapter, Stromversorgung und Library sauber wählst, kannst du damit sehr stabile Setups bauen.
Wenn du ein Projekt willst, das nicht nur einmal kurz läuft, sondern verlässlich bleibt, dann lohnt sich eine einfache Priorität: saubere Schnittstelle (USB-C oder stabile USB-UART-Lösung), gutes Kabel, gepflegte Library. Damit sind viele der typischen „Waveshare-Probleme“ plötzlich keine Mystik mehr, sondern vorhersehbare, vermeidbare Fehlerquellen – und genau so sollte Technik sich anfühlen.
Kommentare