企业官网建设流程全解析

简介：STM32F103C8T6与MPU6050惯性测量单元的完整工程，专为需要快速实现姿态解算的嵌入式学习者和开发者设计，提供从底层驱动到上层算法的完整解决方案。工程基于Keil MDK搭建，可直接编译并下载运行，省去环境配置与引脚初始化等繁琐步骤，其目录结构清晰，便于按模块学习与裁剪。压缩包共包含188个文件，整体大小仅6.16MB，其中含有35个C源文件、32个头文件，覆盖定时器、ADC、I2C、USART、CAN等标准外设库驱动模块，并附带axf、hex等编译产物及工程配置文件，方便直接烧录与二次开发。已有2610人学习使用，广泛适用于飞行器、机器人、智能穿戴、健康监测等众多场景。资源内配有示例代码和说明文档，详细演示通过I2C接口读取MPU6050数据并完成姿态解算的完整流程，可有效降低开发门槛，助力快速验证算法并移植到自身项目中，对初学者尤其友好。

1. 这个完整工程解决的痛点：F103C8T6与MPU6050为何经常搭在一起

先说结论：STM32F103C8T6加MPU6050这对组合，几乎垄断了大学生课设、电子设计竞赛培训、个人DIY平衡车/云台/手势控制项目的第一阶段选型。原因并不复杂——F103C8T6是市面上最容易买到的ARM Cortex-M3芯片，64脚LQFP封装，20K RAM、64K Flash，价格常年稳定在几块钱，而MPU6050则是全球出货量最大的六轴惯性传感器，内置三轴陀螺仪和三轴加速度计，I2C接口就可以通信。这两个芯片组合在一起，材料成本可以控制在15元以内，功能上却足够支撑姿态解算、运动检测、倾角测量等一堆常见需求。

但是问题也恰恰出在这里：芯片经典、资料泛滥，真正能拿来就用的完整工程却没那么好找。网上下载的例程要么用的库版本太老，打开后编译报错上百条；要么只有核心代码文件，缺少系统初始化部分和串口调试封装；要么硬件引脚定义和手上的最小系统板对不上，还要自己对着原理图改半天。我见过太多人在这一步卡住，明明传感器和主控都是好的，最后却因为工程文件不完整而放弃。

这个工程的设计目标很明确：基于标准外设库，把MPU6050的数据读取、姿态解算、串口打印全部封装好，下载到STM32F103C8T6最小系统板上，接好线，打开Keil工程，编译，烧录，串口助手就能看到实时的加速度、角速度和姿态角数据。不需要额外移植第三方驱动，不需要自己写I2C协议栈，更不需要改引脚定义。整个过程应该在一小时内完成从零到出数据。

适合看这篇文章的人：刚学会新建STM32工程但还没碰过I2C传感器的新手，准备做平衡车或机械臂但想先验证姿态传感器数据的人，以及纯粹想搞明白MPU6050初始化流程和数据格式的进阶学习者。

2. 硬件接线：从最小系统板到传感器模块，少走冤枉路

2.1 引脚资源的正确分配思路

STM32F103C8T6虽然有48个引脚，但实际可用的GPIO数量并不算多，尤其是如果工程里还要挂OLED、按键、电机驱动，资源规划就得提前想清楚。这个工程里MPU6050使用的硬件I2C1引脚，默认映射在PB6（SCL）和PB7（SDA），这是STM32上最标准的I2C引脚组合，也是绝大多数MPU6050例程默认使用的引脚，尽量不要把I2C重映射到其他引脚，除非你有特别的理由。

工程里另外用到了串口1（PA9/PA10）作为调试输出口，波特率设置为115200。串口1是最常用的调试串口，因为ST-Link的虚拟串口默认就接在这两个引脚上，如果你的板载ST-Link支持虚拟串口，一根USB线就能同时完成烧录和串口通信，省一个USB转TTL模块的钱。

GPIOA的其他引脚留空，方便后续扩展按键、PWM输出等。这里有个选型逻辑值得说：PB6/PB7作为I2C引脚，与串口、SWD下载口都不冲突，这是F103C8T6引脚分配中“安全边际”最大的一种接法。

2.2 接线的几个关键细节

具体接线非常直接，STM32最小系统板和MPU6050模块之间只需要四根线：

