WS2812 Ansteuerung

[Marcel K. (viewer)]

Hallo Forum Gemeinde,

ich möchte mich im Moment mit dem WS2812 beschäftigen.

Ich habe bereits einiges darüber gelesen. Sowohl hier auf einigen Seiten 
als auch sonst im Internet. Da sind bereits echt gute Informationen 
zusammen gekommen.

Auch gibt es sehr viele Codebeispiele. Dennoch würde ich nur ungerne 
Code von anderen verwenden weil ich es gerne selber machen möchte. Ich 
habe schon einige Ansteuerungsversuche gemacht. Ganz einfach per 
Bitbanging, per SPI und auch per PWM. (Mein Controller läuft mit 48MHz / 
zum Testen habe ich eine 8x8 LED Matrix mit WS2812B LED’s)
So richtig sauber funktioniert es allerdings noch nicht.

Des Weiteren habe ich ein 5m RGB Band aus dem Baumarkt an dem ich mit 
dem Oszilloskop mitmessen kann. Ich vermute, dass auf dem Band der 
TM1829 verbaut ist.

Ich habe da einige Fragen die mir nicht ganz klar sind, die aber für den 
einen oder anderen bestimmt simpel zu beantworten sind.

Als erstes habe ich gedacht, dass der Ruhepegel des Digitalpins des 
Controller auf LOW liegen sollte, da die Pulse ja mit einem High- Signal 
anfangen. Dann ist mir beim nachmessen des RGB Bands aus dem Baumarkt 
aufgefallen, dass der Ruhepegel auf high liegt. Wenn man das Band 
einschaltet dann wechselt der Datenpin auf LOW und die Datenübertragung 
beginnt dann nach ca. 13ms. Wenn man das Reset- Signal laut Datenblatt 
betrachtet, dann macht es durchaus auch Sinn dass der Ruhepegel auf High 
liegt, denn nur so kann der LED Chip auch ein Reset erkennen. Liege ich 
mit der Vermutung richtig? Wie macht ihr das?

Wenn wir schon beim Reset sind habe ich da noch eine Frage. Wird der 
Reset nach jeder LED gesendet oder erst zum Schluss, wenn man alle Daten 
bis zur letzten LED geschoben hat? Von der Logik her vermute ich zum 
Schluss, da die Daten ja seriell durch alle LED’s geschoben werden. Wenn 
der Controller fertig ist, wird ja nicht mehr durchgeschoben und dann 
erkennen die LED- Chips dieses Ende weil nichts weiter durchgeschoben 
wird. Lieg ich auch hier mit meiner Vermutung richtig?

Hier auf der Webseite:

https://www.mikrocontroller.net/part/WS2812B

Ist ja das Datenblatt hinterlegt. Auf der 4. Seite, unter Data 
Transmission Mode wird von „Data refresh cycle 1“ und „Data refresh 
cycle2“ gesprochen. Was ist denn damit gemeint? Mit „Refresh“ verstehe 
ich erst mal, dass man das Signal „refreshen“, also wiederholen möchte. 
Sollte das gleiche Signal immer wieder wiederholt werden? Oder soll das 
Bild lediglich zeigen, dass zwischen dem ersten Frame für die LED’s und 
dem zweiten Frame immer ein Reset folgen muss?

Mit ist bei dem Baumarkt- RGB Band aufgefallen, dass obwohl die LED’s 
alle still stehen, weiterhin Daten an das Band geschickt werden. 
Zwischen zwei Frames für das Band liegen ca. 280ms. Wie macht ihr das? 
Schickt ihr die Farben für die LED’s durch das Band und hört dann auf 
oder sendet ihr ebenfalls zyklisch weiter? Dies würde ja eventuelle 
einzelne Bitfehler an einer LED wieder korrigieren.

Ich würde mich über ein paar Antworten sehr freuen!

Viele Grüße und ein schönes Wochenende,
Marcel

[Der Zahn der Zeit (Gast)]

Hallo Marcel,

