Neopixel bug (w/ Arduino Yun/BANNED) (255,255,255 not working)

[awardblvr]

Problem...

In the Adafruit Neopixel library, sketches / objects and their members overall work fine... Except when you try to use the class member to set a single pixel to all white:

Code: Select all

    // Set pixel color from 'packed' 32-bit RGB color:
    void Adafruit_NeoPixel::setPixelColor(uint16_t n, uint32_t c) {

And employ it on an Arduino Yun/BANNED with a call like:

Code: Select all

   Console.println("White");
    strip.setPixelColor(0, strip.Color(255, 255, 255)); // White
    strip.show();
    delay(4000);

The pixel Flashes white, then goes to black (off)

However if you change the above with:

Code: Select all

    strip.setPixelColor(0, strip.Color(255, 255, 254)); // or make any of the 3 values so that they are not all 3 the same...

Then the pixel works fine... stays (almost) pure white as possible.

What is the library or HW bug where (on the Yun/BANNED, at least) where if these three color values are the same non-zero values, it flashes that color then instantly changes to off?

Any suggestions / discussion welcomed.

(Using a straight WS2812B connected directly to the Yun, pin 6 for Data/clk)

-Andrew

[pburgess]

That's a new one. Can't think of anything offhand that would trigger this behavior...and unfortunately don't yet have a BANNED to test against. Do you have an Uno that you could compare for posterity? Or could you try pin 5 on the BANNED? I'll examine this as soon as I have some hands-on with the new board.

[pburgess]

BANNED acquired. The following sketch works as expected w/both WS2812 and WS2812B:

Code: Select all

#include <Adafruit_NeoPixel.h>
#define PIN 6

Adafruit_NeoPixel strip = Adafruit_NeoPixel(1, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
}

void loop() {
  strip.setPixelColor(0, strip.Color(255, 255, 255)); // White
  strip.show();
  delay(1000);
  strip.setPixelColor(0, strip.Color(255, 0, 0)); // Red
  strip.show();
  delay(1000);
}

Not sure what to suggest. Can you try the above program and see what happens? Can you post a complete sketch that exhibits the problem? Try another pixel? Are you using a bare chip, or do you at least have a decoupling cap on there?