BMA2x2 三轴加速度计 Linux 驱动开发：从寄存器到设备树全解析

简介：BMA2x2驱动源码包面向嵌入式开发者，适用于智能手环、手机外设、工业监测等需采集运动数据的物联网场景，解决从底层寄存器初始化、数据读写到联合调试的完整开发问题。压缩包内共4个文件，包含2个C源文件、1个头文件和1个Markdown文档，合计仅45KB，结构清晰；C文件分别实现驱动主逻辑与外设支持接口，头文件定义寄存器映射和必要数据类型，README则提供编译和接线指引。已有175人学习下载，适合具备基础C语言与MCU开发经验、希望快速集成BOSCH BMA2x2传感器的开发者。通过这份驱动可掌握I2C/SPI通信模式的选择与配置、低功耗/正常等不同工作模式切换、采样率与灵敏度调整、加速度数据读取及校验等关键环节，并能根据示例代码快速验证传感器响应，为后续姿态识别、运动检测等应用开发缩短调试周期。

1. 打开 BMA2x2_driver-master.zip 之前，先看懂它在驱动什么

拿到“BMA2x2_driver-master.zip”的开发者，一般是从 GitHub 仓库点的 Download ZIP，文件名里的 master 是分支名。这个驱动对应的是博世（Bosch）的 BMA2x2 系列三轴加速度计，涵盖 BMA250、BMA222、BMA255 等型号，广泛用在手机、手环、开发板和姿态检测方案里。标题里既有“驱动下载”又有“联合开发”，说明这个包通常被两种角色使用：一类人直接拿来当现成驱动编译进内核，另一类人把它当作多人协作的代码底盘，继续改量程、改中断、改设备树。下面按“解包 → 结构 → 初始化 → 数据读取 → 验证”的顺序，把这份驱动从下载到跑通的全过程拆开讲，新手能照做，老手能看到寄存器、设备树与 I2C 时序上的坑。

2. 解包与源码结构：BMA2x2 驱动目录里每个文件干什么

压缩包在本地展开是第一步。我习惯先建一个干净的目录，再解压到里面，避免 zip 里的文件名直接散落到工作区。

mkdir -p ~/src/bma2x2 && cd ~/src/bma2x2 unzip ../BMA2x2_driver-master.zip cd BMA2x2_driver-master tree -L 2 .

解压后的目录结构在不同的仓库版本里会略有差异，但常见的是 4 到 6 个核心文件，外加一个 Makefile 和可能存在的 README。用 tree 能快速看到顶层布局。接下来先看每个文件在驱动里承担什么角色，再决定从哪里开始读代码。

拿到一套驱动不要急着编译，先确认它注册的是哪类驱动。BMA2x2 的老驱动多数走的是“字符设备驱动框架”：在 probe 里调用 register_chrdev 或 misc_register，生成 /dev/bma2x2 节点，用户态通过 read 拿原始加速度数据。这套写法在 Linux 3.x 时代很常见，好处是直接、好调试，坏处是和内核 sysfs 以及电源管理集成不紧密。新项目里如果内核版本比较新，社区更推荐把它改成 IIO（Industrial I/O）子系统驱动，统一用 /sys/bus/iio/devices/iio:device0 暴露数据。

驱动代码的阅读顺序我一般固定为：先看 bma2x2_driver.c 里的 probe，再往回追 bma2x2.c 暴露的 API。probe 是整个驱动的“亮灯”动作，它要做的事大致如下：

