1. 项目概述与思路拆解1.1 我做这个项目的初衷手边正好有一块STM32F103C8T6最小系统板十几块钱的那种蓝色板子一直想拿它做点小玩意儿。网上翻了一圈发现红外避障小车、智能家居防撞提醒之类都是围绕这个芯片加上红外避障模块来做的所以我决定自己也动手把它点亮起来并且额外加一块0.96寸的OLED显示屏把检测状态直接显示出来这样调试的时候不用每次都猜程序跑到了哪里。这个项目的定位非常明确用STM32F103C8T6的GPIO读取红外避障模块的数字输出信号判断前方是否有障碍物然后把结果实时刷新在OLED屏幕上同时通过串口打印详细的状态信息。整套流程覆盖了“传感器采集 - MCU处理 - 人机交互显示 - 调试输出”这个完整的嵌入式开发闭环非常适合作为入门后的第一个组合型小项目。1.2 硬件选型背后的考量先说红外避障模块。市面上最常见的型号是带LM393比较器的那种三线接口VCC、GND、OUT板上有一个电位器可以调节检测距离。它输出的信号是数字电平有障碍物时输出低电平无障碍物时输出高电平不需要ADC采样接一个GPIO就能读。选择这种模块而不是直接用红外对管自己搭电路是因为我踩过一次自己搭电路的坑红外接收管的输出信号受环境光影响极大白天和晚上读取到的数值完全不同没有比较器整形的话程序里就得来回调阈值。独立模块把放大、比较、整形都做完了省掉一个很大的麻烦。再说OLED。0.96寸、128x64分辨率、I2C接口的SSD1306屏幕是玩单片机绕不开的经典外设。它只需要接SCL、SDA两根信号线加电源就能工作配合HAL库的I2C外设驱动起来非常干净。最重要的是OLED本身就是一个极好的调试工具比串口直观得多——程序跑没跑到某段代码全局变量的值有没有变化都能直接显示在屏幕上。芯片选STM32F103C8T6没有悬念。这颗芯片虽然叫“C8T6”但实际Flash是64KBRAM是20KB频率能跑到72MHz对红外避障这种传感器任务来说绰绰有余。而且它兼容5V和3.3V的模块电平红外模块和OLED都用3.3V供电就能跑整个系统不需要电平转换芯片接线非常省事。1.3 系统的完整数据链路在动手写代码之前我先在纸上把整个系统的数据流画了一遍。从传感器到显示输出链路非常清晰GPIO读取红外模块输出 - 软件消抖滤波 - 状态判定有/无障碍 - OLED屏幕刷新显示 串口打印调试信息这个链路里最容易被忽视的是中间那步“软件消抖滤波”。红外模块输出的是数字电平但它的电平切换并不是理想的瞬跳在检测阈值临界点附近会有反复跳动直接拿原始信号做逻辑判断会导致OLED显示内容疯狂闪烁根本没法看。这也是我后来花了最多时间调试的地方后面专门用一整章来讲。2. 硬件接线与模块原理详解2.1 红外避障模块的工作原理这个模块的核心是红外发射管和红外接收管。发射管持续发出特定频率通常是38kHz附近的红外光红外光碰到障碍物后反射回来被接收管接收。接收管把光信号转成电信号送到LM393比较器的一个输入端另一个输入端接着电位器分压出来的参考电压。当反射光强度足够大也就是障碍物足够近时比较器输出翻转模块的数字输出脚就输出对应的电平。模块上的电位器非常关键。顺时针拧到底参考电压升高模块需要更强的反射光才能触发翻转也就是检测距离变近逆时针拧到底参考电压降低检测距离变远。但这个调节范围不是无限大的我实测下来大概在3cm到30cm之间超过30cm基本就不稳定了。这里有一个特别重要的实操经验不同的障碍物表面反射率差别极大白色纸板能轻松触发黑色绒布几乎完全不反射。如果你发现模块明明对着障碍物却没有任何反应先拿一张白纸试一试大概率是物体表面太吸光了。另一个容易被忽略的点是模块的输出逻辑。有障碍物时OUT引脚输出的是低电平无障碍物时是高电平。方向反了很常见写代码之前一定要先用万用表实测一下避免在主循环里把判断条件写反。2.2 OLED显示模块的关键细节0.96寸OLED的内部驱动芯片是SSD1306自带128x64的显存也就是说你把数据写进它的DDRAM屏幕上就会对应显示出来不需要主控反复刷新。I2C接口上它分两个主要步骤先发控制字节再发数据字节。控制字节的0x80表示后面跟的是命令0x40表示后面跟的是数据。这个细节是OLED驱动里最常见的坑忘了区分命令和数据的后果就是屏幕乱码或者完全不亮。屏幕的I2C地址默认是0x787位地址0x3C左移一位。大多数卖家发的模块都是这个地址但也有少数是0x7A。地址不对的时候I2C通信完全没有ACK响应我的经验是先用扫描程序探测一下地址不要凭默认值死磕。OLED屏幕能够显示中文、英文、数字和简单的图形。字符显示的核心是取模也就是把每个字形拆成像素点在x和y方向上的亮灭排列。我用的字库是网上常见的“宋体16x16”和“ASCII 8x16”对应中文和英文两种尺寸取模软件选“纵向取模、高位在前”的格式数据直接用const数组存在Flash里不占宝贵的RAM。2.3 完整接线表与引脚规划这个项目的接线非常简单总共用到7根线。我实际焊接好之后量了三次确定无误才上电。红外避障模块STM32F103C8T6说明VCC3.3V模块供电GNDGND共地必须接OUTPA6GPIO输入模式读取检测结果OLED模块STM32F103C8T6说明VCC3.3V屏幕供电GNDGND共地SCLPB6I2C1时钟线SDAPB7I2C1数据线串口调试STM32F103C8T6说明TXPA9USART1发送RXPA10USART1接收本次未用选PA6做红外输入是因为它默认就是浮空输入模式内部不带上下拉外部模块的电平可以直接驱动。PA9和PA10正好是USART1的默认引脚复用功能开启即用。整个接线图里最重要的就是共地红外模块和OLED各有一条GND要汇总到STM32的GND不共地的话信号会完全乱掉屏幕上会出现各种莫名其妙的跳动。3. 软件初始化与核心驱动实现3.1 开发环境与工程模板选择我用了STM32CubeMX生成HAL库工程配合Keil MDK写代码。CubeMX 6.x版本对F1系列的支持很成熟选芯片型号STM32F103C8Tx就能看到引脚排列图鼠标点几下就能把时钟和引脚配好。很多人纠结用标准外设库还是HAL库我的建议是直接学HAL。虽然HAL库封装层级多、看着没有寄存器操作那么“硬核”但它把I2C这类外设的细节全部处理好了代码迁移到别的STM32型号时基本不用改。对于红外避障这种小型项目HAL库引入的性能开销根本感知不到。CubeMX里面需要配置的部分包括RCC高速时钟使用外部晶振HSESYS调试接口选Serial WireGPIO里把PA6设为输入模式并命名为IR_SENSORI2C1选标准模式100kHz速度USART1设为异步模式波特率115200。时钟树保持默认的72MHz主频即可这个项目对时钟精度没有苛刻要求。3.2 OLED驱动实现要点OLED驱动我直接用了常见的SSD1306驱动代码核心逻辑是把命令和数据的发送分离成两个函数。发送命令的函数接收一个字节调用I2C写寄存器先写0x00表示后续是命令再写命令本身发送数据的函数先写0x40表示后续是数据。初始化序列里有几个命令值得留意0xAE关闭显示、0x8D打开内部电荷泵、0xAF开启显示顺序不能乱其中电荷泵如果不开屏幕就是一块全暗的玻璃。显示一个字符的过程是计算字符在屏幕上的起始坐标然后按行把字模数组里的每一字节写到对应地址。SSD1306的DDRAM地址自动递增所以写一整行字符时可以连续发送数据而不必反复发送地址命令。整个刷新策略我用的是局部刷新——状态栏上的信息有变化时才去更新相应区域而不是每帧全屏重写。全屏刷新128x648192个字节每个字节两次I2C操作虽然是100kHz的慢速I2C也要几毫秒全屏重刷会明显拖慢主循环节奏。局部刷新只在检测结果变化时触发一次这个体验上的差别很明显实测下来屏幕闪烁几乎不可感知。3.3 OLED显示函数的三层结构我习惯把显示功能分成三层最底层是画点函数控制单个像素的亮灭中间层是画字符函数把一个字符从字模库取出并放到指定坐标最上层是界面函数组织好哪几行显示什么内容。这次项目里我只写了两个界面一个显示“Sensor: OK/OBSTACLE”的英文状态行另一个显示计数器记录障碍物触发次数。中间层有个容易被忽略的麻烦是字符串长度计算OLED是一列一列刷新的字符串太长会超出屏幕边界自动换行到下一行导致显示错位所以主程序里字符串缓冲区大小一定要预留足够空间字符串末尾的‘\0’别漏了。3.4 红外信号的初始读取与主循环框架主程序的框架非常简单。初始化完OLED、USART和GPIO之后进入一个while死循环在循环里读取PA6的电平、做滤波、更新显示状态。用HAL库读取GPIO是HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_6)返回GPIO_PIN_SET或GPIO_PIN_RESET两个宏。结合红外模块的输出极性我做了如下映射#define OBSTACLE_DETECTED GPIO_PIN_RESET // 低电平表示有障碍物 #define NO_OBSTACLE GPIO_PIN_SET // 高电平表示无障碍物 uint8_t sensor_raw HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_6); if (sensor_raw OBSTACLE_DETECTED) { // 有障碍物进入滤波流程 } else { // 无障碍物 }这里有一个非常重要的经验第一版代码千万不要加滤波直接读直接显示。先把最原始的实时状态跑通确认硬件连接没问题、OLED显示正常、串口有输出再逐步引入滤波。如果一上来就想着完美方案传感器抖动和显示之间到底是谁出了问题都分不清。这个“先显性、后优化”的思路在嵌入式调试里是通用的我自己吃过亏才明白。4. 软件消抖与滤波方案的实战对比4.1 为什么原始信号不能直接用上一章我说过红外模块输出的数字电平在临界点附近并不稳定。拿我手上的模块来说障碍物慢慢靠近时输出信号不是一路平坦地从高电平跳到低电平而是高-低-高-低地来回抖动好几下才最终稳定。这个现象有两个来源一是红外接收管自身的持续波动反射光在物体表面会产生漫反射和干涉光强本身就不稳定二是电源纹波叠加到LM393比较器的参考电压上导致比较器输出在阈值附近来回翻转。这种抖动在OLED上的直接表现就是障碍状态疯狂闪烁看起来像是程序中了什么邪。如果这个信号接入的是中断引脚还会触发连续多次中断后续要做防撞逻辑的话小车会神经质地来回抽动。软件滤波是必须做的。4.2 三种滤波方案的对比我实际尝试了三种方案各有适合的场景我把它们的优缺点列出来供大家参考。方案原理优点缺点适用场景延时消抖检测到状态变化后延时10-20ms再读一次二次确认代码最简单只需一行延时阻塞主循环系统实时性下降单传感器、逻辑简单的小项目计数滤波连续读取N次多数状态胜出不阻塞响应延迟可控制占用少量CPU需要缓冲区机械开关、传感器消抖移动平均用一个环形缓冲区记录最近N次采样值取平均值平滑效果好状态跳变平滑过渡内存占用略高代码量稍大模拟量输入、需要平滑曲线的场合对于数字信号的红外避障模块我最推荐的是计数滤波理由是从原理上它最契合“信号在两种确定电平之间跳变”这个特征不需要像移动平均那样计算数值只需要数0和1的个数。4.3 计数滤波的具体实现我用的计数滤波逻辑是这样设计的每一个主循环周期读取一次传感器原始值把最近8次采样存进一个无符号8位变量每次读入新值时整体左移一位并或上新值然后检测这个8位变量是否等于0x00或者0xFF。等于0x00说明连续8次都是低电平、确认有障碍物等于0xFF说明连续8次都是高电平、确认无障碍物。只有确认结果和当前显示状态不一致时才更新显示状态。uint8_t filter_shift_reg 0x00; // 8位移位寄存器 uint8_t current_state NO_OBSTACLE; // 当前确认的状态 while (1) { uint8_t raw HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_6); filter_shift_reg (filter_shift_reg 1) | ((raw OBSTACLE_DETECTED) ? 1 : 0); uint8_t confirmed; if (filter_shift_reg 0x00) { confirmed OBSTACLE_DETECTED; // 连续8次低电平 } else if (filter_shift_reg 0xFF) { confirmed NO_OBSTACLE; // 连续8次高电平 } else { confirmed current_state; // 不确定就保持原状 } if (confirmed ! current_state) { current_state confirmed; // 更新OLED显示 // 串口打印状态变化 } }关键是“不确定就保持原状”这一句它让系统在传感器信号频繁抖动时不会跟着来回变只有当连续8次采样都一边倒时才认账。8次采样的延迟到底多大取决于主循环的执行周期。我在主循环里做一轮读取和显示大概花1ms左右所以从传感器物理触发到软件确认状态最坏情况下等待约8ms人眼和一般控制逻辑完全感受不到。4.4 移动平均的思路供参考如果你做的是模拟量的避障传感器比如输出距离值的红外测距模块那计数滤波就不适用了得用移动平均。核心思路是维护一个N元素的环形缓冲区每来一个新采样值就把最旧的值替换掉然后计算当前缓冲区的平均值用平均值做后续判断。N越大平滑效果越明显但响应越迟钝。对于模拟红外测距我一般取N5或者N7既能把随机噪声削掉大部分又不至于障碍物已经飞走了距离值还停在原地。关于滤波参数的选择我的建议是不要上来就追求“完美”先用比较短的滤波窗口跑起来观察现象不够顺滑再把窗口调大。滤波窗口越大系统的惯性越强反应就越钝。具体多少合适得根据你主循环的周期来定总的原则是滤波延迟不要超过50ms超过这个数值感知上就会觉得卡顿。5. 串口调试与现象排查技巧5.1 串口打印的关键作用OLED能把最终结果显示出来但如果状态判断逻辑出错了OLED上只能看到一个错误的最终答案看不到这个错误是怎么一步步形成的。这时候串口就派上用场了。我把原始值、滤波后的确认值、当前状态三个信息一起通过USART1打印出来格式是[raw0] [filter0x00] [stateOBSTACLE]这样的原始字符串用串口调试助手以115200波特率接收能够非常清楚地看到传感器在阈值边界处的抖动过程。在使用串口调试助手查看数据时有一点需要特别注意串口输出和分析不能影响实时逻辑。我一开始在滤波之前的每个主循环周期都调用printf打印结果发现打印本身占了太多时间主循环周期从1ms被拖到了几十毫秒滤波的响应速度大打折扣。后来我改成只在状态确认变化时才打印一次既保留了关键信息又不干扰实时流程。5.2 打印函数的重定向方法HAL库环境里用printf需要重定向fputc函数。在Keil MDK中需要勾选“Use MicroLIB”然后在工程里加入下面这段代码#include stdio.h int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 10); return ch; }MicroLIB是ARM提供的精简C库占用资源少重定向写法比标准库简单。不勾选MicroLIB的话标准库的printf会引入大量文件系统相关的代码Flash空间不够时会链接报错即使链接过了串口也可能只输出一个字符就死机这个坑很常见。5.3 串口调试助手里看到的真实波形我在实际测试时把障碍物慢慢靠近再慢慢远离串口输出会呈现这样的规律障碍物距离很远时每个主循环周期读到的raw都是1state一直是NO_OBSTACLE随着障碍物慢慢靠近raw开始出现0和1交错的现象filter寄存器的值在0x55、0xAA、0x0F这些值之间跳变但还没有稳定到0x00所以state保持不变障碍物进入有效探测距离后连续8个以上周期都读到0filter稳定成0x00state才翻转为OBSTACLE。这个观察过程很关键它证明了滤波不是凭空想象出来的需求而是真实存在的信号干扰。5.4 OLED显示异常排查清单OLED不亮是初学者最常见的拦路虎。按照排查优先级排序我遇到的OLED问题主要有四类供电异常、I2C地址不匹配、初始化时序不对、缺少上拉电阻。供电方面要量一下模块VCC和GND之间是不是真的有3.3VI2C地址方面拿一个扫描程序把所有地址都打印一遍看设备到底应答在哪一个地址初始化时序方面重点检查电荷泵命令有没有发送成功上拉电阻方面如果OLED模块板上没有自带4.7k上拉电阻就要自己在SCL和SDA上各接一个到3.3V否则I2C线上的高电平可能不够通信会不稳定。还有一个常见现象是屏幕亮了但显示乱码。这个问题的根源多半是显示数据发送时命令字节和数据字节的顺序搞混了。SSD1306要求先发控制字节区分后面跟的是命令流还是数据流一旦把数据当命令发或者反过来屏幕内容就会变成雪花或随机方块。5.5 红外模块的误判与调参技巧调试红外避障模块时最让人抓狂的是误判明明没有障碍物系统却报了“有障碍物”。我这里踩过的一个典型坑是模块放在桌面上时桌面的浅色表面反射红外光足够强模块当作“障碍物”触发了。解决办法很简单安装模块时注意调整角度让它不要直对着桌面同时把电位器稍微顺时针拧一点把检测距离调近些。模块的抗环境光干扰能力也有限阳光直射、白炽灯或荧光灯都会让接收信号带上噪声。如果现场环境有很强的红外干扰可以考虑加装一个遮光罩、用热缩管套住模块周围只留正面发射和接收的小窗这个方法在实际测试中效果明显。5.6 状态变化边沿检测的小技巧在调试避障逻辑时我经常需要知道障碍物是“刚出现”还是“正在持续存在”。这就需要边沿检测只在从无到有、或从有到无的那个瞬间执行一次动作而不是在持续状态里反复触发。实现方法是用一个prev_state变量记录上一次的确认状态每次循环比较当前current_state与prev_state如果不同就说明产生了边沿跳变static uint8_t prev_state NO_OBSTACLE; if (current_state ! prev_state) { if (current_state OBSTACLE_DETECTED) { obstacle_count; // 新障碍物出现 printf(Obstacle appears! count%d\r\n, obstacle_count); } else { printf(Obstacle cleared.\r\n); } prev_state current_state; }我在OLED屏幕上增加的“触发次数”显示就是这个边沿检测的产物功能简单但调试起来非常直观能快速验证滤波后的状态切换是否符合预期。6. 项目扩展与后续改造方向6.1 从检测到控制的升级路径红外避障模块在实际项目里很少是独立存在的它更多是作为“感知前端”接入更大的控制系统。常见升级方向是驱动小车把PA6的检测结果接到电机驱动的逻辑里检测到障碍物时控制电机反转或者转向。这个方向需要增加L298N或TB6612电机驱动模块软件上把确认状态传给电机控制函数记住一点——电机启停瞬间的电流波动可能会拉低电源电压进而影响红外模块的稳定性所以建议红外模块和电机驱动分别供电或者至少加大电源滤波电容。6.2 多路传感器与冲突仲裁单片红外模块只能判断一个方向如果想让小车实现完整的避障行为至少要装3个模块左、中、右各一个。多路传感器带来一个典型的工程问题——多路信号的冲突仲裁左边说没障碍、右边说有障碍到底听谁的我的做法是给每个方向设定优先级正前方的优先级最高因为正前方碰撞风险最大左右两边出现冲突时按照当前的转向状态来决定优先响应的方向。这个逻辑听起来简单但一旦传感器数量超过两路状态组合就会爆炸建议用状态机或者查表的方式管理。6.3 状态机给代码带来的层次感如果你觉得这个项目纯粹靠几个if-else拼起来不够优雅那可以从一开始就引入状态机思想。避障逻辑可以拆成“空闲检测”、“障碍物接近”、“避开动作”、“恢复空闲”四个状态每个状态只响应特定事件状态之间的迁移条件对应滤波后的确认结果。状态机的优势是代码结构清晰每一步逻辑都像一张状态转移表后期加功能不容易把代码改成一团乱麻。6.4 我的实际体会与几条有用的小经验做了一轮完整的硬件接线、原理分析、软件滤波和调试我总结了几条值得留存的个人经验。第一模块接线宁可多花三分钟用万用表量一遍再上电也不要烧坏一块最小系统板。OLED模块和红外模块的VCC接反或者引脚错位是初学者最容易犯的错误。第二调试信息越详细越好但打印要克制。我在调试阶段把原始电平、滤波寄存器的值、确认状态、计数全部打出来等确认一切正常后把除关键状态切换之外的打印全删掉或改成条件编译避免干扰实时逻辑。第三滤波不是越强越好它和响应速度是一对天生的矛盾。8次连续采样确认的方案在红外避障场景下够用但如果你做的是碰撞检测或者急停控制这个延迟可能就太大了需要动态调整采样次数或者改用更激进的判定策略。第四电位器的调节是一项手动修为。把检测距离调到刚好覆盖你想要的范围比每次都靠悬浮判断远近距离靠谱得多。调节时拿一张白纸反复靠近远离边调边观察指示灯调好之后用热熔胶固定电位器防止运行振动导致它漂移。第五这个项目做完之后不要急着拆它是个极佳的调试平台。后续学定时器、中断、PWM都能在这个平台上直接加外设来试验比从零搭一个新工程省事得多。这套STM32F103C8T6 红外避障模块 OLED的组合麻雀虽小但五脏俱全从GPIO采集到外设驱动、从滤波算法到串口调试、从异常排查到功能扩展把嵌入式开发的常见环节基本上都过了一遍。如果你正在找一个能串起“传感器-处理-显示-调试”整条线的入门项目按这个思路走一遍收获会比单纯点个灯、跑个流水线大得多。