STM32C5驱动LSM6D3TR-C六轴IMU：轮询读取陀螺仪数据与排坑实录

最近在评估STM32C5系列MCU的工程可行性，顺手把LSM6D3TR-C这颗六轴IMU也接上了。目标非常明确：先用最传统的轮询方式把陀螺仪数据稳定读出来，摸清楚这颗传感器的脾气，再做后续的中断和DMA方案。STM32C5是ST新一代Cortex-M33内核产品线，性能比C0系列明显上了一个台阶，而LSM6D3TR-C作为一颗低功耗六轴传感器，在无人机、TWS耳机、工业状态监测里出现频率很高。这篇就是完整记录我从CubeMX配置、驱动编写到实测排坑的全过程，适合正在用STM32C5系列或者刚拿到LSM6D3TR-C准备做驱动开发的工程师参考，新手也能照着一步步把轮询通路搭起来。

如果你和我一样，属于那种“新芯片拿到手先让它跑起来再说”的人，这篇文章会很对胃口。我会把为什么这样配置寄存器、为什么轮询节奏要跟ODR匹配、以及实测中遇到的三个最典型的坑，全部摊开来讲。

1. 为什么是STM32C5配LSM6D3TR-C，以及轮询方案的定位

1.1 做这个项目时我在想什么

STM32C5这颗料，说实话我是冲着它的Cortex-M33内核去的。相比之前用过的C0系列，C5的主频和片上外设配置都要充裕不少，做传感器融合、状态监测这类需要一定算力的场景比较合适。LSM6D3TR-C又是一颗典型的低功耗六轴IMU，I2C和SPI都支持，体积小、数据手册齐全，用来验证STM32C5的外设驱动能力是很好的搭配。

不过拿到板子后，我没急着直接上中断+DMA+RTOS那一套，而是先定了个原则：第一版只用轮询，不引入任何异步机制。有人可能会觉得轮询太基础，但做过新平台bring-up的都明白，变量越少，出问题时越容易定位。轮询模式下，每一个数据样本都是MCU主动发起的读操作，寄存器里是什么就是什么，整个执行路径是确定性的，排查起来极其舒服。

1.2 轮询不是偷懒，是在控制变量

轮询经常被误解为“CPU傻等”，其实不是。轮询的精髓在于节奏控制和状态判断。你发一条SPI读取指令，读回来的数据是传感器当前寄存器的最新值，但这个值“新不新”，取决于你上一次读取的时间和传感器内部ODR（输出数据速率）之间的关系。

主循环跑得太快，传感器还没完成一次新的采样，你读到的就是上一份旧数据，表现就是读数长时间不变；跑得太慢，陀螺仪数据就会积压，下次一读跳变特别大。所以轮询设计里最核心的，不是代码本身，而是把轮询频率跟传感器ODR匹配好。这个思路也为后来做中断和DMA留了清晰的位置——在中断回调里置标志位，在主循环里消费数据，本质上还是同一个轮询框架。

1.3 轮询率和ODR的匹配计算

LSM6D3TR-C的ODR由CTRL2_G寄存器配置，可选范围从12.5Hz到6667Hz。我做验证时选择104Hz这个档位，理由很简单：人手的自然晃动频率基本在几赫兹到几十赫兹范围内，104Hz足够覆盖，同时数据和log的吞吐量又不会太大，方便观察。

轮询节奏上，我让主循环大约以9ms为周期读取，也就是实际轮询频率在110Hz左右，略高于传感器ODR。这样做的目的是保证每一次新的采样数据都能在下一次采样之前被读走，不会因为读得慢而丢数据。你不需要精确计时到微秒级，只要保证“轮询周期略小于数据更新周期”这个原则就可以，差个10%完全没问题。

2. 动手接线之前，先把寄存器映射和通信时序看清楚

2.1 寄存器地图和SPI读写格式

LSM6D3TR-C的寄存器结构是8位地址、8位数据，这一点和大多数ST传感器一致。最关键的寄存器就几个：WHO_AM_I（0x0F）用来验证通信链路和芯片ID，CTRL1_XL（0x10）配置加速度计，CTRL2_G（0x11）配置陀螺仪，CTRL3_C（0x12）负责基础控制，STATUS_REG（0x1E）用来查询数据是否就绪，陀螺仪数据输出寄存器从OUTX_L_G（0x22）开始，一共6个字节。

