Compile errors with Neopixel library and Dotstar library on Raspberry Pi

Hi Particle community,
I have looked up if a similar issue was already reported and I didn’t find any. Therefore I create a new thread…

For my distributed home automation system, using a dozen of Photons, I would like to use a Raspberry Pi 3B+ as the “conductor” of my Photon orchestra:
It should collect the live data from all “musicians” and show the home systems status on a panel using about 100 neopixels.

When one of the musicians does not respond, it should hard reset it with a short power cycle. (Seems to be needed for some on a regular basis, even without memory leak… :frowning:

I have tried out the “Particle Pi”, using the GPIO’s available and they work fine.
Now I want to connect a string of Neopixels to test this but I run into compile errors shown below:

Question: How can I use Neopixels on the “Particle Pi” ?


adafruit has an article specifically about using neopixels with a RPi:

Note in the first paragraph this key statement which will apply to running within the Particle Agent:

Because the Raspberry Pi runs a multi-tasking Linux operating system it doesn’t have real-time control over its GPIO pins and can’t easily drive NeoPixels.

I would assume the easiest way to get this going is to figure out how to run NeoPixels on the RPi separately from the Particle Agent and then figure out a method of communication between the Particle Agent and your RPi code running the NeoPixels.

1 Like

Not a solution for your NeoPixel problem, but there are other smart LEDs that are way less timing dependent than NeoPixels.
APA102 (aka DotStar) are my choice - a bit more expensive but definetly a lot easier to drive (no library needed at all)

1 Like

Thanks @cyclin_al and @ScruffR for your quick tips!
I will study these resources and hope to find a way to make this work…

I read the article about the special library but this is exceeding my programming experience, I’m afraid…
For this application, I suppose the APA102 (aka DotStar) will be a solution.


1 Like

I have ordered a 1m strip with 144 LEDs…
Meanwhile I have tried to compile a short test program for Dotstar LEDs but it also fails:

Obviously, it was not validated for using it with a RPi…

@ScruffR: You say we don’t need a library…

Question: How do you propose to control individual LEDs of my status panel?

For example:

  • Set LED #8 to 15% RED, 50% GREEN and 20% BLUE
  • Set LED #67 to 20% RED
  • Set LED #88 to 20% RED and 70% BLUE

This was one of the simplest ways I could come up for controlling an APA102 strip of virtually any length.
I’m not sure whether HW SPI is supported by the RPi Particle Agent, but if it isn’t pushing the data out in a synchronous fashion via shiftOut() should be just as simple.

1 Like

Thanks for this @ScruffR!

As soon as I receive this strip, I will test it with below sketch.
Can you check if it should work with the commands after " // setup your pixels"
(It does compile for RPi…)

#define LEDCOUNT 300
uint32_t pxBuffer[LEDCOUNT];
// actually for the APA102 protocol you need some extra bytes for leadin/leadout
//uint32_t pxBuffer[1 + LEDCOUNT + LEDCOUNT/16 + 1]; // element 0 (leadin) ... LEDs ... 1 leadout clock per 2 LEDs (ceil)

bool needRefresh;
volatile bool canRefresh = true;

void setup()
  SPI.setClockSpeed(8, MHZ);

uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness = 31)
  uint32_t color = 0;
  // due to big endianness in revers order 
  color |= (brightness <<   0) | 0xE0;  //top 3 bits must be 111
  color |= (r          <<   8);
  color |= (g          <<  16);
  color |= (b          <<  24);

  pxBuffer[px] = color;

  return color;

void refreshDone()
  canRefresh = true;

void loop()
  // setup your pixels
  setAPA102Color(8, 30, 100, 40, 100);  // = Approx. "Set LED #8 to 15% RED, 50% GREEN and 20% BLUE"
  setAPA102Color(67, 40, 0, 0, 100);    // = Approx. "Set LED #67 to 20% RED"
  setAPA102Color(88, 40, 0, 140, 100);  // = Approx. "Set LED #88 to 20% RED and 70% BLUE"
  if (needRefresh && canRefresh)
    canRefresh = 
    needRefresh = false;
    SPI.transfer(pxBuffer, NULL, sizeof(pxBuffer), refreshDone);

