Did you know that the Teensy 3.x actually has two sets of hardware SPI pins? Everyone knows about 11/13 but there is also a pair on 7/14. Now you know, as does FastLED3.1[1].
Here’s the annoying thing with the k20 hardware, however. The k20 has two hardware SPI engines internally. Which would mean, in theory, you could have two sets of hardware SPI being written out at the same time (that would be great, no?). Sadly, pins 11/13 and pins 7/14 are alternate configurations for the same hardware SPI engine.
However, we can still use both sets of pins. Let’s say you had a controller in the middle of two strips of APA102s. Now, you can hook
one strip up to pins 7/14 and the other strip up to 11/13 and get stupidly high refresh rates on both strips (rather than either doing a complex wiring thing to make them appear as one strip or having one strip at full hardware SPI speed and the other strip at a slower bitbang’d spi speed).
[1] FastLED3.1 has supported the second pair of pins for a while now, however the way it was implemented it was an either/or. You could use one set of pins or the other, but not both.
So out of curiosity, what are the refresh rates on the hardware pins like versus the other pins? would it be a bad idea to mix and match them? How many LEDs could the hardware pins control at a reasonable refresh rate? (ie 30-60fps?)
On the teensy 3/3.1 you can get a data rate of 24Mhz out of the hardware pins. It’s been a while since I clocked the bitbanging, but that was closer to 6Mbps on the teensy 3.x.
As for the “how many leds” - that depends on a lot of factors - what led chipset are you using (not all of them can clock as high as 24Mhz) - whether or not the led chipset/strip you are using degrades the longer it is (e.g. WS2801’s were notorious for requiring a lower clock rate, the longer your string of data), etc…
woops yeah I should have clarified, I was thinking about apa102 strips since those seem to be the way forward
Those can be driven at 24Mhz (at least sometimes, I’ve had to scale the rate back with some strips, but I have a board with 784 apa102’s on it that has no trouble). You can drive around 6000 leds at 60fps using 50% of the CPU time. (APA102 has a 32-bit data package, 24Mbps data rate means 750,000 led updates/second or 12,500 leds if you spend 100% of your time writing led data).
The reality is it will likely be a bit smaller, mostly because I haven’t done a full round of optimization for APA102 output.
Yet.
God damn, that’s all I’ve got to say haha. I really appreciate you answering this, helps a lot with a project I’m planning!
Sadly, the 2nd SPI’s port’s SCK signal isn’t assigned to any of the pins on the TQFP64 chip. You can only access DOUT and DIN (aka MOSI and MISO in master mode).
Because of this, I never mention the 2nd SPI port when promoting or documenting Teensy 3.1.
Heh, sounds like they’re taking a page from Arduino’s handbook (not bothering to expose the clock pin). That’s fine though, being able to use two sets of pins for hardware SPI output is quite useful - even if it’s the same hardware under the hood. At least until I start doing parallel SPI output 
(Also, @PaulStoffregen , thank you for being sane and exposing the XCK pin on the teensy2/teensy++2
So can we control other SPI stuff off the usual pins and the APA off the second set of pins.
I’m trying to work out how to control APA102 without chip select (as they don’t have it)
You’d have the same CLK pin going to all SPI devices?
No, there’s spi on pins 11 and 13 (data, clock) and 7 and 14 (also data and clock). You can’t use them simultaneously, aka while writing data out on pins 7/14 you can’t be receiving data on pins 11/13 (actually 12/13).
Also it is unclear how good other libraries/devices are about releasing spi resources when they aren’t actively using then.
Ok cool — that’s probably ok for me.
I want to run some MCP23S17 16-bit expanders and a TI DAC8562 off one set of pins (11,12,13) and the APAs of another (7 and 14)
I don’t plan on doing anything simultaneously.
Any plans for a Teensy 3.2 with the newer Freescale Cortex chip? The rep from Arrow wanted to send you some for a proto run when I mentioned the Teensy 3.1 in a Kinetis seminar.
sorry to necrobump, but was doing some project planning and have a noobish question.
If I have apa102 LEDs, and were running long distances of them, does this mean I could run 2 separate strips (lets say, 400 leds each), one using 11/13 as clock and data, and the other on 7/14 as clock and data? Does it matter which one is clock and which one is data?
Yes, of course it matters. If you reverse the clock/data lines you won’t use hardware spi, you’ll be using bit banged spi.
Oh, I think I mean to ask, if as long as I tell FastLED which I intend to use for which, does it matter if 11 is clock and 13 is data, or vice versa? or is each pin dedicated to one of those functions with fastled?
It has nothing to do with FastLED. The underlying hardware only has hardware SPI when pin 11 is data and pin 13 is clock (ditto pin 7 as data and pin 14 as clock).
Again, if you specify pin 11 as clock and pin 13 as data then instead of using the 24Mbps hardware SPI, FastLED will switch back to using bit-bang’d output which is about 1/4-1/6th the speed.
Ah ha, thank you for clarifying. I didn’t realize that SPI implies the use of both clock and data by definition. I get it now, sorry for the stupid question