Beiträge von don_luigi

Ach so ist das also.
Ja, testen musst du das nicht zwingend. Ich bin gerade dabei einen Versuchsaufbau (ersteinmal mit einem ATmega88 auf nem STK500, einer SPI_to_WS2811-Schaltung und einem 1m langen LED-Strang) aufzubauen.
Geht bei dem Wetter etwas schleppend voran. Ist man drinnen, dann ists so heiß, dass Denken kaum möglich ist und es zieht einen raus, und ist man draußen geht nix weiter... Draußen ists trotzdem schöner, die arbeit bleibt , das wetter nicht

Aber damit werde ich dann einfach mal austesten wann und wie der Strang mich noch versteht. Mit dem Internen RC-Oszillator des ATmega kann man ja die Frequenzen ganz easy durchtesten. Der lässt ja ein Trimmen von 50% bis 200% zu... Nicht ganz so gedacht von Atmel denke ich, aber tuts wunderbar. Auf dem Weg bringt man übrigends fast jeden Atmel auf 16-17MHz ohne externen Taktgeber
Nur weiß ich noch nicht ganz genau welche Testdaten ich senden soll, damit ich auch wirklich erkennen kann ob jedes Bit richtig gelesen wurde... Da hab ich mir noch keine Gedanken gemacht. Aber da kommt bestimmt auch noch ne kleine Eingebung

Du scheinst gerade einen schönen Aufbau zum Testen zu haben... kannst du mal testen ob man die Bits auch beispielsweise mit schrägen Frequenzen wie 600kHz oder 1MHz reintakten kann? Die High-Pulse müssen natürlich in den gültigen Bereichen bleiben, wenn wir mal von einem Monoflop ausgehen. Hur aus Interesse, weil einige Chips nicht ganz so flexibel mit dem SPI-Takt sind.
Die Theorie des Monoflops würde dadurch unterstützt...

Zitat von Irrlicht

Auf dem ersten Oszillogramm sieht man eine überlagerte Frequenz von etwa 14,7 MHz.
Kannst Du Dir deren Herkunft erklären?

Für mich sieht das aus wie das clk-Signal...
vermute das ist nur ein Messfehler oder ein Steckbrettaufbau.
Dem kann man bei Bedarf zwar noch nach gehen, aber vorerst sollte das kaum stören.

lizard.king ich glaube du wirst sporadische Fehler generieren. Da das Raspi ja die Datenbytes mit unregelmäßigen pausen zwischendrin sendet wird wohl der Takt nichteinmal mehr während eines Bytes des WS2811-Signals ungestört bleiben und damit vermute ich kommt der Chip dann nicht mehr klar. Ich vermute man muss dem Chip 24 Bit in seinem Format und konstantem 400/800kHz takt übertragen und darf dann bis zu 49µs pause machen bevor man das nächste Pixel überträgt... Damit schätze ich kommt er klar, alles andere wird er nicht verstehen.
Im Worst case muss der Takt allerdings sogar während der gesamten Übertragung konstant bleiben und wenn das der Fall ist haben die Raspis so ziemlich verkackt... denn das geht nicht ohne echtzeitfähiges Betriebssystem, welches das auf dem Raspi afaik nicht ist. Dann hilft wirklich nurnoch ein großer Puffer...

Zitat von Irrlicht

Aber zu dem Puffern aller Daten: Obwohl das als der Königsweg erscheint, sei angemerkt, dass das auch den blöden Nebeneffekt der Zeitverzögerung beinhaltet.

Naja, aber vom Raspi zum µC kann man ja dann auch vollgas die Daten rumtakten, wenn der eh schon Puffert. Und man könnte mit dem Empfang des ersten Bytes auch schon beginnen das erste Byte wieder zu senden, da man vermutlich davon ausgehen kann, dass die Daten schneller vom Raspi kommen als sie durch die LEDs wandern können. Und schon ist die Verzögerung auf wenige µs reduziert...

