Optical Characteristics LCD

@Gast:

>ca. 200ms,

ist sicher ein 08/15-Teil??? So wie z.B. meine alte DCF-Uhr mit 
2-zeiligem alphanumerischem Display.

Trägheit: Es sieht in der Tat auch optisch unschön aus, wenn die 
Software mal an einer Stelle was ins Display schreibt und dann an eine 
andere Stelle, das sieht aus verschiedenen Blickwinkeln dann wie ein 
Flackern aus.

Darum schreibe ich die Ausgabedaten zuerst in ein RAM, und refreshe den 
gesamten Displayinhalt in einem Satz, z.B. sekündlich, oder bei 
Änderungen.


Benedikt K.

Meist tut sich bei Standard-Displays bei -30°C rein gar nichts mehr, und 
in der Sonne wird es schwarz (erholt sich natürlich wieder).

Da müßte man einen Automotive-Temperaturbereich wählen, und selbst das 
kleine LCD bei mir im Auto-Armaturenbrett, wird hier in D in der 
Sommersonne recht dunkel, und schwer ablesbar, wegen des schwindenden 
Kontrastes. In Süditalien wird das echte Probleme bereiten.

Hallo,

@Ferkes-Willem
Darum schreibe ich die Ausgabedaten zuerst in ein RAM....

macht bei einem 240x128er Grafik LCD etwa 30Kb, ein 40x4 Textdisplay 
braucht 160 Byte. Diese für ein Display freizuhalten dürfte für so 
manchen gängigen uC und dessen Anwendung den Rahmen sprengen.

MfG

@Gast:

Jetzt hab ich aber auch was losgetreten, wollte nur mal was zu 
Trägheitseffekten anmerken.

Nun ja, solche Displays werden dann intern andere Refresh-Modes haben, 
so daß es nicht an einzelnen Pixeln flimmert, wo der Controller gerade 
hinschreibt. Internes RAM haben die Displays ja auf jeden Fall. Ich bin 
aber da nicht auf dem aktuellsten Stand.

Klar, heute sind die Aufgaben komplexer als bei meinem Zeilendisplay, 
als da wären z.B. Bildverarbeitung, Packalgorithmen, Farbpaletten.