ich will die (jetzt noch) nicht komplett antworten, zumal ich selber mit 
der 2812 erst in Zukunft was zu tun haben werde (an einen MSP430).

Aber ein Tipp vielleicht: Das genannte Datenblatt ist überholt, es gibt 
ein neues. Die Ansteuerung soll sich irgendwie etwas geändert haben, so 
dass es nach dem alten Datenblatt evtl. nicht geht, hat man mir 
berichtet. Ich habe die Datenblätter aber nicht verglichen.

Data Refresh Cycle 1 / 2 ist da nicht zu finden.

Reset, also Data für > 280 µs low, sorgt dafür, dass die Daten in den 
Registern zur Ausgabe übernommen werden. Also muss in Ruhe die 
Data-Leitung low sein.

Viel Erfolg! DZDZ

[Marcel K. (viewer)]

Hallo DZDZ :),

erst mal vielen Dank für deine Info! Das sind ja ganz neu Angaben und 
sicherlich sehr wichtig!!!!

Sei mir nicht böse wenn ich so nachfrage. Ich habe es jetzt schon 
verstanden, dass ich für einen Reset die Data- Leitung für ">280µs" auf 
LOW- ziehen, bzw. lassen muss. In diesem Fall werden die Daten im Chip 
als Latch erkannt und die Werte an die LEDs ausgegeben. ABER...! Nach 
jeder LED oder erst am Ende der Übertragung? Ich vermute ja am Ende der 
Übertragung!
(das scheint jedem außer mir klar zu sein ;o) )

Viele Grüße,
Marcel

[Markus M. (adrock)]

Nein, der normale Zustand bevor das erste Bit gesendet wird ist LOW.

Dann werden die Bits wie beschrieben gesendet - für ALLE LEDs in der 
Kette ohne weitere Pause dazwischen - und nach dem letzten Bit der 
letzten LED lässt man das Signal auf LOW mindestens für die Resetzeit 
(bei WS2812b mit >= 50µs angegeben).

Man lässt es auf LOW bis die nächste Übertragung beginnt.

So hat es zumindest bei mir immer funktioniert.

[Marcel K. (viewer)]

Hi Markus M.,

vielen Dank für deine Antwort.
Ich habe es also richtig verstanden und bin froh, dass du es mir jetzt 
so deutlich bestätigt bzw. erklärt hast. Jetzt ist es auch endlich mir 
klar wie es sein muss!

Danke noch Mal und viele Grüße :o)

[Markus M. (adrock)]

...falls es immer noch kleine Fehler gibt und der Controller mit 3,3V 
läuft, müsste man mal checken ob evtl. ein Pegelkonverter 3,3V -> 5V für 
den Datenausgang Abhilfe bringt.

Was für ein Controller ist es denn?

[Thomas E. (picalic)]

Servus,

hier: 
https://learn.adafruit.com/adafruit-neopixel-uberguide/best-practices

gibt es auch noch ein paar praktische Hinweise.

Beim Timing ist es ggf. nützlich zu wissen, worauf es tatsächlich 
ankommt. Wichtig ist die High-Impulslänge für die Unterscheidung 
zwischen 1- und 0-Bits und der Abstand der High-Flanken. Bei letzterem 
kommt es darauf an, daß die maximale Datenrate nicht überschritten wird 
(d.h. Abstand der H-Flanken >= 1,25µs) und daß der Abstand nicht größer 
wird, als ein paar µs (< 6 µs sollte ok sein), weil sonst die Gefahr 
besteht, daß die LED das als Ende der Übertragung interpretiert.
Die High-Impulse für 1-Bits dürfen auch länger sein, als im Datenblatt 
angegeben. Am Ausgang der LED wird die Länge des High-Impulses durch die 
LED bestimmt und ist von der Länge des Eingangsimpulses unabhängig. Ein 
Dauer-High am Eingang der ersten LED verhindert zwar den "Reset" der 
ersten LED, aber da am Ausgang der LED wieder ein kurzer Impuls 
herauskommt, kann man die Übertragung für die ganze LED-Kette damit 
nicht pausieren.

