Ich möchte mich mal dran versuchen ein TFT-Display an einen Atmega328 (oder ähnlich) ans Laufen zu bringen, weiß aber nicht so recht welches Display hier wirklich was wäre. Bisher habe ich immer Displays auf Basis des HD44780 oder die OLEDs mit SSD1306 bzw. SH1106 Controller verwendet. Die sind mir aber etwas zu klein (ich werde älter und sehe nicht mehr so gut) und dachte mir jetzt so ein 3.5" TFT, ggf. mit Touch, wäre ja recht nett. Mit Arduino scheint es da auch ein paar nette Beispiel zu geben aber ich bin mehr so auf der C-Schiene und da ist es anscheinend schon recht mühselig. Daher will ich mal nachfragen welches Display mir hier der ein und andere empfehlen kann.
Arduinoquäler schrieb: > 328 mit oder ohne Arduino? Für "328 mit Arduino" gibt es diese Module (in verschiedenen Auflösungen) zum direkt aufstecken: Beitrag "LCD 480x320 mit wenig Aufwand zum Anbinden"
@ M. Köhler (sylaina) >Ich möchte mich mal dran versuchen ein TFT-Display an einen Atmega328 >(oder ähnlich) ans Laufen zu bringen, weiß aber nicht so recht welches >Display hier wirklich was wäre. Nimm ein intelligentes, das entlastet den AVR. http://www.lcd-module.de/produkte/ediptft.html http://www.lcd-module.de/produkte/edip.html Denn du willst ja meistens nicht den ganzen Grafikkram neu erfinden sondern anwenden.
TFT und Atmega scheitern in der Regel an zu wenig RAM. Denn ohne großartige Klimmzüge machen zu müssen, brauchst du mindestens soviel RAM wie das Display Pixel hat. Bei Farbe sogar mehrere Bits pro Pixel. Wie andere bereits schrieben, gibt es jedoch "intelligente" Display Controller die wir der dir bereits bekannte HD44780 zum Beispiel Text erzeugen können aber auch geometrische Figuren bis hin zu ganzen Bildern. Ich denke auch, dass du nach so einem Display suchen solltest. Sonst kannst du das Display nur sehr eingeschränkt nutzen und hast kaum Ressourcen für die eigentliche Anwendung frei.
Stefan U. schrieb: > TFT und Atmega scheitern in der Regel an zu wenig RAM. Denn ohne > großartige Klimmzüge machen zu müssen, brauchst du mindestens soviel RAM > wie das Display Pixel hat. Nein, denn es soll Leute geben die wollen einfach nur Text auf dem Display ausgeben, und dafür braucht es eben kein RiesenRAM. Komisch dass es soviele Leute gibt die ohne Framebuffer einfach so ein LCD benutzen. Sogar auf dem 328.
Arduinoquäler schrieb: > 328 mit oder ohne Arduino? Ohne, ich hab zwar den Arduino Uno, aber nur weil mir das für Testschaltungen so gut gefällt, programmiert wird bei mir mit C, der AVR-GCC ist mein Freund. Die Arduino IDE benutze ich nicht. Falk B. schrieb: > Denn du willst ja meistens nicht den ganzen Grafikkram neu erfinden > sondern anwenden. Ja, das ist sehr sinnvoll. Ich habe in der Tat nicht vor das Rad neu zu erfinden. Danke für die Beispiele. Arduinoquäler schrieb: > Nein, denn es soll Leute geben die wollen einfach nur Text auf > dem Display ausgeben, und dafür braucht es eben kein RiesenRAM. Ich interessiere mich jedoch auch für Grafik, die ein und andere Zeichnung, finde ich, kann in der ein und anderen Anwendung mehr aussagen als tausend Worte ;)
> Nein, denn es soll Leute geben die wollen einfach nur Text auf > dem Display ausgeben, und dafür braucht es eben kein RiesenRAM. Stimmt, dann braucht man keinen Pufferspeicher. Auch nicht, um einfache Linien zu zeichnen. Kompliziert wird es dann, wenn man ohne Pufferspeicher Scrollen möchte und das Display das nicht von alleine kann. Oder wenn man Grafiken und Text überlappend ausgeben will. Zum Beispiel für einen Button.
Beitrag "FT800 / FT810 Library" Die FT8xx TFTs liegen preislich über den China Pixel TFTs, aber unter den eDIP. Dazwischen gibt es noch die Nexion Dinger. Gameduino2 wäre jetzt direkt ein FT800 TFT Shield, kostet aber etwas mehr. Sonst sowas hier: http://www.watterott.com/de/5-800x480-Display-mit-kapazitivem-Touchscreen-FT811CB-HY50HD http://www.hotmcu.com/43-graphical-lcd-touchscreen-480x272-spi-ft800-p-111.html?cPath=6_16 Das 7° TFT von Riverdi mit dem FT813 und 800x480 hatte ich auch schon an einem Arduino UNO hängen, Text ist da total unkritisch, nur mit Bildern schaufelt man sich da sehr schnell das FLASH zu. :-) Ausserdem gibt es noch die CLEO Module von FTDI. http://www.ftdichip.com/Products/Modules/CleO.htm
Problem wird dabei auch die Größe von Bildern. Denn wenn man ein schönes TFT schon mal hat, möchte man ja auch farbig schöne Grafiken darin anzeigen. Wenn man nur ein kleines Bild, einfügen möchte, so können das schon einige kByte bei 24Bit Farbtiefe sein. Minimiert man vorher die Grafiken am PC auf z.B. 8Bit Farbtiefe, so sind es erheblich weniger kByte aber das Bildchen sieht dann aber auch Schei...e im Display aus. Dieses Problem kann man aber mit einer Neuberechnung/Hochrechnung der geringeren Pixelwerte auf bessere Farbwiedergabe im TFT mit einem Programm auf dem ATmega ganz gut beheben. Somit kann man auch mit einem ATmega ganz annehmbare Ergebnisse mit schönen Bildchen mit wenig kByte auf dem Display erzeugen. Als Speicher für einzufügende Grafiken eignen sich sehr gut Flash-Speicher die über SPI angesteuert werden. Ich hatte mal den SST25VF016 für so etwas verwendet. Der hat 16MBit.
Falk B. schrieb: > @ M. Köhler (sylaina) > >>Ich möchte mich mal dran versuchen ein TFT-Display an einen Atmega328 >>(oder ähnlich) ans Laufen zu bringen, weiß aber nicht so recht welches >>Display hier wirklich was wäre. > > Nimm ein intelligentes, das entlastet den AVR. > > Gibt's auch eine Familie von Nextion: https://www.itead.cc/display/nextion.html kann man auch über eBay kaufen und bis 2,8" bleibt man unter der Zollgrenze: https://www.ebay.de/itm/2-8-Nextion-HMI-TFT-LCD-Display-Module-For-Raspberry-Pi-2-A-B-Arduino-Kits/272855194736 Da hast Du dann die Intelligenz im Display und brauchst nur eine Serielle Schnittstelle
M. K. schrieb: > Ich interessiere mich jedoch auch für Grafik, die ein und andere > Zeichnung, finde ich, kann in der ein und anderen Anwendung mehr > aussagen als tausend Worte ;) Dafür nimmt man dann eine erweiterte Textausgabe, nämlich eine, bei der ein gewisse Zahl der ausgebbaren Zeichen zur Laufzeit (um)definierbar sind. Sprich: variable Blockgrafik. Das reicht für sehr viele Anwendungsfälle völlig aus. Oft kann man sogar auf die Dynamik verzichten, indem man einfach clever vordefinierte Blockglyphen benutzt, die sich zu recht komplexen Grafiken zusammbauen lassen. Siehe z.B. https://de.wikipedia.org/wiki/Codepage_437 und darin die Zeichen $b0..$df. Damit kann man schon einiges an Grafik bauen. Übrigens: auch pixelweises Scrolling ist mit Text/Blockgrafik relativ einfach und vor allem auch ohne vollständigen Framebuffer machbar. Alles was man braucht, ist ein Erweiterung des Textbuffers um eine Zeile und/oder Spalte. Und natürlich die entsprechende Programmierung der Ausgaberoutine.
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.