Use of Linux gpio to simulate I2C

 

I2c-gpio usage in Linux Kernel

 

In Linux, we can use gpio to simulate I2C on our own. However, I2C is also available in all-around Linux.

 

Now let's see what interfaces are provided in the i2c-gpio.c File

Static void initialize (void * data, int state) <br/> static void i2c_gpio_setsda_val (void * data, int state) <br/> static void i2c_gpio_setscl_dir (void * data, int state) <br/> static void i2c_gpio_setscl_val (void * data, int state) <br/> static int i2c_gpio_getsda (void * Data) <br/> static int i2c_gpio_getscl (void * Data) 

First, the above interface is quite clear. It is consistent with the interface implemented by ordinary gpio simulation I2C, which is the sda of the gpio and the settings of the SCL.

In the kernel/driver/I2C/algos/i2c-algo-bit.c is the default gpio simulation I2C framework code provided by the system.

 

Static inline void sdalo( struct i2c_algo_bit_data * ADAP) <br/> static inline void sdahi (struct i2c_algo_bit_data * ADAP) <br/> static inline void scllo (struct i2c_algo_bit_data * ADAP) <br/> static int sclhi (struct i2c_algo_bit_data * ADAP) <br/> static void i2c_start (struct merge * ADAP) <br/> static void i2c_repstart (struct merge * ADAP) <br/> static void i2c_stop (struct i2c_algo_bit_data * ADAP) <br/> static int i2c_outb (struct i2c_adapter * i2c_adap, unsigned char C) <br/> static int i2c_inb (struct i2c_adapter * i2c_adap) <br/> static int test_bus (struct i2c_algo_bit_data * ADAP, char * name) <br/> static int try_address (struct i2c_adapter * i2c_adap, <br/> unsigned char ADDR, int retries) <br/> static int sendbytes (struct i2c_adapter * i2c_adap, struct i2c_msg * MSG) <br/> static int acknak (struct i2c_adapter * i2c_adap, int is_ack) <br/> static int readbytes (struct i2c_adapter * i2c_adap, struct i2c_msg * MSG) <br/> static int bit_doaddress (struct i2c_adapter * i2c_adap, struct i2c_msg * MSG) <br/> static int bit_xfer (struct i2c_adapter * i2c_adap, <br/> struct i2c_msg msgs [], int num) <br/>/* ----- exported algorithm data: ----------------------------------- */</P> <p> static const struct i2c_algorithm i2c_bit_algo ={< br/>. master_xfer = bit_xfer, <br/>. functionality = bit_func, <br/> }; 

 

There is no stranger to any shoes that have performed gpio simulation I2C simulation. If you do not understand it, you can refer to the I2C protocol, which is clearer than I have said.

Here we will talk about the struct i2c_algorithm, in which master_xfer is the final called interface when we call i2c_master_send/i2c_master_recv.

 

The following describes how to use the Framework Code for this i2c-gpio

1, View the board. c file, first check where the I2C registration is registered in the system, add the following

Static struct i2c_gpio_platform_data i2c_bus_data ={< br/>. sda_pin = gpio103, <br/>. scl_pin = gpio102, <br/>. udelay = 20, <br/>. timeout = 100, <br/>. sda_is_open_drain = 1, <br/>. scl_is_open_drain = 1, <br/>}; <br/> static struct platform_device arch_device_i2c [] ={< br/>{< br/>. name = "arch-i2c-1", <br/>. id = 0, <br/>. num_resources = array_size (arch_resource), <br/>. resource = arch_resource, <br/>}, <br/>{< br/>. name = "arch-i2c-2", <br/>. id = 1, <br/>. num_resources = array_size (arch_resource), <br/>. resource = arch_resource, <br/>}, <br/> // Add <br/>{< br/>. name = "i2c-gpio", <br/>. id = 2, <br/>. dev = <br/> {<br/>. platform_data = & i2c_bus_data, <br/>}< br/>}, <br/> // end add <br/> }; 

 

 

Here we can see that there are two I2C in the system. Here, when platform_device is registered, the ID uses 2, and the device name is consistent with the name in the I2C gpio driver, that is, name in the i2c-gpio.c.

 

2, In a device that uses gpio to simulate I2C, You need to specify the I2C ID to know which device to use. In this way, the I2C bus where the device is located will be traversed during initialization and information such as the adapter of the device will be obtained, which will be used as normal I2C.

 

------------------------------------------------- Gorgeous split line ----------------------------------------------------------------------------

 

The differences between using gpio port to simulate I2C timing and using kernel module i2c-gpio virtual I2C bus:

 

1. Using gpio ports to simulate I2C timing does not need to register the I2C bus at system startup, but must be implemented independently in the I2C device driver. The i2c-gpio module virtual I2C bus requires a new I2C bus to be registered at system startup and the I2C device is mounted to the new I2C bus, which involves a wide range.

 

2. Use gpio ports to simulate I2C timing. Code operations are cumbersome and it is not convenient to mount multiple I2C devices. The i2c-gpio module can fully simulate the I2C bus and mount multiple devices.

 

3. During I2C read/write operations, the gpio port is used to simulate the I2C timing sequence. The device address <1 + 1/0 is sent each time based on the read/write operations, and the Register address is sent again. Using the i2c-gpio module is equivalent to operating directly on the I2C bus, the I2C BUS address has been told when the system starts mounting the I2C device, in the device's own driver, you only need to use the i2c_add_driver operation to obtain its address and many other information. Read and Write operations only need to send the Register address.

 

PS:

During I2C debugging, read the code to check whether it is consistent with your timing sequence. Remember.