Hi guys, hope someone can help me with a stupid question...

Hi guys, hope someone can help me with a stupid question…
In the past I build one LED panel by using 2x Teensy 3.0 boards to drive 30x30 LED panel. (https://www.youtube.com/watch?v=dKSvSQYUWRw&list=PLFsMkHa76LAIa-mNUPX0b6K-aYrg49W0_&index=5)
For this project I used a modified version of fadecandy (https://github.com/scanlime/fadecandy)

… for my next project I want to use FastLED, because it is really nice and I like the library - just sexy and easy.

Here my question:
can someone show me, how to push data via usb to Teensy 3.1 (like OctoWS2811 did with DMA) and feed this “stream” into FastLED “led array” to show.

Is there already some code out there for streaming data via USB to FastLED?

Honestly, if you are building up data on a computer and pushing it to the leds, fadecandy is a far better solution to use. FastLED really optimized for all the work being done on the MCU, reading bulk data over USB is tricky when fastled is regularly disabling interrupts to push data out to the leds.

That said, if you want to do this, there’s a bunch of code out there for things like ambilight/boblight which are doing exactly this. At some point I will likely implement support for how fadecandy is sending data down the line, but that is unlikely to happen any time soon.

@Daniel_Garcia thx for the fast reply. Ok I see. I hoped that there is one solution for FastLED. Fadecandy is awesome, but has the limitation of 64 LEDs per strip and only 8 ports parallel => 512 LEDs. But I need 1024 for my next setup of only one Teensy 3.1 of course.
I think the limitaton of 8 channels of Octo library is because of the RAM of teensy 2.x boards. But Teensy 3.1 has 4x more RAM - or do we need more DMA channels as well to do 16 instead of 8 ports parallel?

Perhaps I can take a look on FastLED 3.1 and modify my fadecandy fork

Octo only works on teensy 3.0/3.1 - and the 8 channel limit doesn’t have to do with ram, it has to do with the mapping of pins to I/O ports.

The fade candy limitation is because of what’s done with dithering/correction and limited cpu time.

Optimizing for transferring data over USB is going to be your biggest issue to solve for, followed closely by managing the data transfer so that it happens between the frames.

You can use fastled’s octows2811 controller, which will be faster than using octows2811 directly, and get you the ability to push out led data via DMA which will make managing reading usb data a bit easier.

(So, short version - it can be done, but your use case (using the MCU as a frame buffer, pushing data from a computer) isn’t what we’ve focused on optimizing FastLED for. Also, another option, check out the ledscape for the beaglebone black)

OctoWS2811 has been used to stream data over USB to 4320 LEDs (6 zig-zag arranged strips of 90 per pin) at 30 Hz. It can easily handle only 1024 LEDs.

thx @PaulStoffregen for the hint. The best was to use the new port of FastLED 3.1 (with Octo controller) to access 16 channels and with the ability of streaming data over USB.

The Octows2811 controller only uses 8 channels, not 16. There is a 16 channel parallel output controller but that doesn’t use DMA and so you will have the problems I mentioned above getting data over usb.

Oh man, ok I think I got it now O:-)
So I have to figure out which solution will fit most for my next project.
I want to drive 1024 or more LEDs with smooth animation by temp dithering, but also the ability to change animations by Raspberry Pi and Internet.
Choosing FastLED and build a kind of effect-pool, so I can push animations to teensy which are played later in the loop…
Or I would stay on the fadecandy configuration and hook up 2+ boards…

Thank you guys for your details, now are some points much clearer for me. Thanks

Yeah, for smooth animation, FastLED for the high level drawing and OctoWS2811 for the low-level transmit to the LEDs is a great combination.

But really, don’t overthink all this too much. Teensy 3.1 is very fast and both these libraries are very efficient. If you were doing 5000 or 6000 LEDs, I’d agree with really scrutinizing every detail. Only 1024 LEDs really isn’t very much. Less you write really, really inefficient code, 1024 LEDs is pretty easy. That’s a lot for ordinary 8 bit AVR-based Arduino, but it’s not that much for 32 bit ARM-based Teensy 3.1.