LCD-Display an ATmega32 hängt sich auf

[Erik L. (flatsoundz)]

Hallo,

dies ist mein erster Beitrag und nach erfolgloser Suche im Forum 
schreibe ich jetzt auch mal mein Problem auf. Zuerst aber: Hallo, ich 
bin der Neue :)

Ich sitze an einer fertigen Schaltung, in der ein ATmega32 Messdaten 
verarbeitet und auf einem LCD-Display (W204B-NLW) ausgibt. Das 
funktioniert auch wunderbar unter einer Bedingung!

Zwischen der Platine mit dem µC und dem Display selbst befindet sich ein 
Flachbandkabel. Beim Testen benutzte ich ein recht kurzes Kabel (ca. 
10cm), womit alles super funktionierte. Jetzt, nachdem die Platinen in 
einer Box verbaut sind, benötige ich ein längeres Kabel, (ca. 35cm).
Mit diesem kommt beim LCD nichts mehr an oder sagen wir: nur mit Glück.
Geplant ist eine Willkommensroutine (Welcome...etc.) und danach die 
Anzeige der Messdaten. Ich weiß nicht, ob sich das Display "aufhängt" 
oder der µC. Der Punkt ist, dass es mit verschiedenen kurzen Kabeln 
funktioniert und mit längeren nicht.

Meine Ideen: Muss ich die Ausgänge durch Treiberstufen verstärken? Wenn 
ja, geht das auch bei den Datenleitungen?
Sollte ich den µC nah an das Display platzigen und wenn ja, warum?
Mach ich vielleicht etwas ganz anderes falsch?

Ich poste kurz den Ausschnitt aus dem Schaltplan.

Danke im Voraus!

[Karl H. (kbuchegg)]

Na ja.
35cm sind jetzt noch nicht sooo lang.
Wenn ich bedenke, welch wilde Aufbauten ich vom µC über Kabel mit 
drangesteckter Verlängerung auf ein Steckbrett, dort über wilde 
Verkabelung mit Drahtbrücken zu einem LCD ich schon gebaut habe.

Kabel ist durchgemessen. Kein Wackelkontakt?
Eventuell das Timing etwas unkritischer machen, sprich alle Wartezeiten 
bei den Ausgaberoutinen etwas länger machen.

[Hc Z. (mizch)]

35 cm sollten schon gehen, wenn es sich um keine störverseuchte Umgebung 
handelt.

Viel eher halte ich es für möglich, dass das Timing von vornherein arg 
knapp ist.  Beliebt ist für so was z.B., dass E und die Kontrollsignale 
und/oder Daten gleichzeitig in der Software angelegt werden, obwohl vor 
dem Anlegen von E eine Vorlaufzeit für die anderen Signale einzuhalten 
ist (und auch eine Nachlaufzeit nach dem Wegnehmen von E).  Das ist aber 
nur ein Beispiel.

[Klaus W. (mfgkw)]

Das hängt wohl auch vom Typ ab.

Mit einem blauen 4x20 von EA hatte ich auch bei gut
30 cm gelegentlich Hänger des LCD  gesehen.

[Erik L. (flatsoundz)]

Danke für die schnellen Antworten.

ja...das ist eins dieser blauen LCD-Displays. Die Sache mit dem Timing 
werde ich mir mal anschauen. Kann man vielleicht einfach auch den µC 
runtertakten?

Ist damit die Frage geklärt, ob sich eigentlich das LCD aufhängt oder 
der Mikrokontoller selbst? Die Datenleitungen sind noch aktiv.

Zu dem Kabel an sich: ich habe mehrere verschiedene probiert und 
natürlich auch vorher durchgemessen. Die Funktionalität war bei allen 
nur abhängig von der Länge.

[Hc Z. (mizch)]

> Die Sache mit dem Timing
> werde ich mir mal anschauen. Kann man vielleicht einfach auch den µC
> runtertakten?

Falls genau das beschriebene Problem vorliegt: Nein.

[Karl H. (kbuchegg)]

Erik L. schrieb:

> ja...das ist eins dieser blauen LCD-Displays. Die Sache mit dem Timing
> werde ich mir mal anschauen. Kann man vielleicht einfach auch den µC
> runtertakten?

Kann man.
Aber wozu?
Welche LCD Library benutzt du?

Normalerweise konzentriert sich ja die Datenübertragung auf lediglich 1 
oder 2 Funktionen.

Da fällt mir auch noch ein:
In vielen LCD-Librarys muss man die Taktfrequenz des Kontrollers 
irgendwo angeben. Diese Angabe hast du gemacht?

