![\"Multiple](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2015\/02\/Multiple-devices-on-one-I2C-bus-cropped.jpg\")
<\/a><\/p>\n
<\/p>\n
If the device that the host board is calling is on the line (pun intended), that device will respond with an acknowledge (ACK) bit by pulling the SDA line low. The slave device will then listen for the next command while all of the other devices that are also on the bus wait for another start condition before listening for their address again.\u00a0After 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.\u00a0Once 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.<\/p>\n
<\/p>\n
However, this all presumes that everything goes smoothly and the receiving device acknowledges the 8 bits of data by pulling the serial data line low. But what about when the data line is instead left at a high voltage state from the pull-up resistor? This would indicate that the data transfer was not acknowledged, implying that something was wrong with the data. Naturally, what exactly went wrong is dependent on when the NACK (a negative-acknowledge character) was read by the receiving device. The table below illustrates when a NACK might occur and what you could do about it.<\/p>\n
<\/p>\n <\/p>\n Within the\u00a0I\u00b2C protocol, the master device always retains control of the serial clock, driving the line low to indicate to the transmitting device that it should place a bit on the SDA line (blue bars)\u00a0and allowing the\u00a0line to go high telling the receiving device to read the bit on the SDA line (green bars).<\/p>\n <\/p>\n But because the only feedback that a transmitter receives is an ACK or NACK after 8 bits have already been transferred, there is no way for the master device to instinctively know if it is pulsing the SCL line too quickly for the slave device to place or read bits to or from the data line.\u00a0Luckily, the I\u00b2C protocol mitigates this problem through a feature called clock stretching.<\/p>\n <\/p>\n 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 (to ensure the receiver reads the bit on the data line) and subsequently driving the SCL line to a low voltage state.<\/p>\n <\/p>\n With the feature in I\u00b2C of\u00a0multiple devices being able to connect to the same\u00a0I\u00b2C 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. As\u00a0there is no way for any of the components on the line to instinctively “know” that there is another device also using the data line, this raises the possibility that a bus collision (literally) might occur.<\/p>\n <\/p>\n To avoid this breakdown in communication, all devices that are currently using the SDA\u00a0line 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.<\/p>\n![\"What](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2015\/02\/large-nack-table.jpg\")
<\/a>![\"\"](\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/6\/64\/I2C_data_transfer.svg\/600px-I2C_data_transfer.svg.png\"){kind=spacer}
![\"I2C](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2015\/02\/I2C-clock-stretching.jpg\")
<\/a>
![\"I2C](\"https:\/\/digilent.com\/blog\/wp-content\/uploads\/2015\/02\/I2C-arbitration.jpg\")
<\/a>