WS2811 Ansteuerung

[Tobias W. (wagnertobse)]

Guten Tag,
ich versuche gerade eine WS2811 ansteuerung mit einen ATMEGA 32 zu 
realisieren. Der ATMEGA 32 taktet mit 16MHz und die Ansteuerung 
funktioniert mit 24 LEDs einigermaßen. Ich kann die 24 RGB-LEDs 
ansteuern und jeder eine Farbe zuweisen. Das einzige Problem, was 
besteht ist, dass das erste Bit manchmal eine Eins ist anstelle einer 
Null. Das hat zur Folge, dass die erste LED anfängt grün zu blinken.

Ich bin schon mehrmals den Quellcode durchgegangen und finde den Fehler 
nicht. Vielleich könnt ihr mir weiterhelfen.

Hir der Quellcode:

#include <avr/io.h>
#include <avr/interrupt.h>

#include "WS2812.h"


extern unsigned char LEDs[Anzahl];
extern uint16_t HSV_LEDs[Anzahl/12][3];
extern unsigned char flag;

void intpwm(){
  TCCR1A = 0x00;
  TCCR1B = 0x00;
  ICR1= 40;
  DDRD = 0xFF;
  TCCR2 = (1<<CS20) | (1<<CS21) | (1<<CS22);
  //TIMSK |= (1 << TOIE2);
  sei();
}

void ausgabe(){
  TCNT1 = 1;
  TCCR1A = (1 << WGM11);
  TCCR1B = (1<<CS10) | (1 << WGM12) | (1 << WGM13);

  TIFR = 0b00000100;
  while((0b00000100 & TIFR) == 0b00000000);

  if(LEDs[0] & 0b10000000){
    OCR1AL = 25;
  }
  else{
    OCR1AL = 5;
  }
  for(uint16_t i=0; i < Anzahl; i++){
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);
    TCCR1A |= (1 << COM1A1);
    if(LEDs[i] & 0b10000000){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b01000000){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b00100000){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b00010000){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }

    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b000001000){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b00000100){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b00000010){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }

    TIFR = 0b00000100;
    while((0b00000100 & TIFR) == 0b00000000);

    if(LEDs[i] & 0b00000001){
      OCR1AL = 25;
    }
    else{
      OCR1AL = 5;
    }
  }
  TIFR = 0b00000100;
  while(!(0b00000100 & TIFR));
  TCCR1A = 0x00;
  TCCR1B = 0x00;
}

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Warum erfindest du das Rad denn neu? Schau mal hier:
Beitrag "Lightweight WS2811/WS2812 Library"

[chris (Gast)]

Oder nimmst einen Arduino mit der FastSpi-Lib:
http://code.google.com/p/fastspi/

Hat bei mir schnell funktioniert.
http://wiki.hacdc.org/index.php/WS2811_Arduino_Howto
oder ohne Arduino:
http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html

[Tobias W. (wagnertobse)]

Für den Lerneffekt wollte ich es selber schreiben. Es funktioniert jetzt 
mit einer Datenrade von 600kBit/s. Das erste Bit schalte ich jetzt mit 
einen Feldeffekttransistor weg.

[Besserwisser (Gast)]

600kBits/s ??

Die WS2811 kann man auf 400kBit/s und 800kBit/s stellen, aber bei 
600kBit/s hast Du ganz bestimmt ein Timing Problem. Das überhaupt was 
funktioniert liegt offensichtlich an der weitreichenden Fehlertoleranz 
des WS2811. Versuch das timing auf 400 oder 800 kBit/s zu bekommen. Dann 
klappt es (vermutlich) auch mit der ersten LED.

[chris (Gast)]

Die FastSpi-Lib des Arduino nimmte es auch nicht so genau. Ich habe 
zuerst die Signale auf dem Oszi angesehen und dachte, es wird nicht 
funktionieren, da die Pausen deutlich zu lange waren. Allerdings ging es 
doch auf Anhieb. Hier wird beschrieben, dass die Datenblätter wohl auch 
nicht einheitlich sind:
http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html

