I’m trying to control a 5m/150 LED dotstar (apa102) strip with a teensy 3.6. If I understand correctly, Teensy 3.6 is supported in the current master on https://github.com/FastLED/FastLED.
Trying to run any of the stock FastLED examples, however, seems to go haywire. The Blink example (gist link to exact below) does make the first led blink red, but the next 70 or so also blink red in a slower pattern, and further down the strip I get a mix of colors including white, blue, green, and some pixels that just remain off.
I’m guessing I’ve either just missed a step or misunderstood something - can anyone spot an obvious error in what I’ve done? This setup does run the Dotstar “Strandtest” example just fine, so I don’t think there’s any faulty hardware involved.
I’m running the Arduino 1.8.2/Teensyduino 1.3.6 IDE under OSX 10.11.6.
I would expect Blink to blink only the first LED, which is what happens if I run it on, for example, an Arduino Uno (well, technically a SparkFun redboard).
Blink is just the simplest example of the problem here, though - other FastLED demos such as Cylon and DemoReel100 also fail to work properly, just with a more flickering and harder-to-describe pattern.
Strandtest (which is an Adafruit Dotstar library example) works fine. As far as I know, there’s no FastLED equivalent with the same name.
As for the color arrangment, BGR is the appropriate setting for this particular strip - using RGB just changes the color of the lights that blink (making the first one blue, though oddly the color of the next 70ish pixels is still red).
I don’t know how well tested the 3.6 code is - I took a pull request from someone with the changes, but haven’t had a chance to try running through it myself.
Try reducing the clock speed. With the APA102 I find slower speeds get better results over longer distances. Although that is with the Teensy 3.2 not 3.6.
Have a go and see if it works.
Thanks, all. Following up, I’ve found a way to make it work, though at what I think is far less than the APA102’s capability.
What I did was explicitly set the SPI_DATA_RATE to a much lower value. After some experimentation, it seems the maximum value I can set that to and still get appropriate behavior is DATA_RATE_KHZ(2666). Again, this is for a 150 led strip.
Based on Daniel’s APA102 speed run reports a few years ago, it seems that a strip like this ought to run at 12 MHZ without much trouble, so I’m guessing this is more of a workaround than a real fix. But hey, at least I’m in business - we’ll see what happens when I start adding additional strips.
It doesn’t matter - it looks like you’re using software spi - that’s never going to get above 4-6mhz real data rate - my guess is that on the teensy 3.6 when software spi is effectively running with no delays internally to try to control the clock speed it’s flipping something too quickly for the chip to handle (e.g. the pin never gets fully high before being dropped) or the compiler is doing something.
Oof… mentioning the pin not getting fully high may have just tipped me off to at least one more contributing issue. Seems I completely spaced that the teensy outputs 3V, but the LED strip expects 5V signals.
I’ll update once I’ve picked up a level shifter and straightened that issue out.
I almost asked if you were using a level shifter earlier, but since you said the Adafruit test was working fine I figured that wasn’t it. Hmmm, now I’m indeed curious. Here’s a handy reference for you.
I did indeed acquire a level shifter (though a 74AHCT125 in this case, didn’t immediately find a source for the 74HCT245). My only attempt so far did not succeed, but I was on my way out of town so it was a rush job and I didn’t have time to troubleshoot - I may well just have mis-wired it. I’ll hopefully get down to sorting through that in the next few days.
My apologies for the (very) late update. I did need the level shifter, but the real problem eventually turned out to be that the APA102 strips we were running apparently don’t support a data rate higher than 1.2M. I think I know why we got them cheaply.
For those of you attending Burning Man, these will be on the petals and mobile trusses of The Dragonfly Mating Ritual. I’m afraid it’s all going to be fairly bare-bones, not-far-from-example code… we’ve had other hardware issues as well, so I’ve had very little time to write anything for the animations.
At least I’ve got an entire year to work out better stuff before we return with it in 2018… or so I keep telling myself.
Hi. Did you resolve? Im running a strip of 1,038 APA102s with a T3.6 and the best I can use is 8MHz on SPI0 without it crapping up at the end of the strip. Because the APA102s use the cascaded clock line Im getting some weird visuals when increasing the frame rate, hence I need to figure out how to up the SPI data rate. Thx!
Well, it depends on what you mean by “resolve”. Our issue turned out to be the hardware - I’m not exactly sure where the team member doing the procurement bought the strips, but when we took a close look at the specs for them, it listed their max data rate as 1.2Mhz. So there really was no way to improve it, but fortunately it was also was good enough for what we needed. We just drove multiple sets of strips from separate digital i/o pins.
One possibility - how long a distance/how many LEDs are you running from a single power input? I didn’t do our electrical work, but as I recall we were only able to run 2 or 3 5-meter/150 LED strips from each. Any farther than that and things started acting flaky because we just didn’t have enough power.
“Resolve” - Was hoping you figured it out and were able to crank it up!
I have a staff with 6 each 8’ strips. They are all parallel and next to each other, but wired in series (zig-zag style). Power is all connected up at each end of each strip so there really shouldnt be any variation in voltage from one strip to another.
It will work at 12 MHz except for sometimes the last 100-200 LEDs get bad. Runs perfect at 8 MHz.
I was also thinking about changing from the one strip to six parallels. This will be a last resort solution. Ill have to peel up thee of the strips and turn around, and also mess with some wiring.
Ill try a few more things before I do it. Maybe theres something weird in FastLED for the T3.6 so Ill try a simple home grown bitbang. Ill adjust the overall clock speed of the T3.6. I guess Ill also see how the strip does when driven with an ATSAMC21.
