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
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
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
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.
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)
...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?
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.
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
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
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
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
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
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?
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
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/
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
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.
:
Bearbeitet durch User
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?
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.
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!
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
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?
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".
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?
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
:
Bearbeitet durch User
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
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.
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
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!
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.
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.
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.
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.
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
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(,")
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.