LC-Display mit I2C-Bus

Seit dem ich zum ersten Mal mit LC-Displays hantiert habe (Shack-Uhr), empfinde ich diese Displays als äusserst nützlich. Und an Eigenbaugeräten sieht ein Display doch wesentlich professioneller aus, als ein paar LEDs. Nur diese hübschen Anzeigen haben auch gewisse "Haken": Ohne etwas "Computerisierung" (sprich: Microcontroller) lässt sich den LCDs nur wenig Sinnvolles "entlocken". Und dabei werden vom Display dann meistens gleich mehr als die Hälfte der verfügbaren Portbits belegt (zumindest, wenn man hauptsächlich das PIC-"Einsteigermodell" 16F84 verwendet). Für komplexere Projekte fehlen dann die notwendigen (freien) "Verbindungen zur Aussenwelt". Ein Ausweg aus diesem Dilemma wäre eine mehrfache Verwendung der Ports (-> Multiplexing), was jedoch die Verwendung von zusätzlichen Chips (oder sehr "trickreicher" Programmierung?) erfordert. Aber es gibt ja auch noch andere Wege ... Es ist doch immer das gleiche Verfahren: Ein PIC steuert das Display, wobei ein Programm die darzustellenden Daten zusammen mit einigen Steuerbefehlen erzeugt. Die Verarbeitungsgeschwindigkeit spielt bei diesem Vorgang kaum eine Rolle. Also muss es doch recht einfach möglich sein, das eigentliche Display "abzusetzen" und die Daten seriell (zwar langsam, aber nur wenige Leitungen notwendig) zum Display zu senden, was die Anzahl der verfügbaren Portbits drastisch erhöhen würde.

Ok, diese Idee ist nicht neu, und es werden auch LC-Displays mit serieller Schnittstelle oder mit I2C-Bus angeboten. Nur diese Displays sind dermassen teuer (meist mehr als Faktor 10 im Vergleich zu den "klassischen" Displays), daß ich nicht einsehen kann, diesen Preis für ein paar eingesparte Portbits auszugeben. Dafür bekomme ich ja eine ganze Handvoll PICs (und damit Portbits)! Ähhh, Moment mal, genau das ist doch die Lösung! Ich verwende einen PIC zur Steuerung das Displays, und einen Zweiten für die "Applikation". Nur wie realisiere ich die Kommunikation zwischen den beiden Chips? Auf der Hardware-Ebene möchte ich möglichst wenige Leitungen (Portbits) verwenden. Pegelwandler (für "echtes" RS232) wären bei den zu erwartenden kurzen Entfernungen (mit ziemlicher Sicherheit erfolgt die Verbindung innerhalb eines Gehäuses) auch nicht notwendig. Gut, also TTL-Pegel/Leitungen. Ein "Eindrahtbus" (wie z.B. der "CAT"-Bus, den einige Funkgerätehersteller verwenden) währe vielleicht eine Lösung. Aber wie sieht es denn eigentlich mit dem I2C-Bus aus? Dieser Bus ist doch genau für solche Anwendungen (Kommunikation zwischen Bauteilen/Baugruppen) entwickelt worden? Nachdem ich mich in diese Thematik ein wenig eingelesen hatte, war mir klar, daß dies die Lösung für meine Probleme war. Die Vorteile des I2C-Bus liegen klar auf der Hand: Es handelt sich um einen Bus, daher ist die Kommunikation (im Gegensatz zu z.B. RS232) zwischen mehreren Geräten möglich (wer weiss, auf welche verrückten Ideen ich noch komme?). Ausserdem sind Chips (RAMs, EEPROMs, ...) mit einem I2C-Bus tatsächlich verfügbar (und noch nicht einmal extrem teuer). Und da es sich um einen synchonen Bus handelt, ist auch das Bus-Timing (zumindest auf der Seite des "Masters") unkritisch (-> keine Probleme mit "unerwarteten" Interrupts). Einen Nachteil habe ich jedoch auch gefunden: Dieser Bus lässt sich nicht "so einfach mal" mit einem PC bedienen (zumindest ist mir im Zuge meiner Recherchen nichts zu diesem Thema "begegnet"). Aber sollte das einmal notwendig werden, sollte ein "trickreiches" Programm für den seriellen Port (ähnlich meinem PicPrommer), oder einem "Seriell zu I2C-Umsetzer" in Form eines PICs kein unüberwindbares Problem darstellen. Also: "Ran an das Projekt": PIC-Funktionen für einen I2C-Bus schreiben, ein "Protokoll" zur vollständigen Steuerung eines LC-Display "erfinden", eine (möglichst zu Display passende) Hardware entwerfen und aufbauen, und das Ganze dann noch "zum Laufen bringen" ...

