Inter-integrated-circuit, more commonly known as I²C (generally pronounced I-squared-C), is a communication style originally developed by Phillips Semiconductor (now NXP Semiconductor). In this protocol, originally intended to be part of the "Imod Series", only two communication pins are used: a serial data line (SDA) which is shared by both the “master” and “slave” devices and a serial clock line (SCK) which the master controls. Both of these lines are natively held in a logic high position through the use of pull-up resistors.
I²C with its 7 or 10-bit addressing scheme offers the advantage of placing numerous devices on the single data and clock lines. A lone master is then able to start a communication session with a device by issuing a start condition and then submitting the address, as well as an indicator if it wants to read from or write to the device, on the SDA line to all of the listening devices. If the device that the host board is calling is on the line (pun intended), that device will respond with an acknowledge (ACK) bit leaving it to listen for the next command while the rest of the devices wait for another start condition before listening for their address again.
After receiving an ACK, the master can then tell the listening device which register address within the on-board chip that it wants to read from (or write). Once an additional ACK is received, confirming that particular action is permissible, data transmission between the two devices can occur.
In the widely used 9 bit communication style of I²C, a master will pull the SDA low while the SCL line is at a high voltage state (due to the pull-up resistor) as the “start” condition to indicate that it wishes to communicate with a slave device and then transmit two things; the 7 bit address of the slave it wishes to communicate with, and then either a read or write bit to show how it wants to communicate with the Pmod. To do so, the Serial Clock line will first be driven to a low voltage state and then the Serial Data line either driven to a low voltage state or left at an idling high voltage state. The SCL line will then released and allowed to go back to the idling high voltage state, indicating to the device that data is available to be read. After waiting a minimum amount of time to ensure that the receiver has seen the bit placed on the SDA line, the master is then free to repeat this process for the remaining 6 address bits and the read/write bit.
For the 9th bit, and the 9th clock signal, a slave with the matching address will send an acknowledge (ACK) bit on the SDA line by driving the line to a low voltage state to show that it is ready to communicate. If there was no slave with the 7 bit address, the SDA line would remain pulled up high during the 9th clock cycle and the master would interpret this as a not acknowledged (NACK) signal.
Presuming that a Pmod does send an ACK signal, 9 more bits would then be transferred; the first 8 bits will be transferred by the master letting the slave device know which internal register it wants to write to or read from. The slave device will then either acknowledge the request and allow the communication session to successfully continue, or leave the SDA idling high indicating that the requested action is not possible or the register address is invalid.
Once again presuming an ACK is received (we will get to what should happen if a NACK occurs soon), the transmitter (the master if a write command was issued or the slave if a read command was issued) will appropriately change the voltage level on the SDA line for each bit, although the master will maintain control of the Serial Clock line. After 8 bits of data have been transferred, the receiver will then pull the data line low to acknowledge the transfer or leave the line floating high to not acknowledge the transfer.
Once all of the desired data transfer has occurred (as determined by the user's preferences) the master may then issue a “restart” (pulling SDA low while SCL is idling high)to start a fresh communication session or should release the SDA line while SCL is high as its “stop” condition.
Ack! We've received a NACK!
So what does this NACK imply? This depends on when the NACK was received and which device sent the NACK. A table showing several different possibilities and a troubleshooting option is provided below:
|Ack! A NACK!|
|When we received the NACK||Who was transmitting data||What it means||What you can check|
|After the slave address||Master||No device with that address exists on this bus||The datasheet of the device for the correct address and which address the host is actually sending|
|After the command byte||Master||Invalid command||Does the sent register address exist? Also make sure that we're not trying to write to a read-only address|
|After the data transfer||Master||The receiving device will not be able to accept any more data||Restart or End the transmission to allow the device time to process the data and/or point to a different register address|
|After the data transfer||Slave||The master does not want to transfer any additional data||Issue a restart or end condition to relinquish control of the bus line|
Because multiple devices are able to be present on the I²C bus, there is a possibility that two masters might initiate start condition at the same time or have multiple slave devices that respond to a single address. However, there is no way for any of the components on the line to instinctively “know” that there is another device also using the data line.
Consequently, all devices that are currently using the communication line will go through Arbitration on every bit to determine if they have control of the line. This is done by having each device that may be trying to use the data line place their bit of data as they normally would (driving SDA low or leaving it to idle high) and then reading the voltage level on the line to see if it is what the device expects. If a device sees that the line has been driven low when it expects it to be idling high, it will conclude that another device must also be using the SDA line and subsequently relinquish control of the data line, losing arbitration.
The second device, which will see that the voltage level is as it expected, will continue transmitting its message although it will also continue to check the line after each bit in case there is another device that has happened to exactly match its bit values so far. When a master device loses arbitration, it will relinquish control of both the SDA and SCL line and wait for a stop condition before attempting to transmit its message again.
But what about if two devices match each others bit values for the entire duration of the communication session from the start bit to the stop bit? The question that the user then need to answer themselves is: is this actually a problem for my system?
It was mentioned earlier that the master device always maintains control of the Serial Clock within the I²C bus, designating where and when bits should be prepared and read by the receiving device. However, as there is no way for a device to instinctively know if there is another device on the bus, the master device will not be able to tell if it is clocking too quickly for the slave device to place or read bits to or from the data line. Luckily, the I²C protocol mitigates this problem through a feature called clock stretching.
Clocking stretching is the ability of a slave device to continue to drive the Serial Clock line low after the master device has already released the clock line to be pulled up to the high voltage state. This is used to guarantee the slave device enough time (as determined internally by the slave device) to read or prepare the next bit before the clock “ticks” again. In accordance with this, the master device waits for the Serial Clock line to actually reach the high voltage state before delaying a set amount of time and driving the SCL line to a low voltage state.
A timing diagram (courtesy of Wikipedia's I²C page) illustrating the major components of the I²C protocol is shown below:
- Here, you can see that a communication session begins with a start bit, where the SDA line is driven low while the SCL line remains high through the pull-up resistors.
- Once SCL is driven low by the master device, the SDA line is either driven low or left floating high to set the data bit level as shown by each of the blue bars.
- When the Serial Clock line reaches a high voltage level (after any clock stretching has been completed), the SDA line is then read by the receiving device to collect the data bit, as shown by each of the green bars.
- This process of SCL transistions and data bits being placed and read continues until a stop bit, indicated by the SDA being pulled high by the pull-up resistors while the SCL line is high, occurs.
Although this communication style is inherently not as fast as SPI because it only operates in half-duplex and requires consistent checking for arbitration, it is far easier to create a string or “daisy-chain” of I²C devices. This is because the Pmods that offer I²C communication styles have a 2×4 pin header for I²C allowing for a string of devices. Additionally, because the communication style is set up where the master calls out a slave address as opposed to selecting a specific slave on it's own line, only two Input/Output pins are ever needed for a I²C communication setup.