企业官网建设流程全解析

简介：基于STM32 HAL库的遥控小车完整工程资源，面向嵌入式初学者与STM32开发者，帮助理解HAL库的GPIO、TIM、UART、ADC、DMA等模块在真实小车项目中的综合应用。资源以zip压缩包形式提供，共149个文件，主要包含21个c源码、48个h头文件、Keil工程文件（uvprojx/uvoptx）、ioc配置以及hex/axf/map等编译烧录文件，便于直接打开工程查看代码或烧录验证。压缩包约6.81MB，结构清晰，方便按功能模块检索学习。目前已有589人浏览学习。通过这份工程可掌握基于HAL库的遥控信号解析、PWM电机调速、传感器数据读取和中断/DMA处理等核心流程，同时参考工程中的初始化配置与外设驱动写法，快速迁移到自己的小车或机器人项目中。无论是课程设计还是入门实践，这段工程代码都能提供直观的参考。

1. STM32 HAL库遥控小车：最容易翻车的是供电与地线，不是电机代码

遥控小车最常被低估的不是 HAL 库的 API，而是“电机一动、单片机复位”这类硬件问题。你在串口助手里看到指令正常、PWM 占空比也在变，轮子却不转，或者一上大油门电压瞬间掉到单片机重启阈值以下，十有八九不是代码逻辑错，而是供电与地线没处理干净。这篇笔记按“生成 HAL 库工程 → 定时器 PWM 驱动电机 → 串口/无线遥控链路 → 速度闭环”的顺序走，把每一步的关键参数和踩坑点写清楚，既适合第一次用 HAL 库把手头板子驱动起来的开发者，也适合已经在用寄存器开发、想迁移到 HAL 库的人。文中示例以 Cortex-M3 内核的常见 F1 系列为主，F4 系列同样适用，差异只在时钟树配置与引脚映射。

2. 生成HAL库工程并点亮第一盏灯：时钟树与PWM通道的配置顺序

很多人拿到小车套件后第一件事是直接写电机控制代码，结果 PWM 波形出不来，查了半天才发现是定时器时钟没配好。我的习惯是先花十分钟把工程生成、闪灯、串口回传这三件事跑通，再碰电机。因为 HAL 库工程的坑大多集中在时钟树和引脚复用上，这两块没理顺，后面所有外设都会跟着出问题。

2.1 图形化配置时钟树与PWM通道：一张参数表说清分频系数

在官方图形化配置工具里新建工程后，第一步不是勾选外设，而是先确认时钟树。我一般先把主频设到当前芯片能稳定跑到的最髙值，比如 F1 系列的 72MHz 或者 F4 系列的 168MHz，再去看 APB1 和 APB2 的分频关系。定时器 PWM 的频率计算公式是：

fPWM = 定时器时钟 / (PSC + 1) / (ARR + 1)

注意 APB1 分频不为 1 时，挂在该总线上的定时器时钟会是 APB1 的两倍，容易让人算错。比如 APB1 分频为 2，APB1 输出 36MHz，定时器时钟实际是 72MHz。这个细节在图形工具里通常不会直接标出来，需要自己在配置界面核对。

我把 PWM 频率定在 10kHz 到 20kHz 之间，一方面高于人耳敏感区，电机不会发出刺耳高频声；另一方面这个区间内驱动模块的开关损耗和电流纹波都相对可控。占空比分辨率用 ARR=999 刚好对应 0.1% 起步，后续做速度闭环调整量更细腻。如果你想在示波器上看到完整波形，可以先用低频 1kHz 验证，但不要长期用这个频率驱动电机。

2.2 生成工程后的冒烟测试：闪灯加定时器计数，确认时钟链路没断

工程生成后先不要急着写业务代码，先做一个 5 分钟的冒烟测试。代码逻辑很简单，闪灯的同时读取定时器计数寄存器，确认定时器时钟确实在跑。这样才能把“代码问题”和“时钟配置问题”区分开。

