STM32C5通过I2C轮询读取LSM6D3TR-C陀螺仪数据完整指南

拿到LSM6D3TR-C这颗6轴惯性传感器时，我的目标很直接：在STM32C5上用最传统、最容易排查的方式——I2C轮询，把陀螺仪数据先读出来。很多朋友一上手就想搞中断、DMA、FIFO，结果被各种“高级”功能困住，最后连基础数据都调不通。如果你也正准备在STM32C5上驱动LSM6D3TR-C，那这篇就是为你写的：我会从硬件接线、寄存器配置、轮询逻辑、数据换算一路讲到实测坑点，保证你照着做也能在一两个小时内看到陀螺仪数据在串口里跳出来。

这篇文章适合三类人：一是手头正好有LSM6D3TR-C和STM32C5开发板，想把数据读出来跑通流程的；二是刚接触I2C传感器驱动、想搞清楚“轮询到底怎么写”的新手；三是已经能读加速度计但陀螺仪老是不出数、想来找排查思路的朋友。轮询这个说法听着不高级，却是理解传感器时序最好的起点——主控一遍遍去问“数据好了吗”，跟工业现场PLC用Modbus轮询多个从站、总线仲裁器用轮询算法分配信道，本质上是同一件事，理解了它，后面再换中断或者DMA就顺理成章。

1. 项目整体设计思路

1.1 为什么第一步一定要用轮询来读

先聊清楚“轮询”这个动作本身。所谓轮询，就是主控循环里反复主动去查传感器的状态寄存器，发现“数据准备就绪”标志位置1了，才去读采样值。放在LSM6D3TR-C上，就是不断读STATUS_REG（0x1E）这个寄存器，检查第1位GDA（陀螺仪数据可用标志），为1就把陀螺仪的6个字节读回来。

那为什么不用中断？不用DMA？我的经验始终是：新驱动或新平台，第一版必须用轮询。原因有三点：

第一，排查链路简单。轮询的代码是“一问一答”式的，I2C总线上每一笔操作都是你主动发起的，波形可以用逻辑分析仪一条一条对。一旦读到全0xFF或者偶尔超时，你很容易就能定位是接线、地址还是时序问题。而中断一旦不触发，你要查中断配置、查外部中断线、查传感器内部映射寄存器，排查链条一下子拉长好几倍。

第二，能逼你把寄存器行为吃透。轮询要求你理解状态寄存器每一位的含义，理解ODR（输出数据速率）和状态位翻转的关系，理解数据高低字节拼接方式。这些恰恰是传感器驱动最核心的知识。跳过轮询直接上DMA，遇到数据错位你都不知道该查谁。

第三，对STM32C5这种平台来说，轮询开销完全可控。Cortex-M33内核主频不低，跑I2C在400kHz下，读一次状态加读6字节数据也就几十微秒，即便循环外加一些处理，CPU占用也很小。有些人一听到“轮询浪费CPU”就把它一棒子打死，其实对于IMU这种低频传感器，轮询完全够用，真正要命的往往是终端打印和延时函数。

我这么说并不代表轮询没有缺点。它在实时性上确实不如中断，CPU占用也比DMA高，而且轮询周期必须比传感器的ODR周期短，否则会漏读。但这些都是后话，先把轮询跑通，你才说得清楚到底要不要上更高级的方式。

1.2 LSM6D3TR-C这颗料到底是个什么东西

LSM6D3TR-C是意法半导体的一款6轴惯性测量单元，内部集成3轴加速度计和3轴陀螺仪。先说陀螺仪，测的是角速度，单位是dps（度每秒），你拿它绕某个轴转得越快，对应轴输出的数值就越大。它内部是微机械结构，利用科里奥利效应把角速度转换成电容变化，再通过ASIC变成数字量。这跟你拿一个机械陀螺仪“转起来保持指向”的原理完全不是一回事，传感器内部并没有一个真的在旋转的转子，更像是一个“电子陀螺”。

这颗料支持I2C和SPI两种接口，能跑最高6.66kHz的ODR，内部还带FIFO、计步器、倾斜检测、敲击检测这些嵌入式功能，甚至能外挂磁力计做传感器融合。但在本篇文章里，我们只做最基础的一件事：配置好陀螺仪，用I2C轮询方式把原始16位数据读出来，再换算成dps。其余功能后面可以慢慢研究，不建议一开始就铺开。

