5
\$\begingroup\$

I'm developing a device that will have a flash chip and a RTC on the same SPI bus, selected using two different select lines. I also have a front panel for this device that needs to access these devices and is currently wired up to a UART, but I'm thinking of making it also an SPI device so I wouldn't have to use the extra pins.

My basic question is this - could I somehow have the front panel MCU, which will be an SPI slave, talk to the other slave devices on the bus somehow? If not, how would I be able to achieve this? I'm thinking about doing this by re-initializing the SPI bus by causing an interrupt on my main MCU, but I'd rather first see if anyone here knows if I can do slave to slave SPI comms.

Thanks for any help.

\$\endgroup\$

3 Answers 3

Reset to default
5
\$\begingroup\$

A "slave" SPI device that controls another slave becomes a master by definition.

If your front panel software is capable of implementing either slave or master roles at different times there is nothing to stop it doing so, provided that the hardware can accomodate the necessary signal flow and the "normal" SPI master does not interfere or "become confused" by the action. ie

  • Your masters need to cooperate physically: If two masters try to work at once, or if one master asserts a signal line (eg clock) that affects the ability of the other master to control the same line when desired then "there will be problems".

  • Your masters need to cooperate logically: If one master "thinks" it is controlling the bus but the other is also altering the clock or data lines "there will be problems".

From the UART and SPI IC's point of view the physical identity of the master device is unimportant as long as the signal levels and signal flow occurs correctly.

\$\endgroup\$
6
  • \$\begingroup\$ Thanks for the response! I've thought about how I could do this. The pin header that connects to the front panel had 6 unused pins, so I'll be using one of those and wired it to an unused GPIO on my front panel and to an external interrupt pin on my main PIC. I would then write an interrupt handler on the PIC that stores it's SPI state somewhere in RAM - if it's the master, it'll disable it's internal SPI and basically 'get off the bus.' Once the front panel is done, it'd assert the interrupt line again, and the PIC will enable it's SPI and be the master. I think I need to stop the SPI bus \$\endgroup\$
    – Tristan
    Commented Oct 5, 2011 at 3:09
  • \$\begingroup\$ between transitions, but I believe I can do that by just disabling the SCK line, aka pulling it low internally on my PIC when it goes off the bus until my front panel generates a SCK, and once it finished using SPI, it'd stop it's SCK. I figure this won't really cause much issues with my flash and RTC seeing as they can work with a wide range of speeds (4MHz for the RTC, 14 for the flash) but would these devices possibly have issues if their SCK is stopped while they were doing an operation? I haven't seen much in the manuals of them yet, but I shall see. Nevertheless, thanks for the response! \$\endgroup\$
    – Tristan
    Commented Oct 5, 2011 at 3:13
  • \$\begingroup\$ Some devices have a HOLD pin to stall communications. For others raising (or lowering depending on polarity) the SS pin will cancel the current transfer. As long ad you recognise that the transfer has been interrupted you can redo the transfer. \$\endgroup\$
    – Majenko
    Commented Oct 5, 2011 at 8:43
  • \$\begingroup\$ When my front panel would be assuming SPI master, I would probably configure the SS pins as inputs which would leave the pins floating, but then I'd have my front panel micro taking over - which I'm hoping wouldn't cause sporadic activation of chips. \$\endgroup\$
    – Tristan
    Commented Oct 5, 2011 at 22:34
  • \$\begingroup\$ Pins should never be left floating. If they have internal pullups it's OK. If they can be genuinely tristaed it MAY be OK. Otherwsie, being "gently" biased to some valid level is a good idea, at least. \$\endgroup\$
    – Russell McMahon ♦
    Commented Oct 6, 2011 at 1:19
3
\$\begingroup\$

The only difference between a master and a slave is the master genetates the clock and SS signals and the slave listens for them.

While the front panel in not actively being a master there is no problem with it listening for an incoming SS signal and working as a slave. An interrupt would be ideal for this.

Direct slave to slave communication is impossible as there would be no clock.

\$\endgroup\$
2
  • \$\begingroup\$ Well, basically I needed to have two slaves communicate with each other, but there is a master on the bus, so I'm guessing if I could somehow find a way to have the master generate the clock while my front panel would deal with the data, I'd be set. \$\endgroup\$
    – Tristan
    Commented Oct 5, 2011 at 22:31
  • 1
    \$\begingroup\$ At the end of the day it's just data moving around. With SPI data is shifted into one pin and out of another simultaneously. Both slaves and masters do it keyed to the clock - it's just where the clock comes from. If two slaves are simultaneously active and linked in such a way that the output of one goes to the input of the other, once there is a clock the data will move. \$\endgroup\$
    – Majenko
    Commented Oct 5, 2011 at 22:41
0
\$\begingroup\$

One of the advantages of SPI is that there are no bidirectional communications lines. This allows for things like signal boosters or repeaters which don't have to keep track of any state. Unfortunately, it also means that SPI is not well equipped internally to handle multiple masters and negotiation between them. If speed and operational constraints permit, I would suggest having one master for all communications, and having the other device that wants to exchange information with a slave ask the master for assistance. Electrically, the simplest way would be for the master to send the other micro a "what do you want to send and receiv " message, get a response, send that data out the SPI bus, get the response, and send that information to the other micro. If the master and other micro have suitably-reconfigurable I/O, it may be possible for the other device to ask the master to send out some number of bytes' worth of clock without outputting any data, and have the other device itself supply the data. That would improve data throughput, but add electrical complexity.

\$\endgroup\$
1
  • \$\begingroup\$ I've been thinking about something like this - since the front panel will need to exchange info with the main micro in quite a few cases anyways, I could somehow have it fetch my data and send it to my front panel once the data has been fetched. Then again, if I used my front panel micro to 'take over' as a master, I'd not have to hang up my main micro with data reads from 'slow' devices. \$\endgroup\$
    – Tristan
    Commented Oct 5, 2011 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.