DOG S 102 Grafikdisplay - Grundlagen

#2392532
Lesenswert?

Ich habe das DOG S 102 Grafikdisplay und würde gerne für dieses die 
Ansteuerung selbst programieren. Ich habe es laut schaltplan 
angeschlossen und es läßt sich auch initialisieren. Soweit so gut. Aber 
jetzt komme ich mit dem Datenblatt bezüglich der Manipulation der Pixel 
nicht zurecht. Sprich was muß man machen um einen Pixel zu setzen oder 
zu löschen (eine Linie zu zeichnen, Buchstabe zu programieren)? Ich lese 
etwas von Colum Adress, set scroll line, set page adress usw. aber was 
das genau macht ist leider für mich nicht ersichtlich. Kann mir jemand 
ein wenig auf die sprünge helfen?

Danke!
#2392846
Lesenswert?

>Sprich was muß man machen um einen Pixel zu setzen oder zu löschen
Pin CD auf high und dann einfach Byts an das Display senden.

>Ich lese etwas von Colum Adress, set scroll line, set page adress usw.
>aber was das genau macht ist leider für mich nicht ersichtlich.
Wichtig ist erst mal die Page. Das sind immer 8 Zeilen. 8 Zeilen = 8 Bit 
= 1 Byte. Das Byte was du an das Display sendest, stellt genau diese 8 
Bit dar.
Für die 64 Zeilen vom LCD gibt es dementsprechend 8 Pages (0-7).

Das nächst wichtigere ist die Column Address, also die Spalte. Das 
Display hat 102 Pixel horizontal. Die Column Address geht aber von 0 bis 
131. Das liegt einfach daran das die Controller nicht speziell 
angefertigt werden, sondern Standardtypen sind die zufällig mehr haben 
können als das LCD selber. I.d.R. liegen diese Bereiche im unsichtbaren 
Bereich.

Mit Page und Column Address kannst du dich also vertikal und horizontal 
auf dem Display bewegen. Alle andere Funktionen sind nur Zusatzfeatures.
#2393608
Lesenswert?

Wenn du das Display nicht abfragen kannst muss du dir einen Buffer im 
RAM aufbauen, dort kannst du einzelne Bits manipulieren und dann diesen 
RAM im ganzen ausgeben.

Schriftarten werden im Flash abgelegt, von dort die Bytes lesen und 
entsprechend ausgeben, das erfordert je nach Schriftgröße etwas 
Rechnerei über die einzelnen Pages.

Holger
#2396106
Lesenswert?

Holger W. schrieb:
> Wenn du das Display nicht abfragen kannst muss du dir einen Buffer im
> RAM aufbauen, dort kannst du einzelne Bits manipulieren und dann diesen
> RAM im ganzen ausgeben.

geht das mit einem atmega8? 8 pages und 102 Spalten sind immerhin 816 
Byte. Der µC hat 1K. Das Programm an sich benötigt doch auch RAM, oder?

> Schriftarten werden im Flash abgelegt, von dort die Bytes lesen und
> entsprechend ausgeben, das erfordert je nach Schriftgröße etwas
> Rechnerei über die einzelnen Pages.

OK, erstmal einen Buchstaben in eine Zeile schreiben sollte recht 
einfach gehen. Die dann Pixelgenau zu setzen wird dann wieder rechnerei.
Gast #2396136
Lesenswert?

Bei diesen Displays verzichte ich auf die freie pixelgenaue 
Positionierbarkeit und arbeite nur zeilenweise.
Spart viel Aufwand und Speicher.
Allerdings kann man dann recht einfach die Buchstaben auf 8,16,24,32 
Pixel Höhe skalieren.
:-)
Gast #2396144
Lesenswert?

Nö. Unterteilt wird da nix.
Ich kann Text frei positionieren (in x Richtung pixelweise in y-Richtung 
pageweise (8pixel)).
Was du mit dem Rest der Bildschirmfläche machst, ist ja egal. Sobald du 
halt auf die selbe Position schreibst, wirds überschrieben (logisch).
Gast #2396289
Lesenswert?

Ja, ihr seht schon, daß selbst ein kleines Grafik-LCD eine Nummer zu 
groß ist für einen kleinen 8 Bit Controller. Ich hab selber schon mal 
sowas ähnliches gemacht, nämlich eine ALPS-LSU (Pollin) an einen 
PIC16F871 gekoppelt und es funktioniert - ABER: Sowas macht man eben nur 
zum Demonstrieren, daß es prinzipiell klappt. Um damit was Richtiges zu 
machen, da sind all die kleinen PIC's und Atmel's eine Nummer zu klein.

Also mein Rat: Wer mit Grafik-LCD's anfangen will, sollte rechtzeitig 
auf einen größeren Controller umsteigen und alle diese kleinen 8-bitter 
gar nicht erst in Erwägung ziehen.

W.S.
Gast #2396314
Lesenswert?

> Also mein Rat: Wer mit Grafik-LCD's anfangen will, sollte
> rechtzeitig auf einen größeren Controller umsteigen und alle
> diese kleinen 8-bitter

Naja, ich wuerde olle 8bitter auch dringend zu vermeiden versuchen. Aber 
das hier sichtbare Problem ist sicher nicht bitabhaengig. Man sollte 
eher darauf achten einen Controller zu verwenden der genug Ram hat.
Privat, wo es auf einen Euro mehr oder weniger nicht ankommt, wuerde ich 
sicher keinen Controller mehr verwenden der weniger als 8k Ram hat.

Man kann aber das PRoblem auch anders angehen. Eventuell braucht man 
nicht nicht das ganze Display pixelorientiert anzusprechen. Dann reicht 
ein kleineres Stueckchen Ram. Oder man hat eine Anwendung wo man nur die 
letzten xx-Pixel einzeln setzen muss. Dann reicht es aus wenn man nur 
100Bytes oder so in einem Buffer haelt.
Kommt halt sehr auf die Anwendung an. Aber dabei lernt man dann weniger 
geizig zu sein und beim naechstenmal einen Controller mit mehr Ram zu 
kaufen. :-)

Olaf

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