Grafikdisplay langsam - Benötigte Zeit fürs Pixelsetzen?

[BlooD]

Hallo,

ich hab ein "EA DIP128-6" Grafikdisplay im Einsatz in einem Projekt, irgendwie kommt mir aber der Displayaufbau so langsam vor. Ich hab kaum ne Ahnung vom eigentlichen Pixelsetzen weil ich ne fertige Lösung genommen hab: von apetech die "Graphic Library for KS0108- (and compatible) based LCDs" - seine Seite (www.apetech.de) ist leider schon eine weile nicht erreichbar?!

Naja also zum eigentlichen Thema zurück:
Im Datenblatt (http://www.lcd-module.de/deu/pdf/grafik/dip128-6.pdf) stehen doch die Timing Characteristics usw. Lässt sich anhand dessen ausrechnen, wie schnell ein Pixel oder 100 Pixel gesetzt werden können? Wenn ja wie denn?

[AVRfan]

Hallo,

auf welchen Takt lauft der AVR (und sind die Fuses correct? ).

Es gibt AVR mit einen internen Teiler die standard eingeschaltet ist. Damit wird standard durch 8 geteilt: 16MHz wird 2MHz.

Der KS0108 hat einen "E Cycle" zeit von mindestens 1000ns (also 1us). In diesen zeit kann mann einen byte schreiben. Nach der schreibe action braucht der chip aber eine zeit um die daten zu verarbeiten: der Busy flag ist während diesen zeit hoch. Es ist mir nicht deutlich wie lange diesen zeit exakt ist (bei HD44700 displays sind die schon angegeben). Im datenblatt steht nur:

1/fclk <= Tbusy <= 3/fclk

und wenn fclk 250kHz ist wurde das bedeuten: 4us bis 12us.

Gehen wir mal von 12us pro byte aus dann dauert das senden von 1024 bytes (alle pixel) 12288us oder 12,288ms. Wenn mann der Busy flag abfragt kann sich diesen zeit naturlich ändern.

Martin.

[BlooD]

Danke,

das Teil (ATMega16) läuft mit 8MHz intern. Welchen "interne Teiler" meinst du, der das Ergebnis beeinflussen könnte. Hab grad nochmal im Datenblatt gelesen, aber nix entsprechendes gefunden.

Ich müsste morgen mal messen, wie lange das dauert, aber mit sicherheit länger als 12ms, oder hab ich das jetzt falsch verstanden?

Also ich hab ja 128x64 = 8192 Pixel
Ich versteh das Datenblatt einfach noch nicht richtig - glaub ich.

Wie kommst du auf 1024 Bytes für alle Pixel?
- Etwa so?
1 Byte für Y-Adresse (inkrementiert automatisch) +
(1 Byte für X-Adresse + 1 Byte für Daten) * 8 Pages * 64 Y-Adressen
= 1024 Bytes.

Vielleicht nochmal ne blöde Frage:
Die fCLK ist vom Display selber und kann ich nicht beeinflussen, oder?

Also wenn die Rechnung stimmt, könnte man ja über 80Hz erzeugen, also locker ein flimmerfreies Bild.
Dann ist wohl die Lib (bzw. die benötigte Rechenzeit) zu langsam und ich muss mir was neues überlegen.

[AVRfan]

das Teil (ATMega16) läuft mit 8MHz intern. Welchen "interne Teiler" meinst du, der das Ergebnis beeinflussen könnte. Hab grad nochmal im Datenblatt gelesen, aber nix entsprechendes gefunden.

Mega16 hat keinen internen teiler, stimmt. Läuft also auf 8MHz.

Also ich hab ja 128x64 = 8192 Pixel
Ich versteh das Datenblatt einfach noch nicht richtig - glaub ich.

Wie kommst du auf 1024 Bytes für alle Pixel?
- Etwa so?
1 Byte für Y-Adresse (inkrementiert automatisch) +
(1 Byte für X-Adresse + 1 Byte für Daten) * 8 Pages * 64 Y-Adressen
= 1024 Bytes.

stimmt, ich habe einfach 8192 / 8 = 1024 gemacht weil 8 bits in einem byte sind .

Die fCLK ist vom Display selber und kann ich nicht beeinflussen, oder?

auch korrekt: die wird beim herstellen der LCD module eingestellt. Ich habe einen wert in das KS0108 Datenblatt gefunden und als typische wert angenommen.

Also wenn die Rechnung stimmt, könnte man ja über 80Hz erzeugen, also locker ein flimmerfreies Bild.

ich weis aber nicht ob der flussigkeit im LCD da mitmacht .

Dann ist wohl die Lib (bzw. die benötigte Rechenzeit) zu langsam und ich muss mir was neues überlegen.

Wenn beim compilen einen optimizing einstellung falsch ist wirden manchmal die delay-routinen langer dauern. Das habe ich schon erlebt mit WinAVR, welche compiler wird hier benutzt?

Martin.

[BlooD]

ich weis aber nicht ob der flussigkeit im LCD da mitmacht

Naja aber immerhin ein flüssiger Aufbau sollte möglich sein, bisher ist der richtig träge und man kann die Einzelbilder schon mitzählen (wobei sogar nur ein kleiner Bereich immer wieder neu gezeichnet wird).

Ich programmiere mit AVRStudio in C, alse der Compiler von WinAVR.
Die Optimierungseinstellungen schau ich morgen mal an, ich denke es liegt auch mehr an der Lib (in dieser kann man Schriftarten laden und dann Text frei positionieren, das wird wohl einiges an Rechenzeit brauchen).

[AVRfan]

Ich programmiere mit AVRStudio in C, alse der Compiler von WinAVR.

Optimierungseinstellung is dann normalerweise standard -O0 also keine optimierung. In diesen fall wird der delay parameter (einen floating point wert) nicht durch der pre-processor sondern durch der AVR ausgewertet: kostet der arme AVR viel extra zeit. Versuche das mal mit -Os: der pre-processor wird der delay parameter schon auswerten (angenommen es ist einen festen wert) : delay zeit stimmt dann.

Martin.

[BlooD]

Danke für den Hinweis, aber die Optimierung -Os hatte ich schon drin.
Hab das ganze mal mit 16MHz getestet, da sieht das schon viel besser aus, aber um Strom zu sparen wollte ich eigentlich nicht so hoch...

Ich denke, das duch das ganze komfortable Zeug in der LIB von apetech (Schriftart auswählen, Positionieren, Zeichenkette schreiben etc.) der AVR so lange braucht.
Bleibt mir wohl nichts anderes übrig, als eine schnellere LIB zu suchen (und alles umzuprogrammieren) oder es in kauf zu nehmen und evtl. auf 16MHz zu gehen.

Oder noch nen anderen Vorschlag? Wenn ich die Daten puffern könnte, um diese ein wenig verzögert auf das Display zu senden würde das kein Problem darstellen, mich stört nur der langsame Aufbau.