接线看似简单，但有几个细节不注意就会出问题。首先是供电，MPU6050模块上的电压稳压芯片（通常是RT9193或ME6211）虽然允许输入5V，但如果你用的是那种不带稳压的裸片小板，直接接5V就会烧掉传感器。安全做法是始终用3.3V供电，反正STM32F103C8T6的板载LDO已经输出3.3V，直接从排针上取电就行。

其次是I2C上拉电阻。MPU6050模块上通常已经焊了4.7K或10K的上拉电阻到3.3V，所以不需要额外在STM32这边再配置内部上拉，甚至如果你用软件I2C并且自己开了内部上拉，也不会出问题。但这里有个小坑：STM32的硬件I2C在开漏输出模式下，如果外部上拉电阻值太大（比如100K以上），信号上升沿会变得很慢，可能导致通信不稳定。模块上那两颗默认的10K电阻一般是够用的。

最后是接线长度。I2C在100K标准模式下对线路长度不敏感，但如果你用杜邦线飞了20厘米以上，而且旁边有电机这种强干扰源，建议把I2C时钟降到50K以下，或者换成双绞线。在实际项目中，传感器离主控10厘米以内是最稳的布局。

2.3 电源滤波与去耦

MPU6050对电源纹波比较敏感，尤其是陀螺仪数据，在电源噪声大的时候会出现明显的漂移。这个工程虽然能用，但如果你的板子供电来自电机驱动电源或者USB口带载较重，建议在MPU6050模块的VCC和GND之间加一个10uF的钽电容和0.1uF的陶瓷电容并联，位置越靠近传感器越好。

我自己测试时还发现一个有意思的现象：用手触摸MPU6050的金属外壳或附近的GND网络，读数会有微小变化，这是人体耦合噪声导致的。所以焊接或者触摸测试时，尽量只接触模块边缘，不要大范围覆盖传感器区域。这些细节在网上的大多数例程里都不会提到，但对实际数据质量影响很明显。

3. 工程结构拆解：一份能直接编译的代码到底该怎么组织

3.1 标准库和HAL库的取舍，为什么选标准外设库

这个工程使用的是ST标准外设库（Standard Peripheral Library，简称SPL）而不是STM32CubeMX生成的HAL库。原因很实际：第一，F103系列的标准库已经非常成熟稳定，网上存量资料最多，遇到问题随便一搜就有答案；第二，标准库的函数直接操作寄存器，代码执行效率高，对于I2C这种对时序有要求的通信方式，更容易从底层理解问题；第三，很多竞赛模板和课设代码都是标准库写的，用标准库方便大家对照参考。

HAL库的抽象层次更高，代码生成方便，但对于初学者来说，一旦遇到HAL_I2C接口卡死的问题，排查难度反而更大，因为中间隔了好几层封装。对于“要快速跑通一个MPU6050工程”这个目标，标准库是最短路径。

工程在Keil MDK的组织结构是这样的：

Project/ ├── User/ │ ├── main.c // 主函数，初始化流程 │ ├── stm32f10x_it.c // 中断服务函数 │ ├── delay.c/h // 延时函数 │ └── uart.c/h // 串口初始化与printf重定向 ├── MPU6050/ │ ├── mpu6050.c/h // 传感器寄存器读写函数封装 │ └── inv_mpu.c/h // DMP姿态解算库 ├── Hardware/ │ ├── i2c.c/h // STM32硬件I2C1驱动 ├── StdPeriph_Driver/ // 标准外设库源文件 ├── Core/ // 启动文件、系统时钟配置 └── Project.uvprojx // Keil工程文件

这种分层方式的好处在于：底层硬件驱动（I2C、串口）和上层业务逻辑（传感器数据读取、姿态解算）完全隔离。后面你想把MPU6050换成其他I2C传感器，只需要替换MPU6050目录下的文件，驱动程序不需要改动。

3.2 各模块的核心职责和依赖关系

main.c负责整个系统的初始化顺序：先是时钟配置（SystemInit），然后是延时函数初始化、串口初始化、I2C初始化、MPU6050初始化。这个地方有一个常见错误值得提醒：很多人会在MPU6050初始化之前就调用printf打印调试信息，但此时串口还没初始化，数据会全部丢失。这个工程里把串口初始化放在I2C之前，就是避免这种时序问题。

i2c.c是纯底层驱动，里面实现了I2C1的GPIO配置、初始化以及字节读写函数。这里我强烈建议直接使用硬件I2C而不是软件模拟I2C。虽然硬件I2C在STM32上偶尔出现总线锁死的情况（后面会专门讲），但它的CPU占用率低，通信速率稳定，中断处理也更规范。软件模拟I2C虽然代码更直观，时序可控，但对于初学者来说，一旦遇到时序不精准导致通信失败的场景，排查难度会更高。

