Geeigneter µC für großes LED-Matrix-Projekt

[Jonathan (jonathan_v)]

Moin aus Bremen!

Ich hatte vor ein paar Wochen die Gelegenheit, aus unserem Hauptbahnhof 
die alten Fahrgastinformationsanzeigen des ÖPNV hier in Bremen zu 
ergattern. Dabei handelt es sich um vier zwei Meter lange, und 60cm hohe 
monochrome LED-Matrizen, mit einer Auflösung von 320x96 = 30.720 LEDs. 
Ich sammel so ein Zeug und versuche gerne, so etwas wieder zum Leben zu 
erwecken.

Eins dieser Panele besteht aus 30 "Modulen" mit je 64x16 LEDs, und zwei 
"Treiber"-Boards (so nenne ich sie mal), die jeweils zwei dieser 
"Treiber" (also in total 4 "Treiber") enthalten. Jeder Treiber ist für 
32x8 LEDs verantwortlich, enthält 8 High-Current-Transistoren (einer pro 
Zeile) und 4 Shift Register gepaart mit 5 Darlington-Arrays. Im Anhang 
findet ihr Fotos.

Ich habe einen dieser Treiber bereits reverse-engineered und eine 
minimalistische Ansteuerung mit einem Arduino (später ESP32) realisiert, 
der pro Display Refresh jede Zeile auswählt, und dann in die Shift 
Register die jeweiligen Spaltendaten reinschiebt. Soweit so gut.

Nun überlege ich, wie ich eine Ansteuerung für das ganze Panel 
realisieren könnte. Das Panel hat insgesamt fünf "Zeilenbusse", die 
allerdings jedes Modul verbinden, also könnten vermutlich auch diese 
fünf Zeilenbusse gleich gesteuert werden. Die Spaltenbusse hingegen 
müssten, zumindest von den Daten her seperat angesteuert werden. Die 
STROBE, OUTPUT_ENABLE und CLOCK-Pins der Shift Register-Ketten könnte 
man eventuell auch parallel schalten, sofern man dann alle 12 Datenpins 
gleichzeitig bedient.

Um das Ganze zusammenzufassen, es werden:
 - 8 pins für die Zeilen (jede n'te (1.-8.) Zeile ist immer gleichzeitig 
ausgewählt)
 - 12 pins für Spaltendaten
 - 3 pins für geteiltes STROBE, OUTPUT_ENABLE und CLOCK der Shift 
Register
benötigt.

Das macht insgesamt 23 Pins, dann ist der ESP32 mit seinen GPIO-Pins 
auch voll. Ich habe allerdings auch noch die Anforderung, dass ich gerne 
Ethernet on-board hätte, denn das Display soll später auf 
ArtNet/e1.31-Befehle reagieren können (damit ich es ähnlich zu 
tatsächlichem Bühnenequipment ansteuern kann). Da ArtNet ein 
UDP-Protokoll ist, und ich in meinem Test mit dem ESP32 über WiFi doch 
einen höheren Packet Loss feststellen konnte, hätte ich gerne Ethernet, 
und ein externes Ethernet-Interface über SPI/I²C kriege ich am ESP nicht 
mit unter.

Es gibt also jetzt zwei Möglichkeiten: entweder entwirft man eine Art 
Master/Slave-Konzept, in dem ein Haupt-MCU (mit Ethernet) die Daten 
annimmt und an mehrere Subcontroller verteilt, oder man nehme eine 
größeren Controller mit mehr GPIO-Pins. Da sind mir allerdings wenige 
bekannt, und auf einen Raspberry Pi/Beaglebone wollte ich aufgrund der 
doch eher langsam ausfallenden GPIO-Pins (es sei denn man kann diese 
irgendwie low-level ansteuern, ich fand nur den Device Tree Layer) 
verzichten.

Bei meiner Suche fand ich ebenfalls die STM32-basierten Nucleo-Boards, 
davon gibt's auch welche mit Ethernet - könnte das eventuell etwas sein? 
Oder bin ich komplett auf dem Holzpfad?

Ich freue mich auf eine Diskussion, für mich ist das alles mehr oder 
weniger noch Neuland, aber nach dem ich ein kleines Modul bereits 
angesteuert bekommen habe, habe ich nun Blut geleckt, und lasse mich 
gerne belehren :)

Beste Grüße,
Jonathan

PS: ich habe noch einen leienhaften Schaltplan, den ich mit meinem 
(wahrscheinlich unzureichenden) Wissen und einem Durchgangsprüfer 
erstellt habe: 
https://drive.google.com/file/d/1XQVmanVMPL2G8Dl2rx9IEmbrfSX4t7KR/view

[Michael B. (laberkopp)]

Jonathan schrieb:
> Um das Ganze zusammenzufassen, es werden:
>  - 8 pins für die Zeilen (jede n'te (1.-8.) Zeile ist immer gleichzeitig
> ausgewählt)
>  - 12 pins für Spaltendaten
>  - 3 pins für geteiltes STROBE, OUTPUT_ENABLE und CLOCK der Shift
> Register
> benötigt.

Standard ist https://hackaday.com/tag/hub75/

Mehr als ein 1:8 Multiplex würde ich nicht multiplexen, also 3840 LED 
pro Schieberegister oder mehrere Schieberegistern.

Du brauchst auch 3.8kByte Hauptspeicher um die Daten vorzuhalten.

Und genügend Strom.

[Steve van de Grens (roehrmond)]

Jonathan schrieb:
> Bei meiner Suche fand ich ebenfalls die STM32-basierten Nucleo-Boards,
> davon gibt's auch welche mit Ethernet - könnte das eventuell etwas sein?

Klar, why not?

[Harry L. (mysth)]

Michael B. schrieb:
> Mehr als ein 1:8 Multiplex würde ich nicht multiplexen, also 3840 LED
> pro Schieberegister oder mehrere Schieberegistern.

Zumindest bei den HUB75 Displays würde ich eher zu einem Modell mit 1:16 
oder sogar 1:32 raten, wenn es nicht für den Aussenbereich sein soll.

Warum?

Weil die 1:8-Displays extrem hell sind - die sind w.g. eher was für 
den Aussenbereich.
Aber, ich denke, der TO kann sich das in diesem Fall sowieso nicht 
aussuchen, und muss nehmen, was er hat.

Mit BitAngel-Modulation kann man auch "Graustufen" realisieren.

Ich hab das mal mit so einem HUB75-Display mit 64x64 Pixel RGB auf einem 
STM32F4xx über die FSMC-Schnittstelle realisiert.
Damit liessen sich ca. 170 Frames/s darstellen.

@Jonathan: wenn du an dem Code interessiert bist, schreib mir eine PN.