企业官网建设流程全解析

简介：面向意法半导体LIS2DW12三轴加速度计的驱动源码与示例集合，适合嵌入式、物联网开发者快速掌握传感器驱动开发，尤其适用于低功耗运动监测、健康设备与移动终端等场景。压缩包为ZIP格式，共10个文件，全部为C源码，大小约30KB，轻量而实用；内容综合，示例覆盖单次读取、FIFO批量读取、自由落体、单击/双击、唤醒、自检、方向检测、活动识别等典型功能，从底层寄存器配置到上层应用调用层次分明，可系统学习I2C与SPI通信时序、寄存器读写、原始数据解析和中断唤醒机制等核心知识点。已有1508人学习下载，实践参考价值得到较多开发者认可。代码结构清晰，可直接借鉴驱动初始化与数据读取流程，根据实际硬件平台稍作配置修改即可集成使用，能有效降低LIS2DW12驱动开发门槛、缩短项目移植周期。 最近在做一块低功耗运动检测板子，传感器选的是 ST 的 LIS2DW12。这颗芯片的名字经常出现在各种 BSP 里，可真要自己从头写 lis2dw12 驱动的时候，你会发现网上大部分能搜到的例子都是 LIS3DH 或 LIS2DH12 的代码，寄存器名字看着像，实际位定义差不少，直接套用十有八九会翻车。我前后折腾了几天，把一个带 FIFO 和中断的驱动跑通，中间踩了几个值得记下来的坑。这篇文章不打算贴一个超大文件，而是把从芯片原理、寄存器、初始化、读数、FIFO 到 Linux 接入的完整链路讲清楚，并提供可以直接改用的驱动骨架和小例子。适合正在做可穿戴设备、电池供电传感器节点，以及需要在 Linux 下接入这颗加速度计的朋友参考。

1. LIS2DW12 这颗芯片，到底强在哪里

1.1 超低功耗不只是口号

LIS2DW12 是 ST 面向超低功耗市场推出的三轴加速度计，封装做到了 2mm x 2mm x 0.7mm，非常适合手环、耳机充电盒、智能标签这类空间极度紧张的产品。它的典型待机电流只有几十纳安，低功耗模式下 1.6Hz 采样时平均电流能压在 1 微安以内，用一颗 200mAh 的纽扣电池跑一年是完全现实的事情。

这颗芯片的功耗指标直接决定了驱动代码的写法。如果只是在开发板上做姿态检测，轮询读数据完全够了，但如果目标是电池供电产品，加速度计大部分时间必须待在低功耗模式，由内部运动检测中断去唤醒 MCU，而不是让 MCU 不停查询传感器。这个需求差异，会让驱动程序的架构变得很不一样，后面讲 FIFO 和中断配置时还会再提到。

1.2 写驱动前，先精读数据手册里这几页

拿到 LIS2DW12 数据手册，很多朋友第一反应是去翻 register map，然后一头扎进代码里。我建议反过来，先花半小时把下面三部分看明白，后面调驱动会快很多：

• 功能框图：弄清楚寄存器组、传感器核心、FIFO、中断控制器之间的数据流向。尤其是 FIFO 在哪个位置，这会影响你对批量读取的理解。
• 寄存器映射表：地址、默认值和读写属性。写代码时要频繁对照，最好打印一份放在手边。
• 芯片特性表：ODR 范围、量程和灵敏度、噪声密度、功耗数据。这些参数在换算加速度值和诊断异常数据时都要用到。

1.3 别把 LIS2DW12 当 LIS3DH 用

LIS3DH 是很多人的入门传感器，网上教程和代码多到爆炸。LIS2DW12 虽然看起来和它长得很像，引脚也兼容，但它是重新设计的低功耗产品线，不是 LIS3DH 的马甲。WHO_AM_I 的返回值不同，CTRL1、CTRL4 这些寄存器的位定义也有差别，FIFO 的行为更加不一样。我见过不止一个项目直接把 LIS3DH 的驱动文件改个名字就上板子，结果读出来的数据完全不对，最后排查了半天才发现问题出在寄存器配置上。

所以我的建议是：凡是遇到 ST 的加速度计，第一件事确认 WHO_AM_I，第二件事对照你手上那版数据手册的位描述，不要盲目相信网上的代码注释。

2. 驱动编写前，必须吃透的寄存器地图

2.1 I2C 还是 SPI，接线差别很大