SPI读取时，第一个字节的高7位是寄存器地址，最高位（bit7）是读标志，bit6是地址自动递增使能。做陀螺仪连续读取时，我习惯把bit6也置1，这样从0x22开始一次事务就能把6个数据寄存器全部读完，效率和代码量都优于逐个寄存器单独读。

这里有个非常容易踩的坑：STM32 HAL库里的“SPI Mode”编号和传感器手册里的“SPI模式”定义并不完全一致。LSM6D3TR-C手册里支持的是CPOL=0/CPHA=0和CPOL=1/CPHA=1两组时序，在CubeMX里配置时，不要死记Mode编号，直接看CPOL和CPHA两个参数是否对应上就行。

2.2 初始化前必须弄清楚的几个配置位

陀螺仪配置主要在CTRL2_G寄存器。ODR_G位段决定输出数据速率，FS_G位段决定量程。量程直接决定灵敏度，这在后面换算物理单位时非常关键。手册里给了一张灵敏度对照表：±250dps时是8.75mdps/digit，±500dps是17.50mdps/digit，±1000dps是35.00mdps/digit，±2000dps是70.00mdps/digit。

CTRL3_C寄存器里有两位必须留意。BDU位（Block Data Update）如果置1，传感器会保证高字节和低字节在同一时刻被锁存，避免了读高位时传感器刚好更新数据导致拼接错乱。IF_INC位如果置1，才能启用上面说的地址自动递增功能。这两个位我建议在初始化时就设好，都是“一次配置，长期受益”的选项。

数据就绪的判断在STATUS_REG寄存器，bit1是GDA位，为1时表示有新的陀螺仪数据写入输出寄存器。轮询读取的判定就是不停地读这个寄存器，直到GDA位为1，再去读6个数据字节。

3. 搭建工程和写驱动：从CubeMX配置到第一个能用的轮询函数

3.1 CubeMX里的Pinout和时钟配置

新建STM32C5工程时，记得先确认自己用的CubeMX版本支持C5系列。在Pinout页面里，把SPI外设打开，CS片选引脚配成普通的GPIO输出，千万不要图省事直接让SPI硬件管理NSS，那样后续调试时GPIO状态完全不可见，出了问题很难排查。

SPI参数设置上，我建议第一版先把波特率压到1MHz左右。LSM6D3TR-C的SPI最高能跑10MHz，但通信协议刚调通时，未知信号质量问题和布线干扰很容易被高波特率放大。先用低速把链路跑通，确认数据正确后，再逐步提高波特率，每次只改一个变量，是效率最高的调试方式。

时钟树配置要特别注意SPI外设时钟的来源，如果SPI1走的是APB2，那APB2的分频系数会影响最终SPI波特率的计算。我习惯先在CubeMX里看生成的SPI BaudRate实际值，确认接近但不超过目标值，再往下写代码。

3.2 平台读写层的封装

我先封装两个底层函数，一个读寄存器，一个写寄存器。后续所有的初始化、状态查询、数据读取，全部通过这两个接口完成，跟具体的SPI外设解耦。

static void lsm6ds3_cs_low(void) { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); } static void lsm6ds3_cs_high(void) { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); } /* 写寄存器 */ void lsm6ds3_write_reg(uint8_t reg, uint8_t val) { uint8_t tx[2]; tx[0] = reg; tx[1] = val; lsm6ds3_cs_low(); HAL_SPI_Transmit(&hspi1, tx, 2, 100); lsm6ds3_cs_high(); } /* 读寄存器 */ uint8_t lsm6ds3_read_reg(uint8_t reg) { uint8_t tx[2], rx[2]; tx[0] = 0x80 | reg; /* 最高位置1表示读 */ tx[1] = 0x00; /* dummy字节，用于产生时钟 */ lsm6ds3_cs_low(); HAL_SPI_TransmitReceive(&hspi1, tx, rx, 2, 100); lsm6ds3_cs_high(); return rx[1]; }

事务期间CS保持低电平全程参与，事务结束后拉高，这是SPI从设备通信的基本礼仪。另外要注意，SPI是全双工协议，读寄存器时必须同时发送一个dummy字节来产生时钟，不然主控根本收不到数据。这一点刚开始容易漏。

3.3 初始化序列的完整代码和顺序理由

初始化顺序直接决定驱动稳定性，我的代码是这么写的：

