Instantaneous Transmission, Selective Response

Question

I am building a system where I need to transfer the exact same data to tens of devices, but I need to get individual responses. I also need to limit the amount of pins required and have as fast as possible transmission.

My current idea is this: Use SPI to communicate to all slaves by tying all the slaves to the same SS channel. That way all slaves receive the same info at the same time. When it comes to receiving data, I would ask for data from each slave through I2C. This way I only have 6 pins to transmit at a rate of 10Mbps and receive data at 400kbps. Would this idea work or is there a better solution?

I need a fast master to slave transmit rate as the data needs to be realtime, whereas the data from the slaves can be a bit slower which is why I chose I2C.

Thoughts?

Extra Data:

• Distance from Slave to Master will not exceed 2 Meters maximum. It will be usually much shorter from a distance of several inches.

• Slaves Count Will not extend 25

• Received Data from Slave to Master will vary. Could be 10 bytes at a time, or it could be 100 bytes at a time.

• Transmitted Data to slaves needs to be quick at around 1Mbits to all at once. There is some flexibility.

Thanks!

Answer 1

At 10 slaves that needs to receive 1Mb/s: I'd argue that you're entering the area of things that should be solved with a dedicated multi-node bus, rather than cobbled together.

Generally, however, the idea of using SPI (with appropriate fan-out buffering, it's not said that any SPI master can drive a bus with 10 slaves at different distances) for broadcast, and I²C as backchannel is sound.

That way, however, you get a highspeed one way, low-speed no-interrupt backchannel, and that might get complicated. As Brian Drummond recommended, having a mux that just assigns the MISO to a single slave would enable you to use "normal" bidirectional mode, with TX being "broadcast" as a "side effect", and that would simplify the bus logic immensely.

I'd argue that for SPI at these rates, 2m is actually quite a lot. It definitely works, if you buffer and carefully design traces and wires, but it's a fragile thing that will need a lot of tuning.

All in all: I think you might be better off with something like ethernet. 10×1 Mb/s doesn't really sound like you're connecting arduinos, anyway.

Look into existing Buses:

• CAN sounds a lot like what you want. 2m, high reliability, lots of broadcast traffic, individual small data replies. I think CAN works very well fro broadcast data, and otherwise "feels" a bit like a multi-master I²C bus. It's commonly available as integrated in MCUs, because it's an automotive bus. It is very proven. I think it's fastest mode runs at 1Mb/s, so you got no headroom there.
• LIN: cheaper alternative to CAN (and basically obsolete because CAN is cheap these days): too slow
• I²C: too slow
• SPI in a shift register ring: Design your own protocol. All your slaves and your master form a ring; data is just shifted through the slaves in one direction in a fixed packet length with a header byte saying from where the data came; many microcontroller's SPI peripherals actually do exactly that forwarding with their RX buffers if you don't modify the TX buffer.
  If a slave has something to say, it inserts its own packet. Works if you clock your SPI bus faster than 1Mb/s, so that there's reliably gaps in between broadcast packets. Downside is: own implementation -> bugs, limited segment length, and of course latency.
• Ethernet: Will need Microcontrollers that "speak" to a PHY (MII, RMII, GMII,…) and ethernet PHYs. On a single PCB, you might get away without magnetics attached to these. Upside is obvious (well-tested protocol, including broadcast, unicast, multicast, hardware integrity, mature and easy debugging, prototyping with a goddamn normal PC with a normal network card). Downside: Cost
• USB: Master and slaves speak USB 2 FullSpeed = 12Mb/s. Only allows for point-to-point (as far as I know), will need a USB hub IC, but a very elegant, easy to test, relatively cheap solution. Downside might be firmware complexity.

Answer 2

Would this idea work...

It should, provided the interface requirements are met (SPI fanout?) and the devices can handle the data rates.

...or is their a better solution?

Possibly, but why should you care? The important thing is to develop a solution that works satisfactorily. An advantage of your idea is that it is simple and easy to debug, whereas a 'better' solution that eg. multiplexes the SPI slave responses might require extra hardware and more complex software that could be hard to get right.