Difference between revisions of "Embedded System I2C Tutorial"
(→Protocol Information) |
|||
Line 33: | Line 33: | ||
A typical I2C write is to be able to write a register or memory address on a slave device. The protocol states that we will first send the slave address, then the memory address of the slave device, followed by the data to write to that memory address. To maximize throughput and avoid having to do this for each memory location, the memory address is considered "starting address". If we continue to write data, we will end up writing data to M, M+1, M+2 etc. | A typical I2C write is to be able to write a register or memory address on a slave device. The protocol states that we will first send the slave address, then the memory address of the slave device, followed by the data to write to that memory address. To maximize throughput and avoid having to do this for each memory location, the memory address is considered "starting address". If we continue to write data, we will end up writing data to M, M+1, M+2 etc. | ||
+ | |||
+ | The ideal way of writing an I2C driver is one that is able to carry out an entire transaction given by the function below. Note that the function only shows the different actions hardware should take to carry out the transaction, but your software should be state machine based as illustrated on the state machine diagram on the right. | ||
<BR/> | <BR/> | ||
Line 64: | Line 66: | ||
An I2C read is slightly more complex and involves more protocol to follow. What we have to do is switch from "write-mode" to "read-mode" by sending a repeat start, but this time with an ODD address. To simplify things, you can consider an I2C even address being "write-mode" and I2C odd address being "read-mode". | An I2C read is slightly more complex and involves more protocol to follow. What we have to do is switch from "write-mode" to "read-mode" by sending a repeat start, but this time with an ODD address. To simplify things, you can consider an I2C even address being "write-mode" and I2C odd address being "read-mode". | ||
+ | |||
+ | Again, the function shows what we want to accomplish. The actual driver should use state machine logic to carry-out the entire transaction. | ||
<BR/> | <BR/> | ||
Line 78: | Line 82: | ||
char data = i2c_read(0); // NACK if reading last byte | char data = i2c_read(0); // NACK if reading last byte | ||
− | /* | + | /* If we wanted to read 3 register, it would look like this: |
− | * | + | * char d1 = i2c_read(1); |
+ | * char d2 = i2c_read(1); | ||
+ | * char d3 = i2c_read(0); | ||
*/ | */ | ||
− | |||
− | |||
i2c_stop(); | i2c_stop(); |
Revision as of 22:27, 7 February 2014
Contents
Theory of Operation
I2C is prounced "eye-squared see". It is also known as "TWI" because of the intial patent issues of this BUS. This is a popular, low throughput (100-1000Khz), half-duplix BUS that only uses two wires regardless of how many devices are on this BUS. Many sensors use this BUS because of its ease of adding to a system.
Open-Collector BUS
I2C is an open-collector BUS, which means that no device shall have the capability of internally connecting either SDA or SCL wires to power source. The communication wires are instead connected to the power source through a "pull-up" resistor. When a device wants to communicate, it simply lets go of the wire for it to go back to logical "high" or "1" or it can connect it to ground to indicate logical "0".
Pull-up resistor
Using a smaller pull-up can acheiver higher speeds, but then each device must have the capability of sinking that much more current. For example, with a 5v BUS, and 1K pull-up, each device must be able to sink 5mA.
Protocol Information
I2C was designed to be able to read and write memory on a slave device. The protocol may be complicated, but a typical "transaction" involving read or write of a register on a slave device is simple granted a "sunny-day scenario" in which no errors occur.
The code given below illustrates I2C transaction split into functions, but this is the wrong way of writing an I2C driver. An I2C driver should be "transaction-based" and the entire transfer should be carried out using a state machine. The idea is to design your software to walk the I2C hardware through its state to complete an I2C transfer.
In the diagrams given below, your software should take the step given in the arrow, and the hardware will go to the next state granted that no errors occur. To implement this in your software, you should follow the following steps :
- Perform the action given by the arrow
- Clear the "SI" (state change) bit for HW to take the next step
- Wait for "SI" (state change) bit to set, then take the next action
Write Transaction
Code Sample | State Machine |
A typical I2C write is to be able to write a register or memory address on a slave device. The protocol states that we will first send the slave address, then the memory address of the slave device, followed by the data to write to that memory address. To maximize throughput and avoid having to do this for each memory location, the memory address is considered "starting address". If we continue to write data, we will end up writing data to M, M+1, M+2 etc. The ideal way of writing an I2C driver is one that is able to carry out an entire transaction given by the function below. Note that the function only shows the different actions hardware should take to carry out the transaction, but your software should be state machine based as illustrated on the state machine diagram on the right.
void i2c_write_slave_reg(void)
{
i2c_start();
i2c_write(slave_addr);
i2c_write(slave_reg);
i2c_write(data);
/* Optionaly write more data to slave_reg+1, slave_reg+2 etc. */
// i2c_write(data); /* M + 1 */
// i2c_write(data); /* M + 2 */
i2c_stop();
} |
Read Transaction
Code Sample | State Machine |
An I2C read is slightly more complex and involves more protocol to follow. What we have to do is switch from "write-mode" to "read-mode" by sending a repeat start, but this time with an ODD address. To simplify things, you can consider an I2C even address being "write-mode" and I2C odd address being "read-mode". Again, the function shows what we want to accomplish. The actual driver should use state machine logic to carry-out the entire transaction.
void i2c_write_slave_reg(void)
{
i2c_start();
i2c_write(slave_addr);
i2c_write(slave_reg);
i2c_start(); // Repeat start
i2c_write(slave_addr | 0x01); // Odd address
char data = i2c_read(0); // NACK if reading last byte
/* If we wanted to read 3 register, it would look like this:
* char d1 = i2c_read(1);
* char d2 = i2c_read(1);
* char d3 = i2c_read(0);
*/
i2c_stop();
} |