I've been monitoring this question, and since no one has answered yet, I'm going to take a stab at it. I apologize in advance if my reasoning ends up being flawed, but I'll do my best.
I think the possibility of making your project work depends upon how many RGB LEDs you plan on using. I've been going over the Allegro datasheet, and it looks like you need to pair one IC with one each of red, green, and blue LEDs (i.e. one RGB pixel). All of the data gets transmitted down the chain of 6280s.
If you want to only have one RGB pixel, or more specifically, N pixels displaying the same temporal information, then I think you might be able to get away with using SPI. I think your linked list idea is the right way to go, but obviously the key is to latch LI at the right time (every 31 bits), and it won't be on 8 bit boundaries. The only SPI libraries I've ever used on micros take a byte, clock out the data and read the response byte. In your case, you'll need to figure out how to make an SPI function that can trigger LI during a byte transfer.
Since SPI requires transferring one byte at a time, you'll be forced to send 32 bits when you only want 31. So the 32nd bit will actually be the first bit of your second set of RGB data. You'll set LI before clocking out the 32nd bit. For the next round of data, you'll trigger LI before clocking out the 31st bit. You might be able to do this without writing your own SPI library, but I'm not sure.
If you want to support scrolling data, then things look like they will be a bit trickier. I'm having a hard time formulating the explanation, but timing LI will be interesting. LI determines how quickly your display is going to scroll, since it dictates when one 6280 outputs the data to the next.
For the first set of RGB data, you will trigger LI as soon as you've clocked out 31 bits. You've also clocked out 1 bit for the next set of data. You will then clock out another 3 bytes of data, plus 6 more before triggering LI. But if your scroll time is slow, you can't send out the byte that contains the last 6 bits until you are ready to trigger LI, because you don't want to overflow the shift register buffer! But once you are ready to trigger LI, you'll send out this byte. Now 2 bits for the next set of data is already in the serial buffer. Send out another 3 bytes (26 bits total), and wait until you need to trigger LI. When it is time, send out the next byte (that has the remaining 5 bits). Repeat this over and over again.
I hope this makes sense. Like I said, I don't have experience with this chip, but what I've written here is at least the first step I'd take to trying to solve this problem using SPI.
Good luck, and keep us posted!
Add these steps to your algorithm:
0. Prepare first bit of data
...
3. Use external interrupt on rising edge to output prepared bit and put next bit into your bit holder variable. Count outputted bits.
* Step 3 will be automatically repeated 16 times (external device will trigger it).
4. When bit counter reaches 16, disable ext interrupt and set ready line back.
hint: on atmega168/328 any pin may be used as ext interrupt source on incoming edge transition with quite simple technique.
I hope your external device is not driving clock pulses too fast. Arduino is not very good at reaction speeds faster than 1MHz. I'd say you should expect this approach to work reliably up to 100 kHz clock. On higher speeds either hardware SPI should be used to clock out your data or tight assembly coding. In any case several MHz is max you can do with bare AVR here.
Best Answer
If both of your microcontrollers support setting the pins you are using as the serial clock signal to a high impedance state/tristate (if you are using a normal GPIO pin most micros would support this) then you can achieve what you have described without any additional components or insulating the clock pins from each other. What you will be doing is just directly wiring the two micro clock pins and the shift register's clock input together, then setting each micro's serial clock pin to high impedance whenever it is not actively generating a clock signal, leaving the other micro free to drive the clock line. There is an older question covers what it means to set a pin to high impedance/tristate a pin.
As you've picked up on with asking about 'insulating' the clock lines from each other, you want to tristate the pins so that there is not 'contention' when one micro is trying to drive the clock signal line in one direction (eg. high) and the other micro is trying to drive it in another direction (eg. low) - which would cause the two micros to source/sink a lot of current, get things hot, potentially let the magic smoke escape and generally cause trouble. As a result you should be careful that there is never any time when both micros are actively driving (ie. not high impedance) the clock line at the same time, particularly during the hand-over time when you are changing which micro is driving the clock line.
You will probably also want to add a pull up resistor on the shared clock line to avoid the clock line being free to oscillate around due to any noise it picks up at times when neither micro is actively driving the line (ie. both have their clocks set to high impedance - this will probably happen, at least for a short time, if you pay attention to the previous sentence...). You may be able to get away without the pull up resistor by using the internal pull ups on the micros, or just get lucky and not pick up any 'spurious' clock signals, but it would be safer to add the external pull up.