LED - Strips hintereinander?

Ja.

Von den LEDs her kein Problem. Die Update-Rate sinkt natürlich 
entsprechend.

Wenn Du eine Library nimmst, müsste man abklären, ob und wo es da eine 
Grenze gibt (abklären = ausprobieren). Die Libraries, die ich kenne 
(FastLED, Adafruit) können auch an mehreren Ports LED-Streifen 
ansteuern.

Vergiss nur den Strom nicht.
Bei 60LEDs/m und 50mA pro LED bei Weiss und voller Helligkeit hast Du 3A 
pro Meter oder 360A für Deine 120 Meter.
Da sollstest Du mindestens alle 10 Meter ein Netzteil setzen.

Torsten_C schrieb:
> Bei WS2812 müssen die kompletten Daten im RAM sein

...oder schnell bei Bedarf errechnet werden können.

c-hater schrieb:
> was für ein ausgefallenes Muster schwebt dir vor

Fraktale :-) :-)

200 Takte pro Byte heisst aber, dass die Bits per Hardware geschoben 
werden müssen. Bei dem etwas proprietären Timing der WS2812 wird das mit 
einem einfachen Controller kaum funktionieren. Das heisst man braucht 
externe Hardware, und zwar nicht nur ein einfaches Shift-Register.

Aus diesem Grunde haben wir einen Arduino Due dafür genommen, mit 
reichlich RAM. Manche haben es auch schon mit dem Raspberry geschafft, 
die Bits im DMA-Mode rauszuschieben.

MCP schrieb:
> Oder so etwas:
> http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf

Oder sowas:
http://www.picalic.de/PIC2WS2812

(ich wollte es halt mit einem einen µC mit nur 8 Pins erledigen ;) )

Thomas Elger schrieb:
> Oder sowas:
> http://www.picalic.de/PIC2WS2812

"Die kurzen Impulse (250ns) für die "0"-Bits werden als PWM-Signal durch 
TMR2 in Verbindung mit dem CCP1-Modul erzeugt. Für die längeren "1"-Bit 
Impulse (625ns) wird das SPI Clock-Signal (SCL) benutzt."

Ein bisschen ein Gebastel ist das aber schon. Aber durchaus interessant. 
Gibt es sowas auch auf AVR-Basis?

Der andere Link ist ja für WS2811, die mit der extra Clock-Leitung.

MCP schrieb:
> WS2811 ist der Chip in den WS2812 LEDs...

Ja, richtig. Aber gab es da nicht einen Chip mit Clk und Daten getrennt?

Pink Shell schrieb:
> Ja, richtig. Aber gab es da nicht einen Chip mit Clk und Daten getrennt?