[Marcel K. (viewer)]

Hallo zusammen,

@Markus M.
Hmmm, ja ich betreibe meinen SAMD20 mit 3,3V. Mal sehen wie ich das mit 
einem Pegelwandler hinbekomme. Das würde ich schon noch mal 
ausprobieren!
Laut dem Datenblatt welcher "Der Zahn der Zeit" hochgeladen hat, müsste 
ich mit 3,3V unterhalb der im Datenblatt stehenden Spezifikation liegen. 
Meine 8x8 LED Matrix wird mit einem 5V Netzteil versorgt(Genau 5,22V). 
Laut Datenblatt muss für ein High Level 0,7xVdd, also 3,5V verwendet 
werden. Komischerweiße ist der Ruhe- High Level des Controllerpins bei 
3,3V die Pulse an die LED’s allerdings 3,69V. Dies hat mir zumindest 
mein Oszilloskop gemessen. Etwas merkwürdig und da muss ich mal genauer 
hin schauen.

@Thomas Elger
Danke für deine Nachricht und Erklärung. Den Link kannte ich noch nicht!
Ich interpretiere das jetzt so… Pausen > 6µs könnten zwischen den High- 
Flanken als einen Reset erkannt werden. Sobald eine High- Flanke länger 
ist wie die einer Null- Flanke, wird es als eine Eins erkannt. Daher ist 
vermutlich nicht so kritisch wenn das High- Signal einer "1" länger 
dauert wie im Datenblatt.

Für mein Verständnis sieht mein Signal eigentlich ganz gut aus!
Ich habe mal ein einzelnes Frame an eine LED aufgezeichnet und gemessen.
Ein "0"- High Pegel dauert ca. 346ns. Der Ganze "0" Puls  1,6µs. Ein 
"1"- High Pegel dauert ca. 870ns und der ganze Puls 1,9µs. Die Pause 
zwischen der Farbe Grün und Rot bzw. Rot zu Blau ist ca. 2µs lang. Das 
müsste alles im Rahmen liegen.
Oder sehe ich das falsch?

Es ist nicht so, dass sich gar nicht tut. Mal wird es richtig angezeigt 
wie ich es sende. Manchmal seh ich auch gar nichts.

Viele Grüße und einen guten Wochenstart,
Marcel

[Daniel_S (Gast)]

Hi,

Bzgl. Pegelwandler: Sind die Pins an deinem Controller 5V-Tolerant? Dann 
ist die einfachste Möglichkeit, den Ausgang als Open Drain / Open 
Collector zu konfigurieren und die 5V mittels Pull-up zu erzeugen. So 
habe ich es erfolgreich zumindest an einem STM32-Controller getestet.

Zu deinen Zeiten:
Dein High-Puls (und die Zeiten zwischen den Farben) sind zumindest schon 
mal außerhalb der Spezifikationen im Datenblatt. Kann funktionieren, 
muss nicht.

Weitere Mögliche Ursache für "tut mal; mal auch nicht": Gibt es in 
deinem Programm evtl. noch Interrupts, die dir dein Timing zerstören?

Gruß Daniel

[Thomas E. (picalic)]

Hallo Marcel,

Marcel K. schrieb:
> Komischerweiße ist der Ruhe- High Level des Controllerpins bei
> 3,3V die Pulse an die LED’s allerdings 3,69V. Dies hat mir zumindest
> mein Oszilloskop gemessen. Etwas merkwürdig und da muss ich mal genauer
> hin schauen.

kann eigentlich nicht sein, außer, wenn es da irgendwo noch einen 
Pull-Up nach 5V gibt. Das könnte dann aber ein Problem für den 
µC-Ausgang sein!
Deine Signale sehen sehr verschliffen aus - als gäbe es da noch einen 
Kondensator mit ein paar Nanofarad an der Signalleitung!? Das sind ja 
eher Lade-/Entladekurven, als ordentliche, digitale Flanken.
Wenn das Signal wirklich an der LED so ankommt (vielleicht durch ein 
langes Kabel?), wäre als Pegelwandler evtl. ein Baustein mit 
Schmitt-Trigger Eingang sinnvoll.

