Yes, very easily. In this scenario, RESET works as the active-low slave-select. The programming algorithm is very well documented in every AVR datasheet (look under Memory programming, Serial Downloading).
Note however that some AVR chips have their ICSP SPIs on different pins than their regular SPIs (for example, atmega128 shares the ICSP SPI with one of its USARTs).
SD Card access is a fair bit more complicated because of the need to consider the FAT file system etc. So if I were you I would concentrate on getting the LED driver working first; at least then you know your SPI bus is working.
To answer a few of your questions:
- The voltage at the output of any LED output pin will be the voltage that is required to achieve the programmed constant current. It should not be 0V unless the outputs are set for maximum current. And it should not be the supply voltage unless the LED is supposed to be off.
- The fact that the LED driver has an internal 30Mhz clock should not be of concern to you. Your device is the master, it controls the clock, and the slave should clock in the data based on the clock your master provides to it. The 30Mhz info is just useful in terms of appreciating the maximum speed you can push data through the device.
A few things to check:
You mention pulsing LE high, but you don't mention holding OE low to enable the LED outputs?
You need to make sure you've configured the master clock and data pins properly. I am not familiar with Arduino stuff so I can't help you with the specifics here, but there are various modes of SPI operation and you'll need to set up your device to match. You need to make sure you have the correct mode set up to output the data on the rising edge of the clock, with data sampled in the middle (for the LED driver - maybe it's different for the SD!).
Where is the chip-select pin on this device? Surely it has one? Couldn't see it on the supplied diagram.
If there is no chip-select, how will you switch between data provided to the SD card and data provided to the LED driver? You'll need two SPI peripherals? Unless perhaps the LED driver is happy to just sit there receiving data, even if it isn't the intended recipient, and it's up to you to control the LE and OE pins when it is the intended recipient. It's worth just looking into this to clarify everything.
I'm not sure what is supposed to come out of the LED driver SDO pin? Are you using it?
How is SDI supposed to relate to LED outputs? I notice in the timing diagram SDI is high for bits 0, 2, 5, 10, 11, 12, and 15. But outputs 0, 3 and 15 are shown to respond with an 'ON' condition. Maybe this is explained elsewhere in the datasheet, because it doesn't seem to make any obvious sense from the timing diagram...
Good luck!
Best Answer
A "slave" SPI device that controls another slave becomes a master by definition.
If your front panel software is capable of implementing either slave or master roles at different times there is nothing to stop it doing so, provided that the hardware can accomodate the necessary signal flow and the "normal" SPI master does not interfere or "become confused" by the action. ie
Your masters need to cooperate physically: If two masters try to work at once, or if one master asserts a signal line (eg clock) that affects the ability of the other master to control the same line when desired then "there will be problems".
Your masters need to cooperate logically: If one master "thinks" it is controlling the bus but the other is also altering the clock or data lines "there will be problems".
From the UART and SPI IC's point of view the physical identity of the master device is unimportant as long as the signal levels and signal flow occurs correctly.