WS2812B datenkompatibel zu WS2812?

[Peter Z. (Gast)]

Hi,

ich habe einen LED-Streifen mit 4 x WS2812 aufgebaut, funktioniert seit 
Monaten wunderbar am ATtiny.

Habe dann bei Amazon einen Streifen mit 60 Stück WS2812B gekauft. 
Betreibe beide Streifen parallel, bei dem im Internet gekauften Streifen 
ist nix zu sehen!!! Wie kann das sein?
Mit dem Oszilloskop sehe ich, wie die Datenpakete von LED zu LED 
weitergereicht werden und das jeweils erste Datenpacket wird 
einbehalten.

(Ist quasi wie in der Schule, wenn Zettel verteilt werden:
"Einen nehmen, Rest weitergeben")

Ist der bei Amazon gekauft Streifen Schrott, oder haben der WS2812 und 
der WS2812B unterschiedlichen Datenformate?
Die Zeiten für T0H, T1H, T0L unterscheiden sich laut den Datenblättern 
für den WS2812 und den WS2812B minimal um jeweils 0,05us während die 
Abweichung bei T1L 0,15us beträgt.
ich habe diese WS2812_send_array Routine, eine Änderung um 0,05us bzw. 
0,15us scheint recht schwierig zu sein, ein NOP sind bei 8MHz ja schon 
0,125us!

//*********************************************************************
#define ws2812_port 0x02 // Number of the data port register
#define ws2812_pin 2 // Number of the data out pin
void ws2812_sendarray_8Mhz(void)
{
  unsigned char *data = &color[0];
  unsigned char curbyte;
  unsigned char ctr;
  unsigned char datlen = 12;
  while (datlen--) {
    curbyte = *data++;
    asm volatile(
    " ldi %0,8    \n\t"
    "loop%=:    \n\t"
    " ROL %1    \n\t"
    " dec %0    \n\t"
    " sbi %2, %3  \n\t"
    " brcs .+2    \n\t"
    " cbi %2, %3  \n\t"
    " brcc .+2    \n\t"
    " cbi %2, %3  \n\t"
    " brne loop%=  \n\t"
    : "=&d" (ctr)
    : "r" (curbyte), "I" (ws2812_port), "I" (ws2812_pin)
    );
    // loop overhead including byte load is 6+1 cycles
  }
}
//*********************************************************************

SOS

[Conny G. (conny_g)]

Die sind eigentlich Datenkompatibel, und die Toleranzen des Protokolls 
sind sehr hoch.
Hast auch Spannung und Masse richtig angeschlossen?
Liefert das Netzteil genug Strom?

[Peter Z. (Gast)]

Conny G. schrieb:
> Hast auch Spannung und Masse richtig angeschlossen?

Ich denke mal ja, sonst könnte ich auf dem Oszilloskop ja nicht so schön 
sehen, wie die Datenpackete weitergereicht werden.

> Liefert das Netzteil genug Strom?
Der neue LED-Streifen braucht kaum Strom, es leuchtet ja überhaupt nix.
Nur der alte LED-Streifen blinkt munter vor sich hin.

[Conny G. (conny_g)]

Du könntest mal versuchen die erste LED abzuschneiden. Ich habe schon 
öfter gelesen (mir noch nicht passiert), dass die gerne kaputt geht.
U.a. soll man nie das Datensignal anlegen, bevor die Spannung am 
Streifen ist, wenn ich mich richtig erinnere.

Was allerdings dagegen spricht, dass Du das weiterreichen des Signals am 
Oszi siehst. Das würde nicht geschehen, wenn die erste LED kaputt wäre.

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter Zz schrieb:
> Der neue LED-Streifen braucht kaum Strom, es leuchtet ja überhaupt nix.
> Nur der alte LED-Streifen blinkt munter vor sich hin.

 Dann hänge mal den alten LED-Streifen einfach hinter den neuen und
 prüfe ob es immer noch leuchtet.

[Peter Z. (Gast)]

Marc Vesely schrieb:
> Dann hänge mal den alten LED-Streifen einfach hinter den neuen und
> prüfe ob es immer noch leuchtet.

Genau das habe ich jetzt probiert und tatsächlich, nachdem das Signal 
durch einen WS2812B durch ist, enthält es nur noch "0" siehe Bild!
Der ATtiny10 sendet immer "0x0F"
Das gelbe Signal ist vor dem WS2812B, das blaue dahinter.
Habe das mit WS2812B aus verschiedenen Lieferungen probiert, immer das 
selbe!
Was tun?

[Peter Z. (Gast)]

Konnte den Bug jetzt fixen  :-)

Ein kleines nop verändert das Timing so,
das WS2812 und WS2812B das Signal verstehen.

