Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
11 years, 7 months ago. This question has been closed. Reason: Question became redundant as resolved the situation myself (thanks all)
Multi-Master SPI
Hello All,
I've scanned the SPI examples and cannot find any that describe the situation where two SPI devices are connected using a 'multi-master' approach. This is where both connected SPI devices are initially set to slave SPI mode and then at some stage one of them will request data from the other by switching into master mode and transmitting a 'data request', (note that as soon as the request has completed the requesting device will immediately toggle back into slave mode).
On receiving the request the second device responds by toggling into SPI master mode and transmitting the data that has been requested and on completion of the transfer it also reverts back to SPI slave mode.
Does anyone know if there are examples of this sort of SPI 'multi-master' handshaking on the mbed website?
Thanks
2 Answers
11 years, 7 months ago.
Hi Dan,
Have you looked at the following example?
https://mbed.org/forum/helloworld/topic/2541/
Not sure it's exactly what you're after, but it's a start (maybe)?
HTH
Jez
Hi Jez,
Thank you for taking the time to answer.
I hadn't seen the example you suggested... but this does look like another situation where one controller is set to master mode and the other slave, (and this configuration remains for as long as the program runs). My alternative, of having each device toggle in and out of master mode to transmit its data, doesn't seem to be covered here.
Cheers
Dan
posted by 30 May 2013Hi Dan,
On a different (non-mbed) NXP-based product, we have an SSP/SPI link between two NXP LPC17xx parts & make use of the tow-way data transfer implicit in the operation of SPI to transfer teh data backwards.
We actually have a scheduled transfer to cycle through a series of certain data 'packets' on a regular basis & pass the size of data to be returned form the SPI slave so that if that is larger than usual we can make the next SPI Master write bigger & thus capture all the data from the SPI slave.
This stops up having to change which SPI device is the master & makes a lot of the operation much more deterministic for our application.
I understand that it might not be ideal for your solution but it might give you the option to get some code trnasferring data in both directions more quickly.
I'd have though that you would need some mechanism to prevent both trying to switch to master mode at the same time (such as a couple of GPIO lines between them for arbitration).
I've not seen any application doing what you are aiming to do with SPI (but that doesn't make it 'wrong' to try!) but have seen lots where the one master & multiple slave approach is implemented successfully.
Of course, if you want to have two devices able to access a third SPI slave (e.g. an SPI-based memory) then having the ability to change the devices between master & slave mode is a more logical solution (but still not the only way).
Just trying to suggest some potential alternatives to get you started...8-)
Cheers,
Jez
posted by 31 May 2013
11 years, 7 months ago.
My first question would be: Why do you possibly want that? SPI is a masters/slave system. Now I can imagine there could be situations where you want two masters on one bus, but switching all the time between master and slave, why? You describe for example that a device becomes master, requests data, and then the other one becomes master to send it. Why not just send it as slave?
You could do it using new and delete, and making/deleting SPI/SPISlave objects when required. And then you would need something like pull-ups on the lines to make sure they don't float. At which point it makes much more sense to go to I2C. That has proper multi-master support and for example collision detection. It might make even more sense to simply use an UART, an asynchronous RX/TX, so they can just send something to the other when they feel like it.