Im vorigen Absatz hörte sich die Aufgabe ja noch recht einfach an, nur leider hatte ich (mal wieder?) während der Entwicklung noch Ideen zur Erweiterung: Wenn ich schon ein LC-Display in einem Gerät einsetze, ist es doch auch sehr wahrscheinlich, daß dieses Gerät auch einige Schalter/Taster benötigt. Da der PIC, der das Display steuert, sowieso "fast nichts zu tun hat", kann er doch nebenbei noch ein paar Schalter/Taster abfragen, entprellen, und das Ergebnis via I2C-Bus zur Verfügung stellen ... Zusätzlich gestaltete sich das Testen/Debuggen des I2C-Handshakes als ziemlich umständlich und zeitraubend: Ein PIC-Programm in einem entsprechenden Simulationsprogramm zu analysieren, ist ja keine Kunst, nur in diesem Fall kommunizieren zwei Programme miteinander (und zeigen entsprechende "Reaktionen"), was diese Angelegenheit doch recht "knifflig" werden lässt. Falls es irgendjemand hinbekommen hat, zwei Instanzen von "gpsim" miteinander (über die Ports der simulierten PICs) kommunizieren zu lassen, würde mich das Verfahren sehr interessieren. Das von mir angewendete Verfahren, erst das Programm des I2C-Masters zu simulieren, daraus dann eine Datei erzeugen, die den Signalverlauf beschreibt, diese Datei (als "Stimulus") zur Simulation des "Slaves" (hier: des Display-Moduls) zu verwenden, Datei um die Reaktion des I2C-Slaves zu erweitern, damit wieder den Master simulieren, ... ist doch sehr umständlich kostet viel Zeit. Daher habe ich auch nicht alle möglichen Display-Befehle getestet -> Mögliche Fehler des PIC-Programms werden sich bei der Anwendung zeigen (und dann behoben werden).

Bei der Erstellung des Schaltplans mittels Eagle habe ich die Möglichkeit vorgesehen, bis zu acht Tasten/Schalter an das Modul anzuschliessen. Es waren - nach "Verbrauch" der zur Steuerung des Displays und des I2C-Busses notwendigen Bits - noch vier Ports frei, von denen ich drei zur Selektierung der Taste, und einen als "Zustandskontrolle" verwendet habe. Da es bestimmt einige Anwendungen gibt, die mit weniger als vier Schaltern/Tastern auskommen, ist der "Tasten-Multiplexer" als optionaler Schaltungsteil vorgesehen. In diesem Fall kann der Bauteilbedarf des Moduls um den 3zu8-Encoder vom Typ 74LS138 und fünf Dioden reduziert werden (das PIC-Programm bleibt gleich und es ist dem Programmierer der Applikation überlassen, sich die richtigen Bits für die entsprechende Tasten aus dem "Tastenstatus-Byte" herauszupicken). Die Idee, die Hintergrundbeleuchtung des Displays ebenfalls vom PIC (bzw. I2C-Bus) steuerbar zu realisieren (ggf. sogar mit "Dimmer"-Funktion), musste ich leider mangels Portbits aufgeben. Bei dieser Variante wären nur noch maximal zwei Schalter/Taster möglich gewesen, was - in meinen Augen - doch eine wesentliche Einschränkung dargestellt hätte. Vielleicht fällt mir ja auch noch eine trickreiche "Mehrfachbenutzung" eines des LCD-Steuersignale ein ... Bei der Erzeugung des Layouts habe ich mich an die Geometrie des LCD-Moduls gehalten, sodaß die komplette Platine direkt hinter dem Display montiert werden kann. Trotz intensiver Bemühungen ist es mir auch bei diesem Projekt leider nicht gelungen, alle notwendigen Leiterbahnen auf einer Leiterplattenebene unterzubringen -> die vier im Layout rot dargestellten Verbindungen müssen als Drahtbrücken ausgeführt werden.