uart.c里的重点是printf重定向。工程通过重写fputc函数，把printf输出定向到串口1，这样在调试时直接用printf打印姿态数据，非常方便。这个文件在工程里虽然只有十几行代码，但少了它，所有调试信息都出不来，属于典型的“小文件大作用”。

mpu6050.c是传感器驱动层，包含初始化配置、单字节/多字节读写、数据读取三个层次。inv_mpu.c则是InvenSense官方提供的DMP姿态解算库，用于把原始的加速度和角速度数据融合成四元数，进而转换成欧拉角。这两个文件放在一起，区分了“读寄存器”和“解算姿态”两个不同层次的工作。

3.3 中断、延时和通信速率的配合

工程里延时函数使用SysTick实现，提供us和ms两种粒度。MPU6050初始化过程中，很多寄存器写入之后需要等待一段时间才能生效，系统手册里要求的是“等待至少30ms”，实际使用中50ms更保险。这个细节对稳定性很重要。

I2C速率配置为100K标准模式，也就是I2C_InitStructure的I2C_ClockSpeed参数设为100000。虽然STM32的硬件I2C可以到400K快速模式，MPU6050也支持400K，但100K更稳定，尤其在杜邦线连接的情况下，抗干扰能力更强。MPU6050的采样率我设置为100Hz，也就是DMP输出速率100次每秒，这个速率对于大部分姿态显示和控制应用来说已经完全够用，串口每10ms输出一帧数据，不会造成数据堵塞。

4. 核心代码走读：从初始化到串口滚动的原始数据

4.1 MPU6050初始化流程完整拆解

MPU6050上电后默认处于睡眠模式，必须先通过寄存器配置唤醒。整个初始化流程看起来是几行函数调用，但每一个步骤背后都有明确的寄存器操作逻辑：

第一步是唤醒传感器，往电源管理寄存器1（PWR_MGMT_1，地址0x6B）写入0x00，清除SLEEP位。这里有一个容易忽略的细节：在上电初期，传感器内部的时钟还没有稳定，所以唤醒后最好延时100ms再继续下一步。

第二步是设置陀螺仪量程，往陀螺仪配置寄存器（GYRO_CONFIG，地址0x1B）写入0x18，对应的量程是±2000°/s。为什么选这个量程而不是±250°/s？在课设和竞赛场景里，最常见的动作是快速转动传感器模拟运动轨迹，±250°/s的量程很容易超限。量程越大，原始数据可以表示的范围越大，虽然精度会降低，但对于F103C8T6这个级别的处理能力来说，±2000°/s完全够用。

第三步是设置加速度计量程，往加速度计配置寄存器（ACCEL_CONFIG，地址0x1C）写入0x00，对应的量程是±2g。加速度计量程的选择逻辑和陀螺仪不同：在静止状态下，加速度计测到的就是重力加速度（1g），±2g的量程提供了最佳的分辨率，读出来的重力方向数据更精确，有利于后续倾角计算。

第四步是设置数字低通滤波器（DLPF），这是整个初始化里直接影响数据质量的一步。往配置寄存器（CONFIG，地址0x1A）写入0x03，对应的滤波器带宽是44Hz。这个值是从测试中调出来的：带宽太高（比如260Hz）时，数据里混入的高频噪声太多，串口打印出来的数值跳动幅度很大；带宽太低（比如5Hz）时，数据确实平滑了，但响应变迟钝，转动传感器后姿态角要过一会儿才跟得上。44Hz是一个兼顾平滑度和响应速度的折中值。

4.2 DMP库与自解算的选择逻辑

MPU6050的姿态解算有两种主流方案：一种是使用官方DMP（Digital Motion Processor）固件，在传感器内部直接完成姿态融合，输出四元数；另一种是自己在MCU上跑互补滤波或者Mahony滤波算法，从原始数据算出姿态角。

这个工程选择的是DMP方案，原因有两点。第一，DMP库输出的四元数经过官方优化，姿态解算的效果稳定，万向节锁和漂移问题都处理得比较好，不需要自己去调滤波器的权重系数。第二，DMP在传感器内部完成融合，MCU只需要通过I2C读取结果，CPU占用率极低，后续就算要在F103C8T6上同时跑电机控制、显示刷新，也不会因为姿态解算而卡顿。

