Hi, I wanted to ask a question about parallel output and speed.
I’m using a Teensy 3.1, and have 36 strips of 8 LEDs each(WS2812B LEDs). (I’m really regretting not making it 32 strips, I wasn’t thinking at the time) I’m thinking of running these with a parallel output, I’d like to make it as quick as possible, so I can use the saved time for more complex calculations. With my current layout, running 12 sets of strips in parallel would be easiest, but I can modify my project to run as 8 or 16 sets of strips in parallel.
Is any layout faster than the others? You have listed on the wiki page the timing for strips of 8, in regard to OctoWS2811, but there are no other comparisons.
Thanks
It’s mostly just simple math. 512 leds would take 15.3ms/frame if they were all in one chain, 1.9ms/frame for the 8-way output, 0.5ms/frame for 8-way using FastLED + OctoWS2811’s DMA support, and if you use 16-way output then it would be ~1ms/frame to write out 512 leds. (There is no 16-way, DMA based output available yet that works with FastLED).
For the non-OctoWS2811 based parallel outputs (8-way or 16-way), you take the length of the longest strip and multiply that by 30µs and that gives you the total time to write out a frame of data. It doesn’t matter if you are using 5 of the 8 lanes of parallel output, or 12 of the 16 way, or 16 of the 16 way.
It might also be worth mentioning the WS2812 chip internally uses PWM for dimming the LEDs, with a cycle time of approx 2 to 2.5 ms. So there’s little point implementing update times to much less than about 6 to 10 ms.
Sure there is - more cpu time for prepping the leds for the next frame. (I don’t stream data to my teensys)
Cheers, that’s exactly what I was after
I guess I think only in terms of OctoWS2811, where you always have nearly 100% CPU time available for rendering, no matter how long your LED strips happen to be.
Actually @PaulStoffregen , when you factor in the overhead that OctoWS2811’s SetPixel has, OctoWS2811 provides no more CPU time for rendering than FastLED w/8 or 16-way parallel code (in fact, w/FastLED’s parallel code I’m about 100µs/frame faster).
That said, you get the most CPU by using FastLED3.1 w/the OctoWS2811 controller which bypasses SetPixel.
The timings that I got:
A comparison of CPU timings, for writing out 512 leds:
512 leds on 8 pins, w/FastLED3.0: 15,360µs or 66fps max
512 leds on 8 pins, w/OctoWS2811 using setPixel: 2000µs or 500fps max
512 leds on 8 pins, w/FastLED3.1 parallel output: 1900µs or 526fps max
512 leds on 8 pins, w/FastLED3.1 feeding OctoWS2811: 500µs or 2000fps max (sadly, WS2811’s get unhappy if you go above 400-500fps)
(That said, for folks who will be rendering on a computer and pushing data to the teensy 3.x - if they do the bit-rotation on the computer first that gets rid of the issue of OctoWS2811’s SetPixel code and really brings OctoWS2811 into the nearly 0-overhead realm)
I should update those timings for 16-way output actually, since that will likely be around 1ms/frame to write 512 leds over 16 lines - but I need to set up a rig to measure that timing first. (I prefer to measure vs. just doing back of the napkin calculations 
@Daniel_Garcia Is there a web page or detailed posting somewhere (with parmalink) that I could mention on the OctoWS2811 page?
Also, which version of FastLED would be best to include with the next Teensyduino installer? Looks like the one I have now is getting a bit too old…
https://github.com/FastLED/FastLED/wiki/Parallel-Output talks about FastLED 3.1’s parallel output.
I’m tempted to say you should grab 3.0.3 https://github.com/FastLED/FastLED/releases for now. There’s a couple of teensy specific things that I need to diagnose/fix with the 3.1 branch (including making sure I improve handling around the two SPI clock/data pin pairs on the 3.1 so that someone can use both of them (even though they’re the same hardware underneath), as well as some other cleanup type stuff). Also I need to do some work to get teensy-lc support in the 3.1 branch as well.
(I really want to get rfduino, stm32, and lpc810 support in the 3.1 branch as well - but once I fix the teensy 3.x specific issues I can probably cut a build that you can include in the meantime - I have some code re-org work to do before I finish that, though).
Are you going to be doing another Teensyduino rev for the teensy-lc support or is this release the one that adds it? (Someone emailed me about you looking for new library versions a little bit ago, but it looks like time may be too tight for me to get 3.1 prepped for your imminent release).
Yes, the first Teensyduino test version with Teensy-LC support will be posted on Monday or Tuesday. There will likely be several test/beta versions posted on the forum during the February beta test period.
I’m planning for an official release on March 10th, when Teensy-LC is officially released.
If the Arduino devs manage to release Arduino 1.0.7 significantly before then, I’ll probably put together a proper release without this new stuff, just to support 1.0.7.
March 10th is my schedule for a release with new features.