Dies ist der Prototyp für eine Anwendung, bei der - außer dem Display - nur drei Taster benötigt werden. Daher ist der Tasten-Multiplexers (incl. der dazu gehörigen Dioden) nicht bestückt.

Um die Einbautiefe des Moduls gering zu halten, sind die Verbindungen zum LCD-Modul mit Drähten (anstatt Steckleisten/verbindern) ausgeführt. Als Abstandshalter finden zwei - auf das Display-Modul geklebte - Stückchen Rundmaterial aus Kunststoff Verwendung.

Die benötigten Taster habe ich auf einem Stück Leiterplattenmaterial montiert, welches gleichzeitig als Halter für das LCD-Modul dient und mittels Abstandsröllchen im Gehäuse montiert wird. Der Anschluß der Taster an der Prozessorplatine erfolgt in diesem Fall mit Hilfe einiger Stückchen Litze.

Schaltplan im "Eagle"-Format.
Layout im "Eagle"-Format.
Quellcode des PIC-Programms.
Quellcode der PIC-Funktionen zur Ansteuerung eines Displays von Typ "LCD162C".
Quellcode der PIC-Funktionen zur Ansteuerung eines (langsamen) I2C-Busses. (*)
Definition der verwendeten Befehlscodes). (*)
Assembliertes PIC-Programm im "Intel-HEX"-Code.

(*) Diese Programmteile werden sowohl für dieses Modul, als auch von einem "Applikationsprogramm" (in einem anderen PIC) benötigt.
Eine Portierung der I2C-Funktionen auf Microcontroller anderer Bauart/Hersteller ist von meiner Seite her nicht vorgesehen. Falls jemand eine entsprechende Portierung vorgenommen hat (um dieses Modul zusammen mit seinem "Lieblingscontroller" zu verwenden), würde ich mich über eine entsprechende Nachricht freuen und gerne einen Link zu der entsprechenden Seite setzen.

Hinweise für Nachbauwillige: Für den Bau dieses Moduls ist ein wenig Erfahrung mit der Herstellung einseitiger Leiterplatten und die Möglichkeit der Programmierung des Flash-ROMs von PICs erforderlich. Es handelt sich hierbei nicht um einen Bausatz, sondern eher um eine Anregung für eigene Konstruktionen. Alles, was ich dazu anbieten kann, befindet sich auf dieser Seite, d.h. Nachfragen nach fertigen Modulen, Bausätzen, Leiterplatten oder programmierten PIC-Controllern sind zwecklos -> Ich "produziere" ausschliesslich für den Eigenbedarf. Über Nachbauberichte würde ich mich freuen.

Für die Funktionalität und Nachbausicherheit dieses Moduls kann ich keinerlei Verantwortung übernehmen. Eine kommerzielle Verwertung des Schaltplans, des Layouts, oder des PIC-Programms ist nur mit meiner ausdrücklichen Genehmigung zulässig. Die PIC-Funktionen zur Ansteuerung des LC-Displays und des I2C-Busses unterliegen der "GNU Public License".

Startseite  Hardware  Rechtliches  Kontakt  Darstellung

HTML und Design: DK1RM erstellt: 02.01.2008 ·letzte Änderung: 16.08.20148