[UPDATE] Projekt RGB-Wall: Plasma-Effect

  • Update Teil 2:


    Wie das so im Entwicklungsstadium ist, kaum hatte ich die zweite Version der Modulplatine fertig gelayoutet, und ich hatte die Fertigung fast schon in Auftrag gegeben, da stolperte ich auf der Website von TI über den neuen (und auch problemlos erhältlichen) LED-Treiber-Chip TLC59116. Ich verwendete ja bisher den Chip PCA9634 (8-fach 8-Bit-PWM i2c-LED-Treiber) von NXP. Nun, der TLC59116 entspricht eigentlich ziemlich genau dem Chip PCA9635 (16-fach 8-Bit-PWM i2c-LED-Treiber) von NXP, mit einem entscheidenden Unterschied allerdings: Der TLC59116 hat die bei TI schon relativ üblichen Konstantstrom-Ausgänge, welche global über einen externen Widerstand im Bereich von 5 bis 120 mA eingestellt werden können, anstatt reiner Open-Drain-Ausgänge. Um die Farb-Variationen der einzelnen Matrix-Punkte auf einem Minimum zu halten ist es auch bei nach Helligkeit selektierten LEDs von Vorteil, wenn zumindest etwaige Variationen in der Durchlassspannung keinen Einfluss auf den Strom mehr haben. Dann hat man zwar immer noch die grundlegenden Helligkeitsvariationen (bei gleichem Strom), aber eben diese Variationen sind durch die Selektion vermindert. Ich hatte deshalb schon in der ursprünglichen Modul-Version (mit PCA9634) mit der Verwendung von je einem BCR402 pro LED und Farbe geliebäugelt, was aber durch die extrem hohe PWM-Frequenz (97kHz) der PCA-Chips verunmöglicht wird. In den PWM-Extremwerten ergeben sich bei 8-Bit Tiefe und 97 kHz minimale Pulsweiten von 40 ns, was von einem BCR402 leider nicht zu schaffen ist (wurde mir auf Anfrage sogar von Infineon selbst bestätigt). Umso mehr muss man den Hut vor den TI-Ingenieuren ziehen, denn diese haben die PWM-Frequenz von 97 kHz beibehalten und es trotzdem geschafft, ihre chip-internen Konstantstromquellen so zu designen, dass sie auch bei einem minimalen Puls von 40 ns schnell genug auf den Nennstrom rauffahren bzw. auch wieder runterfahren.
    Langer Rede kurzer Sinn bin ich gerade daran, die Version 3 der Modulplatine (ich hoffe die endgültige ;) ) eben mit 3 Stück TLC59116 zu layouten. Ich bin von diesem Chip so begeistert, dass mich nicht mal dessen einziger Nachteil, das TSSOP-Gehäuse mit 0,65 mm Pitch, mehr abschreckt ;) , zumal ich mir letztens die Weller Lötstation WD 2M mit WMRP-Lötkolben (sehr kleiner SMD-Lötkolben) angeschafft habe.

  • Bezüglich DMX, Bausatz etc.:


    So cool die MADRIX-Software auch ist, zumindest auf Modul-Ebene habe ich ganz sicher nicht vor, DMX zu implementieren. Wie bereits viele Male erklärt, kommt hier ein eigenes Protokoll zum Tragen, welches vor allem die 'Intelligenz' der Module bzw. der einzelnen Matrix-Punkte nutzt, um eben gerade keine grosse Datenflut übertragen zu müssen. Auf der Seite des Master-Controllers kann ich mir DMX als Option zur Kommunikation mit einem PC und/oder Stand-Alone-DMX-Mischpult vorstellen, ist aber für mich von untergeordneter Bedeutung, da das System inkl. Master-Controller vornehmlich unabhängig von weiteren Steuergeräten, also vor allem Stand-Alone funktionieren soll. Schnittstellen zum PC (ob USB oder TCP/IP oder beides wede ich noch sehen) sind zwar geplant, aber eher, um Farbanimationsprogramme am PC offline zu erstellen und dann die Programme zum System zu übertragen, welche dann wiederum stand-alone abgespielt werden. Eine live-Steuerung kann ich mir wie gesagt als Option vorstellen, ist aber für mich nicht primär wichtig. Und insbesondere halte ich von DMX als Protokoll ziemlich wenig (um nicht zu sagen, dass ich es grottenschlecht zusammengeschustert finde ;) , wohlgemerkt als Protokoll), aber naja, es ist eben ein Standard.


    Das System ist bzw. wird aber absolut offen und die HW auch dokumentiert genug sein, dass jeder hier sich seine eigene Software nach belieben sowohl auf die Module wie auch auf den Master-Controller wird klatschen können. Und da kann dann jeder das implemetieren, was er will (im Rahmen der HW natürlich).


    Und das bringt mich zu Bausatz und Konsorten. Sobald die gesamte HW von mir fertig entwickelt, gefertigt und getestet worden ist, werde ich hier Layouts und Schatpläne veröffentlichen, so dass man dann die Teile selbst nachbauen kann. Dasselbe mache ich auch mit der Software (Firmware), so dass man die ATmegas auch selbst beschreiben kann. Dabei werden die Module (bzw. das Modul-Board) wohl zuerst veröffentlicht werden und danach der Mastercontroller.
    Für die Platinen kann ich mir vorstellen, nach erfolgreichen Tests und bei genügend Interesse für die Interessenten hier entsprechende Platinen fertigen zu lassen und zu versenden. Da ich die Platinen in China fertigen lasse, sollten sie relativ günstig werden.
    Bausätze (d.h. Bauteile-Sets) und auch serienmässig bereits programmierte ATmegas etc. werde ich NICHT anbieten. Das ist mir einfach zuviel Aufwand, zumal ich einen anderen 100%-Job habe und dies hier ja auch nicht gewerblich betreibe.
    Da ich das ganze System aber unter Creative Commons (explizit: Namensnennung) veröffentlichen werde, kann ja jeder in die Bresche springen, wenn er will.


    Gruss
    Neni

  • Ich kenne den TLC5940 Chip von TI. Der verrichtet seinen Dienst recht ordentlich. Wird allerdings seriell angesprochen. Da ist die Lösung mit I²C viel schöner. Ich denke mit dem TLC59116 wirst du sehr glücklich werden.

  • Hallo Zusammen,


    bin auch grad an einer ansteuerung für 16 LEDs über I2C dran.
    Für meine Anforderung mit PWM Dimming + Blinking kam zunächst der PCA9532 in Frage.
    Dieses IC hat für mich jedoch den Nachteil, dass es nur 25mA pro Ausgang und 200mA Total treiben kann. Das ist für meine Anwendung etwas knapp.
    Nach einiger Suche ist eine gut verfügbare Alternative scheinbar der TLC59116.


    @ synvox:
    Du hast das Teil scheinbar schon im Einsatz.
    Hast du evtl. ein Codebeispiel zum Ansprechen und konfigurieren des TLC59116?
    Ich finde die TI Datasheets immer etwas unübersichtlich.



    Gruß RePi!

  • Hallo RePi,


    ich habe zwar schon 100 Stück TLC59116 zu Hause, aber leider sind meine neuen Modulplatinen noch nicht fertig. Deshalb habe ich noch keinen der TLC59116 verbaut und angesteuert. Da ich aber in der Vorgängerversion den PCA9634 verwendet habe, habe ich einen Testcode für diesen. Der PCA9634 wird bis auf ein paar Register, andere Adressen etc. genau gleich angesteuert wie der TLC59116, deshalb habe ich wegen der Ansteuerung keine Bedenken.
    Das Datenblatt des TLC59116 entspricht auch weniger dem 'TI-Standard', sondern ist viel stärker an die Datenblätter der PCA-Teile von NXP angelehnt, da TI ja für den TLC59116 den Grossteil des Designs von NXP übernommen hat. TI hat eigentlich 'nur' sein KnowHow in Mullti-Kanal-Konstantstrom-Treibern eingebracht und entsprechend Konstantstrom-Ausgänge einem bestehenden NXP-Design hinzugefügt (der TLC59116 ist ja ansonsten praktisch mit dem PCA9635 identisch).


    Falls du nur eine höhere, maximale Ausgangsbelastung und keine eigentlichen Konstantstromausgänge brauchst, kannst du dir als Alternative auch mal den PCA9625 von NXP ansehen, welcher pro Ausgang (16 Ausgänge) bis zu 100 mA bei max. 24V LED-Spannung (besonders geeignet für LED-Ketten an den Ausgängen) liefern kann.


    Falls es dir hilft, kann ich den Testcode für den PCA9634 posten.


    Ach ja, dein zuerst ins Auge gefasster PCA9532 wäre für eine individuelle Dimmung aller 16 LEDs mit 8-Bit-PWM absolut ungeeignet gewesen. Der PCA9532 hat 'nur' zwei PWM/BLINK-Register. Man kann dann jeweils das eine oder das andere Register jedem einzelnen Ausgang zuweisen, aber eine absolut voneinander unabhängige Dimmung aller 16 Ausgänge ist so nicht möglich. Dazu brauchts dann eben mindestens so viele PWM-Register wie Ausgänge, und das haben erst die PCA96xx-Teile.


    Gruss
    Neni

  • Hallo Neni,


    danke für die Antwort. Ich werde mir die Datenblätter von PCA963x und 9625 auch mal anschauen.
    Für meine Anforderung wäre der PCA9532 schon ausreichend, da ich den für Taster mit LED Beleuchtung benötige und in diesem Zusammenhang nicht jeder Kanal einzeln gedimmt werden muss sondern "nur" je Kanal OFF, ON, Blinken mit ca. 1Hz und ggf. ein Dimming Preset mit ca. 20% Helligkeit als Alternative zu OFF um die Taster bei dunkler Umgebung besser zu erkennen.


    Wäre nett, wenn du deinen Testcode mal posten könntest. Es ist immer hilfreich ein Brispiel zu haben.


    Gruß RePi!

  • Der TLC59116 ist ganz nett, Vor allem weil er nicht wie z.B. der TLC5940 einen externen PWM-Takt braucht.
    Die maximale I2C Frequenz ist allerdings 1000kHz = 1MHz. das könnte bei mehreren ICs in zeitkritischen Anwendungen teilweise was knapp werden.


    Zusatzfrage:
    Kann man eigentlich an den TLC5940 und Konsorten (also Constant Current Treiber) FETs anklemmen um damit größere Ströme zu schalten?
    Oder würde das dem IC/FET schaden, weil der IC versucht sein "Soll" zu erfüllen?
    ggfs könnte man ja auch den Strom auf was kleines wie 4mA stellen...

  • Also ich finde den TLC59116 super, da er eben die guten PWM-Multikanal-Eigenschaften und die extrem hohe PWM-Frequenz der PCA96xx-Teile von NXP mit dem Konstantstrom-Treiber-KnowHow von TI vereint. i2c ist natürlich eine gewisse Einschränkung, da insbesondere der Hardware-TWI aller bisherigen ATMEL AVRs nur max. Fast-i2c mit 400 kHz (Standard i2c ist ja 100 kHz) unterstützt und man mit Software-i2c (Bitbang-i2c) auch nicht schneller wäre. Somit kann man die 1 MHz der neueren i2c-Chip-Generationen gar nicht nutzen und ist auf die maximalen 400 kHz beschränkt. Allerdings reicht das für viele Anwendungen locker aus. Bei meinem 16-RGB-LED-Modul braucht ein ATmega328p mit HW-TWI bei 400 kHz ca. 1,25 ms für's Update aller 48 :!: PWM-Kanäle (3 TLC59116). D.h. man hätte also ne maximale Bildwechsel-Rate für Animationen etc. von 800 fps, zumal ja der Prozi mit der Banalität der PWM-Erzeugung nicht belastet wird. Eine schöne Sache ist auch, dass man das i2c-STOP auch erst am Schluss der gesamten Übertragung an alle Chips (der Wechsel zwischen den Chips findet dann einfach mit wiederholtem i2c-START plus jeweiliges Adressbyte ohne i2c-STOP davor statt) senden kann und diese damit dann synchron die neuen PWM-Werte übernehmen.
    Man könnte meine 16-RGB-Modulplatine (4 x 4) sogar relativ gut für einen 4x4x4-RGB-Cube verwenden, indem man 4 Ebenen a 16 RGB-LEDs übereinander legt und die 4 Ebenen dann nacheinander durchschaltet. Dann könnte man z.Bsp. alle 2,5 ms einen Interrupt auslösen und dabei die jeweiligen Ebenendaten übertragen und die Ebene umschalten. Das ergäbe für den Cube dann eine gute Bildwiederholrate von 100 fps (4 x 2,5 ms). Durch die sehr hohe PWM-Frequenz von 97 kHz müsste man sich auch nicht um die Synchronisation des Ebenen-Umschaltzeitpunktes auf Ende/Anfang eines PWM-Zyklus kümmern, denn bei einer Ebenenschaltdauer von 2,5 ms werden dabei ca. 242 ganze PWM-Zyklen durchlaufen, da macht's dann nicht viel aus, wenn einer davon (der letzte Zyklus)dann nicht vollständig durchläuft.


    maxi: Meine neue Modulplatine mit den 3 TLC59116 geht in den nächsten Tagen (ich muss nur noch den letzten Layout-Feinschliff machen) in China in Produktion, und ja, das ist richtig mit der Verschaltung, allerdings kannst du direkt auch ganze LED-Strings mit bis zu 17V schalten (auch ein weiterer Fortschritt gegenüber den PCA96xx-Teilen), wobei du natürlich die Verlustleistung im Auge behalten solltest. Für 20 mA pro Kanal sollte man einen Widerstand von 910 Ohm verwenden.


    Stefan: Das sollte eigentlich kein Problem sein, allerdings sollte man eine Inverter-Schaltung mit einem weiteren Transi zusätzlich zum N-MOSFET verwenden oder dann aber die LEDs gleich über die Anode mit einem P-MOSFET schalten, denn die TLCs mit Konstantstromausgang schalten ja gegen GND. Weniger als GND bringt ja ein Ausgang jeweils nicht zustande ;) , und wenn dabei dann immer noch kaum Strom fliesst, dann ist's dem Chip ja auch egal, dann ist der Ausgang eben voll ausgesteuert und führt einfach die minimal mögliche Spannung.


    Gruss
    Neni

  • maxi: Meine neue Modulplatine mit den 3 TLC59116 geht in den nächsten Tagen (ich muss nur noch den letzten Layout-Feinschliff machen) in China in Produktion, und ja, das ist richtig mit der Verschaltung, allerdings kannst du direkt auch ganze LED-Strings mit bis zu 17V schalten (auch ein weiterer Fortschritt gegenüber den PCA96xx-Teilen), wobei du natürlich die Verlustleistung im Auge behalten solltest. Für 20 mA pro Kanal sollte man einen Widerstand von 910 Ohm verwenden.


    Moin


    Bin sehr gespannt auf deine Platine. Ich arbeite auch gerade an einer kleinen Experimentierplatine. Läßt du das tatsächlich direkt in China produzieren? Darf man erfahren wo du das machen läßt? Kosten?

  • Hallo Maxi,


    da mein geplantes Panel mit 256 RGB-LEDs 16 Module benötigt, muss ich mindestens auch so viele Modulplatinen fertigen lassen (ich werde aber mal so 20 - 30 Platinen machen lassen), und das ist eigentlich zu einem bezahlbaren Preis nur direkt in China machbar. Wenn ich nur zwei, drei Platinen bräuchte, dann würde ich sie wahrscheinlich auch in DE beim PCB-Pool (BETA-Layout) machen lassen. Ausserdem kann man bei den chinesischen Leiterplattenherstellern sehr viele individuelle Optionen ohne grossen Aufpreis auswählen. Ich möchte für die Platinen zum Beispiel matt-schwarzen Lötstopplack drauf haben, und das kann ich beim Chinesen auswählen und es kostet mich nicht mal viel mehr.


    Ich werde wohl bei PCBcart bestellen, und da kosten mich 30 Stück 120 x 120 mm doppelseitig (mit SMD beidseitig), mit matt-schwarzem Lötstopp und gelbem Bestückungsdruck beidseitig inkl. E-Test und bei einer Fertigungszeit von 8 AT nur rund $ 230 (nicht €), was dann einem Platinen-Einzelpreis von $ 5,25 entspricht. Und die Qualität ist auch top bei den Chinesen, da gibt's nichts zu meckern. Der einzige Nachteil ist, wenn man das Haar in der Suppe sucht, dass neben GERBER nur gerade zwei Layout-Software-Formate akzeptiert werden, nämlich Protel und Eagle, ansonsten muss man eben wie ich auch (ich verwende SPRINT) GERBER-Daten generieren, aber das ist ja eigentlich auch keine Sache.


    Gruss
    Neni

  • Uhi, 256 RGB led´s, da bin ich sehr gespannt. Wann bekommen wir mehr Infos?
    Mich würde etwas Programmcode zum TLC59116 inbteressieren, vielleicht in Bascom. Würde mir Einstieg erleichtern.

  • Ich habe nun das neue RGB-Wall-Modul-Layout fertig, welches ich am Montag den Chinesen zur Platinenfertigung schicken werde, und stelle hier schon mal ein Bild von diesem Layout rein. Dass ein paar Leiterbahnen etwas versetzt erscheinen, liegt an der begrenzten Auflösung des Bildes, im Original ist natürlich alles korrekt. Was gegenüber der 'alten' Version neben der Verwendung der neuen TLC59116-LED-Treiber und eines anderen ATmegas auch noch anders bzw. hinzugekommen ist, ist die Integration eines i2c-non-volatile-Speicherbausteines zur Sequenzprogrammspeicherung (untere Mitte links) für die jeweils 16 LEDs einer Modulplatine. Dabei habe ich darauf geachtet, dass der verwendete Footprint 8-Pin-SOIC-Chips sowohl nach JEDEC- als auch nach EIAJ-Norm (etwas breiter) aufnehmen kann, denn zum Teil sind die entsprechenden Speicherbausteine bei sonst gleicher Pinbelegung nur in der einen oder der anderen Norm erhältlich. Prinzipiell kann man hier also fast alle erhältlichen i2c-8-Pin-SOIC-Speicherbausteine - typischerweise also Flash- oder EEPROM-Speicher - verwenden. Ich werde allerdings für meinen Aufbau wohl die ferro-elektrischen RAM-Bausteine von Ramtron (F-RAM) verwenden, denn diese haben im Gegensatz zu Flash und EEPROM praktisch keine Limitierung der Schreibzyklen (ca. 10^12 Schreib- und Lesezyklen) und benötigen auch keinen Delay beim Schreiben. Sie lassen sich also so einfach verwenden wie ein statisches RAM, sind aber dennoch auch non-volatile-Speicherbausteine mit einer Datenhaltung von mind. 45 Jahren (das reicht mir erstmal ;) ). Der einzige Nachteil ist, dass sie bei hoher Speicherdichte relativ teuer sind. Da ich aber als Sequenzprogrammspeicher nicht so extrem viel Speicher benötige, kann ich hier auch die mittleren Chips nehmen (z.Bsp. FM24C64, 8kByte), und diese sind nicht viel teurer als entsprechende i2c-Flashs oder i2c-EEPROMs.


    Drauf Klicken zum Betrachten in Originalgrösse (Bild):


    Gruss
    Neni

  • öhm, nichts für ungut maxi, aber liest du eigentlich die Beiträge hier (bzw. diesen Thread mal richtig) oder stellst du deine Fragen einfach so ins Blaue? Ich meine, s'ist ja nett, wenn man sich für mein Projekt interessiert, aber ich habe ehrlich gesagt weder Lust noch Zeit, alles unzählige Male zu wiederholen.


    Hier also nochmal, ein letztes Mal, obwohl's drei Posts weiter oben auch steht (zumindest ein Teil davon):
    Die Modul-Platine ist 120 x 120 mm gross und hat 16 RGB-LEDs. Mehrere dieser Modul-Platinen werden zu einem Panel verschaltet - vorläufig werde ich wohl ein Panel mit 256 RGB-LEDs (16 x 16), also mit 16 Modulplatinen machen. Naja, wenn ich wirklich die Lust verspüren sollte, absolut zu klotzen und nicht zu kleckern, dann werde ich ein Panel mit 400 RGB-LEDs (20 x 20) bzw. mit 25 Modulplatinen machen. Die Modulplatinen sind so ausgelegt, dass man sie maximal zu einem Quadrat von 8 x 8 Modulen (64 Modulplatinen) oder eben 1024 RGB-LEDs (32 x 32) zusammenschalten kann. Daneben sollen beliebige Kombinantionen von Modulen mit bis zu 8 Modulen in der Höhe und 8 Modulen in der Breite (also auch 6 x 3 z.Bsp.) möglich sein. Das Ganze soll dann Lounge-mässige, weiche, fluffige und ruhige Farbanimationen (kein Disco-Geblinke) auf die entsprechende Panelgrösse zaubern.


    Alles das und noch mehr wurde bereits weit tiefgehender in diesem Thread beschrieben. Also wenn Fragen da sind, dann bitte erst mal den Thread richtig lesen und schauen, ob's bereits beschrieben worden ist. Ansonsten sind aber Fragen absolut willkommen und werden auch beantwortet.


    Gruss
    Neni

  • Sorry wenn ich was überlesen habe, ich hatte den ein oder anderen Beitrag vielleicht etwas zu schnell überflogen ;) Wäre es nicht einfacher gewesen wenn du jede RGB Led-Farbe mit einem anderen TLC ansteuerst? Es wäre dann etwas einfacher programmierbar (vorstellbar) gewesen weil jeder TLC dann eine Matrix von 16x16 ansteuert.


    Ich habe mir jetzt erstmal ein Testboard mit 16 normalen LED´s gemacht, mal schaun was der TLC so kann. Programmierst du in Assembler, C oder Basic?

  • Wäre es nicht einfacher gewesen wenn du jede RGB Led-Farbe mit einem anderen TLC ansteuerst? Es wäre dann etwas einfacher programmierbar (vorstellbar) gewesen weil jeder TLC dann eine Matrix von 16x16 ansteuert.

    Du meinst wohl eine 4x4 Matrix (16 LEDs) pro TLC und Farbe. Ja, das wäre sicherlich idealer gewesen, aber mach mal ein Layout mit 3 TLCs und einer entsprechenden Verteilung (pro Farbe) der Signalleitungen auf die geforderte LED-Anordnung (plus noch genügend Platz für die anderen ICs und Bauteile), dann siehst du wo das Problem liegt ;) . Ausserdem werden über die Leitungen des TLCs zu den LEDs u.a. Schaltsignale mit einer minimalen Pulsweite von 40 ns übertragen (entspricht einer Frequenz von 25 MHz, also 97kHz PWM-Frequenz bei 8 Bit PWM-Modulationstiefe), da sollten die Leitungen sich dann nicht unbedingt über die ganze Fläche verteilen (auch von der Länge her ungünstig) und dann noch über möglicherweise mehrere Durchkontaktierungen bis zur LED führen. Deshalb habe ich einen Kompromis zwischen möglichst direkten Leiterbahnen zu den LEDs und einer intuitiv verwendbaren Signalverteilung gemacht. Jetzt werden die Register in den TLCs einfach in der Reihenfolge der 16 LEDs (von der LED-Seite her gesehen von links nach rechts und von oben nach unten) und zwar immer R, G, B, R, G, B, R, G, B... etc. beschrieben. Da in meiner Software immer jeweils die PWM-Werte aller 16 RGB-LEDs in einem 'Aufwasch' upgedatet werden, ist es auch programmiertechnisch keine grosse Sache. Übrigens hatte ich auf der Modulplatine Version 1 (mit 6 PCA9634 anstatt der 3 TLC59116) die Ein-Chip-pro-Farbe-Verschaltung realisiert, aber da war's relativ einfach und gut realisierbar, weil man jeweils 3 Chips in einer Reihe für jeweils die oberen und unteren 8 LEDs platzieren konnte und so die Leitungen auch relativ kurz und direkt halten konnte.

    Programmierst du in Assembler, C oder Basic?

    Eigentlich kann ich die AVRs in allen drei Sprachen recht gut programmieren. Meist verwende ich allerdings eine Kombination aus BASCOM (Basic) und Inline-Assembler (für zeitkritische Aufgaben) für meine Firmware-Lösungen.


    Gruss
    Neni