Hallo ich habe ein Problem mit HD44780kompatiblen LED. Ich habe auf meinem ATmega8 das Beispielprogramm aus dem AVR GCC-Tutoial laufen lassen. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung Leider zeigt das LCD nur in der erste Zeile voll angesteurte Balken. Wenn ich das Programm aus dem Assembler Tutorial laufen lassen geht es auch nicht mehr? Es ist auch egal welches meiner baugleichen LCDs ich verwende. Angeschlossen ist es genau wie im GCC-Tutorial beschrieben --> an Port D?
Olli R. schrieb: > Wenn ich das Programm aus dem Assembler Tutorial laufen lassen geht es > auch nicht mehr? Was heißt in diesem Zusammenhang 'nicht mehr'? Hat es denn früher schon mal? > Angeschlossen ist es genau wie im GCC-Tutorial beschrieben --> an Port > D? Das lässt noch ein wenig Spielraum für andere Dinge. Wie schnell ist der µC? Wieviel Zeit gibst du dem LCD nach dem Anlegen der Stromversorgung, bis du es das erste mal ansprichst? Wie kompatibel ist es wirklich?
Karl heinz Buchegger schrieb: > Was heißt in diesem Zusammenhang 'nicht mehr'? Als ich vor einiger Zeit das Assembler-Tutorial angeschaut habe. Ich die LCD-Schaltung jetzt wieder aufgebaut. > > Hat es denn früher schon mal? nicht bei diesem Aufbau. Es ist allerdings alles korrekt angeschlossen. Ich habe es mehrfach überprüft. > Das lässt noch ein wenig Spielraum für andere Dinge. > Wie schnell ist der µC? Ich habe es mit internen 1MHz und über mehreren externen Oszillator (3,6864, 4 und 8 MHz) versucht > Wieviel Zeit gibst du dem LCD nach dem Anlegen der Stromversorgung, bis > du es das erste mal ansprichst? in der main(void) wird es quasi gleich mit dem Starten des µC initialisiert. Deshalb habe ich einfach mal ein _delay_ms(500) eingebaut. --Ohne Erfolg! > Wie kompatibel ist es wirklich? Es ging ja schon einmal und wie ich diesem Forum entnehmen kann nutzen es auch viele andere ohne Probs.
Ich habe jetzt das Ganze mit AVR-Studio simuliert. Dabei habe ich festgestellt, dass das Programm an einer bestimmten Stelle in der Funktion lcd_enable() nicht mehr weiterläuft siehe angehängtes Bild (bild2.png). Um dem Problem auf den Grund zu gehen, habe ich auch noch mal eine kurze while-schleife eingefügt. Der Rest des Programm wird dann nie ausgeführt. Also in dieser While-SChleife möchte ich eine LED an PORTB blinken lassen. Leider bleibt dann aber das Programm schon bei dem Befehl "PORTB |= (1<<PB0)" hängen. Wodran kann das liegen? Also normal ist das nicht?
Olli R. schrieb: > Wodran kann das liegen? Eventuell daran, dass while( 42 ) { ... } eine Endlosschleife ist, die nie verlassen werden kann, weil 42 immer als TRUE gewertet wird?
Auf den ersten Blick würde ich erstmal die Variablen aus den _delay_us(...); rausnehmen. (hier: http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html gibts auch noch ein paar Infos) Häng mal deinen Programmcode als Anhang dran, in den Bilder etwas zu suchen ist etwas unpraktisch.
Karl heinz Buchegger schrieb: > Olli R. schrieb: > >> Wodran kann das liegen? > > Eventuell daran, dass > > while( 42 ) > { > ... > } > > eine Endlosschleife ist, die nie verlassen werden kann, weil 42 immer > als TRUE gewertet wird? Falls das nicht klar war: Das war eine rhetorische Frage, du hast dir dein Programm mit einer Endlosschleife lahm gelegt. > Ich habe jetzt das Ganze mit AVR-Studio simuliert. Wenn du nicht noch irgendwo eine Endlosschleife eingebaut hast, dann hilft dir hier der Simulator nichts. Das ganze ist entweder ein Timingproblem oder es werden die falschen Bytes zum LCD übertragen. Beides kannst du aber mit dem Simulator nicht vernünftig abtesten. > Dabei habe ich festgestellt, dass das Programm an einer bestimmten > Stelle in der Funktion lcd_enable() nicht mehr weiterläuft siehe > angehängtes Bild Ich bin überzeugt davon, dass das Programm an dieser Stelle weiterlaufen würde. Nur dauert es eben seine Zeit bis der Simulator die Warteschleife für die µs abgearbeitet hat.
Olli R. schrieb: > Karl heinz Buchegger schrieb: >> Was heißt in diesem Zusammenhang 'nicht mehr'? > > Als ich vor einiger Zeit das Assembler-Tutorial angeschaut habe. Ich die > LCD-Schaltung jetzt wieder aufgebaut. > >> >> Hat es denn früher schon mal? > > nicht bei diesem Aufbau. Es ist allerdings alles korrekt angeschlossen. Wenn du es exakt gleich verdrahtet hast, wie damals, dann müsste es auch wieder in der Assembler Version funktionieren. Da die Assembler version schon einmal funktioniert hat, würde ich es erst mal wie im Assembler Tut verdrahten und den Assembler Code drauf loslassen.
Also im angehängten Code habe ich keine While-Schleife und das Programm
hängt dennoch an der Anweisung DDRB|= (1<<PB0); ??
/
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>
int main(void)
{
// Initialisierung des LCD
// Nach der Initialisierung müssen auf dem LCD vorhandene schwarze
Balken
// verschwunden sein
DDRB |= (1<<PB0);
PORTB |= (1<<PB0),
_delay_ms(500);
PORTB &= (1<<PB0);
lcd_init();
// Text in einzelnen Zeichen ausgeben
lcd_data( 'T' );
lcd_data( 'e' );
lcd_data( 's' );
lcd_data( 't' );
// Die Ausgabemarke in die 2te Zeile setzen
lcd_setcursor( 0, 2 );
// erneut Text ausgeben, aber diesmal komfortabler als String
lcd_string("Hello World!");
while(1)
{
}
return 0;
}
>Also im angehängten Code habe ich keine While-Schleife und das Programm >hängt dennoch an der Anweisung DDRB|= (1<<PB0); ?? Vieleicht hast du einen Kurzschluss auf PB0 und dein uC startet deshalb immer wieder neu.
holger schrieb: > Vieleicht hast du einen Kurzschluss auf PB0 > und dein uC startet deshalb immer wieder neu. Nein, das kann nicht sein ich habe ein einfaches Assemblerprogramm drübergejagt und es schaltet die an PB0 angeschlossene Diode an bzw. aus.
>Nein, das kann nicht sein ich habe ein einfaches Assemblerprogramm >drübergejagt und es schaltet die an PB0 angeschlossene Diode an bzw. >aus. Ok, dann schmiert er wohl bei _delay_ms(500); ab. Was für einen Controller verwendest du? Ist der im makefile eingetragen? Hast du die Optimierung eingeschaltet? Gibt es warnings vom Compiler? Bist du sicher das du auch die richtige HEX Datei brennst? Poste das ganze Projekt als *.zip.
Angehängte Dateien:
-
compiler_default.png
46 KB
Ok ich füge hier mal das Ganze als rar angefügt. Also ich habe nun die Befürchtung, dass es am Makefile liegt: --> ich nutze die Standardeinstellungen von AVR-Studio Die Einstellungen habe hier als Bild angefügt. Ich verwende den ATmega8: >/ >// Anpassungen im makefile: >// ATMega8 => MCU=atmega8 im makefile einstellen >// lcd-routines.c in SRC = ... Zeile anhängen >// was hat das mit dem SRC = ... da auf sich. muss wirklich ein eigenes "makefile" verwenden?
Deine Daten erzeugen eine Datei LCDbasics.elf.
Passt also nicht zu deinem Bild oben.
>muss wirklich ein eigenes "makefile" verwenden?
Nein.
Ok also an einem falschen oder fehlerhaften makefile kann es nicht liegen. Dennoch bleibt das Programm in der Simulation bei der Anweisung stehen. Aber ich habe nun auch gemerkt, dass das nichts zu sagen hat ein einfaches Prgramm, dass eine LED togglet. läuft jetzt auch. Das bringt mich auf meine ursprüngliche Frage zurück: Warum klappt denn nun die Ansteuerung des LCD nicht? weder mit dem C-Code als auch mit Assembler-Programmen? Die LCD können doch jetzt nicht alle defekt sein?
Olli R. schrieb: > Dennoch bleibt das Programm in der Simulation bei der Anweisung stehen. Nochmal. Sie steht nicht. Der Simulator simuliert die _delay_ms(500) durch. Ja, das kann schon ein paar Minuten dauern! Auch kann man mit einem F10 nicht sinnvoll über einen _delay_ms drübersteppen. Mach dir in die Zeile danach einen Breakpoint und lass den Simulator mit F5 laufen. Du wirst sehen nach einiger Zeit meldet sich der Simulator von dort.
Karl heinz Buchegger schrieb: > Nochmal. Sie steht nicht. > Der Simulator simuliert die _delay_ms(500) durch. Ok das ist mir nun auch klar. Deswegen habe ich zu meiner eigentlichen Frage zurückkehren wollen. Also gibt es ein Problem mit dem LCD? Aber welches?
Olli R. schrieb: > Aber welches? Gute Frage. In den meisten Fällen * ist das Timing zu knapp eingestellt * wird den LCD nach dem Hochfahren nicht genug Zeit gelassen * ist die Verkabelung anders, als im Pgm eingetragen Ich hätte dein Pgm gerne getestet, aber ich hab kein LCD, welches ich so wie bei dir angegeben verdrahten kann. Da dein LCD schon mal funktioniert hat, können wir wohl den Punkt "doch nicht so kompatibel wie gedacht" abhaken. Ich würde nochmal die Verkabelung durchmessen. Durchgangsprüfer: direkt am AVR Pin mit der einen Prüfspitze, die andere Prüfspitze am Lötauge am LCD. Jede einzelne Leitung systematisch durchgehen.
Karl heinz Buchegger schrieb: > In den meisten Fällen > * ist das Timing zu knapp eingestellt hmmh habe ich getestet, indem ich in der lcd-routines.h die zeiten mal verzehnfacht habe. Das Problem besteht weiterhin. > * wird den LCD nach dem Hochfahren nicht genug Zeit gelassen Antwort wie oben: habe ein delay eingefügt. --> Ohne Erfolg > * ist die Verkabelung anders, als im Pgm eingetragen Habe ich mehrfach überprüft außerdem habe ich die Kabel alle durchgemessen. --> Alle Verbindungen, die vorhanden sein sollen, sind da. --> Kein Kurzschluss zwischen irgendwelchen Datenleitungen. Das Problem besteht ja bei allen 3 Displays. Wobei ich als ich vor einiger Zeit das erste ausprobiert habe, das Display funktionierte. Nach einiger Zeit, zeigte diese LCD den hier beschriebenen Fehler. Ich habe mir nichts dabei gedacht und habe das 2te LCD angeschlossen, das prompt funktionierte. Einen Tag später habe ich das vermeintlich defekte LCD wieder angeschlossen und es ging auch wieder. Aber nach einiger war die Funktion wieder nicht mehr gegeben? Ich mag mir aber nur schwer vorstellen, dass gleich alle 3 LCDs kaputt sind?
Das Programm ist OK, auf meinem LCD erscheint sofort Test und Hello World! Das ist wohl das LCD ausserhalb der Spezifikationen oder ein HW-Fehler. Vielleicht ist auch nur R/W nicht auf GND.
Am timing liegt es sicher nicht, mein LCD initialisiert sogar mit einem 7,37MHz Quarz noch, der Text ist dann nur etwas zerstückelt.
Hubert G. schrieb: > Das Programm ist OK, auf meinem LCD erscheint sofort Test und Hello > World! > Das ist wohl das LCD ausserhalb der Spezifikationen oder ein HW-Fehler. > Vielleicht ist auch nur R/W nicht auf GND. Doch R/W liegt auf GND. Hmmh ich habe mir jetzt mal ein paar andere LCD bestellt. (Nicht mehr diese Chinaware) in den Farben Rot und Grün. Wenn dein LCD auf Anhieb läuft, wird es wohl ein HW-Fehler sein?
Olli R. schrieb: > Wenn dein LCD auf Anhieb läuft, wird es wohl ein HW-Fehler sein? Denke ich. Allerdings: Da du mehrere LCD hast, die alle nicht funktionieren würde ich mal eher in Richtung Kabel, Steckverbinder, Stromversorgung tippen.
Karl heinz Buchegger schrieb: > Allerdings: Da du mehrere LCD hast, die alle nicht funktionieren würde > ich mal eher in Richtung Kabel, Steckverbinder, Stromversorgung tippen. Ja so viele Kabel sind ja im 4Bit-Modus nicht zu überprüfen. Und ich hab' sie alle mehrfach überprüft. Die LCD sind alle vom selben "Chinahändler" vielleicht sind die alle gleich labil gewesen!
Also ich habe nun 4 weitere LCD bekommen. Diesmal von einem anderen Lieferanten. Diese funktionieren ebenfalls nicht. Also wo könnte das Problem noch liegen?
Ich kann mich nur wiederholen: Ziemlich sicher nicht am LCD selber. Wenn du selber nichts findest, mach mal * Photo der Verschaltung. Aber so, dass man die Verschaltung hier nachvollziehen kann! * aktuelle Fusebit Einstellung auslesen und hier posten (Screen Shot) * komplettes Projekt, so wie du es brennst, hier posten
Ich habe den Fehler gefunden. Und ich sollte mich selbst dafür geißeln. --> Beim Aufräumen meines Steckbrettes habe ich wohl zu viele Kabel gezogen -- irgendwie war Pin 7 (Vcc) nicht gesteckt) (seltsamerweise hat der µC Trotzdem funktioniert (Also ich konnte PortB ohne Probleme betreiben etc.) Dann habe ich den PIN "PD5" einfach (weil fortlaufend) auf Pin 7 (Vcc) des ATmega8 vermutet. (PD5 liegt aber auf Pin11) Jetzt ist mir das endlich aufgefallen und ich hab's geändert. Allen Vielen Dank, die mir hier versucht haben zu helfen. Ich war mal einfach zu blöd. Naja nun habe ich 4 weitere LCDs. Das hat ja auch was. Jetzt kann ich Text entweder blau, grün oder orange darstellen. Viele Grüße Olli
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.