Ich habe mir den avr-lcd lib unter folgender URL geladen:
http://homepage.hispeed.ch/peterfleury/avr-lcd44780.html
Daran folgende Anpassungen vorgenommen: 1 | ...
| 2 | #define XTAL 7372800
| 3 | ...
| 4 | #define LCD_LINES 4
| 5 | ...
| 6 | #define LCD_START_LINE3 0x10
| 7 | #define LCD_START_LINE4 0x50
| 8 | ...
| 9 | #define LCD_DATA0_PIN 7
| 10 | #define LCD_DATA1_PIN 6
| 11 | #define LCD_DATA2_PIN 5
| 12 | #define LCD_DATA3_PIN 4
| 13 | #define LCD_RS_PIN 3
| 14 | #define LCD_RW_PIN 1 /** Nicht benutzter Port */
| 15 | #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 1 | 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:
1 | $regfile = "m32def.dat"
| 2 | $crystal = 7372800
| 3 |
| 4 | Config Lcdpin = Pin , Rs = Porta.3 , E = Porta.2 , Db4 = Porta.7 , Db5 = Porta.6 , Db6 = Porta.5 , Db7 = Porta.4
| 5 |
| 6 | Config Lcd = 16 * 4
| 7 |
| 8 | Cls
| 9 | Lcd "test"
| 10 | Lowerline
| 11 | Lcd "12345678"
| 12 | 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
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.
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
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
@ 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
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
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 1 | lcd_command( 0x28 ); // 2 lines 5*7
| 2 | lcd_command( 0x08 ); // display off
| 3 | lcd_command( 0x01 ); // display clear
| 4 | lcd_command( 0x06 ); // cursor increment
| 5 | lcd_command( 0x0C ); // on, no cursor, no blink
|
Laut datenblatt müsste es aber 1 | lcd_command( 0x02 ); // 4-Bit Datenlaenge, 1-zeiliges Display, 5x7 Font
| 2 | lcd_command( 0x0F ); // Display ein, Cursor ein, Cursor blinken
| 3 | lcd_command( 0x01 ); // Display loeschen, Cursor auf 1. Spalte von 1. Zeile
| 4 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|