Gruß,

Thomas

[Der Zahn der Zeit (Gast)]

Jetzt habe ich aber Glück gehabt. Ich schrieb, dass ich auch demnächst 
die WS2812 in Betrieb nehmen will. Das Layout ist fertig, aber die 
Bestellung hat sich verzögert, und nun muss ich hier lesen, dass ich 
(Voll-Honk, denn eigentlich weiß ich das) auch den Treiber zwischen 3,3 
V-µC und 5 V-LED vergessen habe. Ein 74HCT1G04 wird es werden. Nur ein 
IC im SOT23-5-Gehäuse, nicht mehr.

DZDZ

[Wolfgang (Gast)]

Thomas E. schrieb:
> und daß der Abstand nicht größer wird, als ein paar µs
> (< 6 µs sollte ok sein), weil sonst die Gefahr besteht, daß
> die LED das als Ende der Übertragung interpretiert.

Woher hat du diese Zahl?
Im Datenblatt des WS2812 wird als Grenze für Reset-Erkennung (t_reset) 
ein Wert von t>50us angegeben.
https://cdn-shop.adafruit.com/datasheets/WS2812.pdf

[c-hater (Gast)]

Wolfgang schrieb:

> Woher hat du diese Zahl?

Vermutlich hat er einfach mal nachgedacht und vielleicht sogar ein wenig 
experimentiert...

> Im Datenblatt des WS2812 wird als Grenze für Reset-Erkennung (t_reset)
> ein Wert von t>50us angegeben.
> https://cdn-shop.adafruit.com/datasheets/WS2812.pdf

Genau. Erst mit einem Impuls dieser Dauer ist auch für eine Kette von 
1024 LEDs sichergestellt, dass alle LEDs  den Reset sicher erkennen 
können, auch die letzte der Kette. Und wenn man jetzt mal sein Augenmerk 
auf eben diese letzte LED der Kette richtet: Wie lange mag wohl aus 
deren Sicht der Resetpegel anliegen, wenn er vorne an der ersten 50µs 
lang ist?

Klingelt's jetzt auch bei dir?

[Marcel K. (viewer)]

Hallo zusammen,

ich bin noch dabei die Vorschläge von allen zu berücksichtigen kann aber 
noch nichts Genaues sagen.

Aber auf deine Nachricht [Wolfgang (Gast)] wollte ich kurz eingehen.


Ich habe einiges Interessantes dazu bereits im Internet gefunden.

Zum Beispiel hier auf den hiesigen Seiten unter:

https://www.mikrocontroller.net/articles/WS2812_Ansteuerung

Wenn du auch etwas Englisch kannst, stehen auch hier ein paar nützliche 
Infos darüber:

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/


Interessant ist auch eine Seite die in die Richtung geht, was der 
„Thomas Elger“ bereits vor einigen Einträgen geschrieben hat, dass es 
eher um die Unterschiede von den High- Impulslängen geht:

https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

Wie du also siehst, sind diese 50µs nur theoretisch richtig. Ansonsten 
solltest du wirklich darauf achten, dass die Pausen immer <6µs sind weil 
sonst wird eine längere Pause als Reset betrachtet!

Ich hoffe ich konnte dir helfen!

Grüße,
Marcel

[Peter (Gast)]

Zum Levelshifter wollte ich noch folgende Idee beitragen (habs aber noch 
nie ausprobiert).
In die Versorgung der ersten LED wird eine Diode geschaltet, um die 
Spannung so weit zu reduzieren, dass auch 3.3V als High erkannt wird. 
Sie leuchtet dann auch ein wenig dunkler.

https://hackaday.com/2017/01/20/cheating-at-5v-ws2812-control-to-use-a-3-3v-data-line/

[Marcel K. (viewer)]

Hallo Peter,

das ist ja mal eine coole Idee!
Danke für den Link!
Natürlich schwierig, falls man ein LED Band betreibt. Dann bräuchte man 
eine "Opfer LED" ;o)

