Hi und das leidige Thema LCD... NEIN habe schon mehrere davon zum Laufen bekommen, doch nun habe ich nen kleinen Black out. Das LCD ist an Port C PC0-PC3 4-Bit Datenbus PC4-PC7 Steuerbits und Backlight So weit alles gut und schön. Inn allen Sourcêcode beispielen findet mann, das die Bits geschoben werden und dann auf den Port Kopiert. Ist ja net, aber lösche ich damit nicht automatisch alle Steuerbits mit weg? Sollte ich da richtig liegen, und dies kein Problem darstellen? Kann Sein. Ist es ratsam die Steuerpins auf einen anderen Port zu legen? Hat schon einer Negative Erfahrungen mit einer solchen Konstelation gemacht. MfG Mobi
Schau dir den Unterschied zwischen PORTC = irgendwas; und PORTC |= irgendwas; bzw. PORTC &= irgendwas; an http://www.mikrocontroller.net/articles/Bitmanipulation
@ Stefan Winter >Das LCD ist an Port C >PC0-PC3 4-Bit Datenbus >PC4-PC7 Steuerbits und Backlight >werden und dann auf den Port Kopiert. Ist ja net, aber lösche ich damit >nicht automatisch alle Steuerbits mit weg? Nicht wenn man es richtig macht. >Ist es ratsam die Steuerpins auf einen anderen Port zu legen? Nicht nötig. >Hat schon einer Negative Erfahrungen mit einer solchen Konstelation >gemacht. Ja, viele Anfänger die noch nicht verstanden haben wie man einzelne Bits in einem Port manipuliert ohne den Rest zu beeinflussen. MfG Falk
Ich habe es noch immer nicht zum 100% laufen bekommen. Mit der Init das ist gelaufen... alle vier Zeilen sind als leichter schatten zu sehen und der Cursor blinkt. Doch wenn ich nun was schreiben möchte geschieht was komisches. der Courser bewegt sich beim ersten Zeichen, ohne dies darzustellen auf Zeile auf Position 20 bein nächsten auf Z4/P19 und danach Z4/P18 usw. wenn man bei der Init Routiene das rechts link Bit nicht setzt ist das gleiche verhalten zu beobachten, nur das es nicht mit Zeile 4 sondern mit Zeile 3 passiert. Die Anzahl der Cursorbewegungen stimmt mit den Sendebefehlten der Zeichen überein. Gibt es bei den 4*20 mit einem HD44780A00 und 4*NJU6407CF eine Besonderheit, welche dies erklärt Erst dachte ich es ist das LCD und nahm ein neues, was in einer schaltung seinen Dienst tat. Doch dieses verhielt sich gleich. Mit den Zeiten beim Warten kann es nichts zu tun haben die sind völlig übertrieben. MfG Mobi
Zeig doch mal den Code, sonst wird das hier ein Rätselraten. Ich schätze mal, dass du irgendwo deine Steuerpins überschreibst. Und dann ist da nochwas: Probleme an PortC riechen nach JTAG aktiviert. Ist es evtl. ein ATmega16 oder so und du hast vergessen JTAG zu deaktivieren (Fuse)?
Hallo und danke für alle Antworten bis Dato Ich nutze einen Mega8535L mit 8MHz und 5V VCC Es gibt neue Erkenntnisse..... ich habe mal den Test gemacht und geschaut, was das LCD am Busypin eigendlich macht. Wärend der Initroutiene läuft alles Super auch mit BF Abfrage. Nach der Initroutine bleibt das BF nach dem ersten senden auf H. Dies ist selbst nach 30 Sek. nicht weg. (Bei jeder Abfrage blinkt die LED) Bei der Initroutiene frage ich das BF vor jedem Schreibzugriff ab, und es macht, was es machen soll. beim schreiben der Zeichen hingegen, bleibt es wie gesagt stehen. Frage... ich muss um ein Zeichen ausgeben zu können das RS setzten, damit das LCD mitbekommt, das ich keinen Befehl sende sondern ein Zeichen? MfG Mobi
Schau dir mal folgenden Thread an: Beitrag "Wie mache ich eine Textausgabe 8Bit auf Display?" Hier findest du eine Beschreibung zu BITs & Bytes als auch eine Beschreibung für eine 4 BIT display Ansteuerung. Am Schluß gibts auch den kompletten Code. Auf Dauer mag man das Thema LCD nicht mehr diskutieren, also, schaus dir an und stelle dann deine Fragen.
Danke Danke Danke... für diese SEEEEEHHHHHRRRR Hilfreiche Antwort. ;-| Möchte Hier keinen vor den Kopf stossen, aber ich benötige doch evektive Hilfe bei diesem LCD.... Alle schreiben das ein 4 Zeiliges mit HD4478.. Controller ist. aber diese halt nicht, und davon habe ich zwei. im 8Bit mode läuft es ohne Prob. nur im 4 Bit mode komme ich bis zur init, welche OK geht. Beim Zeichen ausgeben bleibt der BF hängen. ??? Ich fragte den BF auch mal nach jedem Transver ab, doch auch keine Besserung. Mobi
Hast du dir die erste Antwort in diesem Topic überhaupt mal zu Herzen genommen? Hab nur mal kurz in deinen Code reingeschaut, aber wenn du die Daten- und Steuerleitungen an Port C hast dann zerschießt du dir mit der Zeile PORTC = data; // Daten auf LCD port kopieren natürlich deine Steuersignale.
Er hätte nur mal meiner Empfehlung folgen sollen, da sind mehrere Fehler vorhanden ;-)) War doch seeeeeeeeeehhhhhhhhhhhhhrrr hilfreich ;-))
Hallo zusammen...
>Christoph:
Das war der Tipp, den ich Brauchte... im eigenen Code findet man meist
die leichtesten Fehler nicht...Danke für dem Wink mit dem Zaunpfahl ;-))
mobi
PS.: Habe alle antw. sehr genau gelesen, aber der Fehler ist zu
offensichtilch, als das man ihn da vermutet.
Hallo, Du brauchst Hilfe? Dein RS steht falsch, wenn Du Busy in der Datenroutine abfragst... Gruß aus Berlin Michael
Hi und allen Helfern mit sindvollen Lösungen einen Herzlichen Dank Auch an Michael U.:.... Danke hat mir suchen gespart. aber das Hauptproblem war eigentlich nur, das beim abfragen des BF nach dem Senden von 0x1111 der Port beim inputschalten und lesen das D7 immer noch H hatte und ich damit die selbst gesetzte 1 an D7 gelesen habe. nun lösche ich erst den PORTC setze dan meine Register und lese anschließend D7 von LCD. und siehe da es Funktioniert. Hurra und allen noch einmal herzlichen Dank. Auch wenn das Thema LCD einigen lästig erscheint und ich auch nicht das erste LCD anschliesse und Proge., doch es gibt immer was neues zu entdecken. Ich bin der Meinung alle solten allen Helfen und wenn es etwas länger dauert, na und der der Hilfe Braucht, freut scih immer wenn er effektive Hilfe bekommt. Manchmal, aber nur manchmal... hilft da auch das Tutorial/LCD nicht weiter, weil dort nicht jede möglichkeit abgearbeitet werden kann, die auftretten könnte. Trotzdem allen Danke, Es geht nun. Wer sich selbst hilft, dem sollte geholfen werden. Mobi
Hallo, ich habe mir Deinen Code so genau nicht angeschaut. Für mich gibt es bei solchen Sachen einfach ein paar Grundregeln: wenn die Datenrichtung auf Eingang gewechselt werden muß, muß das Display in TriStae sein, also muß E auf L sein oder CS auf H bei anderen Displays. Sonst gibt es Busprügeleien, weil kurzzeitig 2 Ausgänge gegeneinander arbeiten können. Wenn auf Ausgang gewechselt werden soll, gilt das gleiche, damit das Display keine undefinierten Daten einlesen kann. Außerdem nutze ich immer die gleiche Reihenfolge: Port ist immer Ausgang, Daten setzen, RW setzen, RS passend setzen, E oder CS-Puls, RW zurück auf Lesen. Beim Lesen Portrichtung ändern, RS passend setzen, E oder CS aktivieren, Daten einlesen, E oder CS inaktiv, Daten auswerten. Wenn nötig, kommen da noch Verzögerungen oder ein NOP dazwischen (z.B. zwischen E/CS aktiv und dem Einlesen der Daten, der AVR setzt die Portbits erst im nächsten Zyklus. Wenn man seinen eigenen Ablauf immer einhält und im Datenblatt des Controllers kontrolliert, melden sich auch für mich neue Controller sehr schnell wie gewünscht. Das heißt nicht, daß ich nicht auch schon 2 Stunden gesucht habe, bis ich meinen Tippfehler gefunden habe... Displays am Port sind recht unkritisch, weil man nur wenige Abläufe und das Timing einhalten muß. Diskussionen z.B. mit I2C-ICs konnen da mehr nerven, wenn man sich nicht 100% auf die I2C-Routinen verlassen kann und so mit mehreren Unbekannten kämpft. Gruß aus Berlin Michael
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.