Forum: Mikrocontroller und Digitale Elektronik T6963C GLCD - prinzipieller Ablauf so richtig?


von ralf123 (Gast)


Lesenswert?

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!

von Ralf (Gast)


Lesenswert?

> ...
> 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

von ralf123 (Gast)


Lesenswert?

Danke Namenskollege!

von Sascha F. (sascha_focus) Benutzerseite


Angehängte Dateien:

Lesenswert?

"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
Noch kein Account? Hier anmelden.