企业官网建设流程全解析

简介：面向STM32入门学习者的遥控小车完整工程，基于HAL库实现，覆盖GPIO、定时器PWM、UART/SPI通信、ADC采集与DMA传输等关键模块，适合单片机初学与课程设计参考。压缩包共149个文件，以48个.h头文件与21个.c源码为主体，含Keil工程配置、hex/axf固件、CubeMX的ioc引脚配置等，整体6.81MB，可直接编译运行。资源以STM32F103系列HAL库驱动代码为主，涵盖定时器PWM电机调速、串口遥控指令解析等实现，已有589人浏览学习。分析源码可掌握HAL库外设初始化、电机驱动接线与控制逻辑，以及CubeMX配合Keil的开发流程，对搭建同类遥控车平台有直接参考价值。

1. 基于STM32 HAL库的遥控小车：先把四件事拆明白

基于STM32 HAL库的遥控小车，很多人的第一反应是"不就是个入门课设吗"，实际动手才发现，从一张空白的CubeMX工程到车子在地板上听话地走，中间隔着三座山：硬件搭配怎么选、HAL库外设怎么配、摇杆数据怎么变成左右轮的速度。这篇文章就拆这三座山，再附上一份调试避坑清单。目标是让正在做课程设计、竞赛预演或者纯粹想玩车的开发者，按顺序读完就能自己复现，而不是看一堆零散教程拼不出一台整机。适合有C语言基础、知道GPIO和定时器是什么但没系统做过小车的读者。整条链路拆开其实是四件事：选型、建工程、打通遥控数据、调电机，下面按这个顺序来。

2. 硬件选型与供电设计：主控、电机驱动、遥控模块怎么搭

2.1 主控选型：为什么 STM32F103C8T6 是默认答案

遥控小车对主控的要求其实不高：要出两路PWM、要有一路SPI接射频模块、要有串口做调试、要留几个普通IO给电机方向。把这些需求摆在一起，STM32F103C8T6 就成了绝大多数人的默认选择。72MHz主频、64KB Flash、20KB RAM，对小车这个体量完全够用，而且后期想加编码器测速、加OLED屏显示状态、加循迹传感器，外设也剩得出来。

选它的第二个理由是生态。HAL库的例程、CubeMX的图形化配置、各种开发板的引脚定义，在网上几乎能搜到所有排列组合。真遇到问题，你拿淘宝上最常见的某款最小系统板跑demo，和拿着C8T6芯片自己画板的结论基本一致，这对调试排查非常友好。第三个理由是升级路径顺：如果某天你想加摄像头做视觉巡线，可以从C8T6换到CBT6（128KB Flash），引脚完全兼容，板子都不用重新画。

我个人不推荐一上来就用F407甚至H7。小车这种应用，大部分时间CPU都在空转，F103的性能余量已经很大；高端芯片反而带来供电复杂、引脚密集、CubeMX配置项多的问题，入门阶段属于自我加难度。主控这块的选择，直接影响后面所有调试成本，选F103C8T6是性价比和成功率双高的起点。

2.2 电机驱动选 TB6612，L298N 在这里输在四个细节上

电机驱动是小车里最容易随便选、最后又出幺蛾子的环节。常见选项有L298N和TB6612，我建议直接用TB6612。两者都是H桥驱动，原理一模一样：两个方向引脚的电平组合决定电机正转、反转还是刹车，PWM引脚决定平均电压也就是转速。但落地到小车场景，TB6612的优势是实打实的。

具体说，L298N的压降在电池电压偏低时非常吃亏。两节18650满电8.4V，放到7.2V的时候，L298N输出到电机可能只剩5V出头，小车明显没劲；同样条件下TB6612还能维持6.5V以上。压降不仅影响极速，还影响低速控制——电压不够时，PWM占空比在低段会有一段死区，电机要么不动要么突然窜一下。

