Hallo Gemeinde. Controller: AT89C51ED2 LCD 4x27 (HD44780) Das Display (nur Controller 1 wird verwendet) wird erfolgreich initialisiert. Ich betreibe das Display im 4bit Mode. Alles klappt wunderbar. Nur werden keine Kleinbuchstaben, Sonderzeichen und Zahlen ausgegeben. Dafür aber Leerzeichen und am Ende der "leeren" Zeichenkette blinkt der Cursor. Kann jemand weiter helfen? Danke im Voraus Kerno
Hallo Klaus danke für den Tipp. Ich habe auch gleich alle Datenleitungen nochmals überprüft und mit der Character Code Tabelle des DisplayControllers verglichen. Auf den ersten Blick hatte es den Anschein als, dass alle Zeichen, welche eine | 0010 (dez. 2) im Upper_Nibble enthielten nicht geschrieben werden würden, da alle Zeichen (laut Character Code Tabelle)von @ bis O und P bis _ dargestellt wurden. Wiederum wurden alle Zeichen geschrieben, welche die | 0010 im lower Nibble enthielten. Auf den zweiten Blick aber hätte die 4-Bit Initialisierung nicht funktionieren dürfen. Diese funktioniert aber korrekt. Ich habe die Ports am Controller mal getauscht. Keine Änderung. Mich hatte es nur gewundert, dass das Auslesen des Arrays mit Großbuchstaben und die Übergabe an das Display ohne das Abtasten des Busyflags funktionierte. Mit Abtasten des BusyFlags ging wieder nichts mehr. Lösung: Mein Fehler dabei war, dass ich nach dem Abtasten des BusyFlag RS nicht wieder auf 1 gesetzt hatte. Nun läuft alles. Warum aber funktionierte die Übergabe von Zeichen (laut Code Tabelle) aus den Spalten @ bis O und P bis _ ohne BusyFlag Abfrage? Die anderen nicht? Das kann einen ganz schön verwirren :( Danke Kerno
Das busyflag barcht man nicht. Zwischen jedem Zeichen einen 10ms Delay rein und gut ist.
>Das busyflag barcht man nicht. Zwischen jedem Zeichen einen 10ms Delay >rein und gut ist. 100us reichen auch.
Hi
>100us reichen auch.
Na und? Busy-Flag-Lesen dauert lediglich ein paar µs.
MfG Spess
>>100us reichen auch. >Na und? Busy-Flag-Lesen dauert lediglich ein paar µs. Na und? Meine Displays betreibe ich nur mit R/W an GND. Da bleibt das Programm dann auch nicht stehen falls mal kein Display dran ist.
Hi >Na und? Meine Displays betreibe ich nur mit R/W an GND. >Da bleibt das Programm dann auch nicht stehen falls >mal kein Display dran ist. Tolles Argument. In dem Fall wäre es mir egal, ob das Programm läuft. Aber hier scheint langsam die Verwendung des Busy-Flags als uncool verpönt zu sein. MfG Spess
>Tolles Argument. >In dem Fall wäre es mir egal, ob das Programm läuft. Ist doch auch ein tolles Argument! >Aber hier scheint langsam die Verwendung des Busy-Flags als uncool >verpönt zu sein. Man braucht es nicht. Wenn ich an meine per 1ms Timerint gesteuerte Ausgabe denke wird das Busy sogar noch überflüssiger ;) Da muss ich dann auch keine blockierenden 100us Delays machen.
> Man braucht es nicht. Wenn ich an meine per 1ms Timerint > gesteuerte Ausgabe denke wird das Busy sogar noch überflüssiger ;) > Da muss ich dann auch keine blockierenden 100us Delays machen. Genau so sehe ich das auch. Dazu noch einen "Bildschirmspeicher" im AVR-SRAM mit linearen (unverschachtelten) Adressen (Fließtext-tauglich), und die Print-Routinen werden extrem schnell, weil sie ihre Daten nur in den Bildschirmspeicher legen müssen. Der 1ms-Job schaufelt sie dann im Hintergrund an das LCD und entwirrt dabei nebenbei noch den Zeilen-Adress-Salat. Das kostet kaum Rechenleistung und funktioniert vorzüglich, sowohl bei LCDs mit einem HD44780-kompatiblen Controller als auch bei LCDs mit zwei Controllern (4x27, 4x40). ...
Hi >Man braucht es nicht. Wenn ich an meine per 1ms Timerint >gesteuerte Ausgabe denke wird das Busy sogar noch überflüssiger ;) >Da muss ich dann auch keine blockierenden 100us Delays machen. Genau diese Antwort habe ich erwartet. Aber eigentlich von jemand anderem. Ich persönlich entscheide im Einzelfall, welche Methode am geeignetsten ist. Da bin ich etwas weniger dogmatisch. MfG Spess
>Genau diese Antwort habe ich erwartet. Aber eigentlich von jemand >anderem. Von Peter? Es gibt auch andere die sich Gedanken machen ;) >Ich persönlich entscheide im Einzelfall, welche Methode am geeignetsten >ist. Da bin ich etwas weniger dogmatisch. Das ist ja auch richtig so. Die Interrupt Methode benötigt etwas RAM. Wenn das sowieso knapp ist taugt sie dann eben nicht. Viele Wege führen nach ROM.
Hi
>Viele Wege führen nach ROM.
Stimmt. Man muss sich nur auf einem von denen in die richtige Richtung
bewegen.
MfG Spess
Was'n hier los? So viel Terror um ein Bit? Die sichere Variante wird doch das BusyFlag sein. Oder nicht? Wenn das Device eine solche Funktion zur Verfügung stellt, kann/sollte man sie auch nutzen. Oder esst ihr mit den Händen, wenn der Löffel daneben liegt ;) Kerno
>Oder esst ihr mit den Händen, wenn der Löffel daneben liegt ;)
Versuch mal Chicken Wings mit einem Löffel zu essen ;)
>Die sichere Variante wird doch das BusyFlag sein.
Man muss das Bit dann lesen, mit dem Timer muss man es nicht lesen. Ich
habe meinen 10ms Timertick und kann so einfachst 100 Zeichen pro sekunde
darstellen, die Zeichen werden zyklisch rausgeblasen. Es ist auch
voellig egal ob der Display angeschlossen ist oder nicht.
Wenn man das Busy liest, muss man die Richtung umschalten. Hoffentlich
braucht kein interrupt dieses Port. Und dann muss man das warten auf das
busy so machen, dass das Programm nicht alles blockiert, falls das
Display mal nicht eingesteckt ist.
Meine 2 Cents.
Hi
>So viel Terror um ein Bit?
Entschuldige mal. Es ist doch recht zivilisiert zugegangen.
MfG Spess
> Ich persönlich entscheide im Einzelfall, welche Methode am geeignetsten > ist. Da bin ich etwas weniger dogmatisch. Ich auch... Z.B. hat der Tiny2313 nicht genug RAM für den Bildschirmspeicher eines 4x40-LCDs, da wurde die Textausgabe etlicher Parameter und Menütexte zur Hauptschleife erklärt, die durch den Timer-Merker (1ms) beim Aufruf von LCD_DATA (also in den LCD-Low-Level-Routinen) gebremst wird. In der Bremsphase (warten auf Timer-Merker) wurden dann die restlichen (bedingten) Jobs des Programms ausgeführt. Es gibt für (fast) alles eine Lösung, meist ist es eine individuelle. Es kommt halt immer auf die Situation an. Busywait am Text-LCD habe ich aber schon lange nicht mehr genutzt, die anderen Verfahren sind trotz langsamerer Ausgabe einfach effizienter. ...
>.... >Wenn man das Busy liest, muss man die Richtung umschalten. Hoffentlich >braucht kein interrupt dieses Port. Und dann muss man das warten auf das >busy so machen, dass das Programm nicht alles blockiert, falls das >Display mal nicht eingesteckt ist. So hatte ich die Sache noch nicht betrachtet gehabt. Wird aber doch nicht die Regel sein. >.... >Busywait am Text-LCD habe ich >aber schon lange nicht mehr genutzt, die anderen Verfahren sind trotz >langsamerer Ausgabe einfach effizienter. Werde ich mir im Hinterkopf behalten. > Entschuldige mal. Es ist doch recht zivilisiert zugegangen. Hast ja Recht :o) Und dazu gelernt habe ich auch wieder was. Danke Kerno
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.