Zeilenadressen LCD 4x20 blau

Karlheinz Druschel schrieb:
> Hi Leuts, ich habe hier ein 4x20 Zeichen LCD (blau/weiss) und versuche
> es mit den Routinen aus dem Tutorial anzusteuern.

#define LCD_DDADR_LINE1         0x00
#define LCD_DDADR_LINE2         0x40
#define LCD_DDADR_LINE3         0x14
#define LCD_DDADR_LINE4         0x54


3. Zeile Anfang = 1. Zeile + Displaybreite

Harry

so sollte es gehen ...

Position 1. Zeilen in:

Zeile 1  = 0
Zeile 2  = 40
Zeile 3  = 20
Zeile 4  = 84

Werte sind dezimal !

hättest Du aber auch mit probieren raus finden können

Die 4x20 haben doch alle die gleiche Adressierung (soviel
Möglichkeiten hat man bei 80 Zeichen ja gar nicht mehr),
also geht jedes Datenblatt zu einem 4x20 dafür.

>Nun änderte ich die Adresse der Zeile 3 von 0x10 auf 0x15. Ergebnis:
>Nichts verändert sich, der Text steht in der 1. Zeile ab Position 17.
>Ich habe jetzt alle möglichen Werte durchprobiert, ich kriege keine
>Ausgabe in der 3. Zeile an Position 1.


Wenn ihr meinen Beitrag aufmerksam gelesen habt, dann werdet ihr 
feststellen dass die dies schon versucht habe und die Adressänderungen 
nichts bewirken!!!

Dann würde ich sagen, der Fehler ist in Zeile 42

Selbst folgende Änderung bewirkt nichts:
#define LCD_DDADR_LINE1         0
#define LCD_DDADR_LINE2         40
#define LCD_DDADR_LINE3         00
#define LCD_DDADR_LINE4         40
Nun sollte doch eigentlich egal sein, ob ich die erste oder die dritte 
Zeile anspreche.
Aber es macht ein Unterschied: Spreche ich die 1. Zeile an, dann steht 
der Text ab Position 0,0. Spreche ich aber die 3. Zeile an, dann steht 
der Text wieder ab Position17 in der 1. Zeile??????

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze 
Balken
  // verschwunden sein
  lcd_init();

  // Text in einzelnen Zeichen ausgeben
  lcd_setcursor(0,1);
  lcd_string("0123456789");




  while(1)
  {
  }

  return 0;
}

Die LCD-Routinen sind die Originalroutinen aus dem Tutorial hier:
http://www.mikrocontroller.net/articles/AVR-Tutorial:_LCD
Ich denke eher dass es am Display liegt (nur so ein Gefühl)

Wieso Code?
Dann kann doch jeder den Fehler finden.

Nur die Expoerten schaffen das ohne...

Karlheinz Druschel schrieb:
> Ich denke eher dass es am Display liegt (nur so ein Gefühl)

Muß wohl, weil mit meinem lcd_setcursor() und lcd_string()
funktioniert es auch mit einem 4x20, und deine Funktionen
sind bestimmt genauso gut.
Also kann es nur noch am LCD liegen.
Am Besten umtauschen!

PS:
Du weißt aber schon, daß bei deinem Link gar keine C-Funktion
lcd_string() zu sehen ist, es sei denn ich blind?

Nachdem du in der lcd.h geändert hast:

hast du auch kontrolliert, ob lcd.c tatsächlich neu compiliert wird?

Ansonsten kannst du im Header File ändern, bis du schwarz wirst :-)


> Ich denke eher dass es am Display liegt (nur so ein Gefühl)
Das glaub ich nicht, Tim!

Noch wichtig ist, das man auch da richtige (neue) File auf den 
Controller überträgt :-)

@Klaus:
Wie bereits mehrfach erwähnt ist die Routine hier im Tutorial zu finden 
(Link steht oben).

@Mike: Dann würde sich ja gar nichts ändern, aber es ändert sich doch 
fast (siehe oben).

Karlheinz Druschel schrieb:

> @Mike: Dann würde sich ja gar nichts ändern, aber es ändert sich doch
> fast (siehe oben).

