ATTINY85 o.ä. als I2C zu WS2812 Bridge

Hallo,

das sollte doch von der RAM-Größe unabhängig sein.  Meiner Idee nach 
würden die Bits einfach durchlaufen:  per TWI rein, und per bitbanging 
wieder raus.
Per Clock Stretching wird der Master auf die korrekte Geschwindigkeit 
gedrosselt.

Wenn ich das jeweils erst in den Speicher des Attiny (oder was auch 
immer) lade und dann ausgebe, bremse ich die Ausgabe insbesondere für 
lange LED-Strings enorm ab.

Gruß


rgbled-bastler

Frank K. schrieb:
> Schau Dir mal diese AppNote an:
>
> http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf
>
> Hier wird ein PIC16F1509 verwendet. Der hat konfigurierbare Logikblöcke
> (CLB), und damit und mit der SPI-Schnittstelle wird das Timing quasi
> hardwaremäßig erzeugt, was keine Rechenleistung braucht. Eine ziemlich
> geniale Lösung also. Es gibt noch andere PIC16 mit CLB - such Dir den
> passenden aus.
>
> fchk

OK, dies sieht nach einer netten Sache aus, wie der PIC nativ WS2812 
spricht. Also mit wenig CPU-Leistung den WS2812 füttert.
Jetzt brauche ich immer noch den Uplink und die Synchronisation.

D.h. ich will ja ein bestimmtes Bytemuster synchron auf die WS2812 
bringen, ohne dass dies zuvor komplett auf dem Treiber gespeichert wird.

Ich habe bislang leider noch gar nichts mit den PICs gemacht, auch wenn 
ich gelesen habe, dass diese sehr einfach zu programmieren seien.

Liese sich in Kombination mit der CLB-Ausgabe ein Ringpuffer für die zu 
sendenden Daten implementieren, der von einem Uplink I2C gefüttert wird?

D. h. der I2C Slave würde den Ringpuffer füllen, sobald dieser gefüllt 
ist, per Clock-Stretching den Sender bremsen.
Der Pic würde den Inhalt des Ringpuffers per CLB-maskiertem SPI auf den 
WS2812 schicken, dadurch im Ringpuffer Plaz schaffen, den der I2C-Client 
wirder füllt.

Sobald der Rinpuffer leer ist, hört das CLB_SPI Senden auf, und die 
Kette leuchtet.

???

Peter D. schrieb:
> Soweit ich das sehe, kann man beim WS2812 beliebig lange Pausen zwischen
> den Paketen lassen. Der ATtiny kann also sein I2C bequem nach einem
> Paket machen.
> Überträgt er gerade ein Paket an den WS, kann er entweder SCL strecken
> oder mit NACK antworten.

Hmm, nach allem, was ich ausprobiert habe, und was auch hier steht:
http://www.mikrocontroller.net/articles/WS2812_Ansteuerung
wird eine Pause länger als 50µs als Reset erkannt, und führt dazu, dass 
die LED den gegenwärtigen Speicherinhalt anzeigen.

Wenn es hier einen Trick gäbe, eine Pause zu machen, die nicht als Reset 
interpretiert wird, wären alle Probleme gelöst.

Joachim B. schrieb:
> verstehe ich nicht, warum nicht bit banging direkt aus dem STM32F405
>
> benötigt nur 3 Byte pro LED
>

Weil ich z.B. auf dem pyBoard keinen direkten Zugriff auf Bitbanging 
habe.
Es gibt zwar rudimentäre Inline-Assembler-Möglichkeiten, ich müsste aber 
z.B. Interrupts abschalten, was andere Bibliotheken für so lange Zeit 
gar nicht gerne sehen.

Die Lösung wäre zudem auch wieder nicht so universell, wie das, was ich 
mir vorstelle. Ich mag ja wegen meiner geringen Erfahrung im µC Bereich 
hier zu naiv sein, aber ich stelle mir halt immer noch ein Modul vor, 
dass per I2C mit einer Geschwindigkeit > 800kHz angesprochen wird, und 
das per Clock-Stretching auf 800kHz eingepegelt wird.