Die Nullen werden als kurze Pulse, die Einsen als lange Pulse kodiert. 
Ich nehme an, dass die Pausen dazwischen nicht ganz so kritisch sind.

[Frieder S. (frsc)]

Darf ich mal kurz dazwischenfragen, was du in dem Bild als Diffusor 
verwendest? Ist das transluzentes Acrylglas?

[Torsten C. (torsten_c)]

Also ich habe mich auch gerade mit dem MSP430 dran versucht. In C hängt 
das Timing extrem davon ab, welche Compiler-Optimierungen man aktiviert.

Ich habe den Algorithmus zunächst in C programmiert, mit maximaler 
Opimierung Compiliert und dann den Code aus der erzeugten 
Assembler-Datei als Assembler direkt in C eingefügt, damit ich das 
Timing unter Kontrolle habe. Ich habe 4 LEDs in einer Dasy Chain. Der 
Daten-Ausgang ist P1.7.

Der Code:

#include <msp430.h> 
#include <stdbool.h>
#define Byte unsigned char
  ...
  Byte Daten[12] = {20,39,85, 61,0,0, 0,116,0, 0,0,255};
  static Byte Bits[96] = {false};
  Byte ByteNr;
  Byte BitNr;
  static Byte BitIndex;
  ...
    BitIndex = 0;
    for (ByteNr = 0; ByteNr < 12; ByteNr++) {
      Byte Merker = Daten[ByteNr];
      for (BitNr = 0; BitNr < 8; BitNr++) {
        if (Merker & 128) {
          Bits[BitIndex] = true;
        } else { // 3 + 9
          Bits[BitIndex] = false;
        }
        Merker = Merker << 1;
        BitIndex = BitIndex + 1;
      }
    }
    asm("    MOV.W     #96,r14");
    asm("    MOV.W     #Bits$1+0,r15");
    asm("Lbl$C$L5:    ");
    asm("    MOV.B     @r15+,r13");
    asm("    TST.W     r13");
    asm("    JNE       Lbl$C$L6");
    asm("    OR.B      #128,&P1OUT+0");
    asm("    nop;");
    asm("    nop;");
    asm("    AND.B     #127,&P1OUT+0");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    JMP       Lbl$C$L7");
    asm("Lbl$C$L6:    ");
    asm("    OR.B      #128,&P1OUT+0");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    AND.B     #127,&P1OUT+0");
    asm("Lbl$C$L7:    ");
    asm("    SUB.W     #1,r14");
    asm("    JNE       Lbl$C$L5");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    OR.B      #128,&P1OUT+0");

[Besserwisser (Gast)]

@chris
Ich denke das Datenblatt ist eindeutig, aber die verschiedenen 
Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen. 
Das ist auch die Quintessenz von 
http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html

[Basti (Gast)]

Also, wenn der µC wirklich nichts anderes zu tun hat (bei vielen LEDs), 
kann man ja eure Varianten nehmen... aber Sinnvoll wäre schon was 
anderes... aber dann brauch man so ne nette Sache wie DMA (sollte zB. 
ein besser MSP430 auch besitzen)...

Mein Ansatz läuft absolut Problemlos auf nem XMega:
- UART SPI auf 4*800 kHz stellen (geht sehr gut durch sehr flexible 
Baudraten)
- UART TX (oder in dem Fall MOSI) Invertieren (muss sein, damit der 
Ruhepegel Low ist!
- je zwei Bits mit Lookup in 1 Byte umrechnen (auch invertieren) und in 
einem großen Buffer ablegen (wird dann leider logischerweise 4 mal so 
groß)
-DMA starten und im Hintergrund schon wieder die nächste Animation 
berechnen, oder neue Daten über USB oder Ethernet empfangen...


Grüße

Basti

[Torsten C. (torsten_c)]

Basti schrieb:
> aber dann brauch man so ne nette Sache wie DMA (sollte zB.
> ein besser MSP430 auch besitzen)

Das ist ja auch eine Kostenfrage und eine Frage der Beschaffung. In der 
"Value Line" MSP430Gxxxx ist DMA ein Fremdwort. Ich persönlich nutze 
hauptsächlich die beiden MSP430-Versionen, die mit dem Launchpad 
geliefert werden (MSP430G2553 + MSP430G2452). Trotzden danke für den 
Tipp.

@Besserwisser: Vielen Dank für den Link. :-) Der Code von Alan Burlison 
gefällt mir sehr gut. Bei meinem (s.o.) habe ich pro Bit ein Byte 
verbraucht, was bei insgesamt 256 Byte RAM nicht gerade ratsam ist, dann 
ist bei 6 bis 8 LEDs nämlich irgenwann Schluss.

