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!
I'm afraid the answer is going to be a microcontroller or other programmable device. My reasoning is as follows:
The sensor is a slave device, not a master.
Slave devices need an external clock to clock the data out.
But only 24 clock pulses.
Simple logic devices aren't generally set up to make their own clock.
Therefore, the simplest solution will be a microcontroller with two SPI peripherals and sufficient memory to buffer through your maximum interrupt latency. Choose a micro with an internal clock and appropriate supply voltage for your circuit. Perhaps MSP430F5151.
Now, if your sensor was a SPI master, then you could be clever with multiplexed pins and just use a Microchip serial SRAM, setting up the write with the microcontroller, then letting the sensor continue writing into the RAM. See e.g., the Logic Shrimp logic analyzer for creative use of serial RAM parts.
Power consumption calculation with microcontroller.
By popular request, let's estimate the current draw for the MSP430 that I linked above.
MSP430 achieves low power with a switchable high-speed clock DCO, which will only need to run for the duration of the data transfer.
Let's choose 8 MHz SPI clock. 24-bit transfer will therefore take 24/(8 MHz) or 3 microseconds. From the datasheet, the DCO takes 1.6mA maximum and 6.5 microseconds maximum to start at 8 MHz. So the entire transfer takes about 10 microseconds. Each transfer takes 1.6 mA * 10 microseconds, or 16 nC. 8000 transfers / sec is 128 microamp average current. But double this, because we have to read out as well. (This is bit pessimistic, as the clock doesn't need to run during an SPI slave transaction.) So say an average current of 256 microamps.
Best Answer
I did the same thing on a AT32UC3C0512 (yet, I was the master which probably made it a bit easier).
The idea is probably the following (if you're using the ASF framework, it should work in slave mode as well):
Here's some code as a starting point, hope it helps a little:
I'm not quite sure what has to be done to reset the flag which is set once a byte was received. I would assume simply reading the rx register should do the trick.
It should also be possible to port this code to using interrupts (call the ISR whenever a byte was received/RX register is full).
From the AT32UC3C0512 datasheet:
The SPI waits for NSS to go active before receiving the serial clock from an external master. When NSS falls, the clock is validated on the serializer, which processes the number of bits defined by the Bits Per Transfer field of the Chip Select Register 0 (CSR0.BITS). These bits are processed following a phase and a polarity defined respectively by the CSR0.NCPHA and CSR0.CPOL bits. Note that the BITS, CPOL, and NCPHA bits of the other Chip Select Registers have no effect when the SPI is configured in Slave Mode. The bits are shifted out on the MISO line and sampled on the MOSI line. When all the bits are processed, the received data is transferred in the Receive Data Register and the SR.RDRF bit rises. If the RDR register has not been read before new data is received, the SR.OVRES bit is set. Data is loaded in RDR even if this flag is set. The user has to read the SR register to clear the SR.OVRES bit.
As far as I understand, a flag will be set after 8 to 10 databits. For a first try, you will need to read the data and see if the flag gets raised a second time, even if CS doesn't get asserted a second time.
An alternative solution
You can also use an interrupt on the SCK line (depending on the mode on the rising or falling edge) and sample the data "manually". Once you discover a condition where SCK rises (or falls) and CS is high, you are outside the "normal" datatransfer and you start a new reception.