接线方面，TB6612的关键引脚是VM（接电池正极）、VCC（接逻辑电源，我习惯接3.3V，与STM32电平一致）、GND、STBY（使能，必须接高）、AIN1/AIN2、BIN1/BIN2、PWMA/PWMB。AO1/AO2接左电机，BO1/BO2接右电机。注意STBY这个脚，很多人忘记拉高，结果电机完全没反应，还以为是程序问题。

2.3 供电链路：电池、稳压、电容怎么接才不互相干扰

供电是遥控小车里最容易被低估的一环。常见配置是两节18650串联得到7.4V左右，一路直接进TB6612的VM给电机供电；另一路通过降压模块稳到5V或3.3V，给STM32和NRF24L01供电。关键原则是：电机的能量路径和主控的能量路径要尽量分开，不要共用一根又长又细的导线，否则电机启动瞬间的大电流会把主控电压拉垮。

我一般会在TB6612的VM和GND之间跨接一个大电容，比如470uF电解电容，吸收电机启停的冲击电流；在NRF24L01的3.3V和GND之间放一个10uF陶瓷电容，保证射频收发瞬间电压不塌。地线方面，所有模块的GND最终单点汇合到电池负极，避免形成环路。电源线用短粗线，杜邦线只负责传信号，这是很多小车"电压明明够但跑不起来"的隐藏原因。

电池电压的选择有个判断标准：电机额定电压的1.2到1.5倍。比如电机标称6V，7.4V电池就合适；电机标称3V，用单节18650或两节干电池更稳。电压太高会让电机过热，太高则驱动模块的稳压部分发热严重，这个后面避坑章还会再提。

2.4 遥控方案：NRF24L01 对比蓝牙与红外，延迟与距离说了算

遥控链路决定了手感和调试复杂度。三种常见方案里，我最推荐NRF24L01：2.4GHz射频、空旷距离几十米、延迟很低，而且是双向通信，可以回传小车状态。蓝牙模块（比如HC-05）的好处是手机串口调试方便，但延迟和配对体验一般，而且经常出现在室内人多时被干扰的情况。红外遥控最便宜，但方向性强、距离短，小车转个角度就可能丢信号，调试时很折磨人。

NRF24L01这边还要决定发送端从哪来。常见做法是：接收端用NRF24L01加一片STM32最小系统板，发送端用另一块带摇杆模块的板子，两边跑同一套协议，代码可以互相复用。摇杆模块实际上就是两个电位器加按键，STM32通过ADC读电位器电压，就能得到X/Y轴数值。这样做的成本不比买成品遥控高多少，但你能完全掌控数据包格式，后期加按键、加震动反馈都方便。

NRF24L01有个参数要注意：空中速率。常见的2Mbps延迟低，但接收灵敏度稍差；1Mbps或250kbps距离更远，但发送一包数据的时间变长。对小车来说，我一般选2Mbps，控制周期够快，距离在小场地内也足够，后面避坑章会讲一个和它强相关的问题。

3. STM32CubeMX 建工程：外设配置与 PWM 初始化

3.1 第一步配置时钟树：从 8MHz 晶振到 72MHz 主频

CubeMX建工程的第一步不是画引脚，而是先把时钟树看明白。如果板子上的晶振是8MHz，打开RCC配置，把HSE设成Crystal/Ceramic Resonator，然后在Clock Configuration页面里让HCLK到72MHz。CubeMX会自动计算PLL参数，通常是PLL源选HSE，倍频到72MHz。这一步完成后，整个系统时钟、定时器时钟、串口波特率都有了稳定的基准，后面配置外设时不容易出现莫名其妙的分频错误。

时钟树里有个坑：APB1总线时钟默认是36MHz，而通用定时器TIM2、TIM3挂在APB1上。当APB1预分频系数大于1时，定时器时钟会自动变成APB1的两倍，也就是72MHz。这个机制经常让新人困惑——明明APB1是36MHz，为什么定时器算出来是72MHz？记住"APB1分频后定时器补倍"这个规律，后面PWM频率计算就不会错。

