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].
Ah ja: http://web.media.mit.edu/~ayah/documents/hd44780u.pdf Seite 54. Die Datenpins haben interne Pullups. Also vollkommen sinnlos da bei den freien Pins irgendwas zu beschalten.
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...
Ärgerlich sowas, kann aber vorkommen. Mehr Glück beim nächsten Mal.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.