int main(void) { HAL_Init(); SystemClock_Config(); // 时钟树参数来自图形化配置，不要手改 MX_GPIO_Init(); MX_TIM2_Init(); // 定时器初始化为计数模式 while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); // 调试器里观察这个变量是否持续增长 // 如果一直为0，说明TIM2时钟没配好 uint16_t cnt = __HAL_TIM_GET_COUNTER(&htim2); (void)cnt; HAL_Delay(500); } }

这段代码的关键并不在闪灯，而在于__HAL_TIM_GET_COUNTER(&htim2)的返回值。正常情况 cnt 应该每 500ms 变化一次，数值大小取决于定时器时钟频率。如果 cnt 恒为 0，优先检查 TIM2 的时钟是否在图形化工具里被关闭；如果 cnt 乱跳，再查时钟树的主频是不是设错了。另外 HAL_Delay 的时基默认来自 SysTick，如果你把 SysTick 关了，延时函数会直接失效，这是新手容易忽略的依赖关系。

2.3 HAL_Init、SystemClock_Config、MX_GPIO_Init：这三个函数别乱动

这三个函数是图形化工具按你的配置生成的，我一般只在/* USER CODE BEGIN */和/* USER CODE END */标记之间加自己的代码，重新生成工程时工具会保留这些区域，但会把你自己写的初始化内容覆盖掉。SystemClock_Config 尤其不能手改，因为它同时影响串口波特率计算、定时器分频和 HAL_Delay 的精度。

GPIO 初始化里要注意“复用”概念的引入。PWM 输出不是普通推挽输出，而是要把引脚配置为复用功能。在图形工具里选择定时器通道后，引脚会自动变绿，表示已进入复用状态。如果你拿到工程后手动把这个引脚改回了 GPIO 输出，PWM 波形是出不来的。这个现象我见太多次了，代码看起来和初始化完全正确，但引脚的复用配置被覆盖了。

3. HAL定时器输出PWM驱动电机：启动顺序、占空比映射与左右轮初调

PWM 通道配置完成后，接下来的任务是让两个电机按照给定占空比转起来。很多人在这里犯的错误是“启动 PWM 后，CCR 还没设置就给了个大值”，导致上电瞬间电机猛冲一下。这节把启动顺序、占空比映射和左右轮初调讲透。

3.1 用HAL_TIM_PWM_Start还是__HAL_TIM_SET_COMPARE：启动顺序的讲究

HAL 库提供了两个常用 API，一个是HAL_TIM_PWM_Start()，一个是__HAL_TIM_SET_COMPARE()。前者让定时器产生 PWM 波形，后者设置比较值。正确做法是先设置 CCR 为 0，再启动 PWM，最后才写入目标占空比。

void motor_pwm_init(void) { // 先让比较值为0，避免上电瞬间输出满占空比 __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 0); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, 0); // 启动PWM输出，通道才真正产生波形 HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_2); // 启动后再写入初始速度，比如20%占空比 __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 200); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, 200); }

这段代码最关键的一点是把“设置 CCR”和“启动定时器”分开。HAL_TIM_PWM_Start()这个函数的执行不受 CCR 当前值影响，它会直接使能定时器输出。如果你在启动之前把一个较大的 CCR 写进去，启动瞬间就会输出高占空比，机械结构会产生明显冲击，严重时齿轮会打滑。另外要注意 ARR=999 时，CCR 写入 200 表示占空比约为 20%，计算方式是 CCR / (ARR + 1)。

3.2 占空比映射：把0~100的遥控值换算成CCR，并处理最低启动电压

遥控端通常会给一个 0~100 的速度百分比，你需要把它线性映射到 CCR。看起来是简单乘除法，但有个实际问题：电机存在启动电压，占空比低于某个阈值时，电机只发嗡嗡声不转。这个阈值因电机负载和供电电压而异，直接做线性映射会出现“遥控推了一点，轮子不动，推到某个点突然窜出去”的现象。

// 将遥控百分比速度映射为CCR，带最低启动补偿 // speed: 0~100 arr: 定时器自动重装载值 min_duty: 实测启动占空比 uint16_t map_speed_to_ccr(uint8_t speed, uint16_t arr, uint16_t min_duty) { if (speed == 0) { return 0; // 速度0必须输出0，不能用启动占空比 } uint32_t ccr = (uint32_t)speed * (arr + 1) / 100; if (ccr < min_duty) { ccr = min_duty; // 低于启动阈值时强制抬到最小可转值 } return (uint16_t)ccr; }

min_duty 的确定方法：在代码里手动把 CCR 从小到大步进，观察电机刚好连续转起来的最小值。不同电机的启动占空比差异很大，同一批电机实测可能从 3% 到 6% 都有。这里还有一个小技巧，把启动补偿做成一个查表，而不是在映射函数里做一刀切，因为左右轮电机的启动阈值往往不同，共用同一个 min_duty 会让低速段左右轮转速差被放大。

3.3 左右轮初调：转速差从哪来，如何预校准

左右轮转速不一致基本是必然的，原因有三个：电机出厂个体差异、左右侧机械阻力不同、PWM 通道输出的电气参数略有偏差。在开环状态下，左右轮给相同占空比，实际转速差可能达到 10% 以上。这个问题会让小车跑不远就偏航。

我一般会在开环阶段做一个预校准：把小车架空，给左右轮相同的 CCR，用编码器或手机测速工具读取实际转速，形成一个校正系数表。

实测中这个校正系数并不是恒定的，在低占空比段误差更大，因为轴承摩擦和齿箱阻力占比更高。所以更可靠的做法是分段校准：把 0~100 的速度区间分成 5 段，每段测一组系数，存成数组。当然这阶段不用追求精度，能保证中高速段走直线就行，低速段的偏航留给第 6 章的速度闭环处理。

4. 遥控链路落地：串口透传加帧校验，从收到一个字节到车轮转动

电机能转之后，下一步是接入遥控。最容易踩的坑出现在“收到了数据不等于收到了有效指令”：蓝牙或者 2.4G 模块在干扰环境下会丢字节、插字节，如果不对数据做校验和帧同步，小车就会间歇性抽搐。

4.1 两种主流遥控链路怎么选：蓝牙透传与2.4G接收机

如果你是用手机控制，蓝牙透传最省事，模块上电后直接输出串口数据，HAL 库只需配置一个串口接收。如果你手里有航模遥控器，2.4G 接收机输出的一般是 PPM 或 SBUS 信号，需要额外解码，F1 系列的串口空闲中断可以解 SBUS，但代码复杂度明显上升。我一般建议第一次做遥控小车的人选蓝牙透传，把精力放在运动控制和避坑上，不要一上来就和 PPM 时序纠缠。

4.2 中断逐字节接收与环形缓冲：把乱码挡在解析之前

串口接收不要在主循环里用阻塞式接收函数，否则主循环一忙就会丢字节。常见做法是 HAL 库的HAL_UART_Receive_IT()配合HAL_UART_RxCpltCallback()，在中断回调里逐字节写入环形缓冲。

#define RX_BUF_SIZE 128 // 环形缓冲区和读写指针 volatile uint8_t rx_buf[RX_BUF_SIZE]; volatile uint16_t rx_head = 0; volatile uint16_t rx_tail = 0; volatile uint8_t rx_byte = 0; // 串口中断回调：收到一个字节就进缓冲区 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart == &huart2) { // 假设遥控模块接在USART2 rx_buf[rx_head] = rx_byte; rx_head = (rx_head + 1) % RX_BUF_SIZE; // 消费者处理不过来时丢弃最旧数据，保证新数据优先 if (rx_head == rx_tail) { rx_tail = (rx_tail + 1) % RX_BUF_SIZE; } // 重新开启单字节接收 HAL_UART_Receive_IT(&huart2, &rx_byte, 1); } } void uart_start_receive(void) { HAL_UART_Receive_IT(&huart2, &rx_byte, 1); }

为什么不用HAL_UART_Receive_IT(&huart2, buffer, len)直接接收一帧？因为遥控数据什么时候来是不确定的，你不知道帧长度，也不知道数据是否连续。逐字节接收配合环形缓冲，可以从任意字节开始做帧同步，不容易卡死。这里rx_head是写指针，rx_tail是读指针，两者模 128 回绕。还有一个细节，缓冲区大小选 128 够用，但如果你把串口波特率拉高到 115200，中断频率随之升高，缓冲区太小会被快速打满。

4.3 帧解析与指令映射：从方向值到PWM占空比的一行关键运算

环形缓冲里是一堆原始字节，需要按自定义协议解析。我习惯用一个简洁的帧格式：帧头、命令字、数据长度、数据、校验和。

// 帧格式：AA 55 CMD LEN DATA... CHECK // 示例：AA 55 01 01 64 66 // 帧头 AA 55，CMD=01 表示速度指令，LEN=01， // DATA=64 表示100%速度，CHECK=01^01^64 异或校验 uint8_t parse_frame(uint8_t *frame, uint8_t len) { if (len < 5) return 0; if (frame[0] != 0xAA || frame[1] != 0x55) return 0; uint8_t sum = 0; for (uint8_t i = 2; i < len - 1; i++) { sum ^= frame[i]; // 异或校验：除了校验和自身 } if (sum != frame[len - 1]) return 0; return 1; // 帧合法 }

状态机的逻辑其实就三件事：找帧头、收够长度、校验通过后解析。指令解析出来之后，映射到左右轮占空比是关键运算。假设遥控端发来方向值和速度值，差速转向的处理方式决定了操控手感。

// 解析结果：cmd_dir 0停车 1前进 2后退 3左转 4右转 // cmd_speed 0~100 switch (cmd_dir) { case 1: // 前进：左右轮同速 left_ccr = map_speed_to_ccr(cmd_speed, 999, 50); right_ccr = map_speed_to_ccr(cmd_speed, 999, 50); break; case 3: // 左转：左轮慢、右轮快 left_ccr = map_speed_to_ccr(cmd_speed / 2, 999, 50); right_ccr = map_speed_to_ccr(cmd_speed, 999, 50); break; case 4: // 右转：右轮慢、左轮快 left_ccr = map_speed_to_ccr(cmd_speed, 999, 50); right_ccr = map_speed_to_ccr(cmd_speed / 2, 999, 50); break; default: // 停车 left_ccr = 0; right_ccr = 0; }

转向时内侧轮速度减一半而不是直接停转，是为了避免原地打转造成姿态突变。你可以按手感调整这个比例，有的开发者用 0.7 倍，有的用 0.3 倍。前提是左右轮都超过启动占空比，低于这个值转向会变成单轮驱动，车子会画弧而不是转向。

4.4 死区与超时保护：为什么摇杆回中后小车还在滑

用遥控器摇杆控制时还有一个常见体验问题：摇杆明明回中了，小车还在往前滑。原因有两个，一是摇杆的物理回中位置不是精确的中间值，它可能停留在 47 或 53 而不是 50 附近；二是接收机输出在中间附近有噪声抖动。解决方式是设置死区，把中间值附近的一段范围强制映射为 0。

// 摇杆原始值范围 0~100，中值50 // dead_zone=15 表示 35~65 都视为中位停车 uint8_t apply_dead_zone(uint8_t raw, uint8_t dead_zone, uint8_t center) { if (raw > center - dead_zone && raw < center + dead_zone) { return center; } return raw; }

超时保护的逻辑也不能省。遥控器和接收机一旦断连或者被遮挡，串口就不再收到数据，如果不处理，小车会按最后一条指令一直冲下去。我用一个接收时间戳来实现超时停车，主循环每次处理完指令后把HAL_GetTick()存入变量，下一次进入循环时比较当前时间和上次时间的差值。

uint32_t last_rx_tick = 0; void check_remote_timeout(void) { if (HAL_GetTick() - last_rx_tick > 500) { // 500ms没收到新指令 stop_motors(); // 立即停车 } }

超时阈值我一般设 300ms 到 500ms 之间。设置太短，无线模块偶尔丢一帧就会导致急停，车子一冲一顿；设置太长，断连后滑行距离过大，容易撞东西。500ms 是平衡得比较好的值，既不敏感过度，也能在失联后及时把车停下来。

5. HAL库遥控小车避坑记录：5个让整车趴窝的真实问题与排查顺序

这章把我常遇到的 5 个典型问题按“现象 → 原因 → 解决”拆开。这些问题单独看都很简单，但叠加在一起，排查起来非常耗时。排障顺序也值得说一下：先电源、再时钟、再引脚复用，最后查逻辑代码。很多人一上来就盯代码，实际上供电问题最隐蔽。

5.1 电机不转但代码看着没问题：EN引脚与使能顺序

现象：PWM 波形在示波器上看着正常，代码也没逻辑错误，但电机完全不动。原因：驱动板上的 EN（使能）引脚没有被拉高，或者初始化时 GPIO 被设成了低电平。很多驱动模块的 EN 引脚默认不由 MCU 控制，而是靠跳线帽或外部上拉，如果你把它接到了 MCU 引脚但初始化后输出为低，板子就被关停了。解决：先检查跳线帽是否在位，再确认 GPIO 初始化时这个引脚被设置为高电平输出，最后才启动 PWM。注意初始化顺序，GPIO 先输出高电平，再去HAL_TIM_PWM_Start()，顺序反了可能出现偶发的不转。

5.2 串口一片乱码：晶振频率与HSE_VALUE不一致

现象：串口助手收到波浪线或完全不规则字符，波特率怎么调都不对。原因：板子实际焊接的外部晶振频率和工程里配置的 HSE_VALUE 不一致。常见情况是工具自动填了 8MHz，但板子上是 12MHz 或 25MHz。HAL 库的串口波特率计算依赖这个值，它错了，USB 转串口那里即使设了正确的波特率也没用。解决：检查评估板原理图上的晶振标注，在图形化工具里把 HSE_VALUE 改对，重新生成工程。排查时可以加一个回环测试：MCU 上电后立即往串口发一串固定字符，用示波器看 TX 引脚波形，对比实际波特率与期望值的偏差。

5.3 一接电机供电电压就跌：电池内阻与电容的坑

现象：小车空载时一切正常，放地上加油门就重启，或者电机一启动，MCU 旁边的指示灯就闪。原因：电机启动瞬间电流可以达到正常运行电流的 3~5 倍，电池内阻压降过大，导致电源电压瞬时跌落，单片机进入掉电复位。解决：在电机供电端并联一个大容量电解电容，一般 470uF 到 1000uF 起步，电容充电时间短，能提供瞬时电流。同时把逻辑电源和功率电源分开，MCU 供电单独从稳压模块输出取电，功率地和逻辑地只在电源入口单点相连。不要依赖电池自身的输出能力，电池老化后内阻上升，这个问题会越来越严重。

5.4 遥控延迟感明显：阻塞接收与主循环里跑延时

现象：按下遥控按键，小车要过几百毫秒才有反应，松开后还在动。原因：主循环里有 HAL_Delay() 或其他阻塞串口接收操作，比如HAL_UART_Receive()一次等 10 个字节，等不到就卡住。遥控数据到达后没有被及时处理，缓冲区被积压。解决：主循环里禁止长延时，HAL_Delay 只用于上电初始化和短暂等待；串口接收全部改成中断加缓冲的方式；延时类功能用非阻塞的HAL_GetTick()轮询。还有一个容易被忽略的点，读取环形缓冲的解析函数要尽量短小，解析状态机可以放在主循环里，但单次处理不要超过 1ms 的 CPU 时间。

5.5 下载器突然连不上芯片：SWD引脚被复用成PWM

现象：某次烧完程序后，再次点击下载，工具报错“连接失败”或“No target connected”。原因：代码把 PA13、PA14、PA15、PB3、PB4 这几个调试引脚之一配置成了 PWM 输出或普通 GPIO，导致下载器无法再通过 SWD 接口控制芯片。解决：首选方案是在配置引脚时避开启用复用功能的调试引脚。如果已经刷了错误固件，处理方法是用下载器的“连接时复位”功能，把芯片的 NRST 引脚接到调试器，烧录时复位芯片，在程序运行前抢回控制权。实在不行就只能按住复位键点下载，松开的瞬间让工具抢到连接窗口。

6. 进阶一步：编码器速度闭环与直线校准，验收不再靠肉眼

开环小车验收靠“放地上试跑”，跑偏不跑偏全靠感觉。加上编码器之后，可以看实际转速数据，调整也有据可依。这一节给出最小速度闭环和直线校准方法。

6.1 用编码器读速度：定时器编码器模式的配置与读数

带编码器的电机一般会引出 A、B 两相。用定时器的编码器模式可以免去外部中断计数，硬件自动根据相位关系判断正反转并累计计数值。配置时把定时器的两个通道分别映射到编码器 A、B 相。

// 定时器编码器模式初始化 void encoder_tim_init(void) { TIM_Encoder_InitTypeDef sConfig = {0}; sConfig.EncoderMode = TIM_ENCODERMODE_TI12; // 双沿计数 sConfig.IC1Polarity = TIM_ICPOLARITY_RISING; sConfig.IC2Polarity = TIM_ICPOLARITY_RISING; sConfig.IC1Selection = TIM_ICSELECTION_DIRECTTI; sConfig.IC2Selection = TIM_ICSELECTION_DIRECTTI; sConfig.IC1Prescaler = TIM_ICPSC_DIV1; sConfig.IC2Prescaler = TIM_ICPSC_DIV1; sConfig.IC1Filter = 10; // 滤除高频毛刺 sConfig.IC2Filter = 10; HAL_TIM_Encoder_Init(&htim3, &sConfig); HAL_TIM_Encoder_Start(&htim3, TIM_CHANNEL_ALL); } // 读取转速：两次采样间计数值差 = 编码器计数值变化 int32_t encoder_get_count(void) { return (int16_t)__HAL_TIM_GET_COUNTER(&htim3); }

IC1Filter 的取值需要根据电机实际噪声来调，取太大会延迟响应，取太小滤不掉毛刺。通常是试几次，让小车空转时计数不跳变即可。注意这里用int16_t强转是为了处理正反转，编码器计数是带符号的，不能直接用无符号型。

6.2 一个比例控制器让左右轮转速对齐：代码加实测说明

速度闭环不需要一上来就上完整 PID，比例控制就能解决大部分左右轮速差问题。控制周期我习惯设为 50ms，每周期读取一次编码器计数差值，和目标转速做误差运算，再调整 PWM 占空比。

// 简单比例调速：控制周期50ms // speed_target 由遥控速度映射得到 // speed_now 是50ms内编码器计数增量 int32_t err = speed_target - speed_now; // 比例系数过大容易抖动，过小则跟不上目标 float adjust = (float)err * 0.08f; uint16_t base_ccr = map_speed_to_ccr(speed_target, 999, 50); uint16_t ccr = (uint16_t)(base_ccr + adjust); if (ccr > 999) ccr = 999; else if (ccr < 0) ccr = 0; __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, ccr);

比例系数取 0.08 是经验值，具体需要试。把小车架空，如果轮速出现周期性的“加速-减速-加速”振荡，说明系数偏大。如果长时间追不上目标速度，说明系数太小，可以每次加 0.01 往上调。左右轮各跑一个闭环，才是真正解决跑偏问题的做法，开环校准表只能保证特定速度段有效，速度一变又会偏回来。

调试时建议用串口把speed_target、speed_now、ccr三个数值实时回传到电脑，在曲线工具里看响应。数据格式用逗号分隔的一行文本即可，不需要任何上位机协议。看着速度曲线调参数，比靠耳朵听电机的嗡嗡声要直观得多。这也是我给每个做小车的人的第一条建议：把调试数据打出来，别盲调。

这条习惯帮我省了大量试错时间。后来再做类似的项目，我都是先搭好“测量 → 打印 → 调整”的闭环再动执行机构。希望帮到你。

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