Introduction to I2C: Advanced topics
This presentation covers I2C clock stretching, bus arbitration, logic level translation, and selection of pull-up resistors on an I2C system. Timing specifications are also explained and used to derive the equations for the pull-up resistor. The issues that can occur if mixed supplies are used are covered and also how a level translator device can be used to solve these issues.
Resources
Hello and welcome to our in depth look at communications with precision data converters. In other I2C videos we describe some of the protocol basics of I2C and use an example to show how you might communicate with a precision data converter. With those videos you should be able to understand how I2C works and how to read and debug basic system communications. However, those videos only scratch the surface of the I2C protocol.
This video will cover some advanced topics of I2C. We won't go into too much depth, however we'll introduce some topics that will allow you to understand what they are when you come across them. This information can be found in the I2C bus specification, and you can find more details there.
The first I2C topic in this presentation is clock synchronization and arbitration between controller devices on the bus In I2C, there may be multiple controllers on the same bus. Because of this, there may be two or more devices trying to claim the bus for communication at the same time. This requires multiple active controllers to resolve which device controls the bus.
I2C uses a method of clock synchronization and arbitration to ensure that one controller that gains control and does so without compromising its communication. Because I2C uses open-drain connections to SDA and SCL, the connections result in a wired-AND connection where the line gives a logical AND of the device outputs. This is helpful in arbitration without disruption to the communication. In systems with only one controller, this arbitration isn't necessary.
We'll describe in detail how multiple controllers synchronize clocks for I2C communication. We'll also describe how controllers use arbitration to determine which controller wins the bus without disruptive contention. To prevent bus contention, clock synchronization is first performed using the SCL line in the open-drain during connections from the controllers on the bus. This wired-AND connection is low if any of the controllers pull SCL low. This connection is the logical AND of the two controller devices SCL connection. The output of SCL is high only if both controller devices have released the open-drain connection high.
A truth table of this logical wired-AND is shown in the lower right corner. During a START condition where two controllers are trying to claim the bus, there is a high to low transition on SCL. Here is an example where two controller devices are trying to claim the bus at or near the same time. Here, controller one device initiates a start condition shortly before controller device two does the same. Controller one pulls SCL down before controller to. With the wired-AND connection SCL pulls low as soon as controller one pulls down on SCL.
After the START condition, controller one releases SCL to go high. However controller two is still holding SCL low. Because of the wired-AND connection, SCL remains low until controller two releases the SCL high. At the same time, controller one is still monitoring SCL and must wait for the other controller to release the clock. Controller one cannot advance the SCL pulse until the SCL is available when controller two has released it.
When multiple controllers are competing for the bus, SCL stays low for as long as the longest period of time that any controller pulls down SCL. Only after all the controllers have released the SCL can the line be released high for the serial clock pulse. This synchronizes the start of the serial clock for all controllers.
For clock synchronization, each controller device must monitor the SCL line and react to cases where the SCL does not match its expected SCL output. Similarly after the start of the serial clock pulse all the controllers pull down on SCL to complete the serial clock pulse.
Again, with the wired-AND connection, SCL is then pulled down with the first controller that responds with pulling down SCL. The first controller that completes the SCL high time period determines the high time of SCL from the wired-AND connection. The synchronization of the SCL clock continues for subsequent clock pulses between all active controllers. Each SCL clock pulse is generated with its low period determined by the controller with the longest clock low period, and the high period is determined by the controller with the shortest clock high period. Again, clock synchronization works because the controllers monitor each pulse of the SCL line and react to cases where the SCL line does not match the state that the controller expects.
Now that the serial clocks are synchronized, arbitration is done on SDA, both controllers transmit data normally on SDA, sending their communication to the intended target device. Similar to SCL, SDA is a wired-AND connection. Both controllers also monitor SDA for the resulting communication. The first controller to transmit a low bit while the other controller transmit a high bit wins arbitration. With the wired-AND connection, the controller that wins arbitration does not have its communication disrupted. The controller device that loses arbitration stops its transmission, and the controller device that wins arbitration continues its communication uninterrupted.
In this method of arbitration, both controllers are transmitting data at the same time. The controller that matches the wired-AND result for SDA is the controller that wins arbitration. The controller that is disrupted by the wired-AND result for SDA stops transmission and releases the I2C bus.
The next topic in this presentation is clock stretching. It's not always the controller that controls the SCL serial clock. In some cases, the target device can slow down the communication. The next set of slides shows how target devices can use clock stretching to slow things down.
In general the SCL line, and therefore the I2C clock rate, is controlled by the controller. However, there may be times where the target device is unable to comply with the clock rate. The target device may need extra time to process a command or send data. In such cases, the target device may try to slow down the communication through clock stretching.
After a target device receives a byte of data in transmission, it may hold down SCL longer so that the controller is required to adjust the clock. This is similar to clock synchronization. The controller monitors SCL and is forced to extend the SCL pulse if it determines that SCL is still low after the controller has released it. If clock stretching is supported by the controller, any SCL pulse can be clock stretched by the target device. However, the general implementation of clock stretching is done with the SCL pulse around the acknowledge bit. According to the I2C specification, there is no time limit to the target holding down SCL for clock stretching. Other similar specifications like SMBus have time limits for how long SCL can be held low.
Here's an example of the target device clock stretching SCL. In this example, the controller issues a start and sends the target device address. When the target device recognizes the controller is sending the proper target address, the target device then begins to acknowledge the address. If the target device needs to slow down communications, it can pull down on SCL. This is the only instance the target device can control the SCL.
If the controller responds to clock stretching, it monitors SCL and sees that SCL remains low even though the controller has released SCL. Because of this, the controller cannot continue with the SCL pulse until the SCL is released by the target. The controller continues to monitor SCL. Once SCL is released high, the controller can then continue past the target devices acknowledge and continue with the next byte transmission. The resulting wired-AND connection of SCL shows the SCL stretched. Data transmission is delayed by the target device without disrupting communication.
The data sheet for every I2C device will have electrical and timing specifications that cover the characteristics for the I2C bus. Because I2C is a common protocol, these specifications should be matched from device to device.
This section, we'll discuss the electrical and timing characteristics and how they are shown in the I2C specification. We won't go into detail about each of the specifications. But we'll give an overview of how these specifications are organized.
Data sheets for I2C devices will cover what you need to operate our devices. However, you can search out the I2C specifications and read more about each of these characteristics. As an example, here we show table nine from the I2C specifications. This table shows the input-output characteristics for the I2C bus lines.
First, you can see from the columns that the specifications are different for different I2C speed modes. Minimums and maximums are listed for Standard Mode, Fast Mode, and Fast Mode plus. Because the devices operate at different speeds, these specifications are different to accommodate the differences in voltage and timing.
Highlighting some of the parameters, table nine gives specifications for low level and high level input and output voltages for SCL and SDA. This ensures that each I2C bus line has a voltage range that correctly transmits and receives high and low levels. This table also gives the minimum output current that the device open-drain pull down on SCL and SDA.
Table 10 of the I2C specification gives additional minimums and maximums for the SDA and SCL bus timing. The first key parameter gives the maximum SCL clock frequency for each of the I2C speed modes. Much of the rest of the table gives various setup and hold times for the SDA in relation to SCL There is also timing information for the start and stop conditions.
One last key parameter shows the maximum capacitive load allowed onto I2C bus lines. With the high signals based on pullup resistances, the load capacitance may determine the speed at which the I2C bus communicates. Later in this presentation, we'll show how this bus capacitance can be used to determine a range for the I2C pullup resistances.
In whatever I2C devices you use, these SCL and SDA bus line characteristics can be found in their respective data sheets. The data sheets will give enough of these characteristics to set up the device correctly. Again, for further information, you can search out the I2C specifications and read more about these characteristics.
Larger systems may have multiple power sources with multiple voltages. These different voltages may power different I2C controllers and target devices. Here we'll talk about voltage level translation and how these different I2C voltages may or may not interact.
One common problem with designing large systems is the mixing of different voltage levels within the system. For example, what happens when the controller and to the target device do not run on the same voltage? Mismatched voltages in the supply can disrupt communication or even damage a device. The connection of the pullup resistors determines if the output voltage of one overdrives or under-drives the input of the next device. Several examples can show some of the consequences of the mismatch.
Here's one example of supply mismatch with different I2C devices. In this example, the controller and the pullups are set to 3.3 volts while the target device is set to 5 volts. In the I2C specification, there are minimum and maximum voltages required for a digital input voltage to be accurately interpreted as a digital high or low. For example, the SDA and SCL are interpreted as a digital input low voltage when the input goes below the maximum 0.3 times VCC. Also, the SDA and SCL are interpreted as a digital input high voltage when the input goes above the minimum of 0.7 times VCC.
This latter specification is important for the mismatched supplies. With the pullups tied to the lower supply of 3.3 volts, the resistors are never able to pull up higher than the minimum required voltage of 3.5 volts. In this case, neither the SDA nor the SCL are insured to be interpreted as a digital high. This would potentially prevent communication between the devices.
Here's another example where the controller is set to 1.8 volts, but the pullups and the target device are set to 5 volts. In this example, the I2C bus lines are able to be pulled up to 5 volts, however the controller device may not accept voltages that high. If the difference between the device voltages are too great, the lower voltage device may be susceptible to damage.
Here's an example where the controller and pullups are set to 5 volts, but the target device is set to 3.3 volts. The I2C bus lines are able to be pulled up to 5 volts, exceeding the target device supply. However, the target device has inputs tolerant into higher voltages. This is a feature in some I2C devices. This may allow for direct connections between the I2C bus with pullups to the higher voltage supply. Check with the device data sheets for this possible feature.
The ADS1115 is just one device that has SDA and SCL lines that are tolerant to voltages higher than the supply. Looking at the absolute maximum table from the data sheet, the maximum digital input voltage is 5.5 volts regardless of the supply voltage. With this type of I2C line, the target device can tolerate pullup voltages higher than the supply. This allows for I2C communication between the devices even with different supply voltages.
With mismatched supply voltages, the best option may be to use a special device to bridge the two supplies. This figure shows an example of using an I2C voltage level translater to bridge the communication between two different supply voltages. There are two sets of pullups, one for each voltage level. As a common voltage translator, the PCA9306 allows for communication between different supply levels.
Another I2C advanced topic involves the pullup resistances required for I2C communication. To ensure that the bus speed is fast enough to meet the protocol bus speed, you may need to calculate values for the pullup resistances. In this section, we'll show how to calculate a minimum and maximum value for the pullup resistances based on the I2C specifications.
With the open-drain connections of SDA and SCL, transitions from these lines from high to low and from low to high are dependent on bus capacitance, current sync from the device connection, and the pullup resistor magnitude. The normal pullup resistor recommendation is one kiloohm to 10 kiloohms. However with higher resistances, the I2C communication is slower. With lower resistances, the I2C communication requires more power. Based on the several different parameters, we can calculate a minimum and maximum resistance for the I2C bus speed.
First, let's look at a table listing parametric characteristics from the I2C specifications. We can focus on the specifications for the standard mode. It lists the maximum rise time for the I2C bus, the maximum capacity of load on the bus, and it lists the low level output voltage, listed as VOL, which are given for different voltage levels for different speed modes of I2C. The table also lists the output current sunk by the device, which we'll call IOL. We'll use all of these parameters to help determine the pullup resistance values.
Here, we have an open-drain connection to the I2C bus, and we show the output waveform. The SDA and SCL bus transition low from the current pulling from the device. The positive supply is connected to the bus voltage VCC when the device releases the SDA or SCL line.
When active, the device drain pulls the bus line output to near ground. The output must drop to the output low level voltage, VOL. The device pulls the bus line low with current IOL. Based on this current, we can calculate the minimum resistance needed for the pullup. If the resistance is smaller, the output current can't pull the output voltage of the bus low enough to be recognized as a digital low. This is shown in the equation in the bottom right.
Then the open-drain connection releases the output current, and the resistors pull the bus connection high. The bus line output waveform shows an exponential rise. As the resistor pulls the voltage up from ground, the voltage settles based on the bus capacitance, CB.
The maximum pullup resistance is limited by the bus capacitance because of the I2C standard rise time specification. With the high resistance, the pullup output rises too slowly and may not reach the logical high fast enough. The equation for the exponential rise over time is shown with the pullup resistance. The rise time is based on the transition from the digital input low voltage of 0.3 times the supply voltage to the digital input high voltage of 0.7 times the supply voltage.
From the exponential equations, the rise time can be solved in terms of the maximum pullup resistance and to the bus capacitance. Again the rise time is based on the bus line's rise time from 0.3 times VCC to 0.7 times VCC. Using the equations developed over the previous few slides, we can calculate the minimum and maximum pullup resistance for a Fast Mode SCL communication bus In this example, we can calculate the minimum and maximum pullup resistance with a 200 picofarad bus capacitance and supply voltage of 3.3 volts.
Solving for the minimum pullup resistance, subtract the output low voltage of 0.4 volts from the supply voltage of 3.3 volts. Then divide by the current pulled by the bus line of three milliamps. This results in 967 Ohms. Then solve for the maximum bus resistance. Take the rise time of 300 nanoseconds and divide by the quantity of 0.8473 times 200 picofarads. This gives a maximum resistance of 1.77 kiloohms.
This may appear to be a narrow range, however this is because we've designed the pullup resistor sizing to operate with the high bus capacitance of 200 picofarads. If the design could ensure a lower bus capacitance, the maximum resistance could be increased, reducing the power dissipated on the I2C bus. For a more detailed description of I2C pullup resistor calculations, see application report SLVA689, I2C Bus Pullup Resistor Calculation by Rajan Arora.
The I2C specification discusses several other communications protocols based on I2C. These other protocols may be similar and compatible with I2C communication and may be used for specific applications. They may also have defined sets of commands and application specific extensions for their systems. Just as in the I2C specification, we'll briefly describe these other protocols, but we'll leave it to you to dig deeper into their systems, applications, and uses.
The first of these similar protocols is the System Management Bus, or SMBus. It is commonly used in servers and computer motherboards for power source management. It's very similar to I2C in the communication protocol and can be understood by an I2C controller.
This protocol has some additional features in comparison to I2C. First, it can dynamically set addresses allowing for quick communications at the start up of a system. Also, it has a 35 millisecond time out on the bus which prevents one device from indefinitely tying up the bus. It also has a packet error checking for error detection and data communication. There is also an additional line called SMBalert# that is used by target devices as an interrupt to tell the controller about certain events detected by the target device.
PMBus bus is basically a variant of SMBus defined by Intel and Duracell. It is used in the digital management of power supplies. This protocol also defines specific commands to retrieve data about voltage, current, and power in the system.
IPMI is another I2C based protocol used by a Baseboard Management Controller, or BMC. It uses a standardized message based interface for a computer motherboard or server. The BMC is always running, even when the main system is off. This allows for operation, measurement, and remote management of a system.
There are several other similar protocols discussed in the I2C specifications. ATCA is a follow on to compact PCI and used in rack mounted telecom hardware. DDC is a monitor or display information protocol that is used by hosts for control of display functions. Finally CBUS is another protocol that is derived from I2C. As mentioned in the reserved address section, it is no longer used.
That concludes this video. Thank you for watching. Please try the quiz to check your understanding of this video's content.
Question one, to prevent bus contention between controllers, I2C uses clock synchronization and then arbitration. How is arbitration done between controllers?
The correct answer is D, contending controllers synchronize clocks and continue communication. The first controller to send an SDA low bit that is not matched by the controller wins arbitration.
Question two, the PCA9306 is an example of what?
The correct answer is A, a voltage translator used to bridge devices with two different supply voltages.
Question three, which of the following parameters is not a factor in calculating the minimum and maximum values for I2C pullup resistors?
The correct answer is C, set up and hold times for SDA and SCL.
This video is part of a series
-
Precision labs series: Microcontroller communication
video-playlist (11 videos) -
Precision labs series: Analog-to-digital converters (ADCs)
video-playlist (94 videos) -
Precision labs series: Microcontrollers (MCUs)
video-playlist (23 videos)