Hi there, I’m trying to get the Fire2012 examples running on my Adafruit Flora + 12MM LED pixels, but I suspect I’m not modifying the example correctly. Although the upload to my Flora appears to complete successfully, only the second and third LEDs light up once powered.
I was able to successfully use the FirstLight example sketch, and I’m also able to use the WS2801 example code from Adafruit, so I think my hardware is OK. Can anybody give me an idea whether I’m doing this correctly?
Here are the code changes I made to the example…
First, the definitions:
#define DATA_PIN 12
#define CLOCK_PIN 6
#define COLOR_ORDER GRB
#define CHIPSET WS2801
#define NUM_LEDS 50
#define BRIGHTNESS 200
#define FRAMES_PER_SECOND 20
Then, the addLeds() call:
FastLED.addLeds<CHIPSET, DATA_PIN, CLOCK_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip );
Other than that, the example is exactly the same as it is in GitHub.
Thanks for all the amazing work you’ve put into this library!
Another possibly relevant detail:
After I upload the Fire2012 sketch, when I restart the Flora the red light breathes. Additionally, when I attempt to upload another sketch, the IDE can no longer find the Flora on any COM port. To get another sketch to upload, I have to hit the rest button during the upload.
I tossed the verbose upload output on gist, in case that is useful: https://gist.github.com/LaughlinElkind/cdb842160d1c95349225
How are you powering the strip? I find that the reset/cannot find scenario you describe happens when I’m drawing too much current directly through the Arduino, vs a separate power supply to the LEDs
I’ve tried this both via USB power, and via a 5v usb pack going to the JST power connector on the Flora (with the LEDs connected to VBATT).
I was worried that it was a power issue, so I tried pulling one of the strands of LEDs off and switching NUM_LEDS to 25, but it didn’t seem to make a difference.
For what it is worth, the strandtest sketch from Adafruit works fine with all 50 LEDs and the same wiring configuration.
Oh, and the same thing happens when the sketch is uploaded without any LEDs connected at all. It also drops off my list of serial ports, so I can’t add any helpful debug printlns.
Sorry, I’m mostly taking guesses here, but…
Have you tried the RGBCalibrate example? It’s as simple as it gets & might be a baby step towards FastLED.
If I remember, there was a note about certain WS2801s possibly needing special handling, so FastLED has a config you can tweak to slow down the write speed. I don’t remember where that came from but search the Wiki for WS2801?
Thanks very much for the suggestions - I’m just making guesses myself.
I did try RGBCalibrate earlier, and it does run, but the 6 LEDs it lights flicker, whether I’m on USB power or using my battery pack. Maybe the flicker is a relevant symptom for whatever I’m dealing with?
The FirstLight example seems to run fine, but it is possible that the lights change too quickly for me to notice any flickering.
Let me see if I can dig up that WS2801 warning
read the note at the bottom of: https://code.google.com/p/fastspi/
re: ws2801 and flashing
(this is for FastSPI, the earlier version of FastLED – so it may not apply any more)
Hmm, FastSPI_LED.setDataRate() is undefined, as is FastLED.setDataRate(). I took a peek at the headers and don’t see anything there - maybe this is something removed from v2?
It looks like chipsets.h has a default 1MHZ data rate and 1000 mindelay for ws2801 chips, the latter of which was bumped up from 500 apparently in response to this issue: https://github.com/FastLED/FastLED/issues/6. Mntocean (the user who opened the issue) is also using the exact same LEDs as I am
I tried adding a delay(1000) to the loop in RGBcalibrate and it got rid of a any fast flickers, but the lights aren’t solidly on (there is a tiny momentary flicker about once per second).
Right about now, I’m regretting my purchase of ws2801 based LEDs .
Thanks again for all your help.
Yeah, probably is removed and/or no longer necessary. BUT it might be worth seeing if Daniel has any thoughts on that. It does appear in chipsets.h that there’s a “DATA_RATE_MHZ(1)” definition for SPI_SPEED and that might be the new version of same.
Coincidentally I already had a Flora wired up to WS2801, so I loaded Fire2012 stock example and it’s working fine. My DATA_PIN is 6 and CLOCK_PIN is 9, just for kicks you might try those just to be safe. (would need to re-attach the data wire obv.)
Also mine is RGB not GRB, so we’re using different WS2801 strips and I still suspect there’s something going on with that…
OK good find on that issue. Are you updated to the FastSPI 2.1 branch? It’s probably worth the switch.
Long shot: if you happen to be going to playa with this, I have a bunch of extra WS2801 (of my no-flicker kind) I could get you some there…
Mine is RGB too actually (which I was helpfully informed of by RGBCalibrate), but I pasted that code snippet before changing it. I am also already running the 2.1 branch
Unfortunately, I made an extremely rookie mistake by soldering a pigtail onto the Flora’s pins after I successfully ran the strandtest example included in Adafruit’s ws2801 library.
I am indeed headed to the playa, tomorrow night in fact (my procrastinating ass deserves every technical issue it gets). As such, I’m probably going to poke around a bit more for software fixes before I redo the pins on the Flora. That’s incredibly generous to offer up some lights - but the LEDs are mostly already attached to the jacket i’m working on. Doh.
Perhaps the other lesson I should learn (besides staying away from ws2801) is not to install your hardware before you’re 100% satisfied with the software.
What pins are you using for SPI on the flora? It is possible that the timing for bitbang’d SPI output is off, and that it’s writing data too quickly to the WS2801 chips that you have. You can try changing the addLeds line to:
FastLED.addLeds<CHIPSET, DATA_PIN, CLOCK_PIN, COLOR_ORDER,DATA_RATE_KHZ(500)>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip );
(This will push the data rate down a bit, which might help).
(Also, @Steve_Eisner FastLED is a ground up, complete rewrite of the old FastSPI_LED library - nothing on https://code.google.com/p/fastspi/ should be considered valid/useful except for the redirects to github 
I’m using pin 12 for data, 6 for clock.
I just tried adding the DATA_RATE_KHZ argument to addLeds, and it is showing the same behavior of dropping off the COM port and requiring a reset-during-upload to get another sketch onto the Flora.
No com port, and needing to hit reset to get an upload sounds like trinket behavior - I wonder if the bootloader went screwy at some point? (Mostly, I was addressing the DATA_RATE_KHZ for the possibility of pushing data too quickly to the WS2801’s, which can cause problems for them. Also, if your number of leds is really low, there is such a thing as writing to the leds too many times a second, which is something that I need to add protection for in the library - My personal projects tend to run in the 100-3000 led range, so that is a particular problem I rarely hit 
Try this, go into fastspi_bitbang.h, down to around line 168 (it’ll be inside the method writeBit) and change the
#if 0
to
#if 1
Pins 6 and 12 are on the same port and there’s an optimization that the library does in that case to try to get the fastest data speeds out, and it is possible that is, in your case, causing the problems with the leds misbehaving.
(FLORA Dead? - adafruit industries seems to indicate that sometimes the flora needs to have the reset button pressed to reprogram it)
@Mike_Thornbury FirstLight and RGBCalibrate work, as does striptest from the Adafruit_WS2801 library. I haven’t attempted funkboxing’s demo - I googled it and it looks like it might not be terribly straight forward to get working, as it seems to be using an older version of FastLED (unless I’m just failing at google and there is a newer version of the demo somewhere that I’m not seeing).
@Daniel_Garcia I swapped the if statement on the line you indicated, and it didn’t seem to produce any different results.
It does seem like the flora occasionally needs a reset during upload, but this makes it terribly difficult to debug Fire2012, because it drops off the COM port as soon as the sketch uploads, and I’m unable to add any debug print statements to see where this is falling apart.
Anyway, thanks to both of you for taking the time to respond to my thread. Whether I get anything prettier than strand test running right now, I’ll definitely be using this library for some other projects in the future.
@Laughlin_Elkind I had that issue when starting with the Flora too (losing the COM port) I don’t know what fixed it, things just got more stable and I stuck with the pattern.
For serial output, put a delay(2000) at the very beginning of your start() to give you time to open up the serial window and catch the startup debugging.
& do try flipping pins, since Daniel has confirmed that there is different code running based on your selection of pins (same port) vs the defaults (different ports)