A few words about addressing: We have mentioned earlier that devices on the bus have a unique address. This has a somewhat different meaning than the “addresses” discussed in the section on the 1- Wire bus protocol. An I2C product such as the SAA10642, which is an I2C compatible seven-segment LED display driver, has a 7-bit address, 5 bits of which are the same for all SAA1064 devices and 2 of which are user configurable. Thus, there are 5 fixed and two programmable bits, respectively. Since two are programmable, you can have 22 or four SAA1064 devices on a single I2C bus. Other device types may have more or less fixed and programmable address bits (still adding up to seven). On the SAA1064, the 2 configurable bits are controlled by assigning a voltage to an external pin.
Figure 11-4: Drawing illustrating the basic I2C bus configuration
Extensions to the basic concept
The I2C protocol has many more features and extensions than described here, such as faster speeds, 10-bit addressing, and multivoltage pull-up configurations. We’re not going to elaborate on them here. The best source for the complete story on I2C is the Philips I2C specification available on the Philips web site.
How TINI Does I2C
This next section examines how TINI communicates with devices over the I2C bus. We’ll talk first about the hardware involved and then discuss the I2Cport class in the TINI API.
TINI and I2C: Hardware
There are a couple of ways in which TINI can generate the I2C data (SDA) and clock (SCL) signals. The primary way is through the direct use of two specific pins on one of the microcontroller data ports. But TINI is also capable of generating I2C signals through memory-mapped I/O, where one bit of a specific memory location is used to generate SDA, and one bit from another memory location is used to generate SCL.
Direct use of microcontroller port pins for I2C
The simplest way to access I2C with TINI is through the use of Port #5, bit0 and bit1. These are often referred to as P5.0 and P5.1. These pins don’t always use the I2C protocol. In fact, they are actually designed to communicate using the CAN bus protocol. But, when used in conjunction with the I2Cport class found in the TINI API, they act as an I2C bus. These correspond to pins 21 and 20 on the TINI microcontroller and pins 10 (labeled CTX) and 11 (labeled CRX) on the TINI edge card connector. The CAN ports, such as Port 5 on the microcontroller, already have weak pull-ups built into them, so when using them to communicate I2C we haven’t found the need to put pull-ups on the SDA and SCL lines. If you experiment with TINI and I2C and you find that the bus isn’t being pulled high, your application may benefit from a stronger pull-up on the bus (20kΩ resistors to Vcc will do nicely).