LCD-Ansteuerung: 16×2 und Grafik-Displays am PIC betreiben

Die LCD-Ansteuerung gehört zu den häufigsten Aufgaben in PIC-Projekten: Ein 16×2-Textdisplay für Menüs und Messwerte, ein kleines Grafik-Display für Icons oder Kurven oder ein größeres TFT für eine moderne Benutzeroberfläche. Der Einstieg wirkt oft simpel („ein paar Pins anschließen, Text ausgeben“), doch in der Praxis entscheiden Details über Erfolg oder Frust: falsche Kontrasteinstellung, flackernde Hintergrundbeleuchtung, Timing-Probleme bei der Initialisierung, kryptische Zeichen statt Text oder ein Grafikdisplay, das zwar leuchtet, aber nichts Sinnvolles zeichnet. Gleichzeitig ist LCD nicht gleich LCD. Ein klassisches 16×2-Modul mit HD44780-kompatiblem Controller verhält sich völlig anders als ein Grafik-LCD mit ST7920 oder ein TFT mit ILI9341, das per SPI oder parallelem Interface angebunden wird. Wer das versteht, kann sehr gezielt auswählen: minimaler Pinbedarf über I²C-Expander, schnelle Updates über SPI, oder maximale Performance über parallele Datenbusse. Dieser Artikel zeigt Ihnen eine saubere Vorgehensweise, wie Sie 16×2-Displays und Grafik-Displays am PIC zuverlässig betreiben: von Hardware und Pegeln über Initialisierung, Timing und Zeichensatz bis zu Speicherbedarf, Performance und robustem Software-Design.

Display-Typen im Überblick: Text-LCD, Grafik-LCD, TFT – was ist was?

Bevor Sie verdrahten oder Code schreiben, klären Sie, welche Displayklasse Sie tatsächlich einsetzen. Die Ansteuerung, die Datenmenge und die Bibliotheksstruktur unterscheiden sich erheblich.

• Text-LCD (z. B. 16×2, 20×4): meist HD44780-kompatibel, zeigt Zeichen in einem festen Raster; Grafik ist nur sehr begrenzt über benutzerdefinierte Zeichen möglich.
• Grafik-LCD (monochrom): Pixelmatrix (z. B. 128×64), oft Controller wie ST7920 oder KS0108; ideal für einfache Grafiken, Icons, große Schrift.
• TFT-Displays (Farbdisplay): Controller wie ILI9341, ST7735, SSD1306 (OLED, monochrom), meist SPI oder paralleles Interface; deutlich mehr Daten, dafür moderne UI möglich.

Für Text-LCDs ist die HD44780-Referenz besonders relevant, weil sehr viele Module kompatibel sind und sich Timing/Kommandos daran orientieren: HD44780 Controller Datenblatt (PDF). Für Grafik-LCDs lohnt es sich, das Datenblatt des konkreten Controllers zu lesen, etwa beim ST7920: ST7920 Controller (Grafik-LCD) Referenz (PDF).

Hardware-Basics: Versorgung, Pegel, Kontrast und Hintergrundbeleuchtung

Viele LCD-Probleme sind Hardwareprobleme. Besonders bei PIC-Projekten ist die Frage entscheidend: Arbeiten PIC und Display mit gleichen Logikpegeln (5 V/3,3 V)? Und ist die Kontrast- bzw. Hintergrundbeleuchtungsbeschaltung korrekt?

• Versorgung: Text-LCDs sind häufig 5 V, viele TFT/OLED-Module dagegen 3,3 V. Prüfen Sie Modul-Spezifikation und ob ein Level-Shifter vorhanden ist.
• Kontrast (Text-LCD): typischerweise über ein Potentiometer (z. B. 10 kΩ) an V0/VEE. Ohne korrekt eingestellten Kontrast „funktioniert“ das Display, bleibt aber scheinbar leer.
• Backlight: Hintergrundbeleuchtung braucht oft einen Vorwiderstand oder eine Konstantstromquelle; viele Module haben ihn bereits integriert, manche nicht.
• Reset-Pin (Grafik/TFT): Viele Controller benötigen einen definierten Hardware-Reset oder eine saubere Reset-Sequenz beim Start.

Vorwiderstand für die Hintergrundbeleuchtung korrekt dimensionieren

Wenn Ihr Modul keinen integrierten Vorwiderstand hat, dimensionieren Sie ihn über die LED-Daten (Vorwärtsspannung Vf, Strom I). Die Standardformel lautet:

$R=\frac{V\mathrm{CC}–Vf}{I}$