Ich sehe jetzt allerdings keinen Grund weshalb das nicht funktionieren 
sollte!
Bestimmt nützlich für den einen oder anderen.

Grüße,
Marcel

[Thomas E. (picalic)]

Marcel K. schrieb:
> Natürlich schwierig, falls man ein LED Band betreibt. Dann bräuchte man
> eine "Opfer LED" ;o)

Naja, dann kann man auch gleich das "richtige" Bauteil opfern (z.B. 
einen 74HC1G_irgendwas). Ok, manchmal will man etwas fertigkriegen und 
nicht erst Bauteile bestellen, dann wäre das mit der Opfer-LED 
tatsächlich eine sinnvolle Option.

Wolfgang schrieb:
> Woher hat du diese Zahl?

Habe zwar auch selbst experimentiert, aber der Ursprung für meine 
Aussagen ist hier im Wesentlichen der bereits von Marcel gepostete Link:
https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

c-hater schrieb:
> Wie lange mag wohl aus
> deren Sicht der Resetpegel anliegen, wenn er vorne an der ersten 50µs
> lang ist?

Ich würde mal annehmen, daß die Länge der LED-Kette dafür keine 
nennenswerte Rolle spielt - schließlich ist die Durchlaufzeit pro LED 
immer gleich. Die Reset-Pause wird also genauso lang verzögert, wie die 
Datenimpulse und die Impulsabstände sind am Ende ziemlich gleich, egal, 
ob die Kette 10 oder 1000 LEDs lang ist.

[Ralf G. (ralg)]

c-hater schrieb:
> Wie lange mag wohl aus
> deren Sicht der Resetpegel anliegen, wenn er vorne an der ersten 50µs
> lang ist?

mind. 30µ
> Klingelt's jetzt auch bei dir?

[Der Zahn der Zeit (Gast)]

Thomas E. schrieb:
> Naja, dann kann man auch gleich das "richtige" Bauteil opfern (z.B.
> einen 74HC1G_irgendwas).

Nicht HC, sondern HCT, sonst kommt man von Regen in die Traufe. Bei mir 
wird es ein 74HCT1G04 werden.

[Thomas E. (picalic)]

Der Zahn der Zeit schrieb:
> Nicht HC, sondern HCT, sonst kommt man von Regen in die Traufe. Bei mir
> wird es ein 74HCT1G04 werden.

Ist natürlich richtig! Danke :)

Beim '04 sollte man im Auge behalten, daß der das Signal nicht nur auf 
einen anderen Level hebt, sondern auch invertiert!

[Klaus (Gast)]

Der Zahn der Zeit schrieb:
> Nicht HC, sondern HCT,

HC14 tuts, Schmitt am Eingang reicht. Da ich den Treiber nicht selbst 
gemacht habe, hat ein zweiter die Polarität des Signals in ordnung 
gebracht.

MfG Klaus

[Wolfgang (Gast)]

Marcel K. schrieb:
> 
https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

Schöne Messungen zum Verhalten der WS2812x. Damit wäre also klar, dass 
bei dem vermessenen WS2812 ein Low-Pegel von 8.95 µs zum Auslösen eines 
Resets ausreicht. In einem vernünftigen Datenblatt hätte man dazu dann 
gerne eine Zeitangabe, die eine Aussage darüber trifft, wie lang der 
Low-Pegel sein darf, damit er garantiert noch keinen Reset auslöst.

c-hater schrieb:
> Genau. Erst mit einem Impuls dieser Dauer ist auch für eine Kette von
> 1024 LEDs sichergestellt, dass alle LEDs  den Reset sicher erkennen
> können, auch die letzte der Kette. Und wenn man jetzt mal sein Augenmerk
> auf eben diese letzte LED der Kette richtet: Wie lange mag wohl aus
> deren Sicht der Resetpegel anliegen, wenn er vorne an der ersten 50µs
> lang ist?

Woher bitte soll das Datenblatt einer einzelnen WS2812 wissen, ob die 
Kette aus 1024 oder aus 1025 Chips besteht?

