Can I connect two microcontrollers via RS232 separated by a distance of 3.5 inches? Both are on two separate PCBs

Question

This design has two PCBs, each with a microcontroller. One can be said to be main and the other is a possible expansion if the user wishes to use it.

The microcontrollers will communicate via RS232 (RX, TX, CTS and RTS lines.)

Both boards will be joined by header type connectors.

The first option is to connect it directly, similar to this image:

The next option is to use an RS232 interface chip:

This second option I think that most will tell me that it is the best and recommended, but a third one occurs to me where I only use a buffer as an amplifier of the communication lines as follows:

Is this third option a good idea?

Answer 1

If the distance is really 3.5 inches, it is quite absurd to think that when connecting two UARTS together you must use RS-232 tranceivers. You don't need to use RS232 tranceivers and you don't need to use buffering. They can be used of course, but why would anyone connect two MCUs at 3.5 inches via RS232 tranceivers or buffers unless there is something we don't know.

Also neither TTL or RS232 levels will work unless the boards share common ground, but I suppose ground between boards exist but is not explicitly drawn in your diagrams.

Answer 2

No, your microcontrollers will not communicate using RS-232 unless you're using RS-232 levels, which only your second option does. What you mean with

(RX, TX, CTS and RTS lines)

is that they're using their UARTs, including RTS and CTS.

For your distance, the default (read: TTL) levels that your microcontrollers produce themselves are sufficient. Hence, go with your first option.

Using RS-232 transceivers is total overkill and a waste of power, and I don't see what benefit the CMOS buffering would have, either. If you're having trouble with noise, you'd probably want to switch to differential signaling instead, not just anything that's higher in levels like your options 2 and 3.

Answer 3

One thing not mentioned in the other answers, is that not only you don't need RS232 transceivers at such a short distance and so low speed, but the use of flow control signals is also a waste of MCU pins.

All you really need is TX, RX and ground.

UPDATE:

I'd like to elaborate on the use of flow control signals.

First, note that RTS/CTS signals wired per your schematic have nothing to do with RS-232. They are typical UART flow control signals.

The legacy RS-232 has RTS wired to RTS and CTS to CTS. They only work in one direction, i.e. to control data transfer from DTE to DCE (main board to expansion board in your case).

The RS-232-E extension has them cross-wired, however RTS signal is renamed to RTR (ready to receive), which is just another way of saying "clear to send".

Now, why one would use flow control with UART? The only reason for that is to allow slow MCU to deal with fast incoming data by telling transmitter to pause for a while. This is legitimate way of dealing with 3rd party devices with fixed baud rates. However when applied to you own devices on both sides of communication it is a clear indicator of bad design.

Note, that by pausing the transmission you reduce an effective throughput of the communication channel. Which means your chosen baud rate is wrong for the capabilities of your devices.

There is a simple rule of thumb for choosing the speed of communication in your own projects - Never pass the data faster than you can process it. Not only you eliminate the need in flow control, you most likely would have more reliable communication due to reduced baud rate.

Answer 4

Other answers correctly state that RS232 is almost certainly overkill, but you may be interested to know where this intuition comes from.

Your MCUs' UART pins have some specific drive strength, which is (roughly speaking) the current they're capable of sourcing or sinking. This current is used to change the voltage on the wire they're driving - all wires have capacitance, so to change their voltage, you must move charge onto or off of them. That's current.

The time it takes to change the cable's voltage is rise time and fall time, and is proportional to capacitance and inversely proportional to drive strength, with additional complicating factors (e.g. nonlinearity of the former factors, inductance at high frequencies) that make calculating rise/fall time difficult in practice without simulation or experimentation.

Ultimately the reason this is important is that if rise/fall time is too long, your MCU can't force the wire to the voltage it wants to send before the other MCU attempts to read that voltage, a problem that depends on baud rate (how fast you're switching voltages.) Different digital busses have different ways of establishing common timings, but the fundamental problem is the same.

Where the intuition that your MCU ports are sufficient comes from is that your wires are are 1's of inches long, and therefore analogous to the traces on a single PCB. It's safe to assume that the MCU manufacturer has chosen the drive strength of the UART pins to be enough to create short rise/fall times on typical PCB traces, short enough to drive the UART at its listed maximum baud. The intuition is social rather than mathematical - connecting MCUs inches apart is a central use case of a UART port, therefore it was probably designed to work.

If you had much longer wires - e.g. 1 meter long - the MCU drive strength may not be enough. That's where a product such as an RS232 transceiver would come in, by repeating the MCU signals at a much higher drive strength (and consequently, power usage.)