Beispiel: 5 V Versorgung, LED-Vorwärtsspannung 3,2 V, gewünschter Strom 20 mA. Dann ergibt sich R = (5 − 3,2) / 0,02 = 90 Ω. In der Praxis wählen Sie den nächsthöheren Normwert (z. B. 100 Ω) für etwas Reserve und geringere Wärme.

16×2 und 20×4 Text-LCD am PIC: HD44780-kompatible Ansteuerung

Text-LCDs sind ideal für Menüs, Statusanzeigen und Messwerte. Die typische Ansteuerung erfolgt im 4-Bit- oder 8-Bit-Modus. Für PIC-Projekte ist 4-Bit oft der Standard, weil er Pins spart, ohne spürbar langsam zu sein.

• 8-Bit-Modus: schneller, aber benötigt mehr IO-Pins.
• 4-Bit-Modus: spart Pins, erfordert das Senden jedes Bytes in zwei Nibbles.
• RS/RW/E: RS wählt Daten/Command, RW wählt Lesen/Schreiben, E taktet die Übernahme.

Viele Designs verbinden RW dauerhaft mit GND, um nur zu schreiben. Das vereinfacht die Schaltung, bedeutet aber: Sie können das Busy-Flag nicht auslesen und müssen stattdessen mit definierten Delays arbeiten. Für robuste Initialisierung ist das in der Praxis völlig in Ordnung, solange die Delays nicht zu knapp bemessen sind.

Initialisierung: Warum Text-LCDs oft „nichts anzeigen“

Die Initialisierung ist der Klassiker. HD44780-kompatible Displays starten nicht immer in einem eindeutig definierten Zustand, besonders wenn die Versorgung langsam ansteigt. Die bewährte Sequenz setzt deshalb mehrfach den 8-Bit-Modus, bevor auf 4 Bit umgeschaltet wird. Wenn Sie hier abkürzen, riskieren Sie Zufallsverhalten. Eine sehr gute Referenz ist das HD44780-Datenblatt selbst: HD44780 Datenblatt (PDF).

Pinbedarf reduzieren: I²C-Expander (PCF8574) und „Backpack“-Module

Wenn Ihr PIC viele Pins für Sensoren oder Aktoren braucht, ist die I²C-Anbindung eines Text-LCDs über einen Port-Expander (häufig PCF8574) sehr attraktiv. Viele „LCD-Backpacks“ setzen genau darauf: Der Expander steuert RS, E und die 4 Datenleitungen sowie oft die Hintergrundbeleuchtung.

• Vorteil: nur zwei Leitungen (SCL/SDA) + Versorgung, ideal bei kleinen PICs.
• Nachteil: etwas höhere Latenz; schnelle Animationen sind begrenzt.
• Praxis: für Menüs und Werteanzeige meist vollkommen ausreichend.

Für I²C ist wichtig: Pull-up-Widerstände, saubere Buslänge und passende Geschwindigkeit. Wenn mehrere I²C-Teilnehmer existieren, prüfen Sie Adressen und Buskapazität.

Benutzerdefinierte Zeichen (CGRAM): Kleine Grafiken auf Text-LCDs

Text-LCDs können über die CGRAM (Character Generator RAM) eigene Zeichen speichern. Damit lassen sich Symbole wie Pfeile, Batterieindikatoren oder Balken darstellen – sehr nützlich für UI ohne Grafikdisplay.

• Typisch 8 Custom Characters: je nach Controller/Modul.
• Raster meist 5×8 oder 5×10: abhängig vom Displaymodus.
• Anwendung: Fortschrittsbalken, Icons, einfache „Grafik“-Elemente.

Der Trick für schöne Balken: mehrere Füllstufen (z. B. 0–5 Pixelbreite) als eigene Zeichen anlegen und daraus eine Bar zusammensetzen.

Grafik-LCDs am PIC: ST7920, KS0108 & Co. – pixelgenau, aber mit Konzept

Ein monochromes Grafik-LCD (z. B. 128×64) ist ein sehr guter Kompromiss: Es wirkt „modern“, benötigt weniger Daten als ein TFT und erlaubt dennoch echte Grafiken. Allerdings brauchen Sie eine sinnvolle Softwarestruktur, denn Sie zeichnen nicht mehr „Zeichen“, sondern Pixel oder Bitmaps.

Controller-Architektur: Display-RAM, Pages und Adressierung

Viele Grafikcontroller organisieren den Speicher in „Pages“ (Zeilenblöcke), wobei ein Byte häufig 8 vertikale Pixel repräsentiert. Das hat direkte Konsequenzen:

• Pixel setzen ist nicht immer „einfach ein Bit schreiben“ – häufig müssen Sie ein Byte lesen/ändern/schreiben oder einen Shadow-Buffer führen.
• Teilupdates sind effizient, wenn Sie pagebasiert arbeiten und Dirty-Flags nutzen.
• Fonts werden als Bitmaps gespeichert; Rendering ist eine Kernaufgabe Ihrer Bibliothek.

Beim ST7920 kommt hinzu, dass er je nach Modul sowohl parallel als auch seriell betrieben werden kann (serielle Anbindung ist SPI-ähnlich, aber nicht immer 1:1 SPI). Eine nützliche Referenz ist die ST7920-Dokumentation: ST7920 Referenz (PDF).

TFT- und Farbdisplays am PIC: SPI als Standard, Performance als Herausforderung

Farb-TFTs wie 240×320 (ILI9341) sind beliebt, weil sie günstig sind und „Smartphone-Feeling“ ermöglichen. Die Herausforderung ist der Datendurchsatz: Ein Vollbildupdate kann schnell Hunderttausende Bytes bedeuten. Daher ist SPI fast immer die Schnittstelle der Wahl, manchmal ergänzt durch DMA (bei geeigneten PICs) oder durch parallele Interfaces bei sehr hohen Anforderungen.

• SPI (4-Draht): SCK, MOSI, MISO (optional), CS plus D/C und Reset.
• Teilscreens aktualisieren: statt Vollbild, z. B. nur Zahlenfelder oder Widgets.
• Farbtiefe: häufig RGB565 (16 Bit), weil Speicher und Bandbreite besser passen.

Als technische Basis ist das ILI9341-Datenblatt hilfreich, weil es Register, Initialisierung und Fenster-Updates beschreibt: ILI9341 Datenblatt (PDF).

Warum „Vollbild-Framebuffer“ am PIC oft nicht realistisch ist

Ein kompletter Framebuffer für 240×320 in RGB565 benötigt 240 × 320 × 2 = 153.600 Byte. Viele PICs (insbesondere 8-bit) haben deutlich weniger RAM. Selbst bei leistungsfähigeren PICs ist das ein großer Block. Deshalb sind typische Strategien:

• Direktes Zeichnen in Display-Fenster: nur die Pixel senden, die sich ändern.
• Tile-/Widget-Rendering: kleine UI-Bereiche als Buffer (z. B. 20×20 Pixel) und dann blitten.
• Komprimierte Bitmaps: Icons im Flash speichern und effizient übertragen.

Schriften, Symbole und UI: Fonts sind Ihr größter Produktivitätshebel

Ob Text-LCD oder Grafikdisplay: Fonts und ein solides Text-Rendering entscheiden darüber, ob Ihr UI professionell wirkt. Bei Text-LCDs ist die Schrift fix, aber Sie können Layout und Abkürzungen optimieren. Bei Grafik/TFT haben Sie volle Kontrolle – und damit auch Verantwortung.

• Monospace-Fonts: einfach zu rendern, gut für Messwerte und Tabellen.
• Proportionalfonts: schöner, aber komplexer (Kerning/Bounding Boxes).
• Unicode? auf kleinen PICs selten sinnvoll; stattdessen definierte Codepages und Symbole.

Eine saubere Strategie ist, einen „Font-Header“ mit Metadaten zu definieren (Breite, Höhe, Startchar, Glyphen-Offsets) und das Rendering zentral zu halten. Dann können Sie Fonts tauschen, ohne überall Code anzupassen.

Timing und Robustheit: Delays, Busy-Flag, Reset-Sequenzen

Displays sind keine „perfekt synchronen“ Peripherien. Gerade beim Power-Up und bei Reset-Zuständen entstehen viele Fehler. Drei Regeln helfen fast immer:

• Nach Power-Up warten: konservativ, bevor Sie initialisieren (insbesondere bei Text-LCDs).
• Reset-Pin nutzen, wenn vorhanden: definierter Startzustand bei Grafik/TFT.
• Delays nicht zu knapp: besonders zwischen kritischen Kommandos (Clear Display, Return Home).

Wer maximale Geschwindigkeit will, kann beim Text-LCD das Busy-Flag auslesen (RW aktiv). Das ist aber nur dann sinnvoll, wenn Sie wirklich eng getaktete Updates benötigen. Für die meisten PIC-Projekte sind saubere, konservative Delays die stabilere Wahl.

Performance verstehen: Wie schnell können Sie wirklich zeichnen?