[c-hater (Gast)]

Wolfgang schrieb:

> Woher bitte soll das Datenblatt einer einzelnen WS2812 wissen, ob die
> Kette aus 1024 oder aus 1025 Chips besteht?

Das weiss das DB. Die erlaubte Maximallänge der Kette von 1024 steht 
nämlich drinne, 1025 ist also nicht möglich (bzw. zumindest nicht von 
diesem DB spezifiziert)

Was es natürlich nicht weiss, ist die tatsächliche Länge der Kette, es 
kennt nur diese Obergrenze. Deswegen sind alle Angaben zum Timing sind 
eben so gestaltet, dass auch eine Kette dieser Länge noch sicher 
funktionieren kann.

Es ist also, genau genommen, kein Datenblatt zu einer einzelnen WS2812, 
sondern ein Datenblatt zum "System WS2812".

[Thomas E. (picalic)]

c-hater schrieb:
> Das weiss das DB. Die erlaubte Maximallänge der Kette von 1024 steht
> nämlich drinne, 1025 ist also nicht möglich (bzw. zumindest nicht von
> diesem DB spezifiziert)

Ich sehe im DB überhaupt keine maximale Länge der Kette spezifiziert - 
woher habt ihr das denn?

[Marcel K. (viewer)]

Hallo zusammen,

also hier mal ein kurzer Zwischenbericht :o)

@Thomas Elger
Du hattest Recht. Es gab da noch einen Baustein. Ich hatte hinter dem 
Controller Ausgang ein NAND- Gatter. Das war das einzige was ich hatte 
um das Signal zu invertieren. Ich wollte unbedingt das Signal 
invertieren, weil ich unter anderem auch Versuche mit dem SPI Interface 
gemacht habe. Beim SPI lässt sich der Ruhe Pegel nicht ändern und ist 
nach der Initialisierung der Schnittstelle immer High. Mit dem NAND (ein 
Pin gegen Vcc) hatte ich dann das Signal invertiert und somit dann 
richtig für die Ansteuerung.

Ich habe jetzt das reine Signal, ohne Schutzbeschaltung direkt an die 
LED Matrix angeschlossen. Ich habe auch die timings mal nach dem 
Datenblatt von „Der Zahn der Zeit“ angewendet. Und siehe da es hat jetzt 
funktioniert.

Dann war ja noch der Spannungswert im Raum gestanden. Der Pegel soll ja 
0,7VxVcc der WS2812 sein. Das Problem ließ sich ganz leicht lösen. Ich 
habe die Versorgungsspannung der LED Matrix von 5V auf 4,5V erniedrigt. 
Somit reichten die 3,3V aus und mit 4,5V lag die Spannung für die WS2812 
noch im grünen Bereich.
Nachdem allerdings die Flanken jetzt deutlich sauberer waren, habe ich 
auch die Spannung wieder auf 5V zurück erhöht und es funktionierte 
trotzdem noch. Ich weiß das ist außerhalb der Spezifikation aber es hat 
halt funktioniert.

Ich werde das Ganze aber noch mal mit einem invertierenden Schmitt 
Trigger versuchen da ich den Weg über die SPI Schnittstelle gerne noch 
mal probieren möchte.

@Daniel_S
Nein die Pins des Controllers sind leider nicht 5V Tolerant. Um auf die 
5V zu kommen werde ich, wie bereits schon mehrmals in diesem Beitrag 
vorgeschlagen :), mit einem Schmitt- Trigger realisieren.

nochmal @Thomas Elger
Ich bin Deiner Meinung. Es ist lediglich bei einer Angabe von 30 fps 
erwähnt, dass es nicht mehr als 1024 LED’s sein sollen. Wenn man auf die 
30 fps verzichten kann, geht da sicherlich deutlich mehr! 30fps (Frames 
per Second) wäre bei bewegten Bildern wichtig.

Auf dieser Seite:
https://hackaday.com/2014/01/02/controlling-ten-thousand-rgb-leds/

