On any bidirectional bus, there is a risk that two (or more) devices may try to

Question

On any bidirectional bus, there is a risk that two (or more) devices may try to place different voltage levels on the bus at the same time. When interfacing with the LCD, this problem was overcome with tristate outputs. How does I2C overcome this problem? In other words, how does I2C handle bus contention (where two devices attempt to drive the same wire (the SDA line, for example) to different voltage levels at the same time)? What are the consequences of this design? Why wouldn’t a tristate solution (like the LCD interface) work for I2C?

Explanation / Answer

The I2C bus on the PDQ Single Board Computer (SBC) comprises an SDA bi-directional data line and an SCL bi-directional clock line; a shared ground connection among the devices is also required. This is an open-drain, multi-drop bus, meaning that multiple devices can be hooked to the bus and communicate with one another. Each device on a given I2C bus must have a unique even-number address between 0 and 254. The bus master transmits this address in the first byte of a message to identify the recipient of the message.

The I2C bus is best suited for communications over a short distance among a number of devices. Connecting to the I2C bus is simple: all the SDA data lines of the HCS12 and peripherals are tied together, and all the SCL clock lines are tied together, as shown on the following diagram. All devices must share a common ground.

Although the master device usually determines the clock speed, the slave also has a say in the matter. The I2C clock, SCL, can be controlled by both the master and the slave, so they aren't constrained to a predefined baud rate. Uunlike RS232/RS485, the clock speed can be changed by the slave, and the slave can even insert delays in communication.

Why is this needed? When the master is reading from the slave, it's the slave that places the data on the SDA line, but the master that initiates the clock pulses. But what if the slave isn't ready to send the next bit? With simple slave devices this usually isn't a problem, but when the slave device is itself a microprocessor with its own agenda, delays may be inevitable. To avoid a condition in which the master sends SCL clock pulses that the slave cannot respond to, the I2C protocol allows clock stretching — the slave may hold the SCL line low as long as necessary.

When it is ready, the slave releases the clock line, allowing it to be pulled high by the pull-up resistor. From the masters point of view, after finishing its assertion of a low clock pulse, it reads the SCL line to see if the clock has gone high. If not, the slave must be holding it low. The master then continues to monitor the SCL line and patiently waits until it is released by the slave before continuing. Not only must the master wait until it observes the clock line going high, but it must wait an additional minimum time (4 s for standard 100 kbit/s I2C) before it continues.

ERROR HANDLING:

Each I2C send and receive function returns an integer error value equal to 0 if the operation was completed successfully, and returns a bitmasked nonzero error value if an error occurred. For convenience, the returned error value is also stored in the 16-bit variable named IIC_ERROR. This system variable contains the 16-bit integer error result of the most recent I2C bus data transfer. IIC_ERROR is cleared at the start of each I2C send or receive operation. If the contents of this variable equal zero after an I2C data transfer, there was no error. If the contents are non-zero, then an error occurred.

Related Questions

Navigate

• Browse (All)
• Browse O
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.