EDV-Dompteur/Forum

Hier geht es also um moderne LED-Pixel und deren Ansteuerung.

Populär sind die WS28xx.
Es gibt verschiedene Varianten dieser ICs, mit mehreren Kanälen, sowie auch RGB-LEDs mit bereits integriertem Controller-Chip.
Und die dahinterstehende Technik ist ein echter Problemlöser!

Will man auf klassischem Wege eine größere Anzahl LEDs treiben - sagen wir mal 100 Stück - so braucht man (strikt geradeaus gedacht) pro LED eine Leitung, die dann von einem Mikrocontroller-Port bedient wird.
Bei RGB-LEDs die dreifache Anzahl.
Das überfordert praktisch jeden Mikrocontroller, weswegen eine zumindest eine Porterweiterung her muss.

Ja, natürlich kann man die LEDs auch in Form einer Matrix ansteuern. Dann reduziert sich die Anzahl der benötigten Leitungen/ Ports auf:
2 x sqr(LED-Anzahl).
Wobei das Ergebnis aufzurunden ist.
Bei 300 Kanälen wäre also eine Matrix von 17 x 18 Leitungen, also 17 + 18 = 35 Ports angesagt.
Noch immer unangenehm viel …

Ja, per Charlieplexing lässt sich da noch etwas einsparen, dafür wird die Ansteuerung komplexer.

Überhaupt bin ich bei LEDs generell kein Freund von Matrixschaltungen jedweder Art und von Multiplexing.
Ich habe festgestellt, dass ich Refreshraten bis herauf zu 3000 Hz noch als flimmernd wahrnehme! Das glaubt mir zwar keiner, ist aber so.
Spätestens wenn Bewegung ins Spiel kommt (Fahrzeuge, Karussellgondeln) wird die unterbrechende Art der Ansteuerung störend sichtbar.

Natürlich gibt es spezielle ICs, die sich dem Treiben einer größeren Anzahl LED verschrieben haben.
Bessere Varianten arbeiten mit einer hohen Refreshrate für flimmerfreien Betrieb.
Manche befreien einen von der Notwendigkeit, zahlreiche Vorwiderstände bestücken zu müssen.
Manche sind auch in der Lage Korrekturtabellen zu speichern, um fertigungsbedingte Helligkeitsstreuungen der LEDs zu korrigieren.
Richtig gute Bausteine reduzieren zudem die EMV-Störungen, durch zeitversetztes Ansteuern der Kanäle.
Dennoch: Solche Bausteine sind meistens recht kompliziert in der Ansteuerung und oft nicht ganz billig.

Die WS28xx erleichtern dem Elektroniker prinzipiell das Leben. Sie werden ähnlich einem Schieberegister angesteuert, wobei sich jeder Chip die zuerst ankommenden Daten aus dem Datenstrom herausgreift und die restlichen Daten per Daisy-Chain einfach an den nächsten Chip weiter reicht.
Die zuerst gesendeten Daten landen also im ersten Chip. Die zuletzt gesendeten im letzten Chip.
Also genau anders herum, als bei einem normalen Schieberegister, wobei diese Idee genial ist! Die Kette kann beliebig lang werden, es ist keine Adressierung notwendig und die Daten werden durch das Daisy-Chaining bei jedem Weiterreichen aufgefrischt.

Dickster Makel sind die doch deutlichen Radiostörungen, die solche Bausteine verursachen.
Auch arbeiten die WS28xx nur mit 8 BitHelligkeit pro Farbe, was doch etwas wenig ist, um perfekte Farbübergänge zu erreichen.
Aber dort, wo man mit den Makeln leben kann, sind die Dinger aus praktischer Sicht die Wucht in Tüten!

Etwas tricky sind sie dann aber doch, und zwar aus einem dummen Grund: Die Designer dieser Chips haben leider an einer Stelle etwas gepennt und ein Timing-Protokoll implementiert, dass z. B. mit einem AVR nur schwer einzuhalten ist.
Das Problem ist, dass ein AVR, der das Timing einer solchen Pixelkette korrekt einhält, damit dermaßen ausgelastet ist, dass er kaum noch andere Dinge tun kann.

Es sind verschiedene Wege bekannt, sich damit zu arrangieren.
Teils wird der UART missbraucht, oder der SPI-Port. Manchmal kommen externe Gatter ins Spiel. So richtig gut ist aber keiner der bekannten Ansätze.

Hier mal zwei Links auf die Seiten von Anwendern, die sich ausgiebig mit der Materie beschäftigt haben:

http://bleaklow.com/2012/12/02/driving_t…_16mhz_avr.html

http://www.instructables.com/id/My-respo…thing/?ALLSTEPS

