STM32C5轮询读取LSM6D3TR-C陀螺仪数据：从寄存器配置到物理量换算

1. 项目概述与选型背景

1.1 这颗芯片和传感器组合的来龙去脉

STM32C5是意法半导体近期主推的入门级Cortex-M33内核MCU系列，主频能跑到250MHz级别，片内集成FPU和DSP指令集，放在几年前这配置妥妥是中高端定位，现在下放到入门系列，性价比确实能打。相比老一代F系列，C5在功耗控制、安全特性和外设丰富度上都有明显升级，尤其是硬件TrustZone隔离和大量UART/I2C/SPI实例，做多传感器采集节点非常顺手。

LSM6D3TR-C则是ST在2023年前后推向市场的六轴惯性测量单元（IMU），集成了三轴加速度计和三轴陀螺仪。这颗料的核心卖点是低功耗和高精度，加速度计满量程可配±2/±4/±8/±16g，陀螺仪满量程从±125dps一路到±2000dps，基本覆盖从消费电子到工业监测的绝大多数场景。它内部还带了一个3KB的FIFO，可以边采边存，主控睡大觉，攒一批再唤醒搬运，这对低功耗项目来说相当关键。

标题里点明的是“轮询获取陀螺仪数据”，也就是最简单直接的工作模式——主控定时去读传感器输出寄存器，不做中断也不开DMA。对于刚接触这颗传感器或者想快速验证硬件通路是否正常的开发者来说，轮询模式是最容易跑通的第一步。同时，轮询虽然看起来不如中断和DMA“高级”，但在某些场景下它反而是最优解，这个后面专门展开讲。

1.2 为什么需要单独讲轮询方式

不少初学者一上来就追求“高性能架构”，恨不得中断+DMA+FIFO全套上阵，结果变量竞争、缓存一致性问题、调试困难一堆问题冒出来，最后连数据对不对都不敢确定。我个人的经验是：任何传感器驱动，先把轮询模式跑稳、数据读到并换算成物理单位，再做中断或DMA优化。原因有三：

第一，轮询模式下代码执行路径是线性的，出问题容易定位——要么I2C通信失败，要么寄存器配错，要么换算公式写错，排查范围非常小。第二，轮询模式天然适合低速率采样场景，比如100Hz以下的姿态监测、倾角报警、振动特征分析，MCU完全跑得过来，没必要让中断频繁打断主流程。第三，轮询暴露的是传感器最底层的“实时”输出行为，你可以用逻辑分析仪或调试器观察数据更新节奏，这对理解传感器内部工作机制非常有帮助。

而且轮询模式写好了，后面切换到中断或FIFO时，寄存器配置的90%代码是可以直接复用的，只是在“何时去读”这个策略上换一种触发方式而已。所以这篇博文虽然只是在讲“轮询”，但实际上是整个LSM6D3TR-C驱动开发的地基工程。

2. 核心硬件与通信机制解析

2.1 STM32C5与LSM6D3TR-C的硬件接线

先看引脚。LSM6D3TR-C是LGA-14L封装，3mm x 2.5mm，小得跟芝麻似的，手工焊接稍有手抖就飞件，建议直接画进PCB或者用转接板。电源部分VDD接1.71V到3.6V，I/O电平由VDD_IO决定，如果MCU是3.3V系统，直接两者共用一个3.3V就行，不需要额外的电平转换。

通信接口方面，这颗传感器同时支持I2C和SPI，通过芯片的CS引脚进行选择——CS拉高走I2C，CS拉低走SPI。标题项目用的是I2C，所以CS必须上拉到VDD_IO，否则通信模式会错乱。SDA和SCL各接一个10kΩ到4.7kΩ的上拉电阻，具体阻值取决于总线速率和你线缆的寄生电容，标准模式400kHz（Fast Mode）下10kΩ一般没问题，如果总线上挂了多个设备导致沿变缓，降到4.7kΩ或者2.2kΩ。

