mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welches 7 Zoll Grafikdisplay ist gut?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist "Gut"?

> bastelfreundliche Schnittstelle (kein LVDS oder so)

Woran willst Du das Display anschließen?

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich wirds ein AVR, so lange sich der Wechsel zum ARM Cortex 
oder welche ARM-Variante auch immer vermeiden lässt.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ä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.

Autor: Thomas F. (igel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernhard K. (bkom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Bessa Wissa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

Ebay-Artikel Nr. 271513577223

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: CPU Historiker (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Walter L. (charly2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm dieses
Ebay-Artikel Nr. 272383539604
Gibt es auch mit SPI.
VG Walter

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Jenn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmieren lernt man sicherlich nicht in der Schule. Wenn das schon 
die Einstellung/Erwartungshaltung ist, kannst du es knicken.

Autor: Flo_85 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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!

Autor: Ray M. (ray_m)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mein Gott, nimm einfach ein https://nextion.itead.cc/ ...
rede mit irgendwas seriel rein und es wird bunt ;)
Schnell, einfach, billig, geht ... fertig

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Peter H. (peterhofbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christian J. (Firma: privat) (christianj)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Christian J. (Firma: privat) (christianj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Ebay-Artikel Nr. 382397394621

: Bearbeitet durch User
Autor: Christian J. (Firma: privat) (christianj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: W.S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.