Ja, es gibt diverse Chips mit CLK und Daten, die sich per SPI-Interface 
ansprechen lassen. In LEDs integriert heißen die dann z.B. APA102
(siehe auch: https://cpldcpu.wordpress.com/2014/08/27/apa102/)
Habe schon seit einiger Zeit einen LED-Streifen von denen hier liegen, 
aber bislang noch nix damit gemacht. Interessant gegenüber den WS281x 
ist u.a. auch die sehr hohe (interne) PWM-Frequenz von den Chips, womit 
sie auch für POV-Anwendungen geeignet wären. Bei den WS281x geht das 
nicht.

@c-hater: klar könnte ich auch ohne "Gebastel" irgendwelche Bitmuster 
auf der SPI-Datenleitung ausgeben, um die HIGHs und LOWs für die LEDs zu 
erzeugen - so krass ist meine Unfähigkeit dann doch noch nicht!
Aber damit schafft man pro SPI-Datenbyte mal gerade so zwei Nutz-Bits zu 
erzeugen, ob das besser ist, als mein "Gebastel", wo ich tatsächlich mit 
jedem SPI-Byte auch ein komplettes Datenbyte ausgebe?
Am Ende soll ja schließlich möglichst viel Rechenzeit zum Berechnen der 
Daten parallel zur Ausgabe übrig bleiben...

Hmmm - also, ich versuche es mal zu übersetzen:

Ohne "Gebastel", dafür mit UART:
- UART ist belegt, steht also nicht mehr für Übertragung von Daten von 
außen an den Controller zur Verfügung,
- pro LED (3 "Nutzbyte") = 8 Sende-Interrupts für 24 bits,
- Umsetzung der RGB-Nutzdaten in 8 Bytes Sendedaten notwendig (in der 
ISR: verlängert die ISR-Laufzeit, oder vorher: mehr Auslastung des 
Sendepuffers). In jedem Fall sind es wohl auch ein paar Takte, die für 
die Transformation der Daten notwendig sind.

Mit "Gebastel":
- ich kann meinem Controller noch Daten und Befehle über UART schicken,
- nur 3 Sende-Interrupts pro LED,
- RGB-Werte müssen nicht übersetzt werden.

Nein Danke, ich bleibe erstmal bei meinem Gebastel (und: Basteln macht 
Spass!)

c-hater schrieb:
> Thomas Elger schrieb:
>
>> Ohne "Gebastel", dafür mit UART:
>> - UART ist belegt, steht also nicht mehr für Übertragung von Daten von
>> außen an den Controller zur Verfügung,
>
> Zum einen gibt es durchaus nicht wenige AVRs, die über mehr als nur eine
> USART verfügen, zum anderen ist die USART zur Übertragung von
> Steuerinformationen heutzutage nicht mehr ganz so wichtig wie
> früher(tm).

Ja, ich bin dann wohl ein ziemlicher Hinterwäldler, weil ich immer noch 
diese antiquarische Schnittstelle zum Senden von Daten vom PC an den µC 
bevorzuge...
Ich kenne auch µCs mit noch mehr UARTs, trotzdem will ich das nicht so 
machen, weil es einfach mehr CPU-Zeit erfordert, und außerdem offenbar 
auch noch einen Inverter! Ich frage mich gerade, was mehr "Gebastel" 
ist: der zusätzliche Inverter-Chip oder die bei mir notwendige simple 
Verbindung zwischen zwei benachbarten Pins am µC?

>
>> - pro LED (3 "Nutzbyte") = 8 Sende-Interrupts für 24 bits,
>
> Wer sagt, daß man die regelmäßige, taktgenau vorhersehbare Hauptarbeit
> eines µC in Interrupts abhandeln muß? Nur Idioten sagen sowas. Nein,
> natürlich wird man einem µC, dessen Hauptaufgabe es ist, unendlich lange
> WS2811-Ketten anzusteuern, erlauben, das in "main()" zu tun. Gerade
> dann, wenn man einen Hardware-DoubleBuffer zur Verfügung hat, um das
> Timing auch dann nicht abreißen zu lassen, wenn zwischendurch Interrupts
> abzuarbeiten sind.

Du willst also behaupten, es sei besonders schlau, der main() 
aufzuzwingen, regelmäßg alle 3,75 Mikrosekunden ein Datenbyte 
auszugeben? Gut, durch Dein "Double-Buffering" dürfen es dann vielleicht 
auch mal 7 Mikrosekunden sein, wenn es dafür im nächsten Schritt wieder 
entsprechend schneller geht.
Was ist, wenn die Berechnung eines RGB-Pixels z.B. mal 20µs dauert?
Ich sehe das so: die main() soll rechnen und sich nicht mit stupiden 
Ausgabe-Timing-Vorgaben herumschlagen. Letzteres sollte am Besten eine 
DMA-Ausgabe erledigen, ohne DMA dann ersatzweise eben ein 
Interrupt-getriebener Software-FIFO.


> Ich brauch für die LEDs überhaupt keinen Interrupt-Overhead, weil der
> ganze WS2812-Quatsch als Hauptaufgabe des µC natürlich in "main()"
> läuft.

s.o.
Wenn Deine LED-Applikation primitiv genug ist, daß Deine main alles 
Timing-korrekt ausführen kann: schön für Dich!


> Warum habe
> ich an dieser Stelle nicht optimiert? Ganz einfach:
>
> Kein Schwein ist in der Lage, die FB schnell genug zu betätigen, daß
> diese Konvertierungsroutine jemals zeitkritisch werden könnte...

Was hat jetzt die Eingabe per FB-Tasten mit der Berechnung und Ausgabe 
von LED-Daten zu tun?

>
> Du hast noch viel zu lernen. Insbesondere, zu erkennen, worauf es
> wirklich ankommt...

Oh, danke, großer Meister, daß Du mich auf meine grenzenlose 
Unwissenheit aufmerksam machst und mich endlich die echte Wahrheit 
lehrst!

Es ist ja ziemlich egal, ob man das mit UART, SPI oder Bitbanging macht, 
bei dem engen Timing ist so ein 8-Bitter damit dicht. Da frage ich mich 
schon, ob es durch die ewigen Sprünge in die Interruptroutinen mit den 
damit verbundenen PUSH/POP Routinen nicht sogar deutlich länger zum 
Rausschieben der Daten braucht als beim Bit-Banging.

Ich habe es auch mit Bit-Banging realisiert, selbst für 100 oder 200 LED 
ist der Datenstrom so schnell rausgeschoben, dass der danach alles 
mögliche andere machen kann. Im Prinzip ist das nur eine Routine zum 
Rauschieben der LED Daten.

Und 120m LED Streifen wären 1800 LED bzw. 10800 Bytes. Könnte man im RAM 
ablegen, wenn man nicht gerade einen Tiny nimmt.

Gruss
Axel

Nur so Interessehalber - die Stromversorgung ist ja eine Sache, aber 
machen nicht bei 120m Datenleitung auch die Ausgangstreiber des 
PIC/AVR/whatever mal die Grätsche?

Martin Luerssen schrieb:
> aber
> machen nicht bei 120m Datenleitung auch die Ausgangstreiber des
> PIC/AVR/whatever mal die Grätsche?

die 120m werden ja nicht getrieben, es wird bei LED Stripes nur die 
Leitung zur ersten LED getrieben, danach verstärkt jede LED für die 
weiteren.

Ist die erste LED etwa 120m weit entfernt? sieht man an der 
Ausgangsfrage nicht.

Danke,klar. Hatte erst nen Denkfehler.

Axel Laufenberg schrieb:
> Es ist ja ziemlich egal, ob man das mit UART, SPI oder Bitbanging macht,
> bei dem engen Timing ist so ein 8-Bitter damit dicht.

Nicht unbedingt! Bei meiner Lösung wird der Controller (PIC12F1840) 
durch die LED-Datenausgabe zu etwa 1/3 ausgelastet, d.h. bei 32MHz Takt 
bleibt quasi ein 20MHz getakteter PIC übrig, der Daten "on the fly" 
berechnen kann.
Damit kann ich mehrere "Objekte" unabhängig voneinander über einen 
praktisch beliebig langen LED-Streifen laufen lassen, obwohl der 
Controller nur läppische 256 Bytes RAM hat. Mir ging es dabei aber auch 
eher um die Knobelei, sowas mit geringsten Mitteln hinzubekommen, als um 
eine simple Lösung mit "overkill-Hardware".

> Da frage ich mich
> schon, ob es durch die ewigen Sprünge in die Interruptroutinen mit den
> damit verbundenen PUSH/POP Routinen nicht sogar deutlich länger zum
> Rausschieben der Daten braucht als beim Bit-Banging.

Wie vorher geschrieben, wird da nix langsamer. Die 
Ausgabegeschwindigkeit ist auf 800kbit/s nach Datenblatt eingestellt. 
PUSH und POP gibt's bei meinem PIC nicht.

Grüße,

Thomas

Thomas Elger schrieb:
> Axel Laufenberg schrieb:
>> Es ist ja ziemlich egal, ob man das mit UART, SPI oder Bitbanging macht,
>> bei dem engen Timing ist so ein 8-Bitter damit dicht.
>
> Nicht unbedingt! Bei meiner Lösung wird der Controller (PIC12F1840)
> durch die LED-Datenausgabe zu etwa 1/3 ausgelastet, d.h. bei 32MHz Takt
> bleibt quasi ein 20MHz getakteter PIC übrig, der Daten "on the fly"
> berechnen kann.

Ok, bei 32 MHz stimmt das. Ich hatte das mal auf einem 8 MHz AVR 
implementiert, da ist der Gewinn längst nicht so gross. Der hatte aber 
widerum genug Speicher.

Aktuell habe ich das auf einem ESP8266 am laufen, da hat man die Option 
sowieso nicht.

Gruss
Axel

Ein 8 MHz AVR und ein 32 MHz PIC sind ungefähr gleich in der 
Rechenleistung.