Ich habe ein GLCD 240x64 Pixel. Ich betreibe es im 6x8 Pixel-Modus. Es hat einen Controller T6963C. Das Display steuere ich mit einem ATMega32 an. Den Textmodus habe ich soweit im Griff. Nun habe ich z.B. ein Smiley in FASTLCD gezeichnet. Die daraus erhaltene Hex-Datei habe ich ins EEprom des ATMega übertragen. Beim Grafikmodus gehe ich dann so vor: 1. Initialisierung des Displays (Home Adresse, Grafik Area etc.) 2. Den ersten Wert aus dem EEprom lesen (Adresse 0) 3. Die Grafik Adresse 0 an das Display senden (enstricht ja den ersten 6 Pixel im Eck links oben des GLCD?!) 4. Nun rechne ich den ausgelesenen Wert des EEproms in eine Binärdatei um 5. Entsprechend der gesetzten Bits der Binärdatei übertrage ich jedes Pixel einzel an das GLCD. (Mit Bit Set z.B. 0xFD für das erste Pixel) Stimmt der eigentliche Ablauf so weit? 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!
> ... > 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
"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?" Hier im Anhang Nur so nebenbei, man kann das Bild auch für den T6963 im 6Bit Format exportieren. Diese kann man im Source einfügen oder halt im EEPROM speichern und übertragen. Das Pixel stzen usw. dauert doch viel zu lange. Gruß Sascha
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.