I2C地址这块需要注意。LSM6D3TR-C的7位I2C地址是110101x，最后一位由SA0引脚的电平决定。SA0接地时地址是0x6A，SA0接VDD_IO时是0x6B。注意这是7位地址，在STM32的HAL库里你通常需要左移一位变成8位地址：0x6A对应的8位写地址是0xD4，读地址是0xD5；0x6B对应0xD6/0xD7。不过HAL库的I2C函数要么接收7位地址（HAL_I2C_Mem_Read直接传0x6A即可），不会帮你移位，这里不要搞混。

我在实际项目中踩过一次坑——画PCB时SA0悬空没处理，结果芯片内部检测到这个脚是浮空电平，有时识别成0x6A有时识别成0x6B，导致设备时有时无。SA0这个脚一定要明确接高或接低，不要悬空。

2.2 寄存器读写时序与BDU机制

无论轮询、中断还是DMA，读取LSM6D3TR-C的数据都绕不开它的寄存器映射。首先WHO_AM_I寄存器（地址0x0F）固定返回0x6A，这是确认I2C通信是否正常、设备是否正确枚举的第一道关卡。代码启动后第一件事就是读它，读不到或者值不对，后面全白搭。

LSM6D3TR-C的陀螺仪数据输出寄存器是OUTX_L_G（0x22）和OUTX_H_G（0x23），各8位，合成一个16位有符号数。加速度计对应的是0x28/0x29（X轴）。这里有个关键设计——Block Data Update（BDU）机制，对应CTRL3_C寄存器（0x12）的BDU位。当BDU = 1时，传感器在读取期间会锁存输出寄存器，确保你先读低字节、再读高字节的这个过程中，数据不会因为新的转换结果而更新，避免高低字节来自不同采样时刻造成的数据撕裂。

轮询模式下BDU尤其重要。因为轮询的节奏不可能和传感器内部数据更新精确对齐，如果没有BDU，你可能刚读完0x22的旧数据，传感器恰好更新了寄存器，然后你读0x23时读到了新数据的高字节，最后拼出来的数值既不是上一个采样点也不是当前采样点。BDU置1后，读取低字节那一刻会锁存整组数据，直到你读走高字节才解除，这是非常优雅的硬件级一致性保障。做陀螺仪数据采集，BDU必须置1，这是我在所有项目中的铁律。

3. 软件架构与初始化流程

3.1 基础工程配置：I2C外设参数选择

这里以STM32CubeIDE + HAL库为例（用LL库也类似，但HAL在黑盒调试阶段更友好，出错信息更直观）。第一步就是用STM32CubeMX生成基础工程，配置I2C1外设。几个关键参数：

• I2C速度模式选择Fast Mode，目标频率400kHz。LSM6D3TR-C最高支持400kHz（Fast Mode），理论上SPI能跑到10MHz，但I2C场景下400kHz够用了。不要试图超频到1MHz Fast Mode Plus，这颗传感器不支持，通讯会不稳定。
• 时钟源选内部时钟就行，不需要额外的I2C专用时钟源。
• 如果STM32C5主频跑到250MHz，注意I2C外设时钟预分频系数要设置正确，否则SCL实际频率会偏离你设定的400kHz目标值。可以在调试模式下拿示波器实测SCL波形，这个习惯我一直保持，因为HAL库对分频器的自动计算偶有边界场景误差。

引脚分配上，I2C1通常默认走PB6（SCL）和PB7（SDA），这是C5上面I2C1的默认映射。如果你板子上这两个脚被其他功能占用，可以改到PB8/PB9或者PF1/PF0，但CubeMX里要手动指定Alternative Function，同时确认目标引脚是否有5V容忍特性，避免电平不符把传感器烧了。

3.2 传感器初始化序列：代码与解释

初始化序列是传感器驱动最核心的部分，寄存器配置错了传感器要么不工作，要么输出数据完全是乱的。我根据自己的实测经验整理了一套比较稳的初始化流程，分四步走。