Hmm.
Ich seh von dir immer nur die Meldung:
Der Beginn meiner 3. Zeile ist in der ersten Zeile Zeichen 17.

An dieser Fehlerbeschreibung hat sich seit deinem ersten Posting nichts 
verändert.

Also für mich klingt das nach:
Du änderst zwar etwas im Header File, aber es kommt nicht auf dem 
Controller an.

Ich würde mal einen Rebuild All machen und darauf achten ob auch 
wirklich alles neu compiliert wird.

Guter Rat schrieb:
> Z.B. haben die LCD's bei denen der KS0073 Controller verbaut ist,
> (Z.B. EA DIP204) die Adressen, ebenfalls ein 4*20 Display.
>
> Zeile 1: 0x00...0x13
> Zeile 2: 0x20...0x33
> Zeile 3: 0x40...0x53
> Zeile 4: 0x60...0x73

Um die Sache noch etwas mehr zu verwirren:
Ich habe hier ein DB von EA, u.a. für EA DIP204*.
Da steht aber gerade nicht deine Adressierung drin, sondern
diese:
Zeile: 0x00
Zeile: 0x40
Zeile: 0x14
Zeile: 0x54

Dann habe ich noch ein DB zu einem EA P204-3N/-NLED, mit
einem Controller HD 66712.
Das wiederum hat deine Belegung:
Zeile: 0x00
Zeile: 0x20
Zeile: 0x40
Zeile: 0x60

(Meine obige Behauptung, daß die eh alle gleich wären,
ziehe ich hiermit stillschweigend wieder ein und behaupte
das Gegenteil.)

Karlheinz Druschel schrieb:
> @Klaus:
> Wie bereits mehrfach erwähnt ist die Routine hier im Tutorial zu finden
> (Link steht oben).

Die LCD-Routinen gibt es hier in etlichen Varianten (die beste
natürlich von mir :-), und dein Link führt auf die Ansteuerung
des LCD in Assembler.
Ehrlich gesagt habe ich keine Lust, zu raten, welchen Quelltext
du nun nimmst, um darin dann Fehler zu suchen.

Noch ein Nachtrag zu den Adressen:
In einem gedruckten DB von EA namens "Blue Line - Blau negativ
mit weisser LED" ist die Tabelle zu sehen wie im Anhang.

Dieses DB beschreibt (an 4x20) die Typen EA W204B-NLW, EA 017-9UKE,
EA DIP204B-4NLW, EA DIP204B-6NLW und EA T204B-BNLW.
Leider finde ich darin nicht, welches jetzt welchen Controller hat...

Also verwendet alleine EA mindestens 3 Controller (HD44780,
KS0073, HD66712), wobei erster bei 4x20 die eine Adressierung
verwendet, KS0073 und HD66712 die andere (siehe oben).

Die Zuordnung von "Guter Rat" von KS0073 zu den Adressen stimmt
hiermit; auch wenn es offenbar nicht oder nicht alle mit einer
Bezeichnung EA DIP... sind.

ok, mit dem Link habe ich mich verhauen. Hier ist der Richtige:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung

@Karlheinz Buchegger: Ich mache immer ein "Rebuild All" (sind ja nur 
zwei Dateien), und wenn ich den Text ändere, dann klappt das auch.

Aber ich glaube ich habe was gefunden.
Im Quellcode von lcd_init steht folgendes:

#define LCD_FUNCTION_2LINE      0x08
// 4-bit Modus  2 Zeilen  5x7
lcd_command( LCD_SET_FUNCTION | LCD_FUNCTION_4BIT |
            LCD_FUNCTION_2LINE |LCD_FUNCTION_5X7 );

Anscheinend wird damit auf zweizeiligen Betrieb umgeschaltet. Fargt sich 
nur noch wie ich auf vierzeiligten Betrieb umschalte...

ok, mit dem Link habe ich mich verhauen. Hier ist der Richtige:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung

@Karlheinz Buchegger: Ich mache immer ein "Rebuild All" (sind ja nur 
zwei Dateien), und wenn ich den Text ändere, dann klappt das auch.