delay(2000); // Slow down loop...



For the color components 100% = 255 and for brightness 100% = 31.
And you need to set needRefresh = true when you want to set new colours.

Apart from that I don’t see why it wouldn’t work.

1 Like

Thanks for checking @ScruffR!

One strange thing though:
Why is there a separate brightness value specified?
If I set R, G and B values for the 3 led chips is that not enough?


That’s a feature of the APA102 LEDs that makes it easy to dim the LEDs without having to recalculate the RGB ratios.
The dimming is also achieved differentyl. While the RGB values are created with a higher frequency PWM signal (19.2kHz) the dimming is done via a superimposed 582Hz PWM. So the actual color stays exactly the same, it’s just not displayed all the time.

This makes things like a breathing effect really simple, since you just need to modulate the one brightness value without needing to adapt the RGB values which is - when considering the human psycho-optic perception - not as straight forward as just linearly scaling it down the RGB components (not that this would matter for the average use tho’).

1 Like

Thanks a lot for your deep explanation @ScruffR!
That sounds like a great progress indeed.
Can’t wait till my string of Dotstars arrive…

I found that 2 versions (manufacturers?) exist: APA102 (aka “Dotstar”) and WS2813…
Do you know the differences, advantages?


I haven’t found a lot of info about the low level workings of the WS2813 but one thing I found was that it seems the WS2813 has a lower RGB PWM frequency (2kHz vs. 19.2kHz)
For more detail I’d have ot order some WS2813 and have some signal analysis - if I ever find the time :wink:

1 Like

OK, I know what you mean!

The strip I ordered is made of the WS2813 chips.
I’ll try them out with your sketch…


Maybe this explains something more:

I had a look at that, but had the impression that it was written somewhat confusing :blush:

1 Like

Hi @ScruffR, I have received my strip of 144 WS2813 “SPI-addressable LEDs” some time ago but I only found time yesterday to try your test sketch with the Photon.

My objective: If that works, I want to make a 100-LED status panel with the RPi…

This is how the 1 meter long strip looks:

I guess the connections from top to bottom are as follows:

  • RED = “5V” (=> Vin)
  • GREEN = “IB” = “IN Backup data” (=> A3 = CLK)
  • YELLOW = “ID” = "IN Data (=> A5 = MOSI)
  • BLACK = “–>” (=> Gnd)

I have connected it as shown:

The sketch compiles fine and I flashed it to the Photon, but I can’t see any response… :frowning:

Possibly this stip is not compatible with the 3v3 data pulses, contrary to the classic addressable chips…
So, I can test it with an Arduino Nano if you believe I can use the same sketch…

Any suggestions meanwhile?
(I’ll be out till sunday…)


What is the exact type of that strip?
The wording “IN Backup Data” sounds puzzling. The CLK line does not carry any data (backup or not) but only provides the timing.

So I now found a datasheet of the WS2813 and as it turns out they are not comparable to the APA102 when it comes to protocol. These LEDs are still using a time critical protocl like the original NeoPixels but feature a sort of bypass feature where one broken LED in the chain shouldn’t affect the following (hence the naming “Backup Control data signal input”)

So I’m afraid, my simple code won’t work on these but only on APA102 LEDs and compatible ones (WS2813 aren’t).

1 Like

Thanks for yr quick reply!
I am travelling and will try to respond from my iPhone:

I understand that “Backup data” sounds confusing… but the terminology for both datalines comes from the eBay seller.
If you want, I can send a screenshot when I’m back home…

For this LED, I find this link:


Never mind, I ordered another strip of REAL APA102 chips now:


Indeed, here you can see the correct markings: Data & Clock, In & Out!


I ordered the type with higher density: 144 LEDs/m, that’ll better for my status panel design…

Delivery end of july…
“I’ll be back!”

1 Like

Update for the “wrong DOTSTAR strip” (WS2813) I bought earlier:
indeed, using any of the 2 data wires, it works with the traditional “Neopixel” library.

Q: Any idea how we are supposed to connect both wires to a Photon? Both in parallel?

In that case, they could as well do that on the flexible PCB and let only one wire come out…