testbericht zum WS2812

ja, das hab' ich auch gefunden, wie ich ws2811 und raspberry gesucht habe. eine schöne lösung, und mit der arduino IDE zu programmieren. am günstigsten hab' ich's hier gefunden:

http://www.ebay.de/itm/Teensy-3-0-USB-Entwicklungs-Board-32bit-ARM-Cortex-M4-MK20DX128VLH-Original-PJRC-/261116450779?pt=Wissenschaftliche_Geräte&hash=item3ccbc0d7db

auf dem DUE kann diese library nicht laufen.

gruß stefan

Ich hab noch immer keine WS bestellt :frowning:

Aber: die Bibliothek kann doch Ports initialisieren, hat das jetzt schon mal jemand getestet?

  FastSPI_LED.setPin(PIN);
    FastSPI_LED.init();
  FastSPI_LED.start();

initialisiert das Ganze, also kann der PIN übergeben werden
Was passiert, wenn man im Sketch mit

FatsSPI_LED.stop();

das ganze beendet und auf einem anderen Port neu initialisiert??

Eventuell noch mit verschiedenen Längen diese anpassen (FastSPI_LED.setLeds).

Das einzige Problem könnte die Verzögerung sein, die dann zwischen den Strängen entsteht, aber ist das ein Problem?

Und @Til: Wenn du deine Beleuchtung zonenabhängig machst, willst du dann die LED einzeln ansprechen können? Ansonsten könnte man ja auch Stränge parallel betreiben?

Dirk

Hi, das ist glaub ich auch ne Idee.
Kannst du abschätzen wie lange die Umschaltzeit ist?
Die LEDs sollen natürlich einzeln steuerbar sein.
parallel wird wohl nicht klappen, wie soll denn dann ein farbwechsel laufen?

Aber nochmal ne Frage, warum soll man OctoWS2811 nicht auf den DUE portieren können? der DUE kann doch ebenfalls DMA.

Til

Eisebaer:
diese beiden aussagen widersprechen sich. mit 2400 WS2812 kannst Du die werte nur 12mal in einer sekunde ändern. wenn Du jetzt also zb fließend von rot auf blau ändern willst, wird das deutlich "ruckeln".

Wieso sollte das denn Ruckeln? Am Ende ist doch die Zeit für den Farbverlauf entscheidend. Der größte "Abstand" bei einer Grundfarbe sind 256 Schritte (von 0 auf 255), das wäre dann in 21,3 Sekunden zu machen. Bei einer immer noch vertretbaren Schrittweite von 2 kommt man schon auf knapp 10 Sekunden.
Problematisch wird es also erst bei sehr schnellen Farbwechseln, die nicht "springen" sollen.

Der Hinweis mit dem Speicher ist allerdings gut.

hi,

Du hast noch nicht verstanden, wie die WS2811 arbeiten.

man schickt bits an die chips, und zwar in dieser form:
entweder
0,25 mikrosekunden strom ein,
1 mikrosekunde strom aus, das heißt 0.
oder
0,6 mikrosekunden strom ein,
0,65 mikrosekunden strom aus, das heißt 1 (toleranz 150 nanosekunden).

und das muß in Deinem fall ohne pause in einem rutsch für alle 24003 leds passieren. daher auch die berechnung der zeit, die man braucht, um einen streifen mit 2400 rbgLEDs zu beschreiben:
2400
3 * 8Bit * 1,25 mikrosekunden = 72.000 mikrosekunden, also 13,8mal pro sekunde
der arduino läuft mit 16 millionen takten pro sekunde, er muß also alle paar takte den strom ein- oder ausschalten. und mittendrin auch noch die richtigen bits an die richtige stelle weiterschieben. das geht nur, wenn man direkt mit diesen takten arbeitet, und das ist der code, den ich oben reingeschrieben hab.

"            LDI %[bits], 4"    "\n"
"            BRCC L13"	"\n"
"            RJMP L5"	"\n"
"    H1:   NOP"	"\n"
"            NOP"	"\n"
"            OUT %[portout], %[downreg]"	"\n"

manche dieser assemblerbefehle brauchen einen takt, manche mehrere. NOP heißt, daß er einen takt nichts machen soll (sind also reserven da :P).
BRCC und RJMP sind sprungbefehle, mit OUT schreibt er wohl den inhalt eines prozessorregisters in einen bestimmten port(pin).
alleine wegen der unterschiedlichen taktgeschwindigkeit der beiden prozessoren kann man nicht einfach umschreiben. außerdem sind es zwar beides ARM-prozessoren, aber ob der assembler-befehlssatz gleich ist, ist auch nicht sicher.