> Ist damit die Frage geklärt, ob sich eigentlich das LCD aufhängt oder
> der Mikrokontoller selbst?

Ich denke mal: weder noch.

Die Kommandos vom µC werden höchst wahrscheinlich ein wenig zu schnell 
zum LCD geschickt, bzw. die Wartezeiten die zb zwischen Anlegen der 
Daten und aktivieren der E-Leitung ablaufen müssen, sind etwas zu kurz.

Geh deine LCD Funktionen durch. Bei allen Aufrufen einer Funktion die 
delay oder wait oder so ähnlich heißt, gibst du überall (hausnummer) 10% 
dazu.


Probehalber, aber wirklich nur probehalber, kannst du ja mal den Quarz 
mit seinen 16Mhz wegschalten und auf 8Mhz internen Oszillator gehen 
(aber nicht das Programm neu compilieren. Es ist Absicht das 'Programm' 
hier anzulügen). Wenns dann besser klappt, dann werden es wohl 
Verzögerungszeiten sein, die ein wenig länger zu machen sind.


Deine Frage lässt in mir aber einen Verdacht aufkeimen:
Dein µC arbeitet auch wirklich mit dem Quarz und den 16Mhz? Dazu müssen 
Fuses umgestellt werden. Hast du das gemacht?

[Klaus W. (mfgkw)]

Wenn die Datenleitungen noch zappeln (und der MC nicht
dauernd resettet) wird es wohl das Display sein.

Ich habe da noch einen Verdacht: Die mit der blauen Beleuchtung
ziehen ordentlich Strom.
Vielleicht ist ja auch die Spannungsversorgung etwas knapp?
Testweise könnte man doch die +5V extern zuführen und/oder
einen dicken Elko direkt am LCD spendieren, vielleicht wird
es ja dann besser.

[holger (Gast)]

Kleiner Tip anderer Art: Unbenutzte Pins nicht auf Masse legen
sondern den internen Pullup ein- bzw. den Pin auf Ausgang schalten.
So hätte ich zu viel Angst evtl. doch mal unbeabsichtig auf Ausgang
zu wechseln und zu allem Unglück den auch noch High zu legen.

[Erik L. (flatsoundz)]

Die Beleuchtung des Displays habe ich schon abgeschaltet, das Problem 
war damit leider noch nicht behoben. Diesen Punkt hab ich schon in einem 
anderen Beitrag gefunden.

Die Fuses sind richtig eingestellt, ich arbeite mit einem 16MHz Quarz.

Ansonsten verwende ich die LCD-Library von Peter Fleury. Dem Tipp mit 
den kürzeren Delay-Zeiten werde ich gleich mal angehen.

[MarioT (Gast)]

Erik L. schrieb:
> Dem Tipp mit
> den kürzeren Delay-Zeiten werde ich gleich mal angehen.

Karl heinz Buchegger schrieb:
> 10%
> dazu.

[Karl H. (kbuchegg)]

Erik L. schrieb:

> Ansonsten verwende ich die LCD-Library von Peter Fleury. Dem Tipp mit
> den kürzeren Delay-Zeiten werde ich gleich mal angehen.


Ich würde mal hier ansetzen

static void toggle_e(void)
{
    lcd_e_delay();      // <- noch ein bischen warten, damit sich die Datenbits stabilisieren
    lcd_e_high();
    lcd_e_delay();
    lcd_e_delay();      // <- und hier auch den Puls ein wenig länger machen
    lcd_e_low();
}

[Karl H. (kbuchegg)]

Seh aber gerade, dass lcd_e_delay auch an anderen Stellen benutzt wird.
Da wird es wohl auch sinnvoll sein, diesen delay an sich etwas anzuheben

Original

#define lcd_e_delay()   __asm__ __volatile__( "rjmp 1f\n 1:" );

#define lcd_e_delay_single() __asm__ __volatile__( "rjmp 1f\n 1:" );
static void lcd_e_delay()
{
  lcd_e_delay_single();
  lcd_e_delay_single();
}

Wenn das dann nicht genug verzögert, weiß ich auch nicht mehr :-)

[Erik L. (flatsoundz)]

Danke, das hat geholfen.

Ich hab vorher probiert, den µC mit dem internen Schwingkreis und 8MHz 
zu betreiben (hab es in den Fuses geändert und auch in der Header-Datei) 
und dort funktionierte es ebenso, nur halt etwas langsamer.

Die Code-Variante aus dem letzten Post hat das Problem beseitigt. Damit 
ist das Problem gelöst. Vielen Dank :)