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.
ftdi FT800 leave it to EVE, z.B. mit 4,3" Display... schöne Sache das!
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
Man sollte fuer ein graphik LCD auch noch etwas Rechenleistung uebrig haben. Denn meist ist man ja mit Text drauf nicht zufrieden...
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.