(176 * 208 pixel * 4096 Farben)

Wie kann ein Color-Graphik LCD-Display betrieben werden ohne dass man ein  Datenblatt der Display Controllers hat?

Diese Frage stellt man sich wenn man die relative großen und zudem recht preiswerten Ersatz-Farbdisplays der Nokia Serie 60 Cellular Phones betrachtet.

Mit etwas technischem Aufwand, viel Geduld und einer Portion Glück kann man es schaffen. Dabei stand in diesem Fall zunächst mehr die technische Realisierbarkeit im Vordergrund, als eine direkte praktische Anwendung. Das Projekt war ein "Selbstläufer". Von Ereignis zu Ereignis, auch wenn es einen Fehlschlag gab, zog es sich selbst  (und den Entwickler) immer weiter.

Nach mehrmonatiger Suche im Internet, nach vergeblichen Anfragen beim Handyhersteller , nach Anmeldung in und Befragung von zig Foren und nach erfolgloser Anzapfung aller restlichen Kanäle stand fest, dass definitiv kein Datenblatt des Displays auf zutreiben war.

Die einzigen verwertbaren Informationen zum gewünschten Display waren dem Service Manual zum Handy zu entnehmen. Das gesamte Service Manual mit Schaltplänen konnte aus dem Internet bezogen werden. Hieraus ergaben sich die wichtigsten Information zur Steckerbelegung und zu den elektrischen Eigenschaften wie Spannungsversorgung, Schaltschwellen und Timinginformationen. Weiter war daraus ersichtlich, dass die Ansteuerung des Displays parallel mit einem 8 Bit breitem Bus erfolgen muss und dass es diverse Steuersignale für den Datentransfer gibt. Dies waren also schon mal ausreichende Voraussetzungen um eine Art "Reverse Engineering" durchzuführen.

Die Idee war also, mit geeigneten Hilfsmitteln den Datenstrom zwischen Handy und Display aufzunehmen, daraus die Initialisierung zu erkennen und die Sequenz zum Darstellen von Zeichen, Texten und Bildern zu extrahieren. Insgeheim bestand die Hoffnung , anhand der Steuerkommandos doch noch den passenden Controller identifizieren zu können.

Da bei ebay die Displays des Nokia Handys 7650 sehr preiswert zu beschaffen waren und auch defekte Handys günstig angeboten wurden, wurde also zunächst ein komplettes , defektes Handy ersteigert. Glücklicher weise war das Handy schnell repariert und konnte für Versuche benutzt werden.

Das erste Problem ergab sich aus dem Anschluß eines Logikanalysators. Die Anzapfung der Signale war nur an den Lötstellen des Steckverbinders zum Displays möglich. Die extrem kleinen Abstände der SMD Steckverbindung erschwerten das Anlöten  der sehr dünnen Drähte. Diese wurden dann auf einen Pfostenstecker geführt, der auf die flexible Leiterplatte geklebt war. Nach erfolgreicher  Kontaktierung des LAs , konnten dann die ersten  Daten aufgezeichnet werden.

                                                                                

Das nächste Problem war die Bewältigung der anfallenden riesigen Daten- menge. Es durften ja nur die relevanten Daten lesbar dargestellt werden. Ein geeignetes Triggerprogram und vor allen Dingen die Aufzeichnung von transienten Daten sorgten dann schliesslich dafür, dass zuverlässige und sich stetig wiederholende Daten beim Einschalten bis zur Darstellung des Bildes am Display, am Analyzerbildschirm einstellten.

Daraus konnten dann schon die Kommandos von den Daten getrennt und auch
die Wartezeiten zwischen den Kommandos ermittelt werden. Weiter war es dann daraus auch möglich,  die Sequenzen zur Darstellung der Daten und das Ein-und Aus-Schalten des Displays identifiziert zu können.

Leider war die Suche nach Controllern die vergleichbare Kommandos benutzen und deren Datenblätter im Internet verfügbar waren, nicht erfolgreich.

