I2C (TWI) vs SPI EMI noise resistance

Question

I will be building the electronics and communication between a AVR MCU (ATMEGA328P) with another device (lets call it In-situ device), which probably will be located in a electromagnetic-noisy environment (motors, inductors etc).

The In-situ device is used to build a system of In-situ monitoring of dry etching process:

Something like this: https://www.plasmionique.com/plasma-etching

Or this:

The hookup is: PC -> ATMEGA_MCU -> In-situ device

I will make sure to build the PCB so that it will be as resistant as possible to EMI, but I will not be testing it to meet any ISO standards. I do not care about speed of data transmission, I would go with the lower speed possible to reduce the impact of noise in the communication.

I would use either CAN or Ethernet protocol for the communication, but the MCU does not have this feature build-in. So I want to try using its build-in features and see if there will be any issues with noise and disconnections (since this is not a critical or life-dependent project).

I read here, @r0ger101 says:

Since I2C tends to hang on noise on the bus, so you need timeout handlers to recovery the bus (disabling and reinitializing the I2C-hardware).

SPI needs very clever handshake managing to solve arbitration and to lose no data since SPI is unbuffered on the AVRs.

With this data only, I would go with the SPI. But:

Which of its other features (SPI or TWI/I2C) would be more noise-resistant?

Where would I look for data regarding the noise-resistance of these two protocols?

Answer 1

Neither I2C or SPI by themselves are great options for this. CAN, ethernet, RS-422 or RS-485 would all be better options by far for noise immunity (even RS-232 may be fine for many applications). There are CAN bus controllers that you can interface with over SPI that would be a good solution here

If you must use either I2C or SPI I would recommend SPI with shielded twisted wires (like an ethernet cable) to limit noise coupling onto a single signal. The timing requirements for SPI are also far looser than I2C, and you could possibly try to get strategic with termination resistors to get better noise immunity with SPI (more on this below)

In general for singe ended signaling, current driven signals (where there's a resistor on the receiving end that causes the voltage drop that is measured) will be more robust than a voltage driven signal, because a current driven signal will not be influenced as heavily by transient noise coupling on the line. I2C will suffer from the pullup resistors being placed closer to one end of the bus, which will help noise in one direction but not the other. You could look into adding termination resistors strategically onto the SPI lines so that the MOSI and SCK lines have termination near the slave device and the MISO line is terminated near the master. This may have implications on rise times or other aspects of SPI I'm not thinking of and you'd need to check the datasheets for the parts to ensure that you're not overloading the lines. This is also not going to be as good as a differential signal and ultimately I think more work trying to get right than just converting to another protocol meant to handle noisy environments.

Differential I2C and SPI

There are also options for I2C and SPI to drive them with differential signaling which will greatly improve their noise immunity:

I2C

https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4331.pdf https://hackaday.com/2017/03/31/an-introduction-to-differential-i%C2%B2c/

SPI

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

Answer 2

Neither SPI or I2C are robust in the presence of noise. On the other hand, UART in both directions over RS-422 or RS-485 will provide much better common mode noise immunity, and your protocol can be designed such that it can detect and recover from errors.

Your ATMega could possibly run SLIP or PPP, making it work as a networked device that would transfer packets, IP-style. Then you have some error recovery built-in.

More about SLIP and PPP here: https://ccm.net/contents/282-ppp-and-slip-protocols

If PPP seems too complex, you may wish to roll a simpler serial protocol yourself, or better yet, find an existing industrial UART protocol that leverages work in field controls that includes link integrity checking (e.g., Modbus-RTU.)

Answer 3

RS-422/RS-485 is pretty much the only viable option for a low-end MCU without CAN nor Ethernet.

Another option is UART over fiberoptic (Toslink or equivalent).

SPI is single-ended and not tolerant of common mode noise that's ubiquitous in RF plasma environments.

I2C is not only single-ended but also a relatively high impedance link, and is very much noise-intolerant. It's meant for use at the board level, or within a card cage at most. I2C is not meant to run on cables - it may work, but it usually is not very reliable and is only usable in development/diagnostic use, and not as a permanent means of communication in the field. It can be made to work, yes, but it's much harder than it needs to be. And UART is simpler anyway!

I believe that in your application the KISS principle applies. Keep it simple! Since you'll need error detection and retransmission probably anyway, PPP will be perfect for that purpose. It's standardized in RFCs, open source implementations exist, and it's easy to run a tiny IP stack on top of PPP, and maintain reliable end-to-end communications via TCP/IP.