[PIC] Is this SPI Multi-Master Communication working properly ? [Doubt]

[milan.rajik]

Is this SPI Multi-Master Communication working properly ?

Please see the image. There are some zeroes shuttling. Are there zeroes present because after 1st SPI communication the SSPBUF got cleared and it is shuttling in further SPI communications ?

broken link removed

 

[Aussie Susan]

By definition the SPI protocol does not allow multi-master operation. The reason is that the SPI protocol assumes that the "master' has complete control of the SCK signal. Also, it generally means that the MOSI (or in Microchip terms, the SDO) signal can also always be driven.
SPI does allow for multi-slave in that the slaves only ever drive the MISO (or SDI) line and they are expected to do this ONLY when their \SS\ line is low.
Using Microchip devices, the only way you could have multiple masters on the SPI 'bus' is to disable one SPI master and let the other 'master' take over and drive the SCK and SDO lines.
I've not looked at your code, but from the circuit diagram I can't see any lines that connect between the MCUs that would allow the two to communicate in this way to switch between the 'master' roles.
Susan

 

[milan.rajik]

Using Microchip devices, the only way you could have multiple masters on the SPI 'bus' is to disable one SPI master and let the other 'master' take over and drive the SCK and SDO lines.

That is exactly what I have done in the code.

I've not looked at your code, but from the circuit diagram I can't see any lines that connect between the MCUs that would allow the two to communicate in this way to switch between the 'master' roles.

You can see that in the circuit (Master-Slave-X = MS-X)

connections

MS-1's SCK connects to MS-2's SCK

MS-1's SDO connects to MS-2's SDI

MS-1's SDI connects to MS-2's SDO

MS1's SS connects to MS-2's SS.

The SS line is used for selecting slaves. In the code SS is toggled as Output or input as required during master mode and slave mode.

 

[Aussie Susan]

That was not what I meant. Yes I can see how the SDI and SDO pins are connected but not how the two devices decide which is to be the master and which the slave at any point in time. You only have the 4 SPI lines that are in common between the two MCUs.
As you don't show any code, I can only assume that you have the SPI peripherals disabled and when one MCU wants to send something to the other it must try to use one (or more) of those lines to see if it can become the 'master'. As the only line that is not pulled 'high' is the 'SS' line, then I assume you let it float normally and try to use some tricky algorithm to detect a collision when both devices try to take on the 'master' role.
I must admit, I can't see the advantage in using the SPI peripherals in this way. I2C has multi-master capability built in to the protocol, but as you simply want to exchange values between the two MCUs, why not use the UART? That way each can simply send the value to the other whenever it wants to - no need to try to claim bus ownership and each can send to the other without regard for what the other MCU is doing.
Susan

 

[milan.rajik]

As you don't show any code

In the .rar file I have posted the complete mikroC PRO PIC project. You can view just the .c file. If you still want me to post the code here, I will do so.

 

[FvM]

It's bad enough that this discussion proceeds in a cross posted thread, but moderators decided not to merge the threads to avoid further confusion.

I complete agree with Aussie Susan's statement "I can't see the advantage in using the SPI peripherals in this way".

No question that it can be done somehow, although synchronizing the master/slave role swap isn't easy and prone to failure. There's a reason why I2C has a dedicated, well considered protocol for multi master operation. All in all, the idea looks to me like re-inventing a square wheel.

Having sayed this, we could of course interrogate what goes wrong in the example.

 

[milan.rajik]

This is not a cross posted thread. The other thread is related to SPI Master Slave and this thread is SPI Multi master. The two threads have different codes posted.

 

[FvM]

This is not a cross posted thread. The other thread is related to SPI Master Slave and this thread is SPI Multi master. The two threads have different codes posted.

Yes, they have different codes, but it's still a very formal and wordly innocent few, I think. The Edaboard "duplicated content" rule is talking about related posts that should be posted in a single thread with a good reason.

Even if you have a clear distinction between both threads in your mind, it usually won't arrive at the reader, particularly if both threads are using exactly the same simulation circuit.

 

[Aussie Susan]

OK - back to the original question which (I think!) was why is the 'slave' side of the exchanges always sending zeros? (Please correct me if I'm wrong as your question is not very clear to me.)
Looking at the code (and I now see it - but there are 41 files in there and I think only 2 are relevant; master.c and slave1.c!) you write to the SSPBUF when the SPI peripheral is in 'master' mode and use the interrupt to receive values when in 'slave' mode.
However when in the 'slave' mode, you don't ever load up the SSPBUF with a value to exchange back to the master. When in slave mode, you need to set the SSPBUF with the value you want to send back when the master initiates an exchange and in the ISR (in your case) read the received value and then write the next value to send.
The SSPBUF is not an 'ordinary' register in that what you read from it is not necessarily what you write to it. If you look at Figure 13-1 in the data sheet for your MCU on page 187, and read the description underneath about how the register works, you will see that writes to the SSPBUF are also made to the SSPSR register. The data sheet is also silent on what the SSPBUF/SSPSR registers hold when nothing is written to the SSPBUF before an exchange (in slave mode - this situation cannot occur in master mode as the writing to the SSPBUF is what triggers the exchange) so it can be assumed that the result is "unpredictable".
You are using a simulator which means that you need not be seeing what a real device will do but what the simulator writer wants to do - which appears to be using a value of zero in this case.
Again, use the UART rather than the SPI and you will not have this issue as you control what is sent at all times.
Susan

 

[milan.rajik]

why is the 'slave' side of the exchanges always sending zeros?

No, it is not sending zeroes. Data is being transferred properly. You can see the data on LCD. My question was are those zeroes in the SPI debugger present because the SSPBUF got cleared after each byte is transferred ? SPI debugger shows both data that came into the SSPBUF and also that went out of the SSPBUF. See the arrow marks.

Yes, my next project will be UART Synchronous communication.

 

[Aussie Susan]

As I mentioned, on a real MCU the data sheet is silent on what value (if any) is in the SSPBUF if you don't write to it. I have even less idea what your simulator is doing but, going by an apparent interpretation of the trace you have shown, it is putting in zeros.
The way I read that trace, you are looking at both the DIN and DOUT lines of the SPI device at the bottom left of the image. Because the SPI protocol is always an exchange of values and you are not writing to the SSPBUF when a particular MCU is playing the 'slave' role, you are seeing the values form the 'master' and zeros form the 'slave', which is exactly what your code says should happen.
Susan