Questions regarding messages for SPI protocol

I want to use the SPI protocol to communicate between an STM32 and Arduino.

So I made up some message structure where the first byte is the 'command' byte, and data bytes following. The number of data bytes depends on the command byte (so not all messages have the same length).

Now I have a few basic questions regarding defining those messages:

1. 
   

   Can I assume SPI is kind of 100% reliable? (meaning no bytes are lost, the Arduino/STM32 will be within max 10 cm/4 inches difference) ? (if yes, the following questions might be less critical). I don't need a super fast speed.

   
   


2. 
   

   Is it a good way to have messages of different length? Rationale: When the command byte is not read correct, the number of data bytes is incorrect, and all consequent bytes will not result in valid messages.

   
   


3. 
   

   To prevent this, should I add some 'end bytes'? Or is there a better way to solve the problem of misreading (e.g. the command byte)? And if the end bytes would be e.g. 255, should I make sure 255 is not used in the command or data bytes?

   
   

Or maybe in other words:

What should I change to a simple message structure Command byte - Data byte(s) where the data bytes are varying on the command byte, in case the command byte is received incorrectly?

Answer

I use SPI to communicate between two STM32's in some of the products I design, it works well, but there are some gotchas.

Can I assume SPI is kind of 100% reliable? (meaning no bytes are lost, the Arduino/STM32 will be within max 10 cm/4 inches difference) ? (if yes, the following questions might be less critical). I don't need a super fast speed.

SPI is not 100% reliable, it is susceptible to noise, especially common mode noise. This means having a solid ground between devices. If this is a board-wire-board bus then it could also be more susceptible to noise. If you have switching power loads, this also may crate noise.

Speed and error rate go hand in hand, in general higher speeds are more susceptible to noise and the error rate goes up. The problem is in rise times (mostly from capacitance) of the bus. The higher the speed, the more likely rise times and ringing will become problematic.

I would think if your running less than ~5MHz you should be fine. Use good EMC/EMI control, check the rise times of the SCLK and give the clock time to settle, this should minimize error rate.

Is it a good way to have messages of different length? Rationale: When the command byte is not read correct, the number of data bytes is incorrect, and all consequent bytes will not result in valid messages.

This is all dependent on the software you want to write, I prefer fixed bytes. The most likely error is probably going to be from a bit flip, not a missed clock (if your running the bus slow enough).

Another thing to consider is to add interrupt lines to the spi bus for hardware flow control if you are rolling your own software. This makes it easier to tell which processor is talking, I'll usually a CS line from the master to slave, but also one from the slave to master, so you don't have to poll all the time, just handle the interrupt if the slave wants to talk (not needed if you have communication that is one way only).

To prevent this, should I add some 'end bytes'? Or is there a better way to solve the problem of misreading (e.g. the command byte)? And if the end bytes would be e.g. 255, should I make sure 255 is not used in the command or data bytes?strong text

Hardware flow control is best, if you need reliability then use a CRC byte/scheme to make sure the message has been sent correctly. Use the CS line to figure out when the message is over.