配置完时钟后，在SYS里把Debug选成Serial Wire。这一步看起来无关紧要，但如果不选，CubeMX可能把PA13/PA14这两个SWD下载引脚重新分配成普通GPIO，导致程序烧过一次后第二次下载失败，只能按住复位键抢时间。这是网上"下不进程序"问题的高发原因，建议每一步都先把这个选项勾上。

3.2 引脚分配：一张表钉死 PWM、SPI、方向控制与串口

引脚分配直接在CubeMX的Pinout视图上点就行。我常用的分配方案是一张表能写完的，所有外设互不冲突，也不用开复用功能的高级选项：

把这几个外设配好，CubeMX生成的代码会自动把GPIO模式、复用功能、定时器参数全部初始化好。需要手动确认的是每个GPIO的初始电平：方向控制脚AIN1/AIN2这类输出，最好在CubeMX里就设成低电平，避免刚上电的一瞬间TB6612收到不确定的输入而导致电机乱动。还有一个细节：没用的引脚不要悬空，我习惯把它们设置成Analog模式，省电也稳定。

工程生成后，建议直接在CubeMX里把项目名和存储路径保持默认，Toolchain选MDK-ARM或者STM32CubeIDE都行。生成的代码结构是HAL库标准的main.c、gpio.c、tim.c、spi.c、usart.c，后面写业务逻辑主要在main.c里加，不建议去改动CubeMX自动生成的文件初始化函数。

3.3 用 HAL 库初始化 PWM：PSC 与 ARR 的取值逻辑

PWM是电机调速的核心。打开CubeMX的Timers配置，选TIM2，在Channel1和Channel2都设成PWM Generation CH1/CH2。最关键的两个参数是Prescaler（预分频PSC）和Counter Period（自动重载ARR），它们一起决定PWM频率和占空比分辨率。

// CubeMX 生成的 TIM2 初始化代码（节选） void MX_TIM2_Init(void) { TIM_OC_InitTypeDef sConfigOC = {0}; htim2.Instance = TIM2; htim2.Init.Prescaler = 71; // 72MHz / (71+1) = 1MHz htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 99; // 1MHz / (99+1) = 10kHz PWM htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(&htim2); sConfigOC.OCMode = TIM_OCMODE_PWM1; sConfigOC.Pulse = 0; // 初始占空比为0，防止上电猛跑 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH; HAL_TIM_PWM_ConfigChannel(&htim2, &sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_ConfigChannel(&htim2, &sConfigOC, TIM_CHANNEL_2); }

这段代码的逻辑是：先把72MHz的定时器时钟分成1MHz，再用这个1MHz去填充一个0到99的计数器，每计满100次输出一个周期，所以PWM频率是1MHz/100=10kHz。占空比由CCR寄存器决定，CCR的取值范围是0到99，对应0%到100%。

选择10kHz而不是1kHz，是因为有刷直流电机在高频PWM下转矩脉动小、噪声低，低速线性度也更好。如果你把电机放在桌上听得到尖锐啸叫，通常就是PWM频率落在了音频范围内，可以尝试把ARR改成49得到20kHz，或者改成199得到约5kHz，对比一下低速手感和噪声。要注意，ARR改小之后占空比分辨率也会变低，比如ARR=49就只有50档可调，差异主要在低速段能不能细腻控制。

启动PWM的代码在main函数里，调用HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1)和HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_2)。修改占空比用__HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, duty)，duty是0到99的整数。很多新人会在这里掉坑：初始化了PWM但是忘了调用Start函数，结果电机一点反应都没有，检查半天发现是输出根本没使能。

3.4 printf 重定向：串口成为第一件调试工具