static int bma2x2_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct bma2x2_data *data; int ret; data = kzalloc(sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; >#define BMA2x2_CHIP_ID_REG 0x00 #define BMA2x2_DATA_REG 0x02 #define BMA2x2_RANGE_REG 0x0F #define BMA2x2_BW_REG 0x10 #define BMA2x2_PMU_LPW_REG 0x11 #define BMA2x2_SOFT_RESET_REG 0x14 #define BMA2x2_RANGE_2G 0x03 #define BMA2x2_RANGE_4G 0x05 #define BMA2x2_RANGE_8G 0x08 #define BMA2x2_RANGE_16G 0x0C

量程寄存器决定加速度数据的满量程范围。选量程的本质是在分辨率和量程之间找平衡：量程越大，单位 LSB 代表的 mg 值就越大，同样的板子震动下数值跳动也越明显；量程太小，设备稍一晃动就削顶饱和。常见选法是手持设备用 ±2g，车载和工业振动场景用 ±8g 或 ±16g。带宽寄存器则配合量程一起决定输出速率和噪声表现，带宽设得高，数据更新快但噪声大，低功耗项目一般压在 125Hz 以下。

初始化流程我一般按“软件复位 → 读 ID → 配置量程带宽 → 退出休眠”四步走。第一步必须做软件复位，否则芯片可能停留在上一次掉电时的未知状态，直接配置寄存器会写入失败。

static int bma2x2_init(struct bma2x2_data *data) { int ret; /* 软复位，让芯片回到已知状态 */ ret = i2c_smbus_write_byte_data(data->client, BMA2x2_SOFT_RESET_REG, 0xB6); if (ret < 0) return ret; msleep(50); /* 复位后需要等待内部上电稳定 */ /* 读回 chip ID，确认 I2C 通、芯片型号没搞错 */ ret = i2c_smbus_read_byte_data(data->client, BMA2x2_CHIP_ID_REG); if (ret < 0) return ret; dev_info(&data->client->dev, "BMA2x2 chip id = 0x%02x\n", ret); /* 配置带宽和量程，顺序上先带宽后量程 */ i2c_smbus_write_byte_data(data->client, BMA2x2_BW_REG, 0x0D); /* 125Hz */ i2c_smbus_write_byte_data(data->client, BMA2x2_RANGE_REG, BMA2x2_RANGE_2G); return 0; }

这段代码里的 msleep(50) 是不可省略的等待时间。软复位命令发出后，芯片内部时钟和传感器偏置需要时间重新建立，读得太快会读到 0x00 或者不稳定值。带宽寄存器写 0x0D 是很多开源驱动里默认对应 125Hz 输出频率的写法，但不同型号的低三位定义有差异，不能照抄，要看手册确认。量程配置放在带宽之后，是避免带宽切换造成的内部状态波动覆盖量程设置。

这个环节最容易出问题的是 I2C 地址。BMA2x2 的 7 位 I2C 地址常见是 0x18，SDO 引脚拉高后变成 0x19。设备树里 reg 写 7 位地址，i2cdetect 显示的也是 7 位地址，但 i2c_smbus_read_byte_data 这类内核 API 内部会自动左移一位拼上读写标志位。如果设备树写成了 0x30，那就把 8 位地址填进去了，总线扫描会看到地址但 probe 永远匹配不上。

低功耗模式是另一个容易忽略的点。BMA2x2 有 normal、suspend、deep suspend 和 standby 等多种电源状态，如果芯片停在 suspend，写量程寄存器不一定报错，但 acceleration data 寄存器读出来一直是 0。调试时遇到“读 ID 正常、数据全零”的情况，优先检查 0x11 寄存器的电源配置位，把芯片切回 normal 模式再看数据。linux 驱动开发里这类“初始化后无数据”的问题，十有八九是电源状态没查干净。

4. 数据读取、中断与设备树：把 BMA2x2 驱动挂进你手里的板子

驱动初始化的下一步，是把 BMA2x2 真正接到实际系统的总线上。以 i2c1 为例，设备树节点通常长这样：

&i2c1 { status = "okay"; clock-frequency = <400000>; bma2x2@18 { compatible = "bosch,bma2x2"; reg = <0x18>; interrupt-parent = <&gpio1>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; vdd-supply = <&reg_3v3>; vddio-supply = <&reg_1v8>; }; };

compatible 字符串是驱动代码里 of_match_table 匹配的关键，驱动里写“bosch,bma2x2”，设备树里必须一字不差。reg 是前面说的 7 位地址。interrupts 指定了加速度计的中断脚接到了主控的哪个 GPIO，BMA2x2 的 INT1 通常是开漏输出，外部需要上拉电阻，设备树里配 LEVEL_LOW 而不是 EDGE_FALLING，可以避免中断脚低电平时边沿触发漏中断。vdd-supply 和 vddio-supply 看实际板子是否做了电源域控制，没做的话这两行删掉不影响功能。

设备树就绪后，数据读取的函数是整个驱动里应用层最关心的部分。加速度数据寄存器从 0x02 开始连续排列，六个字节分别对应当前 X、Y、Z 轴的低位和高位：

static int bma2x2_read_accel_data(struct bma2x2_data *data, int16_t *ax, int16_t *ay, int16_t *az) { u8 buf[6]; int ret; /* 一次 I2C 读，把 6 个数据字节全部取回来 */ ret = i2c_smbus_read_i2c_block_data(data->client, BMA2x2_DATA_REG, 6, buf); if (ret < 0) return ret; /* 组合高低字节，注意要转成有符号数 */ *ax = (int16_t)((buf[1] << 8) | buf[0]); *ay = (int16_t)((buf[3] << 8) | buf[2]); *az = (int16_t)((buf[5] << 8) | buf[4]); return 0; }

这里最关键的是符号扩展。加速度计的数值是二进制补码，把两个字节拼起来后如果最高位是 1，必须转成 int16_t 再做算术右移，否则原始值会被当成无符号正数，静止时在某个轴向上会读到 65535 附近的异常值。拼好后的原始 LSB 数值再乘以灵敏度系数，才是最终的 mg 值。

轮询读数据在大多数场景下够用，但低功耗或者运动唤醒场景一般要走中断。中断模式下芯片检测到运动超过阈值，INT1 拉低触发主控 GPIO 中断，驱动在中断处理里用 workqueue 延后读取数据，避免在中断上下文里睡 I2C。BMA2x2 的中断配置需要操作中断使能寄存器和阈值寄存器，不同型号阈值默认单位不一样，有的是 mg，有的是 LSB，这里是对着手册比较容易出偏差的部分。

多人联合开发时，BMA2x2 驱动最常见的协作点有两个：一是寄存器宏定义可能被其他人为了适配别的型号改掉了，git diff 里看到量程宏变化要警惕；二是应用层接口约定，比如数据方向的正负号约定，同一条 I2C 总线上不同板子安装方向不同，应用层如果按固定方向解算，驱动层改动会直接影响姿态算法结果。建议在驱动头文件里明确写入轴方向注释，并在提交信息里标注寄存器变更的型号依据。

5. 三招快速验证 BMA2x2 驱动：从寄存器到用户态一条线

驱动编译加载后，先用 i2c-tools 直接从用户态读寄存器，绕开内核代码，确认硬件链路本身没问题。

i2cdetect -y 1 i2cget -y 1 0x18 0x00

第一行扫描 i2c-1 总线上所有地址，能看到 0x18 说明芯片应答了。第二行直接读 chip ID 寄存器，BMA250 系列常见返回值是 0xF9，BMA255 系列常见 0xFA，不同批次和型号返回值不同，只要稳定且非 0x00、0xFF，就说明 I2C 链路、电源和地址都没问题。

第二招是验证数据寄存器会随姿态变化。拿一块开发板分别保持水平、左倾、右倾，执行 i2cget 读 0x02 到 0x04 的低字节：

i2cget -y 1 0x18 0x02 i2cget -y 1 0x18 0x03 i2cget -y 1 0x18 0x04

正常状态下三个轴至少有一个值有明显跳变。如果数值始终不变，检查芯片是不是在 suspend 模式，用 i2cset 把电源管理寄存器切到 normal 再重新读一遍。数值全为 0xFF 大概率是 I2C 时序有问题，把总线频率从 400kHz 降到 100kHz 验证。

第三招是循环切换量程，确认配置位真正写进了芯片：

i2cset -y 1 0x18 0x0F 0x03 i2cget -y 1 0x18 0x02 i2cset -y 1 0x18 0x0F 0x0C i2cget -y 1 0x18 0x02

同样的静态姿态下，把量程从 ±2g 切到 ±16g，数据原始值会等比例缩小四倍左右，这是确认寄存器配置生效的最直接方法。如果驱动里已经封装好了设备节点，也可以用 cat 或 hexdump 读 /dev/bma2x2 对比结果，用户态读到的原始值应该与 i2cget 读到的低字节能对上。到这里，寄存器 → 内核 → 用户态的验证链路就完整了，后续再调试中断和运动唤醒就有明确的排查基准。

本文还有配套的精品资源，点击获取