Set DDRAM Address am 4 zeiligen LCD durch ATMega 32 funktioniert nicht

[Dennis Heide (Gast)]

Hallo,
ich arbeite zur Zeit aus lerngründen das AVR-Tutorial durch und bin am 
LCD angekommen.
Ich habe ein 4x20 LCD das den KS0066U Controller (Datenblatt als PDF 
angehangen) verwendet.

Die Initialisierung und so ziemlich alle Funktionen des Displays und aus 
der lcd-routines.asm funktionieren.
Allerdings tritt ein Problem auf wenn ich den Cursor über die DDRAM 
Addresse versetze und anschließend in die 4. Zeile schreibe. Die ersten 
drei Zeichen werden in die 4. Zeile geschrieben, das 4. Zeichen landet 
allerdings am Ende der 3. Zeile.
Im angehangenen Bild habe ich die Zeichen 0 bis 9 ausgegeben nachdem ich 
den Cursor mit folgenden Befehlen versetzt habe:

      ldi temp1, $B7
      rcall lcd_command

      ldi ZL, LOW(text*2)
      ldi ZH, HIGH(text*2)
      rcall lcd_flash_string

Man sieht wie der Cursor  nach der 2 springt und die 3 in die 3. Zeile 
schreibt, statt in der 4. Zeile weiter zuschreiben.

Dieses verhalten tritt nur auf wenn ich die DDRAM Adresse verändere, 
verschiebe ich den Cursor mit dem Shift befehl oder schreibe aus der 
Home Position kann die 4. Zeile ganz normal beschrieben werden.

Nach langer Fehlersuche komme ich nicht weiter und hoffe auf Hilfe. Ich 
kann mir das Verhalten nicht erklären, hat hier vielleicht jemand eine 
Vermutung?

Ich bin für jede Idee sehr dankbar.

[Nooby (Gast)]

Dennis Heide schrieb:
> Ich habe ein 4x20 LCD das den KS0066U Controller (Datenblatt als PDF
> angehangen) verwendet.

Haben wir einen KS0066U kompatiblen Controller oer wirklich einen 
KS0066U?

[Dennis Heide (Gast)]

Im Datenblatt des Displays steht KS0066U und KS0063B.

Der KS0063B ist soweit ich es verstanden habe nur ein Shift Register

[Dennis Heide (Gast)]

Die einzige Erklärung die ich habe wäre, dass bei der Initialisierung 
etwas falsch läuft. Der ATMega läuft mit 14,7456 MHz und das habe ich 
auch in der LCD Routine eingestellt.
Da im Datenblatt bei der Initialisierung nur mindest Zeiten angegeben 
sind habe ich auch schon eine höhere Frequenz eingetragen aber dies hat 
auch zu keiner Lösung geführt.

[spess53 (Gast)]

Hi

>Im angehangenen Bild habe ich die Zeichen 0 bis 9 ausgegeben nachdem ich
>den Cursor mit folgenden Befehlen versetzt habe:

>      ldi temp1, $B7
>      rcall lcd_command

Die Adresse liegt aber nicht im sichtbaren Bereich des LCDs. Was der 
Displaycontroller dann daraus macht kann ich dir aber jetzt auch nicht 
genau sagen.

MfG Spess

[Karl H. (kbuchegg)]

spess53 schrieb:
> Hi
>
>>Im angehangenen Bild habe ich die Zeichen 0 bis 9 ausgegeben nachdem ich
>>den Cursor mit folgenden Befehlen versetzt habe:
>
>>      ldi temp1, $B7
>>      rcall lcd_command
>
> Die Adresse liegt aber nicht im sichtbaren Bereich des LCDs. Was der
> Displaycontroller dann daraus macht kann ich dir aber jetzt auch nicht
> genau sagen.

Jep. Die ist draussen.

Ich würde die Zahlenangabe in 2 Teile aufteilen. Den Teil für das 
Kommando und den Teil für die Adresse und das ver-odern dem Assembler 
überlassen. Der macht dabei weniger Fehler.

    ldi temp1, $80 | $54

bzw. die Adressangabe dann gleich in Dezimal machen (ist für uns 
einfacher)

Das müsste dann für die erste logische Zeile sein

    ldi temp1, $80 | $00 | n

und für die zweite logische Zeile

    ldi temp1, $80 | $40 | n

wobei n dann eben von 0 bis 39 läuft und die Character-Position 
innerhalb der Zeile angibt. Um also den Cursor in der '2.ten Zeile' an 
die Position 20 zu setzen, dann eben

    ldi temp1, $80 | $40 | 20


Im Endeffekt das ganze dann natürlich schön sauber in eine Funktion 
lcd_goto_line_1 verpackt oder so, aber zum Testen der Funktionalität das 
erst mal so aufdröseln. Gerade bei so Bitoperationen vertut man sich da 
gerne mal - und das muss ja nicht sein. Bits zusammenführen kann der 
Assembler genauso gut und der macht da keine Fehler dabei.

Grundsätzlich: Wenn du irgendwelche Berechnungen dem Assembler anhängen 
kannst, dann tu das anstatt selber im Kopf oder auf Papier zu rechnen 
und nur noch das Endergebnis im Programm hinzuschreiben.

[spess53 (Gast)]

Hi

>Ich würde die Zahlenangabe in 2 Teile aufteilen.

Ich auch. Was natürlich auch etwas verwirrend ist, das im Datenblatt 
(S.13) die Adressen mit gesetztem Befehlsbit angegeben sind. Die 
eigentlichen DDRAM-Adressen entsprechen den üblichen Adressen von 4x20 
Displays.

MfG Spess

[Dennis Heide (Gast)]

Tatsächlich, der Fehler lag an der von mir falsch ausgerechneten 
DDRAM-Adresse. Ich war von einem durchgängien Adressbereich ausgegangen.
Der Adresssprung von A7 nach C0 überrascht mich. Ich hatte vermutet das 
es nach A7 am Ende der 3. Zeile in der 2. Zeile mit A8 weitergeht.

Vielen Dank für den Hinweis, kaum macht man es richtig funktioniert es 
auch.

Der Tipp mit der Berechnung im Assembler durch die Veroderung ist sehr 
gut und ich werde ihn umsetzen.

[spess53 (Gast)]

Hi

>Der Adresssprung von A7 nach C0 überrascht mich.

Das ist aber ein Adressprung von 0x27 nach 0x40. Der Befehl für 'Set 
DDRAM address ist 0b1xxxxxxx. Dabei ist 'xxxxxxx' die Adresse.

MfG Spess

[fan control (Gast)]

http://dangerousprototypes.com/docs/Bus_Pirate_LCD_adapter_v2 ca. die 
mitte mal anschauen!