LIS2DW12 支持 I2C 和 SPI 两种接口，最常用的是 I2C，两根线就能搞定，适合大多数 MCU。SPI 适合 I2C 总线已经比较拥挤、或者对数据吞吐率有要求的场景。I2C 从机地址由 SA0 引脚决定，接地时是 0x18，接 VDD 时是 0x19。注意这里说的是 7 位地址，很多平台的 I2C 驱动接口里需要把地址左移一位再去读写，这是新手最容易踩的坑之一。

接线时除了 VDD、GND、SCL、SDA，还有一个细节容易被忽略：LIS2DW12 的 CS 引脚在 I2C 模式下必须接高电平，否则芯片可能进入 SPI 模式，I2C 地址怎么发都不对。上电时如果 CS 悬空，还可能受干扰导致 WHO_AM_I 读出来是 0xFF。

2.2 核心寄存器一览

我在开发过程中把最常用的几个寄存器整理成了表格，处理大部分调试场景都够用。更完整的位描述还是要回到数据手册去查。

2.3 读加速度的两种姿势

第一种是轮询。每次读数据前先看 STATUS 寄存器的 ZYXDA 位，这一位变成 1 说明三个轴的新数据已经准备好了，然后连续读 6 个字节。这种写法最简单，但 MCU 要一直醒着等数据，在低功耗场景里很吃亏。

第二种是 FIFO 加中断。传感器内置了一个 FIFO，可以先把多次采样结果存起来，存到指定水位之后通过 INT1 引脚通知 MCU。MCU 被唤醒后一次性把一批数据搬走，然后再回去睡觉。这种方案能显著降低系统平均功耗，也是这颗芯片的正确打开方式。

3. 一个能直接改用的驱动代码骨架

3.1 先把底层读写接口封好

不管用 I2C 还是 SPI，第一步都是抽象底层通信接口。我习惯定义两个函数指针，初始化时把对应平台的代码填进去。这样驱动主体完全不依赖具体 MCU，换平台时只改一层小接口。

typedef struct { int (*read_reg)(uint8_t reg, uint8_t *buf, uint16_t len); int (*write_reg)(uint8_t reg, const uint8_t *buf, uint16_t len); } lis2dw12_bus_t; typedef struct { lis2dw12_bus_t bus; uint8_t i2c_addr; } lis2dw12_dev_t;

实际在 STM32 上，read_reg 里多半是 HAL_I2C_Mem_Read，Linux 用户态程序里则是 ioctl 加读缓冲。把这一层封装好，后面所有代码都是操作寄存器，清爽很多。

3.2 初始化流程，配置顺序有讲究

初始化第一步永远是读 WHO_AM_I，确认芯片在线，也顺便确认 I2C 地址和接线没有问题。然后才去写 CTRL1、CTRL4 这些控制寄存器。我习惯先把 CTRL1 里的 ODR 和模式配置好，再设置量程，最后如果需要软复位会再补一次复位操作。

int lis2dw12_init(lis2dw12_dev_t *dev) { uint8_t id; uint8_t ctrl1; uint8_t ctrl4; /* 第一步：确认芯片 ID */ dev->bus.read_reg(dev->i2c_addr, LIS2DW12_WHO_AM_I, &id, 1); if (id != 0x44) { return -1; } /* 第二步：配置 CTRL1，ODR 和模式。 * 这里先给出一个示意，实际 ODR 编码请对照手册表格。 */ dev->bus.read_reg(dev->i2c_addr, LIS2DW12_CTRL1, &ctrl1, 1); ctrl1 &= ~0xF0; ctrl1 |= (0x07 << 4); /* 100Hz 示例 */ dev->bus.write_reg(dev->i2c_addr, LIS2DW12_CTRL1, &ctrl1, 1); /* 第三步：配置 CTRL4 的量程，±2g 示例 */ dev->bus.read_reg(dev->i2c_addr, LIS2DW12_CTRL4, &ctrl4, 1); ctrl4 &= ~0x30; dev->bus.write_reg(dev->i2c_addr, LIS2DW12_CTRL4, &ctrl4, 1); return 0; }

配置顺序的重点是：CTRL1 的 ODR 一定要先写，再写量程。有些项目先把量程配好，再回头写 ODR，结果传感器会因为配置不完整进入一种“半工作”状态，表现为数据一直不更新或者读出随机值。

3.3 读取三轴原始值并换算成 g

读数据时我先检查 STATUS 的 ZYXDA 位，然后一次读 6 个字节。多字节读要保证地址自增已经打开，否则会一直在读同一个寄存器。芯片手册里把这个功能叫做 IF_ADD_INC，一般在 CTRL3 里控制。

