put_pixel in the parallel example sets the color order for the pixel to BRG instead GRB

[eelstretching]

The data sheets for the ws2812 and ws2812b led strips (e.g., https://cdn-shop.adafruit.com/datasheets/WS2812.pdf) show that the required color order when sending data is GRB. The put_pixel function in ws2812_parallel.c inverts the order of the colors when putting data into a strip, so you end up with BRG, which means that your colors end up being weird or, at least, not what you expected.

Reversing the order of the additions to current_strip_out solves the problem.

[lurch]

It looks like urgb_u32 already swizzles the RGB order into GRB, and the parameter for put_pixel is named pixel_grb which implies that put_pixel expects the data to already be in GRB order? Or have I grabbed the wrong end of the stick? 🤔

[eelstretching]

You're correct: urgb_u32 does put the bytes into the 32-bit word in g (<<16), r (<<8), b (no shift) order.

But the problem is in put_pixel, the 2 least-significant bytes from that 32-bit word are added to the current strip first (i.e., the blue bytes), then the 2 next-most significant bytes are shifted right by 8 and added (i.e, the red bytes) and then finally the 2 most-significant (i.e., the green bytes) are shifted right by 16 and added, giving you BRG.

I wrote a "pattern" that sends a solid color to the LEDs and with the original code if you send pure blue (r: 0, g: 0, b: 255) you end up with the LEDs lit pure green. With my forked code, you get the expected blue.

I think the, shall we say, freneticness of the patterns (that 10ms delay between frames is awfully short!) mask the fact that the colors aren't acurate.

[lurch]

Thanks for the explanation. But I think there's only one byte per colour, not two: you can't squeeze 6 bytes of colour data into a 32-bit (4-byte) word 😉

[eelstretching]

You can if you really believe in yourself!

(Sorry, spent a good part of the weekend looking at hexadecimal!)

[kilograham]

I believe you ;-)