Hallo, um mal einen passenden Thread zu diesem Thema aufzumachen. Wie ist denn der Stand bzgl. einer möglichst resourcenschonenden Ansteuerung dieser WS2812 RGB LEDs? Vom Timing her sieht's so aus, als würde der Chip xxx ns nach einer steigenden Flanke einfach nur das aktuelle Signal samplen, oder? Könnte man das Timing irgendwie mit SPI hinbekommen? Oder geht wirklich nur Bit-Banging? Grüße Markus
Gast
#2953296
> Unsinn, du hast Daten- und Clock-Leitung. Lies das DB und versteh es.
Unsinn, du redest vom 2801... Lies das RICHTIGE Datenblatt.
Ralf
Gast
#2953301
> Könnte man das Timing irgendwie mit SPI hinbekommen? Oder geht wirklich > nur Bit-Banging? Je nachdem wie schnell dein µC ist geht's mit SPI (ist schon beschrieben worden), Bitbang natürlich, desweiteren gab's schon PWM-Versuche etc. Ich glaub jemand hatte sogar mal die Idee zwei monostabile Stufen zu ver-odern. Ralf
Gast
#2953336
Vielleicht könnte man etwa so machen: Beitrag "Re: [Mitbestellung] SMD5050 RGB-LED mit integriertem 8-bit PWM Controller" und das Ganze in einen CPLD (?) packen?
...naja, man könnte auch einen kleinen ATtiny nehmen und den auf der einen Seite über den SPI mit den normalen RGB-Daten füttern und auf der anderen Seite über "Bit-Banging" (oder evtl. PWM) dann die Daten für die LEDs ausgeben. Die Hardcore-Variante wäre einen ATtiny4 zu nehmen und alles taktzyklengenau in eine kleine Statemaschine o.ä. reinzupacken :-) Man müsste auch mit jeweils 3 Bits auf dem SPI die Zustände ausgeben können, also dann "100" für logisch 0 und "110" für logisch 1. Der Takt müsste dann 0,4µs pro Bit sein (z.B. 20MHz/8), man würde dann nur ein ganz kleines bisschen gegen die Spezifikation verstoßen ;-) D.h. aus einem Datenbyte würden dann 3 auf dem SPI auszugebende Datenbytes werden, das könnte man über eine Lookup-Table realisieren. Man kann natürlich auch 4 Bite nehmen wie vorgeschlagen, dann kann man den Takt noch besser "konform" machen. Die MCU wird wohl während der Ausgabe des Bitstromes eh nichts anderes machen können, per Interrupt wird das nichts. DMA wäre optimal... Grüße Markus
...habe jetzt mal mit einem ATtiny45 / 16MHz als kleinste Basis angefangen. SPI bzw. USI: Kann man vergessen, besonders bei den Übergängen zum nächsten Datenbyte entstehen zu lange Pausen bzw. eine falsche Ausgabe, weil es zu lange dauert das nächste Byte in den Ausgangspuffer zu schreiben (hat kein Double-Buffering...). PWM: Habe ich hinbekommen, allerdings habe ich trotz genau 1,25µs Periodendauer nach der dritten LED einen Glitch, d.h. das MSB für Blau wird verschluckt :-( Grüße Markus
Hi, so, funktioniert jetzt mit PWM. Hier mal der Source, ich musste leider ein wenig loop unrolling machen, da bei 16 MHz die Zyklen zum ändern der PWM schon recht knapp sind :-) Immerhin muss alle 20 Taktzyklen ein neues Bit rausgeschoben werden. Ich komme somit genau auf 800KHz. Mit den Timingwerten im Source ist T0H = 0,36µs T1H = 0,80µs Ist ein ca. 1/3 zu 2/3 Verhältnis. Jewweils dann aufgefüllt zu 1,25µs. Grüße Markus
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.