int lis2dw12_read_xyz(lis2dw12_dev_t *dev, int16_t *x, int16_t *y, int16_t *z) { uint8_t status; uint8_t buf[6]; dev->bus.read_reg(dev->i2c_addr, LIS2DW12_STATUS, &status, 1); if (!(status & 0x01)) { return -EAGAIN; } dev->bus.read_reg(dev->i2c_addr, LIS2DW12_OUT_X_L, buf, 6); *x = (int16_t)((buf[1] << 8) | buf[0]); *y = (int16_t)((buf[3] << 8) | buf[2]); *z = (int16_t)((buf[5] << 8) | buf[4]); return 0; }

原始值和物理量之间的换算，要看量程和分辨率。LIS2DW12 在不同模式下输出位数不一样，正常模式下 14 位，低功耗模式下可能会降到 12 位甚至 8 位。以 ±2g 量程、14 位输出为例，1g 大约对应 4096 LSB，所以换算公式是g = raw / 4096.0。如果你把量程改成了 ±16g，这个系数就完全不同，务必按手册里的灵敏度重新算。

3.4 FIFO 批量读取，把系统功耗真正降下来

FIFO 的用法是把多个采样结果先缓存到芯片内部，然后一次读出来。我常用的模式是连续模式，传感器按 ODR 持续采样，一直往 FIFO 里写，满了之后由硬件设置水位中断，MCU 过来搬数据。FIFO 深度是 32 级，也就是最多缓存 32 个三轴样本。

配置 FIFO 时，我先写 FIFO_CTRL 设置工作模式和水位，再把中断打开。FIFO 水位中断被触发后，我读取 FIFO_SAMPLES 寄存器的低 5 位，得到当前有效样本数，然后循环读取 6 字节数据块，直到把存量样本搬完。

int lis2dw12_fifo_read(lis2dw12_dev_t *dev, int16_t samples[][3], uint8_t max_num) { uint8_t n; uint8_t buf[6]; uint8_t i; dev->bus.read_reg(dev->i2c_addr, LIS2DW12_FIFO_SAMPLES, &n, 1); n &= 0x1F; if (n > max_num) { n = max_num; } for (i = 0; i < n; i++) { dev->bus.read_reg(dev->i2c_addr, LIS2DW12_OUT_X_L, buf, 6); samples[i][0] = (int16_t)((buf[1] << 8) | buf[0]); samples[i][1] = (int16_t)((buf[3] << 8) | buf[2]); samples[i][2] = (int16_t)((buf[5] << 8) | buf[4]); } return n; }

用 FIFO 有个好处，MCU 可以睡上一阵子，等传感器存满一批数据再醒来，平均功耗低很多。但要注意 FIFO 水位不要设成满深度，留一点余量，否则中断响应稍微慢一点就会丢数据。

4. Linux 下的接入方式：用户态调试与内核驱动两手抓

4.1 用户态 I2C 操作，验证传感器最快的方式

拿到一块板子，先别急着写内核驱动。先把 I2C 总线上能不能看到这颗芯片搞清楚。Linux 下用 i2c-tools 可以快速探测：

i2cdetect -y 1 i2cget -y 1 0x18 0x0f

如果i2cdetect在 0x18 或 0x19 位置看到了设备，再用i2cget读 WHO_AM_I，能得到 0x44，说明接线和地址都没问题。这时候可以接着写一小段 Python 脚本，配合 smbus2 库快速验证基础功能：

from smbus2 import SMBus bus = SMBus(1) bus.write_byte_data(0x18, 0x20, 0x70) # CTRL1: 100Hz 示例 data = bus.read_i2c_block_data(0x18, 0x28, 6) x = (data[1] << 8) | data[0] y = (data[3] << 8) | data[2] z = (data[5] << 8) | data[4] print(x, y, z)

这一步看着不起眼，但在写内核驱动之前能把硬件链路确认干净，后期排错会省非常多时间。

4.2 内核 IIO 驱动，产品级做法

如果要做产品，正经的接入方式是走内核的 IIO 子系统。主线内核里已经有 st_lis2dw12 这个驱动，位于 drivers/iio/accel/ 目录下，设备树里把器件挂到 I2C 总线上，声明 compatible 为st,lis2dw12，并配置中断引脚：

&i2c1 { lis2dw12@18 { compatible = "st,lis2dw12"; reg = <0x18>; interrupt-parent = <&gpioa>; interrupts = <1 IRQ_TYPE_EDGE_RISING>; }; };