gruß stefan

Wieso sollte das denn Ruckeln

weil man bei einer frequenz von 13,8 eben ein ruckeln sieht, oder man macht diese wechsel sehr langsam. 10 sekunden für einen farbwechsel sind eben sehr viel, stell Dir als beispiel so ein nightrider-licht vor.

gruß stefan

Hallo Eisbaer,

wieso 16MHz?
Der DUE rennt doch mit 84MHz?
genuegend Zeit die Pins zu wechseln, und wieder zurueckzuschalten, oder?

Til

Nein, genau das eben nicht.
Das Timing muss passen, die Daten müssen an die Kette im 125us-pro-Bit-Rhytmus, ohne Pause bis zum Reset (anzeigen).
Da passt ein umschalten in sauberen Prozessorzyklen kaum, es sei denn, du programmierst das in Assembler selbst.

Mein Ansatz war: Daten komplett an Kette raus, falls möglich Port wechseln, nächste Kette.
Oder eben, wenn die Wechsel immer gleich von links nach rechts gehen, parallel laufende Ketten gleichzeitug versorgen.

Dirk

dischneider:
Ich hab noch immer keine WS bestellt :frowning:

Aber: die Bibliothek kann doch Ports initialisieren, hat das jetzt schon mal jemand getestet?

  FastSPI_LED.setPin(PIN);

FastSPI_LED.init();
  FastSPI_LED.start();




initialisiert das Ganze, also kann der PIN übergeben werden
Was passiert, wenn man im Sketch mit 



FatsSPI_LED.stop();




das ganze beendet und auf einem anderen Port neu initialisiert??

Eventuell noch mit verschiedenen Längen diese anpassen (FastSPI_LED.setLeds).

Das einzige Problem könnte die Verzögerung sein, die dann zwischen den Strängen entsteht, aber ist das ein Problem?

Und @Til: Wenn du deine Beleuchtung zonenabhängig machst, willst du dann die LED einzeln ansprechen können? Ansonsten könnte man ja auch Stränge parallel betreiben?

Dirk

Es ist kein Unterschied ob 3x2400Byte an einen Ausgang verschickt oder diese nacheinander in Teilen an verschiedene Pins. Die Zeit um für 2400 LED die Daten zu senden bleibt fast gleich (die Stückweise Sendung ist etwas langsamer, da das Umschalten und Initialisieren auch Zeit braucht).
Wenn wir jetzt die 2400 LED so gruppieren, daß bei Farbwechseln nur eine Gruppe beteiligt ist, dann ist die Wiederholrate natürlich größer und der Übergang weicher.

Die Ansteuerung der WS2811/12 ist sehr zeitkritisch. Da muß man schon gute Assembler / Maschienensprachekenntnisse haben und das Innenleben des Kontrollers kennen Um das Programm zu schreiben. Ich traue es mir das zB nicht zu.
Die Ansteuerung zB des WS2801 (in einem Anderen aktuellen Tread) ist weniger Zeitkritisch da die Daten mit eimen Takt übergeben werden und die max mögliche Frequenz größer ist.

Wie bereits Vorgeschlagen würde ich einen Teensy3.0 nehmen (da dort bereits Beispiele gibt) oder die LED in Gruppen aufteilen und jeweils von einen ATmega328 oder ATmega2560 ansteuern lassen. Das Programm wird von einem zentralen "Server" übergeben. Da könnte jeder ATmega 328 ca 150 LED ansprechen da so der Speicher für 2 bis 3 Datensätze ausreichend ist und die Wiederholrate bei Farbüberläufen genügend hoch ist. Man muß Zeit für die Datenübertragung und auch die Zeit für die Berechnung der neuen Werte berücksichtigen.

Grüße Uwe

dischneider:
Nein, genau das eben nicht.
Das Timing muss passen, die Daten müssen an die Kette im 125us-pro-Bit-Rhytmus, ohne Pause bis zum Reset (anzeigen).
...
Dirk

Der WS 2811/12 hat eine Zykluszeit von 1,25µS pro Bit im Fast-Modus; der WS2811 auch eine Zykluszeit von 2,5µS im slow Modus.

Grüße Uwe

Ups, da ist mir das Komma verloren gegangen, Uwe entgeht mal wieder nichts.
War ein Test :slight_smile:

uwefed:
Es ist kein Unterschied ob 3x2400Byte an einen Ausgang verschickt oder diese nacheinander in Teilen an verschiedene Pins. Die Zeit um für 2400 LED die Daten zu senden bleibt fast gleich ( die stückweise sendung ist etwas langsamer da das umschalten und initialisieren auch Zeit braucht.
Wenn wir jetzt die 2400 LEd so gruppieren, daß bei Farbwechseln nur eine Gruppe beteiligt ist, dann ist die Wiederholrate natürlich größer und der Übergang weicher.

Das war mir klar, es ging eher um die Möglichkeit einzelne Stränge definiert anzusprechen, um ggf. statische Stränge gar nicht ansprechen zu müssen.

Danke für die Fehlerkorrektur.

Dirk

hi,

wieso 16MHz?
Der DUE rennt doch mit 84MHz?
genuegend Zeit die Pins zu wechseln, und wieder zurueckzuschalten, oder?

Du hast keine library für den DUE !!!

bei der library für den teensy gibt es kein umschalten.

außerdem war das nur ein beispiel, um Dir zu erklären, wie die WS2811 arbeiten und welche zeitprobleme es gibt. auf das umschalten bin ich nirgends eingegangen. was das umschalten bringen könnte, wäre, speicherplatz zu sparen. dafür hat man auch nirgends den istzustand gespeichert. muß aber auch nicht unbedingt sein.

ansonsten kommt es darauf an, was man mit den LEDs zeigen will.
langsame farbübergänge sind mit dem teensy möglich, aber um als beispiel ein knight-rider-licht einmal um den raum laufen zu lassen, geht eben nicht. bei diesem beispiel wird jede led innerhalb nicht mal einer sekunde von 0 auf 100% und wieder zurück gesetzt. das geht nicht in vertretbaren schritten mit 2400 LEDs, die von einer zentralen stelle gesteuert werden, egal ob das ein UNO, ein DUE oder ein cray-supercomputer ist.

ich sehe nicht viele möglichkeiten. mit einem UNO kannst Du, sagen wir mal, 500 LEDs steuern, dann geht Dir der speicher bald aus. also jeder raumteil mit zwei UNOs, aber dann wird die programmierung für ein solches knightrider-licht in einem solchen raumteil sehr unkomfortabel.

oder ein ATmega1284P für jeden raumteil, gesteuert von einem zentralen uno, am besten mit ethenet-shield, dann kannst Du alles vom handy/tablet/computer aus steuern

gruß stefan

hi,

die LED in Gruppen aufteilen und jeweils von einen ATmega328 oder ATmega2560 ansteuern lassen. Das Programm wird von einem zentralen "Server" übergeben. Da könnte jeder ATmega 328 ca 150 LED ansprechen da so der Speicher für 2 bis 3 Datensätze ausreichend ist

vernünftige aussage.
nur die 150 seh' ich als zu niedrig an. jede rgbLED braucht 3 Byte, also sollten 400 doch leicht machbar sein. ein ATmega1284P mit 16k speicher für 800 LEDs geht sicher. und mit 800 LEDs hat man eine wiederholrate von sagen wir mal 30fpS, weil rechnen will der microconroller ja auch.

gruß stefan

dischneider:
War ein Test :slight_smile:

Das zieht bei mir nicht. :wink: :wink: :wink: Ein italienische Politiker windet sich auch immer aus den Fettnäpfchen indem er sagt, man habe ihn falsch verstanden oder falsch zitiert oder es war gar nicht so gemeint. ]:smiley: ]:smiley: ]:smiley: Wenn ich mich so recht erinnere hat er nie gesagt, daß er eigentlich gar nicht da war.

Grüße Uwe

Eisebaer:
...
ich sehe nicht viele möglichkeiten. mit einem UNO kannst Du, sagen wir mal, 500 LEDs steuern, dann geht Dir der speicher bald aus. also jeder raumteil mit zwei UNOs, aber dann wird die programmierung für ein solches knightrider-licht in einem solchen raumteil sehr unkomfortabel.

oder ein ATmega1284P für jeden raumteil, gesteuert von einem zentralen uno, am besten mit ethenet-shield, dann kannst Du alles vom handy/tablet/computer aus steuern

gruß stefan

