7-i2C总线_mpu6050驱动编程
2017-02-03 15:24
274 查看
i2c总线协议:
历史:
是飞利浦公司在80年代,为研发音视频模块的通讯而产生。因其具有的诸多优点,而沿用至今。
优点:
1.简单性
2.有效性
3.多主控性。
i2c总线的信号:
1.起始信号:当scl保持高电平期间,sda由高到低跳变,称为起始信号。
2.结束信号:当scl保持高电平期间,sda由低到高跳变,称为结束信号。
3.数据位: 当scl保持高电平期间,sda保持电平稳定有效性,称为有效数据位。
3.应答信号:当scl保持高电平期间,当发送一个字节的数据后,必须要有对方的应答信号。
i2c总线使用几大原则:
a – 在SCL=1(高电平)时,SDA千万别忽悠!!!否则,SDA下跳则”判罚”为”起始信号S”,SDA上跳则”判罚”为”停止信号P”.
b – 在SCL=0(低电平)时,SDA随便忽悠!!!(可别忽悠过火到SCL跳高)
c – 每个字节后应该由对方回送一个应答信号ACK做为对方在线的标志.一般要由双方协议签定.
d – SCL必须由主机发送,否则天下大乱
e – 首字节是”片选信号”,即7位从机地址加1位方向(读写)控制.从机收到(听到)自己的地址才能发送应答信号(必须应答!!!)表示自己在线.其他地址的从机不允许忽悠!!!(当然群呼可以忽悠但只能听不许说话)
f – 读写是站在主机的立场上定义的.”读”是主机接收从机数据,”写”是主机发送数据给从机.
g – 7位IIC总线可以挂接127个不同地址的IIC设备,0号”设备”作为群呼地址.10位IIC总线可以挂接更多的10位IIC设备.
i2c总线的框架:
1.总线驱动层:主要数据结构是i2c_adapter和i2c_algorithm,总线驱动层完成总线控制器设备的软件实现,和i2c总线通信的方法等
2.i2c核心层:主要提供api给总线驱动层和设备驱动层,完成总线驱动层和设备驱动层之间的通信和匹配。
3.设备驱动层:主要数据结构是i2c_client和i2c_driver,完成从设备的硬件和软件框架功能的实现。
主要数据结构:
1.i2c_adapter:是描述i2c控制器的数据结构
2.i2c_algorithm: 是描述i2c控制器的通信方法,通俗讲就是i2c控制器的驱动部分
3.i2c_client: 是描述总线上从设备的硬件部分的数据结构
4.i2c_driver: 是描述总线上从设备的驱动部分的数据结构
5.i2c_msg: 是在i2c总线上传输的数据的格式
主要使用函数:
1.i2c_transfer:完成i2c总线上,主从设备之间的信号或者数据的发送和接收。
历史:
是飞利浦公司在80年代,为研发音视频模块的通讯而产生。因其具有的诸多优点,而沿用至今。
优点:
1.简单性
2.有效性
3.多主控性。
i2c总线的信号:
1.起始信号:当scl保持高电平期间,sda由高到低跳变,称为起始信号。
2.结束信号:当scl保持高电平期间,sda由低到高跳变,称为结束信号。
3.数据位: 当scl保持高电平期间,sda保持电平稳定有效性,称为有效数据位。
3.应答信号:当scl保持高电平期间,当发送一个字节的数据后,必须要有对方的应答信号。
i2c总线使用几大原则:
a – 在SCL=1(高电平)时,SDA千万别忽悠!!!否则,SDA下跳则”判罚”为”起始信号S”,SDA上跳则”判罚”为”停止信号P”.
b – 在SCL=0(低电平)时,SDA随便忽悠!!!(可别忽悠过火到SCL跳高)
c – 每个字节后应该由对方回送一个应答信号ACK做为对方在线的标志.一般要由双方协议签定.
d – SCL必须由主机发送,否则天下大乱
e – 首字节是”片选信号”,即7位从机地址加1位方向(读写)控制.从机收到(听到)自己的地址才能发送应答信号(必须应答!!!)表示自己在线.其他地址的从机不允许忽悠!!!(当然群呼可以忽悠但只能听不许说话)
f – 读写是站在主机的立场上定义的.”读”是主机接收从机数据,”写”是主机发送数据给从机.
g – 7位IIC总线可以挂接127个不同地址的IIC设备,0号”设备”作为群呼地址.10位IIC总线可以挂接更多的10位IIC设备.
i2c总线的框架:
1.总线驱动层:主要数据结构是i2c_adapter和i2c_algorithm,总线驱动层完成总线控制器设备的软件实现,和i2c总线通信的方法等
2.i2c核心层:主要提供api给总线驱动层和设备驱动层,完成总线驱动层和设备驱动层之间的通信和匹配。
3.设备驱动层:主要数据结构是i2c_client和i2c_driver,完成从设备的硬件和软件框架功能的实现。
主要数据结构:
1.i2c_adapter:是描述i2c控制器的数据结构
2.i2c_algorithm: 是描述i2c控制器的通信方法,通俗讲就是i2c控制器的驱动部分
3.i2c_client: 是描述总线上从设备的硬件部分的数据结构
4.i2c_driver: 是描述总线上从设备的驱动部分的数据结构
5.i2c_msg: 是在i2c总线上传输的数据的格式
主要使用函数:
1.i2c_transfer:完成i2c总线上,主从设备之间的信号或者数据的发送和接收。
/* * i2c_adapter is the structure used to identify a physical i2c bus along * with the access algorithms necessary to access it. */ struct i2c_adapter { struct module *owner; unsigned int class; /* classes to allow probing for */ const struct i2c_algorithm *algo; /* the algorithm to access the bus */ void *algo_data; /* data fields that are valid for all devices */ struct rt_mutex bus_lock; int timeout; /* in jiffies */ int retries; struct device dev; /* the adapter device */ int nr; char name[48]; struct completion dev_released; struct mutex userspace_clients_lock; struct list_head userspace_clients; struct i2c_bus_recovery_info *bus_recovery_info; }; /** * struct i2c_algorithm - represent I2C transfer method * @master_xfer: Issue a set of i2c transactions to the given I2C adapter * defined by the msgs array, with num messages available to transfer via * the adapter specified by adap. * @smbus_xfer: Issue smbus transactions to the given I2C adapter. If this * is not present, then the bus layer will try and convert the SMBus calls * into I2C transfers instead. * @functionality: Return the flags that this algorithm/adapter pair supports * from the I2C_FUNC_* flags. * * The following structs are for those who like to implement new bus drivers: * i2c_algorithm is the interface to a class of hardware solutions which can * be addressed using the same bus algorithms - i.e. bit-banging or the PCF8584 * to name two of the most common. * * The return codes from the @master_xfer field should indicate the type of * error code that occured during the transfer, as documented in the kernel * Documentation file Documentation/i2c/fault-codes. */ struct i2c_algorithm { /* If an adapter algorithm can't do I2C-level access, set master_xfer to NULL. If an adapter algorithm can do SMBus access, set smbus_xfer. If set to NULL, the SMBus protocol is simulated using common I2C messages */ /* master_xfer should return the number of messages successfully processed, or a negative value on error */ int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs, int num); int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, unsigned short flags, char read_write, u8 command, int size, union i2c_smbus_data *data); /* To determine what the adapter supports */ u32 (*functionality) (struct i2c_adapter *); }; /** * struct i2c_client - represent an I2C slave device * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address; * I2C_CLIENT_PEC indicates it uses SMBus Packet Error Checking * @addr: Address used on the I2C bus connected to the parent adapter. * @name: Indicates the type of the device, usually a chip name that's * generic enough to hide second-sourcing and compatible revisions. * @adapter: manages the bus segment hosting this I2C device * @dev: Driver model device node for the slave. * @irq: indicates the IRQ generated by this device (if any) * @detected: member of an i2c_driver.clients list or i2c-core's * userspace_devices list * * An i2c_client identifies a single device (i.e. chip) connected to an * i2c bus. The behaviour exposed to Linux is defined by the driver * managing the device. */ struct i2c_client { unsigned short flags; /* div., see below */ unsigned short addr; /* chip address - NOTE: 7bit */ /* addresses are stored in the */ /* _LOWER_ 7 bits */ char name[I2C_NAME_SIZE]; struct i2c_adapter *adapter; /* the adapter we sit on */ struct device dev; /* the device structure */ int irq; /* irq issued by device */ struct list_head detected; }; /** * struct i2c_driver - represent an I2C device driver * @class: What kind of i2c device we instantiate (for detect) * @attach_adapter: Callback for bus addition (deprecated) * @probe: Callback < e30f span class="hljs-keyword">for device binding * @remove: Callback for device unbinding * @shutdown: Callback for device shutdown * @suspend: Callback for device suspend * @resume: Callback for device resume * @alert: Alert callback, for example for the SMBus alert protocol * @command: Callback for bus-wide signaling (optional) * @driver: Device driver model driver * @id_table: List of I2C devices supported by this driver * @detect: Callback for device detection * @address_list: The I2C addresses to probe (for detect) * @clients: List of detected clients we created (for i2c-core use only) * * The driver.owner field should be set to the module owner of this driver. * The driver.name field should be set to the name of this driver. * * For automatic device detection, both @detect and @address_list must * be defined. @class should also be set, otherwise only devices forced * with module parameters will be created. The detect function must * fill at least the name field of the i2c_board_info structure it is * handed upon successful detection, and possibly also the flags field. * * If @detect is missing, the driver will still work fine for enumerated * devices. Detected devices simply won't be supported. This is expected * for the many I2C/SMBus devices which can't be detected reliably, and * the ones which can always be enumerated in practice. * * The i2c_client structure which is handed to the @detect callback is * not a real i2c_client. It is initialized just enough so that you can * call i2c_smbus_read_byte_data and friends on it. Don't do anything * else with it. In particular, calling dev_dbg and friends on it is * not allowed. */ struct i2c_driver { unsigned int class; /* Notifies the driver that a new bus has appeared. You should avoid * using this, it will be removed in a near future. */ int (*attach_adapter)(struct i2c_adapter *) __deprecated; /* Standard driver model interfaces */ int (*probe)(struct i2c_client *, const struct i2c_device_id *); int (*remove)(struct i2c_client *); /* driver model interfaces that don't relate to enumeration */ void (*shutdown)(struct i2c_client *); int (*suspend)(struct i2c_client *, pm_message_t mesg); int (*resume)(struct i2c_client *); /* Alert callback, for example for the SMBus alert protocol. * The format and meaning of the data value depends on the protocol. * For the SMBus alert protocol, there is a single bit of data passed * as the alert response's low bit ("event flag"). */ void (*alert)(struct i2c_client *, unsigned int data); /* a ioctl like command that can be used to perform specific functions * with the device. */ int (*command)(struct i2c_client *client, unsigned int cmd, void *arg); struct device_driver driver; const struct i2c_device_id *id_table; /* Device detection callback for automatic device creation */ int (*detect)(struct i2c_client *, struct i2c_board_info *); const unsigned short *address_list; struct list_head clients; }; struct i2c_device_id { char name[I2C_NAME_SIZE]; kernel_ulong_t driver_data; /* Data private to the driver */ }; /** * module_i2c_driver() - Helper macro for registering a I2C driver * @__i2c_driver: i2c_driver struct * * Helper macro for I2C drivers which do not do anything special in module * init/exit. This eliminates a lot of boilerplate. Each module may only * use this macro once, and calling it replaces module_init() and module_exit() */ #define module_i2c_driver(__i2c_driver) module_driver(__i2c_driver, i2c_add_driver, i2c_del_driver) /** * struct i2c_msg - an I2C transaction segment beginning with START * @addr: Slave address, either seven or ten bits. When this is a ten * bit address, I2C_M_TEN must be set in @flags and the adapter * must support I2C_FUNC_10BIT_ADDR. * @flags: I2C_M_RD is handled by all adapters. No other flags may be * provided unless the adapter exported the relevant I2C_FUNC_* * flags through i2c_check_functionality(). * @len: Number of data bytes in @buf being read from or written to the * I2C slave address. For read transactions where I2C_M_RECV_LEN * is set, the caller guarantees that this buffer can hold up to * 32 bytes in addition to the initial length byte sent by the * slave (plus, if used, the SMBus PEC); and this value will be * incremented by the number of block data bytes received. * @buf: The buffer into which data is read, or from which it's written. * * An i2c_msg is the low level representation of one segment of an I2C * transaction. It is visible to drivers in the @i2c_transfer() procedure, * to userspace from i2c-dev, and to I2C adapter drivers through the * @i2c_adapter.@master_xfer() method. * * Except when I2C "protocol mangling" is used, all I2C adapters implement * the standard rules for I2C transactions. Each transaction begins with a * START. That is followed by the slave address, and a bit encoding read * versus write. Then follow all the data bytes, possibly including a byte * with SMBus PEC. The transfer terminates with a NAK, or when all those * bytes have been transferred and ACKed. If this is the last message in a * group, it is followed by a STOP. Otherwise it is followed by the next * @i2c_msg transaction segment, beginning with a (repeated) START. * * Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then * passing certain @flags may have changed those standard protocol behaviors. * Those flags are only for use with broken/nonconforming slaves, and with * adapters which are known to support the specific mangling options they * need (one or more of IGNORE_NAK, NO_RD_ACK, NOSTART, and REV_DIR_ADDR). */ struct i2c_msg { __u16 addr; /* slave address */ __u16 flags; #define I2C_M_TEN 0x0010 /* this is a ten bit chip address */ #define I2C_M_RD 0x0001 /* read data, from slave to master */ #define I2C_M_STOP 0x8000 /* if I2C_FUNC_PROTOCOL_MANGLING */ #define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_NOSTART */ #define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */ #define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */ #define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */ #define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */ __u16 len; /* msg length */ __u8 *buf; /* pointer to msg data */ }; /*********************************************************************************** /** * i2c_transfer - execute a single or combined I2C message * @adap: Handle to I2C bus * @msgs: One or more messages to execute before STOP is issued to * terminate the operation; each message begins with a START. * @num: Number of messages to be executed. * * Returns negative errno, else the number of messages executed. * * Note that there is no requirement that each message be sent to * the same slave address, although that is the most common model. */ ``` *** ```int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)``` * 函数功能:完成i2c总线上,主从设备之间的信号或者数据的发送和接收。 * 返回值:成功为发送的msg个数,失败返回负数 * 参数1: 就是i2c总线所依赖的i2c控制器 * 参数2: 要传输的数据格式msg * 参数3: 呀传输的msg的个数 *** <div class="se-preview-section-delimiter"></div> ###### mpu6050驱动编程: * 1.确定需求: fs4412开发板所相连的mpu6050器件工作起来。并在应用层采集到数据。 * 2.查看原理图和数据手册,得知,mpu6050与exynos4412的i2c通道5相连,mpu6050的从地址是0x68 * 还有mpu6050的重要的控制寄存器和数据寄存器。 * 3.完成设备树的书写:描述两个重要设备信息: i2c5通道和从地址0x68 * 4.完成i2c_driver的框架编程。 * 5.完成封装两个重要功能函数,分别完成从mpu6050数据寄存器中读取数据和向mpu6050控制寄存器中写入数据的 功能。 * 6.完成字符设备8步流程,并且完成自动创建设备节点。 * 7.完成mpu6050控制寄存器的初始化。 * 8.完成file_operations中ioctl函数的实现。主要实现三种传感器的数据读取,并传递到应用层。 * 9.完成头文件,头文件中有寄存器的地址,ioctl中传递到应用层数据类型的定义,cmd格式的封装 * 10.完成测试程序,并到开发板上运行测试。 *** <div class="se-preview-section-delimiter"></div>
define SMPLRT_DIV 0x19 //采样率分频,典型值: 0x07(125Hz) */
define CONFIG 0x1A // 低通滤波频率,典型值: 0x06(5Hz) */
define GYRO_CONFIG 0x1B // 陀螺仪自检及测量范围,典型值: 0x18(不自检,2000deg/s) */
define ACCEL_CONFIG 0x1C // 加速计自检、测量范围及高通滤波频率,典型值: 0x01(不自检, 2G, 5Hz) */
define ACCEL_XOUT_H 0x3B // 存储最近的 X 轴、 Y 轴、 Z 轴加速度感应器的测量值 */
define ACCEL_XOUT_L 0x3C
define ACCEL_YOUT_H 0x3D
define ACCEL_YOUT_L 0x3E
define ACCEL_ZOUT_H 0x3F
define ACCEL_ZOUT_L 0x40
define TEMP_OUT_H 0x41 // 存储的最近温度传感器的测量值 */
define TEMP_OUT_L 0x42
define GYRO_XOUT_H 0x43 // 存储最近的 X 轴、 Y 轴、 Z 轴陀螺仪感应器的测量值 */
define GYRO_XOUT_L 0x44
define GYRO_YOUT_H 0x45
define GYRO_YOUT_L 0x46
define GYRO_ZOUT_H 0x47
define GYRO_ZOUT_L 0x48
define PWR_MGMT_1 0x6B // 电源管理,典型值: 0x00(正常启用) */
define WHO_AM_I 0x75 //IIC 地址寄存器(默认数值 0x68,只读) */
“`相关文章推荐
- I2C总线协议
- I2C协议详解
- I2C串行总线及串行EEPROM的扩展
- DOS命令中的cd
- WebSocket 和 Golang 实现聊天功能
- 《大话设计模式》26种设计模式Java代码整理(全)
- Java Transient用法
- Eclipse快捷键
- JAVA读取文件夹大小的几种方式
- 成员变量与局部变量、JavaDoc注释
- 我的编程经历与我所热爱的游戏服务端开发
- Struts2中 Result类型配置详解
- Qt学习笔记-更高级的文本编辑器-完善第一版-gif动画
- 2-驱动_加载函数_卸载函数_注册设备号_led驱动示例代码
- ROS Indigo版本的安装和配置
- Java基础之IO框架
- 1-系统移植_u-boot移植
- win10环境下python3.5安装步骤图文教程
- java中堆和栈的区别
- word2vec原理推导与代码分析