0
\$\begingroup\$

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!

|improve this question
\$\endgroup\$
  • \$\begingroup\$ If you have complete control over the master and slaves, you can probably implement I2C broadcast and save on the SPI pins. The transmit will be slower than SPI, but unless the sent out data is much bigger than the read back data, it's probably not a big effect on the overall timing. \$\endgroup\$ – The Photon Jan 17 '18 at 18:10
  • \$\begingroup\$ The transmit data to slave from master is much much bigger. Sometimes the slaves have nothing to transmit to master, sometimes its like 10 bytes. But they all need to be receiving live data at approx 1Mbits per second but I want wriggle room so I'm aiming for larger \$\endgroup\$ – phivms Jan 17 '18 at 18:23
  • 2
    \$\begingroup\$ OK. It will help to edit the question to clarify your requirements. How much data is being sent and received, the actual maximum number of slaves, the maximum distance to a slave, etc. (Transmitting 10 Mbps by SPI could be tricky if there's more than 10-20 slaves, or if they're several meters away, for example) \$\endgroup\$ – The Photon Jan 17 '18 at 18:26
  • \$\begingroup\$ With a little board level hardware you can have all slaves driven by one SS channel, but all their MISO outputs feed a N:1 multiplexer into the master's MISO. Then you need log2(N) bits to select one slave to listen to. \$\endgroup\$ – Brian Drummond Jan 17 '18 at 18:43
  • 1
    \$\begingroup\$ 25 loads and 2 meters on I2C means you'll need to worry about drive strength of the devices, use strong pull-ups, and/or buffers and/or bus switches. But should be doable if you are careful. \$\endgroup\$ – The Photon Jan 17 '18 at 20:25
2
\$\begingroup\$

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.
|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks! I am just clarifying that they don't each need 1Mbps in case that is what you are thinking, I would transmit too all at once at 1Mbps. I am eyeing a 32 bit PIC microcontrollers for this system. Ill look into what you said! Thanks! \$\endgroup\$ – phivms Jan 17 '18 at 19:42
  • \$\begingroup\$ So, what number is a hard requirement then? Because, if you actually just need a couple dozen kb/s, then I²C will work reasonably well and you wouldn't have to do any special dance at all. \$\endgroup\$ – Marcus Müller Jan 18 '18 at 7:39
  • \$\begingroup\$ The sending data to slaves is the much higher requirements, I can probably go less then 1Mbps second though but its some rough calculations that I won't know till I near the end \$\endgroup\$ – phivms Jan 19 '18 at 0:03
  • \$\begingroup\$ yeah, really, if we don't know that it's going to be lower, then 1Mb/s is a hard limit for your design. You can't eat a cake and still be undecided whether you want to eat it. \$\endgroup\$ – Marcus Müller Jan 19 '18 at 0:15
2
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ I am new to this so I have been researching extensively on the best method and I felt so far this was the best one I could come up with. I wanted to be sure there wasn't something I missed in the process \$\endgroup\$ – phivms Jan 17 '18 at 19:34
  • \$\begingroup\$ There are probably dozens of ways to do it, some of which may be better or worse depending on your exact requirements. But the more complex the solution the harder it will be to get working properly. A common mistake is thinking you just need a bus which is fast enough to do it all. In practice there may be latency issues that make separate interfaces better (as well as easier to debug). \$\endgroup\$ – Bruce Abbott Jan 17 '18 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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