Wow nice! What is that, something on the order of 3200 pixels? I think a Teensy 3.1 should still handle that many APA102 LEDs. Wonder if @PaulStoffregen could offer any thoughts?
Can I split the output across multiple pins anyway, even if they aren’t updated in parallel? (The physical layout of the piece is a “star” topology, and it would be useful not to have to have another wire for the signal return.)
No, that many leds you would want to be on the hardware spi pins, and unlike some arm platforms the k20 doesn’t let you redirect peripherals to arbitrary pins (there’s one arm platform that no matter what pair of pins you use, I can always use hardware spi on them.
The teensy 3.1 does have two sets of hardware spi pins, however. And I do want to work on parallel spi output at some point, just not there yet.
Also, do some code tests. What kind of frame rate do you want, and how do you want to compete values for each frame. Tree of life has 480 leds and currently runs at ~70 fps, about 12ms/frame is spent doing 3 3d noise calculations and a bunch of blending per pixel (this performance is made rougher because I’m not computing noise into a regular grid at all. (Though I have some thoughts on how to further optimize that work).
If you can’t get the frame rates you want (just in terms of computing pixel data, forget writing data you wasn’t) off of the teensy 3.1 then using fade candy w/ws2812s might be a better route.
Just thinking out loud here… What about working with a few Teensie’s driving each a portion of the whole thing and working out some form of synchronisation between them ?
@Daniel_Garcia tree of life? Send me a link to a video please? Sounds a lot like my seed of life, 7 rings of 60 LEDs each for a grand total of accidentally 420 LEDs,lol