Photon DotStar cannot get to work

Firmware Libraries
#1

I can animate a reel of dotstars (APA102) on an Arduino using adafruit/Adafruit_DotStar; however, when I try to use the technobly/Particle-DotStar I cannot get it to work (in neither bit-bang nor SPI modes).

I thought initially that the 40ns/V slew rate for the level shifter was interfering; however, I slowed the SPI down by 128 ( SPI_CLOCK_DIV128) and still no joy.

IMG_3355
IMG_33554032Ă—3024 3.73 MB

// This #include statement was automatically added by the Particle IDE.
#include <dotstar.h>


// GLOBALS
#define NUMPIXLES 30
#define DEBUG true


String app = "xmas-dot-2020: spi/64";
// not working-- trying bit-bang: 
Adafruit_DotStar strip(NUMPIXLES, DOTSTAR_BGR);
// strip(numpix, data, clock)
//Adafruit_DotStar strip(NUMPIXLES, D1, D0);

void testStrip() {
    // test primary colors
    //strip.fill(strip.Color(255,0,0));
    for (int i = 0; i<strip.numPixels(); i++ ) strip.setPixelColor(i, 255,0,0);
    strip.show();
    delay(5000);
    //strip.fill(strip.Color(0,255,0));
    for (int i = 0; i<strip.numPixels(); i++ ) strip.setPixelColor(i, 0,255,0);
    strip.show();
    delay(5000);
    //strip.fill(strip.Color(0,0,255));
    for (int i = 0; i<strip.numPixels(); i++ ) strip.setPixelColor(i, 0,0,255);
    strip.show();
    delay(5000);
    //strip.fill(strip.Color(255,255,255));
    for (int i = 0; i<strip.numPixels(); i++ ) strip.setPixelColor(i, 255,255,255);
    strip.show();
    delay(5000);
    strip.clear();
    strip.show();
}

void setup() {
    strip.begin();
    strip.show();
    Particle.variable("app", app);
    
    // 201130: slowing clock down for level-shifter skew rate.
    SPI.setClockDivider(SPI_CLOCK_DIV128);
    
    if (DEBUG) {
        testStrip();
        Particle.publish("log", "Finished test");
    }
}

void loop() {

}
#2

@marmageek, the level shifter should work but in the picture, you have it connected for software SPI while your code is setup for hardware SPI.

Also, in your picture, you have the GND from the Photon going to the “+” rail on your protoboard!!! I’m not sure how the Photon even works there.

I looks like you are supplying power externally so I assume it is rated to supply the Photon current (say 100-350mA) and the “full-on” dostar current of 30 x 3 x 20mA or 1.8Amps. A 2Amp or more 5v supply is required. Is that what you have?

#3

Must be the angle of the picture… all grounds, 3.3V, and 5V lines are wired correctly. Regarding the picture you are correct as that the picture at the time was wired for bit-banging. As you can see, I wired both bit-bang and SPI (you can see the commented lines of code as well. I have tried both ways and still no luck.

#4

@marmageek, you have a black wire on the RHS of the picture going from the “+” of the protoboard bus to a pin on the Photon which looks like GND. If it isn’t connected to GND, then what is it connected to?

Also, if you have a multimeter, make sure you have power everywhere you expect it, including at the dotstar connector, ideally at the connector. Do you have an oscilloscope?

#5

NB: I have never had the need for a level shifter on genuine APA102 strips.

The APA102 protocol is also so simple that you don’t really need a library to drive them.
If you want specific patterns and “animations” a library may be useful, but to merely set the color you wouldn’t need much more than this.

#define LEDCOUNT 30
uint32_t led[1 + LEDCOUNT + LEDCOUNT/16 + 1]; // element 0 (leadin) ... LEDs ... 1 leadout clock per 2 LEDs (ceil)

void setup() {
  SPI.begin();
  SPI.setClockSpeed(8, MHZ);
  SPI.setBitOrder(MSBFIRST);

  for (i=1; i <= LEDCOUNT) 
    led[i] = 0xFF;                     // initialize all LEDs for full brighness
}

void sendAPA102() {
    SPI.transfer(led, NULL, sizeof(led), NULL);
}
2 Likes
#6

@peekay123— It is connected to - not +. The picture is misleading. It bends back to -.

#7

@ScruffR Indeed it does work without the level-shifter in there.

I did note thought the the spec says [0x0000] +[0xFF][BB][GG][RR]+…+[0xFFFF].
The tail actually turns on an extra pixel to white. So I am guessing you do not need the terminating 0xFFFF.

#8

Actually it would be a lead-in of 0x00000000 (32 zero bits) and a lead-out of all HIGH or all LOW bits (no mixing!) of at least number_of_pixels / 2 bits. Since SPI can only transmit in 8 bit junks you may want to add on extra byte of 0x00 or 0xFF respectively.

Here you can find a good description of the protocol and also some clarification why the datasheets are not entirely accurate (especially the end frame description)

#9

Hey thanks for the reference. I see from this now why my extra lamp lit as my test strand was only 5 lamps. My Christmas tree strand, however, is 300 lamps so by that math, I’d need 150 extra bits!! So I guess my code needs to calculate the end frame length based on the strand. I should also send zeros since the value doesn’t matter (just the clock pulses).

#10

This is what that calculation in my suggested code does.
Since it doesn’t matter whether you have 1s or 0s in the lead-out you can just have the array initialized with 0s (as done by default) and use it as is.

BTW

when you pass a callback function instead of NULL as final parameter, you can even have the transfer happen in the background without the rest of the code being blocked while updating the pixels.

e.g.

  SPI.transfer(led, NULL, sizeof(led), []() { updateDone = true; } );