Hallöchen, ich habe mich mal im Netz so umgesehen, was es für fertige Ansteuerroutinen für die HD44780-kompatiblen LCD's so gibt. Seltsamerweise arbeiten fast alle gefundenen Implementationen mit relativ langen Verzögerungen um den 44780 zu befeuern, keine der gefundenen Sachen wertet das Busy Flag diees Controllers aus. Was ist der Grund dafür? Aus früheren Basteleien weiß ich, daß ddiese pauschalen Verzögerungen die Displayausgabe deutlich verlangsamen und hatte deshalb bei eigenen Sachen (8051,6809, 68000 etc) jedesmal den Busy-Mechanismus impelmentiert, meine Frage ist nun, warum macht das scheinbar niemand Anderes? Gibts dafür einen Grund? Gruß, Holm
Die meisten Geräte (z.B. Laserdrucker o.ä.) steuern die LCDs auch im 4bit Modus an, um Leitungen und somit Kosten zu sparen.
Entschuldige mal, der 4 Bit Modus hat mit der Verwendung des Busy Flags Nichts, aber auch gar Nichts zu tun... Gruß, Holm
In der regel dauert es länger das busy-flag abzufragen als einfach ein paar takte zu warten und bei einem Character-Display spielt ja die Geschwindigkeit nun eh nich so die Rolle, das menschliche Auge ist um Größenordnungen langsamer...
Na ja, "deutliche Verzögerung der Displayausgabe" halte ich für übertrieben. Ein 2x16-Display, das alle 1 ms mit einem Zeichen befeuert wird, ist innerhalb 32 ms komplett refresht. Das heißt, der Displayinhalt kann sich immer noch bis max. ca. 31 mal pro Sekunde ändern. Mit einer letzten Nachkommastelle eines Meßwertes, die mit 31 Hz zwischen 4 und 5 flackert, kann kein Mensch etwas anfangen; flackert sie dagegen mit 2 Hz, ist das Ablesen problemlos möglich. Der Vorteil der LCD-Controller-bekommt-immer-genug-Zeit-Methode dürfte sein, daß man eine Leitung zum Display und damit einen µC-Pin sparen kann, denn wenn man niemals etwas vom LCD-Controller lesen muß/will, dann kann man den R/W-Pin displayseitig auf Masse legen und fertig.
@Holm Tiffe 4bit Modus: 4 Pins gespart RW auf GND: 1 Pin gespart Wenn man Leitungen sparen will macht man beides...
Ich denke auch, dass das Aufwand-Nutzen-Verhältnis nicht OK ist. Und sorry, aber "deutlich verlangsamen" ist völliger Unsinn. Es gibt Datenblätter, und an die kann man sich ja halten. Ich weiss es gerade nicht auswendig, aber ein Write auf den Controller dauert IIRC um die 5µs. Ich habe ein präzise wait()-Funktion, die ich dann eben anschließend 6µs warten lasse. D.h., ich verliere bei einem 2*20-Display ca. 40µs. Und selbst das stimmt nicht, denn das Auswerten des Busy-Flags dauert ja auch eine gewisse Zeit, die man wieder gegenrechnen müsste. Und 40µs ist alles andere als "deutlich verlangsamen", oder? ;-) Mit dem bloßen Auge hast du jedenfalls nicht den Hauch einer Chance, diesen Zeitunterschied festzustellen.
Das mit den 5us stimmt nicht immer. Ich kenne da einige Firmen die ordentlich Probleme hatten als es keine HD44780 mehr gab, sondern nur noch irgenwelche Samsung Nachbauten. Der interne RC Oszillator hat etwa +/-25% Toleranzen (laut Spezifikation), nur die Hitachi ICs waren sehr viel besser. Und seitdem es nur noch die Samsung ICs gibt, gibt es bei bestimmten Temperaturen eben ein paar Anzeigefehler...
Ich habe das mals Scrollen vorwärts und rückwärts da eingebaut, d.h. die Daten im Controller RAM umgeladen. damit wird die Zeiteinsparung mehr als deutlich. Des Weiteren wird die ganze Display Routine unabhängig von der Taktfrequenz und den Zykluszeiten des verwendeten Controllers, ich weiß nicht, aber dafür gebe ich gerne einen Pin für R/W aus. Probiert das mal aus, bevor Ihr über die mögliche Zeiteinsparung deren Nichtwarnehmbarkeit philisophiert... Fazit: ich krame meine alten Sourcen wieder hervor und portiere das. Warscheinlich hat sich hier einfach noch Keiner die Mühe gemacht das mal zu checken. Ich bin mit der Verzögerungsmimik bei 3 unterschiedlichen Display (nicht mal unterschiedliche Controller, alles HD44780 aber mit unterschiedlichen Charaktersätzen) damals auf die Nase gefallen, weil irgend eines immer nicht mitspielte, mit dder Busy Flag Auswertung funktionierten aber Alle ... Das ist auch der Grund, warum ich das hier explizit hinterfragt hatte. Gruß, Holm
Warum verwendest du nicht die Routine von Peter Fleury, ich denke die kann beides.
... gerade die habe ich mir noch nicht angesehen, mache ich morgen. Danke für den Hinweis. Gruß, Holm
"Warscheinlich hat sich hier einfach noch Keiner die Mühe gemacht das mal zu checken." Doch, ich: Also 20 Zeichen a 46µs dauern 20 * 46µs = 0,92ms. Damit der Benutzer nicht wahnsinnig wird vor Flimmern, sondern die Werte auch ablesen kann, begrenze ich die Ausgaberate auf ergonomische Werte, also nicht kürzer als 200..500ms. D.h. der Overhead der Delay-Methode ist gerade mal 0,92ms/200ms=0,5%, also absolut nicht der Rede wert. Dagegen ist der eingesparte Pin schon was wert, d.h. ob ich mit 3 Pins (+ 74HC164) oder 6 Pins auskomme. Ich hab solche Routinen bisher mit 4 verschiedenen Displays verwendet und keinerlei Probleme bemerkt. Man muß natürlich immer die richtige Quarzfrequenz in den Formeln eintragen, damit der Assembler oder Compiler die richtigen Delaywerte berechnet. Peter
Bin auch einer derjenigen die das Busy-Flag (NICHT PIN!) abfragen auch wegen leidvoller Erfahrungen. Durch das Abfragen des Busy-Flags bediene ich ja das LCD genau so schnell/langsam wie es benötigt wird. Einmal sauber Programmiert und die Routinen sind UNABHÄNGIG vom Prozessortakt, Timereinstellung und LCD-Display. Außerdem bleibt mir dadurch mehr Zeit um andere Dinge im uC zu tun. Gruss
Das ist der Charme eines RTOS wie AvrX. Ein RTOS-Tick von 100us ist realistisch und da lohnt es sich dann eher, im LCD-Code ein bischen länger zu warten (100-200us statt 46). Nur eben nicht in Form einer Warteschleife, sondern via Timer-Scheduling. D.h. die Wartezeit wird anderweitig nutzbar.
@A.K. ja, man könnte jetzt noch stundenlang philosophieren, wie man von den 0,5% CPU-Last noch einige Promille einspart. Aber Programmieren soll ja auch effektiv sein. Peter
@Peter: Es geht mir dabei weniger um die Last. Eher um kontinuierlichen Betrieb, wenn beispielsweise noch ein paar 1-Wires dranhängen, deren Bit-Intervalle ähnlich ablaufen.
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.