搞设备状态监测的朋友应该都有同感振动数据好不好一半看传感器另一半看读取链路到底稳不稳。拿到ST的STM32C5样片之后我第一件想干的事就是把它和IIS3DWB这颗专门为振动监测设计的高带宽加速度计通过IIC接口接起来实打实把震动计数据抠出来。这是这个系列的第(2)篇上期已经把硬件底板和CubeMX工程搭好了这期重点全放在IIC这条线上——从物理层的上拉电阻、时钟占空比到传感器寄存器配置、多字节连续读再到我实测时踩进去的坑一次性说透。想复现的读者至少需要一块STM32C5核心板、IIS3DWB评估板或自绘图以及一个逻辑分析仪。后面你会看到逻辑分析仪在这种调试里比示波器还救命。1. 震动监测的高带宽陷阱普通加速度计为何测不准1.1 加速度计带宽到底是什么很多刚接触振动测量的人会把采样率和带宽混为一谈这是第一个容易翻车的地方。加速度计的带宽指传感器幅频响应的平坦区间通常标成-3dB点。比如普通消费级加速度计IIS2DLPC输出数据率可以设到几百赫兹但它的模拟带宽实际上只有几百赫兹甚至更低。你把它贴在电机壳上看到的是被内部滤波抹平之后的温吞波形早期轴承磨损激起的几千赫兹微振早就没了。IIS3DWB这颗芯片的卖点恰恰在带宽它的平带带宽做到6kHz左右专门为了覆盖齿轮啮合频率、轴承故障特征频率以及结构共振频段。带宽和输出数据率ODR是两码事ODR决定你多久采一个点带宽决定传感器本身能不能把对应频率的机械振动真实转成电信号。两者必须配套单有一项高没用。另一个容易被忽略的点是混叠。IIS3DWB最高ODR可以到几十kHz但如果你把ODR降到6.67kHz那么奈奎斯特频率就是3.33kHz这时候把6kHz带宽里的分量采进来高频会折叠到低频段频谱里出现一堆幽灵峰值。所以用这颗传感器的第一原则就是要测多高的频率ODR就得留够余量带宽和采样率必须一起看。1.2 频谱里的高频细节去了哪拿现场最常见的滚动轴承举例。外圈故障频率BPFO的计算公式大致是BPFO (滚珠数 / 2) × 转频 × (1 - 滚珠直径/节圆直径 × cos接触角)即使只看简化形式也能看出故障特征频率和转频直接挂钩。一台30Hz转频的电机外圈故障可能在150Hz附近出现但这只是基频。真正的问题在于轴承故障会激起壳体结构共振这些共振峰常常落在1kHz到5kHz区间故障信息以边带形式挂在共振峰旁边。如果用一只带宽只有500Hz的传感器这些共振边带要么被衰减到看不出要么直接被内部低通滤波器吃掉频谱分析自然找不到故障证据。齿轮箱就更典型了。啮合频率等于转频乘以齿数二级减速箱的中间级啮合频率做到几千赫兹很常见。做预测性维护时我们不仅要看啮合频率本身还要看它的边带分布——边带间隔对应输入轴转频齿面磨损会让边带能量明显抬升。这些特征全部位于高频段带宽不够的传感器根本无法支撑这个分析。1.3 IIS3DWB给出的答案IIS3DWB是ST专为工业振动监测设计的宽带宽加速度计。低噪声、6kHz平带带宽、最高几十kHz的ODR、±2g到±16g可测量程这几个参数摆在一起基本就是把状态监测四个字写在脸上了。配合高分辨率16位输出低速振动和高速微振都能在一个芯片里覆盖。实际拿到芯片后的第一反应是这颗芯片的寄存器配置和ST其他加速度计一脉相承老手基本可以无痛上手新手翻数据手册也能很快摸清。它的I2C地址是0x537位地址SA0接地写在代码里要左移一位变成0xA6。这个细节后面还会再提因为很多人卡在地址对不上这关。2. 选型逻辑STM32C5和IIS3DWB怎么搭起来2.1 STM32C5到底是什么定位STM32C5是ST C系列里把性能门槛抬上去的一档用的是Cortex-M33内核带FPU主频和资源都比C0、C2这一档明显阔绰。这颗芯片现在还是样片阶段渠道远没有F1、F4、G4那么铺得开电商平台基本搜不到现货我这边是通过代理申请样片拿到的。如果你也想复现最靠谱的路径是联系ST代理商或官网渠道申请样品别指望像买STM32F103一样随便下单。C5的定位很明确在成本敏感型应用里提供足够强的通用算力和连接外设。对震动采集这种传感器不断吐数据、MCU要跑滤波和FFT的场景M33内核的DSP扩展指令集其实很加分。我实测时直接在MCU侧做了16点滑动滤波和256点FFT运算压力并不大。2.2 与G4外设的差异I2C这块没有悬念网上老有人问STM32C5和G4外设差多少我实际对比下来就I2C外设而言两者几乎是一个模子刻出来的。C5的I2C控制器和G4用的是同一套设计思路都支持标准模式100kHz、快速模式400kHz都可以通过TIMINGR寄存器精细配置SCL高电平和低电平时间HAL库函数基本通用。做振动采集时你完全可以沿用G4上的I2C驱动经验。差异主要体现在定位上G4把大量资源砸在电机控制场景高级定时器、HRTIM、片内比较器、运放、CORDIC这些外设一应俱全C5则更偏通用连接和成本优化用M33内核换来了更高的性能功耗比。对IIS3DWB这个项目G4和C5在I2C能力上没有本质区别我选C5纯粹是想顺便评估这颗新芯片在通用数据采集场景里的表现。2.3 为什么这条Demo线先走IIC而不是SPIIIS3DWB其实支持I2C和SPI两种接口。SPI上限更高但需要多一根CS线接线和驱动都要多操心一层。我在Demo阶段选择IIC理由很实际两线制好接线逻辑分析仪抓时序方便上位机也好配合调试。但这里必须说一个吞吐量问题。IIS3DWB一次完整的三轴读取要拿6字节数据换算成I2C总线上的实际bit数大概是起始位7位地址读/写位寄存器地址8位重复起始7位地址6字节数据若干ACK/STOP粗算在80bit以上。400kHz模式下一次事务约需200多微秒1MHz快速模式plus下约80多微秒。这个数意味着ODR开到3.33kHz周期300微秒400kHz I2C勉强跟得上开到6.67kHz周期150微秒400kHz就明显扛不住想跑满26.67kHzIIC基本没戏必须上SPI。所以我这篇先用I2C把3.33kHz和部分6.67kHz场景跑通高ODR留给后一篇用SPI处理这也是连载里我要提前埋好的伏笔。3. 先把IIC物理层伺候明白占空比、空闲时间和上拉电阻3.1 时钟占空比不是50%对50%I2C调试翻车十有八九问题出在物理层而不是寄存器配置。先从时钟占空比说起I2C协议从头到尾都不要求SCL是50%占空比它只约束SCL低电平时间tLOW和高电平时间tHIGH的最小值。标准模式100kHz下tLOW要大于等于4.7微秒tHIGH大于等于4.0微秒快速模式400kHz下tLOW大于等于1.3微秒tHIGH大于等于0.6微秒。也就是说SCL一个周期里拉低的时间本来就比拉高更长没必要追求对称波形。STM32的I2C外设里TIMINGR寄存器分别给出SCLL和SCLH两个字段就是为了让你独立控制高低电平时间。用CubeMX配置时会自动计算但如果你手写寄存器初始化务必按I2CCLK的频率反推字段值。我遇到过有人拿STM32F1的软件I2C写法去套硬件I2C把SCL的周期设置成完全对称结果在400kHz模式下从机不认帧总线上一片混乱。3.2 总线空闲时间stop之后别急着startI2C时序里有一个经常被忽略的参数叫总线空闲时间tBUF指停止条件之后到下一次起始条件之间的最小间隔标准模式要4.7微秒快速模式要1.3微秒。用硬件I2C时控制器会在硬件层面处理这个间隔但如果你在GPIO模拟I2C或者频繁执行stop之后立刻发起下一笔事务的代码就要小心总线时序违规。我在早期调试时用HAL库频繁调用Master_Transmit接着Master_Receive中间machine代码如果插入大量延时反而不容易出问题。反而是想优化速度去掉所有延时之后总线偶发出现从机不响应。排查半天最后在逻辑分析仪上看到stop到start间隔只有几百纳秒明显违反tBUF。把CubeMX里I2C时序参数调到规范值问题就消失了。3.3 上拉电阻取多大从3mA法则到上升沿约束I2C是开漏总线上拉电阻的取值直接影响信号上升时间和抗干扰能力。选电阻有两个边界条件要同时满足下限由灌电流决定上限由上升时间决定。下限计算按最不利情况输出低电平时VOL0.4V灌电流IOL通常在3mA左右在3.3V系统下有Rmin (3.3 - 0.4) / 0.003 ≈ 967欧姆所以1k欧姆基本是3.3V系统下的底限再小会把从机的灌电流推到规格外。上限估算按总线电容和上升时间。快速模式要求上升时间最大300ns常见估算式是Rmax tr / (0.8473 × Cbus)如果板子走线不长、总线电容约150pFRmax约等于2.36k欧姆。所以1k到2.2k之间取2.2k是很稳妥的选择兼顾了上升沿速率和灌电流余量。我实际在3.3V供电、I2C排线15厘米以内的情况下用的就是2.2k上拉400kHz跑得很稳。如果总线电容因为长排线、多从机涨到300pF以上Rmax会降到1.2k以下和Rmin几乎没有余量这时候要么降速到100kHz要么缩短线缆这一点写在电路设计评审清单里非常值得。4. 代码实战用IIC把IIS3DWB的振动数据抠出来4.1 寄存器地图速览IIS3DWB的寄存器布局和ST主流加速度计一致核心就那几个地址。我整理了一张速查表寄存器地址作用WHO_AM_I0x0F芯片标识复位值0x7BCTRL10x20ODR、轴使能、连续模式CTRL20x21量程FS、IF_ADD_INCCTRL30x22中断配置、DRDY信号OUT_X_L0x28X轴加速度低字节OUT_X_H0x29X轴加速度高字节OUT_Y_L0x2AY轴加速度低字节OUT_Y_H0x2BY轴加速度高字节OUT_Z_L0x2CZ轴加速度低字节OUT_Z_H0x2DZ轴加速度高字节第一次读WHO_AM_I等于0x7B基本可以断定I2C链路和芯片上电都正常。如果读回0x00或0xFF别急着怀疑芯片坏了先检查供电、上拉电阻和地址方向。4.2 第一步先读WHO_AM_I证明链路活着CubeMX里把I2C1配成400kHz快速模式生成工程后第一段测试代码就是读ID。STM32C5的HAL库里I2C地址参数需要传入8位地址所以7位地址0x53要左移一位变成0xA6。uint8_t reg 0x0F; uint8_t id 0; HAL_I2C_Master_Transmit(hi2c1, (0x53 1), reg, 1, 100); HAL_I2C_Master_Receive(hi2c1, (0x53 1), id, 1, 100); if (id 0x7B) { // I2C链路正常芯片ID正确 } else { // 打印错误id会显示0x00或0xFF等异常值 }这段代码看着简单但它能一次性暴露三类问题地址有没有写错、上拉有没有接、芯片有没有正常启动。我在第5章会专门讲一次ID读回0x00的完整排查过程这里先不展开。4.3 配置量程与连续自增CTRL2是关键一步IIS3DWB的量程由CTRL2的FS位控制FS00是±2g01是±4g10是±8g11是±16g。对电机振动监测来说±8g是比较通用的起步档位既能覆盖启停机时的瞬态冲击也不至于把正常运行的微振淹没在量化噪声里。CTRL2里还有一个必须关注的位置IF_ADD_INC位bit2。这个位置1后从某个输出寄存器开始连续读多字节时内部地址指针会自动递增。否则你每次读一个字节地址都要重新设置一次效率和时序都会很难看。uint8_t config[2]; config[0] 0x21; // CTRL2 config[1] 0x14; // 0b00010100 FS10(±8g) IF_ADD_INC1 HAL_I2C_Master_Transmit(hi2c1, (0x53 1), config, 2, 100);0x14这个值我建议你在数据手册上核对一下位定义再写死不同批次寄存器布局可能有细微差异但ST的惯例是FS位保持在bit4~bit3、IF_ADD_INC在bit2。工程上最忌讳凭记忆写寄存器手册就在官网花两分钟翻一下心中有数。4.4 设置ODR与轴使能CTRL1CTRL1负责输出数据率和轴使能。以6.67kHz档位为例ODR字段对应0100bX、Y、Z三轴使能位全部置1组合出来大约就是0x47。写的时候先拼位再对着手册的ODR表确认数值六位数的头脑估算对这个场景没有意义。config[0] 0x20; // CTRL1 config[1] 0x47; // ODR0100b(6.67kHz) XYZ轴全使能 HAL_I2C_Master_Transmit(hi2c1, (0x53 1), config, 2, 100);这里要注意I2C的吞吐量约束。6.67kHz对应的采样周期是150微秒而400kHz I2C读一次完整6字节耗时超过200微秒所以严格意义上你无法每个ODR周期都抓取一帧。实际调试时我通常把ODR降到3.33kHz用400kHz IIC读采样周期300微秒、读事务约200微秒能稳定追帧。想跑更高ODR请准备好SPI。4.5 多字节连续读并换算成g值核心读取代码不长。地址指到0x28然后一次收6字节因为IF_ADD_INC已经使能地址会自动从X轴低字节一路递增到Z轴高字节。uint8_t reg 0x28; uint8_t buf[6]; HAL_I2C_Master_Transmit(hi2c1, (0x53 1), reg, 1, 100); HAL_I2C_Master_Receive(hi2c1, (0x53 1), buf, 6, 100); int16_t raw_x (int16_t)((buf[1] 8) | buf[0]); int16_t raw_y (int16_t)((buf[3] 8) | buf[2]); int16_t raw_z (int16_t)((buf[5] 8) | buf[4]); // ±8g量程下的灵敏度典型值约为0.244 mg/LSB float x_g raw_x * 0.000244f; float y_g raw_y * 0.000244f; float z_g raw_z * 0.000244f;拼接时务必记住IIS3DWB是小端输出低字节在前。我见过有人按大端方式拼结果静止时数据零点漂移几千个LSB还以为是传感器坏了。量程和灵敏度的对应关系是固定的我放在表里方便你直接查FS量程灵敏度00±2g0.061 mg/LSB01±4g0.122 mg/LSB10±8g0.244 mg/LSB11±16g0.488 mg/LSB到这里震动计数据就算真正抠出来了。后面无非是滤波、FFT、时域特征统计这些和传感器读取本身已经解耦。5. 实测路上的几个坑总线挂死、0x7B之谜和数据毛刺5.1 坑一上电立刻读WHO_AM_I返回0x00第一次把程序烧进STM32C5复位后立刻跑I2C读ID读回来的不是0x7B而是0x00。我当时第一反应是焊接问题拿万用表量了VDD、量了SDA上下拉波形都正常。逻辑分析仪抓到的地址帧也正确ACK也有但从机回的数据就是0。排查到最后才发现问题出在时序上MCU复位后执行到I2C读ID的效率太高快到IIS3DWB内部还没完成上电初始化。传感器上电到可以响应I2C查询需要一小段启动时间几十毫秒量级。解决办法就是在复位后加一个足够长的延时或者干脆读ID失败后延时再重试一次。HAL_Delay(50); // 等传感器内部初始化完成 // 然后再执行I2C读WHO_AM_I这个坑很小但很有代表性。传感器和MCU是两个独立的上电时序不要想当然认为我复位了外设也复位了。外设的启动时间要看手册里的上电特性表格尤其是这种带MEMS核心的芯片。5.2 坑二调试烧录后I2C总线被从机拉死项目做到一半调试器反复烧录程序后I2C通信突然卡死在HAL_I2C_Master_Transmit的超时等待里。用逻辑分析仪看SDA一直处于低电平SCL还在正常跳。这是非常典型的I2C总线挂死场景上一次通信中途主机突然停止发送从机正好在应答阶段把SDA拉低总线被一个不知道什么时候结束的ACK状态锁死。解决思路分两步。第一步软件复位I2C外设并重新初始化GPIO把引脚从复用模式切回GPIO输出然后手动翻转SCL输出9个脉冲让从机复位内部状态机。第二步查自己代码里是否有通信中途异常退出的路径比如超时返回时没有收尾。HAL库的I2C超时机制本身会返回错误但外设状态机器不一定被正确复位所以我在每个事务结束后加了一个外设状态检查。if (HAL_I2C_GetState(hi2c1) ! HAL_I2C_STATE_READY) { __HAL_I2C_DISABLE(hi2c1); // 重新初始化I2C外设 }还有一个经验烧录程序前先断开I2C排线或者把MCU的I2C引脚在调试阶段配置成带上拉的GPIO输入能从源头上减少烧录器复位导致总线锁死的概率。调试器复位整个芯片时外设引脚状态不可控这是I2C调试阶段最容易忽略的坑。5.3 坑三静止状态下数据也在几百LSB范围抖动传感器贴在桌面上三轴数据也有几百LSB的跳动当时差点怀疑买到问题芯片。后来翻手册发现IIS3DWB本身是宽带宽、低噪声设计它的噪声指标比普通窄带加速度计更适合做振动分析但代价就是你拿一个普通万用表或者低速采集逻辑去看它会觉得噪。这不是故障是传感器把微小振动和电噪声都如实呈现了。排查思路是先排除供电问题给传感器单独加一个10μF钽电容并靠近VDD引脚如果跳动明显下降说明是电源纹波通过参考地串进来了。再看接线杜邦线比双绞屏蔽线更容易引入工频干扰拿FFT看频谱50Hz附近有尖峰就基本实锤。最后是实际验证用一个已知振源比如手机线性马达对比IIS3DWB和自己参考传感器的FFT幅值确认读出来的频点是否一致。另一个与数据质量直接相关的点是ODR和带宽的匹配。我调成3.33kHz ODR去测一个4kHz附近的冲击信号频谱里出现了明显的镜像峰这就是混叠。把信号频段控制在ODR的0.4倍以内或者直接换更高ODRSPI读取才能得到让人放心的频谱。最后再说一个调试小技巧整个项目调试下来我最大的体会是I2C调试千万不能盲调。有条件一定上逻辑分析仪哪怕是几十块钱的USB逻辑分析仪也够了。看I2C波形不需要多高的采样率400kHz总线下有个8MHz采样率就绰绰有余。每次通信异常先抓波形看地址对不对、ACK有没有、数据是0x00还是0xFF、总线有没有被拉死四类问题五分钟内就能分清。至于下一篇我会把IIS3DWB的SPI模式和更高ODR数据采集补上顺带对比一下IIC和SPI在高频振动采集场景下的实际差距。到时候你会发现传感器选型是一回事接口选对是另一回事而把这两件事想明白震动监测方案才真正立得住。