bei uns in der Sternwarte ist bei unserer Teleskop-Steuerung (Gemini Pulsar) die Handbox ausgefallen. Nach der Fehlersuche hat sich herausgestellt, dass das Display defekt ist.
Im Rahmen der Fehlersuche und des reverse Engineering habe ich ein "unbekanntes" 2x16 LCD aus der Bastelkiste drangetüddelt. Wie auf dem Foto zu sehen, wird ein Text angezeigt, aber verschoben. Reproduzierbar immer an der Stelle. Ich vermute hier ein Problem mit dem Speicherbereichen des DRAM im Display und nicht mit dem Timing.
Das originale Display ist ein "Emerging Display ES16201", welches natürlich nirgens zu finden ist. Selbst das Datenblatt gabs nur auf einer Archiv-Seite.
Jetzt bin ich auf der Suche nach Ersatz, eventuell auch mit etwas Bastelaufwand.
Es kommt auf diese Features an:
2x16 Zeichen mit paralleler Ansteuerung (8-Bit)
"Chip on Glas" oder ähnlich kompakte abmessungen (Das Feld-Wald-Wiesen Display passt von der Breite nicht rein)
Idealerweise Transreflektiv
DRAM Adresse muss bei 0x80 starten (1. Zeile, 1. Zeichen), Zweite Zeile bei 0xC0
Der letzte Punkt ist vermutlich das Problem an dem verschobenen Text. Kann es sein, dass die "Standard" Displays an anderer DRAM adresse starten?
Was gibt es noch an Herstellern von Displays, wo man Einzelstücke bekommt? Ich habe bisher u.a. bei Winstar, Newhaven, Wandsiplay, Sinda gesucht.
Gibt es eine Möglichkeit den verschobenen Bereich zu korrigieren?
Also ohne einen zusätzlichen µC, der das Adaptiert.
Am Ende ist das ganze eine Aufwandsabschätzung ob es sich lohnt die alte Steuerung zurück ins Leben zu holen, oder man nach einer neuen Steuerung schauen muss, u.a. auch im DIY Umfeld wie OnStep oder TeenAstro.
Vielleicht habt ihr ja noch eine passende Idee oder einen Hinweis den ich jetzt übersehen habe.
Gibt es eine Möglichkeit den verschobenen Bereich zu korrigieren?
Ist denn die Firmware im 8051 da drauf auslesegeschützt? Ansonsten könnte man es dort an der Quelle korrigieren.
Also ohne einen zusätzlichen µC, der das Adaptiert.
Ein kleines FPGA, hätte ich jetzt gesagt. Eine MCU wird zu langsam sein.
Aber FPGAs gibt's natürlich auch wirklich sehr klein inzwischen, Lattice ICE40 zum Beispiel. Die kleinsten davon sind gerade mal 2,5 mm x 2,5 mm groß (und sie haben Flash eingebaut).
dazu gibt es einen Satz von Karl Valentin:
"Ein Bekannter von mir hat gesagt ... also eigentlich ein Bekannter von einem Bekannten, den ich nicht kenne ... also ein Unbekannter von mir hat gesagt..."
Kann es sein, dass der Daten-Übernahmeimpuls einfach die falsche Polarität hat, sodass das erste Zeichen erst an der zweiten Position eingespeichert wird?
Ich würde mal probieren mit einem 4*20 Display, evtl. passt es dann in Zeile 3+4. Schaut mir zumindest von den Adressen her so aus.
Viel Erfolg beim probieren! Solche HD44780 kompatiblen Displays gibt es ja doch noch recht günstig. Und von der Mechanik her, schlimmstenfalls mit 3D-Drucker was machen lassen. Bei Einzelstück sehe ich FPGA-Einarbeitung als overengineered.
Die 44780 sind leider nicht alle identisch, hatte selbst mal ein Problem mit der Holdtime. Da aber sind die Zeichen gehüpft und nicht fest um eine Stelle verschoben.
Eine "Data Write"-Operation dauert 40µs max., das ist auch für einen 8051 ziemlich lange, aber das ist bei den Textdisplays normal. Vielleicht ist in der Software etwas faul, das beim alten Display nicht aufgefallen ist?
Keine Ahnung ob das früher ein Schreibfehler war, oder ob es wirklich "unterschiedlich schnelle" Versionen gibt. Jedenfalls war ich wohl nicht der einzige, der am Anfang seiner Karriere an manchen Stellen ein paar NOPs eingefügt hat.
Keine Ahnung ob das früher ein Schreibfehler war, oder ob es wirklich
"unterschiedlich schnelle" Versionen gibt. Jedenfalls war ich wohl nicht
der einzige, der am Anfang seiner Karriere an manchen Stellen ein paar
NOPs eingefügt hat.
Die Unterschiede gibt es definitiv. Gerade ältere Displays sind schnarchlangsam und bei Kälte erst recht. Busy-Flag auswerten ist da kein Luxus.
Also ohne einen zusätzlichen µC, der das Adaptiert.
Ein kleines FPGA, hätte ich jetzt gesagt. Eine MCU wird zu langsam sein.
Dazu müsste sich man das Timing ansehen. Wir haben das hier mal für einen Ersatz gemacht. Zwischen Origianlcontroller und Display hing dazu ein LPC824. Das Timing war da aber auch ein Stück weg vom theoretischen Minimum eines HD44780. Mit einem schnelleren kleinen ARM aber sicher kein Problem das auch mit den Minimaltimings (tcycE 1000ns) ohne FPGA hinzubekommen.
Eben nicht, da kann man seinen eigenen Zeichensatz ablegen.
Eben doch. Du verwechselst DD-RAM und CG-RAM. Die eigenen Zeichen werden im CG-RAM abgelegt. Die Display-Daten im DD-RAM. Und der hat beim 16x2 die Adressen 00H und 49H.
Ein kleines FPGA, hätte ich jetzt gesagt. Eine MCU wird zu langsam sein.
Wenn es nur das Daten-Interface des Displays ist, sollte man das mit einem AVR schaffen. Pin-Change-Interrupt auf den Enable, darin alle 9 Datenleitungen (8 Bit und R/S) lesen und in einen Puffer schreiben, diesen Puffer kann man dann in der restlichen Zeit verarbeiten (z.B. Adressen anpassen) und an's Display weiterschicken. Das sind ja keine hohen Datenmengen, die da drüber fließen.
40µs sind 25kHz, bei einem AVR mit 16Mhz hat man 640 Takte zwischen zwei Impulsen, das ist eine ganze Menge Zeit für so einen Controller.
Moin!
Erstmal vielen Dank für die vielen Kommentare und Ideen.
Wollte gestern schon antworten, aber wir hatten einen großen Internet-Ausfall.
Die Idee mit dem externen anpassen der Ansteuerung ist wohl eher eine zeitaufwändigere Geschichte. Aber die Idee gleich ein FPGA (oder CPLD) zu nutzen finde ich gut. Einfachhalber würde ich dann eher das "MAX1000" Maker-Board einsetzen, da ich den MAX10 und die Altera/Intel Toolchain kenne.
Den Atmel Controller aus der Handbox auszulesen klingt spannend. Die Idee ist mir bisher nicht gekommen. Bei der Bezeichnung auf dem Atmel Controller hätte ich nicht mit einer ISP Fähigkeit gerechnet.
Mit den Adressen für die Zeichen wäre ich jetzt auch auf dem Stand, dass normalerweise die Zeichen bei 0x00 (oben links, erstes Zeichen) starten.
Bei dem originalen Display ist es:
ES16201GP
Controller: NT7603
80 ... 8F
C0 ... CF
Bei dem anfangs "unbekannten Display" (Hätte vorher mal auf die Idee kommen sollen da nach dem Typ zu gucken ... :) )
STC2E16DRG
Controller: NT3881
80 ... 8F
C0 ... CF
Also kann der verschobene Text ja nicht mehr mit der Adresierung zu tun haben, sondern eher mit dem Timing.
Was mit dann noch aufgefallen ist:
Ein "Displaytech" 2x16 LCD hat die Adressen:
00 ... 0F
40 ... 4F
Aber, im Datenblatt steht zur Ansteuerung:
SET DD RAM ADDRESS:
Data Bit: |7|6|5|4|3|2|1|0|
|1| DD Ram Addr |
Kann es sein, das die unterschiedlichen Adressbereiche einfach daher kommt, das manche Hersteller das Bit-7 mit in den Adressbereich eingerechnet haben und manche nicht?
Muss man eben nach einem anderen Display mit NT7603 Controller schauen.
Basically, das ist der Plan.
Nur sind die 2x16 LCDs nicht mehr so gefragt und daher selten. Moderne vertreter kommen mit I2C statt 6800-Interface. Und dann eines zu finden was mechanisch und elektrisch passt und genau den Contrller hat ist halt nicht einfach.
Kann es sein, das die unterschiedlichen Adressbereiche einfach daher
kommt, das manche Hersteller das Bit-7 mit in den Adressbereich
eingerechnet haben und manche nicht?
Aber die Idee gleich ein FPGA (oder CPLD)
zu nutzen finde ich gut. Einfachhalber würde ich dann eher das "MAX1000"
Maker-Board einsetzen, da ich den MAX10 und die Altera/Intel Toolchain
kenne.
Bei jedem kleinen Problem gleich in die CPLD-Kiste zu greifen, ohne das Problem erkannt zu haben? Das ist der falsche Ansatz.
Was mir nicht ganz klar ist: Ist bei dem gezeigten Bild der Text in der 1. Zeile um 15 Zeichen verschoben oder sollte er in der 2. Zeile erscheinen? Mit einem Adressversatz von >= 64 (0x40) Zeichen wäre Beides nicht zu erklären.
Auch die letzte '0' von '1.150' scheint normalerweise nicht sichtbar zu sein.
Hast Du vielleicht einen Verdahtungsfehler, daß 'E' noch zusätzlich Impulse bekommt?
Erst messen, dann handeln!
das manche Hersteller das Bit-7 mit in den Adressbereich
eingerechnet haben und manche nicht?
That's it.
Das eine ist der Control set.
Da muss Adresse der Stelle, wo das Zeichen dargestellt werden soll, hinzuaddiert werden.
Dann gibt es in der Programmierungsvariante die dezidierte Adressenangabe vor jeder Datenausgabe. Und bei einigen den Control set Einstellung mit automatischem Addieren.
Entry/Shift Mode Set:
Cursor Wandern nach rechts oder links oder nicht.
Meine Empfehlung:
Schau mal den Initaialisierungs-String an.
Wie sieht der aus?
Wo Du die Drähtchen alle so hübsch hast - hast Du einen LA?
Es gibt (zu manchen ... auch Clones) Auswertungs-SW, welche auch HD44780-Signale auswerten kann.
Da könnte man vielleicht schauen, wo genau es klemmt ...
Wo Du die Drähtchen alle so hübsch hast - hast Du einen LA?
Es gibt (zu manchen ... auch Clones) Auswertungs-SW, welche auch
HD44780-Signale auswerten kann.
Bevor alle Leitungen an einen LA angeschlossen sind, hat man diese mit einem Skope doch schon 'durchgeklingelt' und mehr gesehen als nur '0' und '1'.
Bevor alle Leitungen an einen LA angeschlossen sind, hat man diese mit
einem Skope doch schon 'durchgeklingelt' und mehr gesehen als nur '0'
und '1'.
Wenn man sich einmal davon überzeugt hat, dass es nicht nötig ist, auf mehr als '0' und '1' zu gucken, ist ein LA mit passendem Dekoder schon sehr hilfreich.
Eine komplette Initialisierungssequenz in Bytebreite mit dem Oszi 'durchzuklingeln' macht keinen Spaß, wenn das Oszi keinen LA änhält.
Aber die Idee gleich ein FPGA (oder CPLD)
zu nutzen finde ich gut. Einfachhalber würde ich dann eher das "MAX1000"
Maker-Board einsetzen, da ich den MAX10 und die Altera/Intel Toolchain
kenne.
Bei jedem kleinen Problem gleich in die CPLD-Kiste zu greifen, ohne das
Problem erkannt zu haben? Das ist der falsche Ansatz.
Genaugenommen gehört ja der eine Satz vor dem zitierten dazu: "Die Idee mit dem externen anpassen der Ansteuerung ist wohl eher eine
zeitaufwändigere Geschichte."
Damit relativiert sich ja meine Aussage. Das ich die Idee gut finde bezog sich eher allgemein darauf für solche Problemstellen, wo etwas angepasst werden muss, auch über FPGA/CPLD nachzudenken. Bei meinem konkreten Fall ist das eher eine der letzten Lösungen.
Um mal ein Ende zu finden, würde ich wie empfohlen die Timings aufnehmen und schauen, ob ich ein passendes Display dazu finde. Idealerweise eines, was auch mechanisch passt.
Plan B wäre dann tatsächlich die komplette Teleskopsteuerung durch was modernes zu ersetzen.
Eine komplette Initialisierungssequenz in Bytebreite mit dem Oszi
'durchzuklingeln' macht keinen Spaß, wenn das Oszi keinen LA änhält.
Der Datenbus ist doch in Ordnung, wenn ich das Foto sehe. Bleiben also nur RS RW und E, bei denen zu prüfen ist, ob keine VCC/2 Pegel auftreten und keine 'Trabantenimpulse'.
Ich habe inzwischen ein zweites LCD mit anderem Controller aus der "Bastelkiste" angelötet. Dies zeigt sporadisch den Text an der richtigen Stellen.
Danach habe ich das erste "Basteldisplay" wieder angelötet. Und auch hier konnte ich selten(er) sehen, dass der Text passend angezeigt wird. Auch durch häufiges kurzes aus-und-ein-schalten konnte die Textposition zwischen richtig und verschoben (immer um die gleiche Anzahl an Stellen) verändert werden.
Vermutlich ist hier einfach das Timing beim Power-Up nicht sauber. Ich meine mich erinnern zu können, das ich selbst mal so ein Problem hatte, als ich meine ersten Berührungspunkte mit einem 2x16 Dsiplay hatte. Das war noch zu der Zeit als es keine fertigen Bibliotheken dafür gab und ich die Initialisierung selbst nach Datenblattangabe in C umsetzen musste. Auf einem ATtiny2313. :-)
Ich habe dann das Display auf bester Bastler-Art mit Metallwinkeln und Pappe halbwegs mechanisch Stabil an die Controller-Platine befestigt und in unserer Teleskop-Kuppel an die Steuerung angeschlossen. Denn nur wenn der Hauptcontroller mit der Handbox verbunden ist läuft das Programm auf dem "Dsiplay-Controller" weiter. Und siehe da, alle nachfolgen LCD Ausgaben passten. (Siehe Foto)
Nun habe ich ein Display gefunden, welches zumindest schon mal mechanisch in das Gehäuse passt: Display Elektronik DEM16204FGH.
Das Display hat einen "UCi7032c" Controller mit rausgeführten Chip Select Pin. Der Controller hat die gleichen Commands wie die üblichen HD44780 Kandidaten.
Das Datenblatt von Display Elektronik ist da sehr unvollständig und sieht eher zusammengebastelt aus. Ich hoffe das Datenblatt zum Sitronix SI7032 ist da vergleichbar.
Da heißt es zum Chip Select "Chip select in parallel mode and serial interface (Low active). When the CSB in falling edge state (in serial interface), the shift register and the clock counter are reset."
Ich gehe davon aus, das ich das Signal nur auf Low ziehen muss und sich das Display dann "normal" verwenden lässt.
Man könnte die Signale der Haupt-CPU mit einem einfachen Logikanalyzer aufnehmen und schauen, wie die Entwickler es damals gelöst haben. Das dürfte recht statisch vom Timing her sein. Dann eine kleine dünne Zwischenplatine mit Folienstecker und Pinleiste entwerfen, die die Signale einliest und artgerecht wieder ausgibt. Mein Favorit für diesen Job wäre ein ATTiny816MNR (4x4mm), braucht nur einen Kondensator als Außenbeschaltung und ist mit einer 1-Draht UART programmierbar. Dazu noch vollständig Arduino-unterstützt, was die Programmentwicklung zum Kinderspiel macht. Als Werkzeug braucht man nur einen beliebigen UART-Umsetzer, 1 Diode, 1 Widerstand.
Man könnte die Signale der Haupt-CPU mit einem einfachen Logikanalyzer
aufnehmen und schauen,
Das macht er doch beharrlich nicht :-(
Das sproradisch funktionierende Display wird zu langsam getaktet sein, sodaß es von der init-Routine zu früh angesprochen wird.
Wenn man das Problem lösen möchte, läßt sich die Taktfrequenz durch Änderung eines Widerstandes (Rf) erhöhen.
Beharrlich nicht habe ich da nicht rausgelesen, wenn dann "am liebsten nicht".
Oft ist es ja auch gerade der initiale Aufwand, den man scheut. Mittlerweile liebe ich dafür den genannten Controller, die 1-Draht Schnittstelle und die Arduino-Unterstützung minimieren den initialen Aufwand gegen Null. Und man muss für die Programmierung nichts kaufen, was man als Elektroniker nicht eh schon da hätte.
Beharrlich nicht habe ich da nicht rausgelesen, wenn dann "am liebsten
nicht".
Das macht er aufgrund von akuten Zeitmangel nicht.
Und eine anpassung des Timings durch einen externen Controller oder PLD wäre nicht sinnvoll. Die Zeit würde ich dann eher in den Aufbau einer neuen Teleskopsteuerung stecken.
Glücklicherweise war das neu bestellte Display "DEM16204FGH" schon am Wochenende da und ich konnte testen. Anschluss nach "Schema-F" hat nicht geklappt. Eine kleine Falle ist die Displayspannung Vo. Diese muss zwischen 2,7 V und 7 V liegen, was ich erst nach lesen des Datenblattes vom Dsiplay-Controller gefunden habe. Nach umverdrahten von 0 V auf 5 V lief es tadellos. Auch der Text startete immer an Position 0x0.
Machanisch passte es dann auch noch gut ins Gehäuse.
Somit ist das Projekt nun glücklicherweise positiv beendet.
Danke nochmal an alle Helfer für die viele Tipps und Ideen!
20250413_155514.jpg
(170 KB)
