SPI between USCI and USART

In theory, yes. However, the USCI SPI can work seamless, as it does double buffering of incoming and outgoing data. The USCI can only handle one transfer (up to 16 bits in a row = 2 USCI bytes) and then requires software interaction. The software has to handle the end of an USCI transmission in less than 1/2 SPI clock cycle or it will miss a bit.

So if the USI module is the SPI master, there is no problem (as the USI controls the clock timing). However, if the USCI is the master, the baudrate must be low enough (and the software fast enough), so the USI can keep up with a continuous clock.

Thank you. I kind of thought that as long as the timing with the clock was good that the SPI interfaces should be able to communicate.

I am planning on using the USCI and USART as they can handle multiple slaves.

Mike Kuehn said:

I kind of thought that as long as the timing with the clock was good that the SPI interfaces should be able to communicate.

On the othe rhand, on SPI, the clokc signal does not need a specific baudrate. YOuc an change the clock speed from high to veeery low in teh middly of a byte. Unless you cause a timeout on teh slave, all will be well. The problem is at the upper end, since the SPI slave has no way to slow down the master (on I2C, it has, called clock stretching)

Just for an off the wall question.

Are there any software layer protocol standards for the SPI mode of communication? By this I mean transmission validation or some such thing. Especially when working with multiple slaves. Or, is the low bandwidth limiting the desire for validation? As it takes eight clock cycles to transmit one character.

Mike Kuehn said:

Are there any software layer protocol standards for the SPI mode of communication?

Mike Kuehn said:

Or, is the low bandwidth limiting the desire for validation?

Since the SPI bus has its lines driven high and low and the clock is provided with the data signal, the line is almost 100% reliable. It is not suited to be sent over long wires or being transformed (like morphing a sreial RS232/UART signal into RS485 and back). It is for short distance high-speed connections.

About the CS line - some claves require it to be pulled low before and high after every single command transfer, others take it for the start aof a new high-öeveö protocol transfer of several bytes in both directions. in any case, when the CS line goes high, the slave has to be immediately deaf and silent. Some slaves even support freezing a transfer in the middle of a byte when CS goes high, and continuing with the rest later when CS goes low again. The MSP does not support this in master mode, however (but in slave mode). Others abort any non-completed command sequence when CS goes high.

About the 'one slave, one CS', there are some exceptions. Here several slaves can be daisy-chained, so the output of the first slave is the input of the second and the output of the last slave goes to the master. Here, all slaves get the same CS signal.  Usually, teh data they received is captured when CS goes high. So you can send the data for the last slave in the chain first, then the data for the second last etc. The slaves will then output the incoming data to their output (starting with their own state data when CS goes low). So all slaes work like a large n-bit shift register. The master then receives the data form last lasve in the chain first while sending the data for the last slave first. This only works if the slaves have no own data to report (e.g. a serial-in, parallel-out latch) or have exactly as much data bits as they require command bits. Works fine for a/d and D/A chips or the mentioned latches.

Thank you for your comments. They have been quite informative. 

Jens-Michael Gross said:

About the 'one slave, one CS', there are some exceptions. Here several slaves can be daisy-chained, so the output of the first slave is the input of the second and the output of the last slave goes to the master. Here, all slaves get the same CS signal. Usually, teh data they received is captured when CS goes high. So you can send the data for the last slave in the chain first, then the data for the second last etc. The slaves will then output the incoming data to their output (starting with their own state data when CS goes low). So all slaes work like a large n-bit shift register. The master then receives the data form last lasve in the chain first while sending the data for the last slave first. This only works if the slaves have no own data to report (e.g. a serial-in, parallel-out latch) or have exactly as much data bits as they require command bits. Works fine for a/d and D/A chips or the mentioned latches.

The ‘one slave, one CS’ is one thing that bummed me out. Once you get over four slaves you really start to burn pins. I had seen the Wiki page Serial Peripheral Interface and they talked about the daisy-chained slaves. At eight clock cycles per transmission your latency will climb with more slaves.

I realize the half clock cycle to refill the transmission buffer is an issue. One idea I was thinking was to have two unidirectional interrupt wires (one from the master to all slaves and the other from all slaves to the master) and then to have n-address wires. Four or five wires could address 16 or 32 slaves (I would not need this many :). The interrupt wires would drive the chip select function. The address wires would identify the particular slave. You had talked about the master chip delaying the clock in an earlier post. This could be a fixed length delay between bit-shifter reloads and allow an outside chip select function work the signal from inside the chips. In other words, the chip select pins would not need to be external pins on the chip that are in limited quantity. This is assuming that I could work the STE I/O without tying them to external pins. Do you know if it is possible to send a signal to STE from the internal data bus?

Mike Kuehn said:

and then to have n-address wires

You can of course use an address dcoder chip that has m input lines and n = 2^m separate output lines, to extend the MSPs direct IO port usage. Since it is a requirement that only one of them may be low at a time (or else more than one slave would be speaking on the same SOMI line at the same time) You can even scale this by having a master decode that selects several slave decoders on different parts of the PCB by the top 'address lines', while the slave decodes only get an enable signal from the master decode and decode based on the lower 'address lines'. so at the end only one of the slave decoders outputs one low signal.

The only requirement is that only one slave will receive a low signal at a time (and after all the decoding work and inherent signal delay, the master may not start with the actual transfer too soon)

Mike Kuehn said:

You had talked about the master chip delaying the clock in an earlier post. This could be a fixed length delay between bit-shifter reloads and allow an outside chip select function work the signal from inside the chips. In other words, the chip select pins would not need to be external pins on the chip that are in limited quantity.

There may not be something like 'after n bits, the master must stop for m milliseconds'. If such a delay is needed, this is part of a high-level protocol (which may be slave specific and has nothing to do with the SPI itself).
Some SPI slaves (e.g. teh SD card) use a protocol similar to this: immediately after receiving the command, the slave outputs 'busy' bytes (e.g. 0xff) and the master has to continue polling until it receives a byte that is not 0xff. This then is either a status byte or the answer to the command or whatever. usually, the master has to send a dummy byte to the slave to check whether the slave is ready to receive a command too, so the transfer can be interrupted (e.g. master sends command, then pulls CS high and does something else, and when the master next time pulls CS low and sends a dummy command, it will get either a 'still busy' byte or the answer to the previous command, or a status byte saying 'the result of the previous operation can now be requested with the proper command' or something like this.

This is, however, 'on top' of SPI like TCP and UDP are 'on top' of IP protocol, which uitself is als 'on top' of the base, MAC oriented ethernut frame.

Mike Kuehn said:

his is assuming that I could work the STE I/O without tying them to external pins. Do you know if it is possible to send a signal to STE from the internal data bus?

No need nor way to set the STE pin from inside. If you want to cut the SPI hardware form the bus by software, clear the PxSEL bits (have the port pins configured to GPIO input before you do, so they are high-impedance and do not lock the bus).

Thank you for all this information. I will need to play with it for a while to get a full understanding of it, but this has given me a direction to look at it from.