LCD 204B-NLW & AtMega32

Hallo

Klaus Wachtler schrieb:
> alex44 schrieb:
>> Im Datenblatt steht am Rand ein Kommentar:
>> "Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig"
>
> Wenn man jeweils lange genug wartet, braucht man kein BUSY abfragen.
> Siehe oben.

"Merkt" das LCD, ob es abgefragt worden ist? Ich glaube nicht. Die 
Anfrage ist dann nur für den Datensender interessant.


Klaus Wachtler schrieb:
> Ein weiterer Fallstrick ist die Taktfrequenz: wenn der Rechner schneller
> läuft, als der Compiler vermutet (F_CPU), dann stimmen die Wartezeiten
> nicht.
> Zur Kontrolle lasse ich gerne mal mit delay_ms(1000) eine LED blinken;
> dann sieht man schnell, ob eine Sekunde wirklich eine Sekunde ist.

Die eingestellten Zeiten stimmen. Konnte ich nachmessen.


Ich habe mal im Datenblatt nachgeschaut. Kann es an den Flanken und an 
den Pulslängen liegen?
Da steht:
- max   25ns - Flankenanstieg
- min 0,45us - Enable Impuls high
- min 1,00us - Enable Zyklus
- min 0,14us - Address setup
Besonders beim ersten steht im Blatt: "besonders zu beachten". Ich kann 
das mit meinem Oszi nur nicht genau messen, da ich nur bis 0,5us runter 
kann.

Ich werde mal ein kleines Testprogramm ohne Routinen schreiben. Mal 
sehen was dabei rumkommt.


Klaus Wachtler schrieb:
> PS:
> Eine vernünftige HW-Beschreibung wäre zur Fehlersuche nützlich.

Was ist das?

Danke und Gruß
Alex

Wie hast du denn den Kontrastpin des LCDs(Pin3, Vee) angeschlossen? So 
wie im Tutorial 
(http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung)? 
Hast du dann mal am Poti gedreht?

Eventuell hast du einfach nur den Kontrast falsch eingestellt.

Eine Hardwarebeschreibung wäre, wenn du uns erklärst/veranschaulichst, 
wie du das LCD beschaltest hast und an den µC angeschlossen hast. 
Eventuell mit Schaltplan und einem Foto des Aufbaus.

Ansonsten kann man, ob der vielen Fehlermöglichkeiten nur raten, was bei 
dir konkret falsch sein könnte...

Hallo,

- VDD ist an einen 5V Spannungsregler angeschlossen.
- Vee ist über ein 10k Poti wie im Tutorial angeschlossen.
- LED+ hat einen 50 Ohm Vorwiderstand.

- D4 liegt an PC0
- D5 liegt an PC1
- D6 liegt an PC2
- D7 liegt an PC3

- RS liegt an PC4
- E liegt an PC6

- D0,D1,D2,D3,RW liegen auf GND

Da delay.h auf 10000000ul eingestellt ist habe ich das in die routinen.h 
so übernommen.

Dazu habe ich die routinen.h angepasst...

1

//  LCD DB4-DB7 <-->  PORTC Bit PC0-PC3

2

#define LCD_PORT      PORTC

3

#define LCD_DDR       DDRC

4

#define LCD_DB        PC0

5

6

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

7

#define LCD_RS        PC4

8

9

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

10

#define LCD_EN        PC6

Da es mein Display mit zwei verschieden Kontrollern gibt, habe ich beide 
ausprobiert:

für KS0073

1

#define LCD_DDADR_LINE1         0x00

2

#define LCD_DDADR_LINE2         0x20

3

#define LCD_DDADR_LINE3         0x40

4

#define LCD_DDADR_LINE4         0x60

für HD44780

1

#define LCD_DDADR_LINE1         0x00

2

#define LCD_DDADR_LINE2         0x40

3

#define LCD_DDADR_LINE3         0x14

4

#define LCD_DDADR_LINE4         0x54

Habe auch beides mit

1

 while(1)

