Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

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

Status
Not open for further replies.

milan.rajik

Banned
Joined
Apr 1, 2013
Messages
2,528
Helped
540
Reputation
1,078
Reaction score
523
Trophy points
1,393
Activity points
0
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 ?

 

Attachments


Aussie Susan

Advanced Member level 4
Joined
Jan 5, 2015
Messages
1,190
Helped
365
Reputation
730
Reaction score
362
Trophy points
83
Activity points
12,894
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

Banned
Joined
Apr 1, 2013
Messages
2,528
Helped
540
Reputation
1,078
Reaction score
523
Trophy points
1,393
Activity points
0
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

Advanced Member level 4
Joined
Jan 5, 2015
Messages
1,190
Helped
365
Reputation
730
Reaction score
362
Trophy points
83
Activity points
12,894
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

Banned
Joined
Apr 1, 2013
Messages
2,528
Helped
540
Reputation
1,078
Reaction score
523
Trophy points
1,393
Activity points
0
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

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
47,466
Helped
14,044
Reputation
28,341
Reaction score
12,695
Trophy points
1,393
Location
Bochum, Germany
Activity points
276,048
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

Banned
Joined
Apr 1, 2013
Messages
2,528
Helped
540
Reputation
1,078
Reaction score
523
Trophy points
1,393
Activity points
0
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

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
47,466
Helped
14,044
Reputation
28,341
Reaction score
12,695
Trophy points
1,393
Location
Bochum, Germany
Activity points
276,048
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

Advanced Member level 4
Joined
Jan 5, 2015
Messages
1,190
Helped
365
Reputation
730
Reaction score
362
Trophy points
83
Activity points
12,894
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

Banned
Joined
Apr 1, 2013
Messages
2,528
Helped
540
Reputation
1,078
Reaction score
523
Trophy points
1,393
Activity points
0
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

Advanced Member level 4
Joined
Jan 5, 2015
Messages
1,190
Helped
365
Reputation
730
Reaction score
362
Trophy points
83
Activity points
12,894
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
 
  • Like
Reactions: FvM

    FvM

    points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.
Toggle Sidebar

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top