Jumbotron 16x32 Pixel RGB-Matrixen flott ansteuern...

    Thread-Auskopplung von hier:
    Glediator - Freeware LED Matrix Steuerung - Software


    Moin Pepe!


    Bin auf YT auf deine Videos gestoßen und da ich grad was ähnliches plane hier ein paar praktische Fragen :)


    Könntet ihr euch vorstellen, das Protokoll für diese Displays auch zu unterstützen?
    http://www.rayslogic.com/prope…afruitRGB/AdafruitRGB.htm
    Die scheinen Standart für echte Jumbotrons zu sein - zumindest bei den Chinesen.
    Laufen dann aber auch über nen Windows-Treiber oder eben dedizierte Hardware als Display mit bis zu 4k Pixel Breite.
    Bevor der 1. Pixel leuchtet, kauft man also erstmal die PCI-Karte (Win-only, € 160,–), einen Empfänger/Treiber (ca. € 40,–) plus nen Hub (€ 7,–).


    Da wir nur 3 oder 4 16x32 Module ankabeln wollen lohnt das natürlich überhaupt nicht, vor allem will das ja auch keine Sau mit dem PC machen.
    Zumindest nicht für unsere finale Installation.


    Die Module selber sind 1/8 Scan und haben ein 6-Bit-Interface plus 3-Bit-Row-Select und noch Latch, Clock, etc.. Nix besonders anspruchsvolles.
    Dementsprechend wollen wir die Xmega DMA nutzen und die PWM selber erzeugen.
    Also zuerst [ Host USB ] —> [ UART ] —> [ DMA ] —> [ SRAM ]
    und dann [ SRAM ] —> [ DMA ] —> [ DISPLAY ]


    Im Prinzip müsste Glediator nur einen zusätzlichen Ausgabe-Modus bekommen, wo die Bits ein wenig vor dem Senden verwürfelt werden, so dass der Xmega sich direkt passende Häppchen für einen Durchgang BAM-Dimmung greifen kann.
    Schaltplan und Code für den Xmega kann ich dann gerne hier reinposten.


    Ein Xmega-Board "mit Alles" habe ich hier, die zwei Displaymodule für erste Tests sind noch im Zoll.


    Das "Protokoll" hätte ich auch schon fertig erdacht.


    Kannst mir auch gerne eine PM schicken..


    Stefan

    Zitat von Counterfeiter


    Stefan_Z Die Matrix hat ja einen Kampfpreis... könnte mich auch dafür interessieren... Leider geht dein Link nicht... ich vermute du meinst diese hier -> http://www.adafruit.com/products/420


    Ja der Server von dem Link hat heute Morgen irgendwie "verkackt" wie man so schön sagt :)
    Google-Cache hat ihn aber noch (ohne Bilder).


    Und der Preis ist weniger gut als du denkst, schau mal bei aliexpress.com ;)


    Meine zwei Test-Panels sind heute gekommen, wie schon befürchtet nicht ganz was ich bestellt hatte :)
    Statt 1/8 Scan habe ich 1/4 Scan bekommen. Was aber an sich sogar besser ist.
    Beschriftung der Pins ist (obwohl passend zur "Norm") eigenartig.
    Statt B1 und B2 steht da U1 und U2 - also frei nach Malcolm in the Middle "The L stands for Value" in diesem Fall "The U stands for Blue". ;)
    Die ICs sind wiederum korrekt mit UB1-UB8 beschriftet.


    Es sind 3x8 16-Bit KSQ-Treiber drauf, deren Hersteller ich nichtmal finden konnte - von einem Datasheet ganz zu schweigen :)
    Das Logo habe ich mal angehangen, ggfs. weiß ja jemand wer der Hersteller ist...
    Auf den ICs steht:
    SM16126
    dGSnb·61@D3D
    4Q1R 1336G


    Belegung scheint auf den ersten Blick entsprechend zu den üblichen, einfachen Macroblock 16-Bit-Treibern zu sein - je 8 Pins pro Seite zu den LEDs, der Rest Strom und Steuerung.


    Als erstes löte ich mir jetzt mal nen Adapter von zwei Xmega-Ports auf den 16-Pin-header der Panels, dann melde ich mich zurück.

    Hallo,


    scheint so, als wenns da nur noch 10 € sind... =)


    Mir fehlt leider die Zeit mir das gerade näher anzuschauen. Aber so ein paralleler Bus ist evtl. nicht ganz so einfach mit nem DMA anzusteuern...
    Zum Thema Glediator: Man könnte ja auch einen potenteren Prozessor als einen XMega nehmen und das tpm2 Protokoll in das richtige Format schaufeln... und dann per SPI auf kleine Ansteuerboards verteilen...


    Grüße


    Basti


    P.S. Vielleicht solltest du dazu mal nen neuen Beitrag kreieren... dann bleib ich dran, was sich bei euch so tut... :)

    Klingt interessant, vorallem bei dem Preis für die Matrizen.


    Wie wärs denn mit 'nem RaspberryPi der via ArtNet gefüttert wird?
    Mehrere Threads wovon sich je einer um die Ausgabe auf (insg. mehrere) I/Os kümmert und einer der die ganzen Daten aufbereitet und den Ausgabethreads bereitstellt...
    Speicher genug, Rechenpower genug, bringt LAN und I/Os mit, kostet fast nix.

    Beim Raspberry habe ich ein wenig die Angst zu ungenau zu werden.
    Multiplex-Displays brauchen ja sehr genaues Timing, damit man keine komischen Flicker- und Geisterbilder bekommt.
    Beim Rasp und seinen I/Os habe ich die Befürchtung, dass das Linux die IO-Ausgaben zu sehr stört.
    Grad die ganzen PWM-Zyklen "von Hand" zu machen benötigt ja gutes Timing, wenn das LSB da auf einmal 2x so lang ist, dann sieht das grässlich aus.


    Vielmehr hatten wir geplant, den Rasp als Host für die ganze Nummer zu benutzen.
    Der Xmega soll also nur dedizierter Controller sein.
    32MHz, 8MB RAM und flotte DMA sollten gut ausreichen, die Module selber können eh nur 30 Mhz.

    Die GPIO Ansteuerung beim Pi ist Hardwarenah... spielt aber keine Rolle, ohne Realtime Kernel wird das alles nix...



    Das mit dem XMega könnte klappen... mehr als 8 Bit Farbtiefe wird aber nicht drin sein... reicht ja aber auch...


    Was brauchst du 8 MB Speicher? Es sollte eigentlich nur zwei volle 3x8 Bit farbtiefe Bilder nötig sein...


    Also 2x16x32x3 Byte


    Ein Bild wird abgearbeitet und das neue strudelt gerade rein...



    Grüße Basti

    Die 8MB sind halt drauf, die löt ich jetzt nicht runter :)
    Und wir alle wissen ja wie inflationär Speichermengen heute sind...


    8-Bit wird schon gehen, da bin ich zuversichtlich.
    Und es gibt auch Macroblock-Treiber mit SRAM drin, da muss man nur einmal die 16-Bit LED-Werte reinclocken und danach dann immer nur noch die Reihen wechseln bis der was neues anzeigen soll.
    Für die Teile fertig verbaut findet man sicher auch einen Distributor.


    Der Adapter ist fertig, gleich werden die Teile mal angekabelt...

    Hallo Stefan,


    ich hab mich da etwas verrechnet... bin nur von einer 25 Hz PWM Frequenz ausgegangen (also ein Durchlauf pro Bild). Aber das ist ja viel zu wenig, dass muss ja mindestens um den Faktor 4 gesteigert werden.


    Bin aber so schon bei 32 MHz auf nur 3 Takte für eine 0 oder 1 gekommen... bzw 4 Takte bei übertakteten 48 MHz... Müsste man sich mal das ganze in ASM überlegen... ob 4 Takte reichen für einen Vergleich und eine 1 an eine Bitadresse schreiben + Adresse weiter zählen...
    Aber eh egal... Da ja die Frequenz mindestens 100 Hz sein muss, wären nur noch 1 Takt Rechenzeit übrig....
    Bei 6 Bit hätte man wieder die ~4-5 Takte...


    Da bleibt eigentlich bloß noch die Möglichkeit das aufbereitete Bild in der Größe 512*3*256 Byte durchzureichen... (was die maximale Panelanzahl reduziert) dann brauchst du auch wieder die 8 MB RAM... wenn der Zugriff auf diesen auch schnell genug abläuft... puhhh... da hast du dir ja was vorgenommen ;)


    Insgesamt könnte man das mit den Treibern die du angesprochen hast, erledigen (4 Takte bei 8 Bit bleiben aber eine Hausnummer)... da kann man auch gleich einen FPGA nehmen, hab ich das Gefühl :)


    Grüße


    Basti


    P.S. Korrigier mich, wenns die Tabletten sind (Olaf Schubert)

    Hallo,


    diese Time-Square-Panels mit bloßem AVR auf 8-Bit pro Farbe zu bekommen halte ich für aussichtslos. Das Muxen ist einfach zu umständlich / bzw. zeitintensiv. Die Teile sind ganz klar für die Verwendung mit FPGAs konzipiert und hier gibt es auch die fertige HW dafür:


    http://www.adafruit.com/products/1453


    Und diese HW wird dann mit DVI gefüttert, was über Glediator kein Problem ist. --> Einfach Output auf extra Fenster --> Vollbild und gut :P


    LG,


    Pepe

    Ich sag mal... FPGA wäre besser, aber sag niemals nie, dass es ein moderner Prozessor mit Eventsystem und DMA nicht auch schaffen würde...


    Man muss den Prozessor kennen und Kreativität an den Tag legen, dann könnte man es schaffen, wo andere noch Arduino Libs und Sketches suchen :)


    Hier mal mein Ansatz, mit dem ichs versuchen würde...


    Grundlage:


    Mein Trick wäre es den Prozessor gar nicht mehr zu benutzen (versuchen)... klingt erstmal komisch....
    Dann sollte man sich mal vor Augen führen, was so ein Timer alles kann... -> Timer, Zähler, Vergleicher, Addierer, schreiben auf Ausgabepin


    Wie kommt das Bild rein:


    Das Bild kommt in der Originalgröße mit 8 Bit Farbtiefe über einen SPI Port (USART als SPI) rein und ist schon von einem zB. Raspberry vorsortiert. (Glediator oder Jinx! mit tpm2.net zu Pi -> SPI)


    Matrixboard:
    Zwei DMA Kanäle laufen als Ringbuffer selbstständig durch... einer empfängt SPI Daten und sortiert sie in einen Buffer, der andere DMA läuft genau 1 Byte davor und hat damit immer das "älteste" Byte vor sich und das schickt es durch einen anderen SPI Port raus, getriggert werden beide DMAs durch den Empfangsbuffer der eingangs SPI...


    Eine Latch-Leitung an allen Matrix-Prozzis (Port-Pin Interrupt) sorgt dann dafür, dass die DMA Zeiger auf einen zweiten Bildspeicher springen... somit bereit für ein neues Bild und mit dem aktuellen Buffer kann gearbeitet werden...


    Vorteile:
    -16 MHz SPI ist möglich -> bis zu 52 LED Panels können somit Bilddaten in 25 FPS versorgt werden
    -CPU wird nur zum Adressen tausch beim Latch-Interrupt benutzt
    -SPI Signalpegel werden immer wieder aufgefrischt


    Wie kommt das Bild auf die Matrix:
    Die Parallelansteuerung der Schieberegister ist eher was für einen FPGA. Seriell ist also das Ziel. Dazu könnte man den Ausgabepfostenstecker mit dem Eingangsstecker zusammenschließen... So das nur ein serielles Signal gebraucht wird, um alle Bits zu setzen.
    Anschließend wird ein Timer mit Prozessor-Clock getaktet. Dieser zählt nur bis zwei... Bei eins gibt es ein Compare Register... damit haben wir eine Taktleitung mit CPU/2
    Beim Overflow oder auch schon beim Compare Ereignis (je nachdem wie das Timing passt) wird ein dritter DMA getriggert. Dieser schiebt einen 8 Bit Wert in ein Compareregister eines zweiten Timers. Der Timer Load ist natürlich auf den aktuell verarbeiten PWM Wert gestellt. Die Ausgabe ist der Bitdatenstrom synchron zum Clock!


    Das wird natürlich eine knappe Geschichte... Der DMA muss ja auch warten bis er auf den RAM zugreifen kann... Prioritäten sind evtl. einstellbar.


    Je nachdem wie viel Zeit gut gemacht wurde, könnte man nun weitere Sachen versuchen:


    Ein dritter Timer (Zeilentimer) wird dazu benutzt bis 8 zu zählen (eigentlich 7). Das Hochzählen wird über das Eventsystem vom dritten DMA (Bitstrom DMA) Überlauf getriggert. Zeitgleich wird ein vierter DMA vom dritten getriggert, der den Zählerwert des dritten Timers (Zeilentimer) auf einen PORT schreibt...




    Ist vielleicht etwas verwirrend, aber so in etwas könnte es funktionieren... mit dem XMega oder einem anderen Prozessor...


    Wenns richtig gut läuft, dann macht die CPU die ganze Zeit: nop nop nop :D


    Grüße


    Basti

    Hi Basti,


    das Konzept kann unter Umständen klappen. Wie Du schon sagst recht knapp kalkuliert aber evtl. machbar. Der Punkt dabei ist jedoch der, das Du effektiv aus Deinem AVR einen FPGA machst. :whistling: Denn Du schiebst ja alles auf HW-Ebene. Das nimmt sich effektiv rein garnix :) Zudem bist Du immernoch darauf angewiesen das die Daten "vorgekaut werden" und dazu muss irgendjemand (Pi oder PC-SW) massives Bit-Banging betreiben. Der FPGA hingegen würde das ganz "nebenbei" mitmachen.


    Es war also etwas voreilig von mir zu behaupten es ginge nicht, aber Aufwand und Nutzen ... =O


    Egal, noch ein fachlicher Beitrag:


    Zitat von Counterfeiter

    Der DMA muss ja auch warten bis er auf den RAM zugreifen kann... Prioritäten sind evtl. einstellbar.


    Ich weiß nicht genau wie es beim X-Mega ist, aber bei Freescale-Prozessoren kann der RAM zweigeteilt werden: Ein Teil für den DMA zugänglich, der andere Teil für's Programm. Wenn das beim X-Mega auch geht dann wäre dieses Thema schon erschlagen.


    LG,


    Pepe

    Hallo Pepe,


    ich find das nicht so schlimm, wie man mit nem Mikrocontroller zum Ziel kommt, ist doch egal...
    Zudem dürfte nen 2€ mc deutlich günstiger sein, der Aufwand auch kleiner...
    Das "lästige" Vorsortieren ist natürlich nen großes Manko...


    Denke nicht, dass der XMega DMA das kann... Problem bei den schnellen Takten nah des CPU Clocks ist natürlich, ein Wartetakt wirft hier alles aus der Bahn... und da ein MC dann doch nur einen Datenbus hat und der zwischen 4 DMAs und Prozessor geteilt werden muss, kann das schnell in die Hose gehen...


    Bin gespannt wie es beim Stefan voran geht... Vielleicht hat er noch eine Idee...


    Wenns klappt, wäre es sicher ne günstige Alternative... ansonsten muss man wohl doch härteres Geschütz auffahren...


    Grüße Basti

    Ach ich schau mal wie schnell man das hinbekommt.
    Erstmal die synthetischen / geschummelten Tests - also RAM raustakten, DMA testen, PWM basteln.
    Und vor allem: Das Mapping der Module ist ein Alptraum
    Ich hatte ja 1/8 Scan erwartet und 1/4 Scan bekommen. An sich cool, ABER...
    Statt zwei Zeilen doof von links nach rechts durchzutakten kommen hier nach je 8 LEDs der ersten Zeile erstmal wieder 8 LEDs der zweiten Zeile des jeweiligen Scandurchgangs.
    Und zwar von rechts nach links! Man schreibt also gleichzeitig immer vier Zeilen auf einmal, die untereinander verschachtelt und verdreht sind.


    Das ist schwer zu verstehen, daher anbei ein kleiner Plan der ERSTEN von VIER doppelten Doppelzeilen...
    Links die langen Pfeile zeigen den In-Port (jeweils 3-Leitungen natürlich - RGB) der zwei Zeilen.


    Besser wirds nicht in der Visualisierung, das ist ein Kuddelmuddel :)
    Wobei ich eh alle Bits mindestens einmal anfassen muss...


    FPGA hatte ich auch schon im Sinn, aber auch weder einfach, noch grad hier verfügbar.


    Der XMega kann 32MHz, offiziell (Specs der Komponenten) können diese Displays auch nur 30MHz, inoffiziell kommt man auf mehr, aber ab 40MHz fangen die Leitungen an zuviel Schrott einzufangen.


    Der XMega hat schnellen RAM, DMA und kann externe Takte bis um 200MHz erzeugen (das Timer-System ist mal echt komplex und mächtig...).
    Wenn man die DMA in den Griff bekommt und die Bitsortierung wirklich über den Host kommt, dann sollte das machbar sein.
    Man braucht ja nur einen Port gleichzeitig zum rausschreiben, der zweite kommt zum Latchen und für die Clock ins Spiel.

    Die Spannung steigt :) Ich find die Panels cool, würd mich freuen wenn es klappt. Ich halte es zwar auch für sinnvoller wenn man im mc die Daten sortiert bekommt, aber ich kann auch gern in der Software vorsortierte Daten in Jinx! zur Verfügung stellen wenn das hilft.

    Wenn ich das richtig verstehe dann sortiert Stefan gerade die Bits fertig, um das dann mit DMA gleich Mundgerecht auf einen Port zu schmeißen... das sollte definitv recht flott funktionieren... nur verschiebt man doch hier das Nadelöhr auf die eingehenden Daten...


    Wenn ich richtig Rechne braucht man für den "Bildeingang" eine SPI Geschwindigkeit von 16x32x3x8Bitx256PWMx1,25 (Da 6 Ausgänge aber Port 8 Bit = 1/4 Überhang)


    Das ganze zu allem Unglück noch 25 mal die Sekunde...


    Da wären wir bei 100 MBit für ein Panel...


    Wie soll das funktionieren? Oder hab ich mich verrechnet?


    Stefan, weih uns doch mal ein, was du vor hast... ich checks nicht so recht...