Ich bin auf der Suche nach einem Grafikdisplay. Optimale Parameter: - etwa 7 Zoll - natürlich möglichst gute Auflösung - 5V, nur wenns unbedingt sein muß 3,3V - bastelfreundliche Schnittstelle (kein LVDS oder so) Was gibts da so auf dem Weltmarkt, womit habt ihr gute Erfahrungen gemacht und womit nicht so?
Was ist "Gut"?
> bastelfreundliche Schnittstelle (kein LVDS oder so)
Woran willst Du das Display anschließen?
Wahrscheinlich wirds ein AVR, so lange sich der Wechsel zum ARM Cortex oder welche ARM-Variante auch immer vermeiden lässt.
Aha. Du suchst also nicht einfach ein Display, sondern ein Display mit integriertem Controller. Denn ein "nacktes" Display kannst Du mit einem AVR nur mit enormen Ressourcenverbrauch ansteuern, schließlich will zyklisch der gesamte Displayinhalt ausgegeben, was bedeutet, daß Du mindestens so viel RAM haben musst, wie das Display benötigt, oder aber daß Du nur sehr eingeschränkte Dinge mit dem Display anstellen kannst, wie z.B. nur Text ausgeben. Viel Zeit, andere Dinge zu tun, hat Dein AVR dann nicht mehr. Displaycontroller, die man mit recht wenig Rechenleistung und Speicherbedarf ansteuern kann, sind z.B. die "eve"-Controller von FTDI.
Ben B. schrieb: > Wahrscheinlich wirds ein AVR, so lange sich der Wechsel zum ARM Cortex > oder welche ARM-Variante auch immer vermeiden lässt. Du machst entweder Witze oder es ist die blanke Ahnungslosigkeit. Die üblichen 7" Displays haben 800x480 Pixel zu je 18 Bit und benötigen Refresh mit etwa 33 MHz Pixeltakt. Wenn man die Sparversion 565 (5 blau, 6 grün, 5 rot) nimmt, was für die meisten Fälle völlig ausreicht, dann sind das etwa 66 MByte/Sekunde, die du da durchsetzen mußt. Für sowas fängt die Welt mit einem LPC17xx oder LPC4088 an, dazu ein externer RAM passender Größe (768k). Darunter wird das nichts. W.S.
AVR + 7" Display = Display Controller zusätzlich zum Display. Ausserdem habe wohl alle aktuellen 7" Displays Folienkabel dran, sind also wohl bastelunfreundlich. Wenn du es technisch einfach haben willst, dann verwendest du einen RPi oder ähnl als Display-Controller für den AVR. ;-)
Äh hallo... nee, als Witz war's eigentlich nicht gedacht, sondern ich hatte schon ein Display gesucht, was ein wenig eigene Intelligenz mitbringt, so daß man sich auf Controller-Seite nicht mit dem Refresh oder Zeilen/Spalten-Ansteuerung beschäftigen muß. Ich brauche auch nicht unbedingt Farbe, 1 Bit/Pixel wäre ausreichend. Weiß halt nicht, ob es da "so einfache" Displays gibt. Daher die Frage.
Ben B. schrieb: > Wahrscheinlich wirds ein AVR Dann wirst du vermutlich nicht über so ein 4 Zoll TFT mit integriertem Controller hinauskommen: https://de.aliexpress.com/item/4-0-inch-8bit-TFT-LCD-Screen-Module-with-PCB-ILI9486-Drive-IC-320-480-Touch/1899444540.html?spm=a2g0x.10010108.1000016.1.3aa94d7b7qgxY7&isOrigTitle=true
Einen einfarbigen Display-Controller mässiger Auflösung und direkter Ansteuerung durch AVR kann man sich mit überschaubarem Aufwand bauen, BTDT. Gab es auch mal hier im Forum von Benedikt. Das Problem sind die dazu passenden 7" Displays mit bastelkonformem Anschluss. Diese Dinosaurier sind längst ausgestorben und möglicherweise nicht einmal mehr in Pollins Restekiste zu finden. Es könnte am billigsten sein, ein ausgedientes 7" Tablet per BT mit dem AVR zu verheiraten.
:
Bearbeitet durch User
Das ist (noch) meine erste Wahl dazu: https://www.matrixorbital.com/ftdi-eve/eve-ft812/eve2-70g Was das allerdings nicht erfüllt sind die 5V, das benötigt 3,3V zur Versorgung und als Logik-Pegel. Davon abgehalten das an einen 90CAN128 oder M1284 bei 5V zu klemmen hat mich das aber nicht. Die nächste Generation von den Dingern bringt ein externes SPI-Flash mit, aber bis auf die Teile von Bridgetek selber mit BT816 Chip drauf gibt es soweit ich weiss noch kein Produkt am Markt. Und BT816 ist resistiv touch, BT815 kapazitiv. Mal schauen, wie das zur Embedded World aussieht.
Evtl. ist das da ein passendes "einfaches" 7" LCD. https://eckstein-shop.de/70-800x480-TFT-LCD-Display-ohne-Touchscreen-SSD1963-MCU-Arduino-Kompatibel Es kommt anscheinend mit Controller (Arduino-Kompatibel), mal die umfangreiche Doku lesen....
Thomas F. schrieb: > Dann wirst du vermutlich nicht über so ein 4 Zoll TFT mit integriertem > Controller hinauskommen: Nö. Hier gibt's z.B. 7 Zoll: https://www.ebay.de/itm/7-0-inch-OHNE-Touch-SSD1963-MCU-800-480TFT-LCD-Display-fur-Arduino-CP11014/271513577223?hash=item3f37786707:g:SKcAAOSwxNxbWuew:rk:48:pf:0
Danke euch für die Antworten und Vorschläge... aber die Dinger sind eigentlich alle gleich viel zu gut. :) Gibts kein "einfaches grafisches LCD" in der Größe? Oder vielleicht muß ich die Frage umstellen, welches ist das größte grafische Standard-LCD-Display ohne TFT-Techik? So wie man die kleinen grafischen LCDs mit ihrer 8-Bit-Schnittstelle kennt, nur eben größer?
Am AVR könnte ein RA8875 oder vielleicht besser Nextion(nur von gehört) klappen.. der RA8875 unterstüztzt bei 800x480 leider nur 1 Layer und 256 Farben. Der kann aber von einem Flash Chip Bilddaten lesen welche nur mit 10 SPI/I2C bytes angeschubbst werden können, ist nen bisschen Tricky da man den Flash nicht eingelötet programmieren kann aber das klappt schon irgendwie/mit angelötetem Adapter. Ausserdem unterstützt der 100 Built-In befehle für Linien /Symbole und unterstützt optional einen Fontchip um fertige Fonts ohne viele Bytes zu zeichnen. Also wenn man sich die mühe macht und Farben benötigt, best Option. z.B. https://www.buydisplay.com/default/tft-display/7-inch?cotroller_ic=734
:
Bearbeitet durch User
Ben B. schrieb: > Gibts kein "einfaches grafisches LCD" in der Größe? Viele. Als Displays ohne Controller mit sowohl mechanisch als auch in der Signalisierung hässlichem Interface. Als Komplettlösung mit Controller und angenehmem Interface braucht das nur der Arduino-Markt.
> RA8875 Interessant, der kann fast schon wieder zuviel. @PRX Ob für Arduino oder nicht ist mir eigentlich schnuppe (wobei wohl nahezu fast alles beim Arduino auf dem AVR basiert)... Hauptsache irgendwas, was möglichst groß ist (nur damit möglichst gut lesbar, nicht wegen schön bunt) und wo man z.B. Kurven mit Messwerten drauf darstellen kann, wo man nicht auf reinen Text angewiesen ist. Mehr braucht es nicht.
Ben B. schrieb: > welches ist das größte grafische Standard-LCD-Display ohne TFT-Techik? Du willst so etwas nicht haben, denn mit zunehmender Größe und Auflösung wird die Darstellungsqualität immer mieser. So wie sie man sie von sehr alten Notebooks aus der ersten Hälfte der 90er Jahre kennt. Ein TFT-Display zwingt Dich nicht, es auch in Farbe anzusteuern. Du kannst es auch als rein monochromes Display verwenden. Mit steigender Auflösung steigt aber auch der benötigte Pixeltakt, denn solche Displays werden zyklisch aufgefrischt (das passiert meistens mit 60Hz). Bei einem 800x480-Display ergibt sich so ein Pixeltakt im mittleren zweistelligen MHz-Bereich.
Ben B. schrieb: > @PRX > Ob für Arduino oder nicht ist mir eigentlich schnuppe Ich schrieb Arduino-Markt. Produkte dafür sind quasi per Definition bastelkompatibel. Weshalb der Begriff auch dann bei Suche und Einschätzung hilft, wenn man sie nicht an einen Arduino anschliessen will.
:
Bearbeitet durch User
Es ist generell schwer geworden, mit einem AVR noch ein wettbewerbsfähiges Produkt hinzubekommen. Gerade bei sowas, ein Cortex-M4/7 Controller wäre eigentlich auch schon überlastet, deshalb hat er on-Chip noch Peripherie wie LTDC (Schaufelt die Bytes aus dem RAM ans Display), Blitter (2D Grafikbeschleuniger für rechteckige Bildausschnitte füllen/kopieren). Auf Softwareseite gibt es Toolkits wie touchGFX und embedded wizard. Mit selbstprogrammieren kommst du da auf keinen grünen Zweig mehr. Heute steht bei MCUs einfach der nächste Schritt an: Nach der Umstellung von ASM auf C beim MCS51/PIC geht es jetzt darum, nicht mehr jede Zeile selbst zu schreiben, wie das bei vielen beim AVR noch der Fall war.
Ben B. schrieb: > welches ist das größte > grafische Standard-LCD-Display ohne TFT-Techik? Das dürfte sowas hier sein: https://www.lcd-module.de/deu/pdf/grafik/dogxl160-7.pdf Nur muss bei so einem Ding jeder Pixel gesetzt werden und bei einem intelligenten Display mit FT8xx/BT8xx oder auch Nextion, RA8875 oder einem mit Mikro-Controller drauf läuft das über Objekte oder Funktionen.
Ben B. schrieb: > Hauptsache irgendwas, > was möglichst groß ist (nur damit möglichst gut lesbar, nicht wegen > schön bunt) und wo man z.B. Kurven mit Messwerten drauf darstellen kann, > wo man nicht auf reinen Text angewiesen ist. Ich weiß nicht, welche Ansprüche Du an die Geschwindigkeit für den Bildaufbau stellst. Mir wäre ein AVR viel zu langsam, selbst, wenn er nur die Koordinaten der einzelnen Pixel erzeugen soll, wie es bei der Darstellung von Kurven unbedingt notwendig ist. Sollen dann noch die Schriftzeichen Punkt für Punkt generiert werden, ist mit einem AVR dann völlig Feierabend. Wenn Dir schwarz-weiß reicht, kannst Du ruhig ein TFT-Display nehmen und alle RGB-Leitungen zusammenschalten. Bei einem 7" Display mit 800x480 Pixeln reichen schon 48 KB Bildspeicher (neudeutsch: framebuffer). Soviel RAM findet sich schon in vielen Controllern. Aber gut, das wird Dir wohl schon zuviel Aufwand sein. Ein Display mit FT8xx wäre vermutlich ein brauchbarer Kompromiss, da es schon über eigene Zeichensätze verfügt - unabhängig davon, ob die einem nun gefallen und im Bereich 0x80 - 0xff unvollständig sind. Wie schnell soll denn der Bildinhalt geändert werden? Sollen aktuelle Werte schnell aufgefrischt werden oder bleibt das Bild minutenlang unverändert?
Der Flaschenhals beim AVR wird eher die Schnittstelle mit dem Display sein. Die Kurve selbst zu berechnen oder die Pixel in einen Framebuffer hineinzurechnen, schafft ein AVR mit 20Mhz ziemlich problemlos. Vielleicht war meine Frage falsch gestellt, so wie ich das hier sehe können 7-Zoll-Displays schon mehr als ich brauche. Da hab/hatte ich halt wirklich wenig Ahnung von, was es da so gibt. So hoch, wie die Auflösung da schon ist, brauche ich sie gar nicht. Ich denke, daß so 160x120 Bildpunkte oder was es in dem Bereich gäbe schon völlig ausreichend sind. Nur das Display sollte eben nicht zu klein sein, damit man es gut ablesen kann. Ich überlege auch immer wieder auf die ARM-Controller zu wechseln, eben weil die mehr Speicher (RAM) haben als ein AVR. Allerdings habe ich einige Defizite in der C-Programmierung weil unsere damalige Schul-IT-Lehrerin uns lieber TurboPascal beibringen mußte anstatt etwas sinnvolles mit Zukunft zu wählen. Ich hätte lieber C-Grundlagen gelernt, dann hätten mit die Jahre etwas gebracht. Naja, was will man erwarten, wenn ein Herd für die Tussi schon Mikroelektronik ist. Aber deswegen (und weil ich dann genau weiß was der Controller wirklich macht) programmiere ich so gerne mit Assembler. Ich vermute aber, daß das beim ARM so langsam schmerzhaft wird. Also in dem Moment wo ich auf die ARMs wechsle bedeutet das sehr viele verhasste C-Noob-Fragen von mir an euch hier im Forum. Außerdem gibts die ARMs nur selten in einem bastelfreundlichen Gehäuse. Dann müsste man für jedes kleine Projekt sofort eine eigene SMD-Platine entwerfen. Beides zusammen führt dazu, daß ich sehr gerne noch eine Weile mit den AVRs "spiele". :) Beispielsweise bräuchte ich nur zu fragen, welcher denn der für den Einstieg am besten geeignete ARM ist... Schon habe ich wieder viele verschiedene (sicherlich gut gemeinte) Empfehlungen und bin hinterher nicht wesentlich schlauer als vorher. Naja mal sehen.
Programmieren lernt man sicherlich nicht in der Schule. Wenn das schon die Einstellung/Erwartungshaltung ist, kannst du es knicken.
Wie wäre es mit dem EADIPTFT von EA? Es ist sehr teuer, lässt sich aber auch ganz leicht mit einem AVR (per SPI, I2C oder UART) ansteuern, da es fast alles intern macht. Wenn man Makros programmiert kann man mit einem einzigen Befehl vom µC einen ganzen Seitenaufbau aufrufen. https://www.lcd-module.de/produkte/ediptft.html
Ben B. schrieb: > weil unsere damalige > Schul-IT-Lehrerin uns lieber TurboPascal beibringen mußte anstatt etwas > sinnvolles mit Zukunft zu wählen. Schimpf nicht über die gute Frau: TurboPascal zu lehren war bestimmt kein Fehler! Ben B. schrieb: > Ich denke, daß so 160x120 > Bildpunkte oder was es in dem Bereich gäbe schon völlig ausreichend > sind. Nur das Display sollte eben nicht zu klein sein, damit man es gut > ablesen kann. Das größte praktikable Display für diese Auflösung ist ein 5,7" mit 320x240 Pixeln, wobei jeder Punkt dann als 2x2 Pixel ausgegeben werden muß. Ein 5,7" Display ist fast genau so hoch wie ein 7" nur eben nicht ganz so breit. 160X120 kann man auch auf einem 7" ausgeben, indem jeder Punkt auf 5x4 Pixel aufgepustet wird, was dem Faktor 20 gegenüber der gewünschten Auflösung entspricht. Bei 160x120 könnte ein AVR die Koordinaten noch als Bytes handhaben, auf größeren Displays - und ganz speziell einem 7" - geht seine Geschwindigkeit voll in den Keller. Wenn man dann noch sauber programmieren will und die Pixelkoordinaten überprüft, ob sie noch in den Bildspeicher passen, bricht die Geschwindigkeit noch weiter ein. An anderer Stelle hatte ich mal 5,7" TFT-Displays angeboten: Beitrag "[V] 5,7"-TFT QVGA, gebraucht" Ein Beispiel für dessen Anwendung findest Du hier: http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-5 Wenn es um große Darstellung mit geringer Auflösung geht, sind diese Anzeigen m.M.n. nach wie vor ein guter Kompromiß. m.n. schrieb: > Wie schnell soll denn der Bildinhalt geändert werden? Sollen aktuelle > Werte schnell aufgefrischt werden oder bleibt das Bild minutenlang > unverändert? Dazu hattest Du noch nichts geschrieben.
Ben B. schrieb: > Ich überlege auch immer wieder auf die ARM-Controller zu wechseln, eben > weil die mehr Speicher (RAM) haben als ein AVR. Allerdings habe ich > einige Defizite in der C-Programmierung weil unsere damalige > Schul-IT-Lehrerin uns lieber TurboPascal beibringen mußte anstatt etwas > sinnvolles mit Zukunft zu wählen. Ich hätte lieber C-Grundlagen gelernt, > dann hätten mit die Jahre etwas gebracht. Naja, was will man erwarten, > wenn ein Herd für die Tussi schon Mikroelektronik ist. Schreib keinen Quatsch. Pascal zu können und dann C dazu zu lernen, ist vermutlich das Sinnvollste, was man heutzutage tun kann. Man hat die logischen Grundlagen per Pascal gelernt und kann C mit etwas Abstand und weiterem Horizont sehen. Du willst ja hoffentlich nicht mit Scheuklappen durch dein Leben gehen. Zu deinen Display-Ideen mußt du zuvörderst eines bedenken: Grafikdisplays sind dazu da, daß man sie eben grafisch benutzt. Also Flächen füllen, Punkte, Linien, Kreise und anderes zeichnen, Textzeichen in verschiedenen Fonts an frei wählbare Stellen zeichnen. Für sowas braucht man einen ausreichend großen RAM, wo man den Bildschirm-Inhalt drin aufbaut - und der µC muß dafür genug RAM haben, sonst müßte man einen Extra-RAM außen anschließen, wozu nun wieder ein externes Businterface benötigt wird. All diese kleinen 8 bittigen Controller sind eigentlich für so etwas eine Nummer zu klein, weswegen man dort immerzu mit Platzproblemen im RAM zu tun hat. Wenn du diese beherrschen könntest, hättest du den Thread nicht gestartet. Und.. nebenbei gesagt, IST ein Herd heutzutage Mikroelektronik - und das nicht nur für Tussi, sondern auch für alle Anderen. Oder was meinst du, wie ein 13 kW HF-Sender in der Küche (sprich Induktionsherd) sich automatisch an die Topfgröße anpaßt, ohne daß mal eben ein kleines halbes kW davon irgendwo zum KAWOMM führt? Oder daß der Geschirrspüler einen WLAN Anschluß hat? Sei nicht so überheblich. Nochwas: zu meinen, daß man eben nur "einen ARM nimmt", ist weitaus zu blauäugig. Ich hatte das ja schon weiter oben geschrieben. Man braucht für ein 7" TFT in Farbe fast ein Megabyte an RAM für den Bildinhalt. Und in Monochrom sind größere Displays nicht mehr Mode. Und wenn du ein altes großes Monochrom-Display irgendwo noch kriegst, dann wirst du dort auch mit dem dauernden Refresh konfrontiert. W.S.
Also mit Turbo Pascal konnte ich nach der Schule nie wieder was anfangen. Ich muß auch sagen, ich weiß nicht was ich da groß gelernt habe. Wie man programmiert wußte ich schon vorher und als ich den dämlichen Cursor, den Turbo Pascal immer auf dem Bildschirm (ja, damals gabs noch so komische computergesteuerte Elektronenbeschleuniger mit 2cm dickem Glas vorne, kennt man heute noch nur vom Aquarium) blinken lässt bei meinem Programm mittels Inline-Assembler und einer Bios-Funktion vom Bildschirm geschmissen habe (damit kann man den auf Zeile unten+1 (glaube damals 26) setzen und weg ist er), hat die liebe Frau mir gleich unterstellt, ich würde den PC damit kaputtmachen. Die "theoretischen Feinheiten" oder Formen, Möglichkeiten, die man uns damit vermitteln wollte (Deklarieren von Variablen oder sowas Langweiliges wie Funktionen), hätte man uns mit C genau so gut wenn nicht besser "beibringen" können. Aber so war es irgendwie der sinnloseste Unterricht, den ich je erlebt habe. Diejenigen, die es hinterher konnten, konnten es vorher auch schon und die, die es vorher nicht konnten, konnten es hinterher genau so wenig. Das was ich kann habe ich mir alles selber beigebogen. Entweder durch Probieren oder Tutorials, oder Fragen, manchmal mit einem damaligen Kumpel zusammen (der fand Assembler auch cool). Ich hab niemanden, mit dem man ein wenig "rumhängen kann", der mir mal mit Spaß die Grundlagen von C/C++ nahebringt. Was mich an C/C++ auch gewaltig nervt: Wenn man mit Compiler A einen Quelltext schreibt, heißt das noch lange nicht, daß der von Compiler B genau so angenommen wird. Natürlich gibt es die Probleme bei Assembler auch, aber bei C gibt es eine so unüberschaubare Vielfalt an Compilern und Werkzeugen, daß es völlig unmöglich ist, am Anfang jedes Paket herauszufinden, mit dem man "irgendwann" am besten klarkommt oder was für den Aufgabenbereich am besten geeignet ist. Es gibt eine hohe Wahrscheinlichkeit dafür, daß man sich für das völlig falsche Paket entscheidet. >> Wie schnell soll denn der Bildinhalt geändert werden? Sollen >> aktuelle Werte schnell aufgefrischt werden oder bleibt das >> Bild minutenlang unverändert? > Dazu hattest Du noch nichts geschrieben. Nicht schnell, klar ändern sich ein paar Werte, aber wenn ich die einmal pro Sekunde update, ist das völlig ausreichend. Wie schon oben angemerkt, ich "bräuchte" die 7 Zoll wohl nur wegen der Größe, nicht wegen den Funktionen oder VGA-ähnlichen Darstellungen. Eine Auflösung von 160x100 Pixeln ist vermutlich schon genug, 200x120 völlig genug wenn es was in dieser Größenordnung gibt. Farbe wird nicht benötigt. Selbst wenn ich da mit einem ARM los baue, brauche ich immer noch keine Farbe usw. Um sowas würde ich mir erst Gedanken machen, wenn genug Resourcen vorhanden sind, um ein paar Farben quasi kostenlos einbauen zu können. Aber nötig ist es nicht und mit einem AVR strebe ich auch keine Farbdarstellung an.
Ben B. schrieb: > Wie schon oben angemerkt, ich "bräuchte" die 7 Zoll wohl nur wegen der > Größe, nicht wegen den Funktionen oder VGA-ähnlichen Darstellungen. Wie oben schon angemerkt, reicht auch ein QVGA 5,7" aus. Gut ablesbar (schwarze Schrift auf weißem Hintergrund) und preiswert sind letztlich nur TFTs. Passive DSTN o.ä. kannste voll vergessen! Ben B. schrieb: > Nicht schnell, klar ändern sich ein paar Werte, aber wenn ich die einmal > pro Sekunde update, ist das völlig ausreichend. Dafür braucht man schon entweder einen "intelligenten" Display-Controller (FT8xx bzw. "eve" wurde wiederholt genannt) oder einen µC mit hinreichend RAM und passender Schnittstelle. Ansonsten wird ggf. das Löschen des Bildschirms schon eine Sekunde brauchen. Wenn keine Farbe gebraucht wird, reicht es, alle Datenleitungen des Displays parallel zu schalten und die Datenbits per Schieberegister auszugeben. Dazu noch den Takt (ca. 6 MHz bei QVGA), Vsync und Hsync. Das Timing dazu ist unkritisch und 10 KB Bildspeicher reichen aus. Eine Lösung ist im Prinzip einfach. Aber wenn Du ein Einzelstück suchst und nicht selber entwickeln willst, bleibt Dir nur übrig, irgendein fertiges 7" Display zu beschaffen und anzusteuern, oder Deine Ansprüche zu reduzieren und ein Entwicklungsboard mit 4,3" bzw. 5" TFT für Deine Bedürfnisse zu programmieren. Was Du willst und was Du kannst, mußt Du entscheiden/beurteilen.
Ben B. schrieb: > Also mit Turbo Pascal konnte ich nach der Schule nie wieder was > anfangen. Ich muß auch sagen, ich weiß nicht was ich da groß gelernt > habe. Das ist aber dein Problem, gelle? Und was soll dann aus dir werden, wenn du genauso "gut" C lernst wie Pascal? W.S.
Du hast den Kern der Aussage nicht verstanden. Der ganzen Aussage. Ich hätte viel lieber Grundlagen in C gelernt als Grundlagen in Turbo Pascal, weil mit denen könnte ich jetzt was anfangen. Bevor ich einen Controller in Turbo Pascal programmiere, bringe ich einer Kuh das Tauchen bei. Die armen Controller, kein Wunder wenn die manchmal ihren Deckel aufknallen und raus wollen!
Mein Gott, nimm einfach ein https://nextion.itead.cc/ ... rede mit irgendwas seriel rein und es wird bunt ;) Schnell, einfach, billig, geht ... fertig
Schick - was kostet sowas? Ist doch sicherlich unbezahlbar... Eigentlich will ich es doch gar nicht bunt. schnüff Mir reicht schwarz/weiß oder schwarz/grün, irgendwas möglichst großes im Bereich von 200x200 Bildpunkten wenn es sowas gibt. Mit eigenem Display-Controller und RAM, so daß man sich um den Refresh nicht zu kümmern braucht, 8-Bit-Parellelschnittstelle oder RS232/I2C/SPI... keine weiteren störenden Extras.
Hallo Ben! Suche mal bei Ebay nach den Controller T6963C. Damit ausgestattete SW-Displays lassen sich mit einen 8-bitter noch einfach ansteuern. Gruß Peter
Peter H. schrieb: > Suche mal bei Ebay nach den Controller T6963C. > Damit ausgestattete SW-Displays lassen sich mit einen 8-bitter Sie sind nur selten so groß, wie Ben das gerne hätte. Displays mit begehbaren Pixeln sind halt selten.
@TO Ich habe noch einmal in meinen Beständen gekramt. Falls Du keine Lösung finden solltest, könnte ich Dir ein gebrauchtes Display 5,7" 320x240 und ein passendes Controllerboard (Musteraufbau mit STM32F407) anbieten. Die Ansteuerung erfolgt über RS232. Funktionen sind zum einen Terminalmodus (Text in festen Zeilen/Spalten mit ein paar Steuerzeichen) und zum anderen Grafikmodus mit frei positionierbarem Text (Zoomstufen x1 bis x5), Pixel, Linie, Rechteck (leer und gefüllt). Für Vorder- und Hintergund sind 64 Farben wählbar (mit Attributen blinkend + transparent). Die Touch-Funktion wird nicht unterstützt. Für ATmega habe ich ein paar Treiberroutinen (neudeutsch LIB) in C. Kosten 25 Euro + Versand. Bevor es hier bei mir verstaubt, wäre es noch eine sinnvolle Verwertung. Einen zusammenkopiertes Programmbeispiel ist im Anhang. Da mußt Du abschätzen, ob Du mit der Programmierung klarkommst.
Angehängte Dateien:
-
JD500389__1024_x_768_.jpg
150 KB
A. K. schrieb: > Gab es auch mal hier im Forum von Benedikt. Und ich habe seit 10 Jahren noch restliche Platinen von der Sache liegen, bevor Benedikt spurlos verschwand. Basiert auf dem Amega 32PU und klappte prima. Habe das Display noch aber finde den Beitrag nicht mehr wo die Platinenbestückung beschrieben war usw.
Das sind die einzigen Displays, die für 8 Bit überhaupt machbar sind. Ich benutze hier aber den STM32 für flüssige Darstellung mit 12 Mbit/s SPI. Damit lassen sich auch Filme gucken von sd Karte Alle größeren Displays brauchen ein fremdes RAM mit Bus Anbindung oer sogar Grafik Controller. 320x240 ist einfach die Grenze. Fertige Grafik Lib habe ich für STM32. https://www.ebay.de/itm/2-8-TFT-LCD-Display-Touch-Panel-SPI-Serial-240-320-ILI9341-5V-3-3V-STM32/382397394621?hash=item5908a92ebd:g:qBcAAOSwyNBamKgo:rk:3:pf:0
Da ist die gesuchte Lösung... War die Ansteuerung dieser Displays bisher nur mit erheblichem, eigenen Hard- und Softwareaufwand verbunden, so sind diese intelligenten Displays durch das integrierte Microcontrollersystem samt Touchpanel sofort betriebsbereit. https://www.reichelt.de/tft-grafikdisplay-10-9cm-480x272-mit-intelligenz-ea-edip-tft43atp-p86676.html
Die Nextion Displays wurden doch auch schon genannt, und die sind günstiger als das von Reichelt: https://www.banggood.com/de/Nextion-NX8048K070_011C-7_0-Inch-Enhanced-HMI-Intelligent-Smart-USART-UART-Serial-TFT-LCD-Module-p-1338659.html
Christian J. schrieb: > so sind diese intelligenten > Displays durch das integrierte Microcontrollersystem samt Touchpanel > sofort betriebsbereit. Nana, überlege mal, was man für 242,60€ sonst so kriegt. Sowas nur einzukaufen, um es als Anzeige für nen AVR zu benutzen? Ich halte das für ziemlich ungewöhnlich - sozusagen. Rufus Τ. F. schrieb: > Displays mit begehbaren Pixeln sind halt selten. O HA! Danke! Das war - meine ich - der beste Beitrag im ganzen Thread. Vielleicht sollte der TO mal erläutern, was für ein tatsächliches Vorhaben hinter der ganzen Anfrage steht. Das würde die Problemklärung erleichtern. W.S.
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.