How does the SPI bus length effect the communication. I found that if SPI bus length is increased, it does not communicate at all. How does the length effects the communication?


  • \$\begingroup\$ Can you bound the problem here by specifying what frequency you are running the SPI CLK at and what range of lengths you have tried between working and not working? \$\endgroup\$ Nov 27, 2015 at 18:23
  • \$\begingroup\$ I was running the SPI at baud rate of 6.5Mbps. The bus length when working can be around 5 inch and non working was more than that. \$\endgroup\$
    – user123456
    Nov 27, 2015 at 18:27
  • \$\begingroup\$ Was your SPI connection some type of flying wires and a plug type proto board? On a decent PC board layout with GND plane and properly selected series termination resistors at the driver pins you should easily be able to get SPI working at 6.5MHz over longer trace lengths than 5 inches. On the other hand on a plug wire proto board there is so much coupling between things and extra capacitance to deal with that it is not surprising to run into problems at even these moderate frequencies. \$\endgroup\$ Nov 27, 2015 at 18:30
  • \$\begingroup\$ I dont know exact name of the connector. Its not plug type. Its something like bus connector \$\endgroup\$
    – user123456
    Nov 27, 2015 at 18:34
  • \$\begingroup\$ Michael is getting at is this a trace on a board, or hanging off somewhere. Also, do you have a bunch of other lines next to it? What else is in this circuit. \$\endgroup\$
    – mcmiln
    Nov 27, 2015 at 18:36

2 Answers 2


What you are usually dealing with is not length, but capacitance.

The push pull output stage of an SPI device has a maximum allowed load capacitance specified, and that capacitance varies with the speed you want to communicate at.

For example, think of a 3.3V device which output stage can source or sink 10mA maximum, and you want to work at 10MHz. Neglecting series resistances Q=CV holds. At 10MHz the period is 100ns so worst case scenario is that you need to fully (dis)charge a fully discharged(charged) capacitor in 50ns. Total charge your device can output is a function of time, i.e. Q=It, in 50ns our device can therefore output 10mA*50ns=500pC. Since you want V=3.3V you finally get C=Q/V=500pC/3.3V=151pF. That's a pretty realistic value.

What you can find in datasheets is then the maximum allowed capacitance, and cables (should) have a capacitance per meter specified. Please note that the device that needs to be driven also have an input capacitance, and that counts of course. If you have some 50pF/m cable and a 50pF input device you can see that maximum length is 2m. More than that and high and low voltages will start to degrade, up to the point where the push pull stage does not have enough time to drive the line and the receiving device would stop working.

But that's not the full story. There's another bad beast, and it is called cross talking. If you run two wires together and they are near, they form a capacitor. A sudden change in voltage on one of them would be present also on the other, and this is bad. Under the 100MHz range getting proper communication should be quite easy if your data and clock lines are far enough, or (better), shielded. Please note that shielding adds a lot of capacitance, so there's a tradeoff (surprise!).

A common mistake that also quite expert people do is running data and clock on twisted pairs, or run the traces on the PCB very close together. For SPI this is very, very bad and can decrease performances dramatically.

  • \$\begingroup\$ I agree with this, but lets see if we can fix it. Lower the speed, shorten the cables, and try to get less bulky connectors in there. See what happens. You should also be able to see the skew all these things give from an oscope. \$\endgroup\$
    – mcmiln
    Nov 27, 2015 at 18:48

Master -> slave SPI can go quite far because clock and data at the receiving end will always remain in sync to each other. In fact if you wanted to drive really remote DACs (for instance) you can convert the SPI clock&data into two lots of RS485, transmit it hundreds of metres, reconvert back to SPI at the far end and of course it works as good as RS485. But this is only in the master to slave transmission. Consider this: -

At the slave end, clock and data remain in sync and dutifully the slave (if it's an ADC) starts outputting data back to the master. It syncs its data output with the only clock it has (from the master) BUT, there may be several hundred nano seconds delay and there will be another several hundred nano seconds delay in the master seeing the return data from the slave. It's no longer very well synced up to the originating clock anymore and the link is busted good and proper.

I'm not saying it is this of course but be aware of it.


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.