最近在做一个设备状态监测的小项目需要把轴承的振动信号通过传感器实时采集下来主控端选了新出的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能跑到10MHzI2C快速模式也能到800kHz就传感器本身来说两条路都不存在瓶颈。我这次选了I2C原因很现实板上还要挂温湿度传感器、EEPROM用同一条I2C总线就能搞定省引脚真要挂多个设备也不需要额外接线。而且I2C的接线方式通用性更强后续如果换主控驱动代码改动很小。STM32C5是ST新一代C系列里的高性价比型号基于Cortex-M33内核主频能跑到250MHz级别板上I2C外设的数量足够还带高级定时器、DMA这些资源。项目里不只是读个加速度后期还要做简单的FFT运算和状态判断M33带DSP指令集算起来比M0轻松不少。选它的另一个原因是评估板好拿、CubeMX和HAL库支持齐全前期跑通功能非常快。这套组合下来传感器端和主控端都不存在性能焦虑。1.3 整体系统构成与数据流系统构成不复杂。主控是STM32C5I2C1外设负责跟IIS3DWB通信传感器供电直接用3.3VSCL和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_I0x0F只读正常值我这次读到的是0x7B如果读不到这个值后面的配置都不用看了。CTRL10x20配置ODR和高半字节低两位配置量程。CTRL20x21包含自检和一部分滤波配置。CTRL30x22重点位是BDU块数据更新和一些中断相关使能位。CTRL40x23I2C相关配置以及SPI模式下的一些选项。STATUS0x27查询数据是否更新的标志位。初始化顺序其实很简单先读一次WHO_AM_I确认通信没问题然后往CTRL1写入ODR和量程再把CTRL3的BDU位置1防止读取过程中高低字节数据发生错位最后确认CTRL4里面I2C功能没有被禁用。这个流程跑完传感器就进入工作状态了。2.3 量程和BDU的选择逻辑量程怎么选取决于实际工况。手持设备、电脑风扇这类振动比较小的场景±2g就够了灵敏度和分辨率最高。泵、电机、减速机这类工况振动加速度通常有几个g甚至更大为了不削波选±8g或者±16g更稳妥。我这次初调直接选了±16gCTRL1低两位配置为11先保证数据不会溢出等实际测试下来再根据信号幅值切换量程。BDU这个位很多新手会忽略。它内部的作用是在你读数据的时候传感器先把当前时刻的六字节数据锁存住保证你读到的高位和低位是同一个时间点的数据。如果不打开BDU读取时序稍微拖长就可能出现高位是新数据、低位是旧数据的混搭情况算出来的物理量完全是错的。这个位在CTRL30x22的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×50pF235ns勉强够用。如果走线更长、器件更多建议换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, reg, 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: ODR26.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, reg, 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×1000488mg也就是0.488g。(\pm 2g)量程对应的灵敏度是0.061mg/LSB精度更细适合小幅振动。换算逻辑本身很简单真正容易翻车的是符号扩展问题。buf[1]8的时候如果数据是负数直接强制转换int16_t是能正确处理的但如果你不小心用了uint16_t再转int16_t顺序错了结果就会不对。推荐先拼成一个uint16_t的临时变量再直接赋给int16_t隐式转换成有符号数。按代码里的读法XYZ三轴数据格式是一样的。静止状态下Z轴读数接近1gX轴和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。等那部分调通了再整理一篇关于振动频谱特征分析的内容分享出来。
STM32C5通过I2C读取IIS3DWB振动传感器完整指南
最近在做一个设备状态监测的小项目需要把轴承的振动信号通过传感器实时采集下来主控端选了新出的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能跑到10MHzI2C快速模式也能到800kHz就传感器本身来说两条路都不存在瓶颈。我这次选了I2C原因很现实板上还要挂温湿度传感器、EEPROM用同一条I2C总线就能搞定省引脚真要挂多个设备也不需要额外接线。而且I2C的接线方式通用性更强后续如果换主控驱动代码改动很小。STM32C5是ST新一代C系列里的高性价比型号基于Cortex-M33内核主频能跑到250MHz级别板上I2C外设的数量足够还带高级定时器、DMA这些资源。项目里不只是读个加速度后期还要做简单的FFT运算和状态判断M33带DSP指令集算起来比M0轻松不少。选它的另一个原因是评估板好拿、CubeMX和HAL库支持齐全前期跑通功能非常快。这套组合下来传感器端和主控端都不存在性能焦虑。1.3 整体系统构成与数据流系统构成不复杂。主控是STM32C5I2C1外设负责跟IIS3DWB通信传感器供电直接用3.3VSCL和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_I0x0F只读正常值我这次读到的是0x7B如果读不到这个值后面的配置都不用看了。CTRL10x20配置ODR和高半字节低两位配置量程。CTRL20x21包含自检和一部分滤波配置。CTRL30x22重点位是BDU块数据更新和一些中断相关使能位。CTRL40x23I2C相关配置以及SPI模式下的一些选项。STATUS0x27查询数据是否更新的标志位。初始化顺序其实很简单先读一次WHO_AM_I确认通信没问题然后往CTRL1写入ODR和量程再把CTRL3的BDU位置1防止读取过程中高低字节数据发生错位最后确认CTRL4里面I2C功能没有被禁用。这个流程跑完传感器就进入工作状态了。2.3 量程和BDU的选择逻辑量程怎么选取决于实际工况。手持设备、电脑风扇这类振动比较小的场景±2g就够了灵敏度和分辨率最高。泵、电机、减速机这类工况振动加速度通常有几个g甚至更大为了不削波选±8g或者±16g更稳妥。我这次初调直接选了±16gCTRL1低两位配置为11先保证数据不会溢出等实际测试下来再根据信号幅值切换量程。BDU这个位很多新手会忽略。它内部的作用是在你读数据的时候传感器先把当前时刻的六字节数据锁存住保证你读到的高位和低位是同一个时间点的数据。如果不打开BDU读取时序稍微拖长就可能出现高位是新数据、低位是旧数据的混搭情况算出来的物理量完全是错的。这个位在CTRL30x22的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×50pF235ns勉强够用。如果走线更长、器件更多建议换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, reg, 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: ODR26.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, reg, 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×1000488mg也就是0.488g。(\pm 2g)量程对应的灵敏度是0.061mg/LSB精度更细适合小幅振动。换算逻辑本身很简单真正容易翻车的是符号扩展问题。buf[1]8的时候如果数据是负数直接强制转换int16_t是能正确处理的但如果你不小心用了uint16_t再转int16_t顺序错了结果就会不对。推荐先拼成一个uint16_t的临时变量再直接赋给int16_t隐式转换成有符号数。按代码里的读法XYZ三轴数据格式是一样的。静止状态下Z轴读数接近1gX轴和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。等那部分调通了再整理一篇关于振动频谱特征分析的内容分享出来。