当然，DMP方案也有代价。inv_mpu库压缩包大概几十KB，放在Flash里没什么压力，但库的初始化过程比较繁琐，尤其是firmware加载那一步，一旦I2C通信不稳定，固件加载就会失败，导致初始化卡死。后面会专门讲这个问题。

自解算方案适合想深入理解姿态融合算法的人，比如上手Mahony滤波只需要几十行代码，而且在静态情况下效果能调得不错。但动态效果和DMP相比还是有差距，尤其在大角速度转动时，互补滤波的滞后和超调问题比较难调好。

同时保留两种方案，工程里通过宏定义来选择：默认使用DMP方案，如果想切换到自解算模式，注释掉USE_DMP宏，调用自解算函数即可。这个设计方便了不同需求的使用者，也方便对比两种方案的数据差异。

4.3 原始数据与姿态数据的完整输出链路

从MPU6050读取数据到串口输出，中间经过的链路是这样的：

加速度计和陀螺仪的原始测量值存储在传感器内部的寄存器组中，从0x3B到0x48共14个字节，包含加速度X/Y/Z各16位、温度16位、角速度X/Y/Z各16位。mpu6050.c里使用I2C多字节读取函数，一次性把这14个字节读出来，在内存里拼接成6个16位有符号整数。

这里有一个经典的字节序问题：MPU6050的寄存器数据是高位在前（大端模式），在把寄存器值拼成整数时，必须先把高8位左移8位，再与低8位做或运算。顺序搞反了，加速度计和陀螺仪的数据就会严重错乱，表现为数值乱跳甚至静止时非零。

如果使用DMP，读取的是FIFO缓冲区的数据，经过inv_mpu库的dmp_read_fifo函数处理，输出四元数q0、q1、q2、q3。四元数本身不能直接查看，需要转换成欧拉角才能直观理解。工程里使用了标准的四元数到欧拉角转换公式，输出Yaw、Pitch、Roll三个角度，单位是度。这样串口打印出来的数据就是直观的“当前朝向”。

串口输出的数据帧格式是：

Acc: X=1234 Y=-567 Z=16384 | Gyro: X=12 Y=-3 Z=8 | Yaw=45.2 Pitch=12.3 Roll=30.1

每一行代表一次采样，每行以换行符结尾。用串口助手打开后，可以看到数据持续滚动。如果你的传感器静置在桌面上，Accel的Z轴数值应该接近16384（±2g量程下1g对应的值约为16384），X和Y轴接近0，这组特征数据可以帮助判断传感器是否正常工作。

5. 编译下载实测：Keil工程细节与烧录验证

5.1 Keil工程配置的关键选项

这个工程的Keil版本是MDK5.29，兼容性向下支持到5.17，不建议用更老的版本，因为标准外设库的头文件路径格式在新版本中有变化。工程文件中已经配置好了所有头文件路径、宏定义和Flash下载算法，打开后直接编译就行。

但有几个配置项值得你自己去检查一下，因为它们决定了编译能否一次通过。首先是Device选择，必须确认是STM32F103C8系列，这个在工程里已经选好。其次是C/C++选项卡里的Define要注意包含三个必填项：STM32F10X_MD、USE_STDPERIPH_DRIVER，这两个宏告诉编译器当前芯片是中等密度产品，并且使用标准外设库。

然后是Flash Download选项卡。如果Debug选项里选择的是ST-Link，Programming Algorithm里必须添加STM32F10x Medium-density 64K Flash算法，如果没有这个算法，烧录时会直接报错Flash下载失败。工程文件里已经配好，不过换一台电脑打开工程时，这个设置偶尔会因为Keil版本不同被重置，编译前最好看一眼。

编译目标选的是Release模式，优化等级设为-O0，也就是不优化。不优化意味着代码执行顺序和C语言源码保持一致，调试时可以单步跟踪，逻辑一目了然。实际测试中，关闭优化后生成的代码在20K RAM和64K Flash上运行完全没问题，不需要为了省空间开优化。对于这种数据采集型工程，宁可代码大一点，也要保证可调试性。

5.2 ST-Link烧录与串口验证

编译通过后会生成一个约36KB的HEX文件。烧录方式我推荐ST-Link，因为它是F103C8T6最小系统板上最常见的下载接口。连接方式是ST-Link的SWDIO接板子的SWDIO引脚，SWCLK接SWCLK引脚，GND接GND，3.3V接3.3V，四条线就够。

