Hallo, ich habe mit ein paar Kommilitonen ein recht gewaltiges Projekt vor, dass für Messe-Zwecke genutzt werden soll. Ein 16x16x16 RGB Cube. In ein Rechnung für welche Ansteuerung wir uns entscheiden ( auch in Preislicher Hinsicht ) haben wir uns gegen WS2812 entschieden, da wir 'normale' RGB Dioden sehr günstig bekommen können ( 4500 für ca. 110 Euro) und wir würden zwar mit dem alternativen 'baustyle' die die WS2812 ermöglicht ca. 230m Silberdraht sparen im Gegenzug dazu allerdings knapp 700Euro für die Dioden ausgeben. Wie dem auch sei wir haben uns für den 'normalen' Baustyle entschieden. In einem Horizontalen Layer wird die Anode aller Dioden miteinander verlötet und in den vertikalen Layern Werden immer die R G B Kathoden der Übereinander liegenden Dioden verlötet, sodass man jede Diode einzeln ansteuern kann, indem man GND an den Jeweiligen Vertikalen Zugang der Diode am Layer anschließt und VCC auf den gesamten horizontalen Layer anschließt. Natürlich wollen wir via Mutliplexing alle Dioden 'gleichzeit' leuchten lassen können. Was uns letztendlich zu einem Problem führt: Als Treiber dachten wir an den TLC5940, der sich in kleineren Projekten schon bewährt hat. Allerdings müssten wir 768 LED's gleichzeitig ansteuern und das in einem 1/16 tel einer 1/24 Sekunde. Ein Update pro layer darf also nicht länger als 2.6ms dauern. Aus dem Datenblatt haben wir ausgerechnet, dass wir allerdings für 768 LED's ein Update ca. 100ms dauern würde. Einmal würde ich ein mit dem TLC5940 erfahreneres Mitglied bitten, vielleicht unsere Rechnung zu verifizieren bzw. uns zu sagen, ob wir uns umsonst den Kopf zerbrochen haben und (hoffentlich) uns ein Rechenfehler unterlaufen ist. Falls dem nicht so sein sollte würde ich euch Bitten uns alternative zu zeigen. Wir dachten schon an sowas wie pro verticalen layer ein Arduino zu nehmen, der 3 TLC5940 ansteuert und diesen dann via z.B. I2C von einem Master Arduino anzustuern o.ä. Wir sind für eure Vor- und Ratschläge offen. Zusammen finden wir bestimmt eine Lösung (Ein Monitor funktioniert schließlich auch ähnlich und hat weit mehr LED's ;) ) Viele Grüße!
:
Bearbeitet durch User
Ich kann Dir dazu keinen Ratschlag geben, wäre allerdings sehr daran interessiert, zu erfahren, was das für ein "Messe-Zweck" sein könnte.
Für unseren 20³ Cube haben wir damals zunächst auf den TLC5973 von TI gesetzt. Das Schieberegister im Chip läuft mit 3MBit/s. Pro IC müssen 48 Bit geschrieben werden. Somit kann man pro Sekunde gute 62000 RGB LEDs ansteuern. Will man die üblichen 30 FPS, sind das immer noch über 2000 Stück die man sich pro Frame erlauben kann. Inzwischen haben wir aber auf die APA102-2020 LED gesetzt. Gegenüber den bekannten WS2812 LEDs hat sie das schnellere Interface. Mit 2x2 mm ist sie sehr klein und durch das fast durchsichtige Gehäuse kann man sie gut aus jedem Winkel sehen. Somit konnten wir den ganzen Würfel filigraner Aufbauen und man sieht die inneren LEDs besser.
Naja, die Rechnung ist ja so schwer nicht: 256 LEDs x 3 (RGB) x 12 Bit = 9216 Bits pro Ebene (dafür werden 48 TLC5940 benötigt!). Die max. Clock des TLC5940 ist mit 30MHz Transferrate angegeben. Die Übertragung dauert also (1/30000000)*9216 = 0,3ms. Für 16 Ebenen dann ca. 5ms. D.h. ihr könntet ca. 200 Updates pro Sekunde für den ganzen Cube machen. Wie habt ihr das denn berechnet?
:
Bearbeitet durch User
Messe-Zwecke damit meinte ich, dass wir den Cube unter anderem auf einer Uni Messe Präsentieren möchten. Sowas wie eine Job-Messe nur dass sich dort die Unis vorstellen :D
Ich habe einen 10x10x10 blauen Würfel mit TLC5948A realisiert. Das ist ein 16bit PWM Treiber, sehr ähnlich dem TLC5940. Ich verwende einen STM32F070 mit 48MHz. Bei einer Bildwiederholrate von 100Hz, muss jede Ebene für 1mS geschaltet sein. Nutze ich z.B. nur 8Bit der PWM, muss ich diese mit 256*1000 = 256kHz betreiben und alle 256 Zyklen einen Interrupt auslösen, um die nächste Ebene zu schalten. ### Wenn ihr auch 100Hz machen wollt, dann benötigt ihr 0,625mS pro Ebene. Bei 16*16 = 256*3 LEDs pro Ebene braucht ihr 768 Kathoden. Das wären 768/16 = 48 Treiberbausteine. Bei einem 256Bit Schieberegister müsstet ihr alle 0,625mS 48*256 = 1526byte übertragen. Bei 20MHz SPI braucht ihr dafür 0,6104mS. Ich würde das Ganze ggf. auf mehrere synchrone µC verteilen. Ich würde mir auchmehr Sorgen um die Bildberechnung machen, anstatt der Übertragung und dem Stromfluss.
Nachtrag: Ich wollt ja 24 Updates/s. Da müsst ihr aber auch schon eine ziemlich hohe Frequenz für die PWM nehmen, nämlich: Fgsclk >= 4096 x 16 x 24 = 1,57MHz Habt ihr denn mal ausprobiert, ob eure ausgewählten LEDs bei 1/16 PWM überhaupt noch ausreichend hell sind? Man kann zwar den Strom im PWM Betrieb erhöhen, aber auch dem sind Grenzen gesetzt... Und wenn ihr den Strom erhöht, müsst ihr das bei der Stromversorgung mit einkalkulieren, wenn ihr mal mit 100mA pro LED rechnet, sind das schon so um die 75A Spitzenstrom (R=G=B=max).
:
Bearbeitet durch User
Markus M. schrieb: > Habt ihr denn mal ausprobiert, ob eure ausgewählten LEDs bei 1/16 PWM > überhaupt noch ausreichend hell sind? Man kann zwar den Strom im PWM > Betrieb erhöhen, aber auch dem sind Grenzen gesetzt... Bei mir gehts. 1/10 der Zeit sowieso nur an (10x10x10 Würfel), kann ich bei Nutzung von 12bit statt 16bit immernoch ganz normal zufriedenstellend dimmen. 100Hz 10 Ebenen 12bit = 4MHz PS: Formel wird in fette Schrift umgewandelt..
@Chris K. Also dann 256 von den Treibern ? PA102-2020 bei dieser Diode sehe ich das gleiche Preisproblem wie bei der WS2812. @Markus M. Wir haben mit zusätzlichen Bits für die Adressierung gerechnet, die nach meinem Wissen 10 Bit ist und mit einer Niedrigen Frequenz von 16Mhz, da wir von einem Arduino ausgegangen sind. Oder haben wir die den TLC falsh verstanden ? @Curby23523 N. Das war auch eine Überlegung von uns, allerdings bleibt da die Frage offen wie wir die µC mit der Information versorgen welche leds einzuschalten sind. @Markus M. Um ehrlich zu sein. Allerdings hoffen wir darauf, dass wir die Framrate so hoch treiben können, dass es hell genug ist. Falls nicht laufen wir tatsächlich in das von dir Angesprochenen Problem.
Was für eine Adressierung? Der TLC5940 wird einfach kaskadiert, siehe auch Datenblatt Seite 23. Da schiebt ihr dann die 256x3x12 Bits rein. Ihr benötigt einen schnellen Controller mit SPI DMA und möglichst viel RAM. Ein STM32F4xx kann das leisten denke ich mal.
Sebastian W. schrieb: > Messe-Zwecke damit meinte ich, dass wir den Cube unter anderem auf einer > Uni Messe Präsentieren möchten. Ihr könnt ihr damit messen, wie viele Leute sich davon angezogen fühlen. Vielleicht können die Hersteller von elektrischen Mückenfallen etwas daraus ableiten. Sozusagen Menschenversuche für Tierprodukte, da kann sich kein Veganer drüber beklagen :-)
Ne leider nicht. Pro LED ein Treiber. Macht halt Sinn, wenn man die wie wir gesponsert bekommt. Für die apa haben wir gut 500 Euro bezahlt. Dagegen kannst du rechnen was dich die anderen Kontroller kosten
Stefanus F. schrieb: > Ihr könnt ihr damit messen, wie viele Leute sich davon angezogen fühlen. > Vielleicht können die Hersteller von elektrischen Mückenfallen etwas > daraus ableiten. Sozusagen Menschenversuche für Tierprodukte, da kann > sich kein Veganer drüber beklagen :-) Tatsächlich hatten wir mit Leucheffekten schon den ein oder anderen geködert allerdings dient dieser Würfel nicht als 'Leuchtreklame' sondern wird 'live' programmiert, Interessenten können dort ihre eigenen Algorithmen implementieren oder nur Stumpf eine LED nach der anderen zum leuchten bringen. Programmier erfolge mit direkten Visuellen Effekt sind wohl die ansprechendsten für Einsteiger. Allerdings habe ich das Konzept nicht ausgearbeitet wir/ich sind/bin lediglich nur Teil der Executive ;-) Markus M. schrieb: > Was für eine Adressierung? > > Der TLC5940 wird einfach kaskadiert, siehe auch Datenblatt Seite 23. Da > schiebt ihr dann die 256x3x12 Bits rein. > > Ihr benötigt einen schnellen Controller mit SPI DMA und möglichst viel > RAM. > > Ein STM32F4xx kann das leisten denke ich mal. Perfekt, dann hatten wir tatsächlich einen Fehler in der Logik und es ist mit den TLC5940 tatsächlich Umsetzbar :D Ich habe jetzt nach kurzen suchen diesen STM32F4 raus gesucht: https://www.exp-tech.de/plattformen/arm/stm32-discovery/9059/xcore407i-stm32f4-core-board?gclid=CjwKCAjwiN_mBRBBEiwA9N-e_qHnCQwgY1kkl_4FdwoDkbvH0TPLfTi1upjmgM3bzsJgXSqCX5TYexoCSn0QAvD_BwE Wenn ich es richtig Verstanden habe, hat dieser µC Sogar 3 SPI Ports die Parallel verwendet werden könnten. Was dann pro Port nur 16 TLC heißen würde. Auch der Ethernet Anschluss ist super, da wir so ein Standard Protokoll für die Kommunikation verwenden können. Allerdings steht im Datenblatt diese Angabe für den RAM: 1024kB Flash, 192+4kB SRAM. Würden wir für 786Pins einen Status 'Behalten' müssen wofür ja dann jeweils 12Bits gespeichert werden müssten wo wir bei überschlgen 50Mb raus kommen. Hast du vielleicht eine alternative ?
:
Bearbeitet durch User
Also natürlich will man wenigstens einen "Frame" zwischenspeichern, gerade dann wenn man Algorithmen ausprobieren möchte. Also ihr habt 4096 LEDs. Ihr müsstest euch entscheiden ob ihr mit RGB oder HSV Farbraum arbeiten wollt. Beide haben Vor/Nachteile, man kann auch zwischen beiden konvertieren, kostet aber Speicher bzw. Rechenzeit. Persönlich würde ich empfehlen nur mit 8 Bit Auflösung je Farbe zu arbeiten und das dann über Gamma-Korrektur auf die 12 Bit der Treiber umzurechnen. Dann würdet ihr pro kompletten Frame 4096 x 3 = 12kByte Speicher benötigen. Das ist bei einem Controller mit 192kByte jetzt nicht wirklich viel. Ich würde es so machen: - Einen Buffer mit den Ausgabedaten in RGB oder HSV (8 Bit pro Farbe) - Eine Funktion die diesen Buffer-Inhalt in den seriellen Datenstrom für die LEDs umrechnet, und dabei: -- Gammakorrektur (8 Bit -> 12 Bit) durchführt -- Ggfs. von HSV nach RGB umrechnet (sofern gewünscht) - Die SPI Ausgabedaten sind dann 18Kbyte (wg. der 12 Bit pro Farbe) - Es wird ein SPI DMA gestartet um die Ausgabedaten zu übertragen Während der Übertragung aus dem SPI Buffer kann im RGB bzw. HSV Buffer bereits der nächste Frame berechnet werden. Viel Spass.
Sebastian W. schrieb: > Programmier erfolge mit direkten Visuellen Effekt sind > wohl die ansprechendsten für Einsteiger. Kinder stehen noch mehr auf Akustische Effekte - die Lehrer und Eltern eher nicht.
Sebastian W. schrieb: > müssten wo wir bei überschlgen 50Mb raus kommen. Huch! Kannst du mal Offenbarung, wie du auf diese Zahl gekommen bist? Nur mal so zum Zahlenvergleich: Die ganze Bibel umfasst etwa 5 Megabytes.
Stefanus F. schrieb: > Kinder stehen noch mehr auf Akustische Effekte - die Lehrer und Eltern > eher nicht. Ich verstehe, dass du von der Idee nicht sonderlich begeistert bist. Aber ich muss keine Überzeugungsarbeit leisten. Wenn dir die Grundidee nicht gefällt, dann ist es so. Aber es geht in diesem Thread nicht darum, ob es sinnvoll ist einen solchen Cube für eine Messe zu bauen. Deshalb würde ich dich bitten beim Thema zu bleiben. Stefanus F. schrieb: > Huch! Kannst du mal Offenbarung, wie du auf diese Zahl gekommen bist? > > Nur mal so zum Zahlenvergleich: Die ganze Bibel umfasst etwa 5 > Megabytes. Vollkommen richtig! Ich habe ohne weites überlegen ein Mb hinter die 50 gesetzt ich meine natürlich kb. Auf die Zahl bin ich gekommen, da ich 768 PIN's ansteuern möchte, der TLC5940 12 Bit pro Ausgang für die PWM benötigt. Somit wären es 3.152 Bits um einen Layer zu speichern und da ich 16 Layer habe komme ich auf 49.152 Bits was ungefähr 50kb sind.
@adrock Ich danke dir für dein 'Rezept'! Wirklich super! Wir haben jetzt eine gute Vorstellung, wie wir diesen Würfel treiben bzw. programmieren werden! :D Wie ich/wir es verstanden haben würdest du nur einen SPI Port verwenden. Gibt es dazu einen speziellen Grund ?
Sebastian W. schrieb: > Wir sind für eure Vor- und Ratschläge offen So baut man das nicht. Man multiplext nicht 16 Ebenen mit je 48 TLC5940 a 16 RGB LED, sondern man multiplext höchstens 8 Ebenen, also den halben Würfel, und braucht dann eben 96 TLC5940 für die 4096 LEDs. Man baut auch nicht 1 Schieberegisterkette auf, sondern man nutzt z.B. 8 parallele Schieberegisterketten a 12 TLC5940, alle mit demselben Takt und die Daten aus einen parallel beschickten Port. Es sind immer noch 4096 x 12 bit pro Schieberegister und 48kByte pro 5ms. Eigentlich möchte man die Belegung der Schieberegisterausgänge in den 5ms vorbereiten, dann die alte Ebene abschalten, die neue Schieberegisterausgangsbelegung durchschalten und die neue Ebene einschalten, doch dafür eignet sich der TLC5940 nicht. Bei ihm wird die LED an 1 Pin immer gleich gesteuert nach dem die 12 bit PWM Daten übertragen wurden. Daher halte ich von dem Chip nichts. Braucht ihr wirklich 4096 Helligkeitsstufen, reicht nicht an/aus ? Die billigen LED sehen sowieso von jedem Betrachtungswinkel unterschiedlich hell aus und das auch noch pro Farbe, da sind Helligkeitseindrücke kaum steuerbar. Selbst ein simpler an/aus Chip wie CAT4016, bei dem man wenigstens alle bits reinschieben kann bevor man alle Ausgänge für alle LED schlagartig beim Ebenenwechsel durchschaltet, erfordert 192 bit in 5ms für alle 12 in einer Reihe, also 25us Takt bei 8 parallelen Reihen. Man will gerne Standards, entweder kompatibel zur Ansteuerung eines Farb-TFT mit LVDS Signalen und z.B. 6 bit pro Farbe und HSYNC / VSYNC Signalen, oder entsprechend dem LED Panel Standard Hub75 https://hackaday.com/tag/hub75/ Beitrag "LED-Matrix, 9x9 RGB, Voll dimmbar" http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.8.1 Unterschätzt nicht den Aufwand, 16000 LED Anschlussbeinchen zu verlöten. Und rechnet mit 125 zu schaltenden Ampere bei 5V.
Sebastian W. schrieb: > Ich verstehe, dass du von der Idee nicht sonderlich begeistert bist. Oh doch, das ist ein tolles Projekt! Da habe ich mich wohl missverständlich ausgedrückt.
MaWin schrieb: > So baut man das nicht. Man multiplext nicht 16 Ebenen mit je 48 TLC5940 > a 16 RGB LED, sondern man multiplext höchstens 8 Ebenen, also den halben > Würfel, und braucht dann eben 96 TLC5940 für die 4096 LEDs. Warum? Wg. dem ungünstigen Tastverhältnis? (1/16)? Das hatte ich ja auch oben schon zu Bedenken gegeben... > Man baut auch nicht 1 Schieberegisterkette auf, sondern man nutzt z.B. 8 > parallele Schieberegisterketten a 12 TLC5940, alle mit demselben Takt > und die Daten aus einen parallel beschickten Port. Ja, die Idee hört sich gut an. Benötigt allerdings mehr Aufwand bei der Vorbereitung der Daten. > einschalten, doch dafür eignet sich der TLC5940 nicht. Bei ihm wird die > LED an 1 Pin immer gleich gesteuert nach dem die 12 bit PWM Daten > übertragen wurden. Daher halte ich von dem Chip nichts. Hmmm... er hat doch aber sowohl ein BLANK als auch LATCH (XLAT) Eingang. Das ist doch dafür gedacht, oder habe ich etwas falsch verstanden? > Unterschätzt nicht den Aufwand, 16000 LED Anschlussbeinchen zu verlöten. Jupp, das wird sehr heftig. Alleine das Biegen, Ablängen etc. ist eine ziemliche Strafarbeit. Selbst bei meiner "nur" 20x20 WS2812-Bedrahtet-Klon-Matrix brauchte es echt Durchhaltevermögen um nicht aufzugeben.
Bitte 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.