Compile errors with Neopixel library and Dotstar library on Raspberry Pi


WOW! :heart_eyes:

This is exactly what I need @ScruffR !
I can use it also with a normal function and it works like a charm!!!

Thanks for this great sketch, I will try to use it straight away with the RPi!
Only, I am not sure if I can connect the strip the same way like the Photon…
The Rpi is not 5V tolerant…
So, I should protect the SPI ports, right?



There are variations of course (zener diodes, level converters etc…) but this is the simple protection method I 'd like to use for ALL RPI GPIOs:


Any comments somebody?


For one, this is a silicon diode, so it has a forward voltage of ~0.7 V which will allow the voltage on the GPIO rise to ~4.0V before the diode actually opens and then you are back-feeding ~4.3V into the 3.3V out side of the regulator, which might not be happy with it (the Particle device’s regulators will definetly not, and since the µC sits on the same rail it won’t be either).

I can’t talk for the RPi’s regulator, but I’d at least go for a Germanium Schottky diode which will have a forward voltage of only ~0.2V


That’s right @ScruffR, I hesitate also, but I read in a RPi blog that this should be fine…

Is there an IC with 8 or so bidirectional logic level shifters?


Yes, there are some.
That’s one of them


Great tip @ScruffR, thanks!
I ordered these for $1/pce:


Hey @ScruffR, this is really a great way to control these Dotstars.
But is there a possibility to also control the first led in a string?

When the following Particle.function() arguments are sent “1,255,0,0,31” the second led turns RED.
With “0,255,0,0,31” they ALL turn RED…



Hmm, of course it’s possible, but when I tested I had the impression 1 did turn on the first LED.
If it doesn’t on your strips, you can always adapt the code that does the parsing.

e.g. like this

 if (sscanf(arg, "%d,%d,%d,%d,%d", &px, &r, &g, &b, &br) >= 4)
    if (px > 0)         // set LED with number px
      px_ = px--;
    else if (px < 0)    // set LEDs 1 .. px
      px_ = abs(px);
      px = 0;


Thanks again for the tip!
On the road till sunday evening…
I’ll try as soon as I’m back in town…


Hi @ScruffR, here we are again under a clear sky full of great DOTSTARs…

Starting from your above sketch, remotely controlling DOTSTARS with a Particle function, I modified it to set the colour and brightness of individual LEDs for my “status panel” (to be connected to a Raspberry Pi)

Below sketch “kinda works”, but not fully yet:
Colour and intensity of the leds is OK, but not the correct pixel Nr. is transmitted to the strip.
( See my comment in the loop() )

const int LEDCOUNT = 70;
uint32_t pxBuffer[1 + LEDCOUNT + LEDCOUNT/16 + 1];
uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness = 31);

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

  for (int px = 0; px < LEDCOUNT; px++)
    pxBuffer[px] = 0x000000E0;

  setAPA102Color(-1,0,0,0,31); // Initializing the strip...

void loop()
// TEST: Alternate the colours for 3 LEDs to RED and BLUE...
    // ATTENTION: I expect #40,41 & 41 to respond, but instead, #0,1,2 respond... Troubleshoot!
  setAPA102Color(40,0,0,30,5); delay(1000);
  setAPA102Color(41,0,0,30,5); delay(1000);
  setAPA102Color(42,0,0,30,5); delay(1000);

  setAPA102Color(40,30,0,0,5); delay(1000);
  setAPA102Color(41,30,0,0,5); delay(1000);
  setAPA102Color(42,30,0,0,5); delay(1000);

uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness)
  uint32_t color = 0;

  color |= (brightness <<   0) | 0xE0;
  color |= (b          <<   8);
  color |= (g          <<  16);
  color |= (r          <<  24);

  pxBuffer[px] = color;

  SPI.transfer(pxBuffer, NULL, sizeof(pxBuffer), NULL);

  return color;

Thanks for any tip which can point me in the right direction again…

BTW: Sorry for the blocking “delay()” commands again… :wink:



You need to first “initialise” the pxBuffer.
For each LED in the strip you need to pre-set the 0xE0.

This is what setLEDs() (in my original code) would do when you send a negative px number or pass invalid parameters.
So calling setLEDs("-1,0,0,0,31") in setup() should do the trick.

Or what I actually already had written in my original code …

… that wasn’t there for decorational purposes but had functional siginificance :wink:


OK, thanks for your reply, but I am not using the setleds() particle function in this sketch…

I’d like to use the setAPA102Color() function directly to control each individual strip from within the loop() or from another function.


Then you need to mimik its behaviour for initialisation :wink:


I added this line to setup() in my sketch above, but the behaviour is still the same:

The sketch sets the colour and intensity but for the wrong pixel #…


Do you see the difference :wink:

As I said


I modified this, but still no change in behaviour…

For this I’ll have to experiment…


In order to mimik the wanted initialisation that setLEDs(-1) (or any equivalent call) performs you need to do this at least once

  for (int px = 0; px < LEDCOUNT; px++)
    pxBuffer[px] = 0x000000E0;

setLEDs() had this for() loop inside its belly, setAPA102Color() is not featuring any loop hence, calling it for one pixel will always only set one pixel.

Also since you added the SPI.transfer() call to your setAPA102Color() you are sacrificing performance whenever you want to set multiple pixels before actually needing to show them.
Hence I had the separation between updating the pixel buffer (pxBuffer[]) and the actual transfer.


Thanks! that was the golden tip!!!
I modified set-up like this and all works fine!



I rather tend to not provide ready-meal answers but rather want my code to be understandable and hence understood :wink:
It’s much more rewarding for me when I know I was able to explain a concept than just provide a solution.

With the for() loop in place that setAPA102Color(-1,0,0,0,31) call is superfluous as it wouldn’t anyway do what setLEDs(-1,0,0,0,31) would have done if it were still there :sunglasses:


That’s fantastic! Even I can now understand this… :rofl: