Forum: Mikrocontroller und Digitale Elektronik Displaycontroller mit einstellbarer Auflösung/Farbtiefe?


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.
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vom freundlichen Asiaten gibt es ja billige "halbintelligente" (=eigener 
Controller und Speicher mit seriellen oder paralleler Ansteuerung auf 
Pixelebene, aber keine höheren Grafikfunktionen) Displays in vielen 
verschiedenen Größen und Auflösungen, die prinzipiell auch sehr gut mit 
kleinen/langsamen Microcontrollern nutzbar sind.

Dabei stellt sich mir oft die Frage: Ich bräuchte nur 16 Farben und 
verdopple die Pixel damit die Schrift des kleinen Fonts auf dem 2" 
Display noch lesbar ist... warum muss ich dann 16 oder 24 Bit RGB und 
volle Auflösung über die Schnittstelle schicken, wo mir doch 4 Bit und 
halbe Auflösung reichen würden und dann viel flotter wären!

Gängige Controlle wie ILI9341 oder ILI9488 scheinen leider keine 
"Grafikmodi" außer dem nativen des Displays zu unterstützen. Kennt ihr 
irgendwelche in billigen kleinen Displays verbaute Controller (die 
"intelligenten"-Displays der 50+€-Klasse mal außen vor) bei denen man 
(zu übertragende) Farbtiefe und Auflösung (ähnlich einer Grafikkarte) je 
nach Bedarf einstellen kann?

danke,
  Andy

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Andy schrieb:
> wo mir doch 4 Bit und
> halbe Auflösung reichen würden und dann viel flotter wären!

Mit welchem µC willst Du das Display ansteuern?
Mit einem AVR bleibt es fraglich, ob kürzere Ausgaben die 
Geschwindigkeit erhöhen. Mit SPI geht die Ausgabe recht schnell im 
Hintergrund, sodaß die Ausgabe eher dadurch gebremst wird, daß der µC 
die neuen Pixeladressen errechnen muß.

16 Farben fallen etwas aus dem Rahmen. Bei 8 Farben/Pixel werden pro 
Farbe entweder 0 oder 0xff ausgegeben. Bei voller SPI-Taktrate dauert 
die Ausgabe eines Pixels ohne Adressberechnung < 2 µs, was nicht 
schlecht ist.
Wenn allerdings eine schräge Linie oder Buchstaben gezeichnet werden 
müssen, geht die Ausgabe durch die Berechnung der Pixeladressen stark in 
die Knie. Die Farben sind hierbei nicht die Bremse!

Wenn es richtig schnell gehen soll, läßt man den µC das Display direkt 
ansteuern, wobei der Bildspeicher im internen RAM liegt. Ein Beispiel 
findest Du hier: Beitrag "4,3" TFT-Controller STM32F730"

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Gängige Controlle wie ILI9341 oder ILI9488 scheinen leider keine
> "Grafikmodi" außer dem nativen des Displays zu unterstützen.

Ja, wozu auch.
Such mal nach "Peripheral Controller".
Als mittlerweile zwar obsolete Typen z.B. Renesas HD64461/HD64463.
Die haben nebenbei sogar einen 2D-Beschleuniger dabei.

von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Mit welchem µC willst Du das Display ansteuern?
> Mit einem AVR bleibt es fraglich, ob kürzere Ausgaben die
> Geschwindigkeit erhöhen. Mit SPI geht die Ausgabe recht schnell im
> Hintergrund, sodaß die Ausgabe eher dadurch gebremst wird, daß der µC
> die neuen Pixeladressen errechnen muß.

Nunja, der AVR hat ja kein DMA. Hardware-SPI bedeutet nur dass man die 
Bits nicht einzeln anpacken muss... bei 20 Mhz und CLK/2=10 Mhz SPI Takt 
dauert das Senden von "kompletten Schirm füllen" = 320x240x24=1.843.200 
Bit halt 0,18 Sekunden = 5 fps.
Mit halber Auflösung und 16 Farben wären es 160x120x4=76.800 = 0,0078 
Sekunden = 130 fps.
Klar, wenn man jetzt komplexe Grafiken oder Vektor-Fonts berechnen will 
liegen die Zeitfresser woanders.


>Ja, wozu auch.
>Such mal nach "Peripheral Controller".
>Als mittlerweile zwar obsolete Typen z.B. Renesas HD64461/HD64463.
>Die haben nebenbei sogar einen 2D-Beschleuniger dabei.

Die sind aber leider bei bei den fertigen günstigen Bastler-Boards wie 
Arduino Uno, Bluepill oder ESP32 nicht mit drauf... und ein 
STM32f429-Discovery-Board mit Displaycontroller ist vielleicht ein 
bisschen Overkill für die meisten kleinen Projekte.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
Andy schrieb:
> Nunja, der AVR hat ja kein DMA.

Und wenig Speicher. Ein STM32F411 im BluePill Format kostet beim 
Chinesen 4-5 € und hat 512 k Flash, 128 k RAM, SPI mit 50 MBit/s.
Die etwas größeren F407 Boards haben mehr Pins rausgeführt, da geht auch 
16 Bit parallel mit hoher Geschwindigkeit, da muss die Anzeige nicht 
mehr so pixelig wie beim C64 aussehen.

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Andy schrieb:
> Nunja, der AVR hat ja kein DMA. Hardware-SPI bedeutet nur dass man die
> Bits nicht einzeln anpacken muss... bei 20 Mhz und CLK/2=10 Mhz SPI Takt
> dauert das Senden von "kompletten Schirm füllen" = 320x240x24=1.843.200
> Bit halt 0,18 Sekunden = 5 fps.
> Mit halber Auflösung und 16 Farben wären es 160x120x4=76.800 = 0,0078
> Sekunden = 130 fps.
> Klar, wenn man jetzt komplexe Grafiken oder Vektor-Fonts berechnen will
> liegen die Zeitfresser woanders.

