SPI over 1.5m distance

[ricko_uk]

Hi,
what are some reliable solutions to interface between multiple micros and devices over SPI over a distance of 1.5 meters?

Initially I thought of differential but that would not work with multiple devices on the bus because it would create bus contention.

There is an interesting LT part that is differential and has multiple CS but it costs £ 6 (for quantities) and in this system 12 are needed, so it would cost £ 70 per system which is not realistic.

Any suggestions or clever solutions?

Thank you

[Nominal Animal]

Dual or triple optical Toslink, with idle low; one cable for clock, plus one per data direction.  Price really depends on whether you can find the cables and transceivers for cheap.  You may want to do 8b/10b, depending on the transmitters used; some don't like to be 100% on.

Tongue in cheek answers aside: What's your expected/required SPI clock frequency range?  Can you use a pre-set, fixed SCK frequency?

[ricko_uk]

 

The clock as high as reasonable. The compromise is finding a balance between high enough to be acceptable to transfer maybe 20 MB of data (just from time to time) without annoying the user and low enough to work reliably over that 1.5m distance (possibly even 2m). The first constraint is much less critical then the second. So speed can be decreased but reliability and distance cannot be compromised.

Yes I can fix the clock but why does that matter?

What ideas/suggestions are you thinking about?

Thank you

[Smokey]

I've done single master / single slave SPI over cabled LVDS that was longer than 1.5m.  Should also work over something higher voltage like RS422.  With multiple devices on the bus that would get interesting through.  Maybe you could have the SS also enable the transceiver or something?

Unless you have a multi-master spi bus (is that a thing?) I'm not sure where the contentions would come from.

[ricko_uk]

Thank you Smokey.

The bus contention would come from the multiple slaves output (MISO) signals driving the same line (that goes to the master).

[Smokey]

The SS enable thing might work then.  Does rs485 not handle multi-node bus trasmissions in the transceiver?

[Nominal Animal]

Yes I can fix the clock but why does that matter?

What ideas/suggestions are you thinking about?

Weird things, as usual.  Like using cheap MCUs to convert between SPI and Ethernet transport.  Low BOM cost but high software development cost, really.  TI DP83825I 10/100 MII/RMII transceivers cost 0.20€ apiece at LCSC.  The MII/RMII interface fixes the clock (to 25MHz or 50MHz).


Instead of N slave selects, you could use ⌈log₂(N+1)⌉, and have them encode the currently selected slave in binary.
Three lines for up to 7 slaves, four lines for up to 15 slaves, five lines for up to 31 slaves, and six lines for up to 63 slaves.
If you use open collector bus for the slave selects, you can easily make it a multi-master instead, although you do need a bit of logic at the selection: only assert when bus is free, and detect when the bus state matches the node number (even when pulled down by self).

[moffy]

If you have individual CS for the slaves, then that can be used to enable/disable a tristate buffer.

[Smokey]

If you have individual CS for the slaves, then that can be used to enable/disable a tristate buffer.

that's a great idea

[langwadt]

why SPI?

[bookaboo]

Perhaps a small micro with SPI and Canbus on each node? Then its just a 4-wire solution.
Or an RF enabled micro on each node, do the comms over RF, just bring power to each node.

[Smokey]

Perhaps a small micro with SPI and Canbus on each node? Then its just a 4-wire solution.
Or an RF enabled micro on each node, do the comms over RF, just bring power to each node.

CANBUS transceivers have an ack bit after transmissions.  That would probably mess up SPI unless you were really careful.

[mikeselectricstuff]

UART over RS485, small MCU at each node to convert and handle addressing.

[Jon_S]

SPI over a distance of 1.5 meters?

We actually tried pretty much this length at 1MHz with bussed traces, with the result that the clock got into the MISO and buggered things up. A small bodge cap at the far end 'fixed' that, but we binned the idea and replaced it with CAN as cost wasn't a limitation for that application (and the processors had CAN engines anyway).