烧录成功后，用USB转TTL模块连接串口1，RX接PA9（STM32的TX），TX接PA10（STM32的RX），注意交叉连接。如果你的最小系统板上有板载ST-Link且引出了虚拟串口，直接插USB线，在设备管理器里就能看到一个COM口，不需要额外接线。打开串口助手，选择对应COM口，波特率设为115200，8位数据位，1位停止位，无校验，点击打开，就能看到姿态数据持续输出。

实测时有一个判断数据是否正常的快速方法：保持传感器静止，观察串口输出的Yaw、Pitch、Roll值。正常情况下，Pitch和Roll应该在0度附近波动，波动幅度不超过±1度，Yaw值会缓慢漂移但不应该跳变。如果Pitch和Roll在静止时就在±45度以上跳来跳去，说明传感器初始化时量程配置或者DLPF设置有问题，需要检查代码配置。

5.3 运动状态下的数据特征

把传感器拿在手里，做几个不同动作，可以检验传感器数据是否可信。首先保持水平，屏幕上Roll应该接近0度，Pitch也接近0度，Yaw是任意值，表示当前朝向。其次把传感器绕Z轴快速旋转，Yaw值应该跟着同步变化，响应的时间延迟很小，如果DMP输出频率设置了100Hz，人眼几乎感知不到延迟。

还有一个值得尝试的动作：把传感器沿着X轴翻转90度，Pitch值应该迅速稳定在90度附近，而Roll和Yaw保持不变（或者只有微小变动）。如果翻转后的角度值和实际角度相差较大，可以在静止状态下进行一次陀螺仪零偏校准。具体操作是在传感器完全静止3秒后，记录陀螺仪的偏置值并做补偿，这个功能在工程里预留了接口，通过串口发送“cal”字符即可触发。校准参数会保存到结构体中，下次上电自动使用。这个小功能看起来不起眼，但实际做平衡车项目时非常关键——零偏没校准好的陀螺仪，会让姿态角在静止状态下也不断漂移，控制环路根本无法工作。

6. 踩坑实录：五个典型问题与完整排查思路

6.1 卡死在I2C等待标志位

这是STM32硬件I2C最经典的坑。现象是程序跑到I2C等待事件标志位的while循环里，弹出硬件错误中断，之后卡死不运行。原因是STM32的硬件I2C在通信异常时，总线状态寄存器的主模式标志位没有正确置位，导致等待EV5事件的循环永远等不到条件满足。

排查思路是先确认接线是否正确，PB6/PB7有没有和别的外设引脚冲突。其次是确认上拉电阻有没有接，MPU6050模块上如果出于某些原因没有焊接上拉电阻，I2C总线电平悬空，通信必然失败。如果这两项都正常，可以考虑把I2C理解为“虽然能用但偶尔犯倔”，在初始化时增加一次总线复位操作——将SCL和SDA对应的GPIO全部配置为推挽输出，手动翻转9个时钟周期，可以让挂在总线上的设备释放总线。这个操作在这个工程的i2c.c初始化函数开头已经加了，所以如果你直接编译这个工程，大概率碰不到这个问题。

6.2 陀螺仪数据静止时剧烈跳动

陀螺仪数据在静止时应该是接近0的，如果你发现静止状态下陀螺仪Z轴数值在几百甚至上千的范围跳动，先不要怀疑传感器坏了，大概率是电源噪声问题。MPU6050内置的ADC对电源噪声比较敏感，如果VCC和GND之间没有足够的去耦电容，电源纹波会直接耦合进测量结果。

另一种可能是DLPF配置问题。DLPF带宽设置太高，陀螺仪的高频噪声没有被滤除，数据跳动幅度自然大。可以先检查初始化代码里CONFIG寄存器写入的是不是0x03，如果用的是默认的0x00（带宽260Hz），数据跳动幅度会比较明显。还有一种情况是在电机等大功率负载启动瞬间，数据会短暂跳变，这是电磁干扰导致的，除了加强屏蔽和滤波之外，软件上可以在DMP输出端加一个滑动平均滤波，进一步平滑数据。

6.3 读出的加速度数据全是0，但陀螺仪正常

这个现象通常意味着I2C通信本身没问题，但加速度计的某个寄存器配置不正确。MPU6050虽然集成了加速度计和陀螺仪，但在某些寄存器配置下，加速度计会被部分关闭。最常见的原因是写入ACCEL_CONFIG寄存器的值不对，导致加速度计数据通道异常。实际排查时，优先检查初始化代码中0x1C寄存器的写入值。

