Tach, kurze Frage mit Bitte um Einschätzung: Ist das Display im Eimer? Siehe Bild im Anhang. Hintergrund: Es ist ein Everbouquet MC2004B-SYL, das ich mit üblichem HD44780-Modus (4-Bit) ansteuere. Es ist neu und lief nie mit allen 4x20=80 Chars, sondern immer so wie im Bild. Den String kann ich beliebig wechseln. Ein Clear-Screen-Kommando bleibt wirkungslos. Habe ich irgendwas verpeilt und komme nicht drauf oder ist das ein Dead on Arrival? Quasi ein bekanntes Fehlerbild? Danke und Gruß, Jan.
Angehängte Dateien:
-
disp20x4_doa.jpg
36 KB
Ich würde mal sagen, falsch initialisiert. Was für ein Kontroller, welche Software?
Hängen die anderen 4Bit der Datenleitung in der Luft? Würde ich nnicht machen? Zumindest anlöten... Ingo
Hi >Ich würde mal sagen, falsch initialisiert. >Was für ein Kontroller, welche Software? So falsch, das die Anzeige mitten in einem Buchstaben aufhört? >Hängen die anderen 4Bit der Datenleitung in der Luft? Nein. Die Displaycontroller haben interne Pull-Up-Widerstände. @ Jan R. (janra) Sieht nach defekten oder nicht kontaktierten Spaltentreiber aus. Ändert sich an der Anzeige etwas, wenn du am oberen oder unteren Rand auf das Glas drückst? MfG Spess
Spess53 schrieb: > Hi > >>Ich würde mal sagen, falsch initialisiert. Was für ein Kontroller, welche Software? > > So falsch, das die Anzeige mitten in einem Buchstaben aufhört? > >>Hängen die anderen 4Bit der Datenleitung in der Luft? > > Nein. Die Displaycontroller haben interne Pull-Up-Widerstände. > > @ Jan R. (janra) > > Sieht nach defekten oder nicht kontaktierten Spaltentreiber aus. Ändert > sich an der Anzeige etwas, wenn du am oberen oder unteren Rand auf das > Glas drückst? Nein, keine Änderung in irgendeiner Weise. Egal, an welcher Kante ich etwas drücke. Grüße, Jan.
Spess53 schrieb: >>Ich würde mal sagen, falsch initialisiert. >>Was für ein Kontroller, welche Software? > > So falsch, das die Anzeige mitten in einem Buchstaben aufhört? Möglich ist da sicher alles, aber das bei defektem Spaltentreiber trotzdem die Kästchen sichtbar sind?
Display runter (ist mit so dreh-haken-dinger aus metal fest), kontakte auf pcb putzen, leitgummi putzen, wieder zusammenbauen (richtige drehung vorhe merken oder markieren (nicht alles disps haben richt-nasen). Wenns wieder ged: gut, wenn nich: tja.... So hab ich schon 2 alte radio-displays wieder hingricht (defekte passieren oft wenn sowas runterfällt und der kontakt-gummi verrrutscht)
Ingo L. schrieb: > Würde ich nnicht machen? Zumindest anlöten... Egal was im Datenblatt steht... Wenn man das schon macht, muss sichergestellt werden, dass nie ein Read-Kommando ausgeführt werden kann, d.h. am besten auch R/W gleich auf Low festnageln.
Hi >Wenn man das schon macht, muss sichergestellt werden, dass nie ein >Read-Kommando ausgeführt werden kann, d.h. am besten auch R/W gleich auf >Low festnageln. Was haben die unbenutzten Pins mit einem Read-Befehl zu tun? MfG Spess
Jan R. schrieb: > Ist das Display im Eimer? Siehe > Bild im Anhang. Im Grunde sieht das während einer Entwicklung gesund aus, wenn noch nicht alles perfekt spielt. Vielleicht ist das Timing zu schnell? Man kann es zur Not einen kleinen Tick langsamer wählen, als im Datenblatt angegeben. Ich hatte mal was ähnliches: Und zwar war das Display über nicht besonders gute Kontakte mit dem µC verbunden, und ausgerechnet das Busy-Flag zuckte. Dann bleibt an der Stelle das Programm stehen, wenn man nicht z.B. im Code noch einen Timeout-Timer drinne hat.
Spess53 schrieb: > Hi > >>Wenn man das schon macht, muss sichergestellt werden, dass nie ein >>Read-Kommando ausgeführt werden kann, d.h. am besten auch R/W gleich auf >>Low festnageln. > > Was haben die unbenutzten Pins mit einem Read-Befehl zu tun? > > MfG Spess Ganz einfach, wenn man die unbenutzen Pins (wie manche hier fordern) einfach auf GND zementiert, dann bekommt man ein Problem falls man einen Read ausführt. Deshalb lässt man die offen. Und das sieht NICHT nach einem SW Problem aus. Das muss die Hardware sein. Falsche Initaliserung verursacht keinen viertel Buchstaben. gruß cyblord
Paul Baumann schrieb: > Hast Du nicht noch ein anderes Display zum Gegenprüfen? > > MfG Paul Paul, du machst es richtig. Ein nur teilweise abgebildetes Zeichen sah ich aber auch noch nie. Es könnte, wie ich schon beschrieb, daran liegen, daß man wieder zu schnell auf das Display zugreifen möchte, und man ein Delay aus dem Datenblatt nicht eingehalten hat. Während der Initialisierung kann man bei manchen Displays das Busy-Flag nicht abfragen. Das LCD hat ja auch einen eigenen µC, der Zeit braucht, um zu verarbeiten. Mir passierte das noch nicht, weil ich Delays beim Test immer erst mal viel größer wähle. Wenn ich auf meinen ollen Keyboard-Display-Controller 8279 zu schnell zugreife, bekomme ich auch nur Mist geliefert, bzw. er initialisiert nicht richtig.
Hi >Es könnte, wie ich schon beschrieb, daran liegen, daß man wieder zu >schnell auf das Display zugreifen möchte, und man ein Delay aus dem >Datenblatt nicht eingehalten hat. Während der Initialisierung kann man >bei manchen Displays das Busy-Flag nicht abfragen. Unwahrscheinlich. Das unvollständige Zeichen in der ersten Zeile dürfte ein 'u' sein. Das heißt, das der Displayspeicher richtig beschrieben wurde. HD44780- und kompatible Displaycontroller haben 16 Zeilentreiber, die zwei Zeilen bedienen. Bei einem vierzeiligen Display wird die erste Zeile auf dem Display in Zeile 1 und 3 dargestellt und die zweite in Zeile 2 und 4. Im Bild ist zu sehen, das der Fehler bei beiden 'Controllerzeilen' ab der gleichen Spalte auftritt. Und die Spalte wird für beide Zeilen von einem Treiber bedient. Das hat nichts mit irgendwelchem Timing der Ansteuerung zu tun. MfG Spess
RAM-Defekt im Displaycontroller? Aus irgendeinem Grund müssen die Bytes ja alle $FF sein.
Spess53 schrieb: > Das hat nichts mit irgendwelchem Timing der Ansteuerung zu tun. Na ja. Irgendwie müssen Delays aber eingehalten werden. Bei einer halben geforderten Delayzeit kann man nicht einfach blind ins Display schreiben. Möglicherweise macht der Displaycontroller dann nur noch Mist. Das war ja auch nur eine Anmerkung. Bin aber gespannt, wie es aus geht.
Hi >RAM-Defekt im Controller? Aus irgendeinem Grund müssen die Bytes ja alle >$FF sein. Bis auf das Zeichen nach dem 'p'. Das ist nur zu 4/5-tel $FF. MfG Spess
Paul Baumann schrieb: > Hast Du nicht noch ein anderes Display zum Gegenprüfen? > > MfG Paul Ja, das hatte ich sogar schon vor dem Post hier gemacht. Einmal mit einem 2x32 und einem anderen 4x20, allerdings eines anderen Herstellers. Das Teil im Bild von Everbouquet ist das einzige, das diese Zicken zeigt.
Achso, zum Controller: ich hatte das LCD heute flux an einen Arduino geklöppelt, um es zu testen. Vom A. kann man jetzt halten was man will, aber um mal eben ein LCD mittels der mitverschifften Lib zu befeuern, taugt das ganz gut und dabei kann man nicht viel falsch machen. Der Code dazu ist dann auch lächerlich einfach. Ein Bißchen Init für die Verdrahtung und im main() dann der String und der Counter. Die eingebundene Library, die mit anderen LCDs klaglos läuft (vgl. Msg. zuvor), ist bestimmt auch praxiserprobt genug, um so einen Bug nicht mehr mitzuschleifen; die Plattform ist ja sehr populär. Um die genaue Ahnenforschung der Lib und das konkrete Timing habe ich mich noch nicht gekümmert, kann da also leider Nachfragen nicht qualifiziert beantworten, wie ich es eher könnte, wenn ich alles selbst gecodet hätte. Das Controller selbst ist ein mega328p bei 16 MHz, welcher bis zum Test an einem anderen Sensor im Haus hing und ein 2x16-LCD klaglos bediente. Das kannes also m.M. nicht sein. Und es läuft auch nach dem Test mit dem (vermutl. defekten) 4x20 noch, hat also beim Test selbst keinen Schuß bekommen. Viele Grüße, Jan.
Ja, dann ist es wohl wirklich nicht mehr im Gange. Zitat Werner: "Hau wech die Schei....!" ;-) MfG Paul
Spess53 schrieb: > Was haben die unbenutzten Pins mit einem Read-Befehl zu tun? DB[0..3] sind erst unbenutzt, wenn das Display richtig auf den 4-Bit Modus initialisiert ist. Bei einem Read im 8 Bit-Modus würde ein High vom Ausgangstreibers auf den auf Gnd festgenagelten Pin-Pegel treffen. Das geht i.d.R. nur mit OC-Treibern gut und zumindest bspw. das Datenblatt vom Displaytech S162A ist diesbezüglich etwas schwach.
Bernd schrieb: > Spess53 schrieb: >> Was haben die unbenutzten Pins mit einem Read-Befehl zu tun? > > DB[0..3] sind erst unbenutzt, wenn das Display richtig auf den 4-Bit > Modus initialisiert ist. Bei einem Read im 8 Bit-Modus würde ein High > vom Ausgangstreibers auf den auf Gnd festgenagelten Pin-Pegel treffen. > Das geht i.d.R. nur mit OC-Treibern gut und zumindest bspw. das > Datenblatt vom Displaytech S162A ist diesbezüglich etwas schwach. Ja, Display-Datenblätter ... diese Everbouquets runden in dieser Disziplin sehr nach unten ab. Kann es nicht als klar gelten, daß der 4-Bit-Modus in diesem Fall löppt? Ich meine, die ersten 11,2 Zeichen der ersten Zeile macht es einwandfrei, keine Bitkipper, kein Pixelsalat. Dann kommt die Mauer. Und in der zweiten Zeile zählt es munter die Integerzahlen nach oben, ohne je zu flimmern oder zu springen (falls da Störungen zu sehen gewesen wären, hätte ich euch das geschrieben). Dann wieder die Mauer. Und die nach unten, denn wenn ich mehr als zwei Zeilen ausgeben will, kommen die nicht hinter den 0xffs hervor.
Hi >Bei einem Read im 8 Bit-Modus würde ein High >vom Ausgangstreibers auf den auf Gnd festgenagelten Pin-Pegel treffen. Wo stand da etwas von 'Gnd festgenagelten Pin-Pegel'? MfG Spess
Spess53 schrieb: > Wo stand da etwas von 'Gnd festgenagelten Pin-Pegel'? Ingo L. schrieb: > Hängen die anderen 4Bit der Datenleitung in der Luft? Würde ich nnicht > machen? Hat das Ding noch Garantie? -> Reklamieren ... Gruß Jobst
So ein Fehlerbild kann man durch keine Software, bzw. fehlerhafte Software erzielen. Das sollte auch eine Kapazität auf dem Gebiet "LCD Displays" wie unser aller geliebter Willy F. einsehen.
Wilhelm Ferkes schrieb: > Spess53 schrieb: > >> Das hat nichts mit irgendwelchem Timing der Ansteuerung zu tun. > > Na ja. Irgendwie müssen Delays aber eingehalten werden. Bei einer halben > geforderten Delayzeit kann man nicht einfach blind ins Display > schreiben. Möglicherweise macht der Displaycontroller dann nur noch > Mist. Das war ja auch nur eine Anmerkung. Bin aber gespannt, wie es aus > geht. Ja aber bei zu schnellen Befehlen gehen diese einfach verloren. Der Controller arbeitet noch und kann auf neue Befehle nicht reagieren. Mehr passiert aber nicht. gruß cyblord
hi Jan: Ich sah Ihr LCM-Display, geschätzt BUSY Staat nicht lesen, versuchen Sie. yan.q http://www.szjunxian.com
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.