> im Atmel brauchst du doch buffer entsprechend der LED Tiefe x 3
> also 900 Byte bei 300 LEDs, da bietet sich eher ein atmega an mit mehr
> RAM, z.B. atmega1284p mit 16kB Ram für vieles mehr.

Dann brauche ich eben auch keinen Puffer im Atmel, den ich auch nicht 
haben will. Sondern die bytes laufen einfach durch, per I2C rein und per 
WS2812 raus.  Der Baustein in  der Mitte (ob nun Atmel oder Pic oder 
...) sorgt einfach durch Clock-Stretching dafür, dass die WS2812 nicht 
überfahren werden.

Somit brauche ich auf dem eigentlichen Device nur eine Standard 
I2C-master Implementierung, die in der Lage ist mit mehr als 800kHz zu 
senden und die auf Clock-Stretchung reagiert.

Die LED Daten sind dann nur auf diesem Gerät im Puffer, der µC 
dazwischen ist nur ein Synchronisationsglied.

Peter D. schrieb:
> Ich dachte, das sollen sie auch.
> Warum sonst schickt man was an den WS?

Ja natürlich, aber ich will ja nicht nur eine LED sondern 100 oder 200 
LED zum Leuchten bringen.

D.h. ich muss die Bytes für alle LEDs innerhalb der erlaubten 
Spezifikation ohne Pause raushauen. Sobald ich eine Pause mache, wird 
das angezeigt, was aktuell in den Puffern ist.

D.h. während ich der ersten LED die ersten drei Byte reintakte, sendet 
diese drei Null-Bytes an die Zweite, diese sendet drei Null-bytes an die 
Dritte usw.

Beim nächsten Triple sendet die erste LED die zuvor erhaltenen Daten an 
die Zweite, diese jedoch die zuvor erhaltenen Nullbytes an die 
Dritte....

Sobald nun eine Pause eintritt, wird angezeigt, was in den Puffern ist.

Wenn die Pause nach zwei bytes erfolgen würde, gibt es sogar ganz 
falsche Farben....

Peter D. schrieb:
> rgbled-bastler schrieb:
>> Sobald nun eine Pause eintritt, wird angezeigt, was in den Puffern ist.
>
> Dann entlastet der ATtiny ja nicht sonderlich den Master, der muß dann
> weiterhin in Echtzeit senden.
>
> Besser, der ATtiny puffert die I2C-Daten und schiebt sie komplett raus.
> Bei 512Byte SRAM sind ~150 LEDs möglich.
> Insbesondere kann dann der Master nur die Daten senden, die sich
> wirklich ändern.

Der Attiny soll ja in erster Linie nicht den Master entlasten, sondern 
nur dafür sorgen, dass ich auf dem Master keine Klimmzüge machen muss.

Wenn der Attiny puffert, verdoppelt sich im besten Fall die 
Ausgabegeschwindigkeit, was für Spiele etc. schon nicht mehr so toll 
ist.

Das Ausgangsproblem ist, dass auf etlichen schnelleren Minicomputern und 
µC je nach Implementierung des dort laufenden Systems, ein einfaches 
Bitbanging etc. nicht mehr möglich ist.

Ich will hier nun von der Implementierung weg, dass ich das dreifache an 
RGB-Daten auf dem Master allozieren muss, da ich dort den Takt nicht 
langsam genug bekomme, um di eeinfach Datenmane rauszuschieben.

Das alleine dürfte schon eine Entlastung des Master sein.  Je nach dem, 
wie der Master sein I2C implementiert, läuft das vermutlich ohnehin dann 
parallel zu den anderen dort laufenden Tasks.

Joachim B. schrieb:
> nö, I2C clock 100 bis 400 kHz, aber nicht als Avr Slave? und ein WS hat
> 800kHz bremst schon mal aus und 3 Byte pro LED muss man am Atmel
> buffern, -> RAM