Meine Überlegung dazu ist gerade, einen kleinen µC zu nehmen und jeweils 3 Byte (1Pixel) zu Puffern und dann direkt im entsprechenden Format wieder zu Senden. Hierbei könnte man dann auch im µC die Bytes so aufblasen, dass jedes Bit zu einem Byte wird, das mit 8-facher Geschwindigkeit über dessen SPI gesendet wird ("1" => 0b11110000; "0" => 0b11000000), sodass man direkt mit dem µC das passende Signal generiert. Ein µC mit 2 SPI-Schnittstellen wäre dann natürlich Vorausgesetzt und einer mit DMA wäre genial...
Solche µCs (STM32 z.B.) haben aber dann vermutlich sowieso schon wieder so viel Speicher, dass man gleich alle Daten Buffern könnte...

Jetzt wäre es interessant ob und wann Pausen im Datenstrom eingefügt werden dürfen. Nach jedem Byte, nach jedem Pixel, oder überhaupt keine Pausen...

Zitat von lizard.king

800khz ergibt pro Bit 1.25us. Der Ws2811 erwartet für eine 1 einen Puls von 0.6us. Ev könnte man ein Monoflop einsparen und für die 1 Pulse direkt auf das Clocksignal vom SPI zurückgreifen um einen Puls von 0.625us zu erhalten. Die Genauigkeit dürfte vermutlich ausreichend sein.

Ich glaube der Vorschlag kam schon einmal. Ist prinzipiell möglich und die Genauigkeit sollte auch sehr gut ausreichen, nur hast du dann immernoch den kurzen "0"-Puls und der braucht halt irgend einen Monoflop. Das kann man dann zwar mit nem NE555 aufbauen, aber das benötigt dann wieder mehrere Logikgatter am Eingang für ein SlaveSelect etc. Die 74xx123 haben bereits zwei Monoflops integriert und das auch noch mit passender Eingangslogik. Die Schaltung von mir oben benötigt "nur" 2 ICs, 2 Widerstände und 2/4 Kondensatoren (2 Kondensatoren für die Schaltung, 2 für die Stromversorgung, Hardliner können also sogar noch die 2. zwei Cs einsparen)

Wo ich gerade parallel noch dran bin (Hilfe erwünscht) ist ein kleiner AVR, der die Umsetzung in nur einem Chip erledigt. Passend wären da z.B. die AVR ATtiny25, weil die dank einer PLL mit einer 16MHz-internen-Taktquelle angetrieben werden können und durch vertrimmen des internen RC eventuell sogar auf 20MHz aufgebohrt werden können. Meinen Überlegungen nach müssten aber die 16MHz knapp ausreichen. Würde ich einen Timer-Counter sinnvoll in einen single-Shot-Modus bewegen können, dann käme man evtl sogar mit geringerer Taktfrequenz aus...

Servus zusammen,
hab mir das Thema hier mal ein wenig zu Gemüte geführt. Feine Anregungen gibt es hier.
Ich hab die hier rumgeisternde Schaltung noch ein klein wenig optimiert (Bauteile weg optimiert) und bin schließlich auf die Schaltung die ihr hoffentlich im Anhang findet gekommen.

Bis auf die Timings die bei LTSpice offenbar mehr Schrott als sinnvolles ergeben, hat sie in der Simulation sehr gut funktioniert. In der Simulation hab ich durch ausprobieren für die Cs 330pF und für die Rs 1k und 3k ermittelt. Naja, ich vertraue da mal mehr auf eure praktischen Versuche und Werte und hab daher diese in den Schaltplan geschrieben...
Wenn sich jetzt noch jemand findet der sie testen kann... ich kann das gerade leider mangels ICs nicht.

Funktionieren sollte das dank des AHCT dann auch mit den 3.3V aus dem RasPi oder mit sonstigem 3.3V SPI auf 800kHz.
Der SlaveSelect ist high-active. Also SS > 2V selektiert, SS < 0.7V deselektiert. Nur sollte man nicht zu früh deselektieren, sonst könnte das letzte Bit sofern es eine "1" ist etwas gekürzt werden (was die WS2811 ICs allerdings sicherlich nicht einmal stört).

Viel Spaß damit. Testen werde ich die Schaltung wohl nicht vor ein bis zwei Wochen können, da ich die Teile alle erst bestellen muss...

Ach ja, das NAND am Ausgang kann auch durch 2 Transistoren mit Pullup ersetzt werden (Emitter an GND, Basis mit vorwiderstand an die invertierten Ausgänge, Collectoren verbinden und mit einem z.B. 1k Widerstand nach 5V). Alternativ geht auch ein OR-Gatter an den nicht invertierten Ausgängen.