调小车的时候，最想知道的不是"程序跑没跑"，而是"遥控数据收没收到""当前状态机是什么"。串口打印就是把黑匣子打开的手段。HAL库的标准做法是把printf重定向到USART1，这样就能用printf直接输出调试信息。

// 重定向 printf 到串口1，基于 MDK-ARM + MicroLIB #include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

在MDK工程里记得勾选MicroLIB，否则需要自己处理底层的文件系统接口。如果你用的是STM32CubeIDE，重定向方式不同，需要在syscalls.c里把_write函数改掉，原理一样都是把字符逐个送到串口。这一步做完，你在主循环里每50ms打印一次"spd=xxx dir=xxx"，小车不听话的时候，先看打印值是不是符合预期，就能快速判断是"没收到数据"还是"收到了但处理逻辑不对"。

串口调试的另一个用途是看控制周期。在主循环里翻转一个GPIO，用示波器或逻辑分析仪量它的频率，就能确认你的主循环实际跑了多少Hz。这个小技巧在调PID、调滤波的时候特别有用，后面进阶章还会提到。

4. 遥控数据到电机转动：协议、差速与状态机实现

4.1 数据包格式先定好：六字节协议与和校验

遥控链路的本质是"发送端把摇杆值打包发出去，接收端解包后驱动电机"，所以数据包格式是双方的口径，必须先定下来。我常用的包是6字节：两字节转向值X、两字节油门值Y、一字节按键、一字节校验。发送端把ADC采到的电位器电压映射到-500到+500的整数范围，接收端根据这两个值和按键状态决定小车怎么走。

// 遥控数据包格式定义 // 帧格式: [X_H][X_L][Y_H][Y_L][KEY][SUM] // X/Y 为 int16 大端传输，范围 -500 ~ +500 // KEY: bit0=按键A, bit1=按键B, 其余保留 // SUM: 前5字节累加和，取低8位 typedef struct { int16_t steer; // 转向值，负数为左，正数为右 int16_t speed; // 油门值，负数为后退，正数为前进 uint8_t key; // 按键位 } remote_cmd_t;

选大端还是小端不重要，重要的是发送端和接收端一致。中断方式接收NRF24L01数据可以做，但会引入中断优先级、FIFO管理这些复杂度；小车的控制周期本来就有几十毫秒，轮询接收完全够用，而且代码直观好排查，所以我通常用主循环轮询的方式。和校验放在最后一位，接收端先算一遍校验，不对就丢包，不做任何响应。

这地方有个设计原则：丢包是常态，不是异常。2.4GHz射频在室内遇到Wi-Fi、蓝牙，或者距离稍远，偶尔丢一包很正常。所以接收端的逻辑必须容忍丢包——丢了就保持上一帧的有效指令，连续丢失超过一定时间再停车，这样车子在遥控距离边缘才不会一顿一顿地点头。

4.2 NRF24L01 轮询接收：把接收函数请进主循环

NRF24L01的驱动在很多公开例程里都有，初始化顺序一般是：SPI初始化、写配置寄存器（数据速率、通道频率、收发模式）、拉高CE进入接收状态。驱动细节不展开，重点是接收逻辑怎么嵌进主循环。

// 主循环中轮询接收 NRF24L01 数据 uint8_t rx_buf[6]; remote_cmd_t cmd = {0}; uint32_t last_rx_tick = 0; while (1) { // 从 NRF24L01 读一包数据，成功返回0 if (nrf24_receive(rx_buf) == 0) { // 先做和校验，避免错包进入控制逻辑 uint8_t sum = 0; for (int i = 0; i < 5; i++) sum += rx_buf[i]; if (sum == rx_buf[5]) { cmd.steer = (int16_t)((rx_buf[0] << 8) | rx_buf[1]); cmd.speed = (int16_t)((rx_buf[2] << 8) | rx_buf[3]); cmd.key = rx_buf[4]; last_rx_tick = HAL_GetTick(); } } // 超过300ms没收到有效数据，强制停车 if (HAL_GetTick() - last_rx_tick > 300) { cmd.speed = 0; cmd.steer = 0; } // 根据 cmd 计算占空比并输出 control_motor(&cmd); HAL_Delay(5); // 约200Hz控制周期 }