Aber ich glaube ich habe was gefunden.
Im Quellcode von lcd_init steht folgendes:

#define LCD_FUNCTION_2LINE      0x08
// 4-bit Modus  2 Zeilen  5x7
lcd_command( LCD_SET_FUNCTION | LCD_FUNCTION_4BIT |
            LCD_FUNCTION_2LINE |LCD_FUNCTION_5X7 );

Anscheinend wird damit auf zweizeiligen Betrieb umgeschaltet. Fragt sich 
nur noch wie ich auf vierzeiligten Betrieb umschalte...

Karlheinz Druschel schrieb:
> Anscheinend wird damit auf zweizeiligen Betrieb umgeschaltet. Fragt sich
> nur noch wie ich auf vierzeiligten Betrieb umschalte...

Gar nicht.
Es gibt an dieser Stelle nur die Möglichkeit ein- oder zweizeilig.
Vierzeilig als eigenen Modus gibt es nicht.

Dieses Bit im Kommando Function Set betrifft m.W. nur Displays
mit 1x16, von denen gibt es zwei Varianten bzgl.
der Adressierung (alle 16 Zeichen direkt hintereinander, oder
mit ein paar Byte Abstand kompatibel zu einem 2x8-LCD als
ob die zwei Zeilen eines 2x8 hintereinander montiert
wären).

Bei einem 4x20 sollte es keinen Unterschied machen.

PS: in meiner eigenen C++-Klasse für die LCD-Ansteuerung
habe ich solche Kuriositäten zwar eingebaut nach den Unterlagen,
die ich so finden konnte.
Leider konnte ich das nie probieren...
Falls jemand 1x16 hat und entbehren kann (oder sonstige, die ich
noch nicht probieren konnte) und entweder leihweise hergeben könnte
oder für kleines Geld abtreten, dann könnte ich sowas mal
probieren und ggf. vervollständigen.

Was ich bisher schon habe sind:
- EA W162B-BNLW
- EA W204B-NLW
- EA W162B-N3LW
- TC1602A-09
- LCD Displaytech 404B 4x40 Controller: KS0066U
- TC1602E (aus dem Pollin Addon-Board)

Karlheinz Druschel schrieb:

> @Karlheinz Buchegger: Ich mache immer ein "Rebuild All" (sind ja nur
> zwei Dateien), und wenn ich den Text ändere, dann klappt das auch.

OK.
Zeig jetzt bitte deinen tatsächlich verwendeten Source Code.

Es hat da im Tutorial mehere Versionen gegeben.

Das ist der hier

So, jetzt habe ich noch ein altes Displaytech 204B gefunden und 
angeschlossen: Gleiches Verhalten. Am Displaycontroller scheint es also 
nicht zuliegen

Karlheinz Druschel schrieb:
> Das ist der hier

?
Warum steht hier immer noch

#define LCD_DDADR_LINE1         0x00
#define LCD_DDADR_LINE2         0x40
#define LCD_DDADR_LINE3         0x10
#define LCD_DDADR_LINE4         0x50

Weil es nicht sein Quelltext ist, den er hier unbedingt zu
zeigen zu vermeiden sucht, sondern seine Vorlage :-)

Nein, ich probiere halt nur ständig rum. Das ist mein Quelltext!

Dann probiere doch mal die Werte aus 
Beitrag "Re: Zeilenadressen LCD 4x20 blau"

Einer von diesen beiden wird es doch sein.

In "deinem" Quelltext steht keine der beiden Varianten.

Ok, Thema erledigt.
Ich verstehe zwar definitiv nicht den Zusammenhang, aber es ist wirklich 
so:
Nach der ganzen Probierei wollte mein Dragon auf einmal keinen 
Controller mehr programmieren. Also habe ich das AVR-Studio neu 
gestartet. Als auch das nicht geholfen hat, habe ich den kompletten PC 
neu gebootet. Und schlagartig geht das Display so wie es soll.
Kapier ich nicht

