STM32八合一智能小车实战：硬件选型与代码调试全解析

简介：本资源是一套完整的STM32智能小车多功能开发套件，面向嵌入式初学者、课程设计学生及电子竞赛备赛者，解决多模态智能控制功能集成难、代码移植性差、硬件选型无依据等实际问题。压缩包含2000个文件，主体为889个.h头文件与325个.c源文件（HAL库驱动与应用逻辑），辅以.ioc配置文件、.uvprojx工程文件、.hex烧录镜像及大量编译中间文件（.o/.axf/.map等），完整覆盖CubeMX图形化配置到固件部署全流程，总大小75.35MB。已有2775人学习下载，说明其在实践教学与项目复现中具备广泛参考价值。用户可直接编译运行全部八大功能——循迹、跟随、避障、测速、蓝牙遥控、WiFi远程控制、4G联网通信及语音识别响应，并基于详尽中文注释快速理解模块间交互逻辑；所有代码兼容标准库移植，配套硬件清单明确器件型号与连接关系，显著降低二次开发门槛。 网上关于STM32智能小车的帖子很多，但多数只讲单功能——要么循迹，要么蓝牙遥控，碰到“全功能整合”的需求，反而找不到一份完整的参考。我这次把循迹、跟随、避障、测速、蓝牙、WiFi、4G、语音识别全部放到一台F103小车上了，前后折腾了三个多月，代码从几百行膨胀到三千多行。这篇总结把硬件选型、系统架构、各部分代码逻辑、调试经验全部梳理出来，适合已经会点STM32基础、想做一个完整项目的人，也适合备赛或者做毕设的同学参考。

需要说明的是，下面所有源代码不是噱头，是能直接编译运行的工程级代码片段。单片机型号是STM32F103ZET6，标准库+HAL库混着用，但思路完全可以移植到C8T6、F407甚至GD32上。硬件清单部分我会把每个模块选型的理由和踩过的坑也一并写出来，毕竟很多问题不是代码问题，是选型问题。

1. 整车硬件选型清单与采购避坑

1.1 主控与底盘的核心搭配

主控我选了STM32F103ZET6，不是最小系统板，是带底板的那种开发板。为什么不选C8T6？纯粹是因为这个项目后期要挂的模块太多，C8T6的引脚和Flash都紧巴巴的。ZET6有144个引脚、512KB Flash、64KB RAM，做这种多功能小车不会出现引脚不够用还得天天改映射的尴尬局面。如果预算有限或者只做单一功能，C8T6也够，但八功能合并的话，我还是建议直接上ZET6。

底盘用的是四驱亚克力底盘，就是网上最常见的那个蓝色透明板子，配四个TT马达。四驱的好处不只是力气大，重点在于后期如果加摄像头、机械臂这些负载，动力余量足。TT马达不带编码器，所以我额外买了带霍尔测速功能的马达减速箱版本，后面测速功能靠它实现，不用自己改装，省了很多事。

驱动板选的是TB6612FNG，不是L298N。这一条要重点说：L298N的压降太大了，两节18650满电8.4V进去，到电机端可能只有6V多，而且L298N自身发热严重，跑十分钟板子烫手。TB6612的MOS管压降只有零点几伏，同样电池供电到电机端的电压几乎不损失，发热少了非常多。驱动能力方面，TT马达的工作电流在200mA左右，堵转电流也就1A上下，TB6612单路最大1.2A，完全够用。

1.2 传感器件选型细节

循迹我用了五路灰度传感器，不是两路也不是三路。五路的好处是过十字路口的时候能判断车辆姿态，两路的话到了十字路口直接就懵了，不知道自己到底在横线还是竖线。我买的模块是TTL电平输出，白线输出低电平，黑地输出高电平，后面代码里也按这个逻辑写。如果买到的模块极性和我相反，代码里取反就行。

避障模块用的是两个红外避障传感器，装在车头左右两侧，探测距离在2~30cm可调。为什么不直接用超声波避障？超声波扫盲区大、速度慢，近距避障反应不过来。红外模块的响应时间是毫秒级的，左右各装一个，小车侧前方有障碍能立刻感知，配合减速逻辑就能很顺滑地绕开。超声波留给跟随用，各司其职。

超声波选的是HC-SR04，装在舵机云台上。舵机是SG90，9g那种小舵机，力气对于这种小体积的超声波模块来说足够了。云台要自己用亚克力片或者3D打印件搭一个，我用的是3D打印的，20克左右，装在车头正前方。

测速模块是霍尔传感器，型号LM393，磁铁装在TT马达的轮轴上，每转一圈输出一个脉冲，轮子每转一圈的脉冲数跟电机减速比有关，我用的1:48减速电机，霍尔盘每圈输出约13个脉冲（这个数值一定要根据自己买的电机型号实测校准，不能直接抄别人的）。

1.3 通信模块选型：蓝牙、WiFi、4G怎么定