这段代码里有三个关键点。第一，nrf24_receive每次调用都会把CE拉低再拉高，触发一次接收，读到的数据放到rx_buf；如果射频模块那边没有数据或者数据校验不通过，函数返回非0，rx_buf内容不可信。第二，校验和计算放在解析之前，校验失败直接跳过，防止因为错包导致小车突然转向。第三，超时停车是安全兜底——遥控器关机、电池没电、发射端死机，任何一种情况都会让接收端在300ms内收不到包，这时候小车必须自己停下来，而不是保持最后一个指令一直跑。

关于轮询周期，5ms对应200Hz，对遥控小车足够了。人的手速响应在50ms量级，遥控数据的更新率再快，人感知不出区别；但控制周期太快会占用大量CPU时间，影响其他任务。如果你以后要加显示、加循迹传感器，把主循环的HAL_Delay从5ms改到10ms，控制周期降到100Hz，小车操作手感也不会有明显变化。

4.3 摇杆值到占空比：死区、差速与转向状态机

有了遥控数据，下一步就是把它变成两路PWM占空比。这是控制逻辑的核心部分，我把整个逻辑分成三块：死区过滤、方向判断、差速分配。

// 摇杆值转占空比：死区、方向、差速 #define DEAD_ZONE 30 // 摇杆回中的偏移阈值 #define PWM_RANGE 99 // 与ARR对应 void control_motor(remote_cmd_t *cmd) { int16_t speed = cmd->speed; int16_t steer = cmd->steer; // 死区：摇杆电位器不一定能精确回到中点，过滤小幅漂移 if (speed > -DEAD_ZONE && speed < DEAD_ZONE) speed = 0; if (steer > -DEAD_ZONE && steer < DEAD_ZONE) steer = 0; // 转向偏移量：steer范围-500~+500，映射到占空比偏移 // 偏移量不超过总占空比的30%，防止原地甩尾 int16_t steer_offset = (int16_t)((int32_t)steer * PWM_RANGE / 500 / 3); // 基础油门：speed范围-500~+500，映射到0~99 int16_t base_duty = (int16_t)(((int32_t)speed) * PWM_RANGE / 500); if (base_duty < 0) base_duty = -base_duty; // 取绝对值，方向由GPIO控制 // 差速分配：左轮加偏移，右轮减偏移 int16_t left_duty = base_duty + steer_offset; int16_t right_duty = base_duty - steer_offset; // 限幅到0~99 if (left_duty < 0) left_duty = 0; if (left_duty > PWM_RANGE) left_duty = PWM_RANGE; if (right_duty < 0) right_duty = 0; if (right_duty > PWM_RANGE) right_duty = PWM_RANGE; // 方向控制：根据speed正负决定前进后退 // speed>0 前进，speed<0 后退，speed=0 停止 if (speed > 0) { motor_forward(left_duty, right_duty); // 左电机正转、右电机正转 } else if (speed < 0) { motor_backward(left_duty, right_duty); // 左电机反转、右电机反转 } else { motor_stop(); } }

死区这个参数的度要自己摸。摇杆电位器老化后回中偏移会变大，DEAD_ZONE太小会导致小车原地轻微蠕动；太大则在小幅打方向时没反应，手感发肉。我先给30，等装好车跑一圈，观察遥控器回中时串口打印的值，再针对性调整。

转向的实现方式值得多说一句。这里用的是差速转向而不是舵机转向：左右轮速度不同，小车就往速度慢的一侧转。steer_offset占总占空比的1/3，意味着即使油门很大，转向偏移也只占总驱动的三成，避免高速时猛打方向导致小车甩尾或者电机过载。如果你做的是那种四轮小车、前后轮固定没有转向机构，差速逻辑基本就是这套；如果有独立转向伺服舵机，那才需要把角度值单独映射到舵机PWM。

