These are chat archives for Makuna/NeoPixelBus

16th
Dec 2018
Benik3
@Benik3
Dec 16 2018 12:44
Hello.
I will slightly continue with previous recommendation.
I want to use ESP for Ambilight. I will not use Wifi, but I will use Serial 0 for receiving (and sending) data from PC and serial1 to control the strip (so there will be no problem with disabling interrupts like on AVR). Now on AVR the code looks like this: https://www.electronoobs.com/eng_arduino_tut29_code2.php
What I got from above, the best practice would be to write the received data directly into the buffer (strip.pixels())) and then call dirty() ?
Thank you
Benik3
@Benik3
Dec 16 2018 14:55
If I got it right, it use predefined "picture" (the sprite in cylon*.h) which it shows and updates.
But I got the data dynamically from serial line as RGBRGB... bytes. That's why I though, that I could write it directly into internal buffer of NeoPixelBus to avoid storing it in second buffer and then processing (copying) it to internal buffer of NexoPixel to Show up.
Benik3
@Benik3
Dec 16 2018 15:05
The strip has 110LED to be more specific...
Michael Miller
@Makuna
Dec 16 2018 20:21
@Benik3 The data in NeoPixelBus.pixels() is in the byte order that your physical LEDs use. This is often NOT RGB (in that order). The most common order GRB, in my sample this is defined by using a feature when constructing the NeoPixelBus, like NeoGrbFeature.
The order of the data coming in is RGB.
Look at this sample https://github.com/Makuna/NeoPixelBus/tree/master/examples/bitmaps/NeoPixelDibTest for how NeoDib is constructed and used. It not exactly what you want but it deomstrates the class.
Fill an instance of NeoDib pixels (as they are RGB in order), then Render it to your NeoPixelBus. It will translate the byte orders for you then.
Benik3
@Benik3
Dec 16 2018 20:40
Thanks.
It's true that the HW is in order BGR. But I can change order also in the controller SW in PC, I can test it and it will then maybe send the data in the right order to fill the buffer direct.
Michael Miller
@Makuna
Dec 16 2018 20:41
That will work, also, another simple way that doesn't require an extra buffer is to fill a RgbColor color object, then just call SetPixelColor, incrementing the pixel index.
Benik3
@Benik3
Dec 16 2018 20:43
I just checked it and it was mistake, I can't change color order :/
So the DIB is only way and use the Render
The SetPixelColor will be probably easiest
Michael Miller
@Makuna
Dec 16 2018 20:46
from the code you linked, yes, it would be very simple to switch
  for (uint8_t i = 0; i < NUM_LEDS; i++) {
    RgbColor color;    
    while(!Serial.available());
    color.R = Serial.read();
    while(!Serial.available());
    color.G = Serial.read();
    while(!Serial.available());
    color.B = Serial.read();
    strip.SetPixelColor(i, color);
  }
Benik3
@Benik3
Dec 16 2018 20:47
exactly, thank you very much for your time, I will test it tomorrow (I will have new LEDs in my hand) :)
Benik3
@Benik3
Dec 16 2018 21:13
One last question, do you recommend to use NeoEsp8266Uart800KbpsMethod or NeoEsp8266AsyncUart800KbpsMethod?
I can't use DMA when I'm using Serial 0 (because of the pin3).
Michael Miller
@Makuna
Dec 16 2018 21:46
Async is better, but if RAM becomes tight, you can switch to the non-async as it uses less memory (asyc requires keeping a buffer of the pixels that it sends while you can start setting colors).
Benik3
@Benik3
Dec 16 2018 21:54
this is only SW in the ESP so I thing that the RAM will not be problem :)
Thank you!