[Tobias W. (wagnertobse)]

@ Besserwisser
Die Ansteuerung habe ich zuerst mit 400kBit/s realisierirt und der 
Fehler ist auch aufgetreten. Später, als es dann lief (das erste Bit mit 
einen Transistor weggeschaltet), habe ich die Bitrate erhöt, um zu 
schauen was geht. Den Fehler kann man auch in den Bildern meines ersten 
Posts erkennen.

@Frieder S
Die Ausleuchtung der Felder habe ich mit 45x45x45 mm großen Kästchen aus 
Pappelsperrholz gelöst. Auf den Feldern sitz mattes Acrylglas (Ich weiß 
leier nicht mehr zu wieviel % Durchlässig). In jeden Käschen befinden 
sich vier LEDs aus der Sammelbestellung:
Beitrag "[Mitbestellung] SMD5050 RGB-LED mit integriertem 8-bit PWM Controller"

[lucki (Gast)]

Alao meine WS2811-LEDs sind sehr gemütlich anzusteuern. Frequenzen 
zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das 
Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein 
muss eine "1" länger als 550ns. Kritisch ist lediglich der Jitter. Wenn 
die Frequenz des Datensignals nur ein klein wenig wackelt, also die Bits 
mal früher oder mal später kommen, dann gehen bei meinen LEDs massiv 
Bits verloren.

[Tobias W. (wagnertobse)]