Klar, ich muss je nach Implementierung 1-3 Byte puffern. Aber immer nur 
die.
Weil ich ja das Senden weiterer Bytes per Clock-Stretching verhindere.

Das ich auf die 800kHz vom WS runtergehe, ist klar.  Das macht die 
derzeitige Implementation auch, allerdings dadurch, das das dreifache an 
Daten in einem dreifach höheren Takt gesendet wird ;-)

Ich würde 8 Bit Farben verwenden. Damit kann der i2c langsamer takten. 
-> 200 led buffer passt in den ram des tiny.

Und die Daten per spi an dir leds senden. Bei 3,2mhz spi Takt. Wären das 
"1000" für eine 0 und "1110" für eine 1. Und man hätte 0,3125:0,9375µs 
passt also.

Bleibt nützlich dir frage, wann gesendet wird. Und das hängt von der i2c 
Traktate ab. Den nur weil 8mhz möglich sind. Heißt das noch lange nicht, 
das es auch funktioniert.

Robin schrieb:
> Und die Daten per spi an dir leds senden. Bei 3,2mhz spi Takt. Wären das
> "1000" für eine 0 und "1110" für eine 1. Und man hätte 0,3125:0,9375µs
> passt also.

Das ist ja gerade, was ich NICHT möchte, dass ich anstelle eines bits 
mehrere Bits senden muss, und so den Speicherverbrauch auf dem Master 
hochschraube.

Ich zitiere aus einer den Micropython Bibliotheken:
https://github.com/JanBednarik/micropython-ws2812/blob/master/ws2812.py

1

def update_buf(self, data, start=0):