500 LED sehe ich für den Arduino UNO schon zuviel, da die Daten dafür satte 1500Byte sind. Bei 2048 Byte RAM des UNO ist da nicht mehr viel Platz für anderes. Da muß mann schon mit allen kniffen Programmieren und RAMverwendung extrem sparen.

Meine Wahl der max LED basiert auf folgender Überlegung:
*Bildwiederholrate über 25-30 /sec.
*Berechnung der Werte zB dimmen von 1 Farbe von 0 auf 255 oder Farbüberläufe mit neuen Werten aller 3 Farben zwischen 2 Datenübertragungen.(150 bis 450 Berechnungen)
*Übertragung der Daten von SD-Karte oder von Master zwischen 2 "Bildern"
*Speicherplatz für 2 Abbilder.
*Speicherverbrauch unter 1kByte RAM. 2x 3x150Byte = 900 Byte RAM
Ok, es könnten auch 200 LED sein. (600 Byte pro Satz) aber da wirds mit dem RAM in Arduino UNO knapp.

Grüße Uwe

hi,

uwe, ich hab' noch nie mit "abbildern" gearbeitet, deswegen rechne ich nur einen satz von 3 byte pro rgbLED, eben das struct CRBG. "bilder" braucht man meiner meinung nach nicht bei streifen rund ums zimmer, normales licht in jeder farbe und helligkeit geht ohne, effekte werden auch erst zur laufzeit berechnet. auch eine SD-karte ist dann nicht nötig.

der uno "in der mitte" soll ja auch nichts für die satelliten berechnen, sondern nur sagen,welches ihrer "programme" sie ausführen sollen und in welchen farben. berechnen müssen sie dann selber.

aber egal wie, ein ATmega1284P mit 16k ist auf jeden fall besser, doppelt soviel RAM wie ein mega2560. damit reicht einer für jeden raumteil.

gruß stefan

Eisebaer:
am günstigsten hab' ich's hier gefunden:

http://www.ebay.de/itm/Teensy-3-0-USB-Entwicklungs-Board-32bit-ARM-Cortex-M4-MK20DX128VLH-Original-PJRC-/261116450779?pt=Wissenschaftliche_Geräte&hash=item3ccbc0d7db

Bei Watterott bekommst Du den Teensy 3 schon für 18 Euro.

Hallo Stefan
Als Bild oder Abbild meinte ich die vorberechneten oder vom Server übertragenen Daten die vom Arduino oder ATmega in einem Rutsch an die LED-Strippe übertragen werden. Die einzige Möglichkeit um keine vorberechneten Daten zu brauchen ist alle LED einer Strippe mit dem gleichen Wert anzusteuern.Für eine Bedingung das x-te LED

Speicherkarten haben den Vorteil, daß die Daten nicht berechnet werden müssen und auch komplizierte Muster, die zu aufwändig zum Berechnen sind, dargesellt werden können. Ist ja nur eine der möglichen Optionen.

Grüße Uwe

Hey,

vielen vielen Dank für die ganzen Infos. Ich wollte euch damit echt nicht nerven.
Ich bin Informatiker und kein Nachrichtentechniker.
Habe bis jetzt auf jeden Fall schon viel gelernt. thx a lot

Wenn ich das Ganze mal zusammenfasse - so wie ich es verstanden habe - ist folgendes die beste Möglichkeit:

  • Ein zentraller "Server" (am liebsten den Due, denn den hab ich schon bestellt)
  • der berechnet das gesamte "Bild"
  • teilt das "Bild" in die Abschnitte und schickt es an die "Slaves"
  • Drei Slaves Typ "ATmega1284P" für jeden Abschnitt
  • jeder Slave bekommt sein Bild und "pushed" es bei einem gemeinsamen Signal an die Strips
  • Die Übertragung des Teilbildes an den Strip muss fix mit 800kHz erfolgen
  • Die Übertragung des Teilbildes an die Slaves muss mit mindestes 2.4MHz erfolgen, da ja 3 Teilbilder verschickt werden
  • Das Sync Signal muss vom "Server" kommen und 30 Hz betragen.
  • das gemeinsame Sync-Signal darf nur die "Slaves" erreichen, die eine Änderung des Teilbildes haben, Strips die nicht verändert werden behalten so die vorherige Einstellung bei.

Ist das so richtig?

Til

Nachtrag:
Habe gerade mal den größten Abschnitt berechnet.
Dieser ist 12.4m lang, also runt 740 LEDs.
Das liegt ja dann unter den 1000 LEDs und müsste mit 30fps zu machen sein.
Oder?