Dear all,
I am running 16 stripes on an teensy 3.1 using parallel output. Unfortunately the WS2811_PORTDC driver uses all the pins required for SPI so I will not be able to connect e.g. an SD card reader there. A quick look at the fastled library showed that in the file clockless_block_arm_k20.h the pin assignment happens.
switch(DLANES) {
case 16: FastPin<12>::setOutput(); -> Port C Bit 7
case 15: FastPin<11>::setOutput(); -> Port C Bit 6
case 14: FastPin<13>::setOutput(); -> Port C Bit 5
case 13: FastPin<10>::setOutput(); -> Port C Bit 4
//case 16: FastPin<30>::setOutput(); -> Port C Bit 11
//case 15: FastPin<29>::setOutput(); -> Port C Bit 10
//case 14: FastPin<27>::setOutput(); -> Port C Bit 9
//case 13: FastPin<28>::setOutput(); -> Port C Bit 8
If I replace the uncommented part with the commented, that would free up the SPI ports. I am fine soldering four wires to the back of the Teensy. However this is not working. For better explanation I put the Port and the Bit next to the code and I sense that the different bits might be the problem. In a former project I shifted bits out and needed to have them in a serial sequence.
Before I dive deeper in the library I just want to check if someone might know a hint how to approach this? In best case without changing the library. What I am looking for is a SPI safe WS2811_PORTDC. Maybe a WS2811_SPI_PORTDC 
Thanks for any help
Cheers
Mike
What you want to do is a bit ugly - it’s not just enough to change the pins that are set output - because the blockless code relies on setting/clearing an entire port at once. As it is, the 16-way output has some timing issues, and extending it to 20-way (even if not using 4 of the middle bits as you’ve set up above, the work would still need to be done as far as the bit rotation/prep) isn’t really doable at the moment. It’s why those pins are currently commented out entirely in the PORTDC parallel output
However - if the SD card that you’re using also uses a select line, then what you could do is set up two outputs, one 12-way on PORTC and one 8-way on PORTD. You just wouldn’t use lanes 0/1/2/3 on PORTD or lanes 4/5/6/7 on PORTC for LED data.
Do the FastLED addLeds calls first to set up the two outputs - then setup the SD card code and SPI code. That should configure the SPI output to use pins 2/7/8/14 or 10/11/12/13 (whichever you choose) which should cause the pin-twiddling done by the parallel output to effectively be ignored (because those pins would be taken over by the SPI subsystem, so any GPIO setting done by the parallel output would effectively be ignored).
Hi Daniel, thank you very much for your fast reply. I fully understand what you wrote. Seems to be a good solution and I will try it out.
I will do:
#define NUM_STRIPS_PORTD 8
#define NUM_STRIPS_PORTC 12
#define NUM_LEDS 10
FastLED.addLeds<WS2811_PORTD,NUM_STRIPS_PORTD>(leds, NUM_LEDS);
FastLED.addLeds<WS2811_PORTC,NUM_STRIPS_PORTC>(leds, NUM_LEDS);
Now I have an array (leds) with 20*10 = 200 entries assuming that leds[0…9] is on PORTD pin 2, leds[10…19] is on PORTD pin 14 and so on - Correct?
leds[120…159] would be on PORTC pin 10,13,11,12 which I want to use for SPI.
Then I will setup the SPI Port:
const int chipSelect = 10;
card.init(SPI_HALF_SPEED, chipSelect);
So if I understand you correctly, I have to ensure that I skip the leds[120…159] when writing to the array, basically I leave them alone.
I can do this with a wrapper but I might come into a problem when using e.g. fadeToBlackBy(leds, (NUM_STRIPS_PORTD + NUM_STRIPS_PORTC)* NUM_LEDS, 20);
What I want to say is that I fear that functions which modify the complete array also modify bits in the area where I connected the SPI. Hopefully I am wrong 
Your second addLeds will need to offset (leds + NUM_STRIPS_PORTD * NUM_LEDS) - otherwise, they’ll both be using the same set of led data. And it’s more that it doesn’t matter what you write on leds[120…159] - it’ll effectively (in theory) be ignored, so it’s just wasted cpu time. Where you might have to do some extra work is when using a function that builds a gradient (for example) across a set of leds, you’ll have to manually skip the excluded set of leds.
Thanks again, before I try this I am thinking of using a Arduino with an SD Card reader attached as a “player”. Since I do have the RX1 and TX1 pins available on the Teensy I will first try to see if data transfer from Arduino to Teensy is sufficient from a speed perspective.