I2C驱动培训文档.docx

I2C驱动培训文档.docx

《I2C驱动培训文档.docx》由会员分享，可在线阅读，更多相关《I2C驱动培训文档.docx（34页珍藏版）》请在冰豆网上搜索。

I2C驱动培训文档

I2C驱动

1、协议

I2C总线是一种用于IC器件之间连接的双向二线制总线

I2C总线有两根信号线，一根为SDA（数据线），一根为SCL（时钟线）。

可发送和接收数据。

任何时候时钟信号都是由主控器件产生。

I2C总线在传送数据过程中共有三种类型信号，它们分别是：

开始信号、结束信号和应答信号。

　　开始信号：

SCL为高电平时，SDA由高电平向低电平跳变，开始传送数据。

　　结束信号：

SCL为高电平时，SDA由低电平向高电平跳变，结束传送数据。

应答信号：

接收数据的IC在接收到8bit数据后，向发送数据的IC发出特定的低电平脉冲，表示已收到数据。

CPU向受控单元发出一个信号后，等待受控单元发出一个应答信号，CPU接收到应答信号后，根据实际情况作出是否继续传递信号的判断。

若未收到应答信号，由判断为受控单元出现故障。

基本概念

主机初始化发送，产生时钟信号和终止发送的器件

从机被主机寻址的器件

发送器发送数据到总线的器件

接收器从总线接收数据的器件

多主机同时有多于一个主机尝试控制总线但不破坏报文

仲裁是一个在有多个主机同时尝试控制总线，但只允许其中一个控制总线并使报文不被破坏的过程

同步两个或多个器件同步时钟信号的过程

主机发送数据流程

（1）主机在检测到总线为“空闲状态”（即SDA、SCL线均为高电平）时，发送一个启动信号“S”，开始一次通信的开始

（2）主机接着发送一个命令字节。

该字节由7位的外围器件地址和1位读写控制位R/W组成（此时R/W=0）

（3）相对应的从机收到命令字节后向主机回馈应答信号ACK（ACK=0）

（4）主机收到从机的应答信号后开始发送第一个字节的数据

（5）从机收到数据后返回一个应答信号ACK

（6）主机收到应答信号后再发送下一个数据字节

（7）当主机发送最后一个数据字节并收到从机的ACK后，通过向从机发送一个停止信号P结束本次通信并释放总线。

从机收到P信号后也退出与主机之间的通信

注意：

①主机通过发送地址码与对应的从机建立了通信关系，而挂接在总线上的其它从机虽然同时也收到了地址码，但因为与其自身的地址不相符合，因此提前退出与主机的通信；

②主机的一次发送通信，其发送的数据数量不受限制。

主机是通过P信号通知发送的结束，从机收到P信号后退出本次通信；

③主机的每一次发送后都是通过从机的ACK信号了解从机的接收状况，如果应答错误则重发。

总线空闲状态

　　I2C总线总线的SDA和SCL两条信号线同时处于高电平时，规定为总线的空闲状态。

此时各个器件的输出级场效应管均处在截止状态，即释放总线，由两条信号线各自的上拉电阻把电平拉高。

启动信号

　　在时钟线SCL保持高电平期间，数据线SDA上的电平被拉低（即负跳变），定义为I2C总线总线的启动信号，它标志着一次数据传输的开始。

启动信号是一种电平跳变时序信号，而不是一个电平信号。

启动信号是由主控器主动建立的，在建立该信号之前I2C总线必须处于空闲状态。

重启动信号

　　在主控器控制总线期间完成了一次数据通信（发送或接收）之后，如果想继续占用总线再进行一次数据通信（发送或接收），而又不释放总线，就需要利用重启动Sr信号时序。

重启动信号Sr既作为前一次数据传输的结束，又作为后一次数据传输的开始。

利用重启动信号的优点是，在前后两次通信之间主控器不需要释放总线，这样就不会丢失总线的控制权，即不让其他主器件节点抢占总线。

停止信号