2

        """

3

        Fill a part of the buffer with RGB data.

4

        Order of colors in buffer is changed from RGB to GRB because WS2812 LED

5

        has GRB order of colors. Each color is represented by 4 bytes in buffer

6

        (1 byte for each 2 bits).

Da wird genau das gemacht, und ich brauche noch dreimal mehr Speicher, 
als wenn ich nur die 8 bit pro Farbe verwende.

Hier werden nochmals 3 Byte pro Farbe, also 12 Byte pro LED zusätzlich 
im Puffer abgelegt, nur dass der Takt passt.

Joachim B. schrieb:
> offensichtlich nicht klar wenn du von I2C schreibst, ich kenne nur
> 100kHz und 400kHz und selbst wenn I2C schneller gehen sollte, auf dem
> Atmel?

Der STM32 kann auch jeden Fall HighSpeed I2C, das ist 1MHz. Das wäre die 
gewählte Geschwindigkeit, die dann durch Clock-Stretching auf 800kHz 
gesenkt würde.

Das ist doch DER Fall für den LPC810 DIP-8 ARM:

https://github.com/cpldcpu/light_ws2812

Der eingebaute SCT (State Machine Timer) schlägt den ganzen STM32F405 
locker (trotz M0 vs M4)

rgbled-bastler schrieb:
> Robin schrieb:
>> Und die Daten per spi an dir leds senden. Bei 3,2mhz spi Takt. Wären das
>> "1000" für eine 0 und "1110" für eine 1. Und man hätte 0,3125:0,9375µs
>> passt also.
>
> Das ist ja gerade, was ich NICHT möchte, dass ich anstelle eines bits
> mehrere Bits senden muss, und so den Speicherverbrauch auf dem Master
> hochschraube.

Eben nicht. Du kannst das ganze erst beim laden ins Senderegister 
umwandeln. Und da musst du nur einen von 4 möglichen werten laden. 
Abhängig davon, wie die nächsten 2 Bits aussehen.

Robin schrieb:
> Eben nicht. Du kannst das ganze erst beim laden ins Senderegister
> umwandeln. Und da musst du nur einen von 4 möglichen werten laden.
> Abhängig davon, wie die nächsten 2 Bits aussehen.

Bekomme ich da dann nicht Probleme, die 800kHz zu halten, ohne Pausen > 
50µs einzulegen?  Wenn ich vor dem Senden einer 2bit_gruppe festlegen 
muss, welches Byte ich schicke?

Du hast 40 Takte um den Wert zu laden. Das sollte locker ausreichen und 
zur not kannst du ja auch etwas länger brauchen. Im wiki steht etwas von 
maximal 5µs, also maximal 120 Takte. Da kannst du idr. auch noch das I2C 
abarbeiten.

>Statt 3Byte pro LED sind so nun 9 Byte im Puffer.

Na und? Das sind immer noch 12000 LEDs die du ansteuern kannst.
Für unbenutztes RAM gibt es kein Geld zurück;)

Der xmega32e5 hat ebenso die integrierte Logik Blöcke wie der pic und 
zusätzlich noch einen DMA, was eine WS2812 Ansteuerung mit sehr wenig 
CPU Last ermöglicht. In den 4kb RAM kann man also einen großen 
Framebuffer erstellen (eventuell mit double Buffering) und hier die 
Daten zwischenspeichern. Dadurch müssen die Daten vom PC nicht in 
Echtzeit geliefert werden, was er sowieso nicht kann.

Hier noch ein Link zu einer Beschreibung zur Umsetzung am xmega 32e5: 
http://www.ejberg.dk/portfolio/ws2812-xcl/

Mal vieln Dank für all die Hinweise, die hier zusammengekommen sind.
Ich muss das erstmal alles sortieren, werde mich wieder melden!

Danke!

Joachim B. schrieb:
> Peter D. schrieb:
>> Soweit ich das sehe, kann man beim WS2812 beliebig lange Pausen zwischen
>> den Paketen lassen.
>
> wo hast du das denn her?

Das ergibt sich aus der Logik der Sache. Ein "Paket" = ein Frame = 
einmal Werte für alle LEDs am Bus. Die Pause löst für alle LEDs am Bus 
die Übernahme der empfangenen Daten aus. Die Mindestlänge einer dazu 
führenden Pause ist definiert. Aber natürlich kann man die Pause auch um 
so viel länger machen, wie man will. Das ändert rein garnix an der 
Funktion, sondern senkt nur die mögliche Framerate.

> 3 Byte pro LED muss man am Atmel
> buffern, -> RAM

Das ist das einzige echte Problem. Alles andere ist nur der 
Hilfeschrei eines C-"C&P"-Programmierers...

Ja klar, wenn die Source wesentlich langsamer ist als der Sink, dann 
kommt man natürlich nicht drum herum, alle Daten zu buffern. Und die 
leider immer im Vergleich zum Rest des Systems überaus knappe 
Ausstattung der AVR-µC mit SRAM setzt hier die Grenzen für das, was 
geht.

Schließlich will Atmel lieber die großen teuren Geschosse verkaufen, 
daran verdienen sie doch schließlich auch viel mehr, dafür muß man doch 
Verständnis haben...

Also ist die primäre Größe für dieses Problem die Größe des verfügbaren 
SRAM. Näherungsweise braucht man dessen Größe nur durch drei teilen und 
etwas abrunden, um die Zahl der durch einen AVR8 autark ansteuerbaren 
WS2812-Teile herauszubekommen.

Die große Ausnahme von dieser Regel ist: Parametrisch generierte 
Inhalte. Also gerade nicht der stupide Ansatz, die Inhalte jeder 
einzelnen verschissenen LED speichern und strunzdumm rauszukloppen, 
sondern sie statt dessen in Echtzeit berechnen. Ausreichend Zeit dafür 
ist für sehr viele Muster. Jedenfalls für Asm-Programmierer...

Vielleicht kann c-hater den von piedpiper.com entwickelten Algorithmus 
in die Maschinensprache des 85ers portieren? Wäre doch mal ein würdiger 
Job für einen echten Programmierer wie ihn.