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!
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.
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.
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.
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.
> 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.
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?
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.
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.
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.
Erik L. schrieb: > Dem Tipp mit > den kürzeren Delay-Zeiten werde ich gleich mal angehen. Karl heinz Buchegger schrieb: > 10% > dazu.
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
1 | static void toggle_e(void) |
2 | {
|
3 | lcd_e_delay(); // <- noch ein bischen warten, damit sich die Datenbits stabilisieren |
4 | lcd_e_high(); |
5 | lcd_e_delay(); |
6 | lcd_e_delay(); // <- und hier auch den Puls ein wenig länger machen |
7 | lcd_e_low(); |
8 | }
|
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
1 | #define lcd_e_delay() __asm__ __volatile__( "rjmp 1f\n 1:" );
|
1 | #define lcd_e_delay_single() __asm__ __volatile__( "rjmp 1f\n 1:" );
|
2 | static void lcd_e_delay() |
3 | {
|
4 | lcd_e_delay_single(); |
5 | lcd_e_delay_single(); |
6 | }
|
Wenn das dann nicht genug verzögert, weiß ich auch nicht mehr :-)
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 :)
Bitte 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.