An diesem Punkt stellte sich dann ernsthaft die Frage, ob das Projekt aufgegeben werden sollte oder ob man weitermacht. Was könnte man im schlechtesten Fall erreichen, wenn man nicht doch noch das Datenblatt des Controllers irgendwo findet ?

Aufgeben oder weitermachen ?

Wenn es gelingen sollte den aufgezeichneten Datenstrom mit Hilfe eines Mikrocontrollers anstelle der CPU aus dem Handy zum Display zu schicken und wenn dort dann ähnliches sichtbar sein würde, wäre ein Nutzung trotzdem möglich. Dann wüsste man wenigsten, welche Kommandos und Daten nötig wären um ein komplettes Bild vom Prozessor zum Display zu übertragen.
Anders als "normal", müsste man dann zunächst ein Abbild des Displays im Speicher des Mikrocontrollers erstellen und das dann als ganzes Bild so schnell wie möglich zur Anzeige schicken.

So wurde also als Ziel ins Auge gefasst zunächst zu erkunden, ob es möglich ist den Datenstrom wieder zum Display zu schicken und ein reproduzierbares Bild dort zu erzeugen.

Weitermachen !

Ein vorhandenes Evaluation Board mit einem MSP430F149 wurde schnell an das Display angeschlossen. Dabei war natürlich klar, dass es sich bei dieser Lösung nur um eine prinzipielle Machbarkeitsstudie handeln konnte, da der MSP430 einerseits kein ausreichend großes Daten-RAM hat (es würden 54912 Byte benötigt) und er andererseits mit 1.8V betrieben werden musste und deshalb keinerlei Ansprüche an Geschwindigkeit gestellt werden konnten.

                                                                          

Mit Hilfe eines Debuggers und des Logikanalysators ist es dann nach einiger Zeit tatsächlich gelungen, den aufgenommenen Datenstrom zum Display zu schicken und dort erst einmal bunte Punkte in regelmässigen Abständen zu erzeugen. Zu diesem Zeitpunkt war noch nicht ganz klar, in welcher Weise die Farbinformationen (12 bit pro Bildpunkt) übertragen werden musste. Durch empirische Versuche ist es dann schliesslich gelungen, das gesamte Display mit allen 176*208 Bildpunkten in einer einzigen  Farbe leuchten zu lassen. Langsam wurde auch die Anordnung der jeweils 4 bit für rot, grün und blau für geradzahlige und ungradzahlig Bildpunkte ersichtlich. Sodann war es kein großes Problem mehr die gewünschte Farbe einzustellen und sogar Farbbalken zu erzeugen.

Der Durchbruch

Jetzt fehlte nur noch , dass man etwas sinnvolles auf dem Display darstellt. Was lag näher als es zunächst mit einem Bild zu versuchen. Aber wie kann man das bewerkstelligen angesichts der knappen Recourcesen des Testaufbaus? Und wie stellt man es generell an ein Bild in eine Datei zupacken und den Inhalt über den Prozessor zum Display zu schicken um dort wieder das Bild zu erzeugen?

Letztendlich muss jeder Bildpunkt in seine RGB Komponenten zerlegt vor liegen. In diesem Fall müsste also das Bild in 12 bit pro Bildpunkt umgewandelt und in das Programm des MSP430F149 eingebunden werden. Dieser sollte dann wieder für die Ausgabe am Display sorgen.

Aber wie bekommt man die Farbinformationen  aus  dem BMP oder JPG file in das C Programm ? Wieder  war eine Recherche im Internet angesagt. Eine ganze Menge  von Bildconvertern ist dort auffindbar. Ein Converter kam den Vorstellungen  schon sehr nahe. Er konnte ein BMP Bild laden, es in die Farbkomponeten zerlegen und daraus eine C-Datei erstellen. Diese C-Datei würde dann zum eigentlichen Programm des MSP430F140 dazugebunden und schon wäre das Bild auf dem a Display zu  sehen.