Otherwise I'd vote for mikeselectricstuff's suggestion of UART over RS485/422 as a robust solution.

[David Hess]

If you have individual CS for the slaves, then that can be used to enable/disable a tristate buffer.

Exactly, for mulitiple slaves sharing an SPI bus, a CS (chip select) signal going to each slave enables its output.  Unfortunately this means adding another signal for each slave to control CS.

An alternative is to multiplex the SPI signals at the master and run a separate set of SPI signals to each slave.

[Nominal Animal]

How about using 4 lines for node select for up to 14 nodes?  With its own timing restrictions, not clocked to the clock line?

A 74HC85 can compare the four lines to a hardcoded or dip-switched number, and a 74HC154 can expand it directly to 16 parallel active low slave selects.  Zero is reserved for "none", and node 15 the master.

Using open collector logic for the four node select lines, each node asserts its own number to send a message on the bus.  It will detect a collision by comparing the actual state of the node select lines to its own number: if 74HC85 A inputs are the actual line states and B inputs encode current node, then Q_A<B output of the 74HC85 tells if this node needs to back off.  That way higher node numbers get higher priority, with node 15 always winning all races.

Use the first 16 data bits on the bus to encode the recipient map (one bit per node), and each node can send messages to any subset of nodes.  Only needs one clock line, one data line, and 4 much lower frequency node select lines.

If the winning node also generates the clock line, then you have a multi-master half-duplex bus, I believe.

[David Hess]

There are all kinds of ways to do it.  Small microcontrollers are so cheap now that I would consider using asynchronous serial on the bus, maybe even CAN or microwire, and having a cheap microcontroller at each node to handle addressing and convert to SPI.  The idea here is that now no chip select signals are needed, and no clock signal either.

[Nominal Animal]

Very true.

In fact, I'm waiting on some WCH MCUs right now to do some experiments: CH32X033 (QingKe RISC-V4C running at 48 MHz in TSSOP20 with 20k RAM and 64k Flash for about 0.34€ apiece), mostly because the built-in two-pin PIOC; might be interesting to do PDM experiments at some point.  I'm also looking at some CH32V203 (QingKe RISC-V4B running at up to 144 MHz) for USB-SBC interfacing, especially CH32V203F8P6 (TSSOP20, 20k RAM, 64k Flash, 0.36€ apiece in lots of 72 or more at LCSC) and CH32V203C8T6 (LQFP48, 0.44€ apiece in lots of 100 or more at LCSC, one USB device + one device/host).  At this point, for a hobbyist like myself, the WCH RISC-V MCUs are as cheap as their E8051 ones are, but much more capable.

I mention this because those CH32X033/CH32X035 and CH32V203 RISC-V MCUs have hardware SPI slave support, which I believe (but have not verified) should work at up to quarter/half the frequency of the main clock (so 12 MHz/72 MHz, respectively).  They can also output their system clock on a dedicated pin (MCO).  It might be possible to use the PIOC RISC8b processor on the CH32X03x for 8b10b encoding or decoding, for example.  If interested, see WCH's openwch github, ch32x035 repo.

[SiliconWizard]

SPI over a distance of 1.5 meters?

We actually tried pretty much this length at 1MHz with bussed traces, with the result that the clock got into the MISO and buggered things up. A small bodge cap at the far end 'fixed' that, but we binned the idea and replaced it with CAN as cost wasn't a limitation for that application (and the processors had CAN engines anyway).

Otherwise I'd vote for mikeselectricstuff's suggestion of UART over RS485/422 as a robust solution.

I second that, if you want something robust and that will work at a few Mbits/s, I would recommend CAN FD. Up to 8 Mb/s IIRC, robust, easily available (many MCUs now support CAN FD), cheap. If max 1Mb/s is OK, standard CAN will work too and will be even cheaper.

[Doctorandus_P]

What about using quad SPI and make it resemble GPIB and using HDMI cables for the differential bits?
As you are dealing out all the cards yourself it should not be too difficult to put those things together into something affordable, speedy and reliable.

