STM32C5+LSM6D3TR-C陀螺仪轮询读取实战：寄存器配置与踩坑记录

最近在ST新一代的STM32C5系列上做一个姿态感知项目，传感器选了LSM6D3TR-C。这篇文章是这个系列的第一篇，先把最基础的轮询读取陀螺仪数据这条路完整走通：硬件连接、寄存器配置、代码实现、实测结果，以及调试过程中踩过的几个比较典型的坑。为什么把轮询放在第一篇？因为它能逼你把传感器的数据通路彻底搞清楚，后续再切中断、FIFO或者加姿态解算算法，都是在通路已经打通的前提下叠加上去。

1. 为什么是STM32C5和LSM6D3TR-C：选型背后的几个考虑

1.1 STM32C5系列对传感器项目意味着什么

ST的STM32C5系列属于新一代基于Arm Cortex-M33内核的主流MCU，主频最高能到250MHz级别，不同型号的Flash/RAM配置差别挺大，但整体定位就是面向工业控制、物联网边缘节点和需要一定算力的传感器应用。相比老牌的F4系列，C5在几点上有明显优势：Cortex-M33带了FPU和DSP指令，做浮点姿态解算的时候不用像F1那样靠软件模拟硬算；TrustZone和安全启动能力对需要保护固件的产品是刚需；另外主频上来了，意味着同一个IO口上既能跑传感器采集，还能顺便跑个轻量级算法，不用像以前那样动辄上双MCU。

选型的时候我也对比过G4系列，G4在模拟外设和电机控制上更强，但就纯传感器数据采集这个场景，C5的性价比和低功耗表现更合适。当然，如果你手里已经有F4的板子，这篇的代码逻辑也可以直接搬过去，I2C和GPIO的差异不会影响传感器驱动的移植。

1.2 LSM6D3TR-C这颗传感器取代了谁

LSM6D3TR-C是ST出品的一颗低功耗六轴惯性传感器，三轴陀螺仪加三轴加速度计集成在一个非常小的封装里，典型场景是可穿戴设备、TWS耳机、工业状态监测、机器人姿态估计。这颗料和经典的LSM6DS3TR-C在寄存器层面兼容度非常高，数据手册里的寄存器映射基本可以对照阅读，如果你以前调过LSM6DS系列，那上手的心理负担可以放下一半。陀螺仪支持±125、±250、±500、±1000、±2000 dps五档量程（标题配置里我用了2000dps），输出是16位有符号补码，I2C接口最高能跑400kHz，SPI接口能跑更快，功耗数据在当前六轴IMU里也算第一梯队。

有人可能会问，既然和LSM6DS3TR-C那么像，为什么还要单独写一篇？答案很朴素：实际项目里换新料、换新MCU平台，就算寄存器兼容，I2C时序、初始化序列、电源域配置这些细节仍然要重新验证一遍。这篇记录的过程，就是我在STM32C5上重新把LSM6D3TR-C陀螺仪数据读出来的完整复盘。

1.3 为什么第一篇先用轮询模式

很多做传感器的朋友一上来就上中断、开FIFO，觉得轮询太初级。但我的看法是：轮询是最直接的数据通路验证手段。中断方式要处理EXTI配置、中断服务函数里做I2C读取（或者只置标志位丢到主循环），一旦数据不对，你很难分清是传感器配置问题还是中断链路问题。轮询把问题域缩小到：寄存器配置是否正确、I2C读写是否正确、数据处理是否正确三个环节，排查起来非常清爽。

轮询也不是只能在Demo里用。如果你的采样率不高，比如100Hz的陀螺仪数据用于姿态估计，主循环里每10ms读一次，CPU占用率并不高；真正的高频姿态解算动辄上千Hz，那时候再考虑FIFO和DMA也不迟。先跑通轮询，把传感器摸熟，再上复杂机制，这个顺序是我一直推荐的。

2. 硬件连接与底层基础准备

2.1 引脚分配与原理图要点

STM32C5和LSM6D3TR-C之间我选择了I2C接口，原因很实际：引脚占用少，两根线就够，100kHz/400kHz的速率对六轴传感器完全够用。如果你需要非常高的输出数据率（比如1.66kHz的陀螺仪ODR），SPI会更稳，但对多数项目来说I2C是性价比最高的选择。

原理图上有几个点需要特别注意：