内部寄存器按功能可以分几大类：配置寄存器（CTRL1_XL、CTRL2_G、CTRL3_C等）、状态寄存器（STATUS_REG）、数据输出寄存器（OUTX_L_G到OUTZ_H_G、OUTX_L_XL到OUTZ_H_XL），以及FIFO控制寄存器等。轮询会用到的大概就这几个：CTRL1_XL、CTRL2_G、CTRL3_C、STATUS_REG和陀螺仪输出寄存器。

1.3 STM32C5在这里扮演什么角色

STM32C5是ST新一代主流MCU系列，基于Cortex-M33内核，带FPU（浮点运算单元），这个FPU对我们换算角速度很有用——直接用float做乘法没有软件模拟开销，代码写起来也清爽。在工程里，它只负责两件事：通过I2C外设和传感器通信，通过UART把数据打印到电脑上。

我用的方案是STM32CubeMX初始化时钟和I2C1，配合HAL库读写寄存器。可能有人觉得HAL库绕、效率低，但对于I2C这种慢速总线，HAL的封装反而是优势：超时机制、错误处理都帮你写好了，调试期出问题更容易排查。等真要把性能榨到极致，再用寄存器或者LL库重写底层不迟。STM32C5主频高、资源足，完全顶得住I2C轮询加浮点转换加串口打印，这也是我选它来做这个驱动的原因——传感器逻辑的验证不能被主控资源不足干扰。

2. 硬件接线与I2C通信基础

2.1 引脚连接：先接对线再谈代码

LSM6D3TR-C常见的封装是LGA-14，引脚不多，但LGA封装不方便手工飞线，所以我建议直接买集成好的模块板，模块上一般已经帮你把去耦电容、上拉电阻都做好了，引脚也引出来了。你要是手头只有裸片，那就得好好处理焊接和走线——这属于另一个话题，我只说模块板的接法。

I2C模式下接线非常简单，但有几个关键点必须注意。首先是SDO/SA0引脚，它不仅是SPI数据输出脚，在I2C模式下它还决定芯片的7位I2C地址：SDO接地，地址是0x6A；SDO接高电平，地址是0x6B。很多朋友第一次读不到数据，最后发现就是SDO悬空导致地址不稳定。另外一个容易忽略的是CS引脚，I2C模式下必须把它接到高电平（VDD），否则芯片可能错误地认为你要用SPI模式。

下面是参考接线表：

第5行SDO这里建议直接接地，这样地址固定为0x6A，好记。CS接VDD这一步千万别省，我以前偷懒悬空过，结果通信时好时坏，查了好久才发现是CS电平不对。

I2C是开漏总线，需要上拉电阻把SCL和SDA拉到高电平。模块板通常自带上拉，如果没有，你在SCL和SDA上各接一个4.7kΩ电阻到3.3V。STM32内部虽然也能配置上拉，但内部上拉阻值偏大，高速通信时沿不够陡，建议外部上拉，能省很多调试时间。我第一次接的时候偷懒只用了内部上拉，结果400kHz模式下偶尔通信失败，加上外部4.7kΩ电阻后就好了。

2.2 用CubeMX配置I2C1的步骤

打开STM32CubeMX，选好你的STM32C5型号，在引脚配置里把PB8设为I2C1_SCL、PB9设为I2C1_SDA，或者直接用菜单分配I2C1功能，让CubeMX自动选引脚也行。需要注意的是，I2C引脚的模式应该是开漏输出（Open Drain），CubeMX生成代码时会自动配好，但如果你要从别的示例拷代码过来改，务必检查GPIO配置是不是开漏。用推挽输出去跑I2C开漏协议，最典型的现象就是通信时好时坏，看起来像接触不良。

I2C1的参数里，速度设为Fast Mode（400kHz），地址长度7位。LSM6D3TR-C支持最高400kHz的I2C时钟，直接拉满没问题。时钟源选择I2C1的时钟树，CubeMX会自动配置好，一般用默认就行。

生成工程后，确认生成的I2C初始化代码里已经打开了I2C外设时钟和GPIO时钟。接下来就是封装底层读写函数。HAL库里与I2C读写寄存器最匹配的函数是HAL_I2C_Mem_Read和HAL_I2C_Mem_Write，这两个函数的语义是“往指定器件地址的某个寄存器地址读写若干字节”，完美契合传感器寄存器操作。

