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
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"
> 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.
> 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.
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.
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.
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.
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 ...
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.
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.
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.
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.
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 ;-)
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.
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.