驱动加载成功以后，IIO 框架会在/sys/bus/iio/devices/iio:deviceX下生成节点，读原始值可以直接用 sysfs 接口：

cat /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw

不过不同内核版本的 IIO 驱动对设备树属性的支持程度有差异，有些属性只在新版本里才生效。我的建议是先用当前内核文档核对一遍，不要直接照抄旧项目的设备树。

4.3 两种接入方式怎么选

用户态 I2C 适合调试和快速验证，Python 脚本改起来快，图形化也方便。内核 IIO 驱动适合正式产品，sysfs 接口方便上层应用读取，也让传感器管理和电源管理更容易统一交给内核。如果只是在 MCU 上做开发，完全用不上内核驱动，直接在 RTOS 或裸机环境里用第三节的代码骨架就行。

5. 实战避坑：数据手册写了，但容易看漏的细节

5.1 WHO_AM_I 读出来是 0xFF 或 0x00

这个现象十有八九是接线或接口模式问题，按下面顺序排查：

1. 用万用表确认 VDD 和 GND 电压正常，芯片供电范围一般是 1.62V 到 3.6V，不要给到 5V。
2. 确认 CS 引脚在 I2C 模式下确实拉高。CS 悬空是 I2C 模式下最容易犯的错。
3. 确认 I2C 地址。0x18 是 7 位地址，如果你用的是 ioctl 方式，要把地址左移一位，变成 0x30 才能发给内核。
4. 用逻辑分析仪抓一下 SCL 和 SDA，看主机是不是真的把起始条件和从机地址发出去了。

我遇到过一次非常隐蔽的问题：板子上拉了 4.7k 上拉，但主控的 I2C 引脚配置成了开漏输出之后又被复用成别的功能，导致 SCL 一直拉不高。这类问题不从波形上看很难定位。

5.2 读出来数据全是 0，或者长时间不更新

先看 STATUS 的 ZYXDA 位有没有变化。如果永远为 0，说明传感器根本没有产生新的采样结果。这时候优先检查 ODR 配置是否写进去了，很多库函数在初始化时会把 CTRL1 清零，如果后面没有再设置 ODR，芯片就一直处于 power-down 状态。

另外一种常见情况是：读函数用了单字节读，但没有开地址自增。结果每次读到 OUT_X_L，然后总线自动又回到同一个地址，6 个字节读出来全是同一个值。这个现象很有迷惑性，很容易让人以为是传感器坏了。

还有一点提醒一下：有些传感器在配置完寄存器之后需要等一段时间才能输出第一组有效数据，不能指望写完初始化立刻就有数据。如果逻辑分析仪上能看到 I2C 事务正常，但 STATUS 一直是 0，可以加一个几十毫秒的延时再查。

5.3 FIFO 水位中断不触发

中断不触发，先从硬件到软件一层层查。我最常遇到的是中断引脚配置没对上。LIS2DW12 的 INT1 和 INT2 是可以配置不同中断源的，如果代码里把 FIFO 满中断配到 INT2，但硬件上只连了 INT1，自然永远等不到中断。

另一个容易被忽略的点是中断触发方式。有些驱动配置的是电平触发，但中断引脚没有正确清标志位，导致中断一直挂着；有些场景适合边沿触发，需要读一次 STATUS 或 FIFO_SAMPLES 来清标志。每次调试中断问题，我都会先写一个最简单的轮询版本来确认 FIFO 数据本身没问题，再去查中断链路，这样能把“传感器异常”和“中断路径异常”快速区分开。

5.4 低功耗模式下，ODR 和带宽不一定能随意配

LIS2DW12 虽然有很丰富的低功耗档位，但并不是所有组合都能自由选择。某些低功耗模式下，支持的最高 ODR 会降低，如果代码里选了手册不允许的组合，可能读到的数据更新率完全不符合预期。选型时如果项目需要 400Hz 采样，就要确保工作在支持这个 ODR 的模式下，否则数据曲线会“断断续续”，看起来像是驱动有 bug，实际是模式配置本身就不合法。

5.5 调完这块芯片以后，我给自己留的一条笔记

最后一个建议，来自我这次实际调完之后的一点体会：ST 传感器的寄存器位定义在不同子型号之间差异不小，无论从哪个例程开始改，第一步永远是把 WHO_AM_I 和手册版本确认好。把寄存器配置写成一个清晰的结构体或配置表，不要散落在代码里到处都是 magic number。这样即使换了芯片型号，也能很快比对差异，不至于重新踩一遍同一个坑。

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