I’m using APA102s on the SPI pins of an Arduino Due. This is giving nice fast updates. The problem is when I want to try to read images off the SD card - apparently, since they both use the same SPI pins on the Due, either one works or the other, but not both. Is there a solution? Moving the LEDs to non-SPI pins kills the performance and is not an option.
The one thing I have tried that “sort-of” works is in setup() I open the image from the SD card and read it into RAM, then I initialize FastLED with FastLED.addLeds() after. This is flaky though as sometimes the SD card read fails anyway, and the fix is to disconnect power to both the LEDs and the Arduino, then just power up the Arduino, then connect the LED power after a few seconds.
I’m hoping for a better solution. If the SD card becomes slower that’s fine because I’m reading the image data into RAM anyway.
I think the Teensy 3.1 has two sets of data/clock SPI pins. I’m not sure if that would be a proper solution, but might be something to check out if you’re not locked to using the Duo.
Unfortunately not at the moment - an annoying thing about atmel chips is a peripheral is on at most two sets of pins - in the case of the due the second set of pins are not available on the board. (As opposed to, say, the rfduino, where I can put spi data and clock on any pair of pins I want)
I might be able to throw something together that uses the usart in spi mode, but I won’t know for sure until tomorrow or Sunday.
Alternatively, if you’re handy with electronics you can rig something that will switch the clock/data lines from the spi card to the LEDs and back again.
Is it possible to programmatically select either the SD card or the LEDs to use the SPI bus? I read somewhere that it’s possible to have multiple devices on the same bus, but you may have to set the Slave Select pin for the device HIGH or LOW to disable/enable it. I think the SS pin for the SD card is 4, not sure if there is one for the LED output … I’m beyond my level of expertise here.
My guess on the SD not always working, would probably be the supply in not coming up quickly enough to correctly reset the hardware for your setup routine to be able to access it.
If you do build hardware to keep the MOSI and SCK signals quiet while the Arduino it talking to the SD card, beware trying to reuse the SD card’s CS signal. There are times when SD communication happens with its SD signal high (not asserted). At startup, many clock pulses are needed with CS high. There’s also a little-known part of the SD spec that says up to 8 extra clocks with CS high may be needed for a card to execute a command. The old Arduino SD library does not do this, but Bill’s newer SdFat does, and so does a higher-performance SD rewrite I’ve been making for Teensy 3.x. If you build hardware that tries to reuse the SD card’s CS signal, it’ll likely fail when/if newer and better SD libraries are used.
My workaround was to read the data off the SD card first and store ot in RAM, then initialize the LEDs. Once the LEDs are initialized the SD card becomes inaccessible.