Probleme mit Jitter habe ich durch die Ansteurung mithilfe der 
Hardware-PWM nicht. Für 800MHz ist leider mein Code zu lagsam :(
Die Optimierung habe ich auf O1 gestellt.

Hat schonmal irgendwer getestet, wieviele LEDs man hintereinander 
schalten kann? Ich plane bei meinen Projet 384 LEDs hintereinander zu 
schalten.

[Torsten C. (torsten_c)]

lucki schrieb:
> Frequenzen
> zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das
> Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein
> muss eine "1" länger als 550ns.

Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie
500ns + 6167ns und 550ns + 6117ns?

Tobias Wagner schrieb:
> Hat schonmal irgendwer getestet, wieviele LEDs man hintereinander
> schalten kann?

Ich hab's nicht getestet, sehe aber auch keinen Grund. Du kannst ja auch 
Tausende hintereinander hängen. Nur die Update-Häufigkeit der Farbmuster 
(sozusagen "frames per second") sinkt. Aber bei Super-8-Filmen ist man 
ja auch mit 12,5 fps ausgekommen, und das Bild ruckelte kaum.

Das ist aber nur relevant, wenn Du "kontinuierliche" Veränderungen 
machen willst, und das Auge keine "Sprünge" wahrnehmen soll. Und bei 384 
LEDs ist das ja noch total unkritisch.

Du solltest nur darauf achten, dass bei der letzten LED noch genug 
Spannung ankommt, also dass der Spannungsabfall auf der 
Versorgungsleitung nicht zu groß wird.

[Drago (Gast)]

Torsten C. schrieb:
> Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie
> 500ns + 6167ns und 550ns + 6117ns?

Torsten C. schrieb:
> lucki schrieb:
>> Frequenzen
>> zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das
>> Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein
>> muss eine "1" länger als 550ns.
>
> Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie
> 500ns + 6167ns und 550ns + 6117ns?

nach allem was ich mit meiner Hardware ertesten konnte kann ich bei 
meinen LEDs folgende Specs festlegen:
f_min = ca. 147kHz
f_max = 1,15MHz
T0H_max <= 500ns
T0L_min = ?? (< 220ns) hardware limitation
T1H_min >= ?? (< 560ns) hardware limitation

mehr Werte haben mich nicht interessiert!

[franz (Gast)]

Besserwisser
>Ich denke das Datenblatt ist eindeutig, aber die verschiedenen
>Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen.
>Das ist auch die Quintessenz von
>http://bleaklow.com/2012/1202/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html

"The exact timings seem to vary depending on which source you believe 
(800KHz mode):"
Siehe Tabelle

[Torsten C. (torsten_c)]

Kann TOL tatsächlich beliebig irgendwo zwischen 370ns und 6583ns sein? 
Ich meine getestet, also nicht nach „Datenblatt“!

Bei f = 147kHz und TOH = 220ns komme ich auf T0L = 6583ns.
Bei f = 1,15MHz und TOH = 500ns komme ich auf T0L = 370ns.

lucki schrieb:
> Kritisch ist lediglich der Jitter. Wenn
> die Frequenz des Datensignals nur ein klein wenig wackelt, also die Bits
> mal früher oder mal später kommen, dann gehen bei meinen LEDs massiv
> Bits verloren.

Was ich noch nicht verstehe:
* Einerseits sollen die Low-Zeiten innerhalb des o.g. Rahmens
  egal sein,
* andererseits darf es keinen Jitter geben.

Wie häufig dürfen sich denn die Zeiten ändern? Nur nach einem Reset? 
Oder alle 24 Bit? Oder nach jedem Bit?

Zum Vergleich: Bei 1wire (ist ja ähnlich) darf nach jedem Bit eine 
beliebige Pause sein, nur ist hier der Ruhe-Pegel „High“ und beim WS2811 
ist der Ruhe-Pegel „Low“.

Weiss denn niemand, wie der WS2811-interne Zustandsautomat funktioniert?

[Tobias W. (wagnertobse)]

@Torsten C.
Ich hatte nur bedenke, dass die Weiterleitung der LEDs die Qualität der 
Datenübertragung beeinflusst und das Signal verjittert.
Das mit der Stromversurgung ist mir bewusst ich schalte maximal 16 LEDs 
an 4 Adern Flachbandkabel.

Mit den Timings musste ich auch ein bischen rumspielen. Ich hatte mich 
erst an die Timings aus den Datenblatt gehalten:
http://www.adafruit.com/datasheets/WS2811.pdf
Jedoch wurde dort eine Null als eine Eins erkannt. Die Zeiten konnte ich 
hundertprozentig durch die Hardware-PWM einhalten. Auch ein Puls von 
62,5 ns wird als eine Null erkannt. Ich hatte anfangs Probleme, dass bei 
den Setzen des Compareregisers auf 0 die Ganzen LEDs anderauernd Nullen 
empfangen haben. Die 62,5ns haben dafür ausgereicht.

[Torsten C. (torsten_c)]

Tobias Wagner schrieb:
> Ich hatte nur Bedenken, dass die Weiterleitung der LEDs die Qualität der
> Datenübertragung beeinflusst und das Signal verjittert.

So wie ich Alan Burlison verstanden habe, wird das Timing am Ausgang 
jeder LED aufbereitet ("signal reshaping"), so wie in seinem Oszilogramm 
zu sehen:

http://bleaklow.com/images/2012/ws2811_in_out.png

Also dürfte es sich eher verbessern als verschlechtern.

Das gilt sicher für Jitter-freie Eingangssignale. Wie diese 
Signalaufbereitung auf Jitter reagiert, wäre interessant. So war auch 
meine o.g. Frage gemeint: "Wie häufig dürfen sich denn die Zeiten 
ändern? Nur nach einem Reset?"

Vielleicht ist diese Signalaufbereitung der Grund, falls sich das Timing 
nur nach einem Reset ändern darf.

Ansonsten steht ja z.B. im Datenblatt: "When the refresh rate is 30fps, 
cascade number ... are not less than 1024 points."

[Torsten C. (torsten_c)]

PS: Also wie ich die bisherigen Postings interpretiere:

1. Jitter ist wegen des "signal reshapings" unbedingt zu vermeiden,
   also f_frame muss zwischen zwei Resets konstant sein.

2. Der Abtastzeitpunkt (s. Bild) liegt bei:

$$T_{sample} = 525ns \pm 25ns$$

Seht Ihr das auch so?

Ich habe mir einen "MiniLA" (ebay 121096923360) bestellt und werde mir - 
zum ersten ausprobieren des Gerätes - die 15 Signale nach jedem 
"reshaping" mal anschauen.

[Torsten C. (torsten_c)]

Tobias Wagner schrieb:
> Vielleich könnt ihr mir weiterhelfen.

Tobias, sorry, aber mit TCCR1A, ICR1, OCR1AL, TIFR usw. kann ich nix 
anfangen.

Besserwisser schrieb:
> die verschiedenen
> Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen.

Nein, Besserwisser, die Frequenz scheint wirklich ziemlich egal zu sein. 
Es geht offenbar nur um wenig Jitter und den 525s Abtastzeitpunkt nach 
der steigenden Flanke.

Also C (ohne Assembler) geht auch gut. Um wenig Jitter zu erzeugen, 
kopiere ich meine Bytes in ein Array Daten[] und dann ist's egal, ob 
mit_ oder _ohne "Test-Verzögerung" (s. Code). Das bisschen Jitter an 
den Byte-Grenzen akzeptieren meine 4 Dioden.

for (x = 0; x < 12; x++) {
  for (bit = 0; bit < 8; bit++) {
    if (Daten[x] & 128) {
      P1OUT = 128;                  // Bit setzen
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      P1OUT = 0;                    // Bit spät löschen
    } else {
      P1OUT = 128;                  // Bit setzen
      asm("    nop;");
      P1OUT = 0;                    // Bit früh löschen
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
      asm("    nop;");
    }
    Daten[x] <<= 1;
    // Test-Verzögerung Beginn
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    asm("    nop;");
    // Test-Verzögerung Ende
  }
}

[Tim . (cpldcpu)]

Warum gibt es zu diesem Thema eigentlich sich ständig wiederholende 
Diskussionen darüber, dass die LEDs auch bei Verletzung des im 
Datanblatt angegebenen Timings noch funktionieren?

Es ist einfach eine saubere Arbeitsweise, sich an das Datenblatt zu 
halten. Da dieses problemlos auf den AVRs möglich ist, gibt es wenig 
Gründe das nicht zu tun. Wer weis, ob dieses Gehacke auch auf den neuen 
Devices (WS2812B) noch funktioniert? Oder bei der nächsten 
Produktionscharge des Controllerchips?

Für Hobbykram ist die Herangehensweise ja ok, aber professionell ist das 
nicht...

@Torsten: Die Funktionsweise und den Abtastzeitpunkt sehe ich ähnlich 
wie Du. Allerdings bin ich mir nicht ganz sicher, was das "reshaping" 
wirklich macht. Wird es durch eine interne synchrone Logik erzeugt, oder 
handelt es sich um eine weitere monostabile Kippstufe? Bei letzterem 
sollte Jitter ziemlich egal sein...

[Torsten C. (torsten_c)]

Tim .  schrieb:
> Warum gibt es zu diesem Thema eigentlich sich ständig wiederholende
> Diskussionen darüber, dass die LEDs auch bei Verletzung des im
> Datanblatt angegebenen Timings noch funktionieren?
>
> Es ist einfach eine saubere Arbeitsweise, sich an das Datenblatt zu
> halten.

Ja. Wenn's denn eins geben würde. Aber selbst die Datenblätter 
widersprechen sich:

http://kt-elektronic.de/wawi11/artikeldaten/strip-rgb2812_30blsk-rita/ws2811.pdf
http://kt-elektronic.de/wawi11/artikeldaten/strip-rgb2812_30blsk-rita/ws2812.pdf

Und selbst das "reshaping" hält sich nicht an's eigene Datenblatt (siehe 
Bild). Ich kann die Diskussion daher nachvollziehen.

