1. 从一颗芯片到一块会“感知姿态”的屏幕STM32F103这颗芯片在嵌入式圈子里是什么地位不用我多说。它几乎是很多人入门ARM Cortex-M3的第一颗芯片价格便宜、资料多、外设够用拿来做各种小项目再合适不过。但正因为用的人多想做出点“不一样”的东西反而更难——点灯、串口打印、驱动OLED这些例程网上一搜一大把真正能让人眼前一亮的不多。“空间姿态显示”这个题目第一次看到的时候我就觉得有意思。它要解决的核心问题很明确让一块小小的MCU能够实时感知自己在三维空间中的倾斜、旋转状态并且把这个状态直观地显示出来。听起来像是手机里的重力感应但用STM32F103从零搭一套出来涉及的东西其实相当完整——传感器数据采集、姿态解算、图形渲染、屏幕刷新每一个环节都有坑。这篇文章适合谁看如果你已经玩过STM32F103的基础外设想找一个能把I2C、SPI、定时器、DMA、浮点运算、图形库串起来的综合项目那这个方向非常合适。如果你刚接触嵌入式也能从里面看到一颗MCU是怎么把物理世界的“姿态”翻译成屏幕上看得懂的画面的。我会把整个链路拆开讲包括选型逻辑、数据流设计、姿态解算的数学原理、Arm-2D图形库的接入方式以及我在实测中踩过的那些坑。先给一个整体印象这个项目的本质是一条从传感器到屏幕的实时数据管道。MPU6050这类六轴传感器负责采集加速度和角速度STM32F103负责读取原始数据、做姿态融合运算算出俯仰角Pitch、横滚角Roll甚至偏航角Yaw最后通过Arm-2D图形库把姿态可视化到LCD或OLED屏幕上。整条链路对实时性有要求对运算精度有要求对显示流畅度也有要求所以它不是简单的“读一个数、显示一个数”而是一个需要认真设计的小系统。2. 姿态感知的硬件选型与数据链路设计2.1 为什么是MPU6050加STM32F103这个组合姿态检测的传感器选择其实不少从最简单的三轴加速度计到九轴IMU价格和复杂度跨度很大。我最终选MPU6050理由很实际它集成了三轴加速度计和三轴陀螺仪通过I2C接口输出六轴数据成本低模块化程度高资料极其丰富。对于STM32F103这个级别的MCU来说MPU6050的数据量和接口速率刚好匹配不会造成瓶颈。有人会问为什么不直接上九轴带磁力计的方案。我的经验是磁力计在室内环境下受干扰太严重电机、音箱、金属桌面都会让航向角漂得没法看。如果项目不需要绝对航向六轴做姿态融合已经足够显示俯仰和横滚。而且MPU6050自带DMP数字运动处理器理论上可以在传感器内部完成姿态解算减轻MCU负担。不过DMP的配置比较繁琐固件加载也有坑我后面会讲为什么我最终选择在STM32侧自己做融合。STM32F103的选型也有讲究。F103系列里C8T6是最常见的64KB Flash、20KB RAM跑姿态解算加图形显示刚好够用。如果要用Arm-2D做比较复杂的界面建议选RBT6或VET6这类Flash和RAM更大的型号。我实测下来C8T6跑简化版姿态显示没问题但如果要加轨迹记录、多页面切换RAM会紧张。2.2 I2C读取MPU6050的时序细节MPU6050的I2C通信看起来简单但实际调试时最容易出问题。它的从机地址是0x68AD0接地或0x69AD0接VCC很多人第一次读不出数据就是地址搞错了。STM32F103的硬件I2C外设在某些版本上有已知的锁死问题我个人的做法是直接用软件I2CGPIO模拟时序稳定可控速率调到400kHz也够用。读取流程是这样的先配置MPU6050的电源管理寄存器0x6B唤醒设备设置采样率分频寄存器0x19和数字低通滤波器0x1A然后配置陀螺仪和加速度计的量程0x1B和0x1C。量程选择很关键——陀螺仪我一般设±2000dps加速度计设±2g这样既有足够的动态范围又能保证分辨率。数据读取时从0x3B开始连续读14个字节依次是加速度X/Y/Z、温度、陀螺仪X/Y/Z每个轴两个字节高字节在前。这里有个细节读出来的原始值是补码形式需要转换成有符号16位整数。我见过有人直接用无符号读结果负角度全变成大正数姿态显示直接飞掉。提示MPU6050上电后需要一定时间稳定建议初始化后延时100ms再开始读取。另外传感器安装方向要和你的坐标系定义一致否则算出来的角度方向是反的。2.3 定时器触发采样与数据缓冲姿态解算对采样周期的稳定性要求很高。如果采样间隔忽长忽短积分运算会引入很大误差。我的做法是用TIM2或TIM3做一个1kHz的定时中断在中断里置一个标志位主循环检测到标志位后读取传感器并做融合。这样采样周期基本稳定在1ms陀螺仪积分的时间基准就准了。数据缓冲方面如果只是做实时显示不需要大缓冲一个结构体存当前六轴数据就够了。但如果你想做数据记录或者用DMA传输可以开一个环形缓冲区。STM32F103的RAM有限缓冲深度要权衡。我一般用32组数据的环形缓冲足够平滑短时抖动。这里顺便提一下SPI通过DMA读取芯片数据的思路。虽然MPU6050用的是I2C但如果你换用SPI接口的传感器比如某些型号的IMUDMA方式能大幅降低CPU占用。配置CubeMX时把SPI的RX设为DMA模式传感器数据就绪中断触发DMA传输传完一帧再处理CPU只在DMA完成中断里干活效率高很多。这个思路在高速采样场景下非常值得用。3. 姿态解算从六轴原始数据到欧拉角3.1 加速度计和陀螺仪各自能做什么加速度计测量的是比力静止时输出的是重力加速度在三个轴上的分量。通过这个分量可以算出物体相对于水平面的倾斜角度。比如加速度计X轴输出接近0、Y轴输出接近0、Z轴输出接近1g说明物体是水平放置的。如果X轴输出0.5gZ轴输出0.866g那俯仰角大概是30度。但加速度计有个致命问题它对振动和线性加速度极其敏感。设备一动加速度计的输出就混入了运动加速度算出来的角度会剧烈跳动。所以单靠加速度计只能做静态倾角测量动态下根本不能用。陀螺仪测量的是角速度单位是度每秒。对角速度做积分就能得到角度变化。陀螺仪的优点是动态响应好短时间内的角度变化非常准确。但它有零偏静止时输出不是严格的0而是有一个小偏差。这个偏差积分之后会累积成角度漂移时间越长漂移越大。我实测MPU6050的零偏如果不校准一分钟能漂好几度。所以结论很清晰加速度计长期稳定但短期噪声大陀螺仪短期精确但长期漂移。姿态融合的目的就是把两者的优点结合起来。3.2 互补滤波的工程实现互补滤波是我最推荐入门者使用的融合算法原因很简单计算量小、参数直观、效果够用。它的核心思想是用高通滤波保留陀螺仪的动态部分用低通滤波保留加速度计的静态部分然后加权融合。具体公式是这样的假设当前姿态角为angle陀螺仪积分得到的角度变化为gyro_rate * dt加速度计解算出的角度为acc_angle那么angle alpha * (angle gyro_rate * dt) (1 - alpha) * acc_angle其中alpha是滤波系数通常取0.95到0.98之间。alpha越大越信任陀螺仪动态响应越好但漂移抑制越弱alpha越小越信任加速度计静态稳定但动态跟随变慢。我在实际调试时发现alpha取0.96是个不错的平衡点。但要注意这个系数和采样周期有关。如果采样周期是1msalpha0.96意味着时间常数大约是25ms如果采样周期变成10ms同样的alpha对应的时间常数就变了。所以换采样率时一定要重新调这个参数。加速度计解算角度用反三角函数pitch atan2(accel_x, sqrt(accel_y * accel_y accel_z * accel_z)) * 180 / PI roll atan2(accel_y, sqrt(accel_x * accel_x accel_z * accel_z)) * 180 / PI这里用atan2而不是atan是因为atan2能处理分母为零的情况并且返回值范围是-180到180度更适合全姿态测量。注意STM32F103没有硬件浮点单元atan2和sqrt都是软件实现的运算量不小。如果采样率是1kHz每毫秒做一次三角函数运算CPU占用会比较高。我的做法是把融合频率降到200Hz或100Hz显示刷新用插值这样CPU压力小很多视觉效果也够流畅。3.3 卡尔曼滤波值不值得上很多人一提到姿态融合就想到卡尔曼滤波觉得互补滤波太“低级”。但我的实际经验是对于STM32F103这个级别的MCU做显示类姿态应用互补滤波完全够用卡尔曼滤波的收益和投入不成正比。卡尔曼滤波需要矩阵运算状态转移矩阵、观测矩阵、协方差矩阵的更新涉及大量浮点乘加。F103跑完整的卡尔曼滤波单次融合可能就要几百微秒如果采样率高CPU基本被占满。而且卡尔曼的参数过程噪声Q、观测噪声R调起来比互补滤波的alpha麻烦得多调不好反而效果更差。当然如果你用的是F4系列带FPU的芯片或者对姿态精度有极高要求那卡尔曼滤波值得上。但在F103上我建议先把互补滤波调好把传感器校准做扎实效果不会差。3.4 零偏校准和温度补偿陀螺仪零偏是姿态漂移的主要来源。校准方法很简单设备静止放置采集几百个陀螺仪样本求平均值这个平均值就是零偏。后续每次读取陀螺仪数据都减去这个零偏。但零偏会随温度变化。MPU6050内部有温度传感器我试过在温度变化10度的情况下零偏能变化0.5度每秒左右。如果项目工作环境温度变化大建议做温度补偿——在不同温度下测零偏拟合一条零偏-温度曲线运行时根据当前温度查表补偿。这个工作比较繁琐但对长时间运行的姿态精度提升明显。加速度计也需要校准。理想情况下水平静止时Z轴应该是1gX和Y是0。但实际有零偏和比例误差。最简单的校准是六面校准法把设备分别朝六个方向静止放置记录每个方向的输出算出零偏和比例因子。这个校准做一次就行数据存在Flash里。4. Arm-2D图形库在姿态显示中的落地4.1 Arm-2D解决了什么问题在没有图形库的情况下要在LCD上画一个姿态指示器你得自己写画线、画圆、填充多边形的函数还要处理图层叠加、透明混合、区域刷新。这些工作量大且容易出bug。Arm-2D是ARM官方推出的一个轻量级2D图形库专门为Cortex-M系列MCU设计提供了基本的绘图原语、图层操作和硬件加速接口。它最大的价值在于把图形渲染和硬件加速解耦了。Arm-2D定义了一套标准的API底层可以对接DMA2D如果芯片支持、GPU或者纯软件实现。STM32F103没有DMA2D所以走软件渲染路径但即使纯软件Arm-2D的优化也比我手写的绘图函数高效。对于姿态显示我需要画的东西包括一个圆形表盘、一个十字准线、一个表示姿态的飞机符号或小球、以及角度数值文本。Arm-2D的draw_circle、draw_line、blit等接口能直接覆盖这些需求。4.2 移植Arm-2D到STM32F103的关键步骤Arm-2D的移植不算复杂但有几个关键点容易卡住。首先从官方仓库获取源码核心文件是arm_2d.c、arm_2d_helper.c以及各种draw和transform模块。把这些文件加入Keil或STM32CubeIDE工程。然后需要实现几个底层接口一个是像素填充函数Arm-2D通过回调的方式调用你的填充实现另一个是颜色格式转换Arm-2D支持RGB565、RGB888等格式要和你的LCD驱动匹配。我用的是SPI接口的ST7789屏幕RGB565格式所以配置Arm-2D的color format为RGB565。最关键的一步是配置Arm-2D的tile机制。Arm-2D把屏幕分成多个tile每个tile独立渲染这样可以减少RAM占用。对于F103的20KB RAM我建议tile大小设为屏幕宽度的1/4或1/8比如240x320的屏幕tile设为240x40这样每个tile的缓冲只需要24040219.2KB刚好放得下。如果tile太大RAM不够会编译失败。提示Arm-2D的tile缓冲建议用静态数组分配不要用malloc避免内存碎片。F103的RAM本来就紧张动态分配风险太大。4.3 姿态指示器的绘制逻辑姿态显示的核心是把欧拉角映射到屏幕上的图形变化。我的做法是画一个类似飞机仪表盘的界面中间一个固定的飞机符号代表设备本身背景是一个会随姿态旋转的天地线。具体实现时天地线的旋转角度就是横滚角Roll天地线的上下平移量对应俯仰角Pitch。当设备向右倾斜时天地线向左旋转当设备抬头时天地线向下移动。这种映射方式符合人的直觉看起来就像是真的在透过飞机舷窗看地平线。绘制流程是这样的每一帧先清空tile缓冲然后根据当前Roll角计算天地线的两个端点坐标用Arm-2D的draw_line画出来。接着画固定的飞机符号可以用draw_line画几条线段组成一个简化的飞机轮廓。最后用Arm-2D的文本绘制功能显示角度数值。这里有个性能优化的点不要每帧全屏重绘。Arm-2D支持脏区域刷新只重绘发生变化的区域。天地线旋转时只有天地线附近的区域需要更新飞机符号和数值区域如果没变就不用重绘。我实测下来脏区域刷新能把SPI传输量降低60%以上帧率从20fps提升到40fps。4.4 屏幕刷新率与SPI带宽的平衡STM32F103的SPI接口速率有限SPI1最高可以到18MHzAPB2时钟72MHz分频4但实际驱动ST7789时考虑到信号完整性和屏幕本身的写入速度我一般跑在9MHz或18MHz。240x320的RGB565全屏数据是153600字节按18MHz SPI算理论传输时间约68ms也就是全屏刷新最多14fps。如果加上Arm-2D的渲染时间实际帧率会更低。所以全屏刷新在F103上是不现实的。必须用脏区域刷新把每次更新的区域控制在屏幕的1/4以内这样帧率能到30fps以上视觉上就流畅了。另外SPI的DMA传输可以进一步降低CPU占用——把要发送的像素数据交给DMACPU在DMA传输期间可以做姿态解算两者并行。我实测的一个配置是SPI1用DMA1_Channel3发送屏幕分4个tile每个tile 240x80脏区域检测后只刷新变化的tile。姿态融合跑在200Hz显示刷新跑在30fpsCPU占用大约60%还有余量做其他事情。5. 实测中那些让我熬夜的坑5.1 姿态角跳变与万向节死锁第一个让我头疼的问题是姿态角在特定角度附近会突然跳变。后来想明白了这是欧拉角的固有缺陷——万向节死锁。当俯仰角接近±90度时横滚角和偏航角的定义会退化导致数值剧烈变化。对于显示应用完全避免死锁需要用四元数表示姿态。但四元数到欧拉角的转换在死锁点附近仍然会有跳变。我的处理方式是在显示层做角度平滑当检测到角度突变超过阈值时用上一帧的值做插值过渡避免画面突然翻转。另外如果项目允许限制俯仰角的显示范围在±80度以内避开死锁区域。5.2 I2C总线锁死的应急处理软件I2C虽然稳定但在电磁干扰强的环境下偶尔会出现从机拉低SDA不放的情况导致总线锁死。我的应急处理是在I2C读写函数里加超时检测如果SCL拉高后SDA一直为低超过一定时间就强制发送9个时钟脉冲让从机释放总线。这个技巧在多个项目里救过我强烈建议加上。5.3 浮点运算的精度陷阱STM32F103的软件浮点是单精度的在做长时间积分时累积误差不可忽视。我遇到过陀螺仪积分几分钟后角度漂了十几度的情况排查后发现是积分累加的浮点精度损失。解决办法是用double做角度累加虽然F103的double也是软件实现速度更慢但精度足够。或者用定点数做积分把角速度乘以一个缩放因子转成整数积分完再转回浮点这样精度和速度都能兼顾。5.4 Arm-2D的版本兼容性问题Arm-2D的API在不同版本之间有变化我从旧版本升级到新版本时发现一些函数签名改了编译报了一堆错。建议锁定一个稳定版本不要盲目追新。另外Arm-2D的文档相对简略很多用法要看例程和源码才能搞明白。我建议先把官方提供的benchmark例程跑通再改造成自己的应用。5.5 屏幕花屏与SPI时序屏幕花屏是调试显示时最常见的问题。原因通常有三个SPI时钟太快导致数据错误、复位时序不对、或者初始化命令序列不匹配。我的排查顺序是先把SPI降到低速比如1MHz确认能正常显示后再逐步提速。如果低速正常高速花屏就是时序问题可以尝试调整SPI的时钟极性、相位或者在数据线加匹配电阻。还有一个容易忽略的点ST7789的初始化需要延时的地方一定要加够。比如软复位后要等120ms如果延时不够后续命令可能不生效屏幕就白屏或花屏。6. 从能跑到好用几个值得做的优化6.1 用查表法替代实时三角函数姿态解算里最耗时的运算是atan2和sqrt。如果CPU占用紧张可以用查表法替代。预先算好一个正弦表或角度表存在Flash里运行时查表加线性插值。精度会损失一点但速度提升明显。我试过用256点的atan2查表角度误差在0.5度以内对显示应用完全够用而运算时间从几十微秒降到几微秒。6.2 传感器数据的滑动平均滤波原始传感器数据有噪声直接用来解算会让显示抖动。加一个简单的滑动平均滤波窗口大小取4到8能明显平滑显示效果。但窗口不能太大否则会引入相位延迟动态响应变慢。我的经验是加速度计窗口取8陀螺仪窗口取4兼顾平滑和响应。6.3 低功耗模式的考虑如果项目是电池供电低功耗就很重要。STM32F103支持睡眠、停止、待机三种低功耗模式。姿态显示不需要一直全速运行可以在没有姿态变化时降低采样率和显示刷新率甚至进入睡眠靠MPU6050的运动中断唤醒。MPU6050自带运动检测功能可以配置一个阈值中断设备静止时不触发MCU就休眠一旦有运动中断唤醒MCU开始工作。这个方案能把平均功耗降到毫安级。6.4 参数在线整定的实现互补滤波的alpha、加速度计校准参数这些如果每次改都要重新编译下载调试效率太低。我的做法是在Flash里划一块区域存参数通过串口命令在线修改。比如发送“SET ALPHA 0.97”就更新滤波系数并写入Flash。这样调试时不用反复烧录效率高很多。串口命令解析可以用简单的状态机实现不复杂但非常实用。7. 关于这个项目我个人的一些体会做这个姿态显示项目最大的收获不是学会了某个算法或某个库而是理解了嵌入式系统里数据流的思维方式。从传感器到屏幕中间每一个环节都有它的约束——I2C的速率、CPU的算力、RAM的容量、SPI的带宽。好的设计不是把每个环节都做到极致而是在这些约束之间找到平衡点。比如姿态融合频率理论上越高越好但CPU扛不住显示刷新率理论上越高越流畅但SPI带宽不够。最后我选了200Hz融合加30fps显示看起来是个妥协但实际效果完全够用。这种“够用就好”的判断是需要在实践中慢慢积累的。另外Arm-2D这个库我越用越觉得顺手。它的设计理念很清晰就是把图形渲染抽象成tile操作让MCU也能有不错的图形体验。虽然F103上没有硬件加速但软件渲染的效率也比我预期的好。如果你在做类似的显示项目我建议花点时间研究一下Arm-2D它的学习曲线不算陡但回报很高。最后说一个调试技巧姿态显示这种项目光看代码很难发现问题一定要把中间数据打出来看。我习惯用串口把原始加速度、陀螺仪、融合后的欧拉角都打印出来用上位机画成曲线。很多时候角度不对一看曲线就知道是传感器校准问题还是融合参数问题。这个习惯帮我省了大量猜测的时间。