• SDA和SCL必须要加上拉电阻，典型值4.7kΩ，这个不能省。有些开发板内部虽然有上拉，但外部再放一份更稳妥，走线长或者总线挂载多个设备时尤其重要。
• SA0引脚决定I2C地址，接GND和接VDD的地址不同。因为我板上没有其他设备争地址，SA0直接接了GND。如果后续要接两颗同样的传感器，SA0就是区分它们的关键。
• LSM6D3TR-C的电源分为VDD和VDDIO，VDD给传感器内部供电，VDDIO给I2C/SPI接口电平供电。我这边VDD和VDDIO都接了3.3V，匹配STM32C5的IO电平。如果你的MCU是1.8V系统，VDDIO要接到1.8V，否则总线电平不匹配会通信失败。

2.2 CubeMX里的I2C配置

在STM32CubeIDE里用CubeMX初始化工程，I2C外设配置成I2C1，模式选I2C，基础参数如下：

时钟树方面，要确认I2C1的输入时钟频率符合I2C外设的分频要求。STM32C5的APB时钟默认分配一般没问题，但如果你把系统主频拉的很高、APB分频系数又不对，I2C的时序就会异常，表现就是通信偶尔成功偶尔失败。排查到这个层面时，可以先回头看一眼时钟树，不要只盯着驱动代码。

2.3 第一步：读WHO_AM_I验证通信

拿到板子后，我做的第一件事不是配置陀螺仪量程，而是先读WHO_AM_I寄存器。这个寄存器地址是0x0F，上电后固定返回该传感器的设备ID。以LSM6D3系列的经验值，读到0x69基本就说明I2C通路没问题。这一步极其关键，可以快速把"硬件没接好"和"功能没配好"这两类问题分开。

验证代码很简单：

#define LSM6D3_I2C_ADDR 0x6A // SA0=GND，具体地址以数据手册为准 #define LSM6D3_WHO_AM_I 0x0FU static HAL_StatusTypeDef lsm6d3_read_regs(uint8_t reg, uint8_t *buf, uint16_t len) { return HAL_I2C_Mem_Read(&hi2c1, LSM6D3_I2C_ADDR, reg, I2C_MEMADD_SIZE_8BIT, buf, len, 100); } uint8_t lsm6d3_check_id(void) { uint8_t id = 0; if (lsm6d3_read_regs(LSM6D3_WHO_AM_I, &id, 1) != HAL_OK) return 0; if (id != 0x69) return 0; return 1; }

读不到ID的时候，不要急着怀疑芯片坏了。先用示波器或者逻辑分析仪看SDA/SCL上有没有波形，再看地址对不对（SA0电平变一下地址就变了），最后确认VDDIO有没有供电。这三个环节按顺序排查，90%的问题都能定位。

3. 陀螺仪数据通路：从寄存器到原始值的完整逻辑

3.1 必须配置的几个关键寄存器

LSM6D3TR-C上电默认状态比我预想的要“安静”得多——陀螺仪和加速度计都处于掉电模式，你不主动配置，它不会输出任何数据。这也是很多新人第一次上手时读到的全是0的根本原因。要让陀螺仪开始工作，至少要碰这几个寄存器：

CTRL2_G是陀螺仪的主开关。ODR_G位段决定输出数据率，0000表示掉电，0001是13Hz，往上依次有26Hz、52Hz、104Hz、208Hz、416Hz、833Hz、1.66kHz等档位。FS_G位段决定量程，00是±250dps，01是±500dps，10是±1000dps，11是±2000dps。我在这颗料上把采样率设为104Hz，量程设为±2000dps，后面做姿态解算时这个采样率够用，而且每个采样周期的计算压力也不大。

CTRL3_C里的BDU位非常值得单独讲。BDU是Block Data Update的缩写，置1后，传感器在输出寄存器更新期间会锁存当前值，确保你一次读取6个字节时，X/Y/Z三个轴的高低位来自同一次采样。如果不置这个位，读数据时正好赶上内部更新，可能读到旧的高字节和新数据低字节拼出来的错误值，表现为数据偶发跳变。IF_INC位则是多字节读写的关键，置1后寄存器地址会自动递增，读陀螺仪数据时一次I2C突发读6个字节即可，否则只能一个字节一个字节读，效率和时序稳定性都会差不少。

3.2 轮询读取的正确流程

轮询读取的流程看起来简单，就是“问一下数据好了没，好了就读”，但实现上有讲究。完整步骤应该是：