//*********************************************************************
#define ws2812_port 0x02 // Number of the data port register
#define ws2812_pin 2 // Number of the data out pin
void ws2812_sendarray_8Mhz(void)
{
  unsigned char *data = &color[0];
  unsigned char curbyte;
  unsigned char ctr;
  unsigned char datlen = 12;
  while (datlen--) {
    curbyte = *data++;
    asm volatile(
    " ldi %0,8    \n\t"
    "loop%=:    \n\t"
    " ROL %1    \n\t"
    " dec %0    \n\t"
    " sbi %2, %3  \n\t"
    " brcs .+2    \n\t" 
    " cbi %2, %3  \n\t"
    " brcc .+2    \n\t"
    " nop         \n\t" // dieses kleine nop macht Daten auch für WS2812B verständlich!!!
    " cbi %2, %3  \n\t"
    " brne loop%=  \n\t"
    : "=&d" (ctr)
    : "r" (curbyte), "I" (ws2812_port), "I" (ws2812_pin)
    );
  }
}
//*********************************************************************

YO

[Conny G. (conny_g)]

Spannend. Dann war das Timing vorher genau an der Grenze.

[Simon K. (simon)]

Warum auch immer man dort Assembler braucht... Angst, dass C zu langsam 
ist? ;-)

[Conny G. (conny_g)]

Simon K. schrieb:
> Warum auch immer man dort Assembler braucht... Angst, dass C zu langsam
> ist? ;-)

Bisschen Woodoo muss immer sein :-)

[H.Joachim S. (crazyhorse)]

Ist sowas nicht besser mit nem Timer erledigt? Toggle on compare + 
OCR-Interrupt, der nen nächsten OCR-Wert schreibt?

[holger (Gast)]

>Ist sowas nicht besser mit nem Timer erledigt? Toggle on compare +
>OCR-Interrupt, der nen nächsten OCR-Wert schreibt?

Damit bekommt man kein ausreichend genaues Timing hin.
Alleine der Aufruf des Interrupts hängt doch schon davon ab
welcher OP Code mit wievielen Takten noch zuende geführt wird.

Am besten ist eine Hardware die das ganze komplett selbst
erledigen kann. Z.B. per DMA. Hat der AVR ja nun aber nicht.

Ich bevorzuge LED Stripes mit LPD8806. Die sind zwar teuer,
aber um Timings braucht man sich da nicht die Bohne Gedanken machen.
Einfach per SPI die Daten reinprügeln. Da ist es auch völlig
Wurst ob da noch ein Timer oder UART massiv mit Interrupts reinhaut.

[H.Joachim S. (crazyhorse)]

Ok, hatte auf dem Foto 100µs als Zeitbasis gesehen, sind aber 1µs.
Bei ca. 0,3µs Pulslänge macht das mit nem AVR-Timer natürlich keinen 
Sinn.

[Peter Z. (Gast)]

Simon K. schrieb:
> Warum auch immer man dort Assembler braucht... Angst, dass C zu langsam
> ist? ;-)

//*********************************************************************
#define ws2812_pin 2 // Number of the data out pin
void ws2812_sendarray_8Mhz(uint8_t curbyte)
{
  for(uint8_t bit_counter = 8;bit_counter;bit_counter--)
  {
    PORTB |= (1 << ws2812_pin);
    if((curbyte & 0x80) == 0)
    {
      PORTB &= ~(1 << ws2812_pin);
    }
    else
    {
      asm volatile("NOP");
      asm volatile("NOP");
      PORTB &= ~(1 << ws2812_pin);
    }
    curbyte <<= 1;
  }
}
//*********************************************************************

dies funktioniert jetzt auch ohne Assembler Voodoo sehr schön.
Nur hat man im Hinterkopf die Angst, das der Compiler das anders 
compilieren könnte und schon ist das exakte Timing futsch.

[Conny G. (conny_g)]

Da kann ein Compiler nicht besonders viel variieren würde ich sagen.

Wieso eigentlich nicht so?

//*********************************************************************
#define ws2812_pin 2 // Number of the data out pin
void ws2812_sendarray_8Mhz(uint8_t curbyte)
{
  for(uint8_t bit_counter = 8;bit_counter;bit_counter--)
  {
    PORTB |= (1 << ws2812_pin);
    if((curbyte & 0x80) != 0)
    {
      asm volatile("NOP");
      asm volatile("NOP");
    }
    PORTB &= ~(1 << ws2812_pin);
    curbyte <<= 1;
  }
}
//*********************************************************************

[Peter Z. (Gast)]

Conny G. schrieb:
> Wieso eigentlich nicht so?

Doch sieht gut aus,
kann es nur jetzt im Moment nicht mehr testen
da ich gerade alles weggeräumt habe...

[Ales D. (testus)]

Das Timing kann man anscheinend auch entspannter angehen...

http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

habe es selber aber nicht ausprobiert

Grüße
Ales