So einfach war es natürlich nicht. Der Konverter lieferte zwar die RBG-Komponeten, aber nicht im richtigen Format. Da der Autor (unbekannt weil in Japan beheimatet) aber freundlicherweise die Quellcodes seines Programmes mitgeliefert hat, konnte dieses Problem aber dann auch gelöst werden. Allerdings ist der Converter in Delphi7 (Pascal) geschrieben, sodass sich erst mal Delphi7 beschafft werden musste und natürlich etwas Einarbeitung nötig war. Als  dann endlich ein Urlaubsfoto, der schiefe Turm zu Pisa, auf dem Display  erschien, war die Freude natürlich groß es geschafft zu haben.
                                                                                

Durch den recht knappen Programmspeicher konnten zwar nur ca 75 % des Bildes dargestellt werde, aber es reichte um den Mechanismus zu prüfen. Der Bildaufbau war auch noch sehr langsam (ca. 1.5 Sekunden pro Bildaufbau), aber der Duchbruch war geschafft und prinzipiell stand jetzt einer Nutzung des Displays nichts mehr im Wege, wenn man die Randbedingungen optimiert.

Die Optimierung

Wie sollten die Randbedingungen nun ausehen? Nach einigen Überlegungen kristallisierte sich folgendes Konzept für eine nutzbare Realisierung heraus:

Aufbau eines eigenen Controllers als Ersatz für den unbekannten Controller des Displays, basierend auf der Fähigkeit ein komplettes Bild zu übertragen.
 
- Aufbereitung des Bildes in einem 56KB größen Abbild des Bildspeichers
- Übertragung eines kompletten Bildes aus dem Bildspeicher zum Display   in
  20 bis 25ms.
- Unterstützung von mehreren fixen und einem ladbaren Charactersatz.
- Unterstützung von Graphic (Linien, Rechtecke,Kreise, etc)
- Unterstützung von Bildübertragungen vom Host
- Anschluss zur Aussenwelt optional über RS232(V24), RS232(TTL), SPI oder
  I2C
- Kommunikation zur Aussenwelt über eigenes, intelligentes Protokoll.
- Nutzung des auf dem Display befindlichen Joysticks, sowie Anschluss-
  möglichkeit für einige Tasten.

Die Frage nach dem Mikroprozessor der diese Aufgaben erfüllen kann wurde durch einige Forderungen bezüglich der Handhabbarkeit fast von selbst beantwortet.
Einmal musste des natürlich ein Prozessor sein, dessen Resourcen von der Geschwindigkeit, vom Programmspeicher und vom RAM-Speicher her geeignet waren. Auch musste er natürlich zu beschaffen sein. Weiter sollte ein C-Compiler billigst verfügbar und nicht zuletzt mussten Debugmöglichkeiten gegeben sein.
Die Wahl fiel auf ein ARM Derivat von Philips, dem LPC2106.

Realisierung des Controllers

Mit Hilfe des CAD Programs EAGLE wurde nur der Schaltplan und das Layout für eine Controllerplatine erstellt. Mühsam war dabei nur, dass für viel Komponenten erst die Schaltplansymbole und die Shapes erstellt werden mussten. Auch sollte die schwierige Kontaktierung des Display ordentlich gelöst werden. Es blieb also nichts anderes übrig , als einen passenden Steckverbinder zu suchen und ihn schliesslich bei einem Lieferanten in USA zu bestellen. Letztendlich war es dann soweit um die Platine als Prototyp fertigen zu lassen. Doppelseitig und durchkontaktierte Platinen mit Leiterbahnen dieser Stärke können nicht mehr mit vertretbarem Aufwand selbst gefertigt werden.

                                                                            
 
Um die nötige Zeit bis zur Lieferung der Platine zu nutzen, wurde inzwischen das SW-Konzept überlegt und mit der Programmierung begonnen.

Zunächst musste sich aber erst mit der Prozessorfamile ARM7 vertraut gemacht werden. Als ARM C-Compiler wurde der vom MSP430 bereits bekannte Imagecraft Compiler benutzt. Die Beta Version für den ARM wurde gerade zum richtigen Zeitpunkt fertig. Zum Testen des Programms stand dann auch ein kommerzieller JTAG Debugger zur Verfügung, ohne dessen Hilfe das Projekt sicherlich nicht so reibungslos zuendegebracht werden konnte.

