WS2816 - bit order looks wrong

[Makuna]

@tablatronix (copied from a closed issue for them) You can copy the image over again if you wish.

Has anyone tested this or have it working ? The bit order on my scope looks wrong like each byte is LSB->MSB and not for all 16bits in order ? Will try to get find my logic analyzer for better capture

NeoPixelBus<NeoRgb48Feature, NeoEsp32Rmt1Ws2816Method> strip(1, TX);

Rgb48Color test(3, 3, 3);

[Makuna]

The WS2816 uses GRB color order. You defined it with RGB order. Try this...

NeoPixelBus<NeoGrb48Feature, NeoEsp32Rmt1Ws2816Method> strip(1, TX);

or the specifically named color feature

NeoPixelBus<NeoGrbWs2816Feature, NeoEsp32Rmt1Ws2816Method> strip(1, TX);

[tablatronix]

There is not a NeoGrb48Feature, but I see this in per color bytes not pixel so not really the issue.

[Makuna]

What do you mean there is not a NeoGrb48Feature? It is present and usable in the library. Just use them. You can find them...

\src\internal\features\NeoGrb48Feature.h (line 29) for NeoGrb48Feature
\src\internal\NeoColorFeatures.h (line 54) for NeoGrbWs2816Feature

The feature will describe to NeoPixelBus how to translate the color, the Rgb48Color object provided colors when calling strip.SetPixelColor(); to the output stream data that can be accessed by calling strip.Pixels().

What do you mean by "per color bytes not pixel"? Please be specific and fully describe what you mean by this statement.

[tablatronix]

Ah! there is, My bad I was testing earlier with 64bit before and there was no grb. And got them mixed up.

Shouldnt C=0x1 be
00000000 00000001?
And not
00000001 00000000

[Makuna]

What do you mean by c=0x1? Please be specific. Include a Snippit of code of how you define and set the color.

[tablatronix]

// NeoGrb48Feature
Rgb48Color test(1, 1, 1); 
strip.SetPixelColor(0, test);
strip.Show();

[Makuna]

Could you try with 10 pixels to see if any difference. There was an old issue with a single pixel strips but I thought it was fixed.

NeoPixelBus<NeoGrbWs2816Feature, NeoEsp32Rmt1Ws2816Method> strip(10, TX);

Confirming details before I try to repo this.
Which ESP32 do you have? ESP32/ESP32-C2/etc
Arduino Board Version (look in board manager for your ESP32 support).
NeoPixelBus library version.

[tablatronix]

Esp32 WROOM
NeoPixelBus<NeoGrb48Feature, NeoEsp32BitBangWs2816Method> strip(10, PixelPin);

I can try any variant, I have them all in dev

I tried i2s and rmt, I think those are the same, I will check again to be sure.

PACKAGES: 
 - framework-arduinoespressif32 @ 3.20007.0 (2.0.7) 
 - tool-esptoolpy @ 1.40500.0 (4.5.0) 
 - tool-mkfatfs @ 2.0.1 
 - tool-mklittlefs @ 1.203.210628 (2.3) 
 - tool-mkspiffs @ 2.230.0 (2.30) 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
xtensa-esp32-elf-g++ -o "/Users/shawn/projects/microcontrollers/dev/libraries/SHAWN_boards/npb_48bit/npb_48bit.ino.cpp" -x c++ -fpreprocessed -dD -E "/var/folders/rd/zdyjybdj00jf_jccm4ms9qhr0000gn/T/tmpndkh_788"
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Framework incompatible library /Users/shawn/.platformio/lib/RCSwitch
Found 76 compatible libraries
More details about "Library Compatibility Mode": https://docs.platformio.org/page/librarymanager/ldf.html#ldf-compat-mode
Scanning dependencies...
Dependency Graph
|-- NeoPixelBus @ 2.7.5 (License: Unknown, Path: /Users/shawn/.platformio/lib/NeoPixelBus)
|   |-- SPI @ 2.0.0 (License: Unknown, Path: /Users/shawn/.platformio/packages/framework-arduinoespressif32/libraries/SPI)
Building in release mode

[tablatronix]

Looks like colors are ok, but methods use uint8_t* pixels so 16bit colors are split and then sent out with its 2 bytes reversed

[Makuna]

It looks like a endianness order problem where bytes in uint16_t are stored swapped in ESP32 (and some other platforms). Looking at a fix now.

[Makuna]

created issue to track it: #700
#699 fixes it.