[转]Comparing the I²C Bus to the SMBus
Comparing the I²C Bus to the SMBus
Abstract: The I²C bus and the SMBus™ are popular 2-wire buses that are essentially compatible with each other. Normally devices, both masters and slaves, are freely interchangeable between both buses. Both buses feature addressable slaves (although specific address allocations can vary between the two). The buses operate at the same speed, up to 100kHz, but the I²C bus has both 400kHz and 2MHz versions. Complete compatibility between both buses is ensured only below 100kHz. This application note focuses on the significant differences between I²C and SMB.
The I²C bus and the SMBus are popular 2-wire buses that are essentially compatible with each other. Normally devices, both masters and slaves, are freely interchangeable between both buses. Both buses feature addressable slaves (although specific address allocations can vary between the two buses). The buses operate at the same speed, up to 100kHz, but the I²C bus has both 400kHz and 2MHz versions. Obviously, complete compatibility between both buses using all devices is ensured only below 100kHz.
This application note focuses on the significant differences between the two buses. Although it is assumed that the reader has some knowledge of the I²C bus and/or the SMBus, let’s first review some protocol basics:
- Start and Stop events. These are especially important in that they are ways of signaling to an interface that it needs to go to an initialized or reset state.
- Data and Clock must be high to generate Start and Stop. A master can’t generate a Start or Stop unless both the Data (SDA for I²C and SMBData for SMBus) and Clock (SCL for I²C and SMBClk for SMBus) lines are free (not pulled low). This is a consequence of being an open-collector bus.
- Start and Stop conditions are the only times there will be a transition on the Data line while Clock is high.
- Data can change state only when Clock is low during a communication. The data on Data must always be ready just prior to a high on Clock and be changed only after Clock has gone low (with the exception of Start and Stop).
Figure 1. A typical communication, showing the Start and Stop conditions.
Timeout and Clock Speed
Timeout and (as a consequence of timeout) minimum clock speed are the most important differences between the I²C bus and the SMBus.
I²C Bus = DC (no timeout)
SMBus = 10kHz (35mS timeout)
Timeout is where a slave device resets its interface whenever Clock goes low for longer than the timeout, typically 35mSec. Use of a timeout also dictates a minimum speed for the clock, because it can never go static. Thus, the SMBus has a minimum-clock-speed specification. By comparison, the I²C bus can go static indefinitely. In the I²C bus, either a master or a slave can hold the clock low as long as necessary to process data.
All of this comes about as a result of how the two buses deal with slave errors and recovering from those errors. To understand error recovery, consider that there are two states, Start and Stop, which on a properly designed I²C or SMBus slave dictate that the slave interface go to a specific state. In the case of a Start, the interface should initialize itself and be ready to receive a communication. This should occur regardless of what preceded the Start condition (for example, if the slave was in the middle of a communication in which the master got confused and had to start over). In the case of a Stop, an interface should again initialize itself, but should be expecting a Start prior to any new communication. Both Starts and Stops are the only Data transitions that take place when Clock is high. In order for the transitions on Data to take place, the Data line (and the Clock line) must be "free" to allow the master to place highs and lows on the line as it needs.
In the I²C bus, if the slave locks up and holds either Clock or Data low, error recovery is impossible. Very few slave devices actually have the ability to hold Clock. As a result, the most common bus error is slave devices that have ended up in a state where Data (the data line) is low. In the I²C bus, a master accomplishes error recovery by clocking Clock until Data is high and then issuing a Start followed by a Stop.
In contrast to the I²C bus, SMBus slaves are expected to reset their interface whenever Clock is low for longer than the timeout specified in the SMBus specification of 35mS. As such, SMBus masters such as the Intel PIIX4 don’t have any error recovery routine built in. In reality, slave devices need to examine both Clock and Data, even though the SMBus specification doesn’t dictate that. This should be done, as experience has shown that slaves in an error state can hold Data low, even though Clock can be high. Implementing timeout exactly according to the SMBus specification doesn’t address this error mode.
Table 1. Considerations for Mixing Devices and Masters with Regard to Timeout
| I²C Slave | SMB Slave |