Display zeigt nichts an.

[Christian M. (cmeckler)]

Ich habe mir den avr-lcd lib unter folgender URL geladen:
http://homepage.hispeed.ch/peterfleury/avr-lcd44780.html

Daran folgende Anpassungen vorgenommen:

...
#define XTAL 7372800 
...
#define LCD_LINES           4
...
#define LCD_START_LINE3  0x10
#define LCD_START_LINE4  0x50
...
#define LCD_DATA0_PIN    7            
#define LCD_DATA1_PIN    6            
#define LCD_DATA2_PIN    5            
#define LCD_DATA3_PIN    4            
#define LCD_RS_PIN       3            
#define LCD_RW_PIN       1            /** Nicht benutzter Port         */
#define LCD_E_PIN        2

mit dem Ergebnis:
beim Aufrufen der funktion lcd_init bleibt er stecken.
aus lcd_init wird lcd_command(LCD_FUNCTION_DEFAULT) aufgerufen,
aus  lcd_command wird _lcd_waitbusy()_ aufgerufen,
und in lcd_waitbusy bleibt er hier stecken

while ( (c=lcd_read(0)) & (1<<LCD_BUSY)) {}

Kommentier ich die Funktion aus, schreibt er kauderwelsch (Muell) auf 
dem Display


Datenblatt des Display
http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=1;INDEX=0;FILENAME=A500%252FLCD164ABL%2523EAS.pdf;SID=265L3wqqwQARoAABlwdfU23ccc90cb2e797aba8f766dd7bb0c0d2



In Bascom gibt es keine Probleme:

$regfile = "m32def.dat"
$crystal = 7372800

Config Lcdpin = Pin , Rs = Porta.3 , E = Porta.2 , Db4 = Porta.7 , Db5 = Porta.6 , Db6 = Porta.5 , Db7 = Porta.4

Config Lcd = 16 * 4

Cls
Lcd "test"
Lowerline
Lcd "12345678"
End

Andere Quelltexte habe ich ausprobiert, viele gingen nicht, da diese zu 
statisch in der Pinvergabe waren.
Wenn jemand einen anderen Quelltext hat waere ich auch zufrieden.

Danke im vorraus

Nachtrag:
MCU: ATmega32 7,372800 Mhz
LCD-BUS: 4-Bit
Entwicklungsumgebung: avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Programmer: myAVR.de AVR ISP Programmer + avrdude + gui

[Stefan B. (stefan)]

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#LCD-Ansteuerung

Die avr-lcd Library von Peter Fleury testet das Busyflag des LCD ab, um 
mitzubekommen wann das LCD wieder bereit ist neue Daten anzunehmen. Dazu 
wird die RW-Leitung vom µC von/zum LCD und eine Datenleitung (DB7) 
benötigt.

Im Gegensatz dazu wird in der Bascom Library (und vielen anderen 
Implementierungen) einfach eine Zeit lang gewartet in der Hoffnung, dass 
alle LCD Befehle entsprechend dem LCD Controller Datenblatt ausgeführt 
und abgeschlossen sind. Hier ist die RW Leitung fest auf GND.

Man muss seine Platine/Schaltung also genau ansehen/planen, dass die RW 
Leitung auch zum µC gelangt, wenn man die avr-lcd Library einsetzen 
will. Ansonsten wartet die Library ewig - genau der von die beschriebene 
Effekt.

[Michael U. (amiga)]

Hallo,

auch wenn es nur indirekt damit zutun hat, wie kommt man zu solch einer 
Bitzuordnung???

#define LCD_DATA0_PIN    7
#define LCD_DATA1_PIN    6
#define LCD_DATA2_PIN    5
#define LCD_DATA3_PIN    4

Egal, ob in Basic, C oder ASM: mal eine Sekunde darübernachgedacht, 
welche Bitschieberei o.ä. das letztlich auslöst?

Vermutlich werden nur wenige Bibliotheken das freiwillig unterstützen, 
üblich wäre wohl:

#define LCD_DATA0_PIN    4
#define LCD_DATA1_PIN    5
#define LCD_DATA2_PIN    6
#define LCD_DATA3_PIN    7

um letztlich mit einem swap registern und and register auszukommen.

Auch ein Compiler mu das ja irgendwie in eine ASM-Befehlskette 
übersetzen die der AVR in Hardware kann.

Gruß aus Berlin
Michael

[Peter D. (peda)]

Michael U. wrote:

> Egal, ob in Basic, C oder ASM: mal eine Sekunde darübernachgedacht,
> welche Bitschieberei o.ä. das letztlich auslöst?

Ach das geht schon, sind etwa 6 Befehle mehr (0,6% beim ATtiny24).


> Vermutlich werden nur wenige Bibliotheken das freiwillig unterstützen,

Doch, z.B.:

http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip

Ich mag es auch, wenn ich beim Layout die größtmöglichste Freiheit habe.


Peter

[Falk B. (falk)]

@ Peter Dannegger (peda)

>> Egal, ob in Basic, C oder ASM: mal eine Sekunde darübernachgedacht,
>> welche Bitschieberei o.ä. das letztlich auslöst?

>Ach das geht schon, sind etwa 6 Befehle mehr (0,6% beim ATtiny24).

Naja, die Performance bei so einem LCD ist sicher nicht so kritisch. 
Aber wie willst du vier Bits mit 6 Befehlen so umsortieren? Ich brauch 
da spontan acht (bset, bld).

MFg
Falk

[Peter D. (peda)]

Falk Brunner wrote:

> Aber wie willst du vier Bits mit 6 Befehlen so umsortieren?

Hab ich auch nicht behauptet.

Es sind 6 mehr bezogen auf die Nibble AND/ORierei.
Schließlich sollen ja die unbenutzten Portpins erhalten bleiben und der 
Wert fürs 2. Nibble.


Peter

[Christian M. (cmeckler)]

Danke Peter Dannegger,

Deine Source hat mir geholfen.

Habe Änderungen an dem Takt, IO-Pins sowie in lcd_pos vorgenommen.
Nun kann ich mein 4*16 Zeilen Display ansprechen.
Den Pfad der Header Files musste ich auf \avr\ umändern

Was ich überhaupt nicht verstehe, ist die INIT

  lcd_command( 0x28 );      // 2 lines 5*7
  lcd_command( 0x08 );      // display off
  lcd_command( 0x01 );      // display clear
  lcd_command( 0x06 );          // cursor increment
  lcd_command( 0x0C );      // on, no cursor, no blink

Laut datenblatt müsste es aber

  lcd_command( 0x02 ); // 4-Bit Datenlaenge, 1-zeiliges Display, 5x7 Font
  lcd_command( 0x0F ); // Display ein, Cursor ein, Cursor blinken
  lcd_command( 0x01 ); // Display loeschen, Cursor auf 1. Spalte von 1. Zeile
  lcd_command( 0x06 ); // Cursor Auto-Increment

macht aber irgendwie keinen Unterschied ???

ich habe dir die Source im Anhang nochmal gepakt.

Gruß aus der schönen Südpfalz