#define LSM6D3_I2C_ADDR 0x6A // SDO接地时的7位地址 uint8_t lsm6d3_read_reg(uint8_t reg) { uint8_t val = 0; HAL_I2C_Mem_Read(&hi2c1, LSM6D3_I2C_ADDR, reg, I2C_MEMADD_SIZE_8BIT, &val, 1, 100); return val; } 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); }

代码里有个地方要特别提醒：HAL库的HAL_I2C_Mem_Read使用的器件地址是7位地址，而很多老代码习惯把地址左移一位变成8位地址（0xD4、0xD6）再传入。用HAL库时千万不要再左移，直接传0x6A就行。我在调别的传感器时见过太多这种错误——明明接线没问题，就是读不通，最后发现有人传了0xD4，HAL库又左移一位，结果地址完全对不上。在这里顺便说一下，读寄存器时，I2C先发一个寄存器地址字节，然后自动切换到读数据模式，这在HAL函数里都封装好了，不用自己折腾“重复起始条件”这些细节。

3. 传感器初始化与寄存器配置

3.1 读取WHO_AM_I，先确认“我是谁”

初始化的第一步不是配置量程，而是读WHO_AM_I寄存器（0x0F）。这颗料固定返回0x6A，这是ST出厂写死的设备标识。你可能会问，为什么先干这个？原因很实际：它能一次性验证I2C总线、设备地址、供电、焊接是否都正常。如果连设备标识都读不到，后面配置再对都没用。

