0
\$\begingroup\$

I have two MCUs and two wires between then. Currently these wires are used as I2C and work well, but we expect bursts of noise and want to protect against it. I am thinking of converting from I2C to RS485 or similar, but we have no space nor money for a separate transceiver chip.

Would there be advantages to implementing differential RS485-like protocol using just two GPIOs on each side with no other parts (except, may be, clamping diodes)?

There was a similar question Options for Differential transmission of digital signal but that was for a high precision synchronization signal, while I only need relatively low speed communication.

Thank you

PS: I was asking about advantages of "differential" (or complementary) GPIO vs other single ended digital protocols, not about comparison of GPIO vs real analog differential transceivers. Unfortunately, most of the answers focused on the latter.

\$\endgroup\$
13
  • 1
    \$\begingroup\$ How do you intend to implement differential signaling on bare GPIOs? What is the bit rate you hope to achieve? How long is the signal path between the MCUs and what is the characteristic of the noise you expect to design against? \$\endgroup\$
    – vir
    Commented Dec 30, 2022 at 21:25
  • 1
    \$\begingroup\$ You can drive RS-485 with GPIO, but without a true differential receiver on the other end, much of the benefit is lost. \$\endgroup\$
    – Dave Tweed
    Commented Dec 30, 2022 at 21:28
  • \$\begingroup\$ Why not uart? Are these chips on the same board? \$\endgroup\$
    – Bryan
    Commented Dec 30, 2022 at 21:32
  • \$\begingroup\$ @vir Modern MCUs, like STM32, have input/output channels, which allow you to generate almost any set of digital signals and record almost any signals. So, generating 2 opposite signals is trivial and reading 2 signals is also easy, while checking for difference in software. \$\endgroup\$
    – jhnlmn
    Commented Dec 30, 2022 at 22:03
  • 2
    \$\begingroup\$ It isn't RS485 without a proper 485 transceiver interface. \$\endgroup\$
    – Andy aka
    Commented Dec 30, 2022 at 22:29

4 Answers 4

5
\$\begingroup\$

Using two IO ports to receive a "differential" signal is not the same as using a dedicated differential receiver. A differential receiver subtracts two voltages, on two conductors, both of which will have roughly the same noise induced upon them. The common noise will be mostly cancelled as a result of the subtraction. The subtraction is an analogue operation, which yields an analogue result. Only then is this result compared with some mid-level potential to determine the corresponding digital high or low value.

When you deliver two digital signals to an MCU, the digital conversion is performed on each, before the MCU can do any kind of noise removal via analogue subtraction. Noise immunity would be no better than sending two consecutive digital bits concurrently.

I assume your MCUs are separated by a significant distance, and if you can't use differential line drivers/receivers then your best bet is to wrap the single-ended signal carrying conductor inside a shield grounded at both ends, like coaxial cable. At low data rates over distances up to a couple of metres, you probably don't need to worry about termination. You definitely should consider error detection and correction in software.

\$\endgroup\$
2
\$\begingroup\$

Without differential receiver (or at least something "better" than common GPIO) you won't get any real advantage.

When you have one signal connected to digital pin, from software point of view you have exactly two distinct states. You are reading either 0 or 1. And you have two faulty states (not counting burned MCU etc. :) ), signal sent as 0 being read as 1 and signal sent as 1 being sent as 0.

If you connect two pins in this "differential" (better say complementary) scheme, the four outcomes, two correct, two faulty, applies absolutely unchanged for each of these two inputs. And with same probabilities of bit-flips because each pin is connected and sensitive to disturbances independently of the other one.

Looking at the pair as whole, you only gain two extra input states for your software, namely seeing 11 or 00. In that case software knows the value is invalid, but has no way to correct the error (you do not know which bit was flipped).

So you gain some kind of error detection at the best. This could be nevertheless achieved in software only using CRC or other coding (i.e. hamming) giving not only detection but even error correction. Depending on the nature of your expected disturbances, data coding parameters can be tuned to provide likely better performance compared to adding second digital signal.

\$\endgroup\$
2
  • \$\begingroup\$ 1. What if I oversample? Say, 5 samples per bit? Would the extra complementary bit provide some advantage vs traditional FEC? 2. In single ended UART the start bit is especially vulnerable - if noise keeps triggering false start bits, then no amount of CRC/FEC would help. I thought that extra complementary bit together with oversampling may help detect/discard false start bits. \$\endgroup\$
    – jhnlmn
    Commented Dec 30, 2022 at 23:51
  • \$\begingroup\$ @jhnlmn Oversampling might help if you were sure that the aggressor signal was a little higher frequency than your clock rate since you could measure it and remove it. That's not too likely though, and you'd probably be better off just using a checksum or CRC. \$\endgroup\$ Commented Dec 31, 2022 at 3:07
1
\$\begingroup\$

No, two GPIOs won't have the common mode rejection of a true differential receiver like RS-485 as each GPIO is measured against circuit GND and not against the complementary GPIO.

But it's a good idea to get rid of I2C for off-board communication in a noisy environment. One disadvantage of I2C - from a noise immunity perspective - is the high-impedance logic high ("driven" only by the pull up resistors). So any physical layer without a high-impedance logic state might be an improvement regarding noise immunity.

\$\endgroup\$
0
\$\begingroup\$

The subtraction of the analog receiver is important for the noise reduction. But imho, the subtraction can be made in digital form as well.

Because the common mode noise will make both digital inputs 1 or 0 in the same time, while the transmitter will make them always different.

So, depending on the algorithms used, the noise can be detected and this way removed from the signal. But well, it is a matter of development. I have never hear about something like this implemented.

After all, the differential drivers are so cheap and solve the problem before the digital stages.

\$\endgroup\$
5
  • \$\begingroup\$ "I have never hear about something like this implemented". That's probably because it cannot be guaranteed to work over the range of common mode voltages that a properly designed RS-485 (or '422 for that matter) interface can. \$\endgroup\$
    – SteveSh
    Commented Dec 31, 2022 at 0:22
  • \$\begingroup\$ Yes, this was my idea (actually my coworker's idea) from the beginning. Question is whether it makes sense. Unfortunately, RS485 transceivers appear to be twice larger and twice more expensive than MCUs. \$\endgroup\$
    – jhnlmn
    Commented Dec 31, 2022 at 1:24
  • 1
    \$\begingroup\$ Some small MCUs do contain analog comparators, but usually without any hysteresis. Perhaps there's a way to configure them to serve as differential receivers. \$\endgroup\$
    – Dave Tweed
    Commented Dec 31, 2022 at 13:07
  • \$\begingroup\$ @jhnlmn: Well, it highly depends on the algorithms used, the level of the noise and the communication speeds you need. But some (many) experiments are mandatory. If you have a time to work on it - try. \$\endgroup\$
    – johnfound
    Commented Dec 31, 2022 at 13:31
  • \$\begingroup\$ @Dave Tweed Yes, modern MCUs often have differential ADC and comparators, but the current question is specifically about GPIOs. I guess that would be another question whether differential ADC or comparator can replace real differential receiver or not. \$\endgroup\$
    – jhnlmn
    Commented Jan 1, 2023 at 0:49

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.