FastLED v2.1 Beta 1 ?
It is with great pride that @Daniel_Garcia and I claim to announce the immediate availability of FastLED v2.1 BETA 1. We’re claiming that it has a list of exotic high-power features that we hope you’ll find suspiciously long and elaborate considering what day today is!
We’re claiming that the new FastLED v2.1 (BETA) shines in three areas: Compatibility, Color, and Parallel output.
-
Compatibility: FastLED v2.1 adds full support for Teensy 3.1, Arduino Due, Digistump DigiX, and the Adafruit Flora, Gemma, and Trinket. [Update: also the P9813 LED driver chip!]
-
Color: FastLED v2.1 adds per-strip RGB LED color correction controls, and adjustable whitepoint ‘temperature’. In addition, FastLED v2.1 now performs on-the-fly temporal dithering, so high color precision is maintained even at (very) low brightness levels; it makes your 8-bit LED strip perform more like a 10-bit or 12-bit strip. All of these color features, including the temporal dithering, are available on all supported platforms. Even on the ATtiny85, with no hardware multiplier. Even the ATtiny85, with no hardware multiplier, when running at 8MHz.
-
Parallel output: on ARM-based Teensy 3 platforms, FastLED v2.1 can now drive up to 12 LED strips in parallel as fast as driving a single strip. This means the effective pixels-per-second speed just went up 12X. On ARM-based Arduino Due and Digistump DigiX, FastLED v2.1 can now drive up to 16 strips of LEDs in parallel.
-
BETA status! While the FastLED v2.1 code can be found at https://github.com/FastLED/FastLED/tree/FastLED2.1 , the documentation and example code just aren’t there; they don’t exist yet. But if you want to try out the bleeding edge of FastLED, please do!
-
Two notes on dithering! First, FastLED v2.1 has temporal dithering enabled by default. If for any reason you want to disable it, use FastLED.setDither(0). Second, if you have any calls to “delay(…)” in your code, you can greatly improve the visual quality of your animations by changing that to read “FastLED.delay(…)”; this allows FastLED to continue updating your LEDs with the fastest dithered colors possible.
Now… do you really think we were able to cram all of that into FastLED, even though we just released v2.0 in January? Or are we just fooling???
Repeat? " Even on the ATtiny85, with no hardware multiplier. Even the ATtiny85, with no hardware multiplier, when running at 8MHz."
Yep, you read right. All of these new features work, even on the ATtiny85, even when running at 8MHz. Or at least that’s what we’re claiming.
Why not run it at 4MHz? grin
Just kidding about the 16/12-way parallel output thing for the due & teensy.
(I won’t be able to get that code checked in until tomorrow or thursday - judicious use of “fuckery” in the code means it needs some cleanup 
@Ashley_M_Kirchner_No you know, you could probably run the 400khz WS2811’s on the ATtiny85 running at 4Mhz 
I’m pretty sure I could make a version of the code that would run at 4Mhz, sans scaling, but what’d be the fun in that? (Though… I wonder if I could, in effect, do 4-bit scaling when running at 4Mhz, instead of the 8-bit scaling that we do now/normally?)
Stop! Stop thinking of all these possibilities! You have enough spaghetti on your plate already!
Relax, it’s worse than you think.
Hmmm - 4-bit scaling at 4Mhz might be tough - where at 8Mhz I have 6 clocks/bit to play with, at 4Mhz, I only have two spare clock/bit - or 16 clocks/byte - 8 bit scaling takes up 41 clocks/byte right now. However, I might be able to move some work to the intra-pixel gap (e.g. loading bytes up). Also, I could extend the timing a little bit to buy myself another clock or two, which would make this doable. Though, in reality, I have more real world practical things to tackle (and while people are using 8Mhz ATTiny’s from adafruit/spark fun in wearables/projects, almost no one is using 4Mhz ATTiny’s - at least, not enough to justify the amount of work that it’d take).
It was a joke … I wasn’t expecting you to delve deep into it.
I’m pretty excited about the parallel output on the teensy3/due. It means that I can drive leds at an aggregate 9.6-12.8Mbps, without any memory overhead, but with all of our inline dithering support.
Of course, it means that the CPU is still spending some time pushing LED data, unlike background DMA w/OctoWS2811 and FadeCandy, but the reality for us is that if we wanted to do dithering w/DMA, we’d have to do CPU work on every frame to do the dithering work anyway. (This is why FadeCandy takes up 100% of the CPU and is basically a color correcting, dithering frame buffer for running effects code on a PC/Pi/BeagleBone - which, if that’s what you’re doing, you should be using FadeCandy!).
Of course, where previously pushing 720 leds would take 21ms/frame (capping me at about 24 led updates/second, if I wanted to keep 50% of the CPU available for effects programming), it would now take 1.8ms/frame on the teensy 3 (or 250 led updates/second, if I wanted to keep 50% of the CPU available for effects programming), or 1.35ms/frame on the due, or a whopping 370 led updates/second.
On the dithering front - it becomes helpful to think of update rates in two numbers. There’s “Frames per second” (fps) - which is the number of times per second your code is changing LED data. But then there’s also update rate (hz), which is the number of times per second that LEDS.show() gets called. The higher the update rate, the more effective the dithering code becomes - so even if your LED animations are only running at 30-90fps, driving a 200-400hz refresh rate will give you a lot more dynamic range as you scale the brightness down. There will be more documentation/discussion about that in the near future, though.
Don’t forget p9813 LED support (Total Control Lighting LEDs) is in this release, right?
@Christopher_De_Vries it is! I knew I was forgetting something when @Mark_Kriegsman asked me what was new.
Also, I read a rumor about some new led chipsets you folks are getting - I’d love to jump on adding support sooner rather than later (though reading that is was 15-bit color instead of 24-bit gave me flashbacks to the lpd6803s)
Woowoo! Does this all work on the Teensy 3.0 as-is too?
(What the hell is it with me and unsupported boards this week? 
)
@Robert_Atkins the teensy 3 has been supported since last spring. The teensy 3.1 support is what is new in 2.1.
I got total garbage when running on a teensy 3.1 set to 48Mhz rather than the over clocked 96. Timing issue presumably?
I’ll check into it, though it was running last week at 48,72, and 96 without problems. What led chipset?
Also, the 3.1’s default clock speed should he 72mhz
Ah, I noticed it worked at whatever the default was but not 48. Ws2812.