方向控制函数里还要把TB6612的方向引脚和PWM输出配合好：

// 前进：AIN1=1 AIN2=0，BIN1=1 BIN2=0，PWM设为对应占空比 void motor_forward(uint16_t left_duty, uint16_t right_duty) { HAL_GPIO_WritePin(AIN1_GPIO_Port, AIN1_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(AIN2_GPIO_Port, AIN2_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(BIN1_GPIO_Port, BIN1_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(BIN2_GPIO_Port, BIN2_Pin, GPIO_PIN_RESET); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, left_duty); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, right_duty); }

这套逻辑里，方向由GPIO电平决定，速度由PWM占空比决定，两者互不干扰。如果你发现"前进"实际是倒车，不一定是接线错，很可能是你的发送端把Y轴极性定义反了，后面避坑章会说怎么处理。

4.4 超时保护：遥控断开后小车自己停下

上面的代码里用了last_rx_tick做超时判断，这个设计在遥控小车里属于安全底线，不是可选项。新人在调试时经常遇到一个场景：遥控器放在桌上忘关，小车插上电池突然就往前跑——因为接收端还在用最后那包"前进"指令。所以上电时也要做一次保护：如果在主循环刚开始的几百毫秒内没收到第一包有效遥控数据，保持停车状态。

我习惯在main函数初始化完成后，先调用一次motor_stop，把TB6612所有方向引脚置低、PWM占空比清零，之后再进入主循环。这样哪怕CubeMX生成的初始GPIO状态不确定，上电瞬间也不会因为某个引脚恰好是高电平而让电机转一下。这个习惯看起来多此一举，但配合"第一步就置零"的原则，可以消灭整台车上电乱动的绝大部分原因。

5. 调试避坑：遥控小车最常见的 5 个翻车现场

5.1 现象一：上电小车自己往前窜，或者电机微微抖动

明明程序里没给任何指令，一插电池车就往一个方向跑，或者电机发出高频吱吱声。这个现象几乎每个做小车的人都遇到过，原因分两种。第一是CubeMX生成工程时，方向控制引脚AIN1/AIN2没有指定初始电平，上电瞬间为不确定状态，TB6612在输入悬空时输出不可控。第二是PWM模块初始化后还没调用HAL_TIM_PWM_Start，CCR寄存器虽然写了0，但输出通道没使能，电机在残留电压下产生微动。

解决方法是双管齐下。在main函数的外设初始化完成之后、进入while循环之前，加一段强制复位逻辑：

// 上电先保证绝对停止 void motor_stop(void) { HAL_GPIO_WritePin(AIN1_GPIO_Port, AIN1_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(AIN2_GPIO_Port, AIN2_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(BIN1_GPIO_Port, BIN1_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(BIN2_GPIO_Port, BIN2_Pin, GPIO_PIN_RESET); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 0); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, 0); }

同时在CubeMX的GPIO配置里，把AIN1、AIN2、BIN1、BIN2的GPIO初始电平直接设成Low。这属于"配置里能解决的不留到代码里解决"，以后重新生成工程也不会丢。

5.2 现象二：前进变后退，左转变右转，方向全对不上

遥控器往前推，车往后跑；往左打方向，车轮转速倒是变了，但车往右转。这种问题看起来玄学，其实就两个根源：要么是电机两端接反了，要么是摇杆X/Y轴的极性定义和你的直觉相反。怎么快速定位？先打印原始数据。在接收端把cmd.steer和cmd.speed直接打印出来，往前推摇杆看speed是正还是负，往左打看steer是正还是负，就知道软件里极性定义是什么了。

如果是电机端子接反导致的，不需要拆车改线。最简单的处理是在软件里做一个交换开关：

