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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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 !
:
Bearbeitet durch User
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
Die einzige Möglichkeit die Update-Geschwindigkeit zu erhöhen, besteht darin, Devices mit höherer PWM-Frequenz zu nutzen: WS2812 - ~400 Hz SK6812 - ~1100 Hz APA102 - ~19000 Hz https://cpldcpu.wordpress.com/2016/03/09/the-sk6812-another-intelligent-rgb-led/
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.
:
Bearbeitet durch User
@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.
Mode Bitte den Thread schießen da sowie so hier nichts mehr Sinnvolles zusammen kommt!
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.
:
Bearbeitet durch User
@ c-heater Jenseits von dem, was Tim geschrieben und als Code um Thema WS2812B beigetragen hat, gibt es nichts.
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...
Bin ich der Einzige der das Gefühl hat das fast alle außer dem TO Ahnung von der Materie haben?
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
DS1Z_QuickPrint1.png
40 KB
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.