1. 读STATUS_REG寄存器，检查GDA位（bit1），该位为1表示有新的陀螺仪数据就绪。
2. 如果GDA为1，从OUTX_L_G（0x22）开始连续读取6个字节，顺序是X低、X高、Y低、Y高、Z低、Z高。
3. 把每两个字节拼成有符号16位整数。
4. 根据当前量程选择灵敏度系数，换算成实际的角速度dps值。

为什么要先看GDA标志而不是直接读？因为陀螺仪内部是按照设定ODR更新的，读取速度如果比更新速度快，你不看标志直接读，读到的其实是上一次的旧数据。在低速轮询场景下影响不大，但在ODR比较高、主循环频繁访问时，这会导致同一笔数据被读多次，后续做积分等运算时会引入系统性偏差。

3.3 原始数据与角速度的换算公式

陀螺仪输出的原始值是16位有符号整数，范围从-32768到32767。要转换成dps（度每秒）需要一个灵敏度系数，不同量程对应不同系数：

单位是mdps/LSB（毫度每秒/每LSB），换算成dps/LSB就是除以1000。计算方式很简单：角速度 = 原始值 × 灵敏度系数 ÷ 1000。例如，量程±2000dps时读到的原始值是1000，实际角速度就是1000 × 70 ÷ 1000 = 70dps，也就是每秒转70度。这里有个经验值可以记一下：把灵敏度系数当成浮点数用，比如2000dps量程时乘以0.070f，比整数除1000再乘更直观，而且Cortex-M33有FPU，浮点乘法完全没压力。

4. 轮询获取陀螺仪数据的代码实现

4.1 底层I2C驱动封装

我把I2C读写封装成两个基础函数，整个驱动都基于它们构建。这样如果后续换SPI接口，只需要替换这两个函数的实现，上层逻辑完全不用动。注意HAL_I2C_Mem_Read/Write函数的DevAddress参数，这里传入的是设备地址，如果使用的是8位表示法，要确认和HAL库的地址位宽一致，否则通信会失败。

#define LSM6D3_I2C_ADDR 0x6A static HAL_StatusTypeDef lsm6d3_write_reg(uint8_t reg, uint8_t val) { return HAL_I2C_Mem_Write(&hi2c1, LSM6D3_I2C_ADDR, reg, I2C_MEMADD_SIZE_8BIT, &val, 1, 100); } static HAL_StatusTypeDef lsm6d3_read_regs(uint8_t reg, uint8_t *buf, uint16_t len) { return HAL_I2C_Mem_Read(&hi2c1, LSM6D3_I2C_ADDR, reg, I2C_MEMADD_SIZE_8BIT, buf, len, 100); }

这里我建议把超时时间设成100ms而不是HAL_MAX_DELAY。原因很实际：如果I2C总线卡死（比如从设备拉低时钟不放），HAL_MAX_DELAY会让系统永远卡在等待里，100ms超时后可以返回错误，在主循环里做错误计数和恢复逻辑，这对长期运行的项目非常重要。

4.2 传感器驱动初始化

初始化序列我习惯按这个顺序来：复位传感器、等待复位完成、读ID校验、配置陀螺仪、配置数据管理。注意先复位再配置，如果顺序反了，可能前脚配好的寄存器后脚被复位清掉。