// 前进后退反了，把油门取反即可，不用拆电机线 #define SWAP_THROTTLE 1 #define SWAP_STEERING 0 int16_t speed = SWAP_THROTTLE ? -cmd->speed : cmd->speed; int16_t steer = SWAP_STEERING ? -cmd->steer : cmd->steer;

这两个宏留成0和1的开关，调试时翻转一次就能看到效果，比反复拆线效率高得多。改完之后把车架起来空转验证一次，确认逻辑正确再下地跑。注意：改了宏之后一定要重新编译烧录，而且要确认接收端和发送端用的极性定义一致，不然会出现"单独测都没问题，连起来就反"的情况。

5.3 现象三：电池电压检测正常，但电机没劲，跑一会整机复位

这是供电链路的问题，而且很有迷惑性。用万用表量电池两端有7V多，量TB6612的VM也有7V，但电机就是没劲，跑起来还偶尔掉电重启。真正的坑在动态电压上：电机堵转或急加速时瞬间电流可以到1A以上，电池内阻加导线电阻一起压降，VM实际可能掉到5V以下；更严重的是，如果主控板也从这条线上取电，电压跌落会直接把STM32拉复位。

我的处理方案有三条。第一，从电池到TB6612 VM的导线换成短粗线，长度尽量控制在15cm以内，截面尽量大，杜邦线只做信号传输。第二，TB6612的VM和GND之间并一个470uF电容，就近跨接在驱动板的电源端子上，这电容就是给电机瞬态电流用的"水库"。第三，主控的供电不要从电机电源线末端直接引，用独立降压模块从电池取电，或者至少在主控板上加一个容量足够的LDO，让MCU的3.3V和电机的大电流彻底隔离。

排查这类问题有一个有效办法：接上电机空转时，用示波器或者万用表交流档量VM和3.3V的波形，看跌落幅度。如果VM在电机启动瞬间跌了超过1V，说明供电链路余量不够，优先加大电容和换粗线，而不是去换电机。

5.4 现象四：NRF24L01 距离近、经常断连，有时完全收不到

NRF24L01收不到数据，先别急着怀疑模块坏了。最常见的两个原因，一是模块供电质量差，二是SPI速率太高。NRF24L01在收发瞬间电流变化很快，如果3.3V是由主控板上的小降压芯片提供、旁边又没有电容，电压塌陷导致的收发失败非常隐蔽——你用万用表量电压是稳的，因为万用表反应不过来。

解决的先后顺序是这样：先给模块的3.3V和GND之间加一个10uF陶瓷电容，最好再加一个100uF的普通电容；然后把SPI速率先降下来，CubeMX里把SPI预分频调大，让SCK在2.25MHz左右。很多模块用10MHz的SPI在短接线情况下没问题，但一旦用了杜邦线、线又超过20cm，信号边沿变形就会随机丢包。降到2.25MHz对小车这种小数据量的应用没有任何性能影响，但稳定性提升明显。

还有一个参数要和发送端对好：NRF24L01的空中速率、射频通道、地址宽度、CRC长度，两端必须完全一致。这几个配置项中任何一个不匹配，接收端虽然能初始化成功，但永远收不到数据。调试时在接收端打印接收失败计数，如果这个值一直在涨，优先排查这几个配置。

5.5 现象五：空转正常，放地上就不走，或者低速时一顿一顿

这是新手最容易崩溃的现象：把车架起来，给油门，车轮转得欢；放到地上，车不走，或者走两步停一下。问题往往不在程序，而在PWM频率和低速线性度。有刷直流电机在PWM频率太低时，低速段的转矩波动非常大，空载时看不出来，一旦带载（就是车放地上受到摩擦力）就表现为抖动、停顿。

处理方法是把PWM频率从1kHz提高到10kHz以上。如果已经在10kHz还是不行，再看占空比映射：摇杆在小角度推的时候，base_duty算出来只有10左右，对应10%占空比，电机可能刚好处于启动临界区。可以给占空比做一个非线性映射，把低速段抬高一点：

