DK1RM - Hardware - Display mit I2C-Bus

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.