Is parallel APA102 output with a shared clock possible?
I’m going to have 10 discrete strips, and I’m wondering if I can get away with just 11 pins for it. each strip has a unique data line but a shared global clock line.
Making one huge daisy chained strip of it is not going to work for this build and I’m hoping I don’t need 20 pins of I/O to control this beast.
There’s no parallel output driver for the apa102 (or any spi based chipset) yet. You might be able to do the 10 data lines, one clock line thing - it’ll use software, not hardware spi - but that’s in theory, I don’t know if anyone has done it (but it’d be similar to the way 4-way hardware spi on the teensy 3.x works)
With APA102 you don’t need to bother with the multiplexer for the clock line - because of a quirk of how the APA102 works - APA102 frames start with a series of 1’bits - so you can strobe the clock line all you want if the data line is left low then the APA102’s aren’t going to do anything : )
The you have a different set of problems. If you have, say 10 data lines and one clock line then you can do 10 addLeds calls and just use FastLED.show() - if you use a multiplexer you have to manage the led controllers yourself and do the multiplexer juggling between calling show on each controller. So - using a multiplexer doesn’t actually make things easier to someone
@Daniel_Garcia Oh right, i do apologize. My multiplexing example was not designed to be used with FastLED i forgot that .show() will just transmit to all the LEDs at once…sorry sorry
“APA102 frames start with a series of 1’bits - so you can strobe the clock line all you want if the data line is left low then the APA102’s aren’t going to do anything”
This sounds like I can have 10 data lines and 1 clock if I update them in serially (strip 1, then strip 2, then strip 3, etc). The number per strip should be low enough that data speed shouldn’t be a big issue.
If so, would it work to call FastLED.addLeds() 10 times with different data pins and the same clock pin?
In my case I plan on using a teensy 3.2 & 74AHCT125 level shifter to drive three APA102 strings. Each string needs to be updated at a different rate, one string at 100 Hz, one at 2 Hz, and one at once every 10 seconds. The first string will have 120 LEDs. I’ll have 480 LEDs total across the three strings, but I need to keep the first string as short as possible to meet the 100Hz target.
I am thinking of just using one set of hardware SPI lines on the Teensy 3.2, and then use separate teensy pins to control the output enable on the level shifter. I connect the single clock line from the teensy to three of the level-shifter’s inputs simultaneously, then connect the output of the level shifter to the clock input of the appropriate string.
All three strings share the SPI data output passing through the level shifter. I control which clock is active via the output enable on the level shifter.
I’ll use three separate FastLED.addLeds() calls with the exact same pins. I have to select/deselect the appropriate output enable lines before calling .show().
Is this scheme any better/worse than the “Getting four hardware SPI lines for the APA102 out of the Teensy 3.0/3.1” example?
I’ve just put together a similar setup. 4 sets of APA102s on a teensy setup exactly as in the example with a 74HCT125 level shifter and it’ll drive the LEDs at 24mhz! I’ll turn them down before they go to the customer though.
You don’t need to use the teensy for the output enable on they level shifter, just grounding all of the ones that you’re using seems to work really well. (I copied the circuit from the PJRC octo adapter with the 100ohm resistors on the output.)
I think that there may be some confusion between the 74HCT175 level shifter and the CD74HC4067…
The scheme you describe is worse. You can’t call addLeds 3 times with the same set of pins and get it to work like you’re expecting. Because you need to change some state (enable on the shifter) between each strip you wouldn’t be able to use FastLED.show()
For four strips or fewer, use the four hardware spi trick. Otherwise, use a single shared clock line and a unique data line for each strip.
You’re right, I’ll have to re-think this. I might not be able to use FastLED as-is. I don’t want to update all 480 LEDs at 100 times a second, only 120 of them. I’ll need a separate FastLED object for each string, not one instance with multiple strings added.
Take a look at the last section here - https://github.com/FastLED/FastLED/wiki/Multiple-Controller-Examples - on using led controller objects directly. (Note this last bit uses code that I often change the interfaces to, so some library updates may require changes to your code if you do this)