Hallo zusammen, 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. Danke und Gruß! Sebastian
Angehängte Dateien:
-
20250413_155514.jpg
170 KB
Sebastian E. schrieb: > 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).
Sebastian E. schrieb: > "unbekanntes" 2x16 LCD Ich würde mal ein bekanntes nehmen. Typisch ist die 1. Zeile an Adresse 0x00 und die 2. Zeile an 0x40.
> ein bekanntes nehmen 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..." Ein Datenblatt vom 6.1.2000: https://www.chipcad.hu/letoltes/adatlapok/ES16201REF.pdf Dito vom 20.3.2001 https://www.alldatasheet.com/datasheet-pdf/view/130865/ETC1/ES16201GP.html Den Hersteller gibt es noch, kennt das natürlich nicht mehr: https://www.edtc.com/products/product-catalog/
Eventuell ist ja garnicht das Display sondern der Folienleiter defekt. Auf den Foto sieht es so aus, wie die Billigvaiante aus Aluminium.
Kann es sein, dass der Daten-Übernahmeimpuls einfach die falsche Polarität hat, sodass das erste Zeichen erst an der zweiten Position eingespeichert wird? Die Standardbreite (Reichelt nennt es Länge) scheint 80mm zu sein, im alten Datenblatt steht 68mm. Reichelt hat ein einziges mit 65mm: https://www.reichelt.de/de/de/shop/produkt/lcd-modul_2x16_h_4_7mm_ge_gn_m_bel_-197520#closemodal
:
Bearbeitet durch User
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.
Muss man eben nach einem anderen Display mit NT7603 Controller schauen.
https://ww1.microchip.com/downloads/en/DeviceDoc/NT7603_V2.3.pdf Ist der nicht zum "Industriestandard" kompatibel? 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? Anscheinend hat die Microchip aufgekauft https://www.buydisplay.com/download/ic/NT7603.pdf Ursprünglich "Novatek"
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Ist der nicht zum "Industriestandard" kompatibel? Man würde darauf im Datenblatt hinweisen.
Christoph db1uq K. schrieb: > https://ww1.microchip.com/downloads/en/DeviceDoc/NT7603_V2.3.pdf > Ist der nicht zum "Industriestandard" kompatibel? Eventuell auch nach alten Versionen schauen. Die Busy-Flag Abfrage war früher "langsamer" (40µs, wie alles andere auch), z.b. https://lcdproduct.com/wp-content/uploads/2022/05/NT7603.pdf, Seite 14 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.
Bruno V. schrieb: > 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.
Sebastian E. schrieb: > - DRAM Adresse muss bei 0x80 starten (1. Zeile, 1. Zeichen), Zweite > Zeile bei 0xC0 Das machen doch alle 'kompatiblen' Controller. Peter D. schrieb: > Ich würde mal ein bekanntes nehmen. Typisch ist die 1. Zeile an Adresse > 0x00 und die 2. Zeile an 0x40. Eben nicht, da kann man seinen eigenen Zeichensatz ablegen. Ich würde auch auf Probleme beim Timing tippen -> Oszilloskope.
Jörg W. schrieb: >> 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.
Hi
>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.
MfG Spess
> 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? ---------------- H. H. schrieb: > 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.
Sebastian E. schrieb: > Also kann der verschobene Text ja nicht mehr mit der Adresierung zu tun > haben, sondern eher mit dem Timing. Vermute ich auch. Man kann ja mal einen kleineren Quarz probieren. Sebastian E. schrieb: > 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? So wirds sein.
> 80 ... 8F > C0 ... CF / > 00 ... 0F > 40 ... 4F Das ist binär beides das gleiche wenn Bit 7 das Kommando signalisiert.
Hast Du mal nachgesehen, ob sich der µC auslesen lässt?
Sebastian E. schrieb: > 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!
Angehängte Dateien:
-
LCD_User_def_char.png
38 KB
Sebastian E. schrieb: > 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? ciao gustav
:
Bearbeitet durch User
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 ...
Hugo H. schrieb: > 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'.
Mi N. schrieb: > 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.
:
Bearbeitet durch User
Mi N. schrieb: > Sebastian E. schrieb: >> 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.
Rainer W. schrieb: > 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'. Sebastian E. schrieb: > Um mal ein Ende zu finden, würde ich ... Besser ohne Konjunktiv - mir fehlen immer noch Antworten. Ferner: Was zeigt denn das Display bei nachfolgen Ausgaben an? Immer der gleiche Versatz?
Angehängte Dateien:
-
20250423_160430.jpg
240 KB
Moin, hier mal ein update der ganzen Geschichte. 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. Display: https://display-elektronik.de/filter/DEM16204FGH.pdf Controller: https://newhavendisplay.com/content/app_notes/ST7032.pdf
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.
Harald A. schrieb: > 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.
Mi N. schrieb: > Das macht er doch beharrlich nicht :-( 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
20250427_133023.jpg
160 KB
Harald A. schrieb: > Mi N. schrieb: >> Das macht er doch beharrlich nicht :-( > > 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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.