RGB666 Bildschirm mit dem FT232H-Chip betreiben möglich?

[Manuel N. (manuelambaum)]

Hi,

Habe letztens den FT232H-Chip bei Adafruit gesehen. Dieser hat ja 20 
GPIO's, welche ja alle mittels USB-Protokoll ansteuerbar sind. Ist es 
möglich, an diesem Chip ein RGB666 oder RGB565 Bildschirm zu betrieben? 
Man braucht ja die einzelnen RGB's dafür, Pixelclock, VSYNC und HSYNC. 
Der FT232H-Chip stellt ja auch SPI zur verfügung. Müsste ja dann 
eigentlich von den geschwindigkeit und so gehen.

Mir ist natürlich klar, dass das so nicht gedacht ist. Trotzdem wollte 
ich mich einmal erkundigen. Und ich nehme an, dass das niemand bisher 
versucht hat?

Ist mehr aus Interesse, da ich gerne solche Experimente wage

Danke im Vorraus

[FPGA Notfallseelsorge (Gast)]

USB macht leider manchmal lange Pausen. Aber wenn das egal ist dann 
könnte das schon funktionieren.

[c-hater (Gast)]

Manuel N. schrieb:

> Habe letztens den FT232H-Chip bei Adafruit gesehen. Dieser hat ja 20
> GPIO's, welche ja alle mittels USB-Protokoll ansteuerbar sind. Ist es
> möglich, an diesem Chip ein RGB666 oder RGB565 Bildschirm zu betrieben?
> Man braucht ja die einzelnen RGB's dafür, Pixelclock, VSYNC und HSYNC.

Da fehlt noch ein Signal. Hat leider von Hersteller zu Hersteller immer 
verschiedene Namen, aber fast immer kommt in diesem Namen oder zumindest 
der Signalbeschreibung irgendwas mit "ENA" oder "ENABLE" vor. Dieses 
Signal ist ganz wesentlich für die Ansteuerung solcher LCDs!
Wohingegen HSYNC und VSYNC eigentlich verzichtbar wären und deshalb 
zumindest bei einigen Displays auch tatsächlich nicht als äußere 
Anschlüsse existieren (aber immer noch als interne Signale, die bei 
diesen Displays dann halt aus diesem "ENABLE"-Signal abgeleitet werden)

> Der FT232H-Chip stellt ja auch SPI zur verfügung. Müsste ja dann
> eigentlich von den geschwindigkeit und so gehen.

Das dürfte schon von der reinen Geschwindigkeit arg knapp werden. Hängt 
aber natürlich auch stark von der Größe bzw. eigentlich der Auflösung 
des Displays ab. Denn die bestimmt letztlich den nötigen Pixeltakt. 
800x480 z.B. hat typisch um die 33MHz Pixeltakt. Größere Displays mit 
Parallel-Interface gibt's selten, da es dann schon recht kritisch wird, 
alle Signale in der richtigen Phasenlage und in brauchbarer Form zum 
Display zu führen.
Kleinere Displays benötigen aber natürlich weniger Pixeltakt.

> Ist mehr aus Interesse, da ich gerne solche Experimente wage

Dann würde ich an deiner Stelle statt auf FT232H auf RaspiPico setzen. 
Ist nicht teurer und vor allem auch derzeit tatsächlich lieferbar...

Der kann dank der "PIO"-Koprozessoren recht problemlos das korrekte 
Timing für solche Displays generieren. Und dank des für µC untypisch 
größen Speichers kann er für kleinere Displays sogar einen echten 
Framebuffer bereitstellen. Für ein Display der 18MHz-Klasse (z.B. 
960x160 oder 480x320) einen 12bpp-Framebuffer.

Damit wird dann der USB-Datenpfad vom Timing her völlig unkritisch.

> Und ich nehme an, dass das niemand bisher versucht hat?

Das mit dem Pico habe ich nicht nur versucht, sondern erfolgreich 
umgesetzt. Siehe Anhang, das ist ein 960x160 Sharp LQ092B5DW01, 
angesteuert von einem RaspiPico mit 12bpp-Framebuffer, also RGB444. 
Dieser komische Welleneffekt ist übrigens natürlich im Original nicht 
vorhanden, sondern ein Artefakt des Fotos, der schon im Originalfoto 
andeutungsweise erkennbar war, aber erst durch die Qualitätsreduktion so 
richtig häßlich wurde.

Wie auch immer: das Timing solcher Displays ist generell recht kritisch, 
je höher der Pixeltakt, desto kritischer. Deswegen wage ich 
vorherzusagen, dass es mit den GPIOs eines FT232H niemals funktionieren 
wird...