　　在时钟线SCL保持高电平期间，数据线SDA被释放，使得SDA返回高电平（即正跳变），称为I2C总线的停止信号，它标志着一次数据传输的终止。

停止信号也是一种电平跳变时序信号，而不是一个电平信号，停止信号也是由主控器主动建立的，建立该信号之后，I2C总线将返回空闲状态。

插入等待时间

　　如果被控器需要延迟下一个数据字节开始传送的时间，则可以通过把时钟线SCL电平拉低并且保持，使主控器进入等待状态。

一旦被控器释放时钟线，数据传输就得以继续下去，这样就使得被控器得到足够时间转移已经收到的数据字节，或者准备好即将发送的数据字节。

带有CPU的被控器在对收到的地址字节做出应答之后，需要一定的时间去执行中断服务子程序，来分析或比较地址码，其间就把SCL线钳位在低电平上，直到处理妥当后才释放SCL线，进而使主控器继续后续数据字节的发送。

总线封锁状态

　　在特殊情况下，如果需要禁止所有发生在I2C总线上的通信活动，封锁或关闭总线是一种可行途径，只要挂接于该总线上的任意一个器件将时钟线SCL锁定在低电平上即可。

总线竞争的仲裁

总线上可能挂接有多个器件，有时会发生两个或多个主器件同时想占用总线的情况，这种情况叫做总线竞争。

I2C总线具有多主控能力，可以对发生在SDA线上的总线竞争进行仲裁，其仲裁原则是这样的：

当多个主器件同时想占用总线时，如果某个主器件发送高电平，而另一个主器件发送低电平，则发送电平与此时SDA总线电平不符的那个器件将自动关闭其输出级。

总线竞争的仲裁是在两个层次上进行的。

首先是地址位的比较，如果主器件寻址同一个从器件，则进入数据位的比较，从而确保了竞争仲裁的可靠性。

由于是利用I2C总线上的信息进行仲裁，因此不会造成信息的丢失。

时钟信号的同步

在I2C总线上传送信息时的时钟同步信号是由挂接在SCL线上的所有器件的逻辑“与”完成的。

SCL线上由高电平到低电平的跳变将影响到这些器件，一旦某个器件的时钟信号下跳为低电平，将使SCL线一直保持低电平，使SCL线上的所有器件开始低电平期。

此时，低电平周期短的器件的时钟由低至高的跳变并不能影响SCL线的状态，于是这些器件将进入高电平等待的状态。

当所有器件的时钟信号都上跳为高电平时，低电平期结束，SCL线被释放返回高电平，即所有的器件都同时开始它们的高电平期。

其后，第一个结束高电平期的器件又将SCL线拉成低电平。

这样就在SCL线上产生一个同步时钟。

可见，时钟低电平时间由时钟低电平期最长的器件确定，而时钟高电平时间由时钟高电平期最短的器件确定。

i2c的有关图例：

参考博客:

二、iomux

IOMUXC指IO多路复用控制器。

由于imx6集成了很多的功能模块，BGA封装容纳不了那么多引脚，所以就想到用IOMUXC的方式来解决此问题，也即一个功能模块的引脚，通过n选1的多路开关，把需要的外设连接到该引脚上。

要使用哪个功能，就需要配置引脚参数。

在实际开发中，具体的配置是通过IOMUXC_SW_MUX_CTL_PAD_（BGAcontactNAME，比如UART3_RXD）寄存器来实现，然后通过配套的寄存器IOMUXC_SW_PAD_CTL_PAD_（PADNAME,比如UART3_RXD）来配置管脚的驱动电压，回转率，驱动强度，开漏，上拉，DDR类型等等。

下面通过一个具体实例，来让大家有个认识：

在linux或android系统中，假如我们要配置飞思卡尔IMX6处理器的GPIO管脚，比如是GPIO_19这个管脚，那么要像这样：

[cpp]viewplaincopy

1#defineMX6Q_PAD_GPIO_19__GPIO_4_5\

