最近在做一个设备状态监测的小项目，需要把轴承的振动信号通过传感器实时采集下来，主控端选了新出的STM32C5系列，传感器用了ST的宽频加速度计IIS3DWB10IS（也就是IIS3DWB，封装后缀不同）。标题里说“IIC获取震动计数据”，这期内容就是把这块传感器通过I2C总线接到STM32C5上，从硬件连线到最后读到正确的加速度值，完整记录一遍。这个过程并不复杂，但雷区不少，I2C的时序、寄存器配置、上拉电阻、地址确认，任何一个环节出问题都会让你卡上半天。这篇文章把整个流程拆开讲，适合正在做振动监测、状态监测或者传感器驱动开发的朋友参考，尤其是第一次接触IIS3DWB这种宽频传感器的，可以少走一些弯路。
1. 项目概述与硬件选型思路
1.1 这个项目到底要解决什么问题
振动监测听起来高大上，实际上就是把一个加速度计贴在设备外壳上，以足够高的采样率把振动信号记录下来，然后通过频谱分析判断设备是否异常。这里的关键词是“足够高的采样率”。普通加速度计，比如手机里那种，带宽大概在几百赫兹到1kHz，拿来测设备振动根本不够用。轴承故障的特征频率往往在几kHz到十几kHz，你想看到高频成分，传感器带宽必须先跟上。IIS3DWB这块传感器的数据手册上写着平坦带宽能到6kHz，工作频率范围接近DC到6kHz，输出数据速率最高可以配到26.7kHz。这颗传感器算是ST针对振动监测专门出的一个型号，拿它做这类项目很合适。
1.2 为什么是IIS3DWB + STM32C5这套组合
先说IIS3DWB。它最大的特点就是宽带宽和低噪声，量程有±2g、±4g、±8g、±16g四档可选，内部有真正的物理震动检测能力。接口支持SPI和I2C两种，SPI能跑到10MHz，I2C快速模式也能到800kHz，就传感器本身来说，两条路都不存在瓶颈。我这次选了I2C，原因很现实：板上还要挂温湿度传感器、EEPROM，用同一条I2C总线就能搞定，省引脚，真要挂多个设备也不需要额外接线。而且I2C的接线方式通用性更强，后续如果换主控，驱动代码改动很小。
STM32C5是ST新一代C系列里的高性价比型号，基于Cortex-M33内核，主频能跑到250MHz级别，板上I2C外设的数量足够，还带高级定时器、DMA这些资源。项目里不只是读个加速度，后期还要做简单的FFT运算和状态判断，M33带DSP指令集，算起来比M0+轻松不少。选它的另一个原因是评估板好拿、CubeMX和HAL库支持齐全，前期跑通功能非常快。这套组合下来，传感器端和主控端都不存在性能焦虑。
1.3 整体系统构成与数据流
系统构成不复杂。主控是STM32C5，I2C1外设负责跟IIS3DWB通信，传感器供电直接用3.3V，SCL和SDA各接一个上拉电阻到3.3V。数据流向是：传感器内部采集振动并数字化，主控以I2C读寄存器的方式把原始加速度值取回来，换算成mg或者g，然后传输到上位机或者本地存储。做实时监测时，可以把传感器的中断引脚接到主控的外部中断上，数据准备好后触发读取，避免主控一直轮询浪费CPU。我这次先跑通查询方式，不着急接中断，等数据链路确认无误再优化。
2. IIS3DWB传感器核心特性与寄存器拆解
2.1 宽带宽对于震动监测意味着什么
很多人第一次看到IIS3DWB的6kHz带宽没概念，我可以给个直观的解释。假如你采样率配到26.7kHz，理论上能看到的最高信号频率是13kHz左右，实际可靠分析的频段到6kHz到8kHz没有太大问题。普通电机的轴承故障特征频率一般在500Hz到4kHz，齿轮箱的啮合频率可以到几千赫兹，所以6kHz带宽能覆盖这些关键频段。如果你拿带宽800Hz的加速度计去测，高频信号直接衰减掉，故障特征根本看不见。
IIS3DWB内部采用了专用的机械结构和信号调理电路，保证在宽带宽下噪声依然比较低，不然带宽是够了，信号全淹没在噪声里也没有意义。实际使用中，在±2g量程下，灵敏度标称约0.061mg/LSB，这个分辨率对于采集轴承振动来说足够用了。
2.2 寄存器地图与初始化顺序
IIS3DWB的寄存器不算多，跟普通ST加速度计的结构类似。初始化的时候，最重要的几个寄存器依次是：
- WHO_AM_I（0x0F）：只读，正常值我这次读到的是0x7B，如果读不到这个值，后面的配置都不用看了。
- CTRL1（0x20）：配置ODR和高半字节，低两位配置量程。
- CTRL2（0x21）：包含自检和一部分滤波配置。
- CTRL3（0x22）：重点位是BDU（块数据更新）和一些中断相关使能位。
- CTRL4（0x23）：I2C相关配置以及SPI模式下的一些选项。
- STATUS（0x27）：查询数据是否更新的标志位。
初始化顺序其实很简单：先读一次WHO_AM_I确认通信没问题，然后往CTRL1写入ODR和量程，再把CTRL3的BDU位置1，防止读取过程中高低字节数据发生错位，最后确认CTRL4里面I2C功能没有被禁用。这个流程跑完，传感器就进入工作状态了。
2.3 量程和BDU的选择逻辑
量程怎么选，取决于实际工况。手持设备、电脑风扇这类振动比较小的场景，±2g就够了，灵敏度和分辨率最高。泵、电机、减速机这类工况，振动加速度通常有几个g甚至更大，为了不削波，选±8g或者±16g更稳妥。我这次初调直接选了±16g（CTRL1低两位配置为11），先保证数据不会溢出，等实际测试下来再根据信号幅值切换量程。
BDU这个位很多新手会忽略。它内部的作用是在你读数据的时候，传感器先把当前时刻的六字节数据锁存住，保证你读到的高位和低位是同一个时间点的数据。如果不打开BDU，读取时序稍微拖长，就可能出现高位是新数据、低位是旧数据的混搭情况，算出来的物理量完全是错的。这个位在CTRL3（0x22）的bit 6，初始化时务必置1。
3. IIC接口：协议要点与STM32外设配置
3.1 为什么I2C必须是开漏加上拉
I2C协议物理层有个硬性要求：总线上的器件驱动能力必须是开漏结构，外部必须接上拉电阻。很多新手直接用推挽输出去驱动SDA和SCL，结果就是通信时好时坏，甚至把器件烧掉。原因很简单，I2C总线是允许多个设备挂在同一条线上的，设备之间通过拉低总线来表示“0”，靠上拉电阻把总线拉回“1”来表示“高”。如果用推挽输出，一个设备输出高电平、另一个设备输出低电平，两个输出级直接对着干，瞬间电流很大，逻辑也会乱掉。只有开漏输出，所有设备都只能拉低，高电平完全靠上拉电阻来恢复，才天然具备“线与”能力，冲突时也不会出问题。所以硬件上，SCL和SDA都必须接上拉电阻，主控端的I2C引脚也必须配置为开漏输出，这一点在CubeMX里选I2C功能后默认就是对的，不要手动改成推挽。
3.2 上拉电阻选多大
上拉电阻的选择跟总线电容、通信速率直接相关。总线电容是PCB走线、器件引脚、连接器等因素叠加出来的，走线越短电容越小。I2C标准对上升时间有要求，快速模式（400kHz）要求上升时间不超过300ns。计算方法是上拉电阻乘以总线电容，近似等于上升沿的RC时间常数。假设总线上挂了3个器件，走线长度在10cm左右，电容大约50pF，用4.7kΩ上拉，时间常数是4.7k×50pF=235ns，勉强够用。如果走线更长、器件更多，建议换2.2kΩ，留出余量。
我这次用的两个上拉电阻都是2.2kΩ，总线速度配的是400kHz，实测波形边沿干净，没有明显失真。特别提醒：如果传感器和主控之间用杜邦线连接，线长10cm以上，电容会明显增大，4.7kΩ可能会出问题，直接用2.2kΩ更稳。
3.3 STM32CubeMX里I2C的配置步骤
我用的工具是STM32CubeMX生成HAL工程，配置I2C1外设。核心配置项是时钟频率，选好开漏模式、400kHz快速模式后，其余参数基本不用动。有一点值得留意：CubeMX里I2C外设的高级参数里有个“时钟占空比”选项，ST的I2C硬件在快速模式下支持两种SCL占空比设定，2:1和16:9。占空比会影响SCL高低电平的配比，进而影响时序。默认配置通常能用，如果通信在高温或者长走线条件下出现不稳定，可以改一下占空比再测，大多数时候会有改善。
配置完成后，生成代码时把I2C事件中断勾上，方便后面用回调函数判断数据接收完成。主频和I2C外设时钟之间的分频关系，CubeMX会自动算好，不需要手工干预。
3.4 用HAL库读写传感器的代码示例
读写传感器寄存器，HAL库提供了很直接的接口。写寄存器时先发送寄存器地址，再跟一个数据字节；读寄存器时先发送寄存器地址，然后重新发起读操作，把数据读回来。IIS3DWB的寄存器地址在I2C读模式下是自动递增的，所以连续读取6个数据字节非常方便，一次把XYZ三个轴的高低字节全读出来。
下面是我在工程里实际用的代码片段。初始化的I2C设备地址，IIS3DWB的7位地址是0x18，左移一位变成8位地址0x30，这是HAL库要求的形式。如果SAO引脚接了高电平，地址会变成0x19，也就是0x32。
#define IIS3DWB_ADDR8 0x30 // 7位地址0x18，左移一位后用于HAL #define IIS3DWB_WHO_AM_I 0x0F #define IIS3DWB_CTRL1 0x20 #define IIS3DWB_CTRL3 0x22 #define IIS3DWB_STATUS 0x27 #define IIS3DWB_OUT_X_L 0x28 uint8_t read_reg(uint8_t reg) { uint8_t value = 0; HAL_I2C_Master_Transmit(&hi2c1, IIS3DWB_ADDR8, ®, 1, 100); HAL_I2C_Master_Receive(&hi2c1, IIS3DWB_ADDR8, &value, 1, 100); return value; } void write_reg(uint8_t reg, uint8_t value) { uint8_t buf[2]; buf[0] = reg; buf[1] = value; HAL_I2C_Master_Transmit(&hi2c1, IIS3DWB_ADDR8, buf, 2, 100); } void iis3dwb_init(void) { uint8_t id = read_reg(IIS3DWB_WHO_AM_I); if (id != 0x7B) { // 通信异常，这里可以打印错误 return; } // CTRL1: ODR=26.7kHz, 量程=±16g write_reg(IIS3DWB_CTRL1, 0xCE); // CTRL3: 开启BDU，避免数据错位 write_reg(IIS3DWB_CTRL3, 0x40); } uint8_t iis3dwb_read_data(int16_t *x, int16_t *y, int16_t *z) { uint8_t reg = IIS3DWB_OUT_X_L; uint8_t buf[6]; HAL_I2C_Master_Transmit(&hi2c1, IIS3DWB_ADDR8, ®, 1, 100); HAL_I2C_Master_Receive(&hi2c1, IIS3DWB_ADDR8, buf, 6, 100); *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; }CTRL1这里我配了0xCE，也就是ODR选了26.7kHz那一档，量程是±16g。实际项目里ODR不一定非得跑满，频率越高，I2C读取频率也要跟着越快，CPU负担会加大。如果轴承的特征频率在2kHz以下，ODR配到6.6kHz就够了。(\pm 16g)量程下的灵敏度是0.488mg/LSB，换算成g就是原始值乘0.000488。
4. 数据采集与物理量换算
4.1 读取流程：状态检查与多字节读取
数据读取的常规套路是：先查STATUS寄存器，看数据是否更新完成，再读六个字节。STATUS寄存器最低位是数据结束标志，传感器内部每完成一次采样，这个位就会置1。查询模式其实就是反复读STATUS，直到位变为1再读数据。
实际代码里我做了个简单处理：如果连续读STATUS超过一定次数还没等到更新，就判定通信超时，重新初始化传感器。这个超时保护在刚上电或者传感器复位异常时能救你一把，不然程序容易卡死在等待循环里。
4.2 计算振动加速度值
原始数据是16位有符号数，两个字节拼起来之后，按照所选量程的灵敏度换算成物理值。(\pm 16g)量程对应0.488mg/LSB，比如原始数据是1000，算出来就是0.488mg×1000=488mg，也就是0.488g。(\pm 2g)量程对应的灵敏度是0.061mg/LSB，精度更细，适合小幅振动。换算逻辑本身很简单，真正容易翻车的是符号扩展问题。buf[1]<<8的时候，如果数据是负数，直接强制转换int16_t是能正确处理的，但如果你不小心用了uint16_t再转int16_t，顺序错了结果就会不对。推荐先拼成一个uint16_t的临时变量，再直接赋给int16_t，隐式转换成有符号数。
按代码里的读法，XYZ三轴数据格式是一样的。静止状态下，Z轴读数接近1g，X轴和Y轴接近0，这是判断传感器是否正常工作的一个很直观的方法。如果平放之后Z轴读出来不是1g左右，要么量程配置错了，要么换算系数不对。
4.3 用示波器和串口验证数据合理性
数据读回来之后，可以先通过串口把原始值和换算后的值打印出来，观察静止状态下的数值变化。正常情况下，静止时Z轴数值应该非常稳定，波动幅度很小。IIS3DWB这种低噪声传感器，(\pm 16g)量程下静止噪声大概在几个LSB以内。
要验证动态性能，最简单的办法是用手敲一下传感器旁边的桌面，观察串口数据有没有明显跳变。如果想看更真实的波形，可以把数据通过DMA发送到DAC或者用虚拟示波器在上位机显示。我直接把数据用串口传到电脑，配合一个简单的串口波形工具，能看到敲击瞬间的冲击波形，这算是初步验证数据链路有效的快速方式。
震动数据的最终验证，还是要用标准的振动台或者频率已知的音叉做参考。在普通项目调试阶段，用手机播放一个固定频率的音频，把传感器贴近喇叭纸盆边，也能看到明显的频率分量，这个土办法我试过，效果还不错。
5. 调试中的问题实录与排查技巧
5.1 WHO_AM_I读不到值
这个问题是I2C器件调试中最高频的故障。优先检查电源电压，IIS3DWB的正常工作电压范围是1.8V到3.6V，我用3.3V供电。然后用万用表确认SCL和SDA上电后都是高电平，如果某个引脚是低电平，说明总线被拉死了，多半是某个器件的地址冲突或者总线卡在错误状态。接着确认上拉电阻，上拉电阻没焊或者虚焊，总线电平就会飘，通信自然失败。再检查地址，SAO引脚如果悬空，7位地址是0x18，如果接高电平，地址是0x19，务必和代码里的0x30或0x32对应上。最后，有条件的话用逻辑分析仪抓一下I2C波形，看主机有没有正常发出起始信号和地址信号，设备有没有回ACK。
我这次第一次读WHO_AM_I的时候也碰到过返回0xFF的情况，最后查下来是SCL和SDA两根线接反了，低级错误，但确实容易发生。
5.2 数据全零或者全FF
数据全0xFF，大概率是总线上的上拉电阻没起作用，或者器件没上电，主机读到的全是高电平。数据全0x00，多半是器件的I2C接口没有真正进入通信状态，或者寄存器地址不对。IIS3DWB在SPI模式下会禁用I2C接口，如果之前有人把CTRL4寄存器配置成了SPI相关模式，I2C就可能失效。另一个排查点是确认读数据之前有没有先写配置寄存器。传感器上电默认可能是低功耗或者关断模式，不配置CTRL1，数据寄存器不会正常更新。
5.3 读取数据偶尔卡死
如果程序运行一会，I2C通信就卡住，大概率是总线状态异常。I2C协议对时序要求严格，如果某次传输中途发生了时钟拉伸或者设备没回ACK，总线的状态就可能停在中间状态。最直接的恢复办法是把I2C外设重新初始化一遍，把SCL和SDA引脚状态恢复。我在代码里加了一个简单的错误处理：如果HAL_I2C_Master_Transmit返回HAL_ERROR，就调用HAL_I2C_DeInit和HAL_I2C_Init重建外设。这个方法虽然不是最优雅的，但非常实用。
还要检查主控端的引脚配置，确认没有复用冲突。STM32C5的引脚功能多，同一个引脚可能同时映射到其他外设，导致I2C信号被干扰。
5.4 数据里噪声大，高频成分异常
噪声大先分清是传感器本身噪声还是信号链问题。把传感器放在桌面上静止不动，观察数据波动，如果静止波动已经很大，先用万用表检查供电是否干净，示波器看3.3V上有没有高频纹波。IIS3DWB对电源纹波敏感，电源引脚附近加一个0.1uF和1uF的去耦电容是标配。我试过没插去耦电容的时候，静止数据噪声明显偏大，加上电容后恢复到了正常水平。
5.5 快速定位问题的排查顺序
我整理了一个排查顺序，遇到问题按这个来，效率最高。第一，用万用表量电压，确认传感器供电正常、引脚电平正确。第二，用逻辑分析仪抓I2C波形，确认总线空闲电平正常、地址和ACK是否正确。第三，读WHO_AM_I，确认通信链路和设备ID都对。第四，读STATUS寄存器，确认传感器有没有进入正常工作状态。第五，读六个数据字节，确认数值量级是否正常。每一步都能定位一类问题，不需要拿着代码瞎猜。
写在最后
这次把IIS3DWB通过I2C接到STM32C5上，整体下来不算难，难点主要集中在对I2C协议细节和传感器寄存器理解的深度上。我个人在做这类传感器驱动时最深的体会是，I2C总线上拉电阻和地址确认这两件事，能提前规避掉八成以上的通信问题。代码本身反而是最不花时间的部分。后续我准备在这个基础上把中断读取方式加上去，再把采集到的数据用DMA搬到内存里，做更高频率的连续采样，配合STM32C5的DSP指令做实时FFT。等那部分调通了，再整理一篇关于振动频谱特征分析的内容分享出来。
