Hallo, ich habe eine Frage zu adressable LED stripes - soetwas wie diesem hier: https://www.pololu.com/product/2548 wieviele davon kann man hintereinander betreiben, wenn jede einzelne mit Strom versorgt wird. Also ist es möglich sagen wir 120m Led streifen aneinander zu hängen und immernoch jede einzelne LED zu steuern? Gruß
:
Verschoben durch Admin
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.
Die Update-Rate wurde ja schon genannt, weitere Grenze: Bei WS2812 müssen die kompletten Daten im RAM sein, damit sie an einem Stück gesendet werden können. Die RAM-Speicher-Größe der MCU begrenzt also die Länge. Die Streifen mit APA102 sind hier flexibler. Bei denen kann die Daten z.B. so langsam raus geben, wie man die Muster gerade berechnet oder auch mal eine ISR zwischendrin bearbeiten: https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/
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.
Torsten_C schrieb: > Bei WS2812 müssen die kompletten Daten im RAM sein, damit sie _an einem_ > Stück gesendet werden können. Die RAM-Speicher-Größe der MCU begrenzt > also die Länge. Man könnte natürlich einfach auch so programmieren, dass die Berechnung in Echtzeit erfolgt. Bei maximal 800kBit/s Richtung LEDs muss man nur eine Datenrate von 100kByte/s schaffen. Bei 20MHz stehen also für die Berechnung und den Versand jedes verschissenen Bytes 200 Takte zur Verfügung. Darin kann man wohl locker alles berechnen, was für eine solche Anwendung üblicherweise nötig ist. Oder was für ein ausgefallenes Muster schwebt dir vor, welches man nicht in dieser Zeit berechnen könnte?
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.
Pink Shell schrieb: > Das heisst man braucht > externe Hardware, und zwar nicht nur ein einfaches Shift-Register. Oder so etwas: http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf
Pink Shell schrieb: > 200 Takte pro Byte heisst aber, dass die Bits per Hardware geschoben > werden müssen. Richtig. > Bei dem etwas proprietären Timing der WS2812 wird das mit > einem einfachen Controller kaum funktionieren. Natürlich geht das problemlos. Bei AVR8 z.B. hat man die Wahl zwischen SPI, USART oder USI, um das zu realisieren. Je nachdem, was im verwendeten AVR drinsteckt. Irgendetwas davon hat wohl wirklich absolut jeder. Man muß die gebotene Hardware einfach nur sinnvoll nutzen. Ja, es ist nicht ganz so einfach wie "out UDR,NextDataByte", aber auch nicht wesentlich komplizierter. Man muß einfach nur mal ernsthaft darüber nachdenken...
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.
Pink Shell schrieb: > Der andere Link ist ja für WS2811, die mit der extra Clock-Leitung. WS2811 ist der Chip in den WS2812 LEDs...
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: > Ein bisschen ein Gebastel ist das aber schon. Aber durchaus interessant. > Gibt es sowas auch auf AVR-Basis? Ja, viel besser, und mit wesentlich weniger "Gebastel"... Allerdings: das Prinzip (Zuhilfenahme der UART o.ä. Hardware, Hauptsache, dass sie ein Schieberegister beinhaltet) wäre natürlich mit den PICs ganz genauso realisierbar. Und ich bin mir ziemlich sicher, daß es irgendwo auch einen fähigen PIC-Programmierer geben wird, der es bereits umgesetzt hat.
Pink Shell schrieb: > MCP schrieb: >> WS2811 ist der Chip in den WS2812 LEDs... > Ja, richtig. Aber gab es da nicht einen Chip mit Clk und Daten getrennt? Meinst du vielleicht den WS2801? c-hater schrieb: > Ja, viel besser, und mit wesentlich weniger "Gebastel"... Geht das auch ein bisschen genauer?
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...
:
Bearbeitet durch User
Thomas Elger schrieb: > Aber damit schafft man pro SPI-Datenbyte mal gerade so zwei Nutz-Bits zu > erzeugen Richtig. Deswegen nehme ich auch die UART, damit gehen drei. Außerdem ist die beim AVR im Gegensatz zum SPI double buffered, was die Freiheiten bei der Benutzung der verbleibenden Takte massiv erhöht.
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: > Man könnte natürlich einfach auch so programmieren, dass die Berechnung > in Echtzeit erfolgt. Das geht nicht, wenn der µC mit dem Bit-Timing beschäftigt ist. Um das zu vermeiden gibt es - wie gesagt - viele Ansätze: UART, Timer+DMA, bitbang-DMA, ... UART ist am effizientesten: Drei Bit bekommt man in einem Byte mit "n,8,1" unter. Also 8 Bytes DMA-Puffer pro RGB-Wert. Allerdings muss TXD dabei invertiert werden. Mit UART + DMA gehen vielleicht auch Fraktale ;-) im Hintergrund.
Oliver R. schrieb: > Da sollstest Du mindestens alle 10 Meter ein Netzteil setzen. Ach nee :-( Hannes Häppi schrieb: > wieviele davon kann man hintereinander betreiben, wenn jede einzelne mit > Strom versorgt wird.
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). > - 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. In diesen Interupts wird nämlich das restliche Zeug abgehandelt, z.B. die Hostkommunikation (viel mehr wird es ja sowieso nicht sein als das). > - Umsetzung der RGB-Nutzdaten in 8 Bytes Sendedaten notwendig Das stimmt natürlich. Der Aufwand dafür ist aber bei auch nur halbwegs cleverer Programierung durchaus erträglich. > Mit "Gebastel": > - ich kann meinem Controller noch Daten und Befehle über UART schicken, Könnte ich auch. Mein AVR hat nämlich zwei davon. Tatsächlich speise ich die Steuerungskommandos allerdings per IR-Fernbedienung ein und verarbeite sie in einem Timer-Interrupt. > - nur 3 Sende-Interrupts pro LED, 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. > - RGB-Werte müssen nicht übersetzt werden. Bei den fest enthaltenen Programmen müssen sie bei mir nichtmal übersetzt werden, da kommen sie nämlich aus Tabellen im Flash. Aber es gibt auch einen "free mode", bei dem tatsächlich die Konvertierung erfolgen muß. Kostet exakt teure 17 Takte pro LED und Farbkomponente (und wäre ziemlich wahrscheinlich noch etwas optimierbar). 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... Du hast noch viel zu lernen. Insbesondere, zu erkennen, worauf es wirklich ankommt...
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!
:
Bearbeitet durch User
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.
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: >> 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. Der macht das Context Saving sogar automatisch während er ins Interrupt spring.
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
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.