2（_MX6Q_PAD_GPIO_19__GPIO_4_5|MUX_PAD_CTRL（NO_PAD_CTRL））

其中_MX6Q_PAD_GPIO_19__GPIO_4_5定义为：

[cpp]viewplaincopy

3#define_MX6Q_PAD_GPIO_19__GPIO_4_5\

4IOMUX_PAD（0x0624,0x0254,5,0x0000,0,0）

这个IOMUX_PAD宏是定义GPIO的关键宏，其原型为：

[cpp]viewplaincopy

5#defineIOMUX_PAD（_pad_ctrl_ofs,_mux_ctrl_ofs,_mux_mode,_sel_input_ofs,

6_sel_input,_pad_ctrl）

IOMUX_PAD宏有6个参数，每个参数的意思是：

参数

含义

_pad_ctrl_ofs

控制寄存器的偏移地址（16进制）

_mux_ctrl_ofs

MUX控制寄存器的偏移地址（16进制）,用于选择引脚的功能

_mux_mode

MUX模式，bit0~3，范围0~7

_select_input_ofs

SELECT_INPUT寄存器偏移地址（16进制）

_select_input

DaisyChain模式,bit0~1,范围0~3

_pad_ctrl

bitstobesetinregister_pad_ctrl_ofsforconfigurationselection

具体的含义要结合IMX6数据手册【Chapter36IMOUXController（IOMUXC）】的内容。

下面看下IOMUX_PAD（0x0624,0x0254,5,0x0000,0,0）中参数的在数据手册中的位置，请看截图。

1、_pad_ctrl_ofs

从图中可以看到_pad_ctrl_ofs=0624h

2、_mux_ctrl_ofs、_mux_mode

如上图，_mux_ctrl_ofs取值为0x254，_mux_mode范围为000~110

只有_mux_mode=0时，_select_input_ofs和_select_input才有效，其余时候_select_input_ofs和_select_input都为0。

I2c2的复用

结合上边对iomux的介绍，参考原理图，

Tianqian

在Iomux工具中ball中查看U5

再查看下图标记部分

看完原理图，结合iomux工具，再参考数据手册，配置把U5复用为i2c2_scl功能

参考博客：

3、驱动

基本知识

在Linux内核源代码中的drivers目录下包含一个i2c目录，而在i2c目录下又包含如下文件和文件夹。

（1）i2c-core.c。

这个文件实现了I2C核心的功能以及/proc/bus/i2c*接口。

（2）i2c-dev.c

实现了I2C适配器设备文件的功能，每一个I2C适配器都被分配一个设备。

通过适配器访问设备时的主设备号都为89，次设备号为0～255。

应用程序通过“i2c-%d”（i2c-0,i2c-1,…,i2c-10,…）文件名并使用文件操作接口open（）、write（）、read（）、ioctl（）和close（）等来访问这个设备。

i2c-dev.c并没有针对特定的设备而设计，只是提供了通用的read（）、write（）和ioctl（）等接口，应用层可以借用这些接口访问挂接在适配器上的I2C设备的存储空间或寄存器，并控制I2C设备的工作方式。

（3）busses文件夹。

这个文件中包含了一些I2C总线的驱动，如针对S3C2410、S3C2440和imx等处理器的

I2C控制器驱动为i2c-imx.c。

（4）algos文件夹。

实现了一些I2C总线适配器的algorithm。

内核中的i2c.h这个头文件对i2c_driver、i2c_client、i2c_adapter和i2c_algorithm这4

个数据结构进行了定义。

理解这4个结构体的作用十分关键。

下面介绍下它们之间主要的关系和作用

1、i2c_adapter与i2c_algorithm，i2c_adapter对应于物理上的一个适配器，而i2c_algorithm对应一套通信方法。

一个I2C适配器需要i2c_algorithm中提供的通信函数来控制适配器上产生特定的访问周期。

缺少i2c_algorithm的i2c_adapter什么也做不了，因此i2c_adapter中包含其使用的i2c_algorithm的指针。

