You didn’t think we were going to stop with FastLED3.0 did you? I’ve just opened the gates on the FastLED3.1 branch for the next major version of the library and this branch is coming out kicking with a frequently requested feature - Parallel output on the teensy 3/3.1, arduino due, and the digistump digix.
Not only does the FastLED3.1 branch have multiple options for 8-way output (2 on the teensy 3/3.1, 3 on the digix/due), but it also includes a controller for working with OctoWS2811 that is approximately four times faster than using OctoWS2811’s setpixel method to populate led data (while getting the brightness/dithering/color correction you’re used to w/FastLED at the same time), making OctoWS2811 more useful for applications where you are doing all of your animation programming on the teensy rather than piping it in from another machine via usb.
In addition, on the teensy 3/3.1, there is the option for 12-way output on PORTC (if you want to solder pins on the back) or 16-way parallel output using the first 8 pins of both port C & D (no soldering pins on the back!).
Right now there’s two examples (examples/Multiple/ParallelOutputDemo and examples/Multiple/OctoWS2811Demo) and the beginnings of a documentation page here - https://github.com/FastLED/FastLED/wiki/Parallel-Output (right now it’s just a list of benefits and numbers, I will extend that to more thoughts about arranging led data, using the parallel output, how to use it with less than 8 pins if you want, etc…) https://github.com/FastLED/FastLED/tree/FastLED3.1
“recover_approximate_HSV_from_RGB” is in the queue and there’s some code already written for it, but not posted yet. I’ll make sure to announce it when it’s up. The other big thing in the queue is improved interrupt friendliness, which will also be announced here when it’s available.
So say, that with my current matrix setup (16x16), I could rewire it into 2 strips and take advantage of accelerated FPS? Thus leaving plenty of time for floating point animations, wireless communications, etc. Are my assumptions correct?
Man, I just keep typo-ing all over the place. I mean the teensy 3/3.1 has 16-way parallel output (as in write out 16 lines of led data in the time it takes to write out 1.1 lines of data normally - at this point, it is faster to use 16-way parallel output than to run OctoWS2811 for 8 lines and FastLED parallel output for another 8 lines).
Octows2811 uses the DMA engine to push led data out cutting back on cpu overhead (and if you are pushing led data from a computer over usb - there’s little cpu involvement in the teensy). It’s why i did the controller for octows2811 as well (eg for 8 strands of 64 leds you will use ~2ms of cpu time pushing out led data with the parallel code and ~.5ms using the fastled octows2811 controller)
@PaulStoffregen I don’t have the hardware lined up to try it yet - but I did do a quick port of that example to use the OctoWS2811 controller in FastLED - it should go from using about 7.5ms/frame calling setPixel to about 1.9ms/frame of CPU overhead. What kind of real effect this has on frame rate would depend on how much CPU overhead the FFT code is using - if you want to try it out I pushed it into the repo here - https://github.com/FastLED/FastLED/blob/FastLED3.1/examples/Ports/PJRCSpectrumAnalyzer/PJRCSpectrumAnalyzer.ino (I really need to get some regular audio stuff wired up at home here for testing).
I suspect the FFT is going to be resource intensive enough that there’s never a case where you wouldn’t want to use DMA’d led output.
With Teensy 3.1 running at 96 MHz, the 1024 point FFT takes approx 2 ms to compute. A hanning window and 50% overlapping is used, so the data output is every 11.6 ms (every 512 audio samples at 44.1 kHz).
I believe you saw it running at Maker Faire, right? 86 Hz frame rate makes for a really fast response to the music.
Already, some people are apparently working on more advanced musical analysis, like note onset detection. No word yet how much CPU time that’s going to chew up, but when it’s working together with fast LED libraries, I believe a lot of people are going to create some absolutely awesome real-time music visualization projects!
Yes! I just put in an order for a couple audio shields and a few more teensy 3.1’s to play with the audio stuff. So - basically, assuming that I did my timings right, at 86Hz, the teensy 3.1 would now have an extra 480ms/s of CPU time to play with - that’s a lot of cycles for more, well… more
