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.
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
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.
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
disp20x4_doa.jpg
(36 KB)
