Maybe this application calls for getting rid of SPI completely and implementing fully interlocked handshaking. With this scheme you can go as fast as the software can allow it to go but it is 100% tolerant to delays on either side due to interrupts or other high needs tasks.

The scheme uses two handshake lines, one from master to slave and one from slave to master. In parallel with these you allocate from one to N data lines. The basic scheme works like this. Master puts data bits onto the data lines and then raises the hand shake line to the slave. Slave sees the rising handshake line and strobes data off the data line(s) and after getting the data will put the return handshake line to a high level. Later the master sees the raised return handshake. This will cause the master to put the next bits onto the data lines. After the data is placed the master lowers the outgoing handshake line back to the low level. Slave sees the lowering at its input and thus strobes the next data off the data line(s) and will subsequently then lower the return handshake line back to the master. Master sees the lowering and gets ready to start the whole cycle again.

I have implemented this scheme MCU to MCU, PC to MCU, MCU to PC and PC to PC. In the various renditions I have used 1, 2, 4, 6 and 8 bit data paths. With careful design a whole protocol can be built on top of this flexible data rate communications scheme. If you establish the proper syncing and packet level strategy it is straight forward to anticipate data flow back to the master from the slave. During this "read" portion of the protocol the sense of who "owns" the initiating end of the pair of handshake lines gets swapped temporarily so that the slave can sequence flexible speed transfer back to the master side.

Protocols like this require much attention to details like timeouts, how to use the pair of handshake lines to implement a slave reset function, inclusion of byte transfer sizes in all packets and use of CRCs to check for packet integrity. With the work done carefully you can build a reliable communications system that can even adjust for long time delays involved with sending data down very long cables. Distance and speed automatically adjust within the physical limits of the drivers and receivers used on the lines. I've implemented with TTL open collector wires, TTL tri-state wires, using RS422 type differential drivers and even RS232 type drivers with +/- voltage swings. Some implementations have included opto couplers for isolation with the delays of such components in the paths automatically taken into account. With modern MCUs achieving data rates that are quite impressive is possible and is directly proportional to the number of data lines you choose to employ in the design.

I had one recent design where I used this scheme between two PCs for passing debug print information from an embedded PC in a BIOS debugging mode over to a laptop that was capturing the data. I was able to achieve data flow with just one data line that exceeded the max rate one would expect for a 115.2K baud serial port link by about 3X. (In this particular case the serial port was unavailable for debugging use).

Michael Karas