Hallo Zusammen! Ich habe bei einem Gerät (Lexicon MRC) das Display ausgetauscht und zwei unterschiedlichen Displays ausprobiert. Das grüne Display funktioniert einwandfrei. Beim blauen Display gibt es nach ein paar Sekunden Probleme siehe Fotos. Das heisst dass nach dem einschalten die Zeichen vorerst korrekt angezeigt werden, nach einigen Sekunden spielt die Anzeige jedoch verrückt. Komisch ist auch dass wenn ich einen Wert verändere wieder alles korrekt angezeigt wird. Nach ein paar Sekunden fängt das Problem jedoch wieder an. Hat jemand einen Hinweis woran das liegen könnte? Grünes Display = DEM 24252 SYH-LY/A Blaues Display = W242B-NLW Vielen Dank für Eure Hinweise
Max M. schrieb: > Hat jemand einen Hinweis woran das liegen könnte? Das wird ein Timing-Problem sein. Das eine Display geht so noch gerade, das andere nicht. Oliver
Max M. schrieb: > Hat jemand einen Hinweis woran das liegen könnte? Vielleicht liegt es an der Schaltung (Logikpegel, Versorgungsspannung, offene Pins).
Oliver S. schrieb: > Max M. schrieb: >> Hat jemand einen Hinweis woran das liegen könnte? > > Das wird ein Timing-Problem sein. Sind das immer noch R/C Oszillatoren?! Wärm das Display mal an, wenn's besser oder schlechter wird, is es definitiv ein Timing-Problem. Die Wartezeiten auf die Befehlsabarbeitung sind zu kurz, nehm ich mal an.
Die Stromversorgung würde ich auch als erstes mit einem Oszilloskop prüfen. Danach die Qualität der Signale (Pegel und Flanken-Steilheit). Bei den HD44780 kompatiblen Display habe ich die Erfahrung gemacht, daß viele erheblich schneller sind, als das Original. Viele im Netzt veröffentlichte Code-Beispiele halten sich nicht vollständig an das geforderte Timing, ohne daß es dem Autor aufgefallen ist. Da kann es durchaus passieren, das ein bisher bewährter Programmcode an einem neuen (langsamen) Display plötzlich doch nicht mehr so stabil läuft, wie bisher. Ergo: Timing ausmessen und mit dem richtigen Datenblatt vergleichen. Nicht nur auf einzelne Bytes achten, sondern auch die geforderten Wartezeiten nach Kommandos kontrollieren. Das teht am Besten mit einem Logic Analyzer, zur Not aus dem Quelltext heraus lesen.
:
Bearbeitet durch User
Hallo Zusammen! Vielen Dank für Eure Hinweise und Tipps! Na dann werde ich mich mal an die Arbeit machen und als erstes Datenblätter studieren. Nochmals Danke und Happy Weekend
Max M. schrieb: > Beim blauen Display gibt es nach ein paar Sekunden Probleme > siehe Fotos. Was heißt das? Macht das Display das von sich aus oder passieren die Probleme, während das Gerät mit ihm kommuniziert? Die Datenblätter nützen dir nur wenig, solange du nicht misst, was in deinem Gerät passiert. Als erstes wäre es daher gut, zu gucken, was an Messtechnik zur Verfügung steht, um den Dingen auf den Grund zu gehen.
Rainer W. schrieb: > ... um den Dingen auf den Grund zu gehen. Und nachdem Datenblaetter studiert (*1) und das Timing des Geraets vermessen wurde (*2), stellt man fest, dass man daran ohnehin nichts aendern kann. Also baut man wieder das Display ein, dass funktioniert. Man haette sich 1. und 2. also sparen koennen.
Motopick schrieb: > Also baut man wieder das Display ein, dass funktioniert. > > Man haette sich 1. und 2. also sparen koennen. ... und gelernt hätte man rein gar nichts.
:
Bearbeitet durch User
Rainer W. schrieb: > Was heißt das? > Macht das Display das von sich aus oder passieren die Probleme, während > das Gerät mit ihm kommuniziert? Wie ich geschrieben habe, ich schalte das Gerät ein, Anzeige einwandfrei, nach ein paar Sekunden werden nach und nach die Zeichen verändert ohne dass ich was mache.
Oliver S. schrieb: > Max M. schrieb: >> Hat jemand einen Hinweis woran das liegen könnte? > > Das wird ein Timing-Problem sein. Das eine Display geht so noch gerade, > das andere nicht. Da das Schreiben klappt, wird es wohl nicht am Timing liegen. Der RAM-Inhalt 'löst' sich wohl auf - nach und nach, wie beschrieben. Vielleicht einfach nur kaputt ;-)
Max M. schrieb: > Wie ich geschrieben habe, ich schalte das Gerät ein, Anzeige > einwandfrei, nach ein paar Sekunden werden nach und nach die Zeichen > verändert ohne dass ich was mache. Unter der Annahme dass das der Controller nicht ständig den selben Inhalt an das Display sendet (was mit einem Logikanalyzer der Oszi zu überprüfen wäre), müssten es demnach unpassende Logikpegel oder Störungen und weniger Timing sein. Schaltet der Controller eventuell bei Inaktivität die Ausgänge Hochohmig? Vielleicht hilft einen Pull-Down am Enable Pin hinzufügen?
Max M. schrieb: > DEM 24252 SYH-LY/A Controller HD44780 > W242B-NLW Controller HD44780 / ST7066 kompatibel Wenn man das liest, ist Vorsicht geboten. Befehlskompatibel heißt nicht timingkompatibel. Deswegen haben andere schon geflucht.
Mi N. schrieb: > Da das Schreiben klappt, wird es wohl nicht am Timing liegen. Vielleicht doch; sobald der Displaycontroller auf Betriebstemperatur ist, kommt ihm irgendne Flanke zu früh. Test: Displayrückseite vorsichtig erwärmen, dann Gerät einschalten. Nächster Test: Displayrückseite mit Kältespray abkühlen, verschwindet der Effekt wieder?
Rainer W. schrieb: > Motopick schrieb: >> Also baut man wieder das Display ein, dass funktioniert. >> >> Man haette sich 1. und 2. also sparen koennen. > > ... und gelernt hätte man rein gar nichts. Wie es scheint, ist der TO meiner Argumentation gefolgt. :) So ein "korruptes" Display ist mir aber auch schon untergekommen. Das war aber ein Grafisches in einem MP3-Player. Mein Lernerfolg damals war, dass Flashspeicher bei zu niedriger Betriebsspannung seinen Inhalt korrumpiert... Sehr viel spannender verlief dann die Suche nach der Recoverysoftware. Nach gefuehlten 2 Dutzend Fehlversuchen fand sich dann eine passende. Ansonsten ein schoenes Stueck Hardware dessen Kern auf dem guten™ Motorolla 56000 basiert. Mit ein wenig Aufwand haette Mann auch noch ein nettes Effektgeraet auf dem Stick laufen lassen koennen. AD- und DA-Wandler waren ja auch schon da... Eigenltich muessten die Hersteller von solchen Flashspeichern ihren Produkten noch einen Spannungssupervisor beistellen oder am besten in ihre Produkte integrieren, um solches "Fehlverhalten" sicher auszuschliessen. Unter anderem sind z.B. auch Notebooks davon betroffen. Frohen Advent!
Harald K. schrieb: > Vielleicht doch; sobald der Displaycontroller auf Betriebstemperatur > ist, kommt ihm irgendne Flanke zu früh. Flanken kommen nur, wenn der µC mit dem Display kommuniziert. Die Frage von gestern ist immer noch offen: Rainer W. schrieb: > Macht das Display das von sich aus oder passieren die Probleme, während > das Gerät mit ihm kommuniziert?
Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten zeigen, legt nahe, daß das kein Fehler ist, den das Display alleine, ohne Ansteuerung hinbekommt. Also halte ich Deinen Vorschlag, das Display "solo" zu untersuchen, für einen nachrangigen Nebenschauplatz. Ich halte es für erheblich wahrscheinlicher, daß hier ein Timing-Problem vorliegt, und der Datenbus am Display nicht zu dem Zeitpunkt stabil ist, zu dem das Display die anliegenden Daten übernehmen will (das sollte eine gewisse Zeit nach der fallenden Flanke von E geschehen). Im Datenblatt des HD44780 (https://www.sparkfun.com/datasheets/LCD/HD44780.pdf) ist auf Seite 58 ein Timingdiagramm abgebildet, und die kritischen Zeiten beim Schreibzugriff sind - tcycE (Zykluszeit eines kompletten Zugriffs) - tAS (Signale RS und R/!W stabil vor steigender Flanke von E) - tEr (Anstiegszeit steigende Flanke von E) - tDSW (Daten stabil auf Datenbus vor fallender Flanke von E) - tH (Daten stabil auf Datenbus nach fallender Flange von E) Die typischen Werte dazu listet das Datenblatt auf Seite 52 auf: tcycE min 500 ns (d.h. maximal 2 MHz Takt auf E) tAS min 40 ns tEr max 20 ns tDSW min 80 ns tH min 10 ns Das sind die Werte des Originals, im vom Original vorgesehenen Betriebsspannungsbereich. Da natürlich sehr viele Displays nicht mehr mit dem Original, sondern nur "kompatiblen" Nachbauten betrieben werden, ist das nicht in der Erde festgemeißelt; idealerweise sollte man sich die betreffenden Werte im Datenblatt des realen Controllers ansehen, was voraussetzt, daß man überhaupt herausfindet, welcher das ist (auf etlichen Displays ist nur der beliebte schwarze Klecks drauf). Weiterhin kann es Abweichungen durch geänderte Signalpegel geben. Die meisten neuzeitlichen Klone des 44780 funktionieren auch problemlos mit 3.3 V Versorgunsspannung, wenn man die Kontrastspannung entsprechend anpasst. Sie lassen sich aber auch im 5 V-Betrieb mit Spannungspegeln eines mit 3.3 V betriebenen µC ansteuern, nur kann es dann zu Verschleifungen kommen, weil eben High-Pegel erst später eine für den 44780 ausreichend hohe Spannung bekommen. Mir scheint hier der Einsatz eines Oszilloskopes angebracht zu sein, um zu prüfen, wie das vorgegebene Gerät überhaupt das Display ansteuert. Versorgungsspannung, Signalpegel und Timing.
Harald K. schrieb: > Die > meisten neuzeitlichen Klone des 44780 funktionieren auch problemlos mit > 3.3 V Versorgunsspannung, wenn man die Kontrastspannung entsprechend > anpasst Das war schon beim Original so. Selbst mit 5V Versorgung reichen Signale mit 3,3V. Harald K. schrieb: > Mir scheint hier der Einsatz eines Oszilloskopes angebracht zu sein, um > zu prüfen, wie das vorgegebene Gerät überhaupt das Display ansteuert. > Versorgungsspannung, Signalpegel und Timing. Ja
:
Bearbeitet durch User
Harald K. schrieb: > Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten > zeigen, Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau). Ein Display kann auch mal defekt sein. Hau weg den Schrott! ;-)
:
Bearbeitet durch User
Mi N. schrieb: > Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau). Gut, OK, ich hatte mich daran falsch erinnert. Mi N. schrieb: > Ein Display kann auch mal defekt sein. Sicher kann es das. Aber hast Du schon mal ein Display mit diesem bizarren Fehler gesehen? Gut, wir wissen auch nicht, ob das Display Neuware ist, oder ob der Threadstarter es irgendwo aus dem Recycling hat. Hinweise zur Untersuchung haben wir jetzt aber genügend gegeben.
Harald K. schrieb: > Sicher kann es das. Aber hast Du schon mal ein Display mit diesem > bizarren Fehler gesehen? Im Laufe der Zeit sieht man sehr viel und glaubt an garnichts mehr ;-) Selbst, wenn das Display nagelneu ist, kann ein visueller Test klaglos durchlaufen werden. Niemand wird sich 1 h davor setzen, um zusehen, ob die Anzeige statisch stabil bleibt. Bei Problemen mit dem Timing klappt meist die Initialisierung schon nicht. Meinerseits würde ich das betreffende Display an eine eigene Schaltung anschließen. Wenn der Fehler bleibt, ist die Ursache klar. Vielleicht hat der TO ein Arduino- oder RP2040-Board. da gibt es doch genug direkt aufspielbare Beispielprogramme.
Hallo Zusammen! Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere REV.E, beide zeigen das selbe Fehlerbild. Das Gerät hat Schieberegler um Werte einzustellen. Bediene ich einen Regler, verschwindet das Fehlerbild sofort und die Anzeige sieht normal aus. Nach 2-3 Sekunden fängt die Anzeige wieder an mit dem Fehlerbild, welches sich nach und nach aufbaut. Also zuerst ein Zeichen, dann folgen weitere mit komischen Anzeigen. Kann leider keine Messung mit dem Oszi machen da ich es verkauft habe.
Mi N. schrieb: > Harald K. schrieb: >> Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten >> zeigen, > > Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau). > Ein Display kann auch mal defekt sein. Hau weg den Schrott! ;-) Das ist wohl eher Altersdemenz (beim Display :).
Max M. schrieb: > Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere > REV.E, > beide zeigen das selbe Fehlerbild. Aha, die Neuen sinds... Haben da evtl. die Eingänge die Segel gehisst? Bzw.fehlen da Pull-Down Widerstände.
Hugo H. schrieb: > Fällt Dir da irgendetwas auf? (-> Bilder) Diese Befehle nutzt doch keiner und schon garnicht wirr mal so zwischendurch!
Teo D. schrieb: > Diese Befehle nutzt doch keiner und schon garnicht wirr mal so > zwischendurch! Gibt es Deine Glaskugel irgendwo zu kaufen?
Hugo H. schrieb: > Fällt Dir da irgendetwas auf? (-> Bilder) Execution Time (f_Osc = 270 kHz) vs. Execution Time (max.) Fällt dir irgendetwas auf? Ohne die Oszillatorfrequenz bzw. deren Toleranzbereich zu kennen, ist das ein Vergleich von Apfeln mit Birnen.
:
Bearbeitet durch User
Rainer W. schrieb: > Ohne die Oszillatorfrequenz bzw. deren Toleranzbereich zu kennen, ist > das ein Vergleich von Apfeln mit Birnen. Die Oszillatorfrequenz (alt) ist bekannt (steht im Datenblatt und ist dort angegeben, da der Controller - auch im Datenblatt referenziert - mit mehreren Frequenzen betrieben werden kann). Daher sind auch die Ausführungszeiten (alt) bekannt. Die Ausführungszeiten (neu) werden für die maximal zulässige "Betriebsfrequenz" angegeben, was ich für sinnvoll halte. Damit kann beides verglichen werden und es ist schon eine deutliche Diskrepanz bemerkbar. Niemand von uns (vermute ich mal) kennt die genaue zeitliche und programmtechnische Ansteuerung des Displays. Kann man mit einem billigen LA recht gut herausfinden, wenn man das will. Programmtechnisch ist es nicht zuletzt deshalb interessant, weil nicht jeder / jede Bibliothek das Busy-Flag abfragt, was im Fall des "neuen" Displays fatal sein kann. Von uns weiß vermutlich auch niemand, in welchem Modus das Display angesteuert wird. Zitat aus dem Datenblatt (neu): HINWEIS Die in der Tabelle angegebenen Ausführungszeiten gelten nur bei Abfrage des Busy Flags; d.h. vor jedem Schreib- und Lesezugriff muß das Busy Flag BF auf 0 abgefragt werden. Wird das Busy Flag nicht abgefragt, so sind die Ausführungszeiten zum Teil wesentlich länger als angegeben. Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig. Datenblätter liest nicht jeder - ich finde es durchaus sinnvoll mal reinzuschauen :-).
:
Bearbeitet durch User
Max M. schrieb: > Komisch ist auch dass wenn ich einen Wert verändere > wieder alles korrekt angezeigt wird. Nach ein paar Sekunden fängt das > Problem jedoch wieder an. Ja, sieht nach Wackelkontakt (Kabelbruch, kalte Lötstelle) aus. Die neuen Daten werden kapazitiv übertragen und dann floaten die Pins wieder. Am Timing liegt es definitiv nicht.
Das Problem hatte ich auch beim Tauschen eines alten Displays gegen ein neues. Die Timings waren nicht die gleichen und die alte Firmware aus den 90ern war halt auf ein anderes Timing angepasst. Die Lösung war, dass auf der Rückseite vom neuen LCD ein Widerstand ist, welcher die Taktfrequenz des LCDs bestimmt. Eine Änderung von diesem Wert hat den Fehler behoben. Ich musste etwas ausprobieren, bis ich den korrekten Wert gefunden habe. Einfach in 10ner Schritten rauf und runtergehen, ca 2 Stunden Arbeit.
:
Bearbeitet durch User
Max M. schrieb: > Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere > REV.E, > beide zeigen das selbe Fehlerbild. Max M. schrieb: > W242B-NLW Im DB steht bei denen als troubleshooting "Pull-Up Widerstand direkt am LCD-Modu". Die internen Pull-Up Transistoren, könnten bei diesen Modellen etwas zu mau sein!?
Hugo H. schrieb: > Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig. Vermutlich hast du den Satz anders gemeint, als er wirkt. Der 4-Bit Modus funktioniert auch ohne Busy-Abfrage (z.B. mit passenden Delays) tadellos.
Sherlock 🕵🏽♂️ schrieb: > Hugo H. schrieb: >> Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig. Das ist ein Zitat aus dem Datenblatt für das "neue / blaue" Display W242B-NLW - deswegen steht auch "Zitat" drüber :-). https://www.mouser.de/datasheet/2/127/2_24-1915198.pdf
Hugo H. schrieb: > Das ist ein Zitat aus dem Datenblatt Danke.
1 | HINWEIS |
2 | Die in der Tabelle angegebenen |
3 | Ausführungszeiten gelten nur bei |
4 | Abfrage des Busy Flags; d.h. vor |
5 | jedem Schreib- und Lesezugriff |
6 | muß das Busy Flag BF auf 0 |
7 | abgefragt werden. Wird das Busy |
8 | Flag nicht abgefragt, so sind die |
9 | Ausführungszeiten zum Teil |
10 | wesentlich länger als angegeben. |
11 | Im 4-Bit Mode ist die Busy-Abfrage |
12 | vor jedem Bytezugriff notwendig. |
Und "wesentlich länger" ist nicht weiter spezifiziert, nicht mal ungefähr. Ich bin negativ beeindruckt. Denn das ist beim originalen HD44780 definitiv nicht so. Dann ist das ja der wahrscheinlichste Show-Stopper gegen einen einfachen Hardwaretausch.
Hugo H. schrieb: > Sherlock 🕵🏽♂️ schrieb: >> Hugo H. schrieb: >>> Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig. > > Das ist ein Zitat aus dem Datenblatt für das "neue / blaue" Display > W242B-NLW - deswegen steht auch "Zitat" drüber :-). Hat ich so mal (versehentlich) für HD44780 Kompatible programmiert, also bei jedem 4Bit Zugriff... Tut natürlich nicht, abfragen erst nach dem 2.Nibble!
Hugo H. schrieb: > Wird das Busy Flag nicht abgefragt, > so sind die Ausführungszeiten zum Teil wesentlich länger als angegeben. Lass mich raten: wesentlich = 10 µs Noch einmal: Wenn das Timing nicht stimmt, bekommt man ersteinmal garkeine sinnvolle Anzeige zustande. Und auch dies noch einmal: Ansteuerung mit einem anderen Gerät/Schaltung testen.
Es kann auch ein Softwarefehler vorliegen, der µC schaltet die LCD-Leitungen zwischen den Ausgaben wieder auf floatend. Das eine LCD könnte einen Pulldown am E-Pin haben, das andere nicht. Mit einem DMM gegen VCC kann man messen, ob der E-Pin floatet oder auf low gezogen wird. Man könnte dann einen Pulldown (10k) nachrüsten, an die SW wird man wohl nicht rankommen.
Ich würde das (vermutlich) defekte LCD mal ausserhalb des Gerätes betreiben, ist ja z.B. mit einem Arduino kein großes Problem. Dann könnte man zumindest erstmal eingrenzen, ob es an der Art der Ansteuerung im "Lexicon MRC" oder tatsächlich am LCD selbst liegt ...
:
Bearbeitet durch User
Bitte 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.