Interessante Studien, wohl wahr. Der IMHO bessere Weg, wenn man denn bei AVR und möglichst wenig externer Hardware bleiben will, ist wohl der, einen XMEGA mit DMA zu verwenden.

Ich wäre jedenfalls in der Regel gerne bereit, weitere Chips einzusetzen und damit die Hardwarekosten um 2,- EUR hochzutreiben, wenn mir das anschließend stundenlanges, nächtelanges Feintuning im Programmcode erspart.
Bei Massenfertigung rechnet man da anders, das ist klar.
Ansonsten bin ich persönlich gründlich davon ab, auf Biegen & Brechen per Software das Letzte Quäntchen Leistung aus eigentlich unterdimensionierter Hardware zu quetschen.
Leicht pflegbarer Code, und Reserven bei der Rechenzeit für später eventuell notwendig werdende Erweiterungen, sind mir da wichtiger.

Der im schlanken 32-poligen TQFP-Gehäuse daherkommende ATXMEGA32E5 beispielsweise, kostet als Einzelstück selbst bei Farnell nur 2,48 EUR (netto).
Der bietet DMA und sogar einen "XCL" genannten Logic-block, für Gatterfunktionen auf Hardwareebene.
http://de.farnell.com/atmel/atxmega32e5-…tqfp/dp/2327712

Zum doppelten Preis gibt es den ATXMEGA128A1U-AU, der zwar ohne XCL, dafür neben DMA auch mit USB daher kommt, sowie mit dickerem Speicher:
http://de.farnell.com/atmel/atxmega128a1…tqfp/dp/2308646

Kombiniert man ersteren Chip, als reinen Pixelkettentreiber, mit letzterem, der dann USB-Connectivität bietet und genügend Power für sonstige Steueraufgaben hat, so wäre das in meinen Augen ein ideales Gespann für anspruchsvolle Beleuchtungsaufgaben.

Das wird wohl eines meiner nächsten Projekte werden ...
- Fortsetzung folgt.

Hackaday berichtet hier: http://hackaday.com/2013/05/27/ws2811-ca…g-a-8mhz-clock/
... unter Verlinkung auf: http://rurandom.org/justintime/index.php…th_an_8_MHz_AVR

... über einen genialen Assembler-Hack, der es ermöglicht, WS2811 LED-Pixel mit 800kHz zu treiben, unter Verwendung des internen 8MHz-Oszillators eines AVR-Controllers!

Respekt! Auch für die gelungene Dokumentation.
Das korrekte, sehr kritische Timing für WS2811 zu erzeugen, ist mit 'nem AVR schon ein recht heftiger Akt. Erst recht im 800kHz-Modus.
Das aber ohne externe Bauteile zu wuppen, rein mit dem internen 8MHz-RC-Oszillator - das beeindruckt!
Da braucht man theoretisch ja nicht mal 'ne Platine; einfach die LED-Kette direkt an den Controller löten und fertig.

Nun ist Assembler nicht so meine Sprache, aber BASCOM erlaubt ja das Einbetten von Assembler-Code.
Dennoch sei angemerkt, dass ein AVR mit so einem zeitkritischen Code natürlich bis zum Anschlag ausgelastet ist.
Lichtmuster vom PC per USB oder WLAN an den AVR zu senden, der dann die Pixelkette ansteuert, ist wohl nicht.

Es wäre mal einen Test wert, ob man die Routine nicht so umstricken kann, dass sie die Daten aus dem RX-Empfangpuffer holt, statt aus dem DATA-Bereich.
Dann könnte man ein Zweiprozessor-System aufbauen, bei dem ein sich langweilender Controller seine Daten byteweise an jenen AVR sendet, der die Pixelkette treibt.
Der erste Controller hat reichlich Zeit, eben weil er immer nur ganze Bytes ausgibt.
Da muss aber natürlich ein Handshake her, zwischen den beiden Controllern, damit der Empfangspuffer im Pixelkettentreiber weder überläuft, noch zu langsam gefüttert wird.

(Seufz!) Wenn die Chinesen den WS2811 doch nur so designt hätten, dass das Timing ganz easy per UART oder SPI erzeugt werden könnte ...

Erstaunlich - Elektroniker klagen gemeinhin über die hoch zeitkritsche Ansteuerung der WS2811 LED-Pixel.
Auch ich habe mir schon manche Stunde den Kopf zerbrochen, wie man den zeitkritischen Part von der Software in hart verdrahtetes Silizium verlagern kann, um den Mikrocontroller zu entlasten.

Aber man lese mal das hier:

NeoPixels Revealed: How to (not need to) generate precisely timed signals