800 KHz sind ziemlich genau der geometrische Mittelwert aus 147kHz und 
1,15MHz. Das paßt also.

[Tim . (cpldcpu)]

>Ja. Wenn's denn eins geben würde. Aber selbst die Datenblätter
>widersprechen sich:

Also eigentlich ist das nicht so kompliziert. Es gibt nur ein WS2812 
Datenblatt. In diesem sind erhebliche Toleranzen zu den genannten Werten 
angegeben.

In den WS2812 ist der Ansteuer-IC im Gegensatz um WS2811 beleuchtet. Wer 
sich schon einmal mit HL-Physik auseinandergesetzt hat, wird schnell zu 
dem Schluss kommen, dass sich der WS2811/2 DIE hier durchaus anders 
verhalten kann. Vermutlich ist das genaue Verhalten des WS2812 abhängig 
vom Schaltzustand der Leuchtdioden...

[chris (Gast)]

>800 KHz sind ziemlich genau der geometrische Mittelwert aus 147kHz und
>1,15MHz. Das paßt also.
Da die Bausteine keine Quarzoszillatoren eingebaut haben, dürften die 
Toleranzen realtiv groß sein.

Meine Vermutung: Die wichtigen Zeiten, die einzuhalten sind, sind die 
Pulslänge für Eins und die Pulslänge für die Null. Die Pausen dazwischen 
dürften relativ große Toleranzen haben. Die Pausen dürfen nur nicht in 
die Gegend des Reset-Signals kommen.

