Hallo zusammen
Ich habe mir vergangene Woche dieses Display geholt:
http://www.pollin.de/shop/dt/NTc1OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_TG12864B_03.html
Funktionieren tut soweit auch alles ohne Probleme, allerdings ist mir
aufgefallen, das es relativ träge reagiert.
Einem anderen Forumsbeitrag hier konnte ich entnehmen, dass Weiss/Blaue
Displays generell langsamer seien als z.B. Schwarz/grüne.
Bei Reichelt bin ich dann auf dieses gestossen:
http://www.reichelt.de/LCD-128SW-DIP/3/index.html?&ACTION=3&LA=446&ARTICLE=53971&artnr=LCD+128SW+DIP&SEARCH=ks0108
Leider wird kein Zeitbedarf für das Umstellen der Pixel im Datenblatt
angegeben, darum frage ich hier nach persönlichen Erfahrungen: Ist das
Schwarz/weisse Display schnell genug, um in "nützlicher Frist" komplett
verschiedene "Textseiten" anzuzueigen? Bzw. ist es schnelle als das
weiss/blaue.
Noch zu meinem Setup: Ich setze einen Atmega32 bei 8Mhz ein und habe das
Display über 8 Leitungen an den COntroller angeschlossen. Verwendet wird
die Grafik Library hier aus dem Forum (apetech library)
Zum Anschluss auch noch eine Frage: Muss ich in der Library irgendwo
einstellen, das ich den 8bit Modus verwende, oder ist das automatisch
so?
Liebe Grüsse
Ah noch als Nachtrag:
Ich habe mir auch überlegt, ob es was hilft bei der nächsten
Reichelt-Bestellung noch ein 16MHz Quarz zu bestellten.
Wenn es aber wirklich so ist, dass das LCD einfach zu langsam beim Pixel
umschalten ist, dann hilft das ja nicht.
Gibt es auch ein Datenblatt, das diese Namen verdient?
Was meinst du mit "träge reagiert"? Gibt es Schatten beim Umschalten
oder dauert einfach ein Bildaufbau zu lange?
Die Farbe eines LCD hat in erster Näherung nichts mit der
Reaktionsgeschwindigkeit der Pixel zu tun.
Hi Georg und Danke für deine Antwort
Der Bildaufbau dauert lange: Wenn ich Text auf das Display schreibe,
dann baut sich dieser Langsam auf, kann man sich ein bisschen wie eine
Laufschrift vorstellen.
Ich denke eine komplette Textzeile mit Text dauert ca. 2 Sekunden.
Schlimmer ist es aber, wenn man das Display löschen möchte, für neuen
Inhalt.
Dann wird das komplette Display mit einem Vierreck (habe in die
Implementation geschaut) überschrieben. Und zwar immer 8 Pixel aufs mal
(Also es werden nacheinander Vierrecke mit 128 * 8 Pixel geschrieben,
bis das ganze Display leer ist).
Ich sehe zwei Ansatzpunkte:
1) Schnelleres LCD
2) Modifikation der Library dahingehend, dass ich mir beim schreiben
merke, welche Pixel nun weiss sind, und beim Löschen werden nur explizit
die weissen Pixel wieder blau gemacht.
Mist, habe deine Frage nach dem Datenblatt vergessen:
Auch auf der Seite des Herstellers ist nur das Datenblatt zu finden,
welches von reichtelt zur Verfügung gestellt wird, ist leider dürftig
Deine Beschreibung deutet stark auf eine zu langsame Treibersoftware
hin. Da solltest du die Library mal kritisch beäugen.
Das Datenblatt von Reichelt ist ja schon mal deutlich besser als das von
Pollin.
Kurze Überschlagsrechnung: Du musst 128*64 Pixel übertragen. Das sind
1024 Bytes. Das Reichelt Display kann 1 Byte/Mikrosekunde abnehmen. Also
dauert ein Neuaufbau etwa 1ms + Verwaltungsarbeit. Selbst, wenn Pollin
um den Faktor 10 langsamer sein sollte, sind 2s für eine Textzeile nur
durch eine sehr ungeschickt programmierte Lib zu erklären.
Gib doch bitte mal einen Link auf die von dir verwendete Lib.
Ich denke, dass könnte man effizienter gestalten, eben zum Beispiel sich
merken, welche Pixel beschrieben wurden und dann nur diese Pixel zu
löschen.
Was mir natürlich auch recht wäre, wäre eine andere Library einzusetzen,
obwohl ich mich mit der verwendeten schon recht angefreundet habe...;)
Auch was Grafik und weitere Schriftarten usw. anbelangt.
Ohne die Lib angesehen zu haben: Kann es sein, dass dort nach jedem
Datenpaket eine pauschale Zeit gewartet wird? Man macht das ja oft, um
den Pin für die Rückmeldung "fertig"/"nicht fertig" vom LCD zu sparen.
Und damit die Lib mit möglichst vielen LCDs funktioniert wurde die
Wartezeit möglicherweise sehr lang gewählt.
Probier mal die von modifizierte Lib. Die wichtigsten Funktionen sind
implementiert: Fonts, analoge Uhr, usw. Benutzt jedoch 1k internes RAM
als
"Bildspeicher". Ist sehr schnell.
Noch eine Anmerkung: Es gibt keinen Unterschied zwischen den Displays.
Die Farbe hat nichts damit zu tun.
Viel Erfolg damit!
Grüße
Peter
@ Lisa (Gast)
>Ich denke eine komplette Textzeile mit Text dauert ca. 2 Sekunden.
Dann ist deine Software Schrott. Wahrscheinlich von einem Delay-Künstler
geschrieben.
>1) Schnelleres LCD
Nö, das ist schnell genug.
>2) Modifikation der Library dahingehend, dass ich mir beim schreiben>merke, welche Pixel nun weiss sind, und beim Löschen werden nur explizit>die weissen Pixel wieder blau gemacht.
Nö, du musst erstmal den IST-Zustand analysieren und schauen, wo die
Zeit sinnlos draufgeht. Dazu kann man einen Timer benutzen, z.B. Timer
1, den lässt man mit ein paat Dutzend kHz laufen. Etwa so.
Start = TIMER1;
Funktionsuafruf
End = TIMER1;
Zeit = End-Start;
Diese Zeiten kann man sich ausgeben lassen, z.B. auf dem LCD. Dann
findet man die Zeitverschwendung.
Ein schneller Blick in den Sourcecode zeigt u.a., dass eine schnelle
Routine zum Löschen des LCDs fehlt. Dort gibt es nur eine Funktion
ks0108DrawRoundRect, die ist aber alles ander als schnell, sondern
greift wiederum auf recht komplexe, langsame Funktion ks0108SetDot
zugreift.
Wenn gleich die Funktionen sicher noch ne Menge Optimierungspotential
haben, glaube ich dennoch nicht so ganz, dass die Ausgabe einer Zeile 2s
dauert. Da ist noch ein anderer Bug. Möglicherweise läuft dein
Controller nur auf 1 MHz mit dem internen RC-Oszillator, das muss man
mal prüfen siehe AVR Fuses.
Die apetech-Lib ist locker schneller, als das LCD. Die nutzt allerdings
nicht das busy-flag, sondern wartet einfach nach jedem Befehl eine feste
Zeit. Die Zeit muß man an sein LCD anpassen.
Dazu sind die KS108 in 8bit hohen Zeilen organisiert. Hat man Fonts, die
kein vielfaches von 8 Bit Zeichenhöhe haben, oder schreibt die Zeichen
in der Höhe so, daß sie nicht an solch einer Zeilengrenze beginnen, so
muß die Lib halt erst die Zeile auslesen, die neuen Pixel hineinrechnen,
und das Ergebnis zurückschreiben. Das dauert, liegt aber in der Natur
der Sache. Das geht nur mit einem Screenbuffer schneller, der aber
kostbares Sram kostet.
Pass die delays an, such dir eine Font, der ein vielfaches von 8 Bit
hoch ist, und schrieb die Zeilen immer auf die Zeilengrenzen, dann
fluppt das mehr als ordentlich.
Oliver
Hui, da ging was=)
Also,immer schön der Reihe nach:
@ Peter M
Vielen Dank für die Library. Ich habe versucht, diese anzuwenden,
scheitere aber an Compiler-Fehlern. Ich habe die Datei protos.h
included, gleich wie im Beispiel "display.c" zu sehen. Ich bekomme aber
für jede Methode die ich verwenden will folgende Fehlermeldung:
1
undefined reference to `ClearScreen`
Wobei der genaue Methodenname natürlich ändert, ClearScreen,
InitDisplay, LCDSoftText usw. usw.
Was mache ich wohl falsch?
@falk:
>>Dann ist deine Software Schrott. Wahrscheinlich von einem Delay-Künstler>>geschrieben.
Das bezweifle ich gar nicht, darum bin ich ja auch der Verwendung einer
anderen library gegenüber nicht abgeneigt.
Der ATmega läuft aber definitiv mit 8MHz, sonst läuft (noch) keine
andere Software darauf die, z.B.: über Interrupts das Display ausbremsen
könnte.
Lisa schrieb:> Gute Idee. Das Einzige was ich gefunden habe war folgendes:>>
1
for(volatile uint8_t i=0; i<8; i++); // a little delay loop
2
> (faster than reading the busy flag)
Das dehnt die Sache mindestens auf das Dreifache der tatsächlich nötigen
Zeit (jedenfalls bezogen auf das Reichelt-Display), ist aber trotzdem
relativ unerheblich, ob in 1ms oder in drei ms das komplette Display
beschrieben ist, ist zwar sicher meßbar, aber für einen Menschen nicht
zu unterscheiden.
> Sowie:>
1
#ifdef DEBUG
2
> volatile uint16_t i;
3
> for(i=0; i<5000; i++);
4
> #endif
Das würde natürlich ganz anders reinkrachen. Ich würde mal davon
ausgehen, daß das DEBUG-Symbol einen Wert hat.
> Bei letzterem muss ich allerdings sagen, dass ich die Debug-Zeile im> Header auskommentiert gelassen habe, also
1
//#define DEBUG
>> Diese Zeile sollte ja also nicht zum tragen kommen
Diese sicher nicht. Aber das Symbol kann auch an beliebiger anderer
Stelle im Quelltext gesetzt werden, außerdem auch noch über die
Compiler-Parameter. Ich würde mal auf letzteres tippen...
Trommelwirbel
Und der Oscar geht an: c-hater
Ich danke dir vielmals, du hattest recht. Ich hab die entsprechende
Zeile auskommentiert.
Hier noch für alle mit dem selben Problem:
Kommentiert in der Datei ks0108.c folgende Zeilen in der Methode
ks0108WriteData(...) aus:
Lisa schrieb:> Hier noch für alle mit dem selben Problem:
Na ja, man könnte ja auch erst einmal nachsehen, wo und warum im eigenen
Code DEBUG definiert wird.
Oliver
Hat c-hater doch geschrieben:
>>Diese sicher nicht. Aber das Symbol kann auch an beliebiger anderer>>Stelle im Quelltext gesetzt werden, außerdem auch noch über die>>Compiler-Parameter. Ich würde mal auf letzteres tippen...
Bei mir warens die Compiler params
Lisa schrieb:> undefined reference to `ClearScreen`
Sorry für die späte Antwort, war unterwegs.
In dem ZIP-File habe ich die GRAFIKLCD.aps mit eingefügt.
Lade Dir das Projekt in Dein AVR-Studio und lass es übersetzen.
Die main() ist display.c definiert. Da läuft dann eine endlos Demo.
Die include Datei ks108.h musst Du entsprechend Deinem AVR anpassen.
Entsprechend auch die Prescaler in central_timer.c anpassen, da Deine
CPU
mit 8 MHz unterwegs ist.
Die Demo ist für 1 MHz eingestellt. Die ISR(TIMER0_OVF_vect) muss mit
1ms Takt aufgerufen werden, sonst stimmt das ganze Timinig nicht.
Wenn die Demo soweit läuft, dann kannst Du dir ein Lib erstellen und die
zu Deinem eigentlichen Projekt dazu linken.
Ich hoffe, dass dies verständlich war.
Thread beobachten
Seitenaufteilung abschalten