I2C Device Driver standard implementation

I was writing a driver some time ago. It is an I2C bus device. so here we will briefly talk about some simple experiences about I2C device drivers. I believe there are many such articles on the Internet. let me add some bricks.

Start to get started.

I will not introduce the I2C protocol here. It is a half-duplex serial line with two wires, SDA-data line, and SCL-clock line.

SDA data is valid when the SCL is high. (To put it bluntly, it is acceptable. People know what you are. If the SCL is low, you are high and low, and the recipient thinks you are a fart)

The high value of the scl sda indicates that the bus is in the waiting state.

The high SDA of the SCL starts from high to low, and the transmission ends.

Each time the SDA transmits 1 byte of data, it must have an ACK at 9th bits. Low ack indicates that the response is okay, and high indicates that the response fails.

 

I2C is now divided into 7-bit address and 10-bit address, nothing more than a mounted device.

Today, we mainly develop seven-bit device addresses.

 

 

 

Let's get started.

1. At the beginning, you need to check the Design circuit diagram of the hardware and the read/write address of your I2C device. generally, this read/write address is 8 bits. For example, if 0x72 0x73 is the read/write address respectively, remove the last read/write mark (0/1) from the address of your I2C device, 0x39.

2. Find the platform initialization file in your kernel and find a struct in/kernel/ARCH/ARM/XX/xxx. C.

Struct i2c_board_info xx_i2c_info [] ={< br/>... <br/>{< br/>. type = "xxx_name", <br/>. ADDR = 0x39, // This is the address of your device <br/>. IRQ = xx_irq, <br/>. platform_data = xxx_data, // What hardware resources can be stored in this file, and the specific driver will be used. If not, forget it <br/>}, <br/>... <br/>}</P> <p>

Type_name must be the same as the name in the driver you are waiting.

The following figure shows platform_data, for example:

Static struct xxx_platform_data tsl2771_u802_data ={< br/>. IRQ = xxx, // hardware resources can be placed in this directory <br/>}< br/>

 

Okay platform has completed the preliminary test file.

 

Next, start the specific device. Generally, if it is an I2C device, you prefer to develop it under/driver/I2C/chips.

 

Start to build a basic driver framework. Needless to say, module_init module_exit.

Needless to say.

The driver generally starts with the _ init function.

 

Before this function, we must declare a struct.

Static struct <br/> i2c_driver xxx_i2c_driver ={< br/>. probe = xxx_probe, <br/>. remove = xxx_remove, <br/>. id_table = xxx_id, <br/>. driver ={< br/>. name = "xxx_name", // This is the string corresponding to the type mentioned above <br/>}, <br/>}; <br/>

 

Enter the _ init Function

I2c_add_driver (& xxx_i2c_driver); // similar to platform_diver_register, this is nothing more than matching the driver and device on the bus, and then Probe

 

 

All right, after matching, it's time to go to probe.

Static int _ devinit <br/> xxx_probe (struct i2c_client * client, const struct i2c_device_id * ID) <br/>{< br/> struct xxx_platform_data * pdata; // This struct is defined by yourself. The structure of the platform and the platform_data in the initialization file is consistent. <br/> pdata = client-> Dev. platform_data; // This is used to obtain your hardware resources <br/>}

Finished. What? What else? Well, if there are still some character device registrations, how can I automatically register the device contacts under/dev, such as/dev/XXX?

1 xx_class = class_create (this_module, "XXX); // register your device in sysfs class

2 Dev = mkdev ();

2 device_create (xx_class, null, Dev, null, "XXX", minor); this is done.

 

As for I2C read/write, I don't need to teach. i2c_smbus_read_byte_data (client, register)

I2c_smbus_write_byte_data (client, register, value) and so on.

 

 

I hope it will be helpful to you after finishing the work.