// 低速段补偿：把占空比小于30的部分映射到30 // 让电机越过启动死区，实际速度差异由PWM调节 if (base_duty > 0 && base_duty < 30) base_duty = 30;

这个补偿逻辑有个副作用：小车在极低速时可能无法做到很细腻的蠕行，但对遥控车来说，手感更重要的是一次给够让车动起来，而不是追求毫米级控制。另外检查一下轮胎和地面，如果是硬塑料轮在瓷砖地面上打滑，那是纯粹的机械摩擦问题，调程序解决不了，换上橡胶轮或者贴防滑胶带立竿见影。

6. 进阶调教：速度平滑、串口观测与扩展预留

6.1 限幅斜坡：让速度变化像油门不像开关

遥控小车最廉价的体验提升，是给占空比变化加一个限幅斜坡。直接拿摇杆值改占空比，油门从0突然拉到80%，电机会瞬间全速，车身会明显往前窜甚至抬头；加了斜坡之后，占空比每5ms最多变化几个百分点，加速过程变得柔和，人操控时容错也高很多。

#define STEP_MAX 4 // 每个控制周期占空比最大变化量 // 在 control_motor 之前先做目标值限幅 int16_t target_duty = base_duty; static int16_t current_duty = 0; if (target_duty > current_duty) { current_duty += STEP_MAX; if (current_duty > target_duty) current_duty = target_duty; } else if (target_duty < current_duty) { current_duty -= STEP_MAX; if (current_duty < target_duty) current_duty = target_duty; }

STEP_MAX取4、控制周期5ms时，从0加速到最大占空比99需要约124ms，体感是"有响应但不突兀"。这个值可以根据你的车重和场地调大调小，车越重、惯性越大，STEP_MAX应该越小，否则起步照样窜。这个技巧也同样用在停车上——急刹车比急加速更容易翻车，限幅缓解了重心前移的问题。

6.2 串口观测状态机：遥控没反应时先看这里

调试遥控小车，最忌讳的是一口气把代码全写完再上电。我习惯在主循环里加一个周期性的状态打印，每100ms输出一次当前摇杆值、目标占空比、实际占空比、方向状态四个量。用串口助手看这些数值，如果摇杆推到一半但打印里的speed一直是0，那就是死区设置问题；如果speed有值但电机不转，那问题在驱动或接线；如果一切都正常但车不走，才轮到怀疑机械部分。

这个习惯省掉的时间非常可观。很多"遥控没反应"的帖子，最后查出来是发送端ADC没启动，打印一下就能看出speed永远为0，根本不用动接收端。串口还有一个好处是能看到丢包率，你在串口助手计数每次超时停车的次数，就能量化评估遥控链路的稳定性，而不是凭感觉判断"好像有时候卡一下"。

6.3 模块化留接口：以后加编码器闭环或循迹不用重写

做到这一步，小车已经能玩了。但如果想继续深入，建议现在就把代码结构按模块拆好：收发层、解析层、控制层、驱动层分开，每层只通过结构体传递数据。这一步的价值在加编码器闭环时立刻体现。

加编码器测速，只需要在TIM3上开编码器模式，在控制层读取计数差值换算成转速，用来修正目标占空比；加循迹，只需要在解析层旁边加一个ADC或GPIO读取函数，把循迹状态也塞进同一个控制入口。这些扩展都不需要改动射频协议和PWM输出部分。我做过最大的教训是第一次把收发、解析、控制全写在main函数里，后来加循迹模块时改得焦头烂额，才意识到模块化的必要性。

这套方案做完，你手里不只是一台能跑的玩具车，还沉淀了一套"无线数据收发+差分驱动控制"的模板。后面做双车通信、做简易无人车底盘、做竞赛的多传感器小车，开头都是这套框架。希望帮到你。

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