第一步，WHO_AM_I自检。用HAL_I2C_Mem_Read读寄存器0x0F，期望值是0x6A。如果读到的值和预期不符，不要继续往下走，停下来检查接线、地址、焊接。特别提醒：如果你用的是LSM6DSO、LSM6DSV等型号，WHO_AM_I寄存器值是不同的（分别是0x6C、0x6B等），代码里的校验值要跟着芯片型号走，很多人照搬例程结果卡在这一步。

第二步，软件复位。往CTRL3_C（0x12）的SW_RESET位写1，然后等待该位自动清零。复位过程大约需要几十微秒到几毫秒，稳妥的做法是循环读该寄存器，直到SW_RESET位归零。复位之后所有寄存器恢复默认值，确保芯片处于已知状态。

第三步，配置陀螺仪。陀螺仪的主控寄存器是CTRL2_G（0x11），其中ODR_G位段选择输出数据率，FS_G位段选择满量程。比如我要配成1.66kHz输出率、±250dps满量程，就往CTRL2_G写0x88。为什么优先选±250dps？因为在满量程范围内，量程越小分辨率越高，±250dps下陀螺仪灵敏度是8.75mdps/LSB，而±2000dps下只有70mdps/LSB。如果你的应用场景不会有超过250dps的角速度（正常手持设备剧烈转动峰值也就几百度每秒），就用最小量程换最高精度。

第四步，开启BDU并确认电源模式。往CTRL3_C（0x12）写0x44，其中bit7是BDU，bit6是IF_INC（寄存器地址自动递增，多字节读取时非常关键，必须置1）。同时确认传感器处于正常模式（而非断电模式或低功耗模式），CTRL1_XL和CTRL2_G的ODR位段不能全为0。

完整初始化代码大致长这样：