uint8_t lsm6ds3_init(void) { uint8_t id; /* 第1步：确认通信链路，读WHO_AM_I */ id = lsm6ds3_read_reg(0x0F); if (id != 0x69) { return 1; /* 通信异常 */ } /* 第2步：软件复位，让传感器恢复到确定状态 */ lsm6ds3_write_reg(0x12, 0x01); HAL_Delay(10); /* 第3步：配置加速度计，104Hz，±2g */ lsm6ds3_write_reg(0x10, 0x40); /* 第4步：配置陀螺仪，104Hz，±250dps */ lsm6ds3_write_reg(0x11, 0x42); /* 第5步：BDU=1，IF_INC=1 */ lsm6ds3_write_reg(0x12, 0x44); return 0; }

第1步读WHO_AM_I，作用不只是确认芯片型号，更重要的是验证SPI通信链路是否正常。如果这一步都过不了，后面配置再多寄存器都是白搭。第2步软件复位是很多开发者容易忽略的，上电后传感器内部状态不确定，直接写配置有概率被内部状态机吞掉，复位一下就能确保所有寄存器回到默认值。第5步把BDU和IF_INC放最后，是因为这两个位影响的是数据读取行为，应该在基本功能配置完成后再生效。

3.4 主循环里的轮询读取

完整的陀螺仪数据读取函数，和主循环示例：

void lsm6ds3_read_gyro_xyz(int16_t *gx, int16_t *gy, int16_t *gz) { uint8_t tx[7], rx[7]; /* 读标志 | 地址自增 | 起始寄存器0x22 */ tx[0] = 0x80 | 0x40 | 0x22; for (int i = 1; i < 7; i++) { tx[i] = 0x00; } lsm6ds3_cs_low(); HAL_SPI_TransmitReceive(&hspi1, tx, rx, 7, 100); lsm6ds3_cs_high(); *gx = (int16_t)(rx[1] | (rx[2] << 8)); *gy = (int16_t)(rx[3] | (rx[4] << 8)); *gz = (int16_t)(rx[5] | (rx[6] << 8)); }

主循环里，先读STATUS_REG判断GDA位，数据就绪才去读6个字节的陀螺仪数据，最后把原始值换算成dps打印出来。

int16_t gx, gy, gz; float fx, fy, fz; while (1) { if (lsm6ds3_read_reg(0x1E) & 0x02) /* GDA位 */ { lsm6ds3_read_gyro_xyz(&gx, &gy, &gz); fx = (float)gx * 8.75f / 1000.0f; fy = (float)gy * 8.75f / 1000.0f; fz = (float)gz * 8.75f / 1000.0f; printf("gx=%.2f gy=%.2f gz=%.2f dps\r\n", fx, fy, fz); } HAL_Delay(9); /* 约110Hz轮询频率 */ }

printf在工程调试阶段几乎不可或缺，但要注意串口打印非常耗时。如果数据量一大，打印本身就会拖慢主循环，导致实际轮询频率严重偏离预期。我在验证前期就吃过这个亏，后面会专门讲。

4. 把寄存器里的裸数换算成物理量

4.1 高低字节拼接的正确姿势和常见错误

陀螺仪输出寄存器里的原始值是16位有符号数，高字节和低字节分开存放在两个8位寄存器里。合并时最容易犯的错误是字节顺序不对，或者符号扩展没处理好。

正确做法是低字节放在低8位、高字节放在高8位，然后整体转成带符号的16位整数：

*gx = (int16_t)(rx[1] | (rx[2] << 8));

这里rx[2] << 8在C语言里会发生整型提升，rx[2]是uint8_t，会自动提升为int类型，左移8位后在int范围内不会溢出，和rx[1]按位或后，再截断成int16_t，位模式完全保留，符号位也正确。

我看到过不少人在这一步写成先把高低字节拼成uint16_t，再转int16_t，虽然最终结果在大部分编译器下也对，但中间涉及实现定义行为，不如上面这个写法干净。还有一种错误是拿着温度传感器的解析逻辑来套陀螺仪，温度数据可能是左对齐的12位，陀螺仪是右对齐的16位，直接套用会导致数据看起来在剧烈跳变。

4.2 灵敏度查表与量纲换算

上一步拿到的原始值是没有物理意义的“裸数”，必须结合量程对应的灵敏度换算成角速度。LSM6D3TR-C在陀螺仪量程为±250dps时，灵敏度是8.75mdps/digit，也就是说原始值每增加1个LSB，代表角速度变化8.75毫度每秒。

换算公式很简单：实际角速度(dps) = 原始值 × 灵敏度(mdps/digit) ÷ 1000