2

  {

3

  lcd_string("Hello World!");

4

  }

in der main getestet.

Dann habe ich mal die Zeiten aus dem Datenblatt angepasst:

1

#define LCD_BOOTUP_MS           50

2

#define LCD_ENABLE_US           1

3

#define LCD_WRITEDATA_US        50

4

#define LCD_COMMAND_US          50

5

6

#define LCD_SOFT_RESET_MS1      5

7

#define LCD_SOFT_RESET_MS2      5

8

#define LCD_SOFT_RESET_MS3      5

9

#define LCD_SET_4BITMODE_MS     5

10

11

#define LCD_CLEAR_DISPLAY_MS    2

12

#define LCD_CURSOR_HOME_MS      2

Auch versucht habe ich in der init:

1

lcd_command( LCD_SET_DISPLAY |

2

             LCD_DISPLAY_ON |

3

             LCD_CURSOR_ON |

4

             LCD_BLINKING_ON);

ändert aber auch nichts

Was ich immer sehe, wenn ich den Kontrast hoch regele ist, sind jeweils 
ein Balken in Zeile eins und drei.

Ich hoffe, dass diese Informationen weiter helfen können...

Gruß
Alex

Der LED-Test funktioniert übrigens und die Signalzeiten konnte ich per 
Oszi messen und stimmen mit den Einstellungen überein.

hier noch das neueste Datenblatt zu dem LCD.

>- D0,D1,D2,D3,RW liegen auf GND

Dann lass D0..D3 einfach mal in der Luft hängen.

hat nichts geändert...

Dem Verständnis wegen: Was hätte es bringen können?

>hat nichts geändert...

Schade:(

>Dem Verständnis wegen: Was hätte es bringen können?

Normalerweise schliesst man diese Leitungen nicht an
GND an. Es soll wohl Displays geben die das wohl möchten,
aber die sind eher die Ausnahme. Ich hatte noch keins von den Dingern.

Falls dein Display einen Ks0073 Controller hat, dann reicht das hier 
nicht:
>für KS0073
>
>#define LCD_DDADR_LINE1         0x00

Allerdings solltest du auch deinen Anschluss zum
Display noch ein paar mal überprüfen. Hardwarefehler
waren hier zu mindestens 50% das Problem wenn das
LCD nicht geht.

Moment mal, ATMega32 und Portc? Dann JTAG abschalten;)

Na hui - JTAG
habe nochmal einen Anschlussplan vom Kontroller rangehäng. Welcher Pin 
ist da das Problem?

>habe nochmal einen Anschlussplan vom Kontroller rangehäng. Welcher Pin
>ist da das Problem?

TDI, TDO, TCK, TMS

Das scheint ganz schön kompliziert zu werden. Ich muss das 
softwareseitig lösen, damit ich den Quellcode später weiterreichen kann 
(was ich muss)

Habe da was im Datenblatt gefunden:

"When the JTAGEN fuse is unprogrammed, these four TAP pins are normal 
port pins and the TAP controller is in reset. When programmed and the 
JTD bit in MCUCSR is cleared, the TAP input signals are internally 
pulled high and the JTAG is enabled for Boundary-scan and programming. 
In this case, the TAP output pin (TDO) is left floating in states where 
the JTAG TAP controller is not shifting data, and must therefore be 
connected to a pull-up resistor or other hardware having pull-ups (for 
instance the TDI-input of the next device in the scan chain). The device 
is shipped with this fuse programmed."

Ich nehme mal an, dass man sich hier über den MCUCSR Fusebite hermachen 
und dort das bit JTD zu null setzen muss.

In der Registerübersicht findet sich weiter folgendes:

1

Address   | Name   | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 

2

$34 ($54) | MCUCSR | JTD   | ISC2  | –     | JTRF  | WDRF  | BORF  | EXTRF | PORF

Jetzt müsste ich eigentlich nur das Bit von der Addresse holen und das 
Entsprechenden Null setzen. Geht das so?:

1

#define JTD 7

2

MCUCSR |= (1<<JTD);