蓝牙模块选了HC05，经典蓝牙，不是HC06也不是BLE。HC06只能做从机，不能发AT指令配置，而HC05既能做主机也能做从机，能通过AT指令改名称、改波特率、改配对密码，后期如果要当一个“遥控主站”去控制别的蓝牙设备，还能切主机模式。手机APP控制方面，经典蓝牙的SPP协议支持面很广，网上大多数蓝牙调试APP都支持HC05，不用自己写APP。

WiFi模块选了ESP8266，型号ESP-01S，刷的是官方AT固件。为什么不用ESP32？主控已经是STM32了，ESP8266在这里只干一件事：透传数据。它把STM32串口发过来的数据通过WiFi转发到局域网里的PC或者手机调试工具上，不需要额外的算力和IO口，AT指令就能搞定，这是最轻量可靠的做法。如果后面想做局域网视频图传，那再单独挂摄像头模块，不在这次讨论范围内。

4G模块用的是SIM7600CE，全网通，支持TCP/IP透传和MQTT协议。这个模块有点贵，而且需要SIM卡和流量，做演示的时候其实很少用到，但它解决了两个蓝牙和WiFi解决不了的需求：一是小车完全脱离局域网，只要有4G信号就能被远程控制；二是可以走MQTT把数据推到云平台，实现真正的物联网闭环。如果只是课堂作业或者实验室演示，WiFi就够了，4G是往产品化方向走的加分项。

语音识别模块用的是SU-03T离线语音识别模块，天问的，不用联网、不用训练平台账号，直接对接串口就能用。为什么不用LD3320？LD3320的识别率在安静环境下还可以，但稍微有点噪声就容易误判，而且它的命令词设置是通过官方的上位机软件写入的，要注册账号、要下IDE，流程繁琐。SU-03T有自己的配置工具，把唤醒词、命令词、串口输出的返回值配置好，烧录进去就能用，识别速度也在百毫秒级，更适合这种嵌入式小车场景。

1.4 电源系统的设计与容量估算

很多新手在这里翻车。我见过有人用USB供电给小车跑，结果一启动电机就复位，这就是典型的供电不足。这台车的用电设备分三类：电机、舵机、逻辑电路。

• 电机四个，正常工作电流总计约800mA，堵转峰值可能到4A
• 舵机SG90，堵转电流约700mA，正常转动时几十毫安
• 主控板、传感器、蓝牙、WiFi、语音模块，逻辑部分合计约300mA

电池我用了两节18650串联，标称电压7.4V，容量2600mAh。电机驱动直接接电池正极，逻辑电路通过降压模块降到5V和3.3V。不要用一节18650直接给逻辑部分供电，因为电机启动瞬间电压会被拉低到4V以下，单节18650充满4.2V，被拉到3V多时，STM32的3.3V稳压芯片输出就不稳定了，很容易复位。

降压方案：5V用MP1584这种DC-DC模块，效率高、压差大也能带得动，别用7805线性稳压，电池8.4V输入时7805发热严重，功耗全浪费在发热上了。3.3V从5V再经过一片AMS1117-3.3就可以，因为逻辑部分电流不大，线性稳压的损耗可以接受。

容量续航也可以估算一下：平均电流大约1.2A，2600mAh的18650实际可用容量大约2000mAh（保护板会限制放电到2.5V每节），理论续航约1.6小时，实际跑起来走走停停、电机频繁启停，大概能支撑1小时左右。这个数字对比赛和演示来说足够了。

2. 系统架构与电气连接：从一堆模块到一台能跑的车

2.1 整车供电拓扑与电平匹配

整车的供电拓扑是这样的：两节18650串联成7.4V电池组，经过一个总开关后，分成三路。第一路直接进TB6612的VM电源脚，给电机供电；第二路进MP1584降压成5V，给舵机、传感器模块、语音模块、蓝牙模块供电；第三路从5V再经AMS1117降到3.3V，供STM32主控板的逻辑部分和ESP8266。

供电拓扑确定了，接下来是电平匹配问题。STM32的IO是3.3V电平，但很多模块是5V电平，比如五路灰度传感器和HC-SR04，它们的信号输出高电平是5V。如果直接把5V引脚接到STM32的3.3V引脚上，长期运行有烧引脚的风险。虽然F103的数据手册说引脚耐压是5V容忍（FT引脚），但不是所有引脚都支持5V容忍，所以我在这几个模块的信号线上串了1kΩ电阻做限流，一来保护引脚，二来不影响数字信号读取。这个做法在工程中很常见，比用电平转换芯片要省事，实测也没有出现信号识别问题。

2.2 引脚分配表与定时器资源规划

引脚分配是整个项目里最需要提前规划的事，因为F103的多路外设共用引脚，比如USART1的TX/RX在PA9/PA10，同时也复用为TIM1的通道。如果等到接线的时候再临时改，往往只能改程序重映射，麻烦得很。我最终确定的引脚分配表如下：

