Hallo zusammen, ich möchte über einen Mikrocontroller mit entsprechendem Display-Controller (vermutlich läuft es auf einen STM32F7 hinaus) gleichzeitig mehrere LCD-Displays ansteuern (bis zu 10 Stück, Typ: EDT ET020009DMU). Diese verfügen über einen 24 Bit breiten RGB-Datenbus und einen VSYNC-, HSYNC- und Clock-Eingang. Nun möchte ich der Reihe nach Frame für Frame an die entsprechenden Displays übertragen. Die Bus-Spannung liegt bei 3,3V und die Pixel-Clock bei 45 MHz. Nun schweben mir hier folgende Lösungsansätze vor: 1) Jedem Display einen Bus-Treiber (oder ggf. mehrere um die ensprechende Bit-Breite zu erreichen) spendieren und diese nacheinander durchschalten. Je nach Eingangsimpedanz der Treiber ggf. noch einen weiteren Treiber zwischen LCD-Interface des Mikrocontrollers und den zehn Treibern. Diese Variante präferiere ich momentan. 2) Einen oder mehrere FPGAs mit der entsprechenden Anzahl an IOs hierfür vorsehen und diese als 27-Bit breiten 1:10 Multiplexer einsetzen. Dagegen spricht, dass dieser auch extra programmiert werden muss (insgesamt geht es nur um knapp 100 Platinen, so dass sich dies vermutlich nicht rechnet), dafür sprechen der geringere Platzbedarf auf dem PCB und die Möglichkeit, problemlos eine sternförmigen Leiterbahnführung auf dem PCB umzusetzen. Hat jemand schon einmal ähnliches realisiert, einen anderen Ansatz oder generelle Tipps zu diesem Vorhaben? Viele Grüße, Marcel
Und nach jedem übertragenen Frame willst du dann den Displays 9 Frames lang keine Clock und keine Daten schicken, und erwartest, dass das Bild noch gut aussieht?
Frage: Sollen die Displays das identische Bild anzeigen oder jedes Display ein eigenen Bild?
Hallo, > Marcel schrieb: > ich möchte über einen Mikrocontroller mit entsprechendem > Display-Controller (vermutlich läuft es auf einen STM32F7 hinaus) > gleichzeitig mehrere LCD-Displays ansteuern (bis zu 10 Stück, Typ: EDT > ET020009DMU). Nu ja, ist ja ein Minidisplay mit gerade mal 176 x 220 Pixel. > Diese verfügen über einen 24 Bit breiten RGB-Datenbus und > einen VSYNC-, HSYNC- und Clock-Eingang. Wobei man nicht alle 24 Bit benutzen muß. Ich meine, da reichen auch 5...6 Bit pro Farbe (bzw. 16Bit-Modus) und man kann statt mit 3 Bytes mit nur 2 Bytes pro Pixel auskommen. Das macht beim Bildinhalt statt 176 x 220 x 3 Bytes = 116160 Bytes nur noch 77,44 kByte. > Nun möchte ich der Reihe nach Frame für Frame an die entsprechenden > Displays übertragen. Wie schnell den? Wieviele Frames pro s sind nötig? > 1) Jedem Display einen Bus-Treiber (oder ggf. mehrere um die > ensprechende Bit-Breite zu erreichen) spendieren und diese nacheinander > durchschalten. Je nach Eingangsimpedanz der Treiber ggf. noch einen > weiteren Treiber zwischen LCD-Interface des Mikrocontrollers und den > zehn Treibern. > Diese Variante präferiere ich momentan. Wozu den solche Umständlichkeiten? Ich meine, es macht eher Sinn, jedem Display einen eigenen Controller zu geben und die Frames über einen Daten-BUS an alle Slave-Controller zu übertragen. Ja nach Abstand kann das z.B. per UART über TTL gehen oder per SPI oder für größere Abstände (bis hunderte Meter) bei den Datenmengen auch locker per RS485. > Hat jemand schon einmal ähnliches realisiert, einen anderen Ansatz oder > generelle Tipps zu diesem Vorhaben? Ich habe in letzten Monaten ein Display 3,7Zoll mit 320x240 für industriellen Einsatz entwickelt. Da nehme ich einen Cortex M3 LPC176x oder so (allerdings mi5t 208 Pins, wegen der LCD-steuerleitungen). Bei dem brauche ich einen externen RAM aber bei deinem kleinen Display sollte der interne RAM schon reichen. Als Interface dient zur Datenübertragung RS485. Die Inhalte auf dem Display werden allerdings nicht als Frame übertragen, sondern mit vordefinierte Grafikelemente dargestellt. Für die LPC gibt es schon fertige Softwarebibliotheken für diverse Grundfunktionen, so dass nur eine darstellung von fertigen Frames wohl sehr schnell programmiert ist. Gruß Öletronika
Hallo zusammen, vielen Dank für die Beiträge! Joe F. schrieb: > Und nach jedem übertragenen Frame willst du dann den Displays 9 Frames > lang keine Clock und keine Daten schicken, und erwartest, dass das Bild > noch gut aussieht? Der Einwand ist natürlich vollkommen berechtigt. So wird dies natürlich nichts. Ich war in Gedanken beim Verfassen des Beitrags noch bei einem anderen Display mit einem anderen Controller. Da bei dem genannten Display ein HX8340-B zum Einsatz kommt und dieser bei Verwendung des RGB-Interfaces den internen GRAM übergeht, müsste hier natürlich die Ansteuerung über den 18-Bit breiten, parallelen Bus erfolgen. Die oben geschilderte Problemstellung bleibt in diesem Fall allerdings noch die selbe (abgesehen von der abweichenden Bus-Breite). Peter schrieb: > Frage: > Sollen die Displays das identische Bild anzeigen oder jedes Display ein > eigenen Bild? Die Displays sollen verschiedene Bildeinformationen anzeigen. U. M. schrieb: > Wie schnell den? Wieviele Frames pro s sind nötig? Auf den Displays werden u.a. auch Animationen angezeigt. Daher ist eine Framerate von mindestens 25 Bildern pro Sekunde notwendig. U. M. schrieb: > Wobei man nicht alle 24 Bit benutzen muß. Ich meine, da reichen auch > 5...6 Bit pro Farbe (bzw. 16Bit-Modus) und man kann statt mit 3 Bytes > mit nur 2 Bytes pro Pixel auskommen. Das macht beim Bildinhalt statt > 176 x 220 x 3 Bytes = 116160 Bytes nur noch 77,44 kByte. Leider ist für die Darstellung der auszugebenden Bildinhalte eine Farbiefe von mindestens 6 Bit pro Farbe notwendig, daher lässt sich hier leider nicht viel an Bandbreite einsparen. Ansonsten wäre auch die Ansteuerung der Displays mittels SPI ein gangbarer Weg gewesen. U. M. schrieb: > Wozu den solche Umständlichkeiten? > Ich meine, es macht eher Sinn, jedem Display einen eigenen Controller zu > geben und die Frames über einen Daten-BUS an alle Slave-Controller zu > übertragen. Dies wäre natürlich der naheliegendste Ansatz. Allerdings wollte ich dies gerne vermeiden, da in dem Gerät letztendlich 20 dieser Displays verbaut werden, so dass dies doch ein wesentlicher Kostenpunkt wäre. U. M. schrieb: > Ja nach Abstand kann das z.B. per UART über TTL gehen oder per SPI oder > für größere Abstände (bis hunderte Meter) bei den Datenmengen auch > locker per RS485. In meinem Fall sind die Displays direkt nebeneinander in einer Reihe angeordnet, so dass dies in keinem Fall ein Problem darstellen sollte. U. M. schrieb: > Die Inhalte auf dem Display werden allerdings nicht als Frame > übertragen, sondern mit vordefinierte Grafikelemente dargestellt. > > Für die LPC gibt es schon fertige Softwarebibliotheken für diverse > Grundfunktionen, so dass nur eine darstellung von fertigen Frames wohl > sehr schnell programmiert ist. Dies ist im geplanten Anwendungsfall nicht einmal notwendig. Die Bilddaten für jedes einzelne Frame werden bereits fertig per USB an den Controller übertragen. Viele Grüße, Marcel
@Marcel (Gast) >Display-Controller (vermutlich läuft es auf einen STM32F7 hinaus) >gleichzeitig mehrere LCD-Displays ansteuern (bis zu 10 Stück, Typ: EDT >ET020009DMU). Also eine Art Videowand. >1) Jedem Display einen Bus-Treiber (oder ggf. mehrere um die >ensprechende Bit-Breite zu erreichen) spendieren und diese nacheinander >durchschalten. Das willst du nicht wirklich, denn dann teilen sich alle Displays die Busbandbreite. Und da man die LCDs sicher NICHT mit Faktor 10 übertakten kann, heißt das, daß sie nur 1/10 ihre Framerate erreichen. >Diese Variante präferiere ich momentan. Ich nicht ;-) >2) Einen oder mehrere FPGAs mit der entsprechenden Anzahl an IOs hierfür >vorsehen und diese als 27-Bit breiten 1:10 Multiplexer einsetzen. Kann man machen, braucht aber satte 270 Pins ;-) >Dagegen spricht, dass dieser auch extra programmiert werden muss >(insgesamt geht es nur um knapp 100 Platinen, so dass sich dies >vermutlich nicht rechnet), Denkst du, die Sache wird billig? Dream on. > dafür sprechen der geringere Platzbedarf auf >dem PCB und die Möglichkeit, problemlos eine sternförmigen >Leiterbahnführung auf dem PCB umzusetzen. Das ist das kleinste Problem. >Die Displays sollen verschiedene Bildeinformationen anzeigen. >Auf den Displays werden u.a. auch Animationen angezeigt. Daher ist eine >Framerate von mindestens 25 Bildern pro Sekunde notwendig. Also brauchst du eine Datenquelle mit 10x25x176x220x3~ 29MB/s Die muss dann auf 10 LCDs mit je 2,9 MB/s verteilt werden. Hmmm. >leider nicht viel an Bandbreite einsparen. Ansonsten wäre auch die >Ansteuerung der Displays mittels SPI ein gangbarer Weg gewesen. Vielleicht. 2,9 MB/s sind ~24 MHz Bittakt, das ist noch OK. >> Ich meine, es macht eher Sinn, jedem Display einen eigenen Controller zu >> geben und die Frames über einen Daten-BUS an alle Slave-Controller zu >> übertragen. >Dies wäre natürlich der naheliegendste Ansatz. Allerdings wollte ich >dies gerne vermeiden, da in dem Gerät letztendlich 20 dieser Displays >verbaut werden, so dass dies doch ein wesentlicher Kostenpunkt wäre. Es wird so oder so nicht billig. Schon gar nicht als Prototyp! >> Ja nach Abstand kann das z.B. per UART über TTL gehen oder per SPI oder >> für größere Abstände (bis hunderte Meter) bei den Datenmengen auch >> locker per RS485. UART mit TTL darfst du getrost vergessen. Selbst für EIN LCD ist das viel zu langsam! >Dies ist im geplanten Anwendungsfall nicht einmal notwendig. Die >Bilddaten für jedes einzelne Frame werden bereits fertig per USB an den >Controller übertragen. Dann kocht der USB aber ganz schön, denn selbst High Speed USB hat bei ~30MB/s ordentlich zu tun. Die Sache mit SPI könnte man vertiefen, das Ganze kann ein mittleres FPGA aufteilen. Aber halt nicht mit 270 Pins sondern eher mit 10x3 für SPI + zwei Dutzend für die USB-IC Anbindung. Beim Verteilen der Signale sollte man an das Thema Wellenwiderstand denken. Man könnte das mit einem FPGA-Evalboard + Adapter aufbauen. Billiger wird es kaum.
Hallo Falk, vielen Dank für deine Anregungen und Einwände. Falk B. schrieb: > Also eine Art Videowand. Bei der Anwendung liegen unter jedem Display mehrere Bedienelemente. Auf den Displays werden die eingestellten Parameter visualisiert. Falk B. schrieb: > Das willst du nicht wirklich, denn dann teilen sich alle Displays die > Busbandbreite. Und da man die LCDs sicher NICHT mit Faktor 10 übertakten > kann, heißt das, daß sie nur 1/10 ihre Framerate erreichen. Wenn ich das Datenblatt des Himax HX8340-B richtig lese und nichts übersehen habe, liegt die minimale Zeit für einen Write-Cycle für das parallele Interface bei 66ns. Damit sollten sich die Anforderungen bei 18 Bit breitem Bus im RGB666-Modus problemlos erfüllen lassen. Falk B. schrieb: > Die Sache mit SPI könnte man vertiefen, das Ganze kann ein mittleres > FPGA aufteilen. Aber halt nicht mit 270 Pins sondern eher mit 10x3 für > SPI + zwei Dutzend für die USB-IC Anbindung. Die Ansteuerung per SPI habe ich in der Tat wohl etwas zu schnell verworfen. Das könnte durchaus auch ein gangbarer Weg sein. Möglicherweise könnte man dann statt eines FPGAs hier sogar noch mit einem oder zwei Mikrocontrollern hinkommen; eine entsprechende Anzahl an SPI-Interfaces und DMA-Kanälen vorausgesetzt. Viele Grüße, Marcel
@ Marcel (Gast) >> Das willst du nicht wirklich, denn dann teilen sich alle Displays die >> Busbandbreite. Und da man die LCDs sicher NICHT mit Faktor 10 übertakten >> kann, heißt das, daß sie nur 1/10 ihre Framerate erreichen. >Wenn ich das Datenblatt des Himax HX8340-B richtig lese und nichts >übersehen habe, liegt die minimale Zeit für einen Write-Cycle für das >parallele Interface bei 66ns. Damit sollten sich die Anforderungen bei >18 Bit breitem Bus im RGB666-Modus problemlos erfüllen lassen. Hmm, 66ns sind ~16MHz. Da man bei 176x220 Pixel x 25 Hz nur ~1 MHz braucht, könnte das klappen. >Möglicherweise könnte man dann statt eines FPGAs hier sogar noch mit >einem oder zwei Mikrocontrollern hinkommen; eine entsprechende Anzahl an >SPI-Interfaces und DMA-Kanälen vorausgesetzt. Vielleicht.
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.