I2C programming in embedded C


Share

Article background

In this article you will learn about Inter-Integrated Circuit(IIC/I2C) protocol, its theory of operation and practical applications.

Article Contents


Online courses related to this article


Course description

Learn firmware development theory, applications, get practical skills from online tests, projects and earn certificate for software jobs



Course description

Learn to develop embedded systems, interfacing electronic peripherals through real time projects and get required practical skills for software jobs



Course description

Learn to develop software solutions for linux environment, implement requirements through real time projects and get required practical skills for software jobs

What is I2C protocol?

The Inter-integrated Circuit (I2C) is a protocol intended to allow multiple “slave” digital integrated circuits (“chips”) to communicate with one or more “master” chips. I2C is ideal for attaching low-speed peripherals to a motherboard or embedded system or anywhere that a reliable communication over a short distance is required. I2C devices use only 2pins for data transfer instead of 8 or more pins for traditional buses. I2C devices provides a connection-oriented communication with acknowledge.

Transmitting and receiving the information step by step serially with respect to the clock pulses is called I2C protocol. It is an inter-system and short-distance protocol, which means, it is used within the circuit board to communicate the master and slave devices.

Like the Serial Peripheral Interface (SPI), it is only intended for short distance communications within a single device. Like Asynchronous Serial Interfaces (such as RS-232 or UARTs), it only requires two signal wires to exchange information. I2C protocol is referred to as Two-Wire Serial interface (TWI) in many application notes and datasheets.

Why I2C protocol is needed?

Because serial ports are asynchronous (no clock data is transmitted), devices using them must agree ahead of time on a data rate. The two devices must also have clocks that are close to the same rate and will remain so. Excessive differences between clock rates on either end will cause garbled data.

Asynchronous serial ports require hardware overhead: The UART at either end is relatively complex and difficult to accurately implement in software if necessary. At least one start and stop bit is a part of each frame of data, meaning that 10 bits of transmission time are required for each 8 bits of data sent, which eats into the data rate.

Another core fault in asynchronous serial ports is that they are inherently suited to communications between two and only two devices. While it is possible to connect multiple devices to a single serial port, bus contention (where two devices attempt to drive the same line at the same time) is always an issue and must be dealt with carefully to prevent damage to the devices in question, usually through external hardware.

Finally, data rate is an issue. While there is no theoretical limit to asynchronous serial communications, most UART devices only support a certain set of fixed baud rates, and the highest of these is usually around 230400 bits per second.

The most obvious drawback of SPI is the number of pins required. Connecting a single master to a single slave with an SPI bus requires four lines(MISO i.e. Master In-Slave Out, MOSI i.e. Master out-slave in, SCK i.e. Serial Clock , CS i.e. Chip Select). Each additional slave requires one additional chip select I/O pin on the master. The rapid proliferation of pin connections makes it undesirable in situations where lots of devices must be slaved to one master. Also the large number of connections for each device can make routing signals more difficult in tight PCB layout situations. SPI only allows one master on the bus, but it does support an arbitrary number of slaves (subject only to the drive capability of the devices connected to the bus and the number of chip select pins available).

SPI is good for high data rate full-duplex (simultaneous sending and receiving of data) connections, supporting clock rates upwards of 10MHz (and thus, 10 million bits per second) for some devices, and the speed scales nicely. The hardware at either end is usually a very simple shift register, allowing easy implementation in software.

I2C requires a mere two wires, like asynchronous serial but those two wires can support up to 1008 slave devices. Also unlike SPI, I2C can support a multi-master system allowing more than one master to communicate with all devices on the bus (although the master devices can’t talk to each other over the bus and must take turns using the bus lines).

Data rates fall between asynchronous serial and SPI. Most I2C devices can communicate at 100kHz or 400kHz. There is some overhead with I2C. For every 8 bits of data to be sent, one extra bit of meta data must be transmitted.

The hardware required to implement I2C is more complex than SPI, but less than asynchronous serial. It can be fairly trivially implemented in software. Examples of simple I2C compatible devices found in embedded systems today include EEPROMs, thermal sensors, ADCs and real time clocks.

The I2C protocol operates three modes such as: fast mode, high-speed mode and standard mode where in the standard mode data transfer rate is 100KHz, the fast mode data transfer rate 400KHz and the high speed mode data transfer rate 3.2MHz. The 9-bit data is sent for each transfer wherein 8-bits are sent by the transmitter MSB to LSB, and the 9th bit is an acknowledgement bit sent by the receiver.

How I2C protocol is implemented?

To Read Full Article

Start any course from the following


Want to contribute or ask a new article? Write and upload your article info .
Share