功能模块	信号	STM32引脚	备注
TB6612	PWMA/PWMB	PA8/PA11	TIM1通道1/通道2，PWM输出
TB6612	AIN1/AIN2/BIN1/BIN2	PB12/PB13/PB14/PB15	方向控制，通用GPIO
TB6612	STBY	PB11	高电平使能
五路循迹	DO1~DO5	PC0~PC4	普通输入，带上拉
红外避障	OUT_L/OUT_R	PC5/PC6	普通输入
HC-SR04	Trig/Echo	PA6/PA7	Echo用TIM3的输入捕获
SG90舵机	PWM信号	PA1	TIM2通道2
霍尔测速	S1/S2	PB6/PB7	TIM4通道1/通道2编码器模式
HC05蓝牙	TXD/RXD	PA10/PA9	USART1
ESP8266	TXD/RXD	PA3/PA2	USART2
SIM7600	TXD/RXD	PB11/PB10	USART3
SU-03T	TXD/RXD	PC11/PC10	UART4
OLED	SCL/SDA	PB8/PB9	I2C1，用于显示状态

这里有个容易踩的坑：PC13、PC14、PC15这三个引脚在ZET6上是RTC和TAMPER引脚，做普通IO用的时候会有额外的限制（比如不能做ADC输入），但做普通数字输出和输入是没问题的，只是要避开它们做高速PWM或定时器输入。我这版没用到这几个引脚，但如果你拿的是最小系统板，要特别注意这个限制。

2.3 为什么每个传感器都要“共地”

接线时最容易忽略但最致命的一个问题：共地。所有模块的GND必须和STM32的GND连在一起，否则信号线上的参考电平不一致，读到的数据会乱跳。尤其当你外接一个DC-DC模块给传感器供电、又用另一路电源给主控供电的时候，如果不共地，模块的输出高电平是相对于模块自己电源的，单片机读这个电平就完全对不上了。

我的做法是在底板上飞了一根粗的GND母线，所有模块的GND就近接到这根母线上，主控板的GND也接上去。注意不要把所有GND都堆到主控板上的一个GND引脚上，那样电流集中，容易在GND线上产生压差，导致各个模块之间的地电位不一致。

3. 八大功能的工程实现与核心代码逻辑

3.1 循迹功能：五路灰度传感器的阈值校准与PID转向

循迹的原理很简单：灰度传感器通过红外发射管照射地面，接收管根据反射光强判断当前颜色。白线反光强、黑地反光弱，模块输出数字电平。但不同环境的光照、不同地面的反光度差别很大，所以必须先做阈值校准，不能直接拿固定的比较电平去判断。

我这里的五路模块输出的是开关量，直接读GPIO就能得到每一位的0/1状态。循迹的核心不只是“检测到白线就转向”，而是要把五路传感器的状态读出来，转换成小车的转向偏差量，再用PID去控制转向打角和速度差。典型的状态处理逻辑如下：