uint8_t lsm6d3_init(void) { uint8_t id = 0; // 1. 软复位 lsm6d3_write_reg(0x12, 0x01); // CTRL3_C: SW_RESET HAL_Delay(20); // 2. 读ID if (lsm6d3_read_regs(0x0F, &id, 1) != HAL_OK) return 0; if (id != 0x69) return 0; // 3. 配置陀螺仪：104Hz ODR，±2000dps // CTRL2_G = 0x5C // 0101 -> ODR 104Hz, 11 -> FS 2000dps, 00 -> 保留 lsm6d3_write_reg(0x11, 0x5C); // 4. 配置CTRL3_C: BDU=1, IF_INC=1 lsm6d3_write_reg(0x12, 0x44); return 1; }

为什么CTRL2_G要写成0x5C？展开二进制看：0101 11 00。前四位0101是104Hz输出率，中间两位11是2000dps量程，最低两位保持默认0。如果你读到的数值和预期不符，可以对照数据手册的位段慢慢拆，养成这种“把寄存器值拆成位段看”的习惯，能少走很多弯路。

4.3 主循环轮询逻辑与节拍控制

主循环里最忌讳的就是死等。很多人写轮询喜欢这样：while(1)里无条件读一次数据，读完就打印。这在Demo里能转，但实际项目里主循环还要处理按键、显示、通信等任务，绝对不能一个循环全耗在传感器读取上。我的做法是给主循环一个时间基准，每10ms采样一次（对应100Hz采样率），其他时间CPU干别的。

int16_t gx_raw = 0, gy_raw = 0, gz_raw = 0; float gx_dps = 0.0f, gy_dps = 0.0f, gz_dps = 0.0f; void lsm6d3_read_gyro_raw(int16_t *gx, int16_t *gy, int16_t *gz) { uint8_t buf[6]; lsm6d3_read_regs(0x22, buf, 6); // OUTX_L_G *gx = (int16_t)((uint16_t)buf[1] << 8 | buf[0]); *gy = (int16_t)((uint16_t)buf[3] << 8 | buf[2]); *gz = (int16_t)((uint16_t)buf[5] << 8 | buf[4]); } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_UART_Init(); if (!lsm6d3_init()) { printf("LSM6D3 init failed\r\n"); while (1); } printf("LSM6D3 init ok\r\n"); uint32_t last_tick = 0; uint8_t status = 0; while (1); { if (HAL_GetTick() - last_tick >= 10) { last_tick = HAL_GetTick(); // 检查数据就绪位 lsm6d3_read_regs(0x1E, &status, 1); // STATUS_REG if (status & 0x02) { // GDA lsm6d3_read_gyro_raw(&gx_raw, &gy_raw, &gz_raw); gx_dps = gx_raw * 0.070f; // 2000dps灵敏度 gy_dps = gy_raw * 0.070f; gz_dps = gz_raw * 0.070f; printf("%.2f, %.2f, %.2f\r\n", gx_dps, gy_dps, gz_dps); } } // 这里可以放其他任务 } }

这里有个细节值得拿出来讨论：为什么读完STATUS_REG的GDA位之后又要连续读6个字节，中间不需要再检查状态？因为对LSM6D3TR-C而言，一旦GDA置1，输出寄存器里的数据在本次读取完成前是保持稳定的，加上我前面设置了BDU，高低字节不会跨采样周期错位，所以一次突发读是安全的。

4.4 原始数据的验证与串口观察

我把三轴数据用printf输出到串口，波特率115200。验证方法很简单：把板子平放不动，看三轴输出是否稳定在0附近。陀螺仪测的是角速度，静止不动时理论上应该为0，但实际上会有零偏，几dps以内的零偏都算正常，可以通过静态校准扣掉。然后把板子绕Z轴快速转90度，再停下来，z轴的输出应该有一个先正后负或先负后正的脉冲，对应旋转过程中的角速度变化，同时X、Y轴基本不受影响。这个测试通过了，说明接线和读取逻辑是通的。

为了让观察更直观，我还在电脑串口终端上开了数据波形绘制，效果类似示波器。调整板子方向时能立刻看到三轴的数值跟着变化，比看十六进制数直观很多。

5. 实测过程中三个容易踩的坑

5.1 上电后数据全0：陀螺仪默认是掉电模式

我第一版固件写完，上电后串口打印出来的数据全是0，而且STATUS_REG的GDA位一直不置1。当时我第一反应是I2C地址配错了，反复核对地址、波形，都没问题。后来翻数据手册的寄存器复位值表，发现CTRL2_G的复位值就是0x00，也就是ODR_G为0000，陀螺仪处于掉电状态。没配置ODR就直接读，当然读不到数据。

这个问题在ST的六轴传感器上非常常见，LSM6DS系列、LIS2系列都是类似的“默认全关”设计，属于低功耗设计的一部分。解决办法就是前面初始化序列里那一步：往CTRL2_G写入非0的ODR值。如果读完这篇恰好在别的ST传感器上也碰到全0数据，先查对应控制寄存器的复位值，大概率能省下半天折腾时间。

5.2 数据跳变巨大：高低字节不同步和字节顺序

第二个坑来自数据本身。静态放置的时候，偶尔会读出一个很大的值，比如Z轴突然跳到+30000多，下一帧又恢复正常。抓了几次波形后确认是BDU位没置1，导致我读6字节的过程中，高低字节发生了跨采样更新。解决办法就是CTRL3_C里把BDU置1，这个在前面已经强调过，实测效果立竿见影，数据一下就稳定了。

紧接着又发现一个更隐蔽的问题：X轴输出在正值和负值之间乱跳，看起来完全不成章法。查了数据手册的寄存器描述才发现，输出数据的字节顺序是“低字节在前、高字节在后”。我第一轮代码写成了把buf[0]左移8位再或buf[1]，结果高地位完全反了。正确的拼法是 (int16_t)((uint16_t)buf[1] << 8 | buf[0])。这个坑在ST传感器里很常见，几乎每一颗IMU都是小端序输出，但只要你吃过一次亏，后面就会条件反射地先看字节序说明再动手。

5.3 轮询频率上不去：I2C时钟、延时和滤波相互拖累

第三件困扰我的事是数据输出率达不到预期。我设定的ODR是104Hz，但在代码里加了HAL_Delay(5)这类阻塞延时以后，实际串口数据输出的间隔非常不均匀，有时候两帧数据间隔20多毫秒，有时候又只有几毫秒。原因倒不复杂：HAL_Delay依赖SysTick，而SysTick同时又被HAL_GetTick用于轮询节拍，延时函数和采样逻辑挤在一起，互相干扰；再加上printf默认是阻塞发送，在115200波特率下发送一条几十字节的记录也要耗费好几毫秒，整体采样节奏自然就乱了。

解决办法分两步。第一步，把采样节拍统一改为基于HAL_GetTick的时间戳判断，不在循环里插入任何阻塞延时。第二步，将printf改成非阻塞输出或者降低打印频率，比如每50ms打印一次平均数据。如果你需要精确到微秒级的采样间隔，那就该上定时器触发DMA传输了，轮询模式解决不了那么硬实的实时性要求。

5.4 如何验证滤波和零偏校准

原始数据稳定下来之后，我顺手做了一个简单的一阶低通滤波和一个零偏校准。零偏校准的思想很朴素：在传感器完全静止时采集N个样本求平均，得到零偏，再用后续每个读数减去这个零偏。代码实现起来就是启动时先转200ms，攒20个样本，算出三轴各自的平均值。

#define CALIB_SAMPLES 20 int32_t sum_x = 0, sum_y = 0, sum_z = 0; for (int i = 0; i < CALIB_SAMPLES; i++) { lsm6d3_read_gyro_raw(&rx, &ry, &rz); sum_x += rx; sum_y += ry; sum_z += rz; HAL_Delay(10); } float bias_x = sum_x / CALIB_SAMPLES; float bias_y = sum_y / CALIB_SAMPLES; float bias_z = sum_z / CALIB_SAMPLES;

滤波我选用了一阶低通：filtered = filtered × 0.8 + new × 0.2。0.8这个系数对应约100Hz采样率下的截止频率大约在十几Hz，能够滤掉大部分机械振动噪声，又不会让姿态响应的滞后太明显。系数越大，滤波越平滑，但滞后越严重，具体值还是要按应用场景调。

6. 轮询之外：中断、FIFO和后续扩展

6.1 什么时候该换中断或FIFO

轮询模式跑通后，我盘点了一下它在实际项目中的边界。如果系统比较简单，主循环任务很少，采样率在100Hz到200Hz之间，轮询完全够用，CPU占用也不高。可一旦出现下面几种情况，就要认真考虑换机制了：

举个例子，如果你要把陀螺仪ODR开到1.66kHz，用轮询模式在主循环里以1.66kHz的频率持续读I2C，CPU基本就干不了别的了。这种情况下，用传感器的内部FIFO把数据缓存起来，每攒到一定数量再通过中断一次性读取，是最合适的方案。LSM6D3TR-C的FIFO深度足够存下几百笔采样数据，配合Watermark中断，可以在低CPU占用下做到高数据率采集。

6.2 后续文章可能扩展的方向

这篇把轮询读取陀螺仪数据的过程完整走了一遍，后面的空间还很足。按照我的规划，下一步是在同样的硬件上测SPI模式，验证它能否进一步降低读取延迟；然后会做中断方式配合低功耗模式，让MCU在数据到来前保持睡眠；再往后是FIFO的批量读取和基于陀螺仪数据的姿态解算。ST的这颗传感器本身还带加速度计，两个传感器数据融合起来做倾斜角测量或者运动检测，又是另一块可以展开的内容。

如果你是从别的MCU平台迁移过来的，这篇文章的驱动代码和寄存器配置逻辑基本可以无缝移植，无非是把HAL_I2C_Mem_Read对应的底层函数替换成你平台的I2C驱动。数据库里的细节才是核心资产，平台只是壳。