> ...
> Die daraus erhaltene Hex-Datei habe ich ins EEprom des ATMega übertragen.
> ...
> 4. Nun rechne ich den ausgelesenen Wert des EEproms in eine Binärdatei um
> Bei den Punkten 4. und 5. brauche ich nun viel zu viel Zeit um den Wert
> umzurechen und einzeln an das GLCD zu senden. Die Grafik baut sich dann
> sichtbar langsam im GLCD auf! Komme ich um die Umrechnung der Daten
> herum? FASTLCD bringt mir für die einzelnen Pixel die Werte
> 1,2,4,8,16,32. Dem GLCD muß ich aber die Werte 248,249,250,251,252,253
> für die 6 Pixel senden!
Hm... Wenn du die Hex-Datei ins EEPROM geschossen hast, warum willst du
da dann noch was ins Binärformat umwandeln? Die Daten liegen ja
eigentlich schon binär vor.
Du solltest nicht einzelne Pixel setzen, um die Grafik aufzubauen (ist
aus meiner Sicht ein beliebter Anfängerfehler). Nimm lieber die
Eigenschaft, ein komplettes Byte auf einmal in den Grafikbereich zu
schreiben.
Hierzu musst du "nur" folgende Sachen beachten:
1. Du musst eventuell die Bitpositionen drehen, je nach Ausgabe des
FASTLCD, denn das LSB einer Speicherstelle im Grafikbereich entspricht
dem jeweils achten Pixel auf dem Display! Das heisst, wenn du die linke
obere Ecke beschreibst, ist die Pixelreihe D7,D6,...,D1,D0 (Das hast du
ja bereits erkannt).
2. Verwende als Position der Grafik die linke obere Ecke der Grafik. Das
hat den Vorteil, das man es sich leichter vorstellen kann. Du schreibst
dann einfach eine Zeile Daten in den Grafikbereich und setzt den
Adresspointer für die nächste Zeile der Grafik-Daten. Dann solange
wiederholen, bis die Grafik vollständig ist.
3. Die Sache hat zwei Haken:
- Bei der Variante mit Pixel setzen musst du ja eigentlich nur dafür
sorgen, dass dem 0-Punkt der Grafik (also quasi linke obere Ecke der
Grafik) die Position, auf der die Grafik erscheinen soll, hinzu addiert
werden muss, also quasi ein Offset. Bei der Variante mit Byte schreiben
gesellt sich das Problem hinzu, dass du je nach Position in X-Richtung
noch Bits schieben musst, wenn die X-Position nicht durch acht teilbar
ist. Das heisst, du musst für ein zu schreibendes Byte immer zwei Byte
Daten "anfassen" und Bits schieben.
-Im 6x8-Modus musst du das sowieso tun, sonst gehen dir zwei Bits an
Daten verloren.
Ich habe mir mal vor langer Zeit entsprechende Routinen gebastelt, und
bzgl. der Geschwindigkeit experimentiert. Ursprünglich habe ich Grafiken
ebenfalls mit dem Pixel-Befehl erzeugt, und bin später zum Byte-weisen
Schreiben gegangen, den du sparst in jedem Fall Zeit, da du ja
acht(sechs) Pixel auf einmal schreibst. Der Mehraufwand, den du durch
das nötige Bit-Schieben hast, lohnt sich aber zeitlich, da das
Bit-Schieben im Controller weitaus schneller geht, als ein Pixel zu
setzen, und zu warten, bis das LCD bereit fürs nächste Kommando ist.
Die Pixel-Befehle würde ich eher empfehlen für dynamische Anwendungen,
damit meine ich z.B. wenn der Controller Linien oder Kreise zeichnen
muss (siehe Bresenham). Bei fixen Daten (also z.B. Grafiken) lohnt sich
das m.E. nicht.
Zu der Sache mit den Werten von FASTLCD kann ich leider nichts sagen,
das kenne ich nicht, aber ich würd mich gern drüber informieren, wo
bekomme ich Infos?
Hm, ist schon spät, ich hoffe, ich konnte es klar rüberbringen, wenn
nicht, bitte fragen!
Ralf
