SPI Communications.

You might want check out this blog entry.

http://blog.hodgepig.org/articles/000048-spi/index.html

He is doing some interesting SPI stuff.

newbie said:

The master clock = 400KHz;

No, it isn't. The maste rclock is anything between 0 and the maximum clock defined by the slave. Which includes even 0 Hz. The slave cannot make any assumption about the clock speed or even how many clock pulses come before there is a pause (may be even in the middle of a byte) or even whether the clock pulse is symmetrical (as long as the minimum timings specified by the slave are met).

newbie said:

The master sends SPI data packets 8 times per second so I am counting on NO continuous clock back to back transmissions.

Another assumption that is invalid for SPI. The slave may specify that after a transfer a minimum pause is required, but even this is unusual. The slave is the slave and may not make any assumptions. This is why it is called slave and why the master is the master.

The usual way to do things is:

The master pulls down a chip select signal. This initiates the communication with the slave. It also enables the slaves output pins (MISO) which need to be deactivated all the time CS is high (as there might be many other slaves on the same line).

Then the master sends a byte and expects a byte in return. The delay between pulling CS low and the first clock pulse can be defined by the slave, but should be next to zero. If the slave requires more time, the usual way is to just put out a status byte indicating that the slave isn't idle yet. This shouldn't be 0xff (so a missing slave can be detected by the master) and may be an invalid value (in case the slave has to send data to the master). If there are no invalid values, then a 'idle' status byte should be sent when teh slave is ready and then the 'real'communication begins.

After all is done, the master pulls CS high, which will end the communication, even if it is not complete yet. It should abort any incomplete data transfer and rese thet slave to being ready for the next communication.
It is necessary to reset the SPI hardware at this point, as you cannot know whether there are half-sent bytes still in the shift register, which will be 'completed' when the master starts the next transfer. Remember, the minimum clock speed is 0Hz, so for the SPI hardware, maybe the master has just dropped the speed down to zero and will resume anytime soon (or never).

There are setups possible where there is no MISO line (the slave is just listening). Then the slave should be ready to receive data as soon as CS is pulled low. This isn't that critical as there are 8 clock cycles time until the first byte is received. There's nothing to be sent and therefore no need to hurry and provide actualized data for th emaster.
Even then, there should be a CS line. It is possible to work without, but then things get complicated, as then timeouts need to be defined. And since SPI allows any clock speed, how much shall this timeout be? Also, it will consume the while SPI bus for this single connection, as the master cannot select one from several slaves. A waste of ressources and violating the commonly used SPI specs. There are, however, examples of devices with such a wasteful behaviour.

To finally answer your question: no, there is no way to detect an SPI idle state as there is none. The only way to tell a ceased/reset transfer from an infinitely slow ongoing transfer is the state of the chip select line. If there is one. If not, you can only make a (non-educated) guess or attach a crystal ball to one of the other MSP ports.