Hallo zusammen,
ich habe es jetzt endlich geschafft eine Char. LCD anzusteuern (20x4),
in den ersten Tagen musste ich im Datenblatt und hier öffter
reinschauen, jetzt aber funktioniert einwandfrei.
Beim Char. LCD sind die Zeichen schon vorhanden und gerade mal 4 Zeilen,
wie sieht es aus mit einem Grafischen LCD, musste man jedes Pixel
ansteuerung??? wenn ich ein Zeichen geschrieben habe und später löschen
möchte muss ich dann die Adresse dieses Zeichen auch merken!!!!!!
Ein spezielles LCD habe ich noch nicht, ich überlege mir nur ob ich
gleich mit einem grafischen LCD anfange oder ist es doch so schwierig!!
Vielen Dank
Neuling schrieb:> wie sieht es aus mit einem Grafischen LCD, musste man jedes Pixel> ansteuerung???
Graphikdisplays leben davon, dass man jedes Pixel einzeln ansteuern kann
- und das muss man dann auch. Oft verwendet man Graphikprozessoren, die
primitive Zeichenbefehle (Linie/Kreis) bereits selber beherrschen.
meist mit einem eigenen font
der hat dann zB 7x5 pixel
deine funktionen schreiben in den LCD RAM dann die werte für die
7x5pixel
( RGB / graustufen/SW)
abhängig vom LCD eben 1/2/4/8bit pro pixel
damit hast du quasi einen eigenen zeilen/spaltenaufbau
das zu löschende zeichen hat eine Position ( dahin wo du schreiben
willst )
ob du ein neues zeichenschreibst oder löschen willst ist den LCD egal
es sind speicherstellen im LCD RAM
das selbe auch bei characterLCD
Neuling schrieb:> ich habe es jetzt endlich geschafft eine Char. LCD anzusteuern (20x4),> in den ersten Tagen musste ich im Datenblatt und hier öffter> reinschauen, jetzt aber funktioniert einwandfrei.
Ich versuche es mal mit einem Vergleich:
"Ich habe mir einen Tretroller selber gebaut, wie schwer ist es sich ein
Motorrad selber zu bauen?"
Antwort:
"Kommt darauf an, wenn du Motor, Bremsen, Felgen und Rahmen fertig
nimmst und nur alles zusammenbaust kann das was werden, ist aber
aufwändiger".
Übertragen:
Wenn du Bibliotheken hast die Zeichensätze beinhalten und sich um
Zeichengenerierung und grafische Primitives kümmern ist das aufwändiger
aber machber, wenn du das alles selber machen willst und "ich habe es
jetzt endlich geschafft" beim Zeichendisplay schon Schwierigkeiten
hattest, dann würde ich sagen lass es.
Im Gegensatz zu Chr-LCDs ist die Arbeit mit Grafik-LCDs ein sehr
anspruchsvolles Thema.
Als Einstieg solltest Du die Literatur-Ressourcen hier unter
"Artikelübersicht" durchforsten. Eine diesbezügliche Suche im hiesigen
Forum sollte auch einiges zu Tage bringen. Und dann gibt es da auch noch
spezielle Bücher, so z.B. das ELEKTOR-Buch: AVR-Programmierung, Bd.3 + 4
- u.a. LCD-Graphik.
Trotzdem ist es dann in der Praxis doch nicht ganz einfach, da die
marktüblichen Grafik-LCDs nicht nach einem einheitlichen Standard
angesteuert werden, sondern je nach verwendeten Display-Controller
unterschiedlichste Ansteuer-Prozederen verlangen - ohne ein
ausführliches Datenblatt steht man oft auf sehr verlorenem Posten.
Dann kommt noch hinzu, dass publizierte Ansteuerprogramme neuzeitlich
meist in "C" und selten ausreichend kommentiert vorliegen, so dass man
außer die Sprache zu beherrschen sich auch noch mit den Tücken
möglicherweise unvollkommener Bibliotheken rumschlagen muß.
Ich bin deshalb bei Assembler geblieben, weil ich da überblicken kann,
was wirklich passiert - und ein modulares Konzept kann man damit auch
realisieren. Meine Untersuchungen bezogen sich auf das LCD-Modul
DM19254A (192x64 Pixel, Controller: KS0108B), was seinerzeit von Pollin
sehr preiswert angeboten wurde.
Zu beachten ist, dass es sich infolge der Kommunikation Steuer-µC mit
dem Display-Controller um eine Master-Slave-Konfiguration handelt und
demzufolge Timing-Probleme anstehen.
Der Entwicklungsbericht hat derzeit weit über 70 A4-Seiten - ist aber
noch nicht abgeschlossen...
Anfragen bitte via eMail (www.ps-blnkd.de/Impressum)
Grüsse aus Berlin
PSblnkd
Grundlage ist "computergerechtes" Denken. Die Anordnung der Pixel im
Pufferspeicher entspricht selten direkt der auf dem Display, oftmals
sind sie noch zu Bytes oder Nibbles (4 Bit) organisiert und man benötigt
UND/ODER-Funktionen um deren einzeln habhaft zu werden.
Also schreibt man sich zunächst eine Software-"Schicht", die diese
"Umsortierung" erledigt, so dass man danach z.B. mit einer Funktion
"set_pixel(x,y,color)" (oder so ähnlich) einzelne Pixel gezielt
erreichen kann.
Der nächste Schritt wäre, diese Pixelfunktion zu sog. grafischen
Primitiven (Linien, Kreise, Flächen) zusammenzufassen, z.B.
"draw_rect(x,y,w,h)".
Wenn man mag, folgt dann die nächste Schicht, die darauf aufbauend ganze
Objekte visualisiert (Buchstaben, Icons, Buttons) usw. ...
Ach, lass Dich nicht abschrecken! Auch ein GLCD ist eigentlich recht
einfach zu programmieren. Als Basis braucht man im Prinzip nur ein
Set/Clear Pixel und damit kann man dann fast alles machen. Und
Beispiele/Libraries gibt es auch viele. Ist natürlich aber schon etwas
komplexer als ein standard LCD.
Du brauchst nur wesentlich mehr Speicher, z.B. für die Font-Daten.
Bei seriell angesteuerten (SPI/i2C) Displays gibt es oft keine
Möglichkeit, den Displayspeicher auszulesen, daher benötigt einen
entsprechenden Screen-Buffer. Bei 128x64 und 1bit sind dass schon 1024
Byte; Dazu dann noch mal die Font-Daten (die aber auch im Flash liegen
können). Nimm also einen entsprechend ausgestatteten µC, ein Tiny ist
eher schlecht :-)
Beim Display achte auf einen standard-Controller, z.B. KS0108 o.ä.
(wobei die Ansteuerung bei vielen gleich ist, ähnlich HD44780 für
alpha-numerische standard LCDs) und nur einer einfachen
Versorgungsspannung (dann musst Du die Kontrastspannung nicht selber
erzeugen!).
Hei schrieb:> Man sollte fuer ein graphik LCD auch noch etwas Rechenleistung uebrig> haben. Denn meist ist man ja mit Text drauf nicht zufrieden...
Und Speicher - in irgendeiner Form. Icons, Bildchen, Animationen,... da
wirds schnell knapp auf dem gängigen Microcontroller.
Noch eine Ergänzung zu meinem Beitrag vom 22.11.2013:
Wer sich lieber mit C++ bei der µC-Programmierung "rumquälen" will -
hier noch ein hilfreiches Buch:
"C und C++ für embedded Systems" ISBN 3-8266-1618-9
Dort ist auch ausführlich die Programmierung von Grafik-LCDs
beschrieben.
Grüsse aus Berlin
PSblnkd
Es gibt sehr unterschiedliche Controller für Grafik LCD. Einige davon
können eine Grafik- und eine Textebene übereinander packen, einige
können Zeichen selber in den Grafikspeicher schreiben und einige haben
halt nur einen reinen Pixelspeicher.
Also erst mal definieren was am Ende raus kommen soll und dann nach
passenden Displays schauen.
micha schrieb:> Ach, lass Dich nicht abschrecken! Auch ein GLCD ist eigentlich recht> einfach zu programmieren. Als Basis braucht man im Prinzip nur ein> Set/Clear Pixel und damit kann man dann fast alles machen.
Das schon. Aber nur sehr, sehr gemächlich...
Nein, es macht wirklich keinen Spaß, live dabei zusehen zu können, wie
sich selbst einfache blöde Rechtecke streifen- oder blockweise aus
Einzelpixeln formen. Das mag noch vor 40 Jahren so durchgegangen sein,
aber schon vor 30 Jahren war es sicher nicht mehr "state of the art".
> Du brauchst nur wesentlich mehr Speicher, z.B. für die Font-Daten.
Flash ist selten das Problem. In aller Regel klemmt's eher beim RAM.
Schon der Bildwiederholspeicher selber braucht relativ viel und viele
(gerade die besonders schnellen) Algorithmen brauchen noch mehr davon.
Und nach meiner Erfahrung sind µC quer über alle Leistungsklassen mit
internem RAM gewöhnlich chronisch unterversorgt, während genug Flash
meist kein Problem darstellt. Der Ausweg aus dem Dilemma besteht dann
darin, auf die effizientesten Algorithmen zu verzichten und statt dessen
weniger effiziente durch massives Loop-Unrolling zu beschleunigen. Damit
wenigstens der Flash genutzt wird, der sozusagen als unerwünschter
Kostenfaktor bei dem µC sowieso dabei ist, den man mindestens kaufen
muß, um den unbedingt erforderlichen RAM für den Bildwiederholspeicher
zu kriegen.
Typisches Beispiel: Ein Monochrom-Display der QVGA-Klasse (also z.B.
320x240). Für den Bildwiederholspeicher benötigt man bei Vollgrafik
320x240/8=9600 Byte RAM.
Da wird die Wahl schon recht eng. Nehmen wir mal an, man entscheidet
sich für einen Mega1284P, denn der hat mit 16k RAM wenigstens in etwa in
einer passenden Größenordnung.
Da könntest du nun 128k Flash mit Fonts füllen. Das braucht kein Mensch.
Ein Vektorzeichensatz für einen großen (gut lesbaren Sans-Serif, also
keinen sinnlos verspielten) Font schlägt mit nur rund 4..8k zu Buche.
Dazu ein oder zwei passende Bitmap-Fonts für ein oder zwei kleine
Schriftgrade nochmal mit etwa genausoviel. Also rund 16k für einen
ordentlichen Font, der in allen Größen schick und lesbar erscheint.
Also bleiben erstmal über 100k ungenutzter Flash. Das freut den Anbieter
des Controllers, aber nicht dich. Denn der hat dich mit seiner
Modellpolitik dazu gezwungen, eine Sache zu kaufen und zu bezahlen, die
du eigentlich garnicht benötigst.
Und wenn dann noch Farbe in's Spiel kommt, sieht das sogar alles noch
viel schlechter aus, denn die Fonts bleiben in aller Regel monochrom.
Da bleibt dann schon sehr reichlich Platz im Flash, um Schleifen endlos
auszurollen...
Neuling schrieb:> Beim Char. LCD sind die Zeichen schon vorhanden und gerade mal 4 Zeilen,> wie sieht es aus mit einem Grafischen LCD, musste man jedes Pixel> ansteuerung??? wenn ich ein Zeichen geschrieben habe und später löschen> möchte muss ich dann die Adresse dieses Zeichen auch merken!!!!!!
Tja, wenn man an die Wandtafel in der Schule was schreiben will, muß
entweder die Tafel an diese Stelle bereits abgewischt sein oder man muß
das selber erledigen. Genauso geht es bei den Grafikdisplays.
Die diversen Einwürfe, daß solche Displays schwer zu benutzen seien,
sind ein bissel hoch gegriffen - aber völlig einfach geht es auch nicht.
Schau dir hier in der Codesammlung mal die "Lernbetty" an, die ist
strunzbillig und dennoch auch für den Anfang in der Benutzung grafischer
Displays ein gutes Lernobjekt. (jaja, tibetanische Gebetsmühle..) Fonts
sind dabei, ebenso Bilder in (4) Graustufen, ebenso Pixel und Linien und
Rechtecke.
W.S.
Ich habe hier einen Versuch gestartet, möglichst viele monochrome (und
graustufen) Graphik OLEDs und Graphik LCDs zu unterstützen:
http://code.google.com/p/u8glib/wiki/device
Läuft mit ARM und AVR (ab ATTiny mit 8K Flash und 512 Bytes RAM).
Bei den Fonts steht jeweils der Speicherbedarf dabei. Damit kann man
sich ja ausrechnen, wieviel Flash man spendieren will:
http://code.google.com/p/u8glib/wiki/fontsize
Oliver