Das sind doch Luftrechnungen, zumal bei dem Vergleich noch das 
Displayformat geändert wurde.
Wo kommen denn die Daten her, daß hier "fps" berechnet wird, und welchen 
µC willst Du verwenden?
Was hast Du vor ?

Andy schrieb:
> STM32f429-Discovery-Board mit Displaycontroller ist vielleicht ein
> bisschen Overkill für die meisten kleinen Projekte.

Das mag sein, aber ein STM32F4/F7/H7 bietet die Geschwindigkeit und den 
notwendigen Arbeitsspeicher, die Du gerne hättest. SPI und DMA: kein 
Problem.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy schrieb:
> Gängige Controlle wie ILI9341 oder ILI9488 scheinen leider keine
> "Grafikmodi" außer dem nativen des Displays zu unterstützen.

Und? Genau das ist es doch, was man braucht.

Also wenn du schon beabsichtigst, deinen µC irgendwelche grafischen 
Ausgaben machen zu lassen, dann wähle zuerst eine sinnvolle Kombination 
aus µC, verfügbarem RAM, verfügbarem Display und verfügbarer 
Taktfrequenz, Farbanzahl etc aus. So herum eben.

W.S.

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Haben die Controller nicht die Möglichkeit, die Daten in 
unterschiedlichen Formaten zu übertragen (4/8/15/16/18/24 Bit/Pixel)? 
Ich meine, das in mehreren Datenblättern gesehen zu haben ...

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Die eff. Bit/Pixel sind immer im Bereich 16 - 24. Mit einer "lookup 
table" (LUT oder CLUT für Farbe) kann man die Farbinformation auf ein 
Byte reduzieren. Kleiner wäre es nicht sinnvoll.
Aber irgendwie scheint mir der TO noch nicht zu wissen, was er 
tatsächlich will.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
Doch, der TO weiß was er will. Aber kein Benutzer möchte mehr grobe 4 
Bit Farbdisplays wo es deutlich bessere gibt. Nur weil der Programmierer 
es nicht besser konnte oder die Kaufleute den Rotstift angesetzt haben.

: Bearbeitet durch User
von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Doch, der TO weiß was er will.

Solange er nur eine Kleinigkeit herauspickt und optimieren möchte, 
bekommt er insgesamt keine Steigerung der Geschwindigkeit. Seinen µC 
hält er nach wie vor geheim.

> Aber kein Benutzer möchte mehr grobe 4
> Bit Farbdisplays wo es deutlich bessere gibt

Damit ist es natürlich schwieriger, dunkelblaue Schrift auf schwarzem 
Hintergrund anzuzeigen, auch wenn das für Nichtlesbarkeit optimal ist.

Als Benutzer schätze ich wenige, prägnante Farben, die eindeutig zu 
erkennen und lesbar sind. Selbst monochrome OLED Displays sind besonders 
gut ablesbar.
Bunte Bilderrahmen taugen nur für Fotos, aber dann bitte auch mit IPS 
Display.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
m.n. schrieb:
> Seinen µC
> hält er nach wie vor geheim.

die Frage war allgemein:

Andy schrieb:
> die prinzipiell auch sehr gut mit
> kleinen/langsamen Microcontrollern nutzbar sind.

aber dazu wurde ja jetzt schon oft genug geantwortet das der Controller 
der Anforderung entsprechen sollte. Und Controller mit Megabytes 
Speicher gibt es auch für kleines Geld, man muss sich nur damit 
beschäfftigen.

m.n. schrieb:
> Damit ist es natürlich schwieriger, dunkelblaue Schrift auf schwarzem
> Hintergrund anzuzeigen, auch wenn das für Nichtlesbarkeit optimal ist.

viele Farben sind aber auch gut für Anti Aliasing oder etwas hübschere 
Oberflächen wie lvgl oder touchGFX.

von m.n. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Johannes S. schrieb:
> viele Farben sind aber auch gut für Anti Aliasing oder etwas hübschere
> Oberflächen wie lvgl oder touchGFX.

Dafür eignen sich ja auch "kleine/langsame Mikroprozessoren" besonders 
gut:
einer pro Pixel ;-)

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
m.n. schrieb:
> einer pro Pixel ;-)

Jawoll, sag ich doch auch immer. Siehe Eröffnungspost:

Andy schrieb:
> Displays in vielen
> verschiedenen Größen und Auflösungen, die prinzipiell auch sehr gut mit
> kleinen/langsamen Microcontrollern nutzbar sind.

Eben: prinzipiell eben nur. Das ist das Feld der Fanatiker, die 
krampfhaft versuchen, den allerkleinsten µC mit dem allergrößten Display 
zu verbinden, egal ob anschließend überhaupt noch ein Byte an RAM oder 
Flash und ein Pin für die eigentliche Nutzanwendung übrig bleibt.

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]
  • [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.