mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega8 und LCD HD44780 nur erste Zeile leuchtet


Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Tu...

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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli R. (downunderthunder42)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes M. (johannesm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__... gibts 
auch noch ein paar Infos)

Häng mal deinen Programmcode als Anhang dran, in den Bilder etwas zu 
suchen ist etwas unpraktisch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Olli R. (downunderthunder42)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Daten erzeugen eine Datei LCDbasics.elf.
Passt also nicht zu deinem Bild oben.

>muss wirklich ein eigenes "makefile" verwenden?

Nein.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hubert G. (hubertg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hubert G. (hubertg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am timing liegt es sicher nicht, mein LCD initialisiert sogar mit einem 
7,37MHz Quarz noch, der Text ist dann nur etwas zerstückelt.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli R. (downunderthunder42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.