Ok, Thema erledigt.
Ich verstehe zwar definitiv nicht den Zusammenhang, aber es ist wirklich 
so:
Nach der ganzen Probierei wollte mein Dragon auf einmal keinen 
Controller mehr programmieren. Also habe ich das AVR-Studio neu 
gestartet. Als auch das nicht geholfen hat, habe ich den kompletten PC 
neu gebootet. Und schlagartig geht das Display so wie es soll.
Kapier ich nicht.
Ich weiss, das klingt so als hätte ich einen Fehler gemacht und wolle 
ihn nicht zugeben, ist aber wirklich so passiert!!!!!!!

Nochmals 1000Dank an alle die hier für mich Datenblätter gesucht, 
gewälzt und sonsto recherchiert haben....

Bitte.
Aber eine Frage noch:
Mit welchen Adressen geht es denn nun?

So gehts jetzt:
#define LCD_DDADR_LINE1         0x0
#define LCD_DDADR_LINE2         0x40
#define LCD_DDADR_LINE3         0x14
#define LCD_DDADR_LINE4         0x54

ok, Danke.
Dann brauche ich keinen neuen Typ in meiner Headerdatei vorsehen,
das ist ja der HD44780.

Und schon habe ich das nächste Problem:
Nachdem alles an PortD so funktioniert wie es soll, wollte ich das Ganze 
umverdrahten auf PortC.
Dazu habe ich im Quelltext (lcd_routines.h> folgendes geändert:
//////////////////////////////////////////////////////////////////////// 
////////
// Pinbelegung für das LCD, an verwendete Pins anpassen
// Alle LCD Pins müssen an einem Port angeschlossen sein und die 4
// Datenleitungen müssen auf aufeinanderfolgenden Pins liegen

//  LCD DB4-DB7 <-->  PORTD Bit PD0-PD3
#define LCD_PORT      PORTC
#define LCD_DDR       DDRC
#define LCD_DB        PC0

//  LCD RS      <-->  PORTD Bit PD4     (RS: 0=Data, 1=Command)
#define LCD_RS        PC4

//  LCD EN      <-->  PORTD Bit PD5     (EN: 1-Impuls für Daten)
#define LCD_EN        PC5

Alles neu kompiliert und Ergebnis: Geht nicht. Aber im Quellcode finde 
ich keine weitere Angabe von PORTD, es sollte also alles umgesetzt sein.
Die Verdrahtung habe ich auch schon mehrfach überprüft.
Wieso das jetzt ? Ist PortC anders zu handhaben als PortD ?

Welcher AVR?
Evtl. JTAG im Weg? Dann ggf. mit Fuses abstellen.

ATMega16 mit 8 MHz.
Programmiert habe ich über JTAG, aber danach den Stecker abgezogen und 
das Board neu eingeschaltet. Da sollte es doch gehen

Mußte man den JTAG Port nicht per Fuse abschalten, wenn man die Pins 
normal nutzen wollte?

Oder muss ich JTAG in den Fuses abschalten ?

Karlheinz Druschel schrieb:
> ATMega16 mit 8 MHz.
> Programmiert habe ich über JTAG, aber danach den Stecker abgezogen und
> das Board neu eingeschaltet. Da sollte es doch gehen

Und wer sagt dem Mega16, dass er die JTAG Pins jetzt nicht als JTAG Pins 
sondern als ganz normale I/O Pins benutzen soll?

Ok, danke für den Tip.
Da mein AVR-Dragon sich immer noch weigert über ISP zu proggen muß ich 
die Routinen wohl umschreiben, da ich kein ganzes Port mehr frei habe 
...

Danke für den Hinweis

Guten Tag,

Habe leider das gleiche Problem und komme der Sache nicht auf die 
Schliche.. :(

Wenn ich in die 3 Zeile schreiben möchte , schreibt er mir für

#define LCD_LINE1      0x00
#define LCD_LINE2      0x40
#define LCD_LINE3      0x14
#define LCD_LINE4      0x54

in das 17 Zeichen der 1. Zeile

und für :

#define LCD_LINE1      0x00
#define LCD_LINE2      0x40
#define LCD_LINE3      0x20
#define LCD_LINE4      0x54

in das 13 Zeichen in der 3. Zeile.

Dazwischen kann ich nicht schreiben.

Das Display ist über einen I2C Portexpander angeschlossen ( Pollin Board 
) und soll laut Hersteller einen KS0066U Display Treiber haben.

http://pdf1.alldatasheet.com/datasheet-pdf/view/132627/ETC1/JHD204A.html


Ich hänge die LCD routinen mal an.

Ich bin wirklich am verzweifeln.

Grüße
Dennis

Okay.. vielen Dank.
Kann ich das in meine Routine einbauen ? bzw. an welchem Punkt. Da dort 
ja ein "direkter" Zeilenzugriff implementiert ist.

Also Zeile 3 ist ab Adresse 0x??  usw...

Bzw. das Programm macht doch auch nichts anderes , als nach Zeichen "39" 
ab Adresse 0x14 weiterzuschreiben. Das wäre ja ohne hin die Zeile 3 wie 
sie bei mir definiert ist.

Auf Zeichen 0x14  zu schreiben bringt aber "scheinbar" nichts.

In dem verlinkten Dokument ist ein C-Beispiel drin, wo die Position 
etwas krude berechnet wird:

1

if (Position > 59)     //also ab 60=0x3C

2

   Position += 0x18;   //also plus 24, 4. Zeile ab 0x54

3

else if (Position > 39)//also ab 40=0x28

4

   Position -= 0x14;   //also minus 20, 3. Zeile ab 0x14

5

else if (Position > 19)//

6

   Position += 0x2C;   //also plus 44, 2. Zeile ab 0x40

Schreibe doch zum Test mal die Zeichen A-Z,a-z,0-9 der Reihe nach auf 
das Display. Dann siehst Du schon, wo die Zeichen landen.

Dennis Henning schrieb:
> Wenn ich in die 3 Zeile schreiben möchte , schreibt er mir für
>
> #define LCD_LINE1      0x00
> #define LCD_LINE2      0x40
> #define LCD_LINE3      0x14
> #define LCD_LINE4      0x54
>
> in das 17 Zeichen der 1. Zeile

das sind doch genau die Werte.. das Test Programm schreibt mir 1 und 2te 
Zeile ohne Probleme und ab der dritten schreibt er wieder ins 17. 
Zeichen der 1. Zeile.

Wie oben schon beschrieben.

Mein Gott du stellst dich aber auch an.

Gib halt einfach mal einen Haufen Zeichen aus!
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHI 
JKLMNOPQRSTUVWXYZ"  usw. usw.
Dann siehst du schon, welches das erste Zeichen in der 3. Zeile ist. 
Dann zählst du noch ab der wievielte Buchstabe das in deinem String war 
und du hast die Startadresse.
Und wenn dieser "Monstertext" nicht ausreicht, dann hängst du eben noch 
ein paar "ABCD.." hinten drann. Aber so, dass dir du im Nachhinein noch 
identifizieren kannst, welche Wiederholung das 1. Zeichen einer Zeile 
darstellt. Zur Not ersetzt du dann eben das erste "ABCD..." durch lauter 
Leerzeichen, oder machst abwechselnd einen Buchstaben und ein 
Sonderzeichen oder was auch immer.

Dem LCD ist das doch wurscht, das schreibt einfach die Zeichen 
nacheinander in der Speicher und der Anzeigeteil vom LCD holt sich dann 
ab einer bestimmten Startadresse die Zeichen und färbt die Pixel in der 
3. Zeile entsprechend. Also bügelst du einfach den Character-Speicher 
mit Zeichen voll und bei irgendeinem fängt der Anzeigeteil an, dafür die 
Pixel der 3. Zeile einzufärben. Du musst nur im Nachhinein abzählen 
können, welches Zeichen wo im Speicher gelandet ist.

Manchmal probiert man die Dinge einfach aus und überlegt sich eine 
Teststrategie anstatt lange rumzurechnen und es dann doch nicht 
rauszukriegen.


Edit:
Aber nimm die lcd_print, die ohne Ansehen von irgendwelchen 
Zeilenstrukturen einfach die Zeichen rausgibt.