You are reading a single comment by @AkosLukacs and its replies. Click here to read the full conversation.
  • @Gordon I think checking for 3 or 4 byte length, and throwing an error if the array length doesn't match the expectation is a valid. I guess 99% it's a programming error. Ran into it myself when messing with these LEDs. :)
    Getting a clear error (IMO) is way better than debugging or blaming LEDs / the library / sample code.

    @Robin Well, there are four colors per chip, so trying 4 bytes per pixel felt a good guess. Add some trial and error, and got them working.

    (Edit: I was wrong, same behavior on the STM32) Regarding RGB / GRB: There is something that looks strange in the NRF driver

    typedef struct
        uint8_t   green; // Brightness of green (0 to 255)
        uint8_t   red;   // Brightness of red   (0 to 255)
        uint8_t   blue;  // Brightness of blue  (0 to 255)
    } rgb_led_t;

    The first color in the struct is green, that might be the reason for the strange color order.

    I will try it with an STM Espruino tomorrow.

    Or simply it's banggood, the item and description is not expected to match perfectly...
    Sometimes they list half a dozen part numbers in the name, and drop in the words like "replacement" or "upgraded"...
    Watched some youtube videos about RGB and RGBW strips, and they mentioned that the color order may change between manufacturers and batches. They might be RGB, GRB, or RGBW, GRBW, etc. So if you plan on creating a long strip, better buy it together...

    @allObjects Yes, mine are async ones. 4 pins on the LEDs, and the strips have 3 wires: GND, VCC, and Data in. Data out on the other end, and no clock signal.

  • Sat 2019.02.09

    While I would have someone with more compiler level skills answer this (I'm an end user like yourself) in detail, I am able to suggest the following:

    'Sometimes they list half a dozen part numbers in the name'

    Yes, annoying isn't it. Their description of WS2812b is an error as you found out.

    'The first color in the struct is green, that might be the reason for the strange color order'

    The beauty of C/CPP is the ability to use pointers to access items. The structure above allows for the definition of the three color items, and as you were on the right track, just needed to get to the usage part to see how that structure is implemented. Those three items therefore, can be used in any order as can be seen by:

    Using the link you provided NRFDriver in #13 above, but use the i2s_ws2812b_drive.c file

    and now my understanding of 'C' is now in question as from line L75 those colors are bit shifted.
    uint32_t rgb_data = (p_led->green << 16) | (p_led->red << 8 ) | p_led->blue;

    Am I getting Javascript and C/CPP/C# muddled here, as I always believed the order of a structure definition didn't set the order of the data. Anyone able to clarify here?

    As you can see, the above module is for the nRF devices using I2S

    The following is for STM using I2C  hardware SPI

    @Gordon passed along this link some time ago for the Neopixel source:­b/master/libs/neopixel/jswrap_neopixel.c­


    but the only reference searching GitHub turned up­b/master/libs/wio_lte/jswrap_wio_lte.c

    L51 unsigned char rgb[] = {(unsigned char)g,(unsigned char)r,(unsigned char)b};

    which does perform a byte reorder, but why is this in the WioLTE file?    Neopixel !== GPS
    'The Seeed Wio LTE board is an open source gateway which enable faster IoT GPS solutions'

    Is it possible there is a suitable Neopixel plug that is to fit into the I2C pin connector on that board? e.g. This board has multiple other uses than that shown?

    I was unsuccessful at locating the source file that contains how the byte order appears for

    My understanding is that to keep the data ordered, it is assumed that it will be RGB to keep the mental model accurate, and left up to the implementer (us) to provide the byte oder to the setup array for require("neopixel").write()


Avatar for AkosLukacs @AkosLukacs started