@Jurgen_Skrotzky : Dan and I have discussed the Pi before, but at this point we’re trying to stay focused on ‘true’ microcontrollers – boards with no operating system, just raw code. Candidly, even if someone just handed us a port to the Pi, we’d be slow to merge it – every time we add a new board, or new microcontroller, or new compiler version (Hi, Arduino 1.6), we have to go back and re-rest every release with every kind of LED strip, and it’s a lot of work. The Pi looks interesting, and I bet that someday we’ll get there, but not terribly soon.
@Jurgen_Skrotzky check out OLA, which can run on the rPi. https://www.openlighting.org/ola/tutorials/ola-led-pixels/
OLA is essentially a programmable patchbay framework that runs on higher level OSs (Linux, OSX, Windows) for professional lighting protocols…but it also runs on the rPi and the BBB…and supports SPI pixels. It would be interesting to somehow combine FastLED and OLA…perhaps FastLED becomes a plugin of OLA?..or OLA is a framework used by FastLED (like QLC+ does it) …not sure…but both of them are awesome and fastmoving projects with awesome developers and awesome communities…each one targets different platforms and has their own unique tricks up their sleeves.
-frenchy (Steve French) http://www.voltvision.com
hey @Steve_French thx for the link. I know OLA, but did not know that there was a RaspPi SPI plugin >> woohoo.
I will try that and perhaps do some porting of FastLED library. I like the API the qute methods
The library can be sort of divided at CRGB, conceptually. You can directly use CRGB “and up” (ie HSV colors, palettes, math, noise, etc) even in environments where FastLED doesn’t directly drive the hardware.
I’ve used it on Colorduino, with ‘analog’ RGB LEDs, and on Rainbowduino 8x8 grids and the 4x4x4 cube http://www.seeedstudio.com/wiki/Rainbow_Cube – none of those are “supported hardware” in terms of the LEDs. Not too hard to use it in desktop C/C++ code, too.
Similarly, you can use FastLED as a wicked fast device driver, and write your own code to load up the RGB arrays.
Don’t parallel APA 102 output - you’re killing your update rates. If you have all the APA 102’s off of a single port, I can drive the data out at 24Mbps on the teensy 3. Because you have them split up over multiple ports like that, you limit the data rate to what I can get with software bitbanging, which is something like 4-6Mbps - so you’ve just made your led writing 4-6 times slower!
Wow, so this thread is completely blowing my mind right now - so much I didn’t know, so forgive me if my questions from here on out sound dumb, this is unexplored territory for me:
So last night I had a test going where I was trying to test a 1:1 comparison of octows2811 pushing 8 strips of 500 leds in parallel vs fastLED pushing 8 strips of 500 apa102’s not in parallel.
My thoughts at the time was that fastLED would be faster still since apa102’s had such a higher refresh / update speed than the ws28xx’s.
I noticed, that in my test the fastLED approach was indeed slightly slower, if only barely when trying to push 500 per pin. I didn’t really know why though.
What I’m understanding now from what you said is that since I was using more than one output on the teensy with fastLED that it could NOT leverage the SPI hardware speed advantage and was there for writing to each of the 8 strips at closer 3-4 mbps (via software/bit banging) which drops it down below the speed of the octo libraries optimized parallel speeds?
Looking at the Teensy 3.1’s pin out diagram:
It seems like there are more than a few green ports labeled SPI in the key. Is it possible to write to more than 1 strip at SPI speeds?
If using just one strip, it does have to be connected to one of those sets of ports only right?
Yes, but not in parallel - so there’s no benefit to splitting your strip over both ports unless it makes wiring easier. However, someone has reported a problem with it that I haven’t had a chance to dig into fixing yet.
Another question if you could - does the speed of bit banging SPI like data depend on the processors speed? Or are there other limitations or factors that slow it down?