Für die Graphic und die Characterdarstellung wurde auf eine SW von Fabian Thiele (KS0108, www.apetech.de) zurückgegriffen. Diese SW konnte natürlich nicht eins-zu-eins übernommen , sondern musste den hier nötigen Gegebenheiten angepasst werden. Der große Vorteil ist jedoch, dass die Fontsätze nicht händisch erzeugt werden  müssen, sondern mit dem GLCD-FontCreator2 (JAVA Tool, auch von Fabian Thiele,www.apetech.de) erstellt werden können und so dem Anwender höchste Individualität gegeben ist.

Nach vielen Stunden Arbeit (meist bis spät in die Nacht) waren dann die Grundfunktionen fertig programmiert und konnten getestet werden sobald die HW verfügbar war.

Wie geplant kamen dann auch nach knapp 14 Tagen die Musterplatinen. Diese wurden eilends bestückt und in Betrieb genommen. Natürlich war die Schaltung nicht ganz fehlerfrei, sodass noch einige kleinere Korrekturen manuell nötig waren. Aber endlich konnte zum allerersten mal das erzeugt Programm mit Hilfe des Philips ISP Tools über die serielle Schnittstelle geladen werden. Später war diese Prozedur nur in Ausnahmefällen nötig, da das Programmieren des Flash-Speichers mit dem Programm dann bequem von Debugger aus erfolgen konnte.

                                                                             
Test des Ergebnisses

Ein Ergebnis der ersten Versuche war allerdings, dass die Übertragungzeit vom RAM-Abbild zum Display, nicht die gewünschte Geschwindigkeit erreichen konnte , wenn man diese Funktion in C programmiert hat. Also blieb nichts anderes übrig, als sich mit dem Assembler des ARM  zu beschäftigen und die Übertragungsroutine optimal in Assembler zu programmieren. Damit war es dann aber  möglich die geforderten 20 bis 25ms zu erreichen. Wobei jedoch eine geringe Übertaktung des Prozessors nur für die Zeit des Datentransfers nötig war.

Nachdem die Funktionen soweit mit dem Debugger getestet waren, mussten jetzt die einzelnen Funktionen natürlich auch von einem Host her auffrufbar sein. Dazu war es nötig sich noch ein Protokoll zu überlegt, das die Funktionen beschreibt und sie für den Host nutzbar macht. Als Host zum Testen bot sich natürlich ein PC an.

Dazu braucht man aber wieder ein Programm das auf dem PC läuft, welches die Funktionen kennt und auslöst.
Also wurde auf ein bestehendes Visual Basic Program aus einem früheren Projekt zurückgegriffen und dies für diesen Zweck modifiziert. Nach wieder mehreren Stunden Arbeit lief dann alles zur Zufriedenheit des Entwicklers.

Als Ergebnis der gesamten Bemühungen sind jetzt einige voll funktionsfähige Prototypen verfügbar, die nun auf ihren Einsatz in entsprechenden Applikationen warten. Wobei die Eigenschaften des Controllers, die Software und das Übertragungprotokoll sicherlich weiter verbessert werden können.

Fazit

Das ganze Projekt erstreckte sich alles in allem über ca. 5 Monate. Es zeigt , dass nicht immer der gerade Weg zum Ziel führt und man sich in Laufe der Zielnäherung mit vielen Dingen beschäftigen muss mit denen man gar nicht gerechnet hat. So waren Berührungspunkte mit Delphi7, Java, Visual Basic, C-Compilern, ARM-Assembler, ARM7 und MSP430 Prozessoren, Grapfikcontrollern, Logic-Analysatoren, Debuggern, Graphicformaten, Fontformaten, Fontgeneratoren und vielem anderem mehr gegeben.

Letztendlich war es aber ein erfolgreiches Projekt, aus dem man viel Erfahrung  und Erkenntnisse für weiter Projekte sammeln konnte.

Back to LCD7650