ist von fast 10.000 LED’s die Rede. (OK, es wurde lediglich simuliert ;) 
)

Ich gebe noch Mal Bescheid wenn ich das mit der SPI Schnittstelle noch 
probiert habe.

Bis dahin viele Grüße und danke für die rege Anteilnahme in diesem 
Thread.
Marcel

[Marcel K. (viewer)]

Sorry, die Bilder vergessen....
(die ließen sich nicht über "Bearbeiten" neu Anhängen!)

Zu den Bilder, die Pause zwischen den Farben ist immer noch länger aber 
bisher geht es so. Mal sehen wie lange und ob ich da noch etwas 
"Nachjustieren" muss!

Marcel

[Thomas E. (picalic)]

c-hater schrieb:
> Und wenn man jetzt mal sein Augenmerk
> auf eben diese letzte LED der Kette richtet: Wie lange mag wohl aus
> deren Sicht der Resetpegel anliegen, wenn er vorne an der ersten 50µs
> lang ist?

Um da auch nochmal eine Antwort zu geben: bei einer Kette aus 1024 
WS2812 liegt an der letzten LED der Reset-Lowpegel etwa um 30,7 ms 
länger an, als an der ersten LED.

[Ralf G. (ralg)]

Thomas E. schrieb:
> bei einer Kette aus 1024
> WS2812 liegt an der letzten LED der Reset-Lowpegel etwa um 30,7 ms
> länger an, als an der ersten LED.

Denkfehler!
Oder Komma falsch gesetzt (wie ich oben):
Ralf G. schrieb:
> mind. 30µ
später (hab' ich glatt vergessen, und die '0').

Die Verzögerung bei der Weiterleitung der Daten beträgt lt. Datenblatt 
max. 300ns(*). Die erste LED empfängt Daten, kassiert die für sich ein, 
leitet die nächsten weiter. Die zweite empfängt ihre Daten einfach nur 
300ns später. Jetzt kommen ständig Daten vorbei, bis auch die letzte in 
der Kette dran ist. Bei 1024 LEDs sind das 1024 x 300ns Verzögerung! 
Bauteiltoleranzen vernachlässigt, läuft jetzt einfach der Reset von der 
ersten zur letzten LED im Abstand von 300ns durch. Die letzte LED macht 
ihren Reset ~300µs später als die erste, sie hat allerdings auch ihre 
Daten ~300µs später erhalten!

Die Anzahl der LEDs ist eigentlich nur dann begrenzt, wenn gedimmt 
werden soll oder die Teile als Videowand verschaltet sind. Dann muss man 
die im Datenblatt genannten 400Hz berücksichtigen(**).

(*)  transmission delay time - so würde ich das interpretieren
(**) high speed mode not less than 1024 points

[Thomas E. (picalic)]

Ralf G. schrieb:
> Denkfehler!

Ich denke nicht:
Die Übertragung der Daten für 1024 LEDs dauert 1024 * 30µs = 30,7ms. 
Während dieser ganzen Zeit kommt bei der letzten LED nichts an, weil nur 
die letzten 3 Bytes bei der letzten LED ankommen - auf deren 
Datenleitung herrscht also min. 30,7 ms Ruhe = Reset-Status!

[Ralf G. (ralg)]

Thomas E. schrieb:
> 30,7 ms Ruhe = Reset-Status!

Würde ich jetzt nicht so bezeichnen. Das ist einfach die ganz normale 
Pause, bis irgendwann mal wieder was Neues angezeigt wird. Wie lange 
sich da auf der Datenleitung nichts tut, wäre mir egal. Reset ist 
m.M.n. nur der Zeitpunkt/ die kurze Zeit der Datenübernahme zur Anzeige.

[Thomas E. (picalic)]

Um wieviel später die Daten bei der letzten LED ankommen, war aber gar 
nicht das Thema - es ging eindeutig darum, welche Länge des 50µs langen 
Low-Pegels nach 1024 LEDs noch bei der letzten LED ankommt. Man könnte 
ja meinen, die Chinesen hätten die 50µs Mindestlänge für den 
Reset-Impuls deshalb so großzügig spezifiziert (wenn schon viel kürzer 
reicht), damit es auch bei längeren LED-Ketten funktioniert. Das kann 
aber eben so nicht sein, weil bei längeren LED-Ketten der Reset-Impuls 
für die LEDs weiter hinten in der Kette immer länger wird.

[Ralf G. (ralg)]

Thomas E. schrieb:
> herrscht also min. 30,7 ms Ruhe

Dafür hat bei der ersten LED aber auch 30,7ms 'Ruhe geherrscht' bis die 
letzte LED ihre Daten erstmal empfangen hat.

[Thomas E. (picalic)]

Ralf G. schrieb:
> Dafür hat bei der ersten LED aber auch 30,7ms 'Ruhe geherrscht' bis die
> letzte LED ihre Daten erstmal empfangen hat.

Nein, wenn man z.B. mit 30 FPS an 1024 LEDs übertragen will, gibt es an 
der ersten LED höchstens 2,6 ms Pause.

[Ralf G. (ralg)]

Aaah, du meinst eine kontinuierliche Datenübertragung mit - im besten 
Falle - nur einer 'Reset-Pause' zwischen den Frames. Ja, da muss die 
erste LED jede Menge Daten anfassen und weiterleiten und die letzte LED 
in der Kette macht sich derweil einen Gemütlichen. Der Reset-Impuls/ 
Befehl zur Datenübernahme kommt trotzdem ~50µs(*) nach dem Empfang der 
eigenen Daten bei jeder LED. Und der wandert sozusagen (gleichmäßig) von 
der ersten zur letzten LED durch.

(*) lt. Datenblatt

[Marcel K. (viewer)]

Hallo ihr Mitleser,

wie versprochen, wollte ich noch kurz über die Verwendung der SPI 
Schnittstelle berichten.

Ich habe jetzt einen invertierenden Schmitt- Trigger hinter dem MOSI Pin 
platziert. Der Grund ist wie schon erwähnt, dass der Ruhepegel von MOSI 
High ist. Das ist für die Ansteuerung der WS2812 eher ungünstig :o) Das 
klappt so aber absolut ohne Probleme.