Reicht das, oder muss ich da noch was dazuschreiben? Kennt avrgcc die 
adresse wo das hinmuss, oder muss da noch was entsprechendes definieren?

Grüße

MCUCSR ist ein µC-Register und hat mit den Fuses nicht wirklich was zu 
tun.

Alex44 schrieb:
> Jetzt müsste ich eigentlich nur das Bit von der Addresse holen und das
> Entsprechenden Null setzen.

Nein, das Flag heißt nicht umsonst JTD ("JTAG Disable"). Du mußt es auf 
1 setzen.
Im Deinem angedeuteten Sourcecode ist es allerdings schon richtig. Nur 
das define ist Mist, das steht bereits in dem ensprechenden Headerfile 
drin.

es reicht dann einfach

1

MCUCSR |= (1<<JTD);

oben in meine main.c mit einzufügen!?

Was mich übrigens immer noch ziemlich stark irritiert ist, dass ein Bit 
nicht so gesetzt wird wie ich es meine programmiert zu haben.

Dazu habe ich folgendes ergänzt:
routinen.h

1

//  LCD RW      <-->  PORTC Bit PC5     (RW: 0=Write, 1=Read)

2

#define LCD_RW        PC5

routinen.c

1

void lcd_init( void )

2

{

3

    // verwendete Pins auf Ausgang schalten

4

    uint8_t pins = (0x0F << LCD_DB) |           // 4 Datenleitungen

5

                   (1<<LCD_RS) |                // R/S Leitung

6

                   (1<<LCD_EN) |                // Enable Leitung

7

                   (1<<LCD_RW);                 // RW Leitung             

8

    LCD_DDR |= pins;

9

10

    // initial alle Ausgänge auf Null

11

    LCD_PORT &= ~pins;

12

13

    // RW auf 0 setzen - LCD-Empfängt Daten

14

    LCD_PORT &= ~(1<<LCD_RW);    

15

...

16

}

dabei ist

1

    // RW auf 0 setzen - LCD-Empfängt Daten

2

    LCD_PORT &= ~(1<<LCD_RW);

doppelt gemoppelt, da das ja schon mit LCD_PORT &= ~pins; abgegolten 
sein sollte. Aber das alleine führte auch nicht zum Erfolg.

Ich konnte allerdings feststellen nachdem ich

1

MCUCSR |= (1<<JTD);

in die main.c eingefügt habe, dass sich die Ausgangsspannung an PC5 
komisch verhält. Ohne LED bekomme ich da ein high, mit LED fällt die 
Spannung auf ca. 2V ab.

Ich hoffe, dass das zur Fehlerfindung beiträgt.

Stefan Ernst schrieb:
> Nein, reicht nicht. Schau ins Datenblatt, was dort zu dem Bit steht.

Eine wenig hilfreiche Antwort. Hätte ich es verstanden, würde ich nicht 
fragen.

Trotz allem fand ich einen Hinweis in einem anderen Beitrag.

1

MCUCSR |= (1<<JTD);

2

MCUCSR |= (1<<JTD);

Einfach zweimal den Befehl und alles ist schick. Das Programm läuft ;-)

Danke für eure Hilfe :-)

Stefan Ernst schrieb:
> Nein? Du hast doch offensichtlich auf Grund dieser Antwort nochmal
> recherchiert und die Lösung gefunden, oder nicht?

Da hast Du Recht :)

Zu dem anderen: Ich habe es versucht zu lesen aber mit meinen 
Englischkenntnissen kann ich wirklich keinen beeindrucken. Von daher...

Nichts desto Trotz: Vielen Dank nochmal

>Trotz allem fand ich einen Hinweis in einem anderen Beitrag.
>
>MCUCSR |= (1<<JTD);
>MCUCSR |= (1<<JTD);
>
>Einfach zweimal den Befehl und alles ist schick. Das Programm läuft ;-)

Geht doch;) JTAG Fuse abschalten hätte auch gereicht und frisst
kein Flash.

Gibt es da noch einen anderen Weg?