Hello everyone! This is my first dip into the FastLED community, and I need a bit of advice.
I have been using WS2812 for my christmas lights, I currently have a 900 pixel segment run under the gutter that I power with an Arduino Mega and the 3.0.3 library.
The problem that I have as my segments get longer, the refresh rate is getting really slow, and I can’t make the animations that I want to. It seems that the arduino starts to struggle past 300 pixels to get through simple loops to scroll.
I have tried the example libraries, and removed all the delay lines, and it is still not fast enough for what I desire.
Am I doing something wrong in code, or do I need to switch to a different microcontroller such as a Teensy 3.1 or an RPi with a higher clock speed, or is there some sort of trick that I can make things go faster. I originally went with the Mega as I started off with the Adafruit library, then ran across FastLED trying to get Josh.com’s simple neopixel library to work.
Some of it is simple math. It will take you 9 times as long to update 900 LEDs as 100 LEDs. If you are doing anything like expensive math per pixel it is going to be particularly noticeable.
Also, the ws2812’s have pretty precise timing requirements that work out to 30us per led, no matter what your clock speed is. That means 100 LEDs will take 3ms to write out, 300 LEDs will take 9ms and 990 LEDs will take 27ms.
I’d strongly suggest considering moving to a teens 3.1 or an arduino due for that many LEDs. Not only do you get higher clock rates (96 or 84Mhz vs 16 on the mega) but you also have the option to write out led data in parallel between 8-16 lines, which will cut out a lot of the overhead of pushing data out to the LEDs.
Oh - also, the other thing you should pay attention to - you’re going to need to inject power at various points (every 100-200 leds, at the least) along your line of leds.
Power is not a problem, I have that taken care of (I’ll have to post that project at some point).
I’ll get a due or teensy and hopefully that will improve things. Is the lack of SPI going to be a big problem? I love the density of the strips I am using (300/5m) and I am already a bit invested in them.
Should I be looking into different strips as I move forward? I am not looking to do anything complicated, but want to be able to chase and scroll colors / animations very quickly to have a fun and unique light display.
(Power is one of those things that I always mention when the led counts get high - I never know who has thought of that vs. who hasn’t
No, SPI isn’t even an option. (I mean, there are people who have hacked SPI subsystems to drive WS2812s, but it doesn’t make them magically any faster, so I’m not bothering with it for FastLED).
If you go the due or teensy 3.1 route I’d strong recommend looking into splitting your leds. If you’re writing 8 or 16 lines out in parallel, it effectively lets you write led data 8-16 times faster (real world gain is a little bit slower, just because of some extra house keeping overhead, but still a very very strong multiplier) - so instead of taking 27ms to write out your 900 leds worth of data, it’d be 3.5 for 8 ways or under 2ms for 16 ways
As far as leds go, I’m leaning towards the APA102’s being my next generation of “Most Favored LED chipset” for my own projects. They have a much higher native data rate (12-20Mhz vs. the WS2812’s 800kHz), because they are driven by SPI I have a lot more options for using/abusing DMA to drive data out. AND i think i might even be able to do parallel output for the APA102’s - but that’s going to require a bit of experimentation and thinking to get right, but i’m very very hopeful
I have a Due on its way to me, and I should have it tomorrow.
When you talk about writing lines in parallel, I take it then I use multiple pins to drive the strip, in my case (sealed silicone) every 5m I’ll cut the data line between strips and wire that back to a different pin on the Due.
Is there any example code for say ‘cyclone’ using parallel writing? I need to work on thinking in terms of modifying my animations to write out in parallel.
I’ll also check out the APA102 for next year … gotta make it bigger and better every year I love when amazed neighbors ask where I got my lights.
As for his article - two bits. One bit is that at 5µs, that’s only 80 clocks on the avr, or more importantly ~26 clocks for each of r/g/b - that’s not a lot of space to really do pixel computation (you’d have to do some impressive gyrations to break up work for it, not sure that it’s worth it The other is that what he’s describing will also slow down the rate of writing data out to the leds, so that 30µs per led I was quoting above? Could end up taking even longer.
It is a nice hack if you’re really tight on memory, but ultimately, when it comes to frame rate, you’re limited by the minimum of 30µs/led.
(This is also why interrupts are allowed on the due, but not on AVR w/WS2812’s, because it turns out that it is really really really difficult to to write a useful AVR interrupt handler that will run in under 80 cycles
I love when amazed neighbors ask where I got my lights.