Ich habe die Senderoutine auf das Senden von 8 Bit runtergebrochen und 
mit einem übergebenen Countwert wird so lange von einem Pointer gelesen, 
bis der Counter "0" ist[while(cycles--)]. Also ganz unabhängig davon, 
wie viele LED’s nun wirklich angesteuert, sondern wie viele Bytes 
übertragen werden sollen.

Was nicht schlecht ist, ich habe auch eine 1x8 LED Matrix mit SK6812 
LED’s. Dies sind RGBW-LED’s und haben somit 32bit um die Farben 
einzustellen. Das heißt die "Basic- function" wird einfach pro LED 
einmal mehr aufgerufen. (Naja, das muss ich ja nicht wirklich erklären 
wie ich das mache). Auch das funktioniert einwandfrei!

Auf jeden Fall bin ich happy das jetzt alles funktioniert und auch 
absolut zuverlässig ohne irgendwelche Fehler. Zumindest bei den 64 
LED’s. Ich bin völlig fasziniert wie man in mitten der ganzen LED's nur 
eine einzige verändern kann. Echt ne coole Sache!

Wenn ich mir jetzt meinen Code anschaue dann sind es echt nur wenige 
Zeilen Code und letztendlich das gleiche wie man hier so im Netz an 
Codebeispielen findet :o)

Aber durch das, dass ich den Code nicht einfach nur kopiert sondern 
selber versucht habe, habe ich einiges (dank euch) dazu gelernt und man 
freut sich umso mehr, wenn es dann endlich funktioniert.

Leider habe ich bisher noch keinen Anwendungsfall für mich. Es war eher 
die Lust an der Aufgabe es hinzubekommen. Naja, vielleicht kommt noch 
eine Idee wo ich es gebrauchen kann ;-)

Also vielen Dank für eure Unterstützung und viele Grüße,

Marcel(,")