Kleine Schaltung: SPI nach WS2811-Umsetzer mittels Standard-Logik-Bausteinen

  • Ja ich denke auch das man vielleicht mal mit nem DMA Treiber am PI experimentieren kann. Ich weiß nur nicht ob man denn immer so genau 800 kHz * 4 Übertragungsrate in Hardware einstellen kann.


    Zu dem STM32 Cortex M3, nen paar habe ich mir auch schon angesehen und der SPI Clock kann nur in 2^x geteilt werden. Was die ganze Sache evtl. unflexibel macht... mit den XMegas geht das recht gut und schmerzfrei...


    Einen Kontroller (AtTiny) dazwischen zu setzen ist IMO der schlechteste Weg. Dann habe ich auf nem normalen AtMega kaum Vorteil in der Programmgeschwindigkeit und ich muss nen zweiten µC programmieren... außerdem bleibt das Problem mit den max 7 us Set-Zeiten bestehen...


    Würde da eher zu einer Lösung tendieren die alle Daten per SPI mit zB. 12 MHz empfängt und dann auf den Strip gibt... das beseitigt einige Probleme. Der Beste weg ist natürlich immer noch sein Projekt gleich mit einem Controller aufzurollen der die Strips auch mal so nebenbei befeuern kann.... Ich kann da den XMega empfehlen, aber da gehen sicher noch viele andere (mit DMA, flexiblen SPI Clocks und invertierbarer MOSI Ausgang)


    Grüße


    Basti

  • Hallo


    Hier einige neue Testresultate mit dem Raspi.


    Die Signalgenerierung liegt nun vollständig beim Raspi. D.h. ich habe am MOSI lediglich ein einzelnes Gatter um auf den 5V Pegel zu kommen, abgesehen davon wird nun alle Arbeit vom Pi gemacht.


    Dazu lasse ich auf dem SPI vorproduzierte Frames ausgeben bei denen die Länge der Pulse durch die Anzahl aufeinanderfolgernder 1 Bits definiert ist.


    Den Versuch habe ich sowohl mit einer 4 bit Variante (d.h. 0 Bit =1000, 1 Bit=1100), wie auch mit einer 8 bit Variante (0 bit=11000000, 1 bit=11110000) durchgeführt. Damit ist das Timing nicht perfekt, aber der Stripe ist in der Lage die Leds korrekt zu schalten. :)
    Anzumerken ist allerdings, dass mein Kabelverhau natürlich auch jetzt immer wieder zu Störungen führt (auch wenn an der Haustüre geklingelt wird flackern die Leds wie wild).


    Den Übergang zwischen den Bytes am SPI habe ich ebenfalls analysiert. Zwischen jedem Byte wird eine Pause in der Länge von einem Bit eingeschoben (nehme an da holt sich das DMA vom SPI das nächste Byte ab). Während dieser Pause liegt MOSI auf Low.
    Aus diesem Grund ist es nicht möglich 5 Bits pro Bit auszugeben (damit hätte man ein sehr schönes Timing hingekriegt), da die Pausen in den Pulsen liegen würden
    Bei oben beschriebenen 4bit Variante ist die Pause nach jedem zweiten Puls etwas länger (normal ca. 0.6us, länger ca. 0.9us). Dies scheint den Strip allerdings nicht zu stören.
    Bei der 8 Bit Variante fällt die Extrapause nach jedem Puls an. Trotzdem fällt sie weniger ins Gewicht da die Pausendauer im Vergleich zur 4bit Variante halbiert ist.


    Auf die Pause zwischen den Bits ist wohl auch zurückzuführen, dass SPI Frequnzen etwas höher als der rechnerisch korrekte Wert liegen zuverlässiger zu funktionieren scheinen. D.h. bei 4bit habe ich mit 4mhz gute Resultate gehabt, bei 8bit haben 7mhz gut funktioniert.


    Der Overhead für die Generierung der vorbrechneten Frames ist aus meiner Optik vertretbar. Der Raspi hat genügend Speicher und auch die Rechnungsleistung sollte kein Problem sein.


    Als nächstes werde ich nun versuchen einen etwas gescheiterrn Treiber für den Bus zum Strip auf eine kleine Platine zu bringen. Damit hoffe ich die Aussetzer ?( die im Moment manchmal auftreten in den Griff zu kriegen.

  • Ja, die Oszibilder darf man natürlich gerne sehen.


    Hier als erstes das Signal an MOSI bei 800khz wenn immerzu 255 ausgegeben wird. Die Pausen zwischen den Bytes sind schön sichtbar.


    Signal an MOSI bei der erwähnten 4bit Variante mit 3.2mhz


    Und last but no least die 8bit Variante mit 7mhz. Das Timming passt recht gut. Der 0 Pulse ist mit 0.28us etwas zu lang, der 1 Puls mit 0.57us geringfühig zu kurz.


    Das Flackern meiner Leds hat vermutlich nur beschränkt mit dem Signal zu tun. Wie schon erwähnt, es flackert sogar wenn jemand an der Haustüre klingelt.

  • Auf dem ersten Oszillogramm sieht man eine überlagerte Frequenz von etwa 14,7 MHz.
    Kannst Du Dir deren Herkunft erklären?
    Das ist ja kein normaler Einschwingvorgang, es tritt ja während der gesamten High-Periode auf.


    Wenn Du mal versuchst auf dieses überlagerte Signal zu triggern und es weiter zu dehen: Wird dann möglicherweise eine größere Amplitude erkennbar, als in dieser Auflösung?


    Habe das Gefühl, dass da irgendwo ein Stützkondensator fehlt, wo besser einer wäre.
    Und vielleicht würde es die Signalqualität verbessern, wenn noch eine UKW-Drossel ins Signal eingeschliffen wird, eventuell mit einer oder zwei zusätzlichen Windungen.


    Wo war eigentlich die Masseleitung vom Oszi angeschlossen?
    - An Masse, schon klar. Aber wo an Masse?
    Und an welcher Stelle hast Du den Tastkopf angesetzt?
    Direkt am Ausgang des ICs, oder am Eingang des Stripes?

  • Auf dem ersten Oszillogramm sieht man eine überlagerte Frequenz von etwa 14,7 MHz.
    Kannst Du Dir deren Herkunft erklären?


    Für mich sieht das aus wie das clk-Signal...
    vermute das ist nur ein Messfehler oder ein Steckbrettaufbau.
    Dem kann man bei Bedarf zwar noch nach gehen, aber vorerst sollte das kaum stören.

  • Ja, das muss das Clock-Signal sein, das rein streut - es sind schon diese Peaks gemeint (roter Pfeil)...?



    die kommen ja 16x pro Byte vor, also 2x Flanke pro Bit... der Kleingrusch dazwischen dann Einschwingvorgänge, wie in der Pause ja auch zu sehen - Irrlicht: die Hig-Periode in der ersten Grafik ist nicht ein einzelnes Bit, sondern ein gesamtes Byte... ;)


    und die Peaks also 800 kHz, nicht 14,7 MHz - passt auch besser zum eingeblendeten Zeitraster von 2 µS


    wenn's beim Klingeln an der Tür im Stripe flackert, hat das wirklich nix mit dem Timing zu tun, das sind halt derbe Einstreuungen - hier kann (wie von André schon gesagt) ein Bustreiber mit Serienwiderstand durchaus Abhilfe schaffen (sowie ne ordentliche Verkabelung/Aufbau).


    das Timing für die Bits ist nicht ganz so kritisch, ich habe auch festgestellt, dass z.B. ein deutlich kürzerer Puls als im DB als "0" gelesen wird - ebenso darf der "1"-Puls auch deutlich länger sein, und die low-Pausen auch deutlich länger als im DB, nur halt nicht in die Nähe der 7 µs kommen...


    zum Glück ist das so, wenn man die Pausen zwischen den Bits auch noch exakt einhalten müsste, dann hätte man echt verloren mit "Hausmitteln"...


    das klingt für mich auch logisch, wenn ich mir überlege, wie der Chip wohl intern funktioniert: ich gehe davon aus, da ist ein Monoflop, das wird durch den Eingang getriggert, und wenn es zurück fällt wird der Eingang in ein SR übernommen - ist er dann also wieder low (kurzer Puls) wird ne 0 übernommen, ist er immer noch high (langer Puls) wird ne 1 übernommen...


    das einzige Problem hier eben, dass die Reset-Pause vom Hersteller so kurz gewählt wurde, da haben die echt nicht an Bastler gedacht...


    das habe ich auch schon öfter ebi diesem Thema erwöhnt: ich persönlich hätte so nen Chip ja anders designed (habe sowas in SW schon mal gemacht), und zwar mit 3 Pulslängen:


    kurzer Puls (z.B. 0,5 µs) = 0
    langer Puls (z.B. 1 µs) = 1
    ganz langer Puls (z.B. 10 µs) = Reset


    dann hätte man zwischen zwei Bits alle Zeit der Welt, kann auch wenn's sein muss ne Minute warten :D, so lange der Reset-Puls nicht kommt, passiert nix...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Du scheinst gerade einen schönen Aufbau zum Testen zu haben... kannst du mal testen ob man die Bits auch beispielsweise mit schrägen Frequenzen wie 600kHz oder 1MHz reintakten kann? Die High-Pulse müssen natürlich in den gültigen Bereichen bleiben, wenn wir mal von einem Monoflop ausgehen. Hur aus Interesse, weil einige Chips nicht ganz so flexibel mit dem SPI-Takt sind.
    Die Theorie des Monoflops würde dadurch unterstützt...

  • Hallo


    Die Flackerprobleme in meinem Aufbau sind sicher durch mein übles Gebastel (mit)verursacht. Bis jetzt ist ist alles auf dem Steckbrett, teils mit, teils ohne Entkopplungskondensatoren und auch die Leitungen zwischen den verschiedenen Teilen des Aufbau (Raspi - Steckbrett, Steckbrett Stripe, Verbindungen zum Oszi) sind einfache Messleitungen. D.h. ein wunderbar unübersichtliches Durcheinander auf dem Arbeitstisch. ;)


    Sobald mir klar ist wie die Schaltung zwischen Raspi und Stripe aussehen muss um ein wirklich stabiles und sauberes Signal zu kriegen, werde ich eine Platine layouten. Dann kehrt wohl auch wieder etwas Ordnung ein.
    Für Nachhilfe bei entsprechenden Schaltungsentwurf bin ich natürlich immer dankbar (Alles was nicht rein Digital ist verstehe ich leider nur halb).


    Die Stromversorgung aller Komponenten kommt aus dem gleichen Netzteil. Auch der Raspi wird so versorgt. Anstelle des Usb-Anschlusses für die Stromversorgung verwende ich den GPIO Stecker um die Spannung einzuspeisen.


    Bezüglich anderer Datenraten habe ich bereits einige Versuche unternommen. Es gibt von der Sollfrequenz durchaus etwas Spielraum nach oben und unten (weiss leider nicht mehr was wirklich funktioniert hat), allerdings haben bei mir stark abweichende Frequenzen nicht funktioniert.


    Viele Grüsse


    Tom

  • Du scheinst gerade einen schönen Aufbau zum Testen zu haben... kannst du mal testen ob man die Bits auch beispielsweise mit schrägen Frequenzen wie 600kHz oder 1MHz reintakten kann?

    Naja, "gerade", das ist schon ne Weile her, dass ich da rumexperimentiert habe (mind. ein halbes Jahr...) - der Testaufbau ist einfach ein AVR, der das Signal per Bitbang erzeugt... ;)


    aber wie schon gesagt, ich habe das mit div. Pausen zwischen den Bits probiert, das sind ja dann versch. Frequenzen - wenn Dich eine bestimmte speziell interessiert, kann ich ja noch mal gucken...


    die Ausgaberoutine in dieser SW hier erzeugt das Signal auch per Bitbang, die Pausen zwischen den High-Pulsen sind hier noch nicht mal einheitlich (je nachdem, was die SW gerade macht, ob eine ISR aufgerufen wird, weil gerade ein Byte rein kommt), funktioniert trotzdem.


    Wie gesagt, nur *zu* lang darf die Pause zwischen zwei Bits nicht werden - ob ich's auch mit *kürzeren* Pausen als im DB probiert habe, kann ich mich gerade nicht genau erinnern... solche hätte man ja, wenn man 1 MHz statt 800 kHz benutzt... kann ich aber noch machen

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ach so ist das also.
    Ja, testen musst du das nicht zwingend. Ich bin gerade dabei einen Versuchsaufbau (ersteinmal mit einem ATmega88 auf nem STK500, einer SPI_to_WS2811-Schaltung und einem 1m langen LED-Strang) aufzubauen.
    Geht bei dem Wetter etwas schleppend voran. Ist man drinnen, dann ists so heiß, dass Denken kaum möglich ist und es zieht einen raus, und ist man draußen geht nix weiter... Draußen ists trotzdem schöner, die arbeit bleibt :D , das wetter nicht ;(


    Aber damit werde ich dann einfach mal austesten wann und wie der Strang mich noch versteht. Mit dem Internen RC-Oszillator des ATmega kann man ja die Frequenzen ganz easy durchtesten. Der lässt ja ein Trimmen von 50% bis 200% zu... Nicht ganz so gedacht von Atmel denke ich, aber tuts wunderbar. Auf dem Weg bringt man übrigends fast jeden Atmel auf 16-17MHz ohne externen Taktgeber :thumbup:
    Nur weiß ich noch nicht ganz genau welche Testdaten ich senden soll, damit ich auch wirklich erkennen kann ob jedes Bit richtig gelesen wurde... Da hab ich mir noch keine Gedanken gemacht. Aber da kommt bestimmt auch noch ne kleine Eingebung :thumbup:

  • Hallo


    Nun bin ich endlich dazugekommen meine Versuche fortzusetzen und habe nun eine funktionierende Lösung zusammengebaut. Dazu habe ich einen Arduino Mega 2560 (ein kleinerer Chip würde auch reichen) mit einem FT245RL (USB to 8 bit Parallel IO Chip) kombiniert. Auf diese Weise kriege ich einen hohen Datendurchsatz zum AVR (mit dem ersten Bascom gewurstel sinds schon ca. 48kbyte Sekunde) und habe immer noch genügend Rechnungsleistung übrig um per Bitbang (dies allerdings in Assembler) das Signal für den Stripe zu erzeugen. Da im Bitbangcode noch diverse NOPs vorhanden sind, hoffe diese durch Befahle für den Datenempfang ersetzen zu können und so gleichzeitig den Stripe zu bedienen und den Puffer mit dem nächsten Frame füllen zu können. Mal sehen obs klappt.


    Das ganze läuft bis jetzt stabil, ohne Geflacker und sonstige Aussetzer. :)


    Im Moment hängt die Geschichte am PC, aber ab dem Raspi müsste die Sache wohl auch funktionieren.


    Hier noch ein Bild des aktuellen Gebastels (werde nächstens eine Platine zeichnen die alle Komponenten vereinigt).



    Viele Grüsse


    Tom


    PS:
    Mit der blauen Klemme mit der Nadel nehme ich das Signal für den Stripe ab. Klappt bestens. ;)

  • Hallo Leute,


    ich hoffe jemand hier kann mir helfen. Ich habe für einen Freund und mich LED's bestellt. Und zwar wollte ich die WS2801 haben, aber ausversehen bestellte ich die WS2811.
    Kann mir jemand sagen, wie ich die an meinem Raspberry so zum laufen kriege, als ob sie die WS2801 wären? Ich hab leider so gut wie keine Ahnung von Eltektrotechnik. ?(
    Die LED's waren dafür gedacht ein Ambilight zu kopieren.
    Würde mich sehr freuen, wenn ihr mir helft. :)


    Viele Grüße


    sincere92

  • Ich würde sagen: Nein.


    Das Protokoll von Boblight geht nicht mit WS2811, der PI an sich geht nicht out-of-the-box mit WS2811, es sind zwei verschiedene Chips.


    Kauf einfach WS2801 Strips. Ein Boblight ist an sich schon genug Stress einzurichten für einen Anfänger.


    Willst du eigentlich Standalone oder für PC?


    Hast die 2811er in China bestellt? Ansonsten schick sie einfach zurück :)

  • Und zwar wollte ich die WS2801 haben, aber ausversehen bestellte ich die WS2811

    Hossa!
    Zwei Seiten weiter vorne (Kleine Schaltung: SPI nach WS2811-Umsetzer mittels Standard-Logik-Bausteinen) habe ich ein kleines Programm gezeigt, mit dem ich erfolgreich die Signale fuer WS2801 (der vorhandene Controller konnte nur das) auf WS2811 umgesetzt habe.


    1) Ich weis nicht, ob das bei Dir auch funktioniert, da ich das timing nicht kenne, das der RasPi ausgibt, wenn er WS2801 "spricht".
    2) Du brauchst einen AVR Mikrocontroller (z.B. Arduino), und die Moeglichkeit ihn direkt (ohne Umwege ueber die Arduino IDE) zu programmieren (z.B. AVR ISP MK2)
    3) Eleganter waere es natuerlich, das korrekte Signal am RasPi zu erzeugen, aber da stecke ich zu wenig in der Materie um Vorschlaege zu machen...


    Vielleicht hilft es Dir ja weiter?


    Viele Gruesse
    Andre

  • Hmm ich dachte es ginge mit dem in diesem Thread genannten SPI-Umsetzer.
    Die Frage ist nur, was ich jetzt mit den WS2811 Strips, die ich leider bestellt habe mache.
    Ja, die sind aus China =/
    Das Boblight ist für den Fernseher gedacht, also Standalone.

  • Klar kannst du es probieren, aber da du ja selber schreibst dass du nicht viel Ahnung hast, rate ich dir davon ab.


    Das Problem ist ausserdem dass du dann wohl der einzige mit dem Setup wärest, dH wenns nicht läuft weisst du null obs am Umsetzer, der Software oder dem Boblight selbst liegt.


    /E


    Wenn es Standalone ist benutzt du raspbmc mit boblight-daemon oder?



    Ansonsten könntest du nämlich auf nem PC XBMC installieren und per Arduino die Ws2811 ansprechen. Das ginge.