Die wahrgenommene Geschwindigkeit hängt nicht nur von MHz ab, sondern von Datenmenge und Protokoll. Ein grobes Modell für die Übertragungszeit eines Datenblocks über SPI lautet:

$t=\frac{N\mathrm{bits}}{f\mathrm{SPI}}$

Wenn Sie z. B. 10.000 Bytes übertragen, sind das 80.000 Bits. Bei 10 MHz SPI wären das idealisiert 0,008 s, also 8 ms – ohne Protokolloverhead, ohne Kommandos, ohne CPU-Zeit. In der Realität kommen Fenster-Setups, D/C-Umschaltungen und Rendering-Rechenzeit dazu. Daher ist das wichtigste Optimierungsprinzip: weniger Pixel senden (Partial Updates) statt „schneller senden“ um jeden Preis.

Software-Design: Treiber, Abstraktion und Wiederverwendbarkeit

Eine professionelle LCD-Ansteuerung am PIC trennt konsequent zwischen Hardwaretreiber und UI-Logik. So können Sie später von 16×2 auf Grafik-LCD wechseln, ohne das gesamte Projekt umzuschreiben.

• HAL/Bus-Layer: GPIO, SPI, I²C, Delay, optional DMA.
• Display-Driver: Init, WriteCommand, WriteData, SetCursor/SetWindow, Clear, Backlight.
• Graphics/Text-Layer: DrawPixel, DrawLine, DrawRect, DrawBitmap, DrawText.
• UI-Layer: Screens, Menüs, Zustandsautomaten, Event-Handling.

Besonders bei Grafik/TFT lohnt sich ein „Dirty Rectangle“-Ansatz: UI-Elemente markieren die Bereiche, die sich geändert haben, und nur diese Bereiche werden neu gezeichnet. Das spart massiv Bandbreite und verhindert Flackern.

Stolperfallen aus der Praxis: Fehlerbilder und schnelle Diagnose

• Text-LCD zeigt nur schwarze Blöcke: Kontrast stimmt, aber Initialisierung fehlt oder läuft falsch; RS/E/4-Bit-Nibbles prüfen.
• Text-LCD bleibt komplett leer: Kontrast zu niedrig/hoch, Backlight aus, falsche Pinbelegung (RS/E vertauscht).
• Grafikdisplay reagiert sporadisch: Reset fehlt, Timing zu knapp, Versorgungseinbruch oder zu lange Leitungen.
• TFT leuchtet, aber zeigt nichts Sinnvolles: falsche Init-Sequenz, D/C-Pin falsch, falscher SPI-Mode, CS nicht stabil.
• Farben „falsch“: RGB/BGR-Einstellung im Controller, Farbtiefe (RGB565) oder Byte-Reihenfolge inkonsistent.

Wenn Sie systematisch debuggen wollen: Erst elektrische Grundlagen (Versorgung, Pegel, Reset), dann Bus-Signale (Logic Analyzer: CS, SCK, MOSI, D/C), dann Initialisierung (Kommandofolge), erst danach Rendering. Für Text-LCDs ist das HD44780-Datenblatt dabei die zuverlässigste Referenz: HD44780 Datenblatt (PDF).

Auswahlhilfe: Welches Display passt zu welchem PIC-Projekt?

• Einfaches Messgerät/Relaissteuerung: 16×2 oder 20×4 (HD44780) – minimaler Aufwand, sehr robust.
• Menüs mit Icons/Graphen: 128×64 Grafik-LCD (ST7920) – gute Lesbarkeit, moderate Datenmenge.
• Moderne UI mit Buttons/Charts: TFT (ILI9341/ST7789) – mehr Aufwand, dafür maximale Flexibilität.
• Extrem stromsparend und kontraststark: OLED (z. B. SSD1306) – oft SPI/I²C, sehr beliebt für kompakte Geräte.

Für SSD1306-OLEDs ist das Datenblatt eine gute Basis, um Adressierung und Display-RAM zu verstehen: SSD1306 Datenblatt (PDF).

Weiterführende Ressourcen: Datenblätter und praxisnahe Referenzen

• HD44780 Datenblatt (Text-LCD, Initialisierung, Kommandos)
• ST7920 Referenz (Grafik-LCD, Speicherorganisation, serieller Modus)
• ILI9341 Datenblatt (TFT-Controller, Fensterupdates, Farbtiefe)
• SSD1306 Datenblatt (OLED, Page-Adressierung, I²C/SPI)
• MPLAB X IDE (Werkzeugbasis für PIC-Displayprojekte)
• MPLAB XC8 Compiler (C-Entwicklung für 8-bit PIC)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.