还有一个小概率原因：传感器的FSYNC引脚被接到了高电平。MPU6050的FSYNC引脚用作外部帧同步信号，如果该引脚悬空，模块内部默认的逻辑电平可能不确定。个别模块把FSYNC引出来但没有接固定电平，这种模块在使用时必须把FSYNC引脚接地。如果你买到的MPU6050模块上没有FSYNC引脚引出（市面上多数模块没引），这个坑可以不考虑。

6.4 串口打印乱码

串口打印出来的不是正常数据，而是乱码，这种问题90%出在波特率不匹配上。检查串口助手设置的波特率是不是和工程里配置的一致（本工程是115200）。但我遇到过一种更容易忽略的情况：STM32的串口波特率由APB2总线时钟计算得出，如果系统时钟不是工程默认的72MHz（比如有人改过时钟配置，把系统时钟降到了8MHz），而串口初始化函数里的波特率计算仍然假设72MHz，实际的波特率就会偏离115200，导致乱码。

排查方法是检查main.c里SystemInit调用前后的时钟源设置，或者直接在调试模式下查看RCC_GetClocksFreq函数输出的系统时钟值。如果确实改了系统时钟，需要同步调整串口初始化中的波特率参数，或把USART_BaudRate计算改用实际波特率。

6.5 静态Pitch和Roll正确，但运动时角度波动大

静止时角度数据很漂亮，一旦拿在手里晃动，角度波动就非常剧烈，这种现象一般是DMP的输出频率和姿态更新频率不匹配导致的。DMP库内部有一个采样率配置，如果传感器原始采样率是100Hz，但DMP输出频率被配置为200Hz，就会导致一部分数据被重复计算或丢帧，体现在角度上就是波动加大。

处理方法是查看inv_mpu.c中dmp_set_fifo_rate函数的参数，确认它和传感器采样率配置一致。工程里统一设置为100Hz，如果你在使用过程中调整过采样率，记得两边要同步修改。另一个可能原因是传感器在运动过程中超过了量程上限，陀螺仪数据被截断，融合出来的姿态角自然不对。这个问题通过查看串口输出中的Gyro原始值就能发现，如果瞬间超过2000dps，需要把量程改回±2000dps甚至检查是否配置被意外改动。

7. 扩展方向建议：这套工程能延伸到哪些项目里

这个工程虽然是围绕MPU6050做的，但它的框架设计让后续扩展变得非常方便。最直接的扩展是做一个小型平衡车或自平衡平台，在现有姿态输出基础上加上PID控制，用PWM驱动直流电机，就是一个完整的闭环系统。F103C8T6的定时器资源足够输出两路带死区的PWM信号，驱动H桥或者L298N模块都没有问题。

第二个扩展方向是手势识别。MPU6050输出的角速度数据可以通过动态时间规整（DTW）算法做手势模板匹配，识别上下左右挥动、画圈等简单手势。这个方向的代码量不大，主要是采集样本数据并设定阈值，适合做智能穿戴设备的小demo。

第三个方向是无线姿态传输。把现有的串口输出接到ESP8266或A7670C等无线模块上，把姿态数据通过MQTT或者TCP协议上报到手机APP或云平台，就变成了一个远程姿态监测系统。在机械设备的状态监测场景里，把MPU6050贴在设备外壳上，监测振动特性和姿态变化，能提前发现设备倾斜或异常振动。

我在实际使用中发现一个不到最后一刻不会意识到的细节：MPU6050的温度输出寄存器读取的值可以用来做传感器温度补偿。在长期运行的设备中，传感器工作一段时间后温度升高，陀螺仪零偏会随之缓慢漂移，姿态角也会轻微漂移。如果项目功耗和算力允许，可以周期性读取温度值，为陀螺仪零偏做温度补偿。这个工程里已经读取了温度寄存器，但暂未写入补偿逻辑，后续有需要可以在这个基础上扩展。

另外再分享一个调试阶段的小技巧：串口输出数据时可以加一个固定的帧头，比如$和回车换行，配合PC端的串口绘图工具（比如VOFA+或匿名上位机），可以实时绘制姿态角变化曲线，比看数字直观得多。只需要在printf语句里加上帧头格式，上位机那边设置对应的分割符，就能看到数据曲线。实测下来，这个技巧在调试PID参数时价值极大，角度响应曲线的形态直接告诉你P、I、D参数该往哪个方向调。

本文还有配套的精品资源，点击获取