hi folks,
ich möchte euch etwas über die WS2812B erzählen, was ihr vielleicht
schon immer wissen wolltet, aber nie zu fragen wagtet. ;o)
Kurz zur Vorgeschichte:
Jeder, der die Dinger mal ernsthaft für nicht-nervige Effekte benutzten
wollte, wird über das Problem der geringen Auflösung ihrer PWM
gestolpert sein. Die macht eine Korrektur passend zur menschlichen
Wahrnehmung bei geringer Helligkeit praktisch unmöglich und auch die
Farbmischung bei geringer Helligkeit läßt sehr zu wünschen übrig. Wer
nicht versteht, worum es geht, kann die beigelegte Funktionsdemo
benutzen, um sich das klar zu machen. Einfach mal ein wenig mit der
Helligkeit in ws28xx_usercode.asm in Richtung "geringer" rumspielen und
es wird schnell klar, wo das Problem ist.
Klar, man kann auf die WS28xx verzichten und was eigenenes mit normalen
RGB-LEDs auf die Beine stellen, das habe ich auch testweise gemacht (15
RGB-LEDs mit 17Bit PWM an einem Mega16). Funktioniert, sieht sehr hübsch
aus, ist aber auch teuer, aufwendig und umständlich. Aber dieser Test
war trotzdem hilfreich, um den persönlichen Rahmen abzustecken, den ich
mindestens brauche, um einigermaßen akzeptable Effekte hinzubekommen. In
meinem Falle kann ich mit einer 11Bit PWM offensichtlich schon leben.
Der Plan war also, den WS28xx per Software effektiv zu einer 11Bit PWM
zu verhelfen, zumindest für einen Strang mit 60 LEDs.
Schöner Plan, leider im ersten Anlauf grandios gescheitert. Und der
Grund dafür soll das Thema dieses Threads sein.
Das Problem ist nämlich, dass die Dinger zwar in jedem Frame die Daten
vom Bus übernehmen, aber das noch längst nicht heisst, dass sie auch in
jedem Frame als neuer Sollwert für ihre PWM wirksam werden. Inzwischen
habe ich unter Benutzung der ebenfalls beigelegten TestSuite zu genau
diesem Problem folgendes herausbekommen:
1)
Selbst bei minimaler Framerate (also Ansteuerung von 1024 LEDs), was in
meiner implementierung ca. 34Hz ergibt, können die Dinger ganz
offensichtlich bestenfalls in jedem 4. Frame Daten in ihre PWM
übernehmen (möglicherweise auch nur in jedem 8. oder 16. oder...).
Aber wie gesagt, ganz sicher nicht häufiger als in jedem 4. Frame.
Beweis: Testsuite mit folgender Konfiguration (leider verteilt über
mehrere Dateien, weil der Code halt ursprünglich nicht als TestSuite
gedacht war).
ws28xx.asm -> WS28XX_RST_NCT = 2
ws28xx_cfg.asm -> WS28XX_LEDCNT = 1024
Diese beiden Größen bestimmen zusammen die Framerate. Der erste ist die
Dauer des Refresh/Latch-Pulses. Eine Einheit davon dauert exakt so
lange, wie der Datentransport für das ColorTriple einer LED. Bei der
Konfiguration 3/1023 kommt also exakt die gleiche Framerate raus, wie
bei der angegebenen. Und tatsächlich zeigt sich, dass es für die in der
Folge beschriebenen Effekte keine Rolle spielt, wie die Zykluszeit auf
Refresh und LEDs verteilt wird.
ws28xx_userdata.asm -> DIVN=4, WHITEFRAME=3
DIVN bestimmt, alle wieviele Frames ein "weisses" rausgeschickt wird
(die anderen sind natürlich "schwarz"). Bei DIVN=4 werden also immer
abwechselnd drei Frames lang alle LEDs auf schwarz geschaltet und dann
für ein Frame auf weiss. WHITEFRAME bestimmt nun, welches Frame im
Zyklus der DIVN Frames das Weisse sein soll.
Und es ergibt sich, dass bei WHITEFRAME=3 die LEDs komplett weiss sind,
bei den anderen drei Möglichkeiten hingegen sind sie schwarz.
So weit, so schlecht. Aber es wird noch schlechter...
2)
Test: (näherungsweise) Verdoppelung der Framerate durch Halbierung der
LED-Zahl auf 512. Sonstiges Setup wie unter 1) angegeben. Ergebnis: bei
WHITEFRAME=3 übelstes Flimmern, aber wenigstens gleichmäßig, dasselbe
bei WHITEFRAME=1. Bei den anderen beiden möglichen Werten: Düsternis.
Die genauen Werte können variieren, wenn die WS28xx zwischenzeitlich mal
länger stromlos gemacht werden. Es ist aber immer so, dass zwei der vier
Möglichkeiten für WHITEFRAME effektiv Dunkelheit produzieren, die
anderen beiden gleichmäßiges Flimmern (höchstwahrscheinlich mit halber
Framerate). Damit dürfte die maximale Übernahmerate von 1/4 der
minimalen Framerate wohl als gesichert gelten. Garnicht gut für meinen
Plan, denn das bedeutet das Aus für ein einfaches Schema zur
PWM-Erweiterung, schon die Ausweitung um ein popliges Bit würde zu einem
üblen Flimmern mit ~15Hz führen.
3)
Die beiden Sachen oben habe ich heute erst ausprobiert. Im Laufe der
Woche hatte ich aber schon bei weit höheren Frameraten (eben denen, die
für meine 60 LEDs relevant sind) und mit anderen Werten für DIVN
rumgespielt. Das Ergebnis war, dass offensichtlich auch die Position der
LED in der Kette eine Rolle dabei spielt, welches der Frames sie für die
Übernahme der Daten in ihre PWM wählt. Besonders schön zu sehen in dem
Video "60led_2ctr_n13.avi", noch viel besser natürlich in Echt. Kameras
sind offensichtlich nicht dafür gedacht, LED-Geblinker gut einfangen zu
können. Die billige Webcam hat noch das beste Ergebnis gebracht. Für
diejenigen, die sich das in Echt anschauen wollen, hier noch das Setup:
WS28XX_RST_NCT = 2
WS28XX_LEDCNT = 60
DIVN=13
WHITEFRAME=egal (verschiebt die Sache nur)
Tja, das war's erstmal. Fröhliches Knobeln.
Ich werde mir den Rest des heutigen Tages mal den Bereich zwischen 1)
und 2) bezüglich der Framerate vornehmen. Irgendwo muss sich da das
Verhalten signifikant ändern, vermutlich sprunghaft, denn leichte
Änderungen um die angegeben Werte herum haben erstmal nichts am
jeweiligen Verhalten geändert. Ich tippe also auf eine PLL als
Taktquelle für die LED-PWM, die an die Framerate gekoppelt ist und zwar
mit einem Faktor, den sie selber entsprechend der Framerate wählt. Wenn
sich das bestätigt, wäre das gaaaanz schlecht für meinen Plan...
So richtig verstehe ich den Zweck nicht.
Wird Reset erkannt werden die nächsten 24bit in den Buffer geschrieben.
Am OUT setzt das Signal dann mindestens 24bit Zyklen aus.
Aus den Buffer werden die Daten dann beim nächsten PWM Zyklus übernommen
und ausgegeben. Bei 500HZ PWM sind das um ungünstigen Fall 2ms.
Es dauert also ~2ms bis die Daten aus dem Buffer wirksam werden. Sendest
du die Daten schneller wird der Buffer überschrieben und der Wert
übernommen der beim nächsten PWM Zyklus im Buffer ist.
Das ganze asynchron !!! Im ungünstigen Fall übernimmt die LED daneben
den Wert erst nach ~2ms. Die Folge wildes geflacker..
Tja und im Datenblatt steht 1 Pixel 400HZ Framerate was 2.5ms
entspricht.
Marco H. schrieb:> So richtig verstehe ich den Zweck nicht.
Das ist nix Schlimmes. Irgendwann kommst du schon dahinter.
> Wird Reset erkannt werden die nächsten 24bit in den Buffer geschrieben.
Genau so ist das eben nicht. Genau darum geht es ja.
> Aus den Buffer werden die Daten dann beim nächsten PWM Zyklus übernommen> und ausgegeben. Bei 500HZ PWM sind das um ungünstigen Fall 2ms.
Woher hast du die 500Hz? Das würde mich mal interessieren. Ganz sicher
jedenfalls nicht aus dem Datenblatt. Das habe ich vorsichtshalber
nämlich gleich mit gepostet. Und natürlich auch gelesen und
vollumfänglich verstanden.
> Das ganze asynchron !!!
Genau das ist es offensichtlich nicht. Das genau ist ja die erste
wesentliche Erkenntnis aus meinen Versuchen. Die PWM der einzelnen LEDs
wird ganz eindeutig mit der Framerate des Datenbusses synchronisiert.
> Tja und im Datenblatt steht 1 Pixel 400HZ Framerate was 2.5ms> entspricht.
Wo soll das stehen?
Die PWM-Frequenz der WS2812b beträgt in der Tat nur 400 Hz. Habe es
gerade mal nachgemessen mit einem Phototransistor + Oszi.
Das ist ja mal nicht dolle...
c-hater schrieb:> Wo soll das stehen?
Ich denke du hast das Datenblatt
> natürlich auch gelesen und> vollumfänglich verstanden.
Es steht auf der ersten Seite. Unter "Featurea and Benefits".
http://wp.josh.com/2014/06/09/neopixels-revealed-warping-time-and-space-to-actually-see-inter-pixel-jitter/
Deine Theorie wird hier widerlegt -> offenbar asynchron
Die verschieden Typen des Streifens entscheiden sich offenbar nur in der
PWM Frequenz.
Da diese relativ niedrig ist und selbst bei 0xFF nicht dauerhaft an,
außerdem asynchron ist der Streifen für Video kaum brauchbar.
http://wp.josh.com/2014/05/15/getting-physical-to-uncover-neopixel-pwm-secrets/
Der Rest steht dort auch und wenn man den Link den jemand
freundlicherweise in einen anderen Thread gepostet hatte aufmerksam
gelesenen hätte wären die tatsächlichen Fakten auch dir bekannt ;)
Ganz unten kann man in den Artikel Parts vor und zurück gehen und
erfährt nebenbei sehr viel was ich zugegebenermaßen auch nur durch
diesen Artikel erfahren habe.
Der Rest steht im Datenblatt !
Der Datenteil des WS2812 besteht auch aus einer getakteten Statemachine.
Der Takt liegt bei ca 4Mhz. Es kann gut sein, dass PWM und Statemaschine
vom gleichem Oscillator mit unterschiedlichen Dividern gespeist werden.
Praktisch macht es aber keinen Unterschied, ob diese Einheiten
zueinander synchron sind, da der Host immer asynchron zu beiden
arbeitet.
> Da diese relativ niedrig ist und selbst bei 0xFF nicht dauerhaft an,> außerdem asynchron ist der Streifen für Video kaum brauchbar.
In einem Video von Ulrich Radig sieht das gar nicht so übel aus(ab
Minute 1:25):
https://www.youtube.com/watch?v=8FiTcabQz1k
c-hater schrieb:>> Wird Reset erkannt werden die nächsten 24bit in den Buffer geschrieben.>> Genau so ist das eben nicht. Genau darum geht es ja.
Genau so ist es eben doch.
Wie auch anders ?
c-hater schrieb:>> Das ganze asynchron !!!>> Genau das ist es offensichtlich nicht. Das genau ist ja die erste> wesentliche Erkenntnis aus meinen Versuchen. Die PWM der einzelnen LEDs> wird ganz eindeutig mit der Framerate des Datenbusses synchronisiert.
Genau das ist es offensichtlich doch.
Es wird nicht mit der Framerate synchronisiert, sondern mit der
steigender Flanke.
Du must halt noch ein bisschen die secrets of WS2812 erkunden.
Reset ist Low > 10us, danach kommen die bits.
Jedes bit beginnt mit Log.1 und genau darauf wartet der WS2812 und
beginnt die bits in den Buffer zu schreiben. Die ersten 24 bits werden
übernommen. Nach Reset + PWM-delay werden diese auch ausgegeben
Da der Takt von microcontroller und WS2812 völlig unabhängig vonein-
ander laufen, muss das Ganze asynchron laufen.
c-hater schrieb:> Das ist nix Schlimmes. Irgendwann kommst du schon dahinter.
Ich hoffe du auch.
@c-hate
ist schon eine Weile her bei mir, aber ich kann mich erinnern, wenn aus
welchen Gründen auch immer, nicht ein vielfaches von 24 Bit in die
LED-Kette geschoben wird, dann werden diese nicht sauber geupdatet.
Tim . schrieb:> Praktisch macht es aber keinen Unterschied, ob diese Einheiten> zueinander synchron sind, da der Host immer asynchron zu beiden> arbeitet.
Falsch. Schon mit der geposteteten Testsuite ist es ja kein großes
Problem, Synchronität zumindest zur Statemachine des Busfeeds zu
erreichen. Jedenfalls für LED-Zahlen >256.
Diesen Bereich habe ich nämlich dieses Wochenende "ausgeklingelt". Die
Sache ist in diesem Bereich eigentlich ganz einfach (wenn auch irgendwie
nicht gerade sehr sinnvoll, deswegen habe ich auch so lange dafür
gebraucht, es ist offensichtlich schlecht, wenn man immer mit der
Annahme an die Analyse einer Sache herangeht, dass sie sinnvoll gelöst
worden wäre...).
Wie auch immer: Das ist rausgekommen und läßt sich mit der Testsuite
100% reproduzierbar nachweisen:
LED-Zahl Übernahmen/Frame
769..1024 1/4
513..768 1/3
257..512 1/2
Einen Sinn kann ich darin irgendwie nicht sehen. Wenn es umgekehrt wäre,
bei dem ersten Bereich 1/2 und bei dem dritten 1/4, ja, dann wäre das
irgendwie sinnvoll. So ist es einfach nur Bullshit. Aber
nichtsdestotrotz wohl die objektive Realität.
Allerdings bezüglich der PWM sehe ich auch eher schwarz. Denn wenn ich
im ausgeklingelten Bereich gezielt dafür sorge, das jede Übernahme
abwechselnd mit weiss und schwarz gefüttert wird (was mir dank der
erzielten Synchronität ja jetzt möglich ist), habe ich zwar den
erwarteteten Helligkeitseindruck, aber immer noch ein "Wabern" drauf.
Dieses erscheint aber jetzt eher stochastisch, ohne erkennbares System.
Es dürfte sich hierbei wohl um die Schwebung mit der PWM-Frequenz
handeln.
Allerdings: bei sehr geringen Helligkeiten muss man schon recht genau
hinschauen, um sie wahrzunehmen.
Außerdem habe ich beim Ausklingeln noch eine Erkenntnis gewonnen: Die
o.g. Gesetze beziehen sich wirklich nur auf die Anzahl der LEDs, nicht,
wie ursprünglich angenommen, auf die Framerate.
D.h.: ich kann die Framerate unabhängig davon beeinflussen (also
zumindest verringern), indem ich die Breite des Refresh erhöhe. Damit
habe ich aber die Möglichkeit, die Schwebungsfrequenz mit der PWM
unabhängig zu beeinflussen.
So ganz gebe ich das Projekt also noch nicht auf. Denn ich brauche die
PWM-Erweiterung ja eigentlich nur in dem Bereich geringer Helligkeiten.
Und die Schwebungen lassen sich vielleicht auch noch in den Bereich der
Nichtwahrnehmbarkeit verschieben.
Was mir viel mehr Sorgen macht, ist der Bereich <= 256 LEDs. Hier gelten
offensichtlich völlig andere Gesetze als in den drei Bereichen darüber.
Mit meinen bisherigen Methoden zum Ausklingeln bin ich hier jedenfalls
erstmal gescheitert. Naja, das nächste WE kommt bestimmt...
Woher sollen die LEDs denn "wissen", ob sie sich im Verbund mit 16, 256
oder 512 LEDs befinden? Deine Beobachtungen müssen sich über das Timing
einer einzelnen LED erklären lassen... und dieses ist hinreichend
bekannt.
Ansonsten könnte man sich natürlich auch noch "Dreckeffekte" durch
Überlastung der Stromversorgen vorstellen.
c-hater schrieb:> Was mir viel mehr Sorgen macht, ist der Bereich <= 256 LEDs. Hier gelten> offensichtlich völlig andere Gesetze als in den drei Bereichen darüber.> Mit meinen bisherigen Methoden zum Ausklingeln bin ich hier jedenfalls> erstmal gescheitert. Naja, das nächste WE kommt bestimmt...
Manoman.
Du solltest in die Politik gehen.
Mit so vielen Wortern nichts gescheites zu sagen - ein idealer
Politiker.
Jede deiner LEDs weiss natürlich immer, wieviele LEDs davor und
wieviele dahinter sind. Dementsprechend gelten auch die "Gesetze".
Jede einzelne WS2812 hat ihren eigenen Takt, Toleranzen, usw.
PWM ist 400Hz, also ist der zu erwartende Fehler im Bereich von
+/- 104us. Alles darunter ist reines Glück.
Und diese 104us ist die Zeit, die jede WS2812 dunkel bleibt, egal was
für ein Wert reingeschrieben wird (selbst 0xFF ist nicht dauerhaft an).
c-hater schrieb:> Mit meinen bisherigen Methoden zum Ausklingeln bin ich hier jedenfalls> erstmal gescheitert. Naja, das nächste WE kommt bestimmt...
WE fast vorbei, neue Erkenntnisse gewonnen, new secrets revealed ?
Tim . schrieb:> Woher sollen die LEDs denn "wissen", ob sie sich im Verbund mit 16, 256> oder 512 LEDs befinden?
Ganz einfach: durch mitzählen. Beachte: ich kann nur die ersten 60 LEDs
beobachten, die restlichen Daten werden zwar gesendet, gehen aber
natürlich mangels hinreichend langer Kette physisch vorhandener LEDs
einfach in's Daten-Nirvana.
> Deine Beobachtungen müssen sich über das Timing> einer einzelnen LED erklären lassen...
Dann mach das doch einfach und ich bin sehr glücklich. Denn dann hast du
mir viel Arbeit gespart.
> Ansonsten könnte man sich natürlich auch noch "Dreckeffekte" durch> Überlastung der Stromversorgen vorstellen.
Sehr, sehr unwahrscheinlich. Dagegen spricht die gefundene Regularität.
Wenn es deiner Meinung nach schon kein System in Bezug auf die bewußte
Ansteuerung geben soll, wie viel geringer ist dann erst die
Wahrscheinlichkeit, die Regularität durch "Schmutz auf der Versorgung"
erklären zu können? Kurz: das ist einfach nur lächerlich!
Mal abgesehen davon handelt es sich erstens um ein Netzteil, welches
selbst bei Vollast nichtmal warm wird (ganz anders als die LEDs
übrigens, über das Kühlkonzept dafür in der Endanwendung muss ich auch
noch nachdenken, das ist aber ein ganz anderes Thema), zweitens betreibe
ich den Kram für meine Tests nicht annähernd mit Vollast, sondern nur
mit maximal einem Achtel (wie dem Quelltext leicht zu entnehmen ist) und
letztlich ist die Versorgung hinreichend geblockt, so dass die lustigen
Blinkerspiele noch 'ne gute Sekunde unverändert weiter laufen, wenn das
Netzteil vom Netz getrennt wird. Bei Vollast allerdings geht's praktisch
ohne merkliche Verzögerung aus. Die Dimensionierung sollte also
vollkommen OK sein.
Marc V. schrieb:> Jede deiner LEDs weiss natürlich immer, wieviele LEDs davor und> wieviele dahinter sind. Dementsprechend gelten auch die "Gesetze".>> Jede einzelne WS2812 hat ihren eigenen Takt, Toleranzen, usw.> PWM ist 400Hz, also ist der zu erwartende Fehler im Bereich von> +/- 104us. Alles darunter ist reines Glück.> Und diese 104us ist die Zeit, die jede WS2812 dunkel bleibt, egal was> für ein Wert reingeschrieben wird (selbst 0xFF ist nicht dauerhaft an).
Aha. Dann erkläre doch bitte mit deinen Axiomen meine Beobachtungen. Die
du ja (zumindest prinzipiell) jederzeit nachvollziehen und zu deinen
eigenen machen könntest.
Marc V. schrieb:> WE fast vorbei, neue Erkenntnisse gewonnen, new secrets revealed ?
Leider nur wenige, eigentlich sogar nur eine: Im Bereich unter 257 LEDs
ist doch, wie ursprünglich beobachtet, die Framerate (in Verbindung mit
der LED-Position!) das einzig entscheidende Kriterium, nicht die Zahl
der angesteuerten LEDs.
Beweis wieder mit eingangs gepostetem Code:
DIVN=5
WHITEFRAME=1 ;völlig egal, solange im erlaubten Bereich
Und nun WS28XX_LEDCNT+WS28XX_RST_NCT (und damit die Framerate) konstant
auf 72 halten. Die beiden Werte werden zum Test also nur sozusagen im
Gegentakt variiert, jede Verringerung der LED-Zahl wird durch eine um
den gleichen Betrag längere Latch/Refresh-Phase ausgeglichen.
Es ergibt sich ein typisches Muster (meistens) besonders langsam
blinkender LEDs. Nämlich auf den Positionen 1,17,22,35 und 48 (natürlich
auf den höheren Positionen nur, so lange sie im Bereich des aktuell
gültigen Wertes für WS28XX_LEDCNT sind). Ein Stück Code mit Hervorhebung
dieser für die Mustererkennung am einfachsten benutzbaren LED-Positionen
(durch "Ausblenden" des Rests) hänge ich einfach mal an...
Das "meistens" meint übrigens: ab und an reisst mal die eine oder andere
der fünf Beispiel-LEDs aus dem Muster aus und zeigt ein stochastisches
Verhalten, diese Ausreißer finden sich aber fast immer schnell in's
Schema zurück.
Soweit wäre das sicher noch sehr gut mit deinem Ansatz (frei laufender
PWM-Takt) erklärbar.
Aber: Recht interessant ist auch die Beobachtung, wie genau die
"Querschläger" aus dem Schema fallen und wie sie wieder zurückfinden...
Außerdem: ändere spaßenshalber mal zusätzlich in ws28xx_init:
> ldi R16,3 ;setup USART for MSB first SPI mode> UOUT WS28XX_UBRRL,R16 ;with 2.5MBit/s -> WS28xx bitrate=833kHz
die 3 in eine 2, sprich: erhöhe den WS28XX_BITCLOCK von ~833kHz auf
~1.1MHz. Und dann staune. Es ändert sich dadurch nämlich rein garnix am
erzeugten Muster. Und auch nicht an der Blinkfrequenz der 5 Sample-LEDs.
So, wenn du mir das mit deinem Ansatz mal erklären könntest...
Außerdem: Die WHITEFRAMES werden ja mit duty 1:5 angeliefert. Bei rein
zufälliger Abtastung sollte dann natürlich auch das Blinken der LEDs
zumindest im langfristigen Mittel ein 1:5 duty haben. Hat es aber ganz
offensichtlich nicht...
Auch eine Sache, die du mir mit deinem Ansatz kaum erklären können
wirst...
Ich bin aber absolut offen für jede logisch konsistente Erklärung dieser
reproduzierbaren Beobachtungen, sei es nach deinem Ansatz oder jedem
beliebigen anderen. Mehr noch: ich bin sogar sehr begierig darauf,
solche Erklärungen zu lesen. Würde mir nämlich einfach einen
Riesenhaufen scheisselangweiliger systematischer Arbeit ersparen...
c-hater schrieb:> Ich bin aber absolut offen für jede logisch konsistente Erklärung dieser> reproduzierbaren Beobachtungen,
ich habe es nicht gesehe oder überlesen
deine paar hundert LEDs, alle auf einem Stripe?
Wieviel Einspeisepunkte?
Ich tippe mal deine Merkwürdigkeiten kommen durch partielle
Unterspannungen + LED Toleranzen bei hohem Takt.
Wenn es ein Stripe wäre und alle 10 LEDs eingespiesen wäre dann will ich
nix gesagt haben.
Aber trotzdem war der Thread interssant.
c-hater schrieb:> Außerdem: Die WHITEFRAMES werden ja mit duty 1:5 angeliefert. Bei rein> zufälliger Abtastung sollte dann natürlich auch das Blinken der LEDs> zumindest im langfristigen Mittel ein 1:5 duty haben. Hat es aber ganz> offensichtlich nicht...>> Auch eine Sache, die du mir mit deinem Ansatz kaum erklären können> wirst...
Ich mache das mit Bitbanging, du mit SPI, das ist der Unterschied.
Vielleicht solltest du davon ausgehen und nicht, dass die WS28xx
irgendwie wissen, wieviele von denen in der Kette sind.
Arbeiten mit ISR und ns Genauigkeit reimt sich irgendwie nicht.
Siehe: Beitrag "Re: Assemblertrick "Delaybreaker" gesucht"
Wie gesagt, SPI ist nicht unbedingt dazu geeignet, probiere es mal
mit Bitbanging und gesperrten Interrupts.
Hi, ich habe mal ein Testprogramm für den STM32F030 dafür in C
geschrieben.
Die Ausgabe erfolgt per SPI+DMA mit ca. 1 MHz Clock.
Mein (rein optisch) ermitteltes Ergebnis:
Bei mir flackern ALLE WS2812 wenn ich versuche PWM zu machen. Aber nicht
alle gleichzeitig sondern in einer mehr oder weniger zufälligen
Verteilung. Das scheinen dann wohl Schwebe-Effekte zwischen der LED PWM
und der PWM per Software zu sein.
Das einzelne LEDs dabei aus der Reihe fallen kann ich nicht feststellen.
Ich habe jetzt nicht so wirklich Lust zu Probieren was bei dem Projekt
mit dem SAM3x passiert wenn ich die Frames hintereinander setze.
Bei meinen WS2812 Test lief dieser über dem PWM Controller des SAM3x .
Per DMA wurde das Tastverhältnis so verändert das dies das Datenformat
des Streifens ergab.
Da der PWM Controller 8 Channels hat könnte man 8 Streifen *synchron
treiben.
*fast jedenfalls
Für BCM ist der Streifen zu langsam, es hat keinen Sinn den Streifen
außerhalb seiner Spezifikation bzw. Bestimmung zu betreiben. Irrend wo
habe ich schon mal von einer 16bit Version gelesen. Wahrscheinlich kaum
bezahlbar ;)
Marc V. schrieb:> Ich mache das mit Bitbanging, du mit SPI, das ist der Unterschied.
Natürlich ist das ein Unterschied, vermulich sogar der entscheidende.
Mein Code garantiert echte Zyklen. D.h.: sämtliche Timings meiner
Ansteuerung der WS28xx-Kette werden bei jedem Frame-Zyklus exakt
reproduziert. Das ist natürlich absolut zwingende Voraussetzung, um
unbekannte (undokumentierte) Timing-Eigenschaften eines Peers ermitteln
zu können.
Wenn dir nicht einmal das klar ist, wirst du zum Thread-Topic wohl
nichts beitragen können... :o(
> Vielleicht solltest du davon ausgehen und nicht, dass die WS28xx> irgendwie wissen, wieviele von denen in der Kette sind.
Jede LED weiss natürlich alles über jede andere LED an späterer
Position in der Kette. Wenn die nichtmal das klar ist: geh einfach
kacken. Vielleicht kannst du wenigstens das ohne Nanny...
> Arbeiten mit ISR und ns Genauigkeit reimt sich irgendwie nicht.
Doch, natürlich. Wenn man die Sache beherrscht. Den Nachweis der
exzellenten Beherrschung des Timings findest du als Kommentare an den
Kernroutinen der Engine. Der Trick der Engine ist ja gerade, dass die
ISR notfalls sogar (kurzzeitig) ein wenig wackelig werden dürfte, weil
das zuverlässige Timing der Ausgabe eben von der Hardware der SPI-UART
mit ihrer Fähigkeit zum double-Buffering recht unerschütterlich
sichergestellt wird. Dazu kommt dann noch das Software-Double-Buffering
des Treibers, was weitere Spielräume eröffnet.
Dazu kann dann noch jeder den Annotationen sehr leicht entnehmen, dass
in dem geposteten Code diese ganzen zusätzlichen Sicherheiten noch
nicht einmal genutzt werden. Nicht ein einziger verschissener Takt
davon. Die ganze Sache ist sehr, sehr locker "just in time".
Nur der im Eingangsposting gezeigte Democode (der rotierende Regenbogen)
kommt (zumindest auf einem Tiny, wegen der dort fehlenden Multiplikation
in Hardware) auch nur in die Nähe der Situation, dass die Sache kritisch
werden könnte. Aber selbst das Ding ist immer noch mit gutem
Sicherheitsabstand safe "in time". Auch das steht in den Anmerkungen.
Der worst case ist dafür ist in den Anmerkungen sogar taktgenau
spezifiziert...
Also ich glaube: bevor du weiteren Bullshit absonderst, solltest du
erstmal lernen, dein Zielsystem wirklich zu beherrschen. Tipp: Das wird
dir in C nicht gelingen...
Wahrscheinlich ist dir nichtmal aufgefallen, dass es keinen RAM-Buffer
für die Farbwerte der LEDs gibt. Die brauche ich nicht. Der Code kann
nämlich praktisch alle bekannten "Effekte" für WS28xx-Blinkerkram in
locker Echtzeit generieren (auf einem kleinen Mega). Und selbst auf
einem Tiny kann er immerhin noch den größten Teil des Spielkrams.
So geht programmieren...
c-hater schrieb:> Mein Code garantiert echte Zyklen. D.h.: sämtliche Timings meiner> Ansteuerung der WS28xx-Kette werden bei jedem Frame-Zyklus exakt> reproduziert. Das ist natürlich absolut zwingende Voraussetzung, um> unbekannte (undokumentierte) Timing-Eigenschaften eines Peers ermitteln> zu können.>> Wenn dir nicht einmal das klar ist, wirst du zum Thread-Topic wohl> nichts beitragen können... :o(
Bisher war ich der Meinung, dass du außer Selbstüberschätzung auch ein
bisschen Ahnung hast.
.
c-hater schrieb:> Also ich glaube: bevor du weiteren Bullshit absonderst, solltest du> erstmal lernen, dein Zielsystem wirklich zu beherrschen. Tipp: Das wird> dir in C nicht gelingen...
Danke, ich benutze C nicht und in Assembler bin ich bestimmt besser als
du.
c-hater schrieb:>> Arbeiten mit ISR und ns Genauigkeit reimt sich irgendwie nicht.>> Doch, natürlich. Wenn man die Sache beherrscht. Den Nachweis der> exzellenten Beherrschung des Timings findest du als Kommentare an den> Kernroutinen der Engine. Der Trick der Engine ist ja gerade, dass die
Wie gesagt, ausser krankhafter Selbstüberschätzung finde ich dort
nichts.
Die Frage wäre, was für eine Refreshrate man überhaupt wählen sollte
bzw. kann, um eine Software-PWM zu realisieren.
Alles >400Hz ist aufgrund der internen PWM Frequenz sinnfrei.
Eigentlich müsste die Soft PWM Frequenz ein vielfaches KLEINER sein, um
die Störeffekte bei der asychronen Übernahme der Daten in den LEDs
vernachlässigbar klein zu halten.
Aber genau das ist ja nicht sinnvoll möglich aufgrund der bescheidenen
400Hz. Das einzige was in meinem Versuch noch halbwegs brauchbar aussah,
war eine Refreshrate von 200Hz und 1 Bit Soft-PWM (sprich duty cyle 50%
oder 100%). Allerdings nur mit 21 LEDs getestet.
Um nun zu sehen ob die WS2812b synchron / asynchron getaktet sind, habe
ich mal über 3 LEDs jeweils einen Phototransistor gehangen und alle
Signale aufgezeichnet (siehe Bild).
Daten für LEDs: R=G=B=1, Refreshrate: 250Hz
CH1: Datensignal
CH2: Helligkeit LED1
CH3: Helligkeit LED2
CH4: Helligkeit LED3
Was man sehen kann, IMHO, die PWM-Frequenz der einzelnen LEDs:
- Ist asynchron zum Datensignal
- Ist nicht gleich für alle LEDs, offenbar gibt es eine Exemplarstreuung