I am not sure at what point things like clock de-skewing becomes an issue. And instead of all the slave selects, maybe you can pass around a token on the bus, i.e. poll the devices in some sort of sequence.

[T3sl4co1l]

1.5m isn't very long. If you can afford a shielded cable, do that. Tie shield tightly to circuit ground plane at both ends, as you are extending the reference plane into the cable and the signals are referenced to that.  A generic multiconductor cable will also have some reference between lines, which can create interference like so,

We actually tried pretty much this length at 1MHz with bussed traces, with the result that the clock got into the MISO and buggered things up. A small bodge cap at the far end 'fixed' that, but we binned the idea and replaced it with CAN as cost wasn't a limitation for that application (and the processors had CAN engines anyway).

The problem is that, for risetime on par with electrical length, the coupling between lines becomes significant (say, > -10dB).  Bused traces over ground plane shouldn't be a problem, but it does depend on the relative spacing and height above plane; likewise the multiconductor cable, how the wires are arranged within it: consider a 7-core cable where the center wire is surrounded by six others, it has no ground reference except by the 1/6th electric field per surrounding conductor, making crosstalk inevitable.  Maybe 1/7th is still within margin, but be careful that multiple signals aren't transitioning at the same time, coupling a bigger total bump into the neighboring wire.

If you can afford filtering to reduce signal bandwidth below the cable's resonances/cutoffs, that greatly improves crosstalk -- at low frequencies, crosstalk manifests as mutual capacitance between lines, and you can just drive them strong enough and filter it down enough that remaining crosstalk doesn't exceed the valid logic threshold level (for typical CMOS pins, about 30% -- on par with the -10dB figure I gave above).  This is very likely satisfactory, for max 1.5m length, below say, 10Mbps or so, maybe even up to 20.

Or, if you can choose twisted-pair cable, shield is still needed, but crosstalk can be improved by grounding every other wire -- so each signal is twisted with GND.  This, at worst merely halves the crosstalk (in the middle of a long cable, the twisted pair looks differential again, CM coupling with neighbors occurs; then CM-DM mode conversion happens when one of the pair is grounded at the other end), but for a short cable, or with CMCs at either end to pseudo-differential drive the pairs (sort of, using the CMCs to pre-crosstalk the signals, so they come out the right way at the final end), crosstalk can be much less.

For long cables, shielded or not, I would just as well suggest RS-422 or 485.

For unshielded cables, choose twisted pair, and use differential even for short lengths or low bitrate.  Filtering may still be necessary; and note that ground wires must be provided, as RS-422/485 isn't isolated, it has a finite working input voltage (CM) range.

SPI can trivially be sent over RS-422 with transmitter/receiver pairs.

Unshielded, non-twisted cable can be used only at very low bitrates -- say, under 1Mbps; filtering is required at both ends, and perhaps a schmitt trigger to recover sharp clock edges.  UART may be preferable to SPI.

If you don't mind the increased complexity (packet framing / bus state / sequencing, escaping/coding, timeouts, etc.), UART over RS-422 (unidirectional per pair) or 485 (bidirectional; of course, you have to solve bus arbitration as well) is promising.

Also, may be of interest: 485 can be used to save power, even if it's used unidirectionally.

Tim

[Kleinstein]

One problem with a digital signal over a long distance is signal reflections and thus ringing, especially with the clock signal. It depends on the devices how sensitive they are. Some µCs can be quite tolerant and simple shift registers are easily fooled by ringing.

One way would be some at least approximate impedance matching with the clock line. Depending on the configuration also clock buffers further down may be an idea, depending on the configuration.
Another option could be BW limiting of the clock signal and where needed schmidt triggers at the devices.
This can get tricky with multiple masters.

[ricko_uk]

Thank you all for all those good ideas and suggestions, much appreciated!!

I am now looking into pros and cons (board space, conenctor/cable impliactions, cost, complexity etc.) of several of them.