[chris (Gast)]

Hier mal ein paar Oszi-Screenshots.

Gelb: Eingang LED0 ( FastSpi Output des Arduino )
Blau: Ausgang LED0 ( bzw. Eingang LED1 )

Die Logik der LED scheint eine Verschiebung des Pulses um 200ns 
vorzunehmen.

[chris (Gast)]

Äh... Entschuldigung. Da ist mir ein Fehler bei den Farben unterlaufen. 
Auf dem Oszi-Schirm sind sie anders ...

Blau: Eingang LED0 ( FastSpi Output des Arduino )
Rot: Ausgang LED0 ( bzw. Eingang LED1 )

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> Ich … werde mir … die 15 Signale nach jedem
> "reshaping" mal anschauen.

Ich habe auf die Schnelle erstmal die ersten 4 genommen, siehe Bild.

Verzögerung der L-H-Flanke: 560ns, 560ns, 550ns

Der erste Wert von den folgenden ist vom µC, die drei danach aus den 
WS2812ern:

Logische 1: 830ns, 650ns, 640ns, 640ns

Logische 0: 330ns, 340ns, 330ns, 330ns

Die Zeiten scheinen sich durch das "reshaping" auf 640ns / 330ns 
einzustellen.

Sample-Zeitpunkt also ca. 485ns nach der steigenden Flanke.

Der LA hat 'ne 10ns-Auflösung. Brauchen wir noch mehr Messungen?

[chris (Gast)]

>Verzögerung der L-H-Flanke: 560ns, 560ns, 550ns

Seltsam, ist mehr als doppelt so viel wie bei meinen Oszi Messungen 
weiter oben ( 200ns ). Ob es wohl an den LEDs liegt?

[Torsten C. (torsten_c)]

chris schrieb:
> Seltsam, ist mehr als doppelt so viel

Oh, stimmt. Mein Fehler: Das sind die Zeiten zwischen den zwei blauen 
Markern im Bild, also vor und nach 3 LEDs. Also im Mittel 184ns pro 
"reshaping". Sorry und danke.