I2C Protocol – Solving I2C Address Conflicts
Today we would like to talk about I2C protocol, issues related to I2C bus conflicts and ways to address those issues. So, without further ado, let’s get to it.
What is I2C?
I2C stands for inter-integrated circuit also known as I2C or IIC. It is one of the most popular bus interfaces used for attaching various peripherals to a controller/CPU.
I2C is a synchronous, multi-controller and multi-target bus interface. Originally invented by Philips Semiconductors (currently NXP Semiconductors) in 1982, today I2C is widely used as a protocol for short-distance, intra-board communication of serial devices with each other.
Today I2C is the communication protocol of choice for various ICs manufactured by more than 50 companies. Some of the largest manufacturers of compatible I2C products are Siemens, Texas Instruments, STMicroelectronics, Motorola, NEC, Nordic Semiconductor and Intersil.
I2C uses only two bidirectional open-drain lines: serial data line (SDA) and serial clock line (SCL) for synchronous data communication. I2C protocol was originally designed to use 7-bit addressing and enable 100 Kbps communication between the chips on a printed circuit board (PCB). Over the years, however, I2C was updated for 10-bit addressing and faster data transmission, and today provides speeds up to 3.4 Mbit.
Being able to support multiple ICs on a single serial communication bus makes I2C perfect for a wide variety of applications in both consumer and industrial electronics.
I2C buses are used in a wide range of control architectures, including System Management Bus (SMBus), Advanced Telecom Computing Architecture (ATCA), Display Data Channel (DDC), Power Management Bus (PMBus), Intelligent Platform Management Interface (IPMI) and others. SMBus specifically is considered to be a subset of I2C that defines stricter usage of the protocol for better interoperability and higher speed.
Common I2C Applications
As we already mentioned above, due to the simplicity of implementation and its low cost, I2C protocol is widely used in modern-day electronic devices. Here are some of the most common applications for I2C communication protocol today:
- Communicating with different microcontrollers,
- Accessing DACs (digital-to-analog converters) and ADCs (analog-to-digital converters),
- Reading memory ICs,
- Reading hardware sensors,
- Connecting EEPROMs, I/O interfaces, and other parts of an embedded system,
- High-speed communication with a large number of peripheral devices,
- Directing and transmitting user-directed actions.
When it comes to specific devices using I2C, you can commonly find this protocol in various sensors (temperature, electrical voltage, etc.), real-time clock (RTC) chips, fan controllers, electric power supply solutions and many other types of control and measurement electronic devices.
Here are some examples of devices that use I2C protocol as a communication interface:
- Accelerometers
- Color sensors
- Gyroscopes
- Temperature sensors
- Humidity sensors
- Pressure sensors
- Analog-to-digital converters
- Authentication devices
- Power management ICs
- Magnetometers (compasses)
- Touch sensors
- Digital audio signal processors,
- LCD controllers and drivers,
- Decoder for satellite and cable TV
I2C Bus Conflicts
Being such a widely used protocol, I2C certainly has its fair share of issues and common problems.
As the I2C compatible modules and chips use7-bit addresses, one I2C bus can simultaneously support up to 127 devices on the same bus. Some of the addresses are so-called ‘general call addresses’ used to send messages to all devices on the bus. Also, every device on the I2C busmust have a unique address for correct master/slave communication.
One very common I2C issue occurs when putting multiple devices that share the same address on an I2C bus. When a large number of sensors and peripheral devices are connected to a single bus, it is possible that some devices will use the same address which would result in a conflict. This happens, for example, when connecting multiple SFP (small form-factor pluggable) connectors to a single I2C bus. As a result, the EEPROM device embedded in SFP transceiver will end up sharing the same 7-bit address with the other SFP transceivers on the bus.
Here are three common ways to address this problem that we would like to talk about in this article.
- Shared data line with dedicated clock lines for each device
If you have a microcontroller that can have multiple functions on the GPIO lines, one way to address this problem would be to share the data line across multiple I2C devices that have the same address, and then use a dedicated clock line to select every single device at a time.
In this case you are sharing the data line but and using individual clocks that requires reconfiguring the CPU pins, and can hardly be considered as an optimal solution. Also, this method is a bit sophisticated as it requires special support on the processor’s side to be able to reconfigure the pins. On the other hand, this is also the most cost-effective way as it does not require additional components.
- I2C MUX
Second, more generic approach to this problem is to use an I2C MUX, a multiplexing circuit able to connect slave devices with the same address to different communication buses, interchanging communication channels by programming the MUX.
With this method, one can simply spread the conflicting devices across the bus by using I2C MUX. It is also safe to say that using I2C MUX is the most straightforward and easy to implement solution to this problem.
- I2C Address Translator
The third way is to use an I2C Address Translator, a component designed to bridge two segments of an I2C bus, adding an offset to incoming addresses on the master side and retransmitting the updated address to the slave side. Using I2C Address Translator, allows replacing the hardwired address of one or more I2C slave devices with a different address.
This method also allows slave devices with the same hardwired address to operate on the same I2C bus. Using an I2C Address Translator may be considered a slightly inconvenient approach compared to the other two as it still leaves space for potential address conflicts within an I2C bus.
Final thoughts
It is extremely important to make sure that there are no I2C address conflicts on the bus. Having an I2C bus with an address conflict (they are often quite difficult to detect) can cause major problems and result in undefined behavior on the bus.
So it is highly advisable to take measures and make sure there are no I2C address conflicts within your system. The ideal solution is to put conflicting devices on different I2C buses, but this option is not always available which is why the ultimate goal should be achieving no I2C address conflicts by utilizing the least number of components.
The Tauro Technologies’ team of electronic engineers and designers has a proven track record of successfully designing custom hardware using I2C bus for various kinds of products. Drawing on the specific needs of our clients, we select and apply various engineering methods to electronic product development and manufacturing in order to achieve the desired result. Utilizing our in-house PCB assembly and debug expertise, we are able to build and evaluate your prototypes before high-volume manufacturing, rapidly and cost-efficiently.
Interested to know more? Get in touch with us for details.