uint8_t lsm6d3_check_id(void) { uint8_t id = lsm6d3_read_reg(0x0F); if (id != 0x6A) { return 1; // 失败 } return 0; // 成功 }

注意一个容易搞混的点：这片料的WHO_AM_I值和I2C设备地址都是0x6A，纯属巧合。新手经常问“这俩是不是同一个东西”，完全不是——WHO_AM_I是寄存器里的设备ID，I2C地址是器件在总线上的门牌号。理解这一点，你排查问题时就多了一分清醒：读到0x6A，说明门牌号找对了，器件也响应了；读不到，则要从总线和地址两方面查。

实际调试中，如果读WHO_AM_I返回0xFF，优先检查接线和上拉；返回0x00，优先检查供电，看VDD是否真的给了3.3V，共地是否牢靠。也可以试试把SDO从接地改成接高，把地址换成0x6B再读一次，排除地址选错的可能。

3.2 软复位、BDU、寄存器自增，一个都不能省

确认ID正确后，我习惯先对传感器做一次软复位。通过CTRL3_C寄存器（0x12）的第0位SW_RESET写1，芯片内部所有配置寄存器会恢复默认值，复位完成后该位自动清零。为什么要做这一步？因为你不确定传感器当前是不是别人动过、处于什么状态，直接配置可能残留脏数据。软复位给了一个干净的起点。

写完软复位后要等待一段时间，我一般延时10到50毫秒，让内部上电流程跑完。之后同一个寄存器要再写一次，把关键功能位配置好。在CTRL3_C上，我会开两个位：

• 第6位BDU（Block Data Update）置1：数据输出寄存器在读取过程中被锁存，直到读完6个字节才允许更新。如果不开启，你把陀螺仪高8位读走后、低8位读来之前，传感器恰好更新了数据，那你拼出来的16位值就是“上半身高、下半身矮”的畸形数据，数值跳变大得离谱。
• 第2位IF_INC（寄存器地址自动递增）置1：连续读取时地址自动加1。这样你可以直接从OUTX_L_G（0x22）开始连续读6个字节，一次I2C事务把X、Y、Z轴的原始数据全拿回来，省掉频繁切换地址的开销。

所以初始化里这两行代码顺序是有讲究的：先软复位，再配BDU和IF_INC。

lsm6d3_write_reg(0x12, 0x01); // SW_RESET=1 HAL_Delay(50); lsm6d3_write_reg(0x12, 0x44); // BDU=1, IF_INC=1

0x44换算成二进制是0100 0100，对应第6位和第2位为1。新手容易犯的错是直接在软复位后马上写其他配置寄存器，不加延时，结果配置被内部复位过程覆盖，表现就是“明明写了量程配置，读出来还是默认值”。

3.3 陀螺仪和加速度计的量程、ODR怎么配

LSM6D3TR-C的加速度计配置寄存器是CTRL1_XL（0x10），陀螺仪配置寄存器是CTRL2_G（0x11）。两者位定义类似：高4位是ODR设置，接下来几位是量程选择。这个项目里我用的配置是加速度计±2g、输出速率104Hz，陀螺仪±2000dps、输出速率104Hz。

为什么选104Hz？对于读取人体手势动作、做姿态演示，104Hz的速率足够，且数据量不大，用串口打印不会刷屏太严重。如果你做的是快速旋转或振动检测，可以按需抬到208Hz、416Hz甚至更高，代价是功耗和数据量上升，轮询周期也得跟着缩短——这个道理在后面第4章会体现出来。

陀螺仪量程我选了±2000dps，这是这颗料的最大量程，能覆盖绝大多数快速转动场景。代价是灵敏度低——在±2000dps下，每个LSB代表0.07dps，而±250dps下每个LSB只代表0.00875dps。这个后面换算数值时要对得上。

那么CTRL1_XL和CTRL2_G到底写什么值？我给出计算过程：

CTRL1_XL：104Hz对应的ODR_XL编码是0100，左移4位得到0x40；±2g对应的FS_XL编码是00，左移2位得到0x00。两者相或，结果是0x40。

CTRL2_G：104Hz对应的ODR_G编码是0100，左移4位得到0x40；±2000dps对应的FS_G编码是11，左移2位得到0x0C。两者相或，结果是0x4C。

lsm6d3_write_reg(0x10, 0x40); // 加速度计：104Hz, ±2g lsm6d3_write_reg(0x11, 0x4C); // 陀螺仪：104Hz, ±2000dps

这里最容易被手册搞晕的地方是FS_G的位位置。LSM6D3TR-C的CTRL2_G里，FS_G占第3位和第2位，左移2位就对了。但ST另有一些老型号把量程位放在更高位，复制代码时一定要先查数据手册确认位域，不能想当然。《数据手册》里寄存器位的图表就是你这辈子最好的朋友，把CTRL1_XL、CTRL2_G、CTRL3_C这几页打印出来放桌上，比任何教程都靠谱。

3.4 别忘了检查状态寄存器STATUS_REG

配置完成后，初始化就算基本完成。接下来要理解的是状态寄存器STATUS_REG（0x1E）。它里面有两组“数据就绪”标志位：

• 第0位（XLDA）：加速度计数据可用标志，置1表示加速度计有新数据可以读。
• 第1位（GDA）：陀螺仪数据可用标志，置1表示陀螺仪有新数据可以读。

很多人在这里出错：想读陀螺仪数据，却去判断XLDA，或者根本不判断状态位就直接读输出寄存器。数据手册明确要求，最稳妥的做法是等到相应标志置1后再读，否则读到的可能是上一帧数据，或者数据正在更新中。虽然开启了BDU后问题不大，但判断状态位仍然是最规范的操作。轮询逻辑的核心就是“不断检查状态寄存器，发现标志置1就去读”，这也是“轮询”名字的由来。

初始化全部完成后，我习惯读一下STATUS_REG并打印出来，确认这个寄存器能正常读。如果STATUS一直为0，大概率是ODR没配置成功，回查CTRL1_XL/CTRL2_G的写入值。

4. 轮询读取陀螺仪数据的核心逻辑

4.1 检查GDA标志的轮询写法

轮询代码的核心是一个循环。每次循环做两件事：读STATUS_REG，判断GDA是否为1；如果为1，就读陀螺仪数据输出寄存器；如果为0，就继续下一次循环。

while (1) { uint8_t status = lsm6d3_read_reg(0x1E); if (status & 0x02) { // GDA=1，陀螺仪数据就绪 uint8_t data[6]; HAL_I2C_Mem_Read(&hi2c1, LSM6D3_I2C_ADDR, 0x22, I2C_MEMADD_SIZE_8BIT, data, 6, 100); int16_t gx_raw = (int16_t)((data[1] << 8) | data[0]); int16_t gy_raw = (int16_t)((data[3] << 8) | data[2]); int16_t gz_raw = (int16_t)((data[5] << 8) | data[4]); float gx_dps = gx_raw * 0.07f; float gy_dps = gy_raw * 0.07f; float gz_dps = gz_raw * 0.07f; printf("GX=%6d GY=%6d GZ=%6d | GX=%.2f GY=%.2f GZ=%.2f dps\r\n", gx_raw, gy_raw, gz_raw, gx_dps, gy_dps, gz_dps); } }

这段代码的关键在于连续读取的6个字节，顺序和寄存器地址是对应的：从0x22开始读，依次是OUTX_L_G（低字节）、OUTX_H_G（高字节）、OUTY_L_G、OUTY_H_G、OUTZ_L_G、OUTZ_H_G。也就是说，data[0]是X轴低8位，data[1]是X轴高8位。所以16位拼装时，左移8位的必须是高字节data[1]，低字节放低位。反过来拼会导致数值完全对不上号，正负方向还可能颠倒。

SO为什么从0x22而不是分别读X高、Y高等寄存器？正是因为初始化时开了IF_INC寄存器地址自增，一次I2C事务就能把6字节都读回来，又省时间又避免数据撕裂。

4.2 从原始值到dps的换算原理

传感器输出的是16位有符号整数，但用户要的是角速度，所以必须换算。这个换算系数完全取决于量程。手册里有张灵敏度表，我常用的几档如下：

我初始化时配置的是±2000dps，所以直接用0.07作为换算系数。方法就是把原始值乘以0.07。比如原始值是1000，那对应角速度就是70dps。如果以后改成±250dps，别忘了把系数同步改成0.00875——这个表保存好，改量程时翻出来看一眼就能避免踩坑。

时序上还要理解一件事：轮询频率和ODR的关系。当我把传感器ODR设为104Hz时，理论上每秒钟会有104次新数据就绪，GDA标志每约9.6毫秒置1一次。如果你的主循环跑得太慢，比如串口打印用了大量时间，那么有些帧会来不及读，表现为打印出来的数据数量跟不上设定ODR。反过来，如果轮询频率比ODR快，一个周期内可能只有一次读到置1的机会，其余轮询读到0是正常的，不用慌。

4.3 串口打印的压力，要心里有数

上面的示例代码里直接用printf打印，在STM32C5上没问题，但要清楚printf格式化浮点数非常耗时，尤其是把6个数字和3个浮点数一起拼成一行，耗时可能达到毫秒级。在这一毫秒里，GDA标志会继续置1，你下一轮循环可能读到老数据或者漏掉几帧。调试阶段这无所谓，但如果后续你要做数据采集、姿态解算，建议打印频率降低，比如每100ms打印一次，或者只打印原始整数，别在循环里无脑刷屏。

我实测过，在104Hz下每帧都打印浮点，串口助手基本会呈现“刷屏但偶发丢帧”的现象，这是正常现象，不必怀疑代码逻辑。想确认丢帧，可以在主循环里加一个计数器，在串口空闲时打印出来对比，这个在第5章会讲。

5. 实测效果与数据验证

5.1 静态数据：先看零偏，学会判断传感器“健不健康”

把开发板平放在桌上不动，理论上陀螺仪三个轴的角速度应该是0dps。但现实永远有惊喜：由于制造工艺、焊接应力和温度影响，芯片静止时输出并不完全是0，通常会有一个小的偏置，我们叫零偏。我手上的样片实测大约在±0.5dps范围内波动，个别片子能到1dps以上。

这一步不是让你纠结为什么不是0，而是要判断这个值是不是在一个合理范围。如果静止时某一个轴输出超过3dps甚至十几dps，那不是零偏大，而是板子在振动、焊接有问题，或者传感器已经受损——这是我遇到过的情况，焊盘虚接时陀螺仪静止读数反而乱跳。

零偏带来的问题在做姿态解算时会放大：一个1dps的零偏积分1分钟，姿态就偏了60度。所以正式用之前，一定做零偏校准。校准方法也很朴素：上电后静止，连续采集几百上千个样本求平均，得到的平均值就是零偏，之后每次读数减掉它就行。

#define CAL_SAMPLES 500 int32_t sum[3] = {0, 0, 0}; int count = 0; while (count < CAL_SAMPLES) { uint8_t status = lsm6d3_read_reg(0x1E); if (status & 0x02) { uint8_t data[6]; HAL_I2C_Mem_Read(&hi2c1, LSM6D3_I2C_ADDR, 0x22, I2C_MEMADD_SIZE_8BIT, data, 6, 100); sum[0] += (int16_t)((data[1] << 8) | data[0]); sum[1] += (int16_t)((data[3] << 8) | data[2]); sum[2] += (int16_t)((data[5] << 8) | data[4]); count++; } } float offset_gx = (float)sum[0] / CAL_SAMPLES * 0.07f; float offset_gy = (float)sum[1] / CAL_SAMPLES * 0.07f; float offset_gz = (float)sum[2] / CAL_SAMPLES * 0.07f;

校准过程要保证板子完全静止，我一般在校准前放一个软垫，把板子放在上面，然后等两三秒再开始采样，避免手放上去的残余振动影响平均值。

5.2 动态数据：验证方向对不对，坐标对不对

静态看完了，动态验证是必须的。拿板子绕Z轴顺时针旋转，观察打印里的Gz，应该出现一个明显的正值；逆时针转，Gz变负值。同理，绕X轴转时Gx变化，绕Y轴转时Gy变化。这个验证能帮你确定芯片坐标轴方向和代码里的通道对应关系是否正确。

我遇到过坐标映射搞反的情况：绕X轴转，打印出来Gy在变。后来查手册发现是芯片摆放方向问题——传感器模块在PCB上的方向不一定跟你想的一致。遇到这种情况不用改代码，把板子旋转90度重新确认坐标对应就好。如果做姿态解算，更要提前想清楚坐标系的约定，否则后面算法会一团糟。

动态读数时还会发现一个现象：手转动的角速度峰值能到几百dps，但在±2000dps量程下，读数不会溢出，这就是量程选得大的好处。如果当初选了±125dps，稍微转快一点就会看到数值突然跳到负方向——典型的溢出表现。所以日常生活场景，±2000dps是最省心的选择。

5.3 验证轮询有没有丢帧

轮询读的是“有新数据就读”，但如果主循环里耗时超过ODR周期，就会出现丢帧。验证方法很简单：主循环里每次读到GDA置1就加一个计数器，同时每秒打印一次计数器的增量。

• 如果每秒增量稳定在104左右，说明轮询跟上了ODR，没有丢帧。
• 如果只有70、50，说明确实丢帧了，丢帧源头八成是printf耗时、延时函数或者I2C重试。

修正思路是把打印频率降低、去掉多余的HAL_Delay、把浮点格式化换成整数打印。如果你用了RTOS，还要检查是不是有更高优先级的任务抢占了I2C总线的访问。

另外，I2C超时时间也值得检查。HAL函数最后一个参数timeout是毫秒，我设为100。正常情况下一次I2C事务在几百微秒内完成，100超时绰绰有余。但如果系统主频低、I2C时钟慢，或者总线上上拉电阻太弱导致沿太慢，I2C操作就可能超时返回错误，轮询自然就“漏帧”了。把timeout设大一点能规避这类问题，但长久来看还是要解决波形质量问题。

6. 常见问题与排查技巧实录

6.1 排查问题速查表

我把调试过程中遇到比较多的问题整理成一张表，建议放到收藏夹里：

这张表里的每一项我都实际踩过。最典型的一次“数据一直为0”，查到最后发现是CTRL2_G的ODR位写错成了0，传感器处于关闭状态。虽然状态寄存器一直读得到，但数据永远不变，因为根本没在采样。

6.2 I2C通信不稳定的独家排查心得

如果I2C通信偶尔失败、时好时坏，我强烈建议做三件事：第一，用逻辑分析仪抓SCL/SDA波形，看有没有毛刺、沿是不是太缓，尤其关注ACK位有没有正常拉低；第二，把I2C时钟降到100kHz试试，如果降低了就稳定，说明电路板布线或上拉有问题，别急着加代码；第三，检查两个上拉电阻是不是都接在3.3V上，有没有虚焊。

还有一个很多人会忽略的细节：在同一组I2C总线上如果还挂了其他器件，地址冲突会表现为“明明器件在，但通信一直不对”。LSM6D3TR-C地址是0x6A或0x6B，如果总线上有另一个器件也用这个地址，就会互相打架。排查方法是把其他器件从总线上临时断开，只留传感器，再用逻辑分析仪看地址波形。

6.3 遇到数据“看起来合理”但方向总不对

这种情况我见过太多——数值大小正常，一转动，方向和预期相反。首先别改代码，先确认坐标定义。数据手册里通常有一张图，标明X、Y、Z轴方向，以及旋转方向与输出正负的关系。把开发板按图里的方向摆好，再验证一次。

如果方向和预期仍然相反，可以考虑两个层面：一是芯片的安装方向，模块板在PCB上的朝向可能跟你想的不一样，把板子旋转一下就能对上；二是代码里的符号处理，可以在最终输出前对某个轴取反。但从工程角度，我更建议在算法层处理好坐标系转换，而不是在读取层直接写负号，后者会污染原始数据，后续做标定会很痛苦。

6.4 为什么我会保留一份“最小复现”代码

调试I2C传感器时，代码越少越好排查。我习惯专门留一个main.c，只做三件事：读ID、配置寄存器、循环读数据。串口打印也尽量精简，只打印几个关键值。所有和业务相关的代码全都不放进来。这样一旦出了问题，我只能怀疑三件事：接线、寄存器配置、I2C时序。一旦加入别的逻辑，排查范围就会爆炸式扩大。

这个“最小复现”文件也是后面做中断、DMA、FIFO版本时的对照基线。每换一种读取方式，我都会回来跑一遍最小复现代码，确认传感器本身没问题，再上手新方式。别看这个习惯土，它帮我避掉的坑比任何调试器都多。

7. 几个容易忽略的细节

7.1 I2C地址到底是7位还是8位，别在这里翻车

我觉得值得反复强调：HAL库的I2C地址是7位，直接传0x6A即可。但有大量教程、老代码甚至有些驱动库用的是8位地址，即0x6A左移一位变成0xD4。如果你混用了两种约定，I2C从机地址会变成完全不同的两个值，通信必然失败。判断方法很简单：如果HAL_I2C_Mem_Read返回值一直是HAL_ERROR，先去看看你传入的地址到底是不是7位。

另外，SDO状态不通时地址会变，这在我前面提过，但值得再记一次：SDO接GND是0x6A，SDO接VDD是0x6B。在同一个项目里，如果你复制别人的驱动而别人用的是0x6B，而你硬件上把SDO接地了，那就得改回去。

7.2 寄存器读回验证：写进去的东西，确认真的写进去了

配置寄存器写完以后，我一般会再把这个寄存器读回来，打印或者和期望值比对。这一步很多人省略，但它能在初始化阶段就暴露问题，而不是等你发现“数据完全不对”时才回头排查。

uint8_t ctrl2_g = lsm6d3_read_reg(0x11); printf("CTRL2_G = 0x%02X\r\n", ctrl2_g);

如果读回来是0x00，说明写入根本没成功，优先怀疑I2C写时序或地址。如果读回来是0x4C，那就说明配置写进去没问题，传感器状态你心里就有底了。别嫌这步啰嗦，调试时多一个确认点，排查链就短一大截。这也是我推崇“每一步都能验证”的编程习惯的原因。

7.3 供电和去耦，别让电源噪声背锅

传感器对电源噪声比较敏感，尤其是陀螺仪这种高精度模拟前端。模块板通常已经放了去耦电容，但如果你自己飞线搭板子，务必在VDD和GND之间加一个100nF陶瓷电容，靠近芯片放置。电源是从DC-DC还是LDO来的也有讲究：DC-DC开关噪声大，最好给传感器单独用LDO供电，或者至少加一个磁珠再加电容。

我遇到过一种诡异现象：数据在80%的情况下正常，但只要电机或者继电器一启动，陀螺仪数据立刻乱跳。后来发现是电源被拉出尖峰，传感器扛不住。加了去耦电容和稳压后，问题立刻消失。所以说传感器数据不对，别总觉得是代码问题，先把电源质量查清楚。

8. 我的实操心得

最后再分享一点个人体会。用轮询驱动LSM6D3TR-C看起来是很基础的活，但我始终认为，静下心把这个过程走一遍，比上来就抄一个FIFO+中断的完整驱动有用得多。你在这过程中会真正理解I2C时序怎么走、状态寄存器怎么用、数据怎么拼接、灵敏度怎么查，这些知识是通用的，换一颗传感器、换一个平台照样能用。

我认为对于STM32C5这颗带FPU的MCU来说，轮询读IMU只是一个起点。等你把轮询彻底吃透，下一步可以试着用中断方式替代轮询，对比一下CPU占用率的变化；再往后可以用DMA配合FIFO，让传感器把一批数据缓存起来，主控一批一批取走；更进一步，用陀螺仪和加速度计数据做姿态解算、输出欧拉角或四元数。这些进阶玩法的地基，就是你现在在轮询里学到的“读状态、读数据、算单位”这套基本动作。

所以我给你的建议是，别急着嫌弃轮询“低级”。赶紧把手上的板子翻出来，按文章第2章接好线，第3章把配置写进去，第4章把轮询代码抄下来，串口看到陀螺仪数据跳出来的那一刻，你对这颗传感器和I2C的理解就真正落地了。剩下的，都是水到渠成的事。