0
\$\begingroup\$

I would like to connect 2 PCBs. On each PCB there is a MCU and each MCU is able to send and receive commands from the other one. Also, PCB1 should supply power to PCB2.

The 2 PCBs are separated by ~100cm and I'm wondering what kind of hardware connection/protocol I should use, knowing that I would like to limit the number of wires between the 2 PCBs.

My first guess was to use UART / RS232, so it can be full duplex, and probably fast enough:

  • 1 TX
  • 1 RX
  • 1 Vcc
  • 1 GND

I tested it, and it works (115200 baud rate), there's just a small ~20ms latency getting a reply when sending a request from PCB1 to PCB2. I limited the baudrate to 115200 because I don't want the connection to radiate.

So I was told I could use 2 additional wires and communicate using SPI (which sounded a bit unusual to me when connecting to external PCBs together), so I'm wondering if it's a good idea, what would be the drawbacks?

\$\endgroup\$
2
  • \$\begingroup\$ You haven't really given enough information to answer this... What kind of data rates do you need? What type of environment to the boards operate in? Do you need a bi-directional connection where both can initiate communication, or just a question-response type connection? \$\endgroup\$
    – Ron Beyer
    Commented Sep 10, 2019 at 14:37
  • \$\begingroup\$ What is your data size? What is your processing turn-around? How are you measuring this "latency" - is it from beginning of Tx or end of Tx? All these factors impact the thruput. Simply changing an interface might not help without this information. \$\endgroup\$
    – Soldersmoke
    Commented Sep 11, 2019 at 8:19

3 Answers 3

Reset to default
4
\$\begingroup\$

I tested it, and it works (115200 baud rate), there's just a small ~20ms latency getting a reply when sending a request from PCB1 to PCB2.

That latency is almost certainly nothing to do with the data rate of 115 kbaud. In 1 ms there can be 115 bits transmitted so, unless your message protocol requires thousands of bits, you are going to be stuck with that latency.

So I was told I could use 2 additional wires and communicate using SPI

and

On each PCB there is a MCU and each MCU is able to send and receive commands from the other one.

Not all that easily achievable if you are wishing to swap who is master and who is slave. I'd stick with UARTs and dump the RS232 bit - just use logic levels. SPI and UARTs will generate EMC and there's no getting away from the fact that for equal baud rates, the EMI will be very similar.

\$\endgroup\$
1
\$\begingroup\$

I wouldn't use SPI at one meter due to the fact MOSI pulse doesn't start until the slave receives the clock pulse but must reach the master before the next clock pulse. Just sayin'

It's also a pain since the link is always initiated and controlled from one end and dummy bits are required for the master to receive when it's not sending.

It's even trickier for the master to receive when sending (duplex communications). You have to take into account the previous command in your current transmission to interpret the data being received at the same time so it aligns properly since messages may be different lengths.

Also think about what this entails for communications where the slave might want to initate a transmission while the master is mid-transmission, or even when the master is just idle. The mid -transmission problem is the previous paragraph on steroids.

The beauty of UART is that it is really easy to synchronize (i.e. no need to synchronize data travelling both ways. Either side can just start talking whenever it wants.). I firmly stay away from SPI for this and stick to duplex UART (either RS232 or full duplex RS422/RS485).

If you are going to add 2 more wires anyways (4 signal wires total) just go with full duplex RS422/485 and crank up the baud and distance. I easily got several Mbps without trying and without termination and was mainly limited by my USB to UART converter which was required to snoop communications with my PC for debugging. Differential signalling reduces the radiation at higher baud too. You should be able to get at least a few Mbps at a meter or two, or three easily.

\$\endgroup\$
2
  • \$\begingroup\$ The clock doesn't make a round trip so I don't understand what you mean by the first sentence. Wouldn't the wiring delays be tens of nanoseconds at worst? What do you mean by "a pain"...don't we deal with this successfully all of the time? This doesn't sound like a technical reason to avoid SPI. \$\endgroup\$
    – Elliot Alderson
    Commented Sep 10, 2019 at 15:23
  • \$\begingroup\$ @ElliotAlderson Yeah, it was badly worded. A roundabout clock is actually the solution to the problem. I reworded it just now. And dummy bits are a pain compared to UART where none are required. \$\endgroup\$
    – DKNguyen
    Commented Sep 10, 2019 at 15:31
1
\$\begingroup\$

As others have noted, I would avoid SPI at that distance. However, if you want to link to be faster, I would recommend passing your UART signals through a full-duplex LVDS transceiver on each PCB. The differential signals will minimize radiated emissions, allowing your bit rate to increase significantly. Something like the DS90LV019 should meet your requirements. Just be careful that you don't try to increase your bit rate too much, or you will risk having to change your protocol to something that is DC-balanced (such as 8b/10b encoding).

You will also need to use twisted pair cable (such as Cat5e) and provide adequate termination at each end.

\$\endgroup\$

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.