uint8_t who_am_i = 0; HAL_I2C_Mem_Read(&hi2c1, LSM6D3TR_I2C_ADDR, 0x0F, I2C_MEMADD_SIZE_8BIT, &who_am_i, 1, 100); if (who_am_i != 0x6A) { // 设备ID校验失败，上报错误并停止初始化 return -1; } uint8_t ctrl3_c = 0x01; // SW_RESET = 1 HAL_I2C_Mem_Write(&hi2c1, LSM6D3TR_I2C_ADDR, 0x12, I2C_MEMADD_SIZE_8BIT, &ctrl3_c, 1, 100); do { HAL_I2C_Mem_Read(&hi2c1, LSM6D3TR_I2C_ADDR, 0x12, I2C_MEMADD_SIZE_8BIT, &ctrl3_c, 1, 100); } while (ctrl3_c & 0x01); // 等待软件复位完成 ctrl3_c = 0x44; // BDU=1, IF_INC=1 HAL_I2C_Mem_Write(&hi2c1, LSM6D3TR_I2C_ADDR, 0x12, I2C_MEMADD_SIZE_8BIT, &ctrl3_c, 1, 100); uint8_t ctrl2_g = 0x88; // ODR=1.66kHz, FS=±250dps HAL_I2C_Mem_Write(&hi2c1, LSM6D3TR_I2C_ADDR, 0x11, I2C_MEMADD_SIZE_8BIT, &ctrl2_g, 1, 100);

注意：软件复位之后，所有寄存器都会恢复默认值，所以BDU和陀螺仪配置必须放在复位完成之后设置。如果你复位后马上配置，有极小概率配置写入和复位操作竞争导致寄存器没写进去，稳妥做法是在复位等待之后加一个短暂的延时（比如1ms），让芯片内部状态机彻底稳定。

3.3 为什么CTRL3_C里的IF_INC必须置1

IF_INC这个位是“寄存器地址自动递增”的开关，它在多字节读取场景下直接决定了代码效率。置1之后，你从0x22开始连续读6个字节，传感器内部地址会自动从0x22跳到0x23再到0x24...0x27，你可以用一个I2C突发读搞定X、Y、Z三个轴的完整数据。如果这个位是0，你必须每个寄存器单独发起一次I2C事务，也就是要读6次寄存器、发6次START/STOP条件、等6次应答，总线的有效吞吐量直接砍半还多。

更重要的是，突发读取天然保证了一组数据的一致性。如果你分别读三个轴，而传感器在这三次读取之间恰好完成了一次数据更新，那么你得到的三轴数据就不是同一个时刻的，这会直接导致姿态解算的结果出现抖动和偏差。虽然BDU机制保证了“单个轴高低字节”的一致性，但跨轴的一致性必须靠突发读取来保证。所以IF_INC置1不是建议，是必须。

4. 轮询采集的完整实现

4.1 轮询策略：频率匹配与数据状态判断

轮询的关键词是“节奏”。传感器内部以固定的ODR（Output Data Rate）更新数据，比如我们配置的1.66kHz。主控侧轮询的频率最好和ODR匹配，或者比ODR略快一点。但轮询太快了也只是读到重复的旧数据，白费CPU和I2C总线带宽；轮询太慢了则会漏掉更新，相当于降采样。

常规做法是用定时器产生一个固定频率的中断或标志位，在定时器回调里触发一次读取。比如传感器ODR是1.66kHz，你可以把定时器配到同样1.66kHz或者略微高一点（比如2kHz），然后在主循环里检查标志位，标志位置位了就执行一次读取。这样读取节奏完全是确定的，不会因为其他任务耗时不同而导致采样间隔抖来抖去。

不过还有一种更省心的方案——轮询STATUS_REG寄存器（0x1E）的XLDA/GDA位。GDA是陀螺仪数据可用标志，当新的陀螺仪数据准备好时硬件自动置1，读数据寄存器后自动清零。你可以在主循环里反复读STATUS_REG，发现GDA为1就立刻读取陀螺仪数据，否则继续等待。这种方式叫作“状态轮询”，它保证了你每次读到的都是新数据，绝不会读到同一个旧值两遍。

状态轮询和固定频率轮询怎么选？我的建议是：如果主循环足够空，用状态轮询最省心，代码逻辑也最直观；如果系统里还有其他优先级更高的任务，用固定频率轮询配合定时器更合理，但需要注意ODR匹配问题。下面我两种方案都给出来。

4.2 轮询读取代码：状态寄存器方案与定时器方案

状态寄存器方案的代码逻辑非常清晰：

uint8_t status; int16_t gyro_raw[3]; uint8_t data[6]; while (1) { // 读取状态寄存器，检查陀螺仪数据是否就绪 HAL_I2C_Mem_Read(&hi2c1, LSM6D3TR_I2C_ADDR, 0x1E, I2C_MEMADD_SIZE_8BIT, &status, 1, 100); if (status & 0x02) { // GDA 位 = 1，新数据就绪 // 连续读取 0x22~0x27 共6字节，陀螺仪X/Y/Z HAL_I2C_Mem_Read(&hi2c1, LSM6D3TR_I2C_ADDR, 0x22, I2C_MEMADD_SIZE_8BIT, data, 6, 100); gyro_raw[0] = (int16_t)((data[1] << 8) | data[0]); // X轴 gyro_raw[1] = (int16_t)((data[3] << 8) | data[2]); // Y轴 gyro_raw[2] = (int16_t)((data[5] << 8) | data[4]); // Z轴 // 转换为物理单位并输出 float gyro_dps[3]; gyro_dps[0] = gyro_raw[0] * 8.75f / 1000.0f; // mdps/LSB -> dps gyro_dps[1] = gyro_raw[1] * 8.75f / 1000.0f; gyro_dps[2] = gyro_raw[2] * 8.75f / 1000.0f; } }

注意拼接顺序：LSM6D3TR的输出寄存器采用小端字节序，L（低字节）在前，H（高字节）在后，所以组合时要把高字节左移8位再或上低字节。这里有个新手的经典错误——搞反高低字节顺序，导致数据跳变巨大且毫无规律。在调试阶段可以在静止状态下看输出，如果读数在0附近小幅波动，说明字节序对了；如果读数是一个巨大且剧烈跳动的量级（比如几万），大概率是高低估反了。

定时器方案的定时器回调部分如下：

volatile uint8_t gyro_sample_flag = 0; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM6) { gyro_sample_flag = 1; } } while (1) { if (gyro_sample_flag) { gyro_sample_flag = 0; // 执行读取，代码同上 read_gyro_data(); } }

在STM32C5上，TIM6是基本定时器，仅用于定时，非常适合这种周期采样任务。配成1.66kHz的更新率，也就是ARR值根据定时器时钟算好：简单口算公式是CNT_CLK / (PSC+1) / (ARR+1) = 目标频率，具体数值根据时钟树分配后的定时器时钟源定。

4.3 原始数据到物理单位的换算逻辑

陀螺仪原始输出是16位有符号整数（int16_t），取值范围在-32768到32767之间，这个裸值没什么直观意义，必须乘上灵敏度系数才能得到角速度（dps，度每秒）。

灵敏度系数由满量程决定，对应关系如下表：

以±250dps量程为例，原始值乘以8.75再除以1000就是角速度值。举个直观的例子：传感器绕Z轴以100dps的角速度旋转时，Z轴原始输出大约在11428左右；如果传感器静止不动，理想情况下三轴输出都是0，但实际因为零漂效应，读出来的原始值可能在±几十LSB范围内浮动，换算出来就是几mdps级别的微小角速度，这是正常的偏置误差，可以通过标定来消除。

换算代码里有个性能小技巧：如果MCU带FPU（C5是有的），直接用浮点乘法没问题；但如果你移植到没有FPU的MCU上，建议先把原始值转成定点运算，比如乘以875除以100000，这样可以避免软浮点带来的性能损耗。对于精度要求不高的场景，或者读数变化率本来就很小的场景，你甚至可以只在最终显示或传输时做浮点换算，核心控制循环里全部走整数运算。

5. 轮询的时序分析与数据一致性保障

5.1 在STM32C5上精确控制采样节奏

进阶问题来了：轮询模式如何保证“每次读取的时刻”和传感器ODR对齐？严格的采样理论要求等间隔采样，如果间隔抖动太大，频谱分析时会出现额外的噪声旁瓣，这在振动监测和机械故障诊断场景里是致命问题。

我在STM32C5上实测发现，状态轮询方案在单任务裸机环境下表现很好——因为主循环一直在刷STATUS_REG，GDA标志置位后通常能在几十微秒内（总线速度400kHz时，读一次STATUS_REG大约需要50μs）完成响应，相当于采样抖动不超过一个I2C读取周期，基本可以忽略。但如果你的主循环里还有其他耗时操作（比如刷屏、写SD卡、跑加密算法），GDA置位后可能要拖到几百微秒甚至几毫秒才能被响应到，这个延迟就是采样抖动，而且抖动幅度和主循环任务耗时直接相关。

解决办法有两种路径。第一，在主循环里把读取操作放在最高优先级的位置，也就是所谓的“查询循环结构”中，确保从GDA置位到执行读取的路径最短。第二，直接用定时器固定频率读取，不去关注GDA标志——这种做法本质上就是软件层面的“恒定速率采样”。注意，定时器频率要略低于ODR（比如ODR 1.66kHz就用1kHz去读），如果定时器频率高于ODR，你就会重复读到同一份数据，判断新数据的逻辑就需要加上“只处理GDA标志”的条件。

更完美一点的方案是用传感器的内部中断引脚（INT1）驱动一个外部中断，读取时刻由传感器硬件精确触发，主控侧只需要在中断回调里标记一个标志位然后去读就行，这个就是中断模式了。轮询和中断的取舍很微妙：如果你的系统允许传感器“什么时候更新你什么时候读”，用中断；如果系统要求“我必须每1ms读一次”，用定时器轮询更合适。没有绝对的优劣，只有是否匹配你的应用模型。

5.2 为什么BDU位能让数据不撕裂

前面说了BDU的原理，这里用一个具象化的场景加深理解。假设BDU = 0，也就是关闭锁存功能，传感器每个ODR周期都在更新输出寄存器。你在某个时刻发起一次连续读取，先读0x22（X轴低字节），此时X轴低字节是上一个采样周期的旧值；然后读0x23（X轴高字节）之前，传感器刚好完成了新一轮更新，0x23被写入新值的高字节。最终你拼凑出的X轴数据，低字节是旧值、高字节是新值，这个数值既不是上一个时刻的X轴角速度也不是当前时刻的，它有可能超出物理上可能的角速度范围，比如读出个每秒几万度的离谱值。

打开BDU之后，传感器在检测到I2C主机读取低字节寄存器时，会把当前所有输出寄存器快照锁存起来。后续你读高字节和其他轴，读到的都是锁存的快照，直到这组6字节全部读完之后锁存解除。下次更新周期到来时，新数据才会写入寄存器。

我在测试中验证过这个行为：BDU=0时，静态放置的传感器偶尔会蹦出一个偏离正常值几个标准差的毛刺点；BDU=1后，同样的数据流干净多了，毛刺完全消失。这个毛刺不是传感器本身的噪声，而是数据撕裂造成的伪信号。如果后续你要做卡尔曼滤波或互补滤波，这种毛刺对滤波器收敛性的破坏尤为明显。

5.3 轮询和FIFO的区别与联系

LSM6D3TR-C内置3KB FIFO，其实很大程度上就是为了弥补轮询模式的不足。FIFO模式下，传感器以ODR持续采样并把数据推进FIFO缓冲区，主控可以隔一段时间（比如攒了30个样本）一次性批量读取。这样主控大部分时间可以处于休眠状态，或者忙着处理其他事务，只在需要的时候快速搬走一批数据。

FIFO模式的代价是数据实时性变差——你读到的是“历史的”一段数据，而不是“当前”的数据。所以FIFO适合数据后处理场景（比如姿态记录仪、跌落检测、振动数据采集），而轮询/中断模式更适合实时反馈场景（比如稳定云台、平衡车姿态控制）。

对于LSM6D3TR-C这颗传感器的FIFO使用，我建议放在轮询驱动稳定之后再做。先跑通轮询，确认传感器硬件正常、寄存器配置正确、数据换算合理，心里有底了再切换FIFO批量读取模式。一次性直接上FIFO，遇到问题你会分不清是配置问题还是批量读取逻辑问题，调试成本会高不少。

6. 实踩问题与排查手册

6.1 I2C通信故障的定位思路

这是最多人卡住的地方。传感器不响应、读WHO_AM_I超时或者读到0xFF，绝大多数情况下是硬件问题而不是代码问题。我按照排查优先级列一个速查表：

最常见也最隐蔽的问题是“SCL波形对、SDA波形对、但就是通信超时”——这种情况十有八九是I2C地址搞错了。注意LSM6D3TR-C的数据手册里给的地址是“110101x”，写在寄存器说明里的是7位格式，而HAL库函数需要的是8位（左移一位后的）地址。两种格式混用会让I2C控制器永远在等待一个不存在的设备应答，直到超时。

6.2 陀螺仪输出异常跳变或恒为0

如果你的轮询程序能跑通，但读出来的陀螺仪数据有问题，分两种情况分析。

第一种情况，三轴输出恒为0。先检查ODR配置——CTRL2_G寄存器的高4位是ODR_G，如果这些位全是0，说明陀螺仪处于掉电模式，不会产生任何数据。这是非常常见的配置遗漏：有些人只配了量程没配采样率，导致传感器一直处于睡眠状态。另外确认一下你操作的是CTRL2_G（陀螺仪配置寄存器）而不是CTRL1_XL（加速度计配置寄存器），两个寄存器位定义很像，新手上手容易看串行。

第二种情况，数据剧烈跳动、量级远超物理极限。首选怀疑字节序拼反或者符号扩展错误。LOW寄存器是低8位，HIGH寄存器是高8位，组合时要(int16_t)((high << 8) | low)，如果写成(int16_t)((low << 8) | high)，数据看起来会是无规律的大数值跳变。再检查是否使用了BDU，如果BDU没开启，数据撕裂也会造成离谱读数。另外，如果是焊接不良导致某个引脚接触电阻变大，数据也会有明显异常，但这种问题在其他外设上同样会暴露，不属于传感器驱动本身的问题。

6.3 零漂与标定：从原始值到可用数据

陀螺仪零漂是MEMS传感器的固有特性，主要体现在两个方面。第一是上电后的静态偏置：传感器静止时，理论上三轴输出应该为0，但实际会有一个固定的偏置值，可能是几mdps到几十mdps不等。第二是温漂：温度变化会让偏置缓慢移动。

解决零漂问题的常规做法是“上电静止标定”——在系统启动后保持设备绝对静止1到2秒，采集N个样本取平均，把这个平均值作为零偏，后续每个样本都减去这个零偏。这个步骤对于做姿态解算的应用来说是刚需，否则积分会产生严重的累积漂移。

标定的实现代码很简单：

float gyro_offset[3] = {0, 0, 0}; #define CALIB_SAMPLES 200 void gyro_calibrate(void) { int32_t sum[3] = {0, 0, 0}; for (int i = 0; i < CALIB_SAMPLES; i++) { read_gyro_data(); // 读取原始值并存到全局 sum[0] += gyro_raw[0]; sum[1] += gyro_raw[1]; sum[2] += gyro_raw[2]; HAL_Delay(2); } gyro_offset[0] = (float)sum[0] / CALIB_SAMPLES * 8.75f / 1000.0f; gyro_offset[1] = (float)sum[1] / CALIB_SAMPLES * 8.75f / 1000.0f; gyro_offset[2] = (float)sum[2] / CALIB_SAMPLES * 8.75f / 1000.0f; }

标定完成后，每次读取的物理值都要减去对应的零偏量。另外提醒一点：每次上电后零偏可能都有细微变化（因为芯片温度不同），所以标定要在每次系统初始化时执行，而不是烧录后只标一次。如果你的应用环境温差很大（比如冬天从室外拿到室内），可以考虑加一个简单的温度补偿模型，但那是后话，这里先不展开。

7. 从轮询到进阶：后续优化方向

轮询模式跑通了，传感器数据能正确读出来，接下来有几个方向可以深入。

第一是上文提到过的FIFO模式。配置FIFO为连续模式（Continuous Mode），传感器持续采样并填充内部缓冲区，每产生一定数量样本或者缓冲区达到阈值时，可以通过STATUS_REG的FIFO_THRESHOLD标志位获知状态，然后主控一次性批量读取。这在低功耗设计中几乎是必选项，因为MCU可以大部分时间留在低功耗模式，只在FIFO接近满时被唤醒搬数据，理论上平均功耗能降低一个数量级以上。

第二是中断模式。传感器可配置输出多种中断信号，包括数据就绪（DRDY）、FIFO阈值触发、惯性唤醒（Wake Up）、姿态变化检测（6D/4D Orientation）等，信号通过INT1或INT2引脚输出。使用中断模式可以让主控在陀螺仪没有新数据时完全不去操作I2C总线，系统效率更高。

第三是数据质量提升。轮询跑通只是入门，真正工程化还需要考虑：传感器安装误差校准（六面标定法对加速度计和陀螺仪的轴对齐进行修正）、陀螺仪零偏温漂补偿、低通滤波抑制高频噪声（ST在这颗传感器内部已经带了可配置的低通滤波器，通过CTRL6_C寄存器配置）、以及更高层级的姿态融合算法（互补滤波、Mahony算法或卡尔曼滤波）。

我在实际项目中感受最深的一点是：驱动开发最忌“一步到位”，把所有高级特性一次性堆上去。熟练跑通轮询，你已经解决了90%的通信和配置问题，剩下的不过是时序策略层面的优化。先把地基打牢，后面怎么盖楼都不慌。

最后分享一个小经验：调试这类I2C传感器时，如果条件允许，尽量在SCL和SDA线上预留测试点或者飞线，调试阶段挂上逻辑分析仪，把通信帧内容抓出来和寄存器手册一一对照，很多“诡异”的问题立刻就能看清真相。我这块STM32C5开发板上额外加了双排针引出I2C引脚，排查问题的时候省了太多事。