ich versuche jetzt schon seit 2 tagen vergeblich mein 1x16 lcd-display
(hd44780) an einem atmega32 zum laufen zu bringen. ich verwende die
peter fleury lcd-library ( http://jump.to/fleury ). das problem ist
jedoch das, dass der uC sich weigert die richtigen signale auszugeben.
außer einem signal am enable-pin erhalte ich nur lauter "highs"
in der lcd.h habe ich 16MHz eingestellt und hier sind die
pin-belegungen
#define LCD_PORT PORTC
#define LCD_DATA0_PORT LCD_PORT
#define LCD_DATA1_PORT LCD_PORT
#define LCD_DATA2_PORT LCD_PORT
#define LCD_DATA3_PORT LCD_PORT
#define LCD_DATA0_PIN 0 <-hier hängt lcd datenport DB4 dran
#define LCD_DATA1_PIN 1 <- DB5
#define LCD_DATA2_PIN 2 <- DB6
#define LCD_DATA3_PIN 3 <- DB7
#define LCD_RS_PORT LCD_PORT
#define LCD_RS_PIN 4
#define LCD_RW_PORT LCD_PORT
#define LCD_RW_PIN 5
#define LCD_E_PORT LCD_PORT
#define LCD_E_PIN 6
das sollte doch eigentlich passen, oder? jtag-fuse ist übrigens richtig
gesetzt, auf anderen ports habe ich auch das selbe problem.
da es mein erstes avr-projekt ist bin ich fast sicher irgendeine
kleinigkeit übersehen zu haben, aber soetwas wie die ports vorab in
meinem program initialisieren ist doch nicht nötig, oder?
im programm habe ich momentan nur lcd_init sowie in einer schleife ein
lcd_home und ein lcd_puts.
hoffe mir kann jemand helfen, danke schon mal im voraus :)
Kommt direkt nach dem Einschalten auf dem Display eine Reihe schwarzer
Kästchen? Wenn nein, dann prüfe mal die Kontrasteinstellung. Bei
einigen Displays kann sogar eine negative Kontrastspannung notwendig
sein (Hochtemperaturdisplay).
Siehe hier:
http://www.sprut.de/electronic/lcd/index.htm
Die Lib selbst sollte in Ordnung sein, da haben andere Forumites hier
schon erfolgreich mit gearbeitet.
Gruss
Jadeclaw.
ja, schwarze kästchen sind da. das display sollte in ordnung sein, habe
es vor einigen wochen problemlos mit einem anderen microcontroller
betrieben.
wie gesagt ist das hauptproblem ja das, dass der atmega keine signale
ausgibt
Bei Mega32 und PortC denke ich immer an das JTAG-Interface...
Setze zweimal direkt hintereinander das JTD-Bit in MCUCSR, dann ist
JTAG deaktiviert und dir steht PortC für I/O zur Verfügung.
Alternativ geht das auch per Fusebit, da sollte man aber genau bescheid
wissen.
...
Es empfiehlt sich auch, zu prüfen, ob die Datenrichtungsbits
(DDRx-Register) für die Ports richtig gesetzt sind. Das könnte man als
Initialisiertung der Ports ansehen, in weitestem Sinne.
danke für die antworten, aber am jtag liegt es nicht, die fuse ist
richtig gesetzt, außerdem betrifft das problem alle ports. das
data-direction-register sollte doch die library richtig setzen oder?
Ich bin mir da nicht so sicher, was die Library betrifft. Es kann nicht
schaden, die DDR-Register per Hand zu setzen. Außerdem würde ich
empfehlen, im Programm mal ein oder zwei der für das Display
vorgesehenen Portpins manuell umzuschalten, nur zu Debugzwecken.
Was hast Du schon ausprobiert:
- Schon mal einen anderen m32 probiert ?
- Die Initialisierung für 4 bit gewählt ?
- Einen anederen Port als PORTC getestet ?
- Anleitung für das Display geprüft (Initalisierung) ?
Du schreibst, dass Du es mit einem anderen uC erfolgreich getestet
hast. Eventuell mal den Code verglichen ?
Timingprobleme ? Ich würde im gessamten Code (auch delay.h) die Angaben
überprüfen. Falls Du AVRStudio einsetzt, setze F_CPU besser global über
die Optionen.
Ansonsten lass erst mal eine LED an einem anderen Port mitlaufen, nur
um zu sehen, ob das Display das Problem ist.
Funktioniert die LED auch, wenn alle LCD-Befehle auskommentiert sind ?
Pete
Hallo,
hab den gleichen Code verwendet, auch mit ATmega32, läuft auch NICHT !
Ich arbeite mit PortB, 20MHz. Die Steuerleitung E bringt einen Takt mit
3,2us Periodendauer, alle Pulse sind interessanterweise kurz
unterbrochen...
Da scheinen die Macros nicht zu stimmen?! Oder gibt's etwas wie
"Known bugs" zu diesem Code???
Gibt's denn noch anderen C-Code, den ich mal ausprobieren könnte ?
Gruss, Dieter
Ja. Hier ein C-Code zum Ausprobieren. Sollte funktionieren, ist aus
einem erprobten Programm ausgeschnitten.
Allerdings ist dieses Beispiel nur für den 8-Bit Modus brauchbar.
Eine manuelle Anpassung der verwendeten Ports ist natürlich
erforderlich. Und ja, ich weiß, daß das schlechter Stil ist. Aber ich
bin Anfänger und hatte keine Zeit.
Übrigens ist dieser Code für ein 16-stelliges Display, das sich wie ein
zweizeiliges verhält. (So etwas ist auf der von Jadeclaw erwähnten Seite
erklätz). Für ein echt einzeiliges, d.h. mit 2 Chips auf der Platine,
muß die Initialisierung geändert werden. Sehen sollte man aber auf
jeden Fall etwas.
> Hast du die übrigen Datenleitungen D0 bis D3 auf Masse gelegt?
Wozu? Die läßt man frei hängen. Mach ich zumindest so. Gab bei >10
verschiedenen LCDs nie Probleme. Ich glaube auch der HD44780 hat
interne Pull[ups|downs].
Danke Sebastian Eckert, aber ich brauch die 4-Bit Lösung und fürchte,
dass ich mit dem Umbau nur ein weiteres Code-Grab öffne...
Es bleibt mir wohl nicht's anderes übrig, als das Rad zum 1.Mio-sten
Mal neu zu erfinden...
Na ja, ich hatte damit Probleme, bis diese Pins definiert auf Low gelegt
wurden. Wobei bei mir, soweit ich mich da zurückerinnern kann, nur ein
HD44780 kompatibles Display. Ob der verbaute Controller auch Pull-Ups
hat, weiß ich demnach nicht.
Ich fürchte ja. Viel Erfolg damit. Übrigens, falls noch nicht bekannt
(und als Hilfe für die Programmierung), es gab mal eine ausführliche
Display-Doku auf Deutsch, von Electronic Assembly. Finde den Link bloß
nicht mehr.
ich hatte heute endlich zeit mich mit dem problem wieder auseinander zu
setzen. nach 3 stunden herumgetue und schreiben einer eigenen
initialisierung kam ich zu dem ergebnis dass mein display einfach
defekt war. lag wohl daran, dass ich anfangs versehentlich +5V anstelle
der negativen Spannung für den Kontrast gelegt hatte...
Hab mein Display jetzt auch zum sprechen gebracht.
Da ich mit 20MHz takte, hat der Code an 2 Stellen Probleme gemacht:
Es gibt delay(16000), wenn ich das Makro mit 20MHz rechne kommt 80000
raus, was fuer 16 Bit zu gross ist.
Hab alle delay(16000) auf 2 Aufrufe a 8000 gesetzt.
Dann ist da noch eine Stelle in lcd.c (Zeile 45) wo fuer die E-Leitung
ein Delay ohne Berücksichtigung der Taktfreq. des uC gemacht wurde.
Dort muessen min. 500ns delay entstehen. Ich hab das Makro mit delay(1)
ersetzt.
Nach anfänglichem Aerger ueber den Code, muss ich jetzt doch sagen: er
ist bis auf die beiden Faelle echt gut geschrieben!
Gruesse, Dieter