i2c_algorithm中的关键函数master_xfer（）用于产生I2C访问周期需要的信号，以i2c_msg（即I2C消息）为单位。

i2c_msg结构体也非常关键。

2、i2c_driver与i2c_client，i2c_driver对应一套驱动方法，是纯粹的用于辅助作用的数据结构，它不对应于任何的物理实体。

i2c_client对应于真实的物理设备，每个I2C设备都需要一个i2c_client来描述。

i2c_client一般被包含在I2C字符设备的私有信息结构体中。

3、i2c_adpater与i2c_client，i2c_adpater与i2c_client的关系与I2C硬件体系中适配器和设备的关系一致，即i2c_client依附于i2c_adpater。

思考问题1：

I2c总线设备和i2c总线上可挂载的i2c设备是在Board-mx6q-sarbed的initboard中初始化的，那么Board-mx6q-sarbed中initboard是从什么时候开始执行的呢？

我们知道内核启动的过程大致为以下几步：

1.检查CPU和机器类型

2.进行堆栈、MMU等其他程序运行关键的东西进行初始化

3.打印内核信息

4.执行各种模块的初始化

5.挂接根文件系统

6.启动第一个init进程

在4步骤之后，start_kernel--->rest_init

__initcall_start和__initcall_end在源码中并无定义,只是在include/linux/init.h中申明为外部变量。

arm平台下，连接控制脚本为vmlinux.lds,它们定义是在/arch/arm/vmlinux.lds中，看下图红色标记部分。

其含义是指示连接程序让__initcall_start指向代码节.initcall.init的节首，而__initcall_end指向.initcall.init的节尾。

在内核中，只要把需要初始化调用的函数的指针放在__initcall_start和__initcall_end之间的节内，函数就会在内核初始化时被调用。

加入到.initcall.init的代码段，是按如上方式调用的。

主要是各个驱动模块。

Machine_desc的是怎么加载的呢？

先看下面几个截图中红色标记部分：

由上图可以看到，成员函数init_machine就是在这里被调用的。

但是它没有被显式调用，而是放在了arch_initcall这个宏里，去看看它怎么定义的：

#definearch_initcall（fn）__define_initcall（"3",fn,3）

#define__define_initcall（level,fn,id）\

staticinitcall_t__initcall_##fn##id__used\

__attribute__（（__section__（".initcall"level".init"）））=fn

customize_machine（）被放到了.initcall3.init里。

理解：

在/include/linux/init.h文件中

#definepure_initcall（fn）__define_initcall（"0",fn,0）

#definecore_initcall（fn）__define_initcall（"1",fn,1）

#definecore_initcall_sync（fn）__define_initcall（"1s",fn,1s）

#definepostcore_initcall（fn）__define_initcall（"2",fn,2）

#definepostcore_initcall_sync（fn）__define_initcall（"2s",fn,2s）

#definearch_initcall（fn）__define_initcall（"3",fn,3）

#definearch_initcall_sync（fn）__define_initcall（"3s",fn,3s）

#definesubsys_initcall（fn）__define_initcall（"4",fn,4）

#definesubsys_initcall_sync（fn）__define_initcall（"4s",fn,4s）

#definefs_initcall（fn）__define_initcall（"5",fn,5）

#definefs_initcall_sync（fn）__define_initcall（"5s",fn,5s）

#definerootfs_initcall（fn）__define_initcall（"rootfs",fn,rootfs）

#definedevice_initcall（fn）__define_initcall（"6",fn,6）

#definedevice_initcall_sync（fn）__define_initcall（"6s",fn,6s）

#definelate_initcall（fn）__define_initcall（"7",fn,7）

#definelate_initcall_sync（fn）__define_initcall（"7s",fn,7s）

以上部分，在内核编译的时候就被加入到了代码段。

（/arch/armkernel/vmlinux.lds）

具体到我们这个例子，arch_initcall（customize_machine）也就是说customize_machine（）在内核编译的时候由arch_initcall（fn）放到了.initcall3.init里。

思考问题2：

