Geschwindigkeit des GLCD´s

Diese Displays sind zwar langsam, aber sooooo langsam auch wieder nicht.

Zeig mal deinen Weichware...

Oliver

Hey Oliver.

Das ist die Software:

Beitrag "GLCD Routinen ( KS0108, HD61202 )"

So wie master.andre sie Schuf...

und hier ist die Sinus Funktion...

Beitrag "Sinusfunktion und glcd"

Meinst Du es liegt an der Verarbeitung bzw. an der Art, wie die Kurve 
dargestellt wird???


WIE GEHT DENN DAS???
http://www.serasidis.gr/circuits/AVR_oscilloscope/avr_oscilloscope.htm

Liebe grüße

ist dein ks0108 blau/weiß? So ein hab ich auch und mir wurde hier 
bestätigt dass diese displays träge sind!

Schau mal hier den Spektrum-Analyser an:

http://elm-chan.org/works/akilcd/report_e.html

da sind auch Videos vom Display im Betrieb und die Software dazu.

gruß hans

Also

@Philipp Karbach - Mein Display ist blau.
Mir ist jedoch nicht bekannt, daß die Geschwindigkeit der Displays von 
der Hintergrundbeleuchtung.

Danke Hans. Ist ja so ähnlich wie bei dem Ossi

Aber nochmal:

Ich stelle eine Kurve folgendermaßen dar:
Sinuswert wird berechnet und an dieser Stelle ein Pixel gesetzt....

Könnte das die Ursache für die langsame Dastellung sein.
Wie kann ich es anders realisieren???

Gruß

tja dann muss ich dich enttäuschen:
Beitrag "ks0108 lahm?"

lies mal hier geht es um genau dieses thema und es wird gesagt dass 
blau/weiß langsam ist.

Also,

ich hab das jetzt mal kompiliert. Mein Simulator behauptet, in ca. 55ms 
die  Sinuskurve zu zeichnen (bei 14.xx MHz AVR-Takt, Optimierung -O1). 
Das Timing entspricht dabei in etwa dem eines blau-weissen EA-LCDs. Das 
ergibt dann ca. 20 Kurven/Sekunde.

Ohne Optimierung dauerts natürlich viel länger ...

Oliver

Naja, die Displays sind schon relativ langsam, aber es ist völlig 
ausreichend, um flüssige Animationen darzustellen:

http://base32.de/images/big/wuerfel.avi

Zwei Optimierungen könntest Du durchführen:
1.) Einen "Shadow-Ram" für den Displayinhalt benutzen, also den 
vollständigen Frame zunächst im internen Ram des Controllers zeichnen 
und anschließend den gesamten Frame in einem Rutsch ans Display 
übertragen (möglich, dass die o.g. Displayroutinen dies sogar schon tun, 
das weiß ich nicht...)
2.) Eine Sinustabelle vorberechnen und die Werte später nur aus der 
Tabelle holen anstatt ständig Sinusberechnungen durchzuführen.

Gruß
Jupp

Hallo !

@Philipp Karbach. Danke! Das habe ich nicht gewusst! :o(

@Oliver und @ Zwirbeljupp. Auch an Euch einen großen Dank.

Die Variante mit der Sinustabelle werde ich in Angriff nehmen. Klingt 
gut!

Vielen Dank an Euch alle.

Gruß

ja also man kann schon eine animation darstellen aber es ist nicht 
wirklich schön! habe versucht tetris zu programmieren und das war nicht 
wirklich ein spaß. die blockgeschwindigkeit muss man enorm herabsetzen 
sonst verwischt alles. Ich bin immer noch auf der suche nach einem 
günstigen display mit schneller ansteuerbarkeit!

@Philipp Karbach
Auf so einem Nokia 6100 Display ist Tetris akzeptabel auch bei hohen 
Blockgeschwindigkeiten hinzubekommen (selbst mit einem PIC bei 12 MIPS). 
Der Bildschirm ist nur halt ein wenig klein...

Du könntest auch mal ein DOGM-Grafikdisplay (gibts bei Reichelt) 
ausprobieren. Diese haben zwar nur ein SPI-Interface, lassen sich aber 
recht flott beschreiben. Ich habe hier zwar noch kein Tetris getestet, 
aber Animationen laufen flüssig.

gruß
jupp