uint8_t line_sensor[5]; int8_t get_line_offset(void) { // 假设白线输出0，黑地输出1 // 五路传感器位置：左、中左、中、中右、右 // 用加权算法计算偏差，中心为0，最左为-4，最右为+4 static const int8_t weights[5] = {-4, -2, 0, 2, 4}; int8_t offset = 0; uint8_t count = 0; for (int i = 0; i < 5; i++) { if (line_sensor[i] == 0) { // 检测到白线 offset += weights[i]; count++; } } if (count == 0) return 99; // 丢失线，返回异常值 return offset / count; }

控制部分就是一个位置式PID，输出量是左右轮的PWM占空比差值：

int16_t pid_line_control(int8_t target_offset) { static int16_t integral = 0; static int8_t last_error = 0; int8_t error = target_offset; integral += error; if (integral > 200) integral = 200; if (integral < -200) integral = -200; int16_t output = KP_LINE * error + KI_LINE * integral + KD_LINE * (error - last_error); last_error = error; return output; }

调试循迹时有个经验：P值先从小往大调，调到小车开始左右轻微震荡，然后加一点D值抑制震荡，最后加一点I值消除过弯时的稳态误差。如果直线段跑得稳、弯道出线，通常是P不够大或者速度太快，不要急着加D，先把基础速度降下来。

3.2 避障功能：红外传感器检测与分级减速策略

两个红外避障模块我装在车头两侧，朝斜前方探测。模块上有一个电位器可以调距离阈值，我调到大约15cm左右，也就是前方15cm内有障碍物时模块输出低电平（不同模块极性不同，要实测确认）。

避障的逻辑不能简单做成“检测到障碍就急转弯”，那样小车会一顿一顿的。我用了分级策略：先减速，再判断障碍在哪一侧，然后转向避让。

uint8_t obstacle_left, obstacle_right; void obstacle_avoid(void) { obstacle_left = GPIO_ReadInputDataBit(GPIOC, GPIO_Pin_5); obstacle_right = GPIO_ReadInputDataBit(GPIOC, GPIO_Pin_6); if (obstacle_left == 0 && obstacle_right == 0) { // 两侧都有障碍，倒车右转 set_motor_speed(-BASE_SPEED, BASE_SPEED); } else if (obstacle_left == 0) { // 左侧障碍，减速右转 set_motor_speed(BASE_SPEED * 0.4, BASE_SPEED * 0.8); } else if (obstacle_right == 0) { // 右侧障碍，减速左转 set_motor_speed(BASE_SPEED * 0.8, BASE_SPEED * 0.4); } else { // 无障碍，恢复前进 set_motor_speed(BASE_SPEED, BASE_SPEED); } }

避障的最佳状态不是每次都急打方向，而是让小车在接近障碍时就有一个柔和的转向趋势。所以我把红外传感器的安装方向稍微朝外偏了15度左右，这样小车还没正面撞上障碍就已经感知到侧前方的障碍物，提前减速，实际跑起来轨迹非常顺滑。这个安装角度的细节，比调代码更影响体验。

3.3 超声波跟随功能：舵机云台扫描与动态PID调速

跟随功能用超声波测距，舵机云台负责扫描。核心代码分两段，第一段是舵机云台扫描，第二段是根据距离和方位控制小车运动。

超声波测距的代码是HC-SR04的标准时序：拉高Trig引脚10微秒以上，然后等待Echo引脚返回高电平，高电平持续时间乘以声速340m/s再除以2就是距离。

float ultrasonic_get_distance(void) { float distance; uint32_t time_us; GPIO_SetBits(GPIOA, GPIO_Pin_6); // Trig拉高 delay_us(15); GPIO_ResetBits(GPIOA, GPIO_Pin_6); // Trig拉低 // Echo用定时器输入捕获测量高电平时间 time_us = ic_get_echo_time(); // 返回微秒数 distance = time_us * 0.034 / 2.0; // 单位cm return distance; }

跟随的控制策略很多人想复杂了。最简单可靠的方案是：舵机云台先扫描180度，找到最近的一个目标，记录下目标在左中右哪个方位，然后控制小车转向；同时根据距离控制前后速度：

• 距离大于40cm：加速前进
• 距离在15cm到40cm之间：保持当前速度
• 距离小于15cm：减速或停止

如果希望小车跟得更稳，可以加一个简单的比例控制：速度 = K * (目标距离 - 当前距离)，目标距离设为25cm左右。K值根据实际情况调，我用的是K=2，也就是距离差10cm时，速度差为20%PWM占空比。

跟随模式有个坑：空旷环境下超声波可能扫到远处墙壁，导致小车误判目标。我的解决办法是限制有效测距范围，只认20cm到150cm之间的目标，超过这个范围跳过。这个简单的范围限制让系统的误触发率大幅下降。

3.4 测速功能：M法测速实现与里程计算

霍尔测速模块的输出接到STM32的定时器编码器模式引脚上，用定时器自带的编码器接口进行脉冲计数，不需要额外占用CPU中断，精度也很高。

M法测速的原理是：在固定的时间窗口内统计脉冲数，然后用脉冲数除以每圈脉冲数得到圈数，再乘以轮子周长得到这段时间走过的距离，除以时间就是速度。这种方式在高转速下精度很高，低转速下由于脉冲个数少，分辨率不够。但TT马达的转速在100~300rpm之间，每圈13个脉冲，10ms的测量窗口也有13个脉冲以上，完全够用。

#define PULSES_PER_REV 13 #define WHEEL_DIAMETER 6.5f // 单位cm float get_speed_cm_s(void) { uint16_t pulse_count; float speed; pulse_count = TIM_GetCounter(TIM4); // 读取计数 TIM_SetCounter(TIM4, 0); // 清零 speed = (float)pulse_count / PULSES_PER_REV * 3.14159f * WHEEL_DIAMETER; // 假设采样周期是100ms，所以速度 = 脉冲数/每圈脉冲数 * 周长 / 0.1s speed = speed / 0.1f; return speed; }

测速数据可以用来做闭环调速，也可以用来记录里程。我在项目里把里程数据实时显示在OLED上，同时通过蓝牙把速度和里程发到手机APP，演示效果很直观。测速模块还有一个额外的用途：当小车检测到轮子被卡住（速度远低于设定值且持续一段时间）时，自动停止电机，这个逻辑在比赛里很实用，能防止电机堵转烧毁驱动板。

3.5 蓝牙控制：HC05串口通信与指令协议设计

蓝牙模块挂在USART1上，波特率9600。很多人蓝牙连不上、收不到数据，一半以上的原因是波特率没对上，HC05默认是9600，但如果你之前用AT指令改过波特率，手机APP也得改成对应的波特率。

蓝牙控制的指令协议，我设计得非常简单：一字节命令+一字节结束符。比如F表示前进，B表示后退，L表示左转，R表示右转，S表示停止，X表示退出遥控模式。这样在手机上用任意一个串口调试APP，按下对应按键就能控制小车，不需要专门写一个复杂的数据帧协议。

串口接收用中断，收到一个字节就存入环形队列，主循环里解析。不要在主循环里用阻塞式接收轮询，否则你按键按下去以后小车要等几十毫秒才有反应，手感极其糟糕。

// 环形队列，串口中断里写入，主循环里读取 volatile uint8_t uart_rx_buf[64]; volatile uint8_t uart_rx_head = 0, uart_rx_tail = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE)) { uint8_t data = USART_ReceiveData(USART1); uart_rx_buf[uart_rx_head] = data; uart_rx_head = (uart_rx_head + 1) % 64; } } void process_bluetooth_cmd(uint8_t cmd) { switch (cmd) { case 'F': set_motor_speed(BASE_SPEED, BASE_SPEED); break; case 'B': set_motor_speed(-BASE_SPEED, -BASE_SPEED); break; case 'L': set_motor_speed(-BASE_SPEED * 0.5, BASE_SPEED); break; case 'R': set_motor_speed(BASE_SPEED, -BASE_SPEED * 0.5); break; case 'S': set_motor_speed(0, 0); break; default: break; } }

蓝牙配对还有个细节：HC05默认配对密码是1234，如果连不上先试这个。另外，HC05的STATE引脚会输出连接状态，接一个LED指示灯，连接成功后灯会变成慢闪，调试时非常直观。

3.6 WiFi与4G透传：AT指令控制与TCP数据通道

ESP8266和SIM7600在架构上可以归为一类，都是“AT指令控制+串口透传”。ESP8266挂在USART2上，SIM7600挂在USART3上，两个模块之间通过串口切换选择，互不干扰。

ESP8266的初始化流程是这样的：

void esp8266_init(void) { uart2_send_string("AT\r\n"); // 测试模块是否在线 delay_ms(200); uart2_send_string("AT+CWMODE=1\r\n"); // 设置为STA模式 delay_ms(200); uart2_send_string("AT+CWJAP=\"SSID\",\"PASSWORD\"\r\n"); // 连接WiFi delay_ms(2000); uart2_send_string("AT+CIPSTART=\"TCP\",\"192.168.1.100\",8080\r\n"); // 建立TCP连接 delay_ms(500); uart2_send_string("AT+CIPMODE=1\r\n"); // 进入透传模式 delay_ms(100); uart2_send_string("AT+CIPSEND\r\n"); }

透传模式下的收发非常爽：ESP8266收到的网络数据会直接通过串口发给STM32，STM32往串口写什么，ESP8266就原样发到TCP服务器上。这意味着蓝牙那套指令协议完全不用改，只需要把指令的收发接口从USART1换成USART2，就实现了从蓝牙遥控到WiFi局域网遥控的平滑切换。

4G模块的流程类似，只是多了SIM卡检测和网络注册的步骤，我用的是AT+CSQ查信号强度，AT+CREG?查网络注册状态，然后AT+NETOPEN打开数据连接，最后也是TCP透传。4G模块启动时间比WiFi长很多，模块上电后要等10秒以上才能AT指令正常响应，程序里必须加一个超时重试机制，否则一上电就发AT指令，模块还没初始化完，直接就卡死在那里。

3.7 语音识别功能：SU-03T离线命令词控制

语音模块SU-03T通过UART4和STM32通信，波特率9600。模块离线识别，不需要联网，识别到预设的命令词后，会通过串口输出配置好的十六进制数据。比如我配置了这样一组命令词：

命令词	串口输出数据	对应动作
“小智小智”	0xAA 0xAA	唤醒，OLED亮屏
“全速前进”	0x01	全速前进
“倒退”	0x02	后退
“左转”	0x03	左转
“右转”	0x04	右转
“刹车停车”	0x05	停车
“启动循迹”	0x10	切换到循迹模式
“启动跟随”	0x11	切换到跟随模式

接收端就是一个简单的状态机，收到0xAA 0xAA就认为是唤醒广播，收到的单字节数据就查表执行对应的动作。

void process_voice_cmd(uint8_t data) { switch (data) { case 0x01: set_motor_speed(MAX_SPEED, MAX_SPEED); break; case 0x02: set_motor_speed(-MAX_SPEED, -MAX_SPEED); break; case 0x03: set_motor_speed(-MAX_SPEED * 0.5, MAX_SPEED); break; case 0x04: set_motor_speed(MAX_SPEED, -MAX_SPEED * 0.5); break; case 0x05: set_motor_speed(0, 0); break; case 0x10: running_mode = MODE_LINE_FOLLOW; break; case 0x11: running_mode = MODE_FOLLOW; break; } }

语音识别的使用要注意一个习惯问题：SU-03T需要先说唤醒词“小智小智”，听到回应后再说命令词，不要上来就直接喊“全速前进”，那样大概率识别不到。这个交互习惯要在演示前就跟观众讲清楚。

4. 多传感器融合时的资源冲突与优先级调度

4.1 定时器资源规划：F103的定时器够不够用

八个功能全部打开的时候，定时器资源非常紧张。我这台小车的定时器占用如下：

• TIM1：两路PWM输出（左轮和右轮速度控制）
• TIM2：一路PWM输出（舵机云台）
• TIM3：一路输入捕获（超声波Echo）
• TIM4：编码器模式（两路霍尔测速）
• TIM6或TIM7：系统心跳，用于控制周期的定时中断

这么算完，F103ZET6的8个定时器几乎全部用上了，C8T6虽然定时器数量相同，但引脚映射和复用资源更紧凑。所以我说如果做全功能，选ZET6的另一个隐形好处就是定时器通道和GPIO的映射组合更灵活。

TIM3既被超声波用又被其他功能占用的坑，我遇到过：超声波测距的Echo接在PA7上，PA7重映射后是TIM3通道2，但如果引脚初始化时配置的是普通输入而不是复用功能，输入捕获就永远读不到高电平。这个排查花了我大半个晚上，最终还是用逻辑分析仪才发现Echo引脚确实有5V高电平，但STM32里定时器根本没捕获到，原因是GPIO模式配置错误。

4.2 串口资源分配与中断优先级

USART1接HC05，USART2接ESP8266，USART3接SIM7600，UART4接SU-03T。四个串口同时用，中断优先级必须规划好，否则响应就会相互干扰。原则是：控制类指令优先级高于数据传输类。蓝牙和语音是控制指令，中断优先级设高；WiFi和4G是数据流，优先级设低一些。

NVIC配置：

NVIC_InitTypeDef NVIC_InitStructure; NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2); // 抢占优先级2位，子优先级2位 // USART1 蓝牙：抢占优先级0，子优先级0 // UART4 语音：抢占优先级1，子优先级0 // USART2 WiFi：抢占优先级2，子优先级0 // USART3 4G：抢占优先级2，子优先级1

中断里不要做耗时操作，比如在USART1的中断服务函数里调用printf或者写OLED，那样会拖慢系统响应。中断里只做“收数据、放环形队列”这件事，具体处理放到主循环。

4.3 功能优先级设计：默认模式与切换机制

这台小车有多种运行模式：手动遥控、循迹、避障、跟随、语音控制。它们不是平等的，我定了一个优先级顺序：

• 语音和蓝牙的“停车”指令优先级最高，任何模式下都立即生效
• 避障优先级高于循迹，因为避障处理的是安全问题
• 循迹优先于跟随，因为循迹是相对固定的路径，跟随是动态目标

实现方式是在主循环里有个状态机，每个模式下维护自己的控制函数，但每轮循环都会先检查“急停”标志和“模式切换”标志：

while (1) { // 1. 先处理急停 if (emergency_stop_flag) { set_motor_speed(0, 0); emergency_stop_flag = 0; running_mode = MODE_MANUAL; continue; } // 2. 处理模式切换指令（通过蓝牙、语音或按键） if (mode_switch_cmd != 0) { running_mode = mode_switch_cmd; mode_switch_cmd = 0; } // 3. 根据当前模式执行控制逻辑 switch (running_mode) { case MODE_MANUAL: manual_control(); break; case MODE_LINE_FOLLOW: line_follow_control(); break; case MODE_AVOID: obstacle_avoid(); break; case MODE_FOLLOW: follow_control(); break; default: break; } delay_ms(10); // 10ms控制周期 }

4.4 主循环架构：前后台系统如何组织

整个工程用的是典型的前后台系统（裸机），没有跑RTOS。前台是定时器中断，承担超声波测距触发、编码器脉冲计数、霍尔测速采样这些硬实时任务；后台是主循环，承担指令解析、模式切换、OLED刷新、PID计算这些软实时任务。

这种架构最大的好处是逻辑清晰、调试简单。如果跑FreeRTOS，八个功能拆成八个任务，任务间的同步和优先级设计反而成了新的复杂度来源。对F103这颗芯片来说，裸机完全能应付这个应用场景，没必要为了“显得高级”而上操作系统。

主循环的周期我控制在10ms，也就是100Hz控制频率。这个频率对电机控制来说足够了，PWM本身的频率是10kHz，但速度环和转向环的控制周期不需要那么快，100Hz的更新率响应已经很快。如果主循环里任务太多导致超过10ms，可以选择去掉OLED刷新，或者把OLED刷新降到20Hz，优先保证控制环的实时性。

5. 实测中踩过的坑：从现象到根因

5.1 HC05蓝牙连不上的完整排查链路

这是最常见的问题，我整理一下当时踩坑的完整排查过程。

现象：手机搜索不到HC05，或者能搜到但连接后发指令没反应。

第一步，先确认模块是否正常上电。HC05的VCC是3.6V到6V，我直接给5V没问题，但有些模块用3.3V供电也能工作却可能不稳定。查看板载LED：慢闪表示AT模式，快闪表示可配对，常亮表示已连接。如果LED不亮，先查电源。

第二步，引脚接线。HC05的TXD要接STM32的RXD，RXD接STM32的TXD，这是交叉接法，很多新手会习惯性地同名前接，结果完全收不到数据。

第三步，检查波特率。HC05默认波特率9600，但如果模块之前被别人改过配置，就可能是38400或者115200。把HC05的KEY引脚拉高，重新上电进入AT模式，用USB转TTL串口工具连接，发AT指令查一下当前参数。注意AT模式下波特率固定是38400，这是HC05的硬件特性。

第四步，如果手机能搜到但连接失败，检查配对密码。默认是1234或者0000，如果被改过，用AT+PSWD?查询。

第五步，如果连接成功但发送没反应，大概率是STM32串口的波特率和模块不一致，或者串口中断没有正确初始化。用串口调试助手直接连接HC05的TXD，看STM32有没有往上发数据，就能定位是哪一边的问题。

排查这类问题一定要有链路思维：手机到蓝牙模块是一段，蓝牙模块到STM32是一段，逐段定位，不要在那里瞎猜。

5.2 舵机抖动与电压跌落问题

跟随模式下，SG90舵机带着超声波云台扫描时，会出现明显的抖动，严重时小车还会重启。用万用表测舵机电源端，发现电压在扫描瞬间从5V掉到4.2V，幅度很大。

原因分析：SG90堵转电流接近700mA，而我从MP1584输出的5V还要给其他模块供电，舵机启动瞬间的大电流把5V母线电压拉低了，STM32那边的3.3V也受影响，单片机就复位了。

解决措施：第一，在舵机电源端并联一个470uF的电解电容，利用电容的电荷储备来缓冲瞬态压降。第二，把舵机电源从5V母线上分出来，单独走一段较粗的线，避免舵机的电流波动传导到逻辑电路。第三，在代码里给舵机加了渐变速度控制，不让舵机瞬间从0度扫到180度，而是按每步2度的速度移动，把瞬时电流峰值降下来。

实测下来，加了电容和渐变控制后，电源电压的波动控制在0.2V以内，问题彻底解决。这提醒我：电机和舵机的瞬态电流远比稳态电流大，给它们供电的线路一定要单独走，不能和逻辑电路挤在一起。

5.3 循迹在强光下乱跑

有一段时间，小车在室内灯光下循迹正常，一到阳光直射的走廊就跑飞。排查后发现是灰度传感器的阈值判断问题。灰度传感器的核心是红外发射管和接收管，强光环境下的红外干扰很大，白线和黑地的反射信号差异被压缩，模块输出的数字电平开始乱跳。

我的解决思路是改用ADC模式读取灰度传感器的模拟输出，每个传感器实时采样，然后做动态阈值校准。具体做法：上电后让用户手动把小车放在白线区域，按一下按键记录白色值；再放到黑色区域，按一下按键记录黑色值；运行时的判断阈值取黑白值的中位数。这个校准过程只需5秒，但效果立竿见影——无论强光还是暗光环境，小车循迹都很稳定。

uint16_t line_adc_white[5], line_adc_black[5]; uint16_t line_threshold[5]; void line_sensor_calibrate(void) { // 等待用户按键，采集白线值 for (int i = 0; i < 5; i++) { line_adc_white[i] = adc_read(i); } // 等待用户按键，采集黑线值 for (int i = 0; i < 5; i++) { line_adc_black[i] = adc_read(i); } for (int i = 0; i < 5; i++) { line_threshold[i] = (line_adc_white[i] + line_adc_black[i]) / 2; } }

这组的校准逻辑对所有光电类传感器都适用，包括光电门、光敏电阻、红外对射，思路都是一样的：先标定环境上下限，再从中取阈值，不要用固定阈值硬拼环境变化。

5.4 STM32延时函数卡死问题

代码里用HAL_Delay()或者自写的delay_ms()时，偶尔出现整个程序卡死的情况。排查后发现两个原因：

第一个是SysTick中断优先级和串口中断优先级配置不当。如果用HAL库的HAL_Delay()，它依赖SysTick中断，而SysTick的优先级默认是15（最低）。如果串口中断抢占优先级更高，串口数据一直进来，SysTick中断就一直被抢占，HAL_Delay()里的while循环永远等不到SysTick计数减到0，程序就“卡死”了。解决办法是把SysTick的优先级调高，或者不用HAL_Delay，改用DWT或者TIM定时来做延时。

第二个原因是中断里调用了延时函数。比如在串口中断里调HAL_Delay(10)，这就极端危险，因为如果一个字节数据导致中断进入延时，延时期间新的中断都被阻塞，缓冲区溢出，系统就乱套了。铁律：中断服务函数里绝不调用任何延时函数，更不做串口打印、OLED刷新这类阻塞操作。

5.5 PID参数整定的血泪经验

这个项目里循迹和跟随都用了PID，参数整定我花了很长时间。最大的体会是：先只调P，让系统稳定下来，再加I和D。

循迹功能的P值整定过程是这样的：初始P=10，小车沿直线走的时候非常迟缓，弯道完全跟不上；加大到P=30，小车开始有轻微的左右震荡，但过弯基本能跟上；继续加到P=50，直线段震荡明显、车头来回摆；最终取P=35，加一点D=5来抑制震荡，效果最好。I值我设得比较小，I=2，只在长直道有轻微偏移时慢慢修正。

跟随功能的速度PID略有不同，这里控制的是速度不是转向角，所以我用了增量式PID，输出是PWM的变化量，这样天然带有积分记忆，不会因为突然的累计误差导致输出超调。

经验总结：PID的调试顺序必须是先P后I再D，不要上来就三个参数一起调，那只会让系统发散得莫名其妙。另外，每次只调一个参数，记录下现象，再改下一个。靠感觉调参数是最浪费时间的事，一定要做实验记录。

6. 源代码工程规划与扩展思路

6.1 工程目录组织与代码模块划分

一套八功能小车的代码，如果全部堆在main.c里，几千行代码会非常难维护。我的工程结构是这样划分的：

Project/ ├── App/ # 应用层 │ ├── main_control.c # 主循环、模式状态机 │ ├── line_follow.c # 循迹控制 │ ├── avoid.c # 避障控制 │ └── follow.c # 跟随控制 ├── Driver/ # 驱动层 │ ├── motor.c # TB6612电机驱动 │ ├── servo.c # SG90舵机驱动 │ ├── ultrasonic.c # HC-SR04测距 │ ├── line_sensor.c # 灰度传感器 │ ├── hall_speed.c # 霍尔测速 │ └── ir_avoid.c # 红外避障 ├── Module/ # 模块层 │ ├── bluetooth.c # HC05通信协议 │ ├── esp8266.c # WiFi透传 │ ├── sim7600.c # 4G透传 │ └── voice.c # SU-03T语音识别 ├── BSP/ # 板级支持包 │ ├── led.c │ ├── key.c │ ├── oled.c │ └── usart.c └── User/ └── main.c # 入口、外设初始化

分层的思想是：Driver层只管最底层的寄存器操作，比如让电机转起来、让舵机转到指定角度；Module层定义模块级的通信和数据接口，比如解析蓝牙指令、封装WiFi透传API；App层决定“这个时刻该干什么”，比如当前模式是循迹还是跟随。这样每一层都可以单独测试，出了问题也容易定位。

6.2 调试技巧：串口调试、逻辑分析仪和printf重定向

开发过程中最依赖的工具是串口调试。我把F103的USART1（蓝牙）在调试阶段暂时拆出来当调试串口用，通过一个USB转TTL线连接到PC，这样就能在代码里用printf输出调试信息。

重定向printf的方式是重写fputc函数：

int fputc(int ch, FILE *f) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, (uint8_t)ch); return ch; }

调试循迹时，我每隔100ms打印一次五个传感器的原始ADC值和判定后的二进制状态，这样不用看小车跑圈，直接在电脑上就能分析传感器数据是否正确。调试超声波时，我打印云台角度、测距值、目标方位，配合串口曲线工具，能直观看到跟随控制的实时表现。

逻辑分析仪是排查串口问题最有力的工具。有一次蓝牙连不上，用逻辑分析仪抓了USART1的TX引脚波形，发现波特率实际上是38400而不是9600，一下定位到问题——模块之前被人改过配置。如果你手头有逻辑分析仪，调试UART、I2C、SPI这类协议故障时，效率会提升数倍。

6.3 从智能小车到更完整的机器人平台

这个项目做完之后，后续的扩展方向很明确：

一是把控制板升级到更强的主控。如果需要在车上跑视觉识别，F103的算力是远远不够的。可以把主控换成树莓派或者K210，STM32继续担任电机控制和传感器采集的“实时层”，树莓派运行图像识别和路径规划，STM32和树莓派之间用串口或者CAN总线通信。这种“双芯片”架构在机器人竞赛里很常见，STM32负责底层务实，树莓派负责上层智能。

二是接一个带AI加速的摄像头模块，比如K210的Maix Cam。K210可以通过串口把识别到的目标坐标发给STM32，让小车实现巡线之外的“找色块”“追踪人脸”“循球”等功能。本届竞赛里很火的“工创赛智能物流小车”项目，核心思路就是这样：STM32做运动控制，视觉模块做目标识别。

三是如果想让小车联网能力再强一点，可以把ESP8266升级为ESP32，走MQTT协议连接云平台，这样小车的数据就能被远程监控，手机APP端也可以通过云平台下发指令，彻底摆脱局域网限制。这个时候4G模块的作用就又体现了——WiFi覆盖不到的区域，用4G网络作为备用链路，数据传输的可靠性会大大提升。

做完这个八功能项目之后，我最大的体会是：单片机开发入门其实不难，难的是把多个模块放到一台设备上让它们协同工作。硬件上要提前规划供电和引脚分配，软件上要设计清晰的模块接口和状态机。如果你也打算做一台全功能智能小车，建议先从小功能单元跑通，再逐步整合，这样每个模块都能单独验证，最后联动的时候才不会出现“一启动就全部崩掉”的无奈局面。希望这份总结能帮你少走一些弯路。

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