那么这些被加入到代码段中的fn，是在哪被调用的呢？

回顾上面的内容，有提到过driver模块等是在/init/main.c里do_initcalls（）的函数里被调用。

再接着看，machine_desc加入了.arch.info.init代码段，它的函数调用关系：

start_kernel（）-->setup_arch-->setup_machine_tags-->for_each_machine_desc开始调用.arch.info.init代码段中的fn。

machine_desc的结构体的赋值如下图描述：

总结：

（这里主要说的是i2c和machine——）

各个i2cdevice或是其他驱动放在.arch.init代码段中，这些加入代码段的fn，会被do_initcalls（）调用，从/init/main.c文件中的开始内核代码谈起，调用顺序如下：

start_kernel-->rest_init-->kernel_init-->do_basic_setup（）-->do_initcalls（）

machine_desc加入了.arch.info.init代码段，它的函数调用关系：

start_kernel（）-->setup_arch-->setup_machine_tags-->for_each_machine_desc（）

I2c驱动的代码流程

结合上图，再联系前面提到的machine_desc和i2c的加载过程，可知：

首先，先将i2c总线作为platform设备加入到platform总线。

将i2c设别加到i2c总线上，值得注意的是i2c总线驱动还未加载。

接着，加载i2c总线驱动，也就是调用i2c_imx.c中的初始化函数i2c_adap_imx_init。

最后，加载i2c设备驱动，也egalaxtp驱动为例，即调用egalax_ts.c中的egalax_ts_init。

Dev下i2c设备节点

在查看开发板设备下我们发现存在：

那么i2c设备节点在那里创建的呢？

看如下截图，可知是初始化i2c_dev_init时，调用register_chrdev将i2c-dev加入一个map，这个map里有设备与操作的一一对应关系。

只要打开这个设备文件，我们就能使用它所定义的操作了。

节点是调用i2c_for_each_dev时，回调i2cdev_attach_adapter创建。

Platform下的i2c

是由platform创建的

主要的函数调用关系：

mx6_sabresd_board_init-->imx6q_add_imx_i2c->imx_add_platform_device-->imx_add_platform_device_dmamask-->platform_device_add，当platform_device_add执行时，它执行了如下图中操作：

整个探测过程完成后，回到device_add（）函数，接着通过klist_add_tail（）函数把设备imx-i2c.0挂到其父设备节点，也就是/sys/devices/platform。

下面在简单的分析一下平台设备驱动的注册过程，在i2c-imx.c中通过platform_driver_probe-->platform_driver_register（）注册i2c平台设备驱动

最后此函数通过调用driver_register（）函数对驱动进行注册。

具体的i2c设备的初始化

加载i2c设备驱动，以egalaxtp驱动为例，即调用egalax_ts.c中的egalax_ts_init。

下面截图是函数的调用关系，看红色标记部分（注意箭头方向，是向左的哦）。

接上图的i2c_register_driver

开始调用具体的驱动probe

如egalax就是：

执行到这，下边就会处理中断了。

（对于i2c来说主要是数据的收发，另外，上报给input子系统）

注：

适配器实现其通信方法，主要实现i2c_algorithm的master_xfer（）函数和functionality（）数。

master_xfer（）函数在适配器上完成传递给它的i2c_msg数组中的每个I2C消息

functionality（）函数非常简单，用于返回FUNC_I2C、I2C_

FUNC_10BIT_ADDR、I2C_FUNC_SMBUS_READ_BYTE、I2C_FUNC_SMBUS_WRITE_BYTE等。

思考问题3：

上面调用到了master_xfer（），那么它是在哪初始化的呢？

大家是否记得，文章的上面提到过，在加载i2c总线驱动时，调用i2c_imx.c中i2c_adap_imx_init函数对i2c_adapter的数据结构进行了初始化。

master_xfer（）也是在这初始化的。

具体情况情看下边截图，中红色标记的部分：

/sys/bus/i2c及/sys/bus/i2c/device和driver增加

I2c总线是在i2c-core.c中i2c_init-->bus_r