Hallo Forum,
ich hab versucht einen WS2812 RGB LED Ring mit dem Raspberry Pi 3
anzusteuern. Klappte leider nicht :(
Mit meinem Arduino ging es problemlos, die LEDs sind also in Ordnung.
Für den Raspberry Pi 3 benutzte ich die Library von jgarff
(https://github.com/jgarff/rpi_ws281x.git) die auch im Adafruit Tutorial
beschrieben wird
(https://learn.adafruit.com/neopixels-on-raspberry-pi/software). Leider
bekomme ich damit nur Flackern. Kann gut sein, dass es mit älteren
Raspberry Pis funktioniert, mit dem 3er wohl nicht.
Hat es von euch jemand geschafft WS2812 mit dem Pi 3 anzusteuern?
Viele Grüße,
Flo
es soll wohl gehen, ich bleibe skeptisch weil der PI kein Echtzeitsystem
ist und das Timing eben nicht eingehalten werden kann.
Vielleicht findest du ja andere LIBs für den PI die das besser können.
Flo schrieb:> Für den Raspberry Pi 3 benutzte ich die Library von jgarff ... Leider> bekomme ich damit nur Flackern. Kann gut sein, dass es mit älteren> Raspberry Pis funktioniert, mit dem 3er wohl nicht.
Hast du die Build Instructions gelesen? Welches Timing benutzt du?
Grundsätzlich sollte das mit jedem Pi gehen, ob Bit Banging, native SPI
oder über die Pi's PWM/DMA Schnittstelle des o.g. Autors.
Joachim B. schrieb:> es soll wohl gehen, ich bleibe skeptisch weil der PI kein> Echtzeitsystem> ist und das Timing eben nicht eingehalten werden kann.
Gerade SPI "Timings" mit niedrigen Durchsatz, die idR sehr flexibel
sind, bekommt man auf einem Single Core Pi mit Bit Banging hin. Sollte
tatsächlich mal Suspended worden sein, setzt man einfach neu auf. Bei
einem Multi Core seized man einen Core im RT Modus. Unabhängig davon
gibt es noch die dedizierten SPI und PWM/DMA Schnittstellen oder einfach
GPIO/DMA, die man auch aus Userland ansprechen kann. [Raspbian]
Mikro 7. schrieb:> Gerade SPI "Timings" mit niedrigen Durchsatz, die idR sehr flexibel> sind, bekommt man auf einem Single Core Pi mit Bit Banging hin.
Es gibt aber bei WS2812b LEDs keinen Clock, nach einer langen
Bitschieberei muss das Timing für die Übernahme stimmen.
Ich wüsste im Moment nicht ob man das im SPI hinbekommt weil dazu auch
immer SCK gehört, oder darf man den dann ignorieren?
Joachim B. schrieb:> Es gibt aber bei WS2812b LEDs keinen Clock, nach einer langen> Bitschieberei muss das Timing für die Übernahme stimmen.
Ah, ok, habe gerade mal das Datenblatt angeschaut. Kein Clock. Die
Timings sind auch schon so, dass man beim Bit Banging etwas mehr
aufpassen muss. Ungepactes DMA/GPIO könnte evtl daneben gehen.
Über PWM/FIFO/DMA (gepaced) wie vom Autor oben sollte das problemlos
sein. SPI sollte imho auch gehen, Clock liegt dann halt frei.
> Ich wüsste im Moment nicht ob man das im SPI hinbekommt weil dazu auch> immer SCK gehört, oder darf man den dann ignorieren?
Ich hatte bisher noch keinen WS2812b. Werd' ich mir mal bestellen und
angucken. :-)
Mikro 7. schrieb:> Ich hatte bisher noch keinen WS2812b. Werd' ich mir mal bestellen und> angucken. :-)
und wieder jemand der hier auf etwas Antwortet von dem er keine Ahnung
hat und nur Unsinn schreibt.
Und nein, die WS2812 haben mit SPI nichts zu tun und auf einem normalen
Pi geht das auch nicht per SPI. Das Timing ist nicht stabil genug und
läuft weg, die Folge ist Farbflackern.
Levelshifter ist verbaut. 5V wird von extern bezogen (nicht vom PI). GND
vom PI und von der Stromquelle sind verbunden. Nutzt aber alles nichts.
Bisher hab ich im Netzt noch nichts gefunden was beschreibt wie WS2812
mit einem PI 3 funktioniert.
Mal noch ne ganz andere Frage: Wenn ich mir einen ATMEGA328 dazwischen
schalte (mit den (angepassten) Neopixel Libs von Adafruit), würde das
funktionieren? Ich meine wegen der internen Clock. Wäre die fürs Timing
genau genug?
Flo schrieb:> Mal noch ne ganz andere Frage: Wenn ich mir einen ATMEGA328 dazwischen> schalte (mit den (angepassten) Neopixel Libs von Adafruit), würde das> funktionieren? Ich meine wegen der internen Clock. Wäre die fürs Timing> genau genug?
LOL.
Sicher, WS2812 kann man von 400KHz bis (fast) 1MHz ansteuern.
Nur die Pause zwischen 2 Bytes soll nicht länger als etwa 20us sein,
ansonsten werden die Daten gelatcht und angezeigt - auch wenn 50us
angegeben sind - WS2812 sind in der Beziehung ein bisschen zickig.
Horst schrieb:> Und nein, die WS2812 haben mit SPI nichts zu tun und auf einem normalen> Pi geht das auch nicht per SPI. Das Timing ist nicht stabil genug und> läuft weg, die Folge ist Farbflackern.
Und ja, mit SPI kann man die Dinger auch ansteuern, nur braucht das
wesentlich mehr RAM und bringt keine Vorteile, ausser man macht das
per DMA.
Marc V. schrieb:> Und ja, mit SPI kann man die Dinger auch ansteuern, nur braucht das> wesentlich mehr RAM
wieso?
leuchtet mir grad nicht ein,
bis jetzt hatte ich immer RGB Arrays a 3 Byte für jede LED
ob die nun so rumliegen 100 LEDs -> 300 Byte und egal wie auch per SPI
müssen die rausgeschoben werden, wo kommt also dein genannter
Mehrverbrauch her?
ich steuere die WS2812b auch über SPI an. Dabei wird ein WS Bit durch 3
SPI Bits erzeugt. Mit einem SPI Takt von 2,4 MHz bekommt man Bitzeiten
von 416 ns, mit 1-0-0 oder 1-1-0 passt die 800 kHz Ansteuerung also.
Wichtig ist das man den SPI Takt genau einstellen kann, mit Cortex-M von
NXP klappt das gut, mit dem STM32F103 habe ich das nicht hingebkommen
weil der nur eine 2^n Teilerstufe für den Takt hat.
Wenn man ein die 1-auf-3 Expandierung in der SPI Ausgabe macht braucht
man nicht mehr Speicher. Die SPI Implementierung beim RaspPi kenne ich
nicht, wenn die blockweise arbeitet muss man eventuell den Framebuffer
vor der Ausgabe enkodieren und braucht damit mehr RAM. Was auf dem RPi
aber nicht wirklich stört...
Das ist aber ein SPI 'Missbrauch' und man hat keine Garantie das diese
Methode auf eweig funktioniert. Auch bei den LPC habe ich verschiedene
SPI Hardware Implementierungen gefunden die Unterschiedliche Behandlung
in der SW nötig machte.
PS:
ein LPC812 wäre ein günstiger Treiber: Slave SPI um die RGB-Frames über
'echtes' SPI zu empfangen, und eine zweite SPI um die LED Kette zu
steuern. Der LPC braucht keine aufwändige HW, nur einen
Abblockkondensator wenn man will. Programmierung über Bootloader im ROM
per RS232-TTL Adapter.
Joachim B. schrieb:> ob die nun so rumliegen 100 LEDs -> 300 Byte und egal wie auch per SPI> müssen die rausgeschoben werden, wo kommt also dein genannter> Mehrverbrauch her?
Weil die bits nicht 1:1 rausgetaktet werden.
Entweder man enkodiert es vorher, dann braucht es mehr RAM, geht
aber schneller oder man enkodiert es in Echtzeit bei der Ausgabe,
dann bringt das aber keine Vorteile gegenuber Bitbanging.
Marc V. schrieb:> Weil die bits nicht 1:1 rausgetaktet werden.
das erklärt es
Johannes S. schrieb:> ich steuere die WS2812b auch über SPI an. Dabei wird ein WS Bit durch 3> SPI Bits erzeugt.
und leuchtet (mir auch ein)
Marc V. schrieb:> oder man enkodiert es in Echtzeit bei der Ausgabe,> dann bringt das aber keine Vorteile gegenuber Bitbanging.
Doch. Denn das Encodieren des nächsten Bytes kann erfolgen während das
vorherige noch herausgrtaktet wird.
Mit dem UART müsste es übrigens auch gehen, selbes Prinzip.
Bernd K. schrieb:> Doch. Denn das Encodieren des nächsten Bytes kann erfolgen während das> vorherige noch herausgrtaktet wird.
Bringt keine nennenswerten Vorteile.
Bei Bitbanging ist die CPU Auslastung 100% aber mit 800KHz geht das
Ganze relativ flott heraus.
Bei SPI und Encodierung in Echtzeit geht das raussenden zwar ohne das
die CPU belastet wird, aber die Encodierung und das ständige hin- und
herspringen von main zu ISR machen das wieder zunichte.
Einzig sinnvolles Verfahren mit SPI ist vorheriges vorbereiten und
Ausgabe mit DMA.
> Mit dem UART müsste es übrigens auch gehen, selbes Prinzip.
Das macht erst recht keinen Sinn - bei welcher Geschwindigkeit soll
das von sich gehen ?
Beim SPI sehe ich noch den Vorteil das man gegenüber BB unabhängiger vom
CPU Takt ist. Die SPI Implementierung funktioniert auf einer ganzen
Reihe von µCs ohne mühsehlig Takte zählen zu müssen.
Marc V. schrieb:>> Mit dem UART müsste es übrigens auch gehen, selbes Prinzip.>> Das macht erst recht keinen Sinn - bei welcher Geschwindigkeit soll> das von sich gehen ?
Der kann angeblich bis zu 4MBaud, da lässt sich evtl schon ein Bitmuster
im passenden Timing erzeugen das der ws2812 schluckt.
Marc V. schrieb:>> Mit dem UART müsste es übrigens auch gehen, selbes Prinzip.>> Das macht erst recht keinen Sinn - bei welcher Geschwindigkeit soll> das von sich gehen ?
Oh mein Gott, einfach mal rechnen?
Fakt ist, dass es selbst mit einem AVR@20MHz relativ problemlos möglich
ist, per SPI (bzw. hier: UART im SPI-Modus) die Daten ohne Jitter und
mit Vmax rauszuschicken. Ein fertige, voll funktionsfähige
Implementierung dafür habe ich schonmal hier geposted.
Und an diesem kann man auch sehr schön sehen, dass die Sache selbst bei
so einem AVR enorme Vorteile bringt: Statt nämlich die MCU zu 100% mit
überwiegend dümmlicher Vernichtung von Rechenzeit auszulasten, benötigt
man nur ca. 45% der Rechenzeit für die Aufbereitung und Ausgabe des
auszugebenden Bitstreams. Das läßt dann genug Rechenzeit über, dass man
sehr viele Effekte sogar in Echtzeit berechnen kann, dann also überhaupt
keinen "display buffer" im RAM benötigt.
Und wo es entweder nicht mehr in Echtzeit berechenbar ist, weil es zu
komplex wird oder weil das Gewünschte mathematisch überhaupt nicht
abbildbar ist, dann braucht man exakt so viel RAM als Displaybuffer wie
in jeder anderen Lösung auch. Nämlich Anzahl der LEDs * 3 Farben.
Bloß, dass man dann trotzdem halt immer noch dauerhaft 45% der
Rechenzeit über hat, um diesen Buffer auch permanent mit den Daten zu
füllen, die ausgegeben werden sollen. Mit Vmax wohlgemerkt, also mit
voller Ausnutzung der Fähigkeiten der WS28xx bezüglich der erzielbaren
Framerate...
Vielleicht lernst du endlich mal programmieren?
Übrigens: Wenn man die UART tatsächlich als UART (und nicht im
SPI-Modus) verwendet, geht es nochmal ein wenig besser, dann kommt man
sogar auf knapp über 60% freier Rechenzeit. Leider ist beim AVR dafür
ein kleiner Trick nötig, weil Atmel keine Möglichkeit spendiert hat, die
Polarität der Ausgabe am TX-Pin in Hardware zu invertieren. Beim Raspi
ginge das hingegen schon...
@Flo:
Beim Raspi ware das Prinzip (egal ob SPI oder UART) leider deutlich
komplizierter umzusetzen als beim AVR. Jedenfalls wenn Linux als OS die
Basis sein soll...
Dazu würde nämlich der Kern meiner AVR-Lösung als Treiber umgesetzt
werden müssen, sonst grätscht das nicht echzeitfähige System für den
userspace immer mal wieder in die Ausgabe des Bitstreams
ein->unbrauchbar.
Und das Schreiben so eines Treibers ist nicht ganz trivial, das wäre
auch für mich richtig Arbeit.
Da werfe ich lieber Linux ganz weg und programmiere den Raspi bare
metal. Erst dann wird wirklich klar, wieviel schneller als ein AVR so
ein Teil wirklich ist...
Und nebenbei: wie ungeeignet Linux eigentlich für die Aufgaben ist, die
ein µC üblicherweise zu erledigen hat...
Johannes S. schrieb:> Beim SPI sehe ich noch den Vorteil das man gegenüber BB unabhängiger vom> CPU Takt ist. Die SPI Implementierung funktioniert auf einer ganzen> Reihe von µCs ohne mühsehlig Takte zählen zu müssen.Bernd K. schrieb:> Der kann angeblich bis zu 4MBaud, da lässt sich evtl schon ein Bitmuster> im passenden Timing erzeugen das der ws2812 schluckt.
Mag sein, ich bleibe trotzdem bei Bitbanging - 170 LEDs in weniger als
5ms bei etwas gestrafftem Timing reicht für mich (und Systimer)
vollkommen.
Bei 50Hz Refreshrate ergibt das 25% CPU Auslastung.
c-hater schrieb:> Und wo es entweder nicht mehr in Echtzeit berechenbar ist, weil es zu> komplex wird oder weil das Gewünschte mathematisch überhaupt nicht> abbildbar ist, dann braucht man exakt so viel RAM als Displaybuffer wie> in jeder anderen Lösung auch. Nämlich Anzahl der LEDs * 3 Farben.
Sicher.
Aber nur in deinem Kopf und in deiner (Wunsch)Anwendung.
WS2812 braucht 10us pro Byte. Die SPI rumschieberei dauert auch nicht
viel weniger, da geht deine geniale Lösung schon flöten. Und die
ständige rumhopserei zur ISR und wieder zurück lassen wir mal vorerst
beiseite.
c-hater schrieb:> Vielleicht lernst du endlich mal programmieren?
Tja, genau dasselbe wollte ich dir vorschlagen...
c-hater schrieb:> Und das Schreiben so eines Treibers ist nicht ganz trivial, das wäre> auch für mich richtig Arbeit.
Ja, ohne Ende.
Du willst es nicht kapieren oder bist nicht dazu imstande ?
Man kann nicht mehr als 2 bits für WS2812 in einen SPI-Byte
packen, es sind also 4 SPI-Bytes pro RGB-Byt notwendig.
Mal angenommen, dein Byte wird mit 4 SPI-Aufrüfen gesendet.
Ohne DMA gibt es nur 1 Möglichkeit:
ISR wird nach jedem Byte angesprungen:
1
==============================
2
ISRAufruf=3Cy
3
8RegisterPUSH=8Cy//* Laden der Indexregister sei dir geschenkt
8RegisterPOP=8Cy//* Selbst mit nur 4 Registern sind es 14us
6
ISRreti=4Cy
7
==============================
8
Gesamt=32Cy
32Cy * 4 Aufrufe = 128Cy = 16us bei 8MHz.
Anstatt 9-10us bei Bitbanging.
Dann gibt es noch die Möglichkeit, dass du alle RGB-Bytes
vorher schon als SPI-Bytes vorbereitet hast, dafür braucht man
aber 4 Mal so viel RAM (alle LEDs) - oder für jede LED bzw. für
RGB-Byt wird eine Berechnung durchgeführt, was aber wiederum keinerlei
Vorteile bezüglich der Zeit bringt.
Nehmen wir aber an, dass du trotzdem irgendwie den ganzen Kram ohne
das vierfache an RAM zu brauchen, in einem Stück rausschickst.
ISR muss aber nach jedem Byte angesprungen werden:
1
==============================
2
ISRAufruf=3Cy//* Übernahme (Portzustand) sei dir geschenkt
3
8RegisterPUSH=8Cy//* Laden der Indexregister sei dir auch geschenkt
4
Send=2Cy//* deswegen nur ld und out SPDR
5
8RegisterPOP=8Cy
6
ISRreti=4Cy
7
==============================
8
Gesamt=25Cy
25Cy * 4 Aufrufe = 100Cy = 12,5us bei 8MHz.
Anstatt 9-10us bei Bitbanging.
Und die Vorbereitung aller Bytes im ersten Fall oder die
Vorbereitung der 4 Bytes in zweitem Fall sei dir wieder
geschenkt.
Und wie du auf 45% der CPU-Zeit kommst, ist mir wirklich nicht klar,
dir höchstwahrscheinlich auch nicht.
Es macht Sinn, mit dem Raspi die Bilddaten zu generieren und dann an ein
kleines uC Board zu schicken, welches dann die WS2812 mit genauem Timing
ansteuert.
Oder man kann ein LattePanda Board nehmen, das hat für solche Zwecke
nebst der Fetten CPU noch einen Mikrocontroller integriert (ATMega32u4).
Ich meine irgendwo gelesen zu haben, dass man Ubuntu auf dem LattePanda
zum laufen bekommt.
http://www.lattepanda.com/
Mw E. schrieb:> Also SPI per DMA ausm RAM und gut is.
Sage ich doch die ganze Zeit.
Ohne DMA und genügend RAM ist das in jedem Fall absoluter Blödsinn.
Mit DMA dagegen ist es wie mit den Missiles - "Fire-and-forget" -
macht also durchaus Sinn...
Marc V. schrieb:> Mw E. schrieb:>> Also SPI per DMA ausm RAM und gut is.>> Sage ich doch die ganze Zeit.> Ohne DMA und genügend RAM ist das in jedem Fall absoluter Blödsinn.>> Mit DMA dagegen ist es wie mit den Missiles - "Fire-and-forget" -> macht also durchaus Sinn...
Ist es denn beim Raspi mit Raspbian garantiert, dass bei DMA-Betrieb
absolut nie eine Wartezeit zwischen zwei Bytes auftreten kann?
Denn bei WS2812 ist das wirklich wirklich essentiell, dass das Timing
über das gesamte "Datenpacket" stimmig ist. Ansonsten flackern dann
einzelne oder mehrere LED's, was ziemlich schlimm aussieht.
Marc V. schrieb:> Du willst es nicht kapieren oder bist nicht dazu imstande ?> Man kann nicht mehr als 2 bits für WS2812 in einen SPI-Byte> packen, es sind also 4 SPI-Bytes pro RGB-Byt notwendig.
Das ist falsch. Bei geeignetem Takt benötigt man genau 3 SPI Bits für
ein WS2812 Bit, also 1:3 Verhältnis.
Deine ganzen Berechnungen beziehen sich auf 8MHz Takt. Nehmen wir doch
mal 16MHz oder 20MHz an. Dann schluckt Bit Banging immer noch 100% CPU,
die ISR Version kann dann aber ihren Charme ausspielen, dass nämlich
zwischendurch doch noch etwas im Hauptprogramm erledigt werden kann.
Markus M. schrieb:> Das ist falsch. Bei geeignetem Takt benötigt man genau 3 SPI Bits für> ein WS2812 Bit, also 1:3 Verhältnis.
Kann sein, nur muss man dann bei der Vorbereitung mit 2 Bytes
gleichzeitig arbeiten, die ganze Schieberei braucht ganz schön Zeit.
Die ISR braucht immer noch mindestens 32Cy * 3 Aufrüfe, ergibt 96Cy.
> Deine ganzen Berechnungen beziehen sich auf 8MHz Takt. Nehmen wir doch> mal 16MHz oder 20MHz an. Dann schluckt Bit Banging immer noch 100% CPU,> die ISR Version kann dann aber ihren Charme ausspielen, dass nämlich
Ich war schon grosszügig bei der ISR berechnung, entweder übernahme
des Portzustands oder ein ganzes Port wird für 1 bit gebraucht.
Laden der Indexregister braucht auch eine gewisse Zeit, oder ?
Und nur 8 Register zu retten genügt bestimmt nicht, dann ist da auch
noch SREG...
Also, um fair zu sein, müsste dein uC viel mehr Zeit in der ISR
verbrauchen als von mir angegeben, vielleicht sogar das doppelte.
10us (1 RGB-Byt oder 3 SPI-Bytes) sind bei 20MHz genau 200Cy.
Wenn aber 150-190Cy in der ISR verbraucht werden, für die Vorbereitung
noch mindestens 40-60Cy gebraucht werden, bleibt nicht mehr viel
von angeblichem Charme übrig...
Das ist und bleibt eine Milchmädchenrechnung von Leuten die keine
Ahnung haben.
Entweder SPI+DMA oder Bitbanging - alles andere ist Blödsinn.
Marc V. schrieb:> Du willst es nicht kapieren oder bist nicht dazu imstande ?> Man kann nicht mehr als 2 bits für WS2812 in einen SPI-Byte> packen
Meine hier bereits gepostete (und wie gesagt: voll funktionsfähige)
Lösung beweist schon bei dieser Behauptung das Gegenteil. Sie kommt
nämlich mit drei SPI-Bits pro WS28xx-Datenbit aus. Wenn du mein Programm
verstehen würdest, wäre dir das klar geworden, das ist ja schließlich
für meine Verhältnisse ungewöhnlich ausführlich kommentiert.
Im übrigen ist auch der Rechenzeitverbrauch bereits im Quelltext voll
dokumentiert, für jeden einsehbar und im Simulator Takt für Takt
nachvollziehbar. Du kannst dich also im Kreise drehen, bis du rotglühend
wirst, diese Fakten wirst du nicht wegdiskutieren können...
> Und wie du auf 45% der CPU-Zeit kommst, ist mir wirklich nicht klar,> dir höchstwahrscheinlich auch nicht.
Doch, natürlich. Wie schon gesagt: das Zeitverhalten ist taktgenau im
Quelltext dokumentiert. ICH weiss ganz genau, was ich tue.
> Und die> ständige rumhopserei zur ISR und wieder zurück lassen wir mal vorerst> beiseite.
Die gerade ist aber der eigentlich Trick meiner Lösung, das hast du wohl
auch nicht verstanden. Nur das erlaubt es nämlich, den Bitstream in
Echtzeit zu encodieren und somit ohne den riesigen Mehrverbrauch an
RAM auszukommen, den du zu apostrophieren beliebtest...
Der Trick ist einfach, dass durch die Interruptnutzung der relative
zeitaufwendige Encodierungsprozess für den Bitstream in die rein zur
Ausgabe benötigten Instanzen der ISR sozusagen reingeschachelt werden
kann. Das geht durch eine sich selbst unterbrechende und hochoptimierte
ISP-ISR.
Ich würde dir empfehlen, das Demo einfach mal so lange im Simulator
laufen zu lassen, bis du das Prinzip verstanden hast. Zusätzlich darfst
du auch gerne in main() (wo sonst eigentlich garnix passiert) eine
kleine Routine einbauen, die einfach nur die dort verfügbaren Takte
kumuliert und dich so von meinen Angaben überzeugen lassen, wenn du
schon die Kommentare bezüglich des Rechenzeitverbrauchs nicht zu
verstehen vermagst...
Natürlich wäre es dafür sinnvoll, in ws28xx_user nicht gerade den
Democode zu verwenden, der ja einen (zumindest auf einem Tiny)
erheblichen Teil der von der eigentlichen WS28xx-Ausgabe freigesetzten
Rechenzeit gleich wieder für die Berechnung des Effektes in Echtzeit
verwendet. Da gehört dann natürlich ein sehr viel simplerer Code hin,
der z.B. ein einfaches Farbbalken-Testbild ausgibt oder aber noch
einfacher: schlicht die RGB-Daten aus dem RAM liest. Damit kommt man
dann wohl vielleicht in die Bereiche, die du zu begreifen und
nachzuvollziehen vermagst...
c-hater schrieb:> Meine hier bereits gepostete (und wie gesagt: voll funktionsfähige)> Lösung beweist schon bei dieser Behauptung das Gegenteil. Sie kommt> nämlich mit drei SPI-Bits pro WS28xx-Datenbit aus. Wenn du mein Programm> verstehen würdest, wäre dir das klar geworden, das ist ja schließlich> für meine Verhältnisse ungewöhnlich ausführlich kommentiert.
Wenn du irgendein Link posten kannst, werde ich wirklich versuchen
deine Lösung zu verstehen.
Vielleicht lerne ich etwas neues, wer weiss...
Marc V. schrieb:> Wenn du irgendein Link posten kannst, werde ich wirklich versuchen> deine Lösung zu verstehen.
Das hast du ja offensichtlich schon damals nicht, denn in dem Thread
hast du mitdiskutiert, wie ich gerade festgestellt habe.
> Vielleicht lerne ich etwas neues, wer weiss...
Meiner Einschätzung nach: Eher nicht.
Aber für die, die wirklich was lernen wollen darüber, wie man aus
kleinen µC das Optimum herausholt, hier doch noch der Link zum Artikel
mit Originalcode und Video als Funktionsbeleg:
Beitrag "The secret of WS2812B"
Natürlich ist nur der mit FunctionDemo benannte Kram aus den Anhängen
hier in diesem Zusammenhang relevant.
Was das eigentliche Thema des damaligen Threads betrifft, bin ich
übrigens effektiv immer noch keinen Schritt weiter...
c-hater schrieb:> kleinen µC das Optimum herausholt, hier doch noch der Link zum Artikel> mit Originalcode und Video als Funktionsbeleg:>> Beitrag "The secret of WS2812B"
LOL.
Und du hältst immer noch an diesem Blödsinn fest ?
Beitrag "Re: The secret of WS2812B"Beitrag "Re: The secret of WS2812B"
Was deinen Code betrifft:
Ein "Programm" zu schreiben, welches die Farben der 60 LEDs von
RED nach GREEN und dann nach BLUE schiebt und sonst nichts macht
als die genialste Erfindung des 21 Jahrhunderts vorzustellen, kann
auch nur dir in den Sinn kommen.
Die Leute hier reden von einem normalen Programm, da werden bei
Einsprung in die ISR mindestens 10 Register gerettet + SREG +
IndexRegister aus RAM laden + Ausgabe + Indexregister wieder in den
RAM schreiben + jmp + reti.
Mindestens 40Cy.
Mal 3 ergibt 120Cy.
Plus Vorbereitung mit mindestens 40-60Cy, ergibt 160-180Cy.
Ausgabe dauert 10us oder 200Cy bei 20MHz.
Das sind für mich dauernd 80-90% Auslastung bei der Ausgabe.
Und das ist ohne die RGB-Bytes (Farbe) zu verändern, das schenke ich
dir wieder, weil es sonst vielleicht über 200Cy dauert...
Anstatt das Ganze in 1,8ms mit Bitbanging rauszujagen und dann kann
die CPU eine Pause von 18,2ms machen (Framerate 50Hz).
Ergibt eine effektive Auslastung von 10% bei deinen 60 LEDs.
Und sollte zufällig bei dir in der "freien Zeit" ein anderer Interrupt
feuern, z.B. Timer1 mit in etwa nötigen 100Cy in der ISR, sieht die
Sache ganz anders aus.
Wann kapierst du endlich, dass die Ausgabe über SPI ohne DMAabsolut keine Vorteile bringt ?
Und mit DMA auch nur bei 3-fachem RAM.
Was bei ARM und Raspberry kein Problem darstellt, da ist leider deine
Genialität nicht nötig.
Habe nun mal so einen LED Streifen testen können (auf Pi-0 und Pi-2).
:-)
Joachim B. schrieb:> Es gibt aber bei WS2812b LEDs keinen Clock, nach einer langen> Bitschieberei muss das Timing für die Übernahme stimmen.
Mit Bit-Banging aus C heraus ist das in der Tat nicht einfach. Wenn man
vor und nach jeder Flanke die Zeit nimmt und damit die min/max Timings
hält/prüft, dann stellt man sehr häufig fest, dass die max Werte
überschritten wurden (und ich meine nicht das Prozess Scheduling). Mit
genügend Retries läuft es dann "irgendwann". Die Quote bessert sich mit
Überziehen der Timings (die scheinen recht gutmütig zu sein). Aber bei
einer "überschaubaren" Anzahl von LEDs ist das Ende der Fahnenstange
erreicht.
> Ich wüsste im Moment nicht ob man das im SPI hinbekommt weil dazu auch> immer SCK gehört, oder darf man den dann ignorieren?
Ja, kann man. Braucht man nicht mal frei zu schalten. Der SPI Serializer
(SPIO) ist die zweitbeste Wahl. "Einfacher" geht es mit einem der PWM
Serializer. SPI0 und PWM haben verhältnismäßig lange Queues und auch DMA
Support.
Spannend, zum Ausprobieren, wären dann noch direkt DMA auf GPIO, SPI1
Serializer (ohne DMA,kleine Queue) und BSC Slave Serializer (ohne
DMA,kleine Queue,ext. Clock-Pulse).
Bei der Ausgabe über PWM wird der Ballast noch größer. Die Ausgabe per
DMA über den GPIO funktioniert wenn der DMA die Möglichkeit besitzt
diesen zu Takten. Sonst müssen weitete zwischen bits gesetzt werden um
die 800khz zu erreichen. Beim Atmel geht das nicht bei ST offenbar
schon.
Marco H. schrieb:> Bei der Ausgabe über PWM wird der Ballast noch größer.
Größer als was? Im günstigsten Fall die oben beschriebenen 3Bit/Bit wie
bei SPI.
> Die Ausgabe per> DMA über den GPIO funktioniert wenn der DMA die Möglichkeit besitzt> diesen zu Takten. Sonst müssen weitete zwischen bits gesetzt werden um> die 800khz zu erreichen.
Speicher ist genug da. DMA kann bspw. aber auch über Wartezyklen oder
separate Controlblöcke ausgebremst werden. Die Herausforderung ist das
fehlende Pacing.
Als bei SPI oder GPIO.
Beim SPI braucht man 4 Bit minimal 3 du musst ja sicher über/unter 50%
Tastverhältnis kommen.
Beim PWM werden aus jeden Bit -> 8Bit den du in den Counter laden musst
um das Tastverhältnis zu erzeugen. Bei Unglücklichen
Teilerverhältnissen bzw Clocks werden da auch schon mal 16 oder 32Bit
daraus.
Beim SAM3x ist das leider dann auch so das du die Values für den Counter
für die Channels hintereinander setzen musst wenn du diese per DMA in
PWM Modul schiebst. Bsp. Channel0->Channel1->Channel2-> usw.
Das heißt du musst einen kompletten Frame zwischen speichern. Oder eine
Art Ring Buffer bauen in dem du rechtzeitig den next Pointer dran hängst
bevor der Transfer zu ende ist.
Beim ST gibt es wohl die Möglichkeit den Transfer über den Timer zu
takten. Das ist natürlich dann ideal da du die Bits dann zum richtigen
Zeitpunkt ausgeben kannst.
Das über PWM oder auch GPIO zu lösen nimmt man dann in Betracht wenn man
viele WS2812 Channels benötigt. Beim SAM3x sind über den PWM Controller
8 möglich entgegen per USART SPI nur 4 , beim Arduino DUE nur 3 da die
eine USART nicht nach außen geführt ist.
Marco H. schrieb:> Beim PWM werden aus jeden Bit -> 8Bit den du in den Counter laden musst> um das Tastverhältnis zu erzeugen....
Aso... Ich glaube hier gibt es ein Missverständnis: Beim Pi ist die PWM
Schnittstelle u.a. auch als (frei definierbarer) Serialisierer
implementiert. Mit 500 MHz Clock Source und Teiler 200 kann man also
bspw. 3 Bit Sequenzen für den WS2812B erzeugen.
> Das über PWM oder auch GPIO zu lösen nimmt man dann in Betracht wenn man> viele WS2812 Channels benötigt. Beim SAM3x sind über den PWM Controller> 8 möglich entgegen per USART SPI nur 4 , beim Arduino DUE nur 3 da die> eine USART nicht nach außen geführt ist.
Beim Pi gibt es lediglich zwei PWM Kanäle (die auch noch geshared sind)
und einen (full) SPI. Wenn man mehr als 3 WS2812B Ketten hat würde man
wohl einen Dummy SPI/PWM Kanal definieren der das DMA Pacing
bereitstellt und dann über DMA die notwendige Anzahl GPIO Pins direkt
ansteuern.
Über DMA kommt man auch beim Pi schon recht weit. Selbst DMX ist so
schon erzeugt worden. Allerdings muss man aufpassen das niemand
dazwischen funkt. Da ist System Kenntnis gefragt. So gesehen ist die
Lösung mit abgesetzten Board und eigenen µP schon einfacher. Die Daten
für den Streifen kann man dann per SPI vom Pi übertragen. Da denkt man
sich eben ein eignendes Protokoll aus und die SPI Geschwindigkeit vom Pi
reicht alle male aus viele Pixel mit hoher Framerate zu übertragen.
Die noch bessere Lösung ist die Daten über Ethernet aus dem Pi zu
übertragen. z.Bsp per Artnet.
hi, es ist definitiv machbar das mit dem Tutorial und dem flackern hatte
ich auch. es gibt einen unterschied zwischen pin Nummer auf der Leiste
und Ausgang in der Software. 18 ist nicht gleich 18. finde den richtigen
Ausgang und es tut ohne Probleme. ich verwende einen Level converter für
3,3 und 5v
Auch wenn das Thema bis auf die Bitebene herunter schon durchdiskutiert
worden ist: probier einfach mal die Anleitung auf
https://tutorials-raspberrypi.de/raspberry-pi-ws2812-ws2811b-rgb-led-streifen-steuern/
aus; das hat bei mir auch funktioniert (allerdings mit kurzem Strip);
sowohl beim ws2812b wie auch ws2801.
Was allerdings anzumerken ist und auch oben schon beschrieben: allzu
viel sollte man den raspi dann nicht mehr mit anderen Aufgaben
beaufschlagen, sonst klappt das mit dem Timing nicht. Wichtig ist auf
jeden Fall, dass die Audioausgabe deaktiviert werden muss.
Für einen einfachen Test reicht das auf jeden Fall aus
Hui, hier brennt die Luft ;-)
Also... ich steuere 256 WS 2812 LEDs über Raspberry Pi 3 an. Und zwar
mit SPI (8 Mhz). Und das funktioniert tadellos.
Keine Ahnung warum hier so viele Posten das es nicht oder schlecht geht.
ich habe kein flackern, keine Sprünge oder dergleichen.
Vielleicht haben die meisten Probleme damit, weil sie die falsche
Frequenz einstellen, und somit mit den Bits irgendwas kryptisches
ausrechnen müssen, um auf die 800 Khz zu kommen. Doch mit 8 Mhz SPI
Clock passt die 252 und 224 (1/0) perfekt in 24 Bits auf 3 GRB Bytes.
Da muss man nichts krumm rechnen.
Das sind 30 Zeilen Code mit Android.
Hallo
Ich habe große Probleme meine ws2812b am raspberry zum laufen zu
bekommen.
Ich habe jetzt mehrere Anleitungen versucht jedoch ohne erfolg.
Bei dieser Anleitung:
https://tutorials-raspberrypi.de/raspberry-pi-ws2812-ws2811b-rgb-led-streifen-steuern/
bekomme ich beim Befehl "sudo python setup.py build" die Fehlermeldung
"File „/usr/lib/python2.7/zipfile.py“, line 811, in _RealGetContents
raise BadZipfile, „File is not a zip file“
zipfile.BadZipfile: File is not a zip file"
Auch mit anderen Anleitung bekomme ich Fehlermeldungen oder die LED
starten erst garnicht.
Gibt es eine Möglichkeit die LED auf Funktion zu testen? Strom bekommen
die led's von einem 5v 8A Netzteil, dass hab ich auch messen können das
saft ankommt.
Jemand eine Idee wie ich die LED zum leuchten bekomme um generell mal zu
testen ob sie funktionieren? Alle LEDs in einheitlicher Farbe oder so...
Danke
Alles auf
https://github.com/jgarff/rpi_ws281x
durchgelesen und so gemacht?
Dabei ist auch ein "test" Programm: "You should see a moving rainbow
scroll across the display."
Danke für die Rückmeldung
Ja das habe ich schon gesehen und leider hat es nichts gebracht :(
Kann es sein das die ws2812b mit dem PI 3 so ohne weiteres nicht laufen?
Noob schrieb:> Kann es sein das die ws2812b mit dem PI 3 so ohne weiteres nicht laufen?
Die Library wird, wie man unschwer erkennen kann, noch immer gewartet.
Wird also keine generelle Inkompatibilität sein...
Würde mal empfehlen ein frisches OS aufzusetzen (also das Original von
der Foundation), denn andere Programme können gern mal was verstellen
oder gar im Hintergrund dazwischen funken.
Ausserdem auch die Verdrahtung nochmal genau checken.
Noob schrieb:> Ja das habe ich schon gesehen und leider hat es nichts gebracht :(
Du hast also den Takt der Peripherie von 400 MHz auf 250 MHz korrigiert
und die entsprechenden Kernel Module installiert bzw. deistantlliert; so
wie es dort steht?
Dann hast du sowohl über PWM/PCM/SPI getestet -- und dabei die richtigen
GPIO Pins benutzt -- und deine LEDs bleiben dunkel?
Du bist dir sicher, dass Spannung anliegt, dass die Verdrahtung korrekt
ist?
Möglicherweise hast du die GPIO Pins des RPi geschrottet? Wenn du keinen
Logic Ananlyzer / DSO hast, kannst du auch einfach mal die Spannung am
Daten Pin messen. Sollte zwschen 1V und etwas über 2V sein (solange das
"test" Programm läuft).
Ein Logic Analyzer gibt es für einen einstelligen Eurobetrag auf eBay.
Eine empfehlenswerte Anschaffung wenn du dich ernsthaft mit der Thematik
beschäftigen möchtest.
Möglicherweise hast du die erste LED der Kette bereits geschrottet?
Schon mit der zweiten probiert?
> Kann es sein das die ws2812b mit dem PI 3 so ohne weiteres nicht laufen?
Ich habe über PWM und SPI auf dem Rpi3 Led Chains angesteuert.
Noob schrieb:> Jemand eine Idee wie ich die LED zum leuchten bekomme um generell mal zu> testen ob sie funktionieren? Alle LEDs in einheitlicher Farbe oder so...
Hast du einen Frequenzgenerator der 800 KHz im Tastverhältnis 1:2/2:1
kann? Damit solltest du sie ein- und ausschalten können (Signal kurz
anlegen dann auf GND).
Noch ein Nachtrag: die WS2812B brauchen eigentlich ein "5V" Signal. Der
Pi macht aber 3,3V. Das hat bei mir trotzdem immer geklappt und ich habe
auch noch nichts gegenteiliges gehört. Wenn du sicher gehen willst,
brauchst du aber einen Level Shifter. Ggf. könnte es auch helfen, die
Versorgungsspannung der LEDs etwas abzusenken.
Hallo
Vielen Dank an alle die mir hier Hilfe leisten!
Eins vorweg: mein Name ist in dieser Sache hier leider Programm , ich
bin mit dem PI ein absoluter NOOB und zu allem Überfluss, ist mein
Englisch auch nicht gerade das beste. :/
Alex G. schrieb:> Die Library wird, wie man unschwer erkennen kann, noch immer gewartet.
Wodran erkennst du das?
Alex G. schrieb:> Würde mal empfehlen ein frisches OS aufzusetzen (also das Original von> der Foundation), denn andere Programme können gern mal was verstellen> oder gar im Hintergrund dazwischen funken.> Ausserdem auch die Verdrahtung nochmal genau checken.
Ich habe mit einem Multimeter die Lötstellen auf Kurzschluss gecheckt
und ob Saft an den stripes ankommt, am Anfang kommen 5,19V an und am
Ende 5,12V, sollte also richtig sein.
Mikro 7. schrieb:> Du hast also den Takt der Peripherie von 400 MHz auf 250 MHz korrigiert> und die entsprechenden Kernel Module installiert bzw. deistantlliert; so> wie es dort steht?
Ähhmm nein das habe ich nicht gemacht :/ ... ich glaube, dab fängt es
nämlich schon an mit den fehlern. Ich habe aber bisher nirgends gesehen
das jemand in den Anleitungen genauer drauf eingegangen ist bzw. das
erwähnt wurde das es gemacht werden muss?! Könntest du mir evtl. kurz
erklären wie das zu machen wäre?
Mikro 7. schrieb:> Möglicherweise hast du die erste LED der Kette bereits geschrottet?> Schon mit der zweiten probiert?
Deswegen wollte ich ja gerne den restlichen Strang der übergeblieben ist
(Ca 0,5m) am PI testen, den dafür bräuchte ich ja keine extreme
stromquelle.
Aber nach der Antwort von Mikro 7 glaube ich das die LED noch in Ordnung
sind ich aber einfach nur zu dumm dafür :)
Hab es mir echt leichter vorgestellt und hätte ich da nicht schon so
"viel" Geld reingesteckt, würde ich es jetzt auch sein lassen aber so
will ich es doch zum laufen bekommen :)
Mikro 7. schrieb:> Du hast also den Takt der Peripherie von 400 MHz auf 250 MHz korrigiert> und die entsprechenden Kernel Module installiert bzw. deistantlliert; so> wie es dort steht?
Kleiner Nachtrag: das mit den MHz Umstellung wird laut Anleitungen doch
gemacht aber erst später, soweit bin ich nicht gekommen da ich ja schon
beim befehl "sudo python setup.py build" die o.g. Fehlermeldung bekomme
Da ich die Lib noch nie getestet hatte, sie aber quasi die Referenz
für RGB Strips ist, habe ich es gerade eben mal geprüft.
(1) Frisches Image
http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-04-10/2017-04-10-raspbian-jessie.zip
(Ist zwar älter, aber immer noch meine Referenz.)
(2) Konfig ändern
$ sudo vi /boot/config.txt
# dtparam=audio=on
(Ist als default nicht auskommentiert.)
core_freq=250
(Für Pi-3: von 400 auf 250 MHz peripheral clock.)
$ reboot
(3) Lib installieren
(4) Verdrahtung sicher stellen
GPIO (BCM) 18 ist default für die Lib für PWM. Das ist Pin 12 auf dem
Pin header.
https://pinout.xyz/#
Data des RGB Strips auf der richtigen Seite anschliessen.
(5) Regenbogentest
$ sudo ./test
Regenbogen läuft.
Noob schrieb:> Wodran erkennst du das?
Bei jeder Datei steht rechts wann sie zuletzt geändert wurde, zudem
steht in der Mitte meist eine Bewchreibung der letzten Editierung.
Wenn das bei vielen Dateien der Fall ist, kann man davon ausgehen dass
sich mindestens noch eine Person damit beschäftigt.
OMG Mikro 77 du bist mein Held des Monats!!!
Die LEDs laufen!!!
Zwar nicht komplett nur bis zur Hälfte aber das wird ja jetzt glaube ich
nur noch eine einstellungssache sein! Vielen vielen Dank du kannst dir
garnicht vorstellen wie sehr du mir damit den Tag gerettet hast ;)
kleiner nachtrag:
ich habe den eintrag "core_freq=250" nicht dafür aber
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
kann es sein das dass bei mir nur anders heißt weil anderer PI oder so?
Noob schrieb:> Zwar nicht komplett nur bis zur Hälfte aber das wird ja jetzt glaube ich> nur noch eine einstellungssache sein!
Default ist 64 Stück.
Noob schrieb:> kann es sein das dass bei mir nur anders heißt weil anderer PI oder so?
Die Zeile wird für PWM nicht benötigt; nur für SPI.
Marc V. schrieb:> Weil die bits nicht 1:1 rausgetaktet werden.> Entweder man enkodiert es vorher, dann braucht es mehr RAM, geht
mit einem Arduino mighty mini 1284p habe ich schon 393 LEDs angesteuert
Ich bin jetzt so weit das die stripes leuchten!
Ich habe aber das Problem das ab der Hälfte die LED's unkontrolliert
flackern.
Der erste stripe ist mit dem Netzteil und PI verbunden. An dem gibt es
kein flackern, der zweite stripe ist mit 5V DI Und GND mit dem ersten
verbunden. An dem zweiten stripe gibt es auch kein flackern.
Ich habe dann den 3 stripe mit einem neuen Netzteil verbunden und DO vom
stripe 2 an DI von stripe 3.
Die Stripes 3 und 4 sind dann wieder normal verbunden mit 5V DO/DI GND.
Mein Problem ist jetzt das stripe 3 und 4 nach kurzer Zeit
unkontrolliert in allen Farben anfangen zu blinken. Sieht für mich so
aus als ob die beiden stripes ein Test abspielen würden.
Jemand vielleicht eine Idee was das für ein Problem sein könnte?!
Du musst Ground vom zweiten und dritten Streifen auch verbinden (und
auch mit dem Raspberry sofernder erste Streifen nicht am selben NT wie
der raspi hängt).
Ist das nicht der Fall dann hat die Datenleitung bei dem dritten und
vierten Stripe kein definiertes Potential zum separaten ground des
zweiten Netzteil.
Edit: Zu langsam ;)
Hmm nee das muss noch was anderes im Argen liegen...
Wenn ich das PI hochfahre, bekomme ich die LED's nicht zum laufen. Beim
Versuch sie zu starten blitzen sie einmal kurz auf und das wars. Erst
nach einiger Zeit (auch wenn ich nichts verstelle) springen die von
alleine an.
Erst die eine Hälfte, dann irgendwann die andere Hälfte.
Danach läuft auch alles kurzzeitig bis dann die 2 Hälfte (stripe 3/4)
wieder anfangen zu blinken.Mit dem nachträglichen verbinden der stripes
2&3 durch GND ist das flackern wesentlich besser geworden aber dennoch
ist es deutlich zu erkennen :(
Dieses Projekt kostet mich noch meine letzten Haare :(
Geh auf Fehlersuche durch Ausschlussverfahren. Z.B.:
Verbinde NT#1 mit VCC/GND der Ketten 1/2.
Verbinde NT#2 mit VCC/GND der Ketten 3/4.
Verbinde RPI/GND mit NT#1/GND und RPI/GND mit NT#2/GND.
Verbinde RPI/DOUT mit Kette 1/2. Regenbogen ok?
Verbinde RPI/DOUT mit Kette 3/4. Regenbogen ok?
Verbinde RPI/DOUT mit Kette 1/2 und RPI/DOUT mit Kette 3/4. Regenbogen
auf beiden ok?
Wiewiel Elemente haben deine Ketten eigentlich und wie hoch ist der
Spannungsabfall?
Vielen Dank dirnochmal für deine geduldige mithilfe :) ich kann mir
vorstellen das es echt anstrengend sein kann sich mit einem vollnoob zu
unterhalten. Ist wirklich sehr freundlich von dir! ;)
Ich werde dann morgen einfach ein zusätzliches Kabel von GND des ersten
stripes an GND von stripe 3 nachlöten und testen.
Sollte es nicht gehen dann noch zusätzlich ein Kabel von DI vom stripe 3
an das DO Kabel was von PI kommt und dann ebenfalls testen.
Nachtrag:es sind insgesamt 4 Stränge stripes, die erste hälfte hat 113
LED's (1 Strang 40, 2 Strang 73). Für die andere Hälfte exakt das selbe.
Ich hatte am Anfang von stripe 1 5,19V gemessen und am Ende vom stripe 2
5,12V
Hallo
Das Problem mit dem falschen ansteuern, ist tatsächlich von der
fehlenden GND Leitung zwischen beider NT's.
Mein Problem was ich jetzt habe ist, dass bei Bewegungen im Bild die LED
flackern. Also nicht wie vorher ein kleiner Teil der unkontrolliert
flackert sondern eher ein hin und herspringen zwischen mehreren Farben.
Ich kann auch über die hyperion app keine Verbindung aufbauen. Mit
hyperion auf dem pc kann ich auch keine genauen Farben einstellen, wähle
ich z.b. Rot aus zeigt er blau an, wähle ich genau das selbe rot nochmal
aus zeigt er mir dann doch rot an.
Meine Probleme im Moment sind also:
Bei Bewegungen im Fernsehbild flackern die LED In mehreren Farben.
Flackern bei bewegten Bildern
Keine korrekte Farbeinstellungen über hyperion auf pc sowie App möglich
Und das Problem das der PI einige Zeit laufen muss bevor die LED's
starten besteht auch noch weiterhin :(
Hier mal ein Video wie es im Moment aussieht
https://youtu.be/tC5zhlrtMLQ
Hallo
Ich wollte mich nochmal kurz melden um mich bei allen die mir hier
geholfen haben zu bedanken! Insbesondere bei Mikro 77!
Ich habe das Projekt erfolgreich abgeschlossen :)
Das flackern war durch Einstellungen an der config zu beheben.
Die LED's leuchten jetzt fast perfekt.
Perfekt bedeutet das max 200 LEDs bei mir betrieben werden (warum auch
immer)
Damit werde ich jetzt aber erstmal leben da man das kaum bemerkt da es
die letzten LEDS in der Ecke sind.
Ich werde die LEDS noch mit einem anderen Programm testen um zu sehen
woran das liegt
Vielen Dank an alle