举个例子，如果原始值gx=1000，在±250dps量程下：1000 × 8.75 / 1000 = 8.75dps。如果量程改成±2000dps，同样原始值1000换算出来就是70dps，同样的原始数代表完全不同的物理量，量程配置和灵敏度必须一一对应。

不同量程下的灵敏度对应关系如下表：

我实测时选±250dps，因为手拿着板子晃动的角速度基本不会超过这个范围，还能拿到最高分辨率。

4.3 静止时读数不是0，先别急着怀疑驱动

把代码跑起来后，发现板子平放在桌面上，陀螺仪读数不是0，而是在0附近小幅波动，这非常正常。陀螺仪存在零偏和噪声，不可能在静止时输出完美的0。判断驱动是否正常，不是看数值是不是0，而是看数值是否在0附近波动，波动的幅度是否在合理范围内。

正常情况下的零偏，对这颗传感器来说通常在几dps以内，噪声表现为高频小幅抖动。如果读数稳定在20dps以上不回落，那就要检查是不是有持续的机械振动，或者传感器焊接/固定有问题。

如果项目对零偏要求高，可以在初始化完成后采集一段静止数据，计算平均值当作零偏，后续每次读取时把这个值减掉。这是最原始也最有效的一种静态校准方式，代码量很少但效果立竿见影。

5. 实测排坑记录：三个花了最多时间的问题

5.1 读WHO_AM_I一直是0xFF或者0x00

这是我每次接新传感器几乎都会遇到一遍的问题。排查链路建议按这个顺序走：

1. 先确认SPI外设时钟有没有使能，CubeMX生成代码时如果忘了勾选SPI的中断或DMA，时钟默认可能没开，读回来自然全0xFF。
2. 检查CS引脚配置。CS必须由GPIO控制，并且事务之间保持高电平，如果CS一直拉低，传感器处于选中状态，SPI总线时序会乱。
3. 用示波器或者逻辑分析仪看SPI四根线的时序，MOSI上有无数据、时钟是否正常翻转、MISO在读取阶段有没有回应。
4. 确认SPI极性相位配置和传感器匹配，这一步最容易出问题，尤其是CubeMX里Mode编号和手册模式定义对不上的情况。

0xFF一般说明MISO方向上完全没有数据，大概率是信号没通、CS或者时钟有问题。0x00一般说明通信建立了一部分但数据没传完整，检查时钟极性和相位更有效。

5.2 数据动不动跳一个大数，看起来像随机数

这个问题排查了挺久。现象是静止状态下，大部分读数在0附近，但偶尔会蹦出一个几千上万的原始值，明显不正常。

第一反应是拼接问题，但检查代码后没发现字节顺序错误。继续排查，发现是我在连续读取6个字节时，没有启用地址自动递增，导致读到的寄存器顺序错乱。解决方法是确认CTRL3_C里IF_INC位已经置1，并且发送的起始地址字节中bit6已经置1。

另一个同样常见的跳变原因是BDU位没有置1。如果不锁存高字节，传感器在CPU读完高字节、没读低字节的空隙里更新了数据，那么低字节就会来自下一次采样，两个字节来自不同时刻，拼出来的数自然完全错乱。

5.3 读数“凝固”不动，偶尔又猛跳一下

这个问题的表现是：快速晃动板子，串口打印的数据却像死了一样不变化，持续一段时间后又突然跳变一大截。这是典型的轮询频率跟不上ODR的问题。

我先在代码里加了一个翻转GPIO的示波器探针，一测量发现实际轮询周期远远大于预期的9ms，重点怀疑对象就是主循环里的printf。串口的波特率当时设的是115200，每条打印语句大约30个字符，理论耗时才3ms左右，但用的是阻塞式发送，还要加上HAL库的等待和系统时钟开销，实际耗时是理论值的几倍，把整个轮询周期拖到了50ms以上。

解决办法有两个方向：一是把日志输出频率降下来，比如每读10次才打印一次；二是给串口发送配上DMA或者用环形缓冲区，让printf不再阻塞主循环。我验证阶段采用的是第一个方案，简单直接，后续正式版本再上DMA输出。

这几轮排坑下来，最大的体会是：轮询方案看着简单，但真正稳定跑起来，靠的还是对传感器内部机制的理解和对“轮询节奏”的控制。尤其是GDA判断这种看似多余的步骤，恰恰是保证数据不混乱的关键。如果你也在STM32C5上调这颗传感器，建议先把这套轮询流程吃透，再考虑上中断和DMA，底层机制清楚了，后面加什么功能都有底。