|
|
Forum: Mikrocontroller und Digitale Elektronik LCD Busy Flag abfragen CHallo, meine Busyflag-Abfrage funktioniert nicht. Es erscheint nur Mühl auf dem Display. Ersetze ich den Befehl "DISPLAY_BUSY()" durch "_delay_ms(3)" geht alles besstens. Komponenten: Atmega 32, 4 Mhz Quarz und LCD EA W204B-NLW. Könnt Ihr mir helfen? Ein Teil des Haup-Programms:
Lass das Busy weg ... ganz gleich ob dein Code stimmt oder nicht wird der Thread so oder so wieder in eine Richtung steuern ... "Busy weglassen oder nicht?" Das ist ja mal ne Antwort. Ich weis das einige in diesem Forum der Meinung sind, dass das Busy nicht benötigt wir. Dennoch will ich wiesen wie´s funktioniert. Stehlt euch vor Ihr seit am essen und hört erst auf wenn es euch ein anderer sagt. Obwohl Ihr eigentlich schon längst satt seid. In der Zeit könntet Ihr was anderes machen. Diese Zeit ist kostbar. Also bitte, nur noch sachliche Antworten. >Das ist ja mal ne Antwort. Ich weis das einige in diesem Forum der >Meinung sind, dass das Busy nicht benötigt wir. Ich hab noch nie das Busy von einem Text LCD abgefragt. Vieleicht funktionieren meine LCD Routinen gerade deswegen mit allen meinen Displays. Und ich hab ne Menge davon.
Deine while-Schleife wird bei dieser Konstruktion doch exakt 0 (!) Mal ausgeführt. Hat sich erledigt. Funktioniert. Danke. Hier die Lösung:
holger schrieb: > Ich hab noch nie das Busy von einem Text LCD abgefragt. > Vieleicht funktionieren meine LCD Routinen gerade > deswegen mit allen meinen Displays. Dafür hast du bei einigen LCD-Funktionen Delays drin, die den Prozessor relativ lange blcokieren, statt einfach einen Interupt zu bekommen, wenn der Display-Controller meint, dass er fertig ist. Matthias schrieb: > Dafür hast du bei einigen LCD-Funktionen Delays drin, die den Prozessor > relativ lange blcokieren, statt einfach einen Interupt zu bekommen, wenn > der Display-Controller meint, dass er fertig ist. Wobei der Interrupt basierte Ansatz wohl nicht bei allen HD44780 funktioniert, da scheinbar manche voraussetzen, dass "E" getoggled wird: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=53763&start=0&postdays=0&postorder=asc&highlight= Und dieser Ansatz scheint dann wohl langsamer zu sein, als ein einfaches Warten: http://stackoverflow.com/questions/1822571/interrupt-driven-hd44780-library-for-an-arduino Insofern: Technisch "schöner" und "besser" ist es wohl das Busy Flag zu verarbeiten, in der Praxis scheint es aber Gang und Gäbe zu sein einfach zu warten. Unlucky2012 schrieb: > Wobei der Interrupt basierte Ansatz wohl nicht bei allen HD44780 > funktioniert, da scheinbar manche voraussetzen, dass "E" getoggled wird: Ich würde eher sagen, umgekehrt. Falls es geht, ohne E zu pulsen, dann ist das die Ausnahme. Laut HD44780 Datenblatt muß man E pulsen. Ist eigentlich auch logisch, daß beim Lesen die Daten stabil sind, d.h. gelatcht werden. Unlucky2012 schrieb: > in der Praxis scheint es aber Gang und Gäbe zu sein einfach > zu warten. Warum sich abmühen, wenn die CPU-Last fürs LCD weit unter 1% ist. Oft ist ein falscher Programmplan das eigentliche Problem. D.h. es wird viel zu oft auf das LCD geschrieben und kein Mensch kann so schnell ablesen. Es geht aber auch ganz ohne Warten, auch nicht auf das Busy. Man gibt einfach in einem Timerinterrupt (z.B. 1ms) jeweils ein Byte aus. Die Mainroutinen schreiben dann nicht direkt auf das LCD, sondern in einen Puffer im RAM. Der Puffer muß so groß sein, wie die Stellenanzahl des LCD. Diese Variante ist sinnvoll, wenn die LCD-Schreibzeit stört und die Mainloop schnell durchlaufen werden muß (schnelle Regelungen). Peter Peter Dannegger schrieb: > Es geht aber auch ganz ohne Warten, auch nicht auf das Busy. Man gibt > einfach in einem Timerinterrupt (z.B. 1ms) jeweils ein Byte aus. > Die Mainroutinen schreiben dann nicht direkt auf das LCD, sondern in > einen Puffer im RAM. Der Puffer muß so groß sein, wie die Stellenanzahl > des LCD. Das löst das eigentliche Problem aber nicht, sondern "umschifft" es. Nun muss man in entweder im Interrupt prüfen, ob man neue Werte ans LCD schicken kann, oder weiter warten muss. Alternativ schreibt man halt einfach. In der Praxis dürfte das wohl meistens klappen, aber die feine Englische Art ist es halt auch nicht. Hallo, ich hab hier die Diskussion über die Ansteuerung von einem Display gefunden. Nun würden mich mal eure Zeiten interessieren die euer Display benötigt um z.B. 1 Zeichen rauszuschreiben ( 1 Zeichen, mit busy-Flag Abfrage) . Lt Datenblatt benötigt mein Display(HD44780) 40us um 1Byte zu schreiben. Das Display wird bei mir im 4-Bit-Modus angesteuert. Bei meinem Display ist nach ca 38us das Display wieder bereit Daten zu empfangen. So wie es aussieht, muß man sich nur ans Datenblatt für die entsprechenden Zeiten halten, dann sollte es kein Problem geben. Wobei mir das immer nicht so gefällt einfach mal ne Wartezeit einzufügen. Das dürfte aber bei 40us ein bisschen unter Haarspalterei fallen. Gruß patt Unlucky2012 schrieb: > Nun > muss man in entweder im Interrupt prüfen, ob man neue Werte ans LCD > schicken kann, oder weiter warten muss. Wozu das denn? Ein Byte schreiben dauert 40µs. Da muß man nach 1ms nichts prüfen, das ist längst fertig. Hier ein Beispiel mit Interrupt: Beitrag "Formatierte Zahlenausgabe in C" Peter Peter Dannegger schrieb: > Wozu das denn? > Ein Byte schreiben dauert 40µs. Da muß man nach 1ms nichts prüfen, das > ist längst fertig. Wie oben gesagt: Dann nimmt man implizit an, dass es fertig sein muss. Das ist halt (technisch) gesehen nicht das Gleiche wie wenn ich wirklich darauf prüfe, ob es fertig ist. Und nochmal: In der Praxis wird das wohl problemlos (in (fast) allen Fällen) klappen. Wichtig an diesen Displays ist die Reset Zeit zu beachten, die ist immer sehr viel laenger wie das Schreiben eines Bytes. Ferner sollte man periodisch das Display neu initialisieren. Es kann passieren, dass es aussteigt wenn beim EMV Test die Mikrowelle von vorne kommt. Ich hab's zwar noch nie gemacht, es ging auch so. Unlucky2012 schrieb: > Wie oben gesagt: Dann nimmt man implizit an, dass es fertig sein muss. Was spricht dagegen, wenn man sicher weiß, dass es einen Time Slot später sicher fertig ist. Man spart sich das Hängen in einer Delay-Schleife. Nach Init oder Clear, wo die Verarbeitungszeit nicht mehr unter Haarspalterei fällt, würde man dann in der 1ms ISR Busy lesen und prüfen. Unlucky2012 schrieb: > Wie oben gesagt: Dann nimmt man implizit an, dass es fertig sein muss. > Das ist halt (technisch) gesehen nicht das Gleiche wie wenn ich wirklich > darauf prüfe, ob es fertig ist. Das ist quatsch. Ich nehme garnichts an, sondern ich lese einfach das Datenblatt. Das Datenblatt ist Gesetz und wenn da steht 40µs, dann kannst Du das ruhig glauben. Niemand prüft auf etwas, was dem Datenblatt widerspricht. Der Interrupt schreibt Datenbytes bzw. setzt auf die nächste Zeile. Die 1,5ms-Befehle (Clear, Home) kommen also nicht vor. Sähe auch äußerst unprofessionell aus, da sie sichtbares Flackern bewirken. Peter 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten