7-i2C总线_mpu6050驱动编程

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，只读) */

“`