I2C Communication in Details | Everything About I2C Communication.

Introduction

In this tutorial, you'll learn all about the I2C communication protocol, why you'd want to use it, and the way it's implemented.

The Inter-Integrated Circuit (I2C) Protocol may be a protocol intended to permit multiple "peripheral" digital integrated circuits ("chips") to speak with one or more "controller" chips. just like the Serial Peripheral Interface (SPI), it's only intended for brief distance communications within one device. Like Asynchronous Serial Interfaces (such as RS-232 or UARTs), it only requires two signal wires to exchange information.

Why Use I2C?

To figure out why one might want to speak over I2C, you want to first compare it to the opposite available options to ascertain how it differs.

What's Wrong with Serial UART Ports?

Block diagram of an asynchronous serial system.

Because serial ports are asynchronous (no clock data is transmitted), devices using them must agree before time on a knowledge rate. the 2 devices must even have clocks that are on the brink of an equivalent rate, and can remain soexcessive differences between clock rates on either end will cause garbled data.

Asynchronous serial ports require hardware overhead--the UART at either end is comparatively complex and difficult to accurately implement in software if necessary. a minimum of one start and stop bit may be a a part of each frame of knowledge, meaning that 10 bits of TRM are required for every 8 bits of knowledge sent, which eats into the info rate.

Another core fault in asynchronous serial ports is that they're inherently suited to communications between two, and only two, devices. While it's possible to attach multiple devices to one interface , bus contention (where two devices plan to drive an equivalent line at an equivalent time) is usually a problem and must be addressed carefully to stop damage to the devices in question, usually through external hardware.

Finally, rate is a problem . While there's no theoretical limit to asynchronous serial communications, most UART devices only support a particular set of fixed baud rates, and therefore the highest of those is typically around 230400 bits per second.

What's Wrong with SPI?

The most obvious drawback of SPI is that the number of pins required. Connecting one controller [1] to one peripheral [1] with an SPI bus requires four lines; each additional peripheral requires one additional chip select I/O pin on the controller. The rapid proliferation of pin connections makes it undesirable in situations where many devices must be connected to at least one controller. Also, the massive number of connections for every device can make routing signals harder in tight PCB layout situations.

SPI only allows one controller on the bus, but it does support an arbitrary number of peripherals (subject only to the drive capability of the devices connected to the bus and therefore the number of chip select pins available).

SPI is sweet for top rate full-duplex (simultaneous sending and receiving of data) connections, supporting clock rates upwards of 10MHz (and thus, 10 million bits per second) for a few devices, and therefore the speed scales nicely. The hardware at either end is typically a really simple register , allowing easy implementation in software.

Enter I2C - the simplest of Both Worlds!

I2C requires a mere two wires, like asynchronous serial, but those two wires can support up to 1008 peripheral devices. Also, unlike SPI, I2C can support a multi-controller system, allowing quite one controller [1] to speak with all peripheral [1] devices on the bus (although the controller devices can't ask one another over the bus and must alternate using the bus lines).

Data rates fall between asynchronous serial and SPI; most I2C devices can communicate at 100kHz or 400kHz. there's some overhead with I2C; for each 8 bits of knowledge to be sent, one extra little bit of meta data (the "ACK/NACK" bit, which we'll discuss later) must be transmitted.

The hardware required to implement I2C is more complex than SPI, but but asynchronous serial. It are often fairly trivially implemented in software.

[1] Note: you'll be conversant in the terms "master" and "slave" to represent the connection between devices on an I2C bus. The terms are considered obsolete and are now replaced with the terms "controller" and "peripheral," respectively.

Obsolete Name Replacement Name
Master Controller
Slave Peripheral

The naming convention may vary counting on manufacturer, programing language , companies, or organizations (e.g. main/secondary, initiator-responder, source/replica, etc.). For more information, inspect the subsequent links.

Wikipedia: Terminology Concerns
OSHWA: A Resolution to Redefine SPI Signal Names

A Brief History of I2C

I2C was originally developed in 1982 by Philips for various Philips chips. the first spec allowed for less than 100kHz communications, and provided just for 7-bit addresses, limiting the amount of devices on the bus to 112 (there are several reserved addresses, which can never be used for valid I2C addresses). In 1992, the primary public specification was published, adding a 400kHz fast-mode also as an expanded 10-bit address space. Much of the time (for instance, within the ATMega328 device on many Arduino-compatible boards), device support for I2C ends at now . There are three additional modes specified:

fast-mode plus, at 1MHz
high-speed mode, at 3.4MHz
ultra-fast mode, at 5MHz

In addition to "vanilla" I2C, Intel introduced a variant in 1995 call "System Management Bus" (SMBus). SMBus may be a more tightly controlled format, intended to maximise predictability of communications between support ICs on PC motherboards. the foremost significant difference between SMBus is that it limits speeds from 10kHz to 100kHz, while I2C can support devices from 0kHz to 5MHz. SMBus includes a clock timeout mode which makes low-speed operations illegal, although many SMBus devices will support it anyway to maximise interoperability with embedded I2C systems.

I2C at the Hardware Level

Signals

Each I2C bus consists of two signals: SCL and SDA. SCL is that the clock signal, and SDA is that the data signal. The clock signal is usually generated by the present bus controller; some peripheral devices may force the clock low sometimes to delay the controller sending more data (or to need longer to organize data before the controller attempts to clock it out). this is often called "clock stretching" and is described on the protocol page.

Unlike UART or SPI connections, the I2C bus drivers are "open drain", meaning that they will pull the corresponding signal line low, but cannot drive it high. Thus, there are often no bus contention where one device is trying to drive the road high while another tries to tug it low, eliminating the potential for damage to the drivers or excessive power dissipation within the system. Each signal line features a pull-up resistor thereon , to revive the signal to high when no device is asserting it low.

Equivalent internal circuit diagram of an I2C system.

Notice the 2 pull-up resistors on the 2 communication lines.

Resistor selection varies with devices on the bus, but an honest rule of thumb is to start out with 4.7kΩ resistor and adjust down if necessary. I2C may be a fairly robust protocol, and may be used with short runs of wire (2-3m). For long runs, or systems with many devices, smaller resistors are better.

Most I2C devices offered within the SparkFun catalog usually include pull-up resistors for the SCL and SDA pins. If you've got many I2C devices on an equivalent bus, you'll got to adjust the equivalent value for the pull-up resistors by disconnecting the pull-up resistors on a couple of of the devices.

Also Read :

counting on what's connected to the bus and therefore the design, you'll include about 7x I2C devices on an equivalent bus. However, if you're having any issues, you'll cut the 2 traces connecting to the middle jumper pad employing a n hobby knife or remove solder on the three jumper pads using a hand tool to disconnect the resistors on certain boards. As you'll see, the planning of the GPS board on the left used traces to attach the jumper pads for the pull-up resistors. the planning of the GPS board on the proper used solder to attach the jumper pads for the pull-up resistors.

Trace Connecting Jumper Pads Solder Connecting Jumper Pads

Trace Connecting Jumper Pads on the SAM-M8Q Solder Connecting Jumper Pads on the XA1110

If your design requires longer runs of wire, you'll use a fanatical IC to increase the signal like the PCA9615.

Qwiic Differential I2C Bus Extender (PCA9615) Hookup Guide

Signal Logic Levels

Since the devices on the bus don't actually drive the signals high, I2C allows for a few flexibility in connecting devices with different I/O voltages. generally , during a system where one device is at a better voltage than another, it's going to be possible to attach the 2 devices via I2C with none level shifting circuitry in between them. The trick is to attach the pull-up resistors to the lower of the 2 voltages. This only works in some cases, where the lower of the 2 system voltages exceeds the high-level input voltage of the the upper voltage system--for example, a 5V Arduino and a 3.3V accelerometer. counting on the planning of the Arduino or the I2C device, we recommend employing a logic level converter to be consistent and avoid damaging any device on the bus.

If the voltage difference between the 2 systems is just too great (say, 5V and 2.5V), SparkFun offers an easy I2C level shifter board — e.g. the PCA9306 Level Translator Breakout. This dedicated level shifter board the board also includes an enable line, it are often wont to disable communications to chose devices. this is often useful in cases where quite one device with an equivalent address is to be connected to one controller — Wii Nunchucks are an honest example. There also are bi-directional logic level converters which will be used.

Serial Communication in Details | Everything About Serial Communication