CAN bus might be an option, I am checking now with the client to see if it is acceptable.

I never used CANbus and when I looked into it almost 20 years ago it was not that easy to work with, especially during debug. Things might be much better nowadays.

If you can afford filtering to reduce signal bandwidth below the cable's resonances/cutoffs, that greatly improves crosstalk -- at low frequencies, crosstalk manifests as mutual capacitance between lines, and you can just drive them strong enough and filter it down enough that remaining crosstalk doesn't exceed the valid logic threshold level (for typical CMOS pins, about 30% -- on par with the -10dB figure I gave above).  This is very likely satisfactory, for max 1.5m length, below say, 10Mbps or so, maybe even up to 20.

How do you find a cable's resonant/cutoff, just by checking signal integrity with an oscilloscope, or some other way?

And what kind of filtering / order?

Thank you

[varjag]

Did you consider use of extenders?

https://no.mouser.com/new/analog-devices/adi-ltc4332-extenders/

Tho I agree with T3sl4co1l, at 1.5m it may well work just fine at a reasonable clock.

[T3sl4co1l]

How do you find a cable's resonant/cutoff, just by checking signal integrity with an oscilloscope, or some other way?

And what kind of filtering / order?

1. A terminated cable has no resonance, it's matched at all frequencies.

With CMOS drivers, this can be achieved with a source termination resistor; a typical output pin is 30-70 ohms internal resistance, so a typical 70-100 ohm trace (or wire in a ribbon cable, every other wire GND) needs 33 ohms in series, give or take.  More can be used to reduce risetime further, approximating the cable as a shunt capacitance and thus an RC filter is had.

For the shielded multiconductor cable case, Zo may be lower (a given wire surrounded by many wires, and/or shield -- approximately a coaxial construction), and perhaps a bus driver (stronger output) is desirable, or even a proper transceiver setup (source (series) termination + load (shunt) termination + precision threshold receiver IC -- for example, analog comparator or perhaps LVDS receiver, vs. a set threshold; 74HC7014 precision schmitt buffer; etc.).

For reasonably well isolated signals (like alternating signal-GND in a ribbon cable, modestly spaced microstrip over GND plane on PCB, or individual coax), with termination, operation is limited only by the effect of propagation delay on the protocol (e.g., MISO might be delayed by a whole clock time) and the attenuation rate of the medium.

2. A poorly terminated cable, or the bandpass coupling due to crosstalk, or the potential for emissions on a poorly or unshielded cable, may find filtering desirable.  The electrical length of the cable is its length divided by its velocity factor (including the speed of light), t = l / (c c_0).  Typical cable is 60-85% c_0 so 1.5m is 6-8ns.  Note that a full reflection travels the length and back, or 12-17ns.  The corresponding frequency is this half-wave period, or 30-43MHz, and harmonics thereof.

For good square pulses, we want to operate less than, say, 1/5th the cutoff frequency, so under 10Mbps will be fine; pushing towards 1/3 might also still be fine, which is as I said before, a bit more may even be acceptable.

The nature of that filtering, can take on many forms:

A simple (single pole) RC filter provides gentle attenuation vs. frequency, so we might prefer it to cut off much lower, to get adequate attenuation near resonance, but that limits baud rate even further.

An LC filter can have sharper response, making cutoff just below cable resonance feasible, and a Bessel characteristic can be chosen to maximize pulse clarity.

An RLC filter is probably best, so that damping resistance is available to absorb resonances on the cable, as well as soften the cutoff characteristic.  A series ferrite bead is a typical choice here, and then some 100s pF shunt.  The ferrite bead may be before, after, or both, the capacitor -- note that FB between cap and cable provides resistance necessary to terminate/dampen its resonance.

We might also choose a series L, then shunt (C || (R + C2)) circuit: we have C2 > C, so that R is dominant in the transition band, terminating the filter even if the source is high or low impedance, or the load is high impedance.

The shunt capacitor is also a good place to put a clamp diode/TVS, for ESD purposes.

Tim