GLCD mit ASM

OP #1029533
Lesenswert?

Hallo an alle,

ich habe letztes Jahr mit ASM-Programmierung begonnen und seitdem 
'normale' LCD's 16x1 oder 16x2 verwendet.

Ich würde mich nun gerne mal an einem Grafik-LCD versuchen. Leider habe 
ich hier kein Torturial darüber gefunden. Kennt jemand eine Adresse, wo 
man etwas nachlesen kann oder kann mir jemand mit ein paar Stichpunken 
erklären, wie man an die Programmierung herangeht. Ist etwas Besonderes 
zu beachten? Bei Pollin gibt es einige GLCD's so um 18-20€. Sind 
bestimmte Controller zu bevorzugen?

Verwende AVR-Studio4 und PonyProg.

Ich hoffe, die Erfahrenen unter euch reißen mir nicht gleich den Kopf 
runter, wegen einer so allgemein gestellten Frage. Also ich will's mir 
wirklich selbst erarbeiten, suche nur irgendwie einen Anfang.

Axel
#1029566
Lesenswert?

dummy wrote:
> Sourcecodes dazu findest du aber fast nur in C.
> ASM macht kaum einer mit GLCDs. Wozu auch ;)

Realitätsfremd, diplomatisch ausgedrückt.

Ich habe es ausprobiert beim T6963c. Versucht man Libs, die sich auch 
bessere nennen, im reinen Grafik-Modus anzuwenden (wozu sonst hätte man 
ein GLCD) fällt die Verzögerung sehr störend auf.

Erst nachdem ich meine eigenen in ASM erstellt habe kann man damit auch 
etwas anfangen.

Empfehlen kann ich dem OP zuerst die C-Sourcen aus Codesammlung 
auszuprobieren. Wird nur Textmodus benötigt dann reichen diese meist 
aus.
Gast #1029600
Lesenswert?

Hi

>ASM macht kaum einer mit GLCDs. Wozu auch ;)

Quatsch! Ich habe z.B. meine Routinen für den T6963 vor zig Jahren 
gemacht und benutze die seit dem fast unverändert. Die meisten 
Funktionen werden über Macros aufgerufen. Also das Laden eines Bitmaps 
brauche ich beispielsweise eine Befehlszeile. Geht es in  C mit weniger?

@Axel

SED1520 ist bei kleineren Displays auch häufiger anzutreffen.

1. Bevor du ein Display kaufst, besorge dir ein Datenblatt vom Display
   und vom Controller. Wenn du damit klarkommst kannst du kaufen.

2. Wichtigsten Routinen sind 'Kommando schreiben' und 'Daten schreiben'.
   Alle Controller, die ich bisher benutzt habe hatten ein 
Statusregister
   mit 'Busy'-Flag. Es ist sinnvoll das Flag in den o.g. Routinen
   abzufragen.

3. Nächster Punkt ist die Initialisierung des Displays.

4. Wenn das funktioniert kannnst du das Display beschreiben


MfG Spess
#1030477
Lesenswert?

In meinem aktuellen Projekt (wird demnächst veröffentlicht) bin ich 
einen etwas anderen Weg gegangen. Im Controller habe ich 1K RAM als 
Bildwiederholspeicher, 64 Zeilen a 16 Bytes. Im Timerinterrupt gebe ich 
die Daten als Video aus und berechne währenddessen das nächste 
auszugebende Byte für das GLCD (genauergenommen 2 Bytes, eins für die 
linke und eins für die rechte Displayhälfte). Bei 15KHz Rate brauche ich 
mich auch um kein Busy-Flag zu kümmern (muß nur schreiben) und erhalte 
ca. 30Hz Refresh-Frequenz ohne dass die CPU jemals auf das Display 
warten muss.
Durch den "linearen Video-Speicher" ist das Schreiben eigener 
Grafikroutinen dann ein Kinderspiel...

Jörg

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren