For teensy 3.1, how does FastLED2.1 compare to OctoWS2811? Is either one clearly ‘better’, or rather, when would you choose one over the other?
If your plan is to use the Teensy 3.1 as a dumb frame buffer for led data generated on a computer, then OctoWS2811 is your better route, though in that case I’d be inclined to recommend fadecandy.
I have 8-way parallel output running with FastLED (not yet checked in) which is 1 of the 2 main advantages of OctoWS2811. The other is that OctoWS2811 does its data writing in DMA in the background. However, given all the extra things that FastLED does when writing frame data out (color correction, brightness adjustment) there isn’t a whole lot of benefit for the background DMA, if you’re making use of such things.
OctoWS2811 doesn’t have any of FastLED’s math, color, palette, etc… code/options.
(The other thing is that the FastLED parallel code, when I check it in, will have both an 8-way output, like the current WS2811 code, but also a 12-way output on a different set of pins).
If I was doing a large, 10,000 led installation where the led programming was coming off of a computer, i’d use fadecandy (based on the teensy 3.1). For anything where animation data is being computed on the teensy, I’d run FastLED.
(To expand your options even more, if you’re going to be running off of a beaglebone black - check out LEDScape)
My plan is to compute things on the fly. I’ll be looking forward to the checkin!
I could have sworn that the Fadecandy was base on Teensy 3.0 since you can turn those into Fadecandy. Did they update the firmware so that it is now a Teensy 3.1?
No, you’re right - fadecandy is still 3.0
About how many LEDs can I control with a reasonable framerate, from a Teensy 3.1? Is it better to have several outputs, or one output with all of the LEDs? ( My project will have around 750 LEDs total. I can chain them however I want, up to 8 outputs)
A reasonable frame rate depends on your application? Are you doing video? POV? Or just some customer pattern? You will be limited by the speed at which the lights can take the data which maxes out on the WS2811 at 800 kbps and what you do in between to set them. I cannot comment on the speed at which FastLED does it but I am certain they are pushing it as fast as they can. So if you do nothing that is 800,000kbps/750leds/3bytesrgb/8bits ~= 44fps ( edited to correct calc ). More than likely you will want to modify the lights between refreshes… so… long story short, it depends…
Your math is a bit off - there’s 24 bits per rgb pixel, not 3 - so 750 linear leds will take (at 30us per led) 22.5ms to write out, or a cap of closer to 40fps (20-25 if you don’t want to spend all your time pushing led data). This is why solutions like octows2811 exist - for writing eight lines out in parallel. (Fastled also had parallel output running on a private branch right now for both the teensy and the due)
I’d love to try the parallel output branch if testers are needed.
I’ll mostly be doing silly animations. Maybe a strobe that blinks a few times, trippy rainbow patterns that move around a little bit, things like that. I won’t be displaying video.
Crap… I knew I was off… 355fps sounded like a lot… Thanks Daniel
I’ll announce here when the new branch is put up. Right now, the interface is very raw and ugly and way too tied to things like port selection (e.g. on the teensy3/3.1 you can have on controller doing 8 way output, and another controller doing 12 way output, so in theory you could drive 20 lines of leds in the time it normally takes to drive 2 - of course, then there’s the due/digix which can drive 24-30 lines in the time it takes to drive 2) and the specific chipset (I want to make sure that it’s generic to other chipset options because, well, the WS2812/NeoPixel is not the only led chpiset out there, and there’s an 8Mbps chip with a 2.5khz refresh rate coming down the line that if I can drive n-way parallel, well… 