Defekter CGRAM in HD44780 ?

[Marius (Gast)]

Hey Leute, habe grade an meinem DFRobot LCD Keypad Shield etwas 
eigenartiges festgestellt und meine jetzt, es auf das Display Modul 
eingegrenzt zu haben.

Zum testen speichere ich in allen 8 CGRAM Plätzen das gleiche Bitmuster 
ab und stelle sie dann nacheinander auf dem Display dar.

Die Ausgabe von CGRAM Charakter Nr. 7 ist aber in sich "gespiegelt", 
d.h. die unteren 4 Pixelreihen des einzelnen Custom Chars überschreiben 
immer auch in die oberen 4 Reihen (s. Foto mit zwei verschiedenen 
Patterns)

Handelt es sich um einen defekten RAM des Displays ?

#include <LiquidCrystal.h>
LiquidCrystal lcd(8, 9, 4, 5, 6, 7); //Angabe der erforderlichen Pins



byte testpattern[8] = {
  0b00000,
  0b00000,
  0b00000,
  0b00000,
  0b01100,
  0b10010,
  0b10010,
  0b01100
};

void lcdtest(){
  
  lcd.createChar(0, testpattern);
  lcd.createChar(1, testpattern);
  lcd.createChar(2, testpattern);
  lcd.createChar(3, testpattern);
  lcd.createChar(4, testpattern);
  lcd.createChar(5, testpattern);
  lcd.createChar(6, testpattern);
  lcd.createChar(7, testpattern);
  lcd.clear();
  for(int i = 0; i<8;i++){
    lcd.write(uint8_t (i));
  }
}

void setup() {
  lcd.begin(16, 2); 
  lcdtest();

}

void loop() {

}

[C. W. (chefkoch)]

Bei mir tritt es jedenfalls mit deinem Code nicht auf.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Da wird wohl das höchste Bit bei der Adressierung klemmen. Dadurch wird 
ein Bereich doppelt angesprochen und die andere Hälfte gar nicht. Hast 
Du mal ein anderes Display draufgesteckt?

[pegel (Gast)]

Wenn ich Display Probleme hatte und kein Defekt vorlag, lag es 
eigentlich immer am Timing.

Vielleicht mag es nicht so hektisch, baue deshalb zur Probe ein paar 
Delays ein.

[Marius (Gast)]

Delays bringen leider nichts, selbst wenn ich nur dieses eine Custom 
Char ausgebe tritt der Fehler auf.

Das Display ist leider auf dem Shield verlötet, habe aber noch andere 
HD47780 hier, die werden bei Zeiten mal getestet und dann berichtet.

Trotzdem direkt mal den DDRAM durchtesten, evtl gibts ja noch mehr 
defekte Speicherzellen.
Der CGROM war soweit in Ordnung

Aber denke mal es hat nen Grund, warum es damals die billigsten Artikel 
ihrer Art in der China-Bucht waren...

¯\_(ツ)_/¯

[c-hater (Gast)]

Marius schrieb:

> Delays bringen leider nichts, selbst wenn ich nur dieses eine Custom
> Char ausgebe tritt der Fehler auf.

Er meinte sicher nicht (nur) zwischen den Customchars, sondern auch 
zwischen den einzelnen Kommandos, die für einen Char notig sind, 
insbesondere die Stelle zwischen dem setzen der CGRAM-Adresse und dem 
ersten Byte des Chars.

[interessent (Gast)]

Ben B. schrieb:
> Da wird wohl das höchste Bit bei der Adressierung klemmen.

pegel schrieb:
> Wenn ich Display Probleme hatte und kein Defekt vorlag, lag es
> eigentlich immer am Timing.

Wird beim original HD44780 die MSB Leitung nicht auch als Ready-Signal 
benutzt? Da tippe ich auf eine Kombination aus beidem.

[Karl B. (gustav)]

interessent schrieb:
> Wird beim original HD44780 die MSB Leitung nicht auch als Ready-Signal
> benutzt?

Hi,
Du meinst wahrscheinlich das ominöse Busy-Flag?

Beitrag "Re: HD44780+PIC18F25k22 Rise Time Probleme?"

ciao
gustav

[Uwe (de0508)]

Hallo Marius,

ich habe an einen LCD Assembler Interface gearbeitet und muss das 
Schreiben einen Custom Char durch setzen der DDRam Adresse, beenden.

So sähe das in diesem AVR Assemblerdialekt aus

_Lcd4DefChar:
movw  ZH:ZL,_HA1:_HA0      ;Adresse der Zeichenbits holen (Datenobjekt)
PopPC
pop  _HA3        ;index (replaces ASCII 0-7)
PushPC
or  _HA0,_HA1      ;pr?fen
breq  __Lcd4DefCharExit    ;raus wenn ung?ltig
cpi  _HA3,8        ;index pr?fen (0-7 erlaubt)
brsh  __Lcd4DefCharExit    ;raus wenn ung?ltig
lsl  _HA3        ;index 3 bits nach links
lsl  _HA3
lsl  _HA3
ldi  _HA0,Lcd4Command_CGRAMAddress
or  _HA0,_HA3      ;index einkn?pfen
call  _Lcd4Command      ;Kommando schreiben
ldi  WL,8        ;reset zeilenz?hler

__Lcd4DefCharLoop:

lpm  _HA0,Z+
call  _Lcd4Char      ;zeilenbyte schreiben
dec  WL        ;incr zeilenz?hler
brne  __Lcd4DefCharLoop
__Lcd4DefCharExit:
; ==============>
ldi  _HA0,Lcd4Command_DDRAMAddress
jmp  _Lcd4Command
; <==============
:end

[c-hater (Gast)]

Uwe S. schrieb:

> ich habe an einen LCD Assembler Interface gearbeitet und muss das
> Schreiben einen Custom Char durch setzen der DDRam Adresse, beenden.

Nein, musst du nicht. Kein HD44780 verlangt das.

Was aber alle verlangen: dass man die Minimalzeiten für jedes einzelne 
verschissene "Kommando" einhält, was über's Interface geht. Bei vielen 
kompatiblen Displays sind diese Mindestzeiten (teils dramatisch) kürzer 
als beim Original. Nur kann man sich nur auf die Zeiten des Originals 
verlassen, wenn man den Kram nicht für jedes einzelne Display erneut 
anpassen möchte.

Also sorgt man dafür, dass man immer die Mindestzeiten des Originals 
einhält, dann werden auch alle "HD44780-kompatiblen" Displays problemlos 
funktionieren.

Im Bezug auf die im konkreten Problem verwendeten "Kommandos" bedeutet 
das: es müssen immer mindestens 37µs dazwischen liegen.

[Uwe (de0508)]

Hallo,

c-hater schrieb:
> Nein, musst du nicht. Kein HD44780 verlangt das.

ja, bestimmt !

Sonst wird bei nächsten Schreibvorgang eines LCD-Zeichens eine falsche 
Ramadresse angesprochen.

Man kann dass natürlich auch durch eine set_cursor(row, col); vor einem 
erneuten Schreiben umgehen.

Bei mir ist es integriert..

[spess53 (Gast)]

Hi

>Man kann dass natürlich auch durch eine set_cursor(row, col); vor einem
>erneuten Schreiben umgehen.

Ja, genau dort gehört die neue Adressierung hin. Nach dem Beschreiben 
des CG-RAMs weißt du ja die neue Adresse noch gar nicht. Also ist das 
Ende der CG-RAM-Initialisierung der falsche Punkt für eine neue 
Adressierung des DDRAMs.

>Bei mir ist es integriert..

Ja, falsch.

MfG Spess

[Soul E. (Gast)]

c-hater schrieb:

> Was aber alle verlangen: dass man die Minimalzeiten für jedes einzelne
> verschissene "Kommando" einhält, was über's Interface geht. Bei vielen
> kompatiblen Displays sind diese Mindestzeiten (teils dramatisch) kürzer
> als beim Original. Nur kann man sich nur auf die Zeiten des Originals
> verlassen, wenn man den Kram nicht für jedes einzelne Display erneut
> anpassen möchte.

Leider hängt das Timing nicht nur von Typ und Charge des Controllers ab, 
sondern auch noch von der Temperatur. Wer nicht immer den absoluten 
worst-worst-case abwarten will, der sollte sich zweckmäßigerweise ans 
Datenblatt halten und das Busy-Flag auswerten.

[Karl B. (gustav)]

Hi,
ob Adressen automatisch erhöht oder erniedrigt werden, definiert man 
afaik doch vorher in der Initialisierung. Mein Display kann zum Beispiel 
auch "rückwärts" schreiben, wenn ich das möchte.

Uwe S. schrieb:
> Man kann dass natürlich auch durch eine set_cursor(row, col); vor einem
> erneuten Schreiben umgehen.
Ich nenne das "locate-Anweisung".

Anbei noch ein Auszug aus dem Datenblatt.

(Und bei der Busyflagabfrage sollte noch mindestens ein NOP dazwischen.)

ciao
gustav

[Harald A. (embedded)]

Marius schrieb:
>
> Aber denke mal es hat nen Grund, warum es damals die billigsten Artikel
> ihrer Art in der China-Bucht waren...
>
Wenn schon FTDIs und AVRs in China kopiert werden trifft das mit 
Sicherheit auch auf den HD44780 zu. Es gibt immer wieder Chips, die 
ihren Originalen nur zu 99% entsprechen. Gerade bei einer relativ selten 
genutzten Option wie dem CG RAM sind Fehler im Silizium ganz bestimmt 
nicht ausgeschlossen.

[spess53 (Gast)]

Hi

>Wenn schon FTDIs und AVRs in China kopiert werden trifft das mit
>Sicherheit auch auf den HD44780 zu.

Der HD44780 ist schon seit Jahren abgekündigt und dürfte in keinem z.Zt. 
hergestellten Displays zu finden sein. Und kompatible ICs gibt es schon 
seit mindestens den 90ern des letzten Jahrtausend.

>Gerade bei einer relativ selten
>genutzten Option wie dem CG RAM sind Fehler im Silizium ganz bestimmt
>nicht ausgeschlossen.

So selten ist bei mir die Nutzung des CG-Rams gar nicht. Und ich hatte 
noch nie Probleme damit. Das ist vom Hersteller garantiert und hat zu 
100%
funktionieren. Wenn nicht, ist der Chip defekt.

Allerdings nutze ich erprobte eigene Assemblerroutinen.

Wenn allerdings der Rest des Programms wie das Geschreibsel des TOs 
weiter oben aussieht, würde ich meine Hand dafür nicht ins Feuer legen.

MfG Spess

[c-hater (Gast)]

soul e. schrieb:

> Wer nicht immer den absoluten
> worst-worst-case abwarten will, der sollte sich zweckmäßigerweise ans
> Datenblatt halten und das Busy-Flag auswerten.

Das ist lt. Datenblatt genauso legal, wie die "blinde" Einhaltung der 
Mindestzeiten, denn diese berücksichtigen ja gerade auch den worst case.

Man tauscht halt bei Verwendung des Busy-Flags (im Idealfall sogar 
deutlich) kürzere Transferzeiten gegen die Notwendigkeit eines 
zusätzlichen IO-Pins.

Falsch ist nur, weder das eine noch das andere zu tun. Das geht dann 
halt oft schief...