Multiprocessor : SPI vs USART

[alexandre239955]

Posted on May 13, 2009 at 04:23

Multiprocessor : SPI vs USART

[alexandre239955]

Posted on May 17, 2011 at 13:10

Hello,

I would like to implement communication between 3 STM32F103 on a board, I know USARTs quite well but I dont have much experience with SPI. - One CPU is a kind of Master, it contains the global state of the application, the 2 others are kind of slaves, they handle communication with external devices and preprocessing, they talk only to the Master. - Important, the CPUs are independant, they do their stuff and are not synchronized, they should never wait for an other CPU. I saw that multiprocessor communication could be done using SPI or USARTs, what do you think would fit the best for this? - With SPI, we can go faster, but how could we do to avoid synchronization, the data of the slave have to be ready when the master starts the exchange ? - With a USART ''bus'' (24.3.5 on the manual, ''Multiprocessor communication'', 1 USART on each processor), the problem is the same than for SPI, the slaves cannot talk at anytime, so there is some synchronization, and both slaves cannot talk simultaneously ? - Is it the best to use 2 USART pairs (Master-SlaveA, Master-SlaveB) and using 2 independant USARTs on the master side ? Thank you, Alexandre

[miles]

Posted on May 17, 2011 at 13:10

Quote:

- Is it the best to use 2 USART pairs (Master-SlaveA, Master-SlaveB) and using 2 independant USARTs on the master side ?

Unless you do not have enough hardware UARTs, or cannot fit the wires into the cables necessary, it will make it much simpler to use multiple UARTs. If you decide to have multiple UARTs on one bus, I suggest using an existing protocol (perhaps

http://en.wikipedia.org/wiki/Profibus

). You could also use

http://en.wikipedia.org/wiki/Controller_Area_Network

. All low-level bus contention issues are handled by hardware. From a software point of view you transmit whenever you like, then the hardware decides when messages actually go onto the bus.

[jpeacock2]

Posted on May 17, 2011 at 13:10

What you might consider is buffering the data in RAM in the slave processor. Use a GPIO pin from the master to generate an interrupt on the slave, indicating the master is ready to receive data. The slave then sets up a DMA channel to empty the buffer via USART or SPI to the master. A GPIO pin from the slave to the master interrupts the master when the DMA is complete (unless you are transferring fixed length blocks, in which case a DMA terminal count interrupt can be used).

This way your only overhead is the GPIO interrupt on each side, plus the bus cycles for the DMA. SPI would offer an advantage of transferring 16 bits at a time, cutting the bus cycles for DMA in half. Neither side stalls since the transaction is interrupt driven.

[relaxe]

Posted on May 17, 2011 at 13:10

Your situation seems perfect for SPI.

SPI is a pretty simple 1 master multiple slaves peripheral. About the ''synchronisation problem'' you seem to ask about: SPI is clock and ChipSelect controled by the master. The slaves synchronise themselves with the Master's clock. The Slaves will not be allowed to talk on the bus unless the master issue them a ''Chip-Select'' (Or Not-Slave-Select). So the advantages are: No collisions, No sync problems, as many slaves as you want. Drawbacks are: You need a master, slaves haves to get invited to talk on the bus by the master.

[darcy]

Posted on May 17, 2011 at 13:10

Hi, for the past few months I've been implementing multi processor comms on a single board with 12 (yep, twelve) STM32F103's.

We use SPI because we can get up to 18Mbit out of it. Single master, 11 slaves. One of the posts above hit on a point that we quickly found... the DMAs introduce quite a few challanges. I'll just list a few points and you can take from them what you want... Fixed length packets will make life easier because then you won't need to interact with the SPI driver once set up. Variable length packets mean that the master will need to inspect the slave's reply once the master has finished its own transmission to see whether it has finished receiving the whole packet - if it hasn't it needs to send (e.g.) zeros until the slave has finished sending all that it needs to (this is the method we use, quite easy to implement but you do need to interact with the SPI driver as well as the DMA interface). The biggest issue with fixed length is when you want to send a message greater than the packet size... reconstruction and all that hassle. Status lines, status lines, status lines!!! These will make your life a WHOLE lot easier. If you're using a packet/ack setup the slave needs to know whether the master is exchanging message packets, or ack packets. We didn't want to have sliding window packet sequence numbers so we keep sending the same packet until we get an ack. This makes software simpler but may not suit all scenarios. The reason for the status lines is that you can assert one line, pull SSEL/NSS low, and this can trigger an external interrupt on the slave STM32. Based on the status lines the slave now knows whether it's exchanging message or ack packets. The advantage of fixed size packets is that you can use the ''free'' CRC16 built in to the SPI peripheral. We use the CRC32 peripheral because it just became too much hassle to use the free CRC16 with variable length packets. Forgot to mention, we interrupt on both high>low and low>high transitions of SSEL at the slaves, giving the slave the knowledge of when the exchange is complete (in this case the DMA receive buffer is many times the size of the actual packet being exchanged). We then manually go in and check the DMA count (at the slave) to see how many words were received. If you've never worked with SPI before you might have some fun in stall for you. If you've got one master and two slaves, you'd proabably find it easier to have the master dedicate one uart to each of the two slaves. This immediately allows both slaves to talk to the master at the same time, but not with each other. Ahh... as per your last note I see. Yep, this would be the quickest method to implement. Have fun!

[picguy]

Posted on May 17, 2011 at 13:10

On one board using separate RS-232 ports is a piece of cake. I would vote for that.

FWIW my RS-232/FIFO page

http://www.hmtown.com/fifo.htm

may be useful. It discusses a simple method of separating physical (ISR) I/O from logical (task) I/O. My way of handling RS-232 allows data to flow both directions at once without confusion. This is sometimes useful.

[alexandre239955]

Posted on May 17, 2011 at 13:10

Thank you very much for all your complete answers ! It helped me a lot to better understand 🙂

As I have variable packet length coming on the slave from external devices, I am implementing with 2 USART pairs, and probably a CAN will be used to send small critical messages. The USARTs can go up to 2 Mb/s, so this will be enough for my application. Best regards, Thanks !