STM32+Proteus智能小车仿真：PWM调速与电机控制实战

简介：这份资源面向嵌入式初学者与电子工程相关专业学生，提供一套基于STM32F103C6与Proteus的智能小车仿真工程，用于在无实物硬件的情况下验证电机控制代码与电路设计。项目通过按键控制两个直流电机的正反转，并借助PWM调节转速，实现小车前进、后退、转弯与加减速，涵盖嵌入式编程、电机驱动与硬件仿真等知识点。压缩包共155个文件、约6.08MB，以C源文件与头文件、Keil MDK-ARM工程文件、Proteus工程及编译产物为主，另含HAL库驱动、HEX固件与工程备份，目录结构完整，可直接打开仿真与调试。已有10236人学习下载，适合作为STM32入门实践与课程设计的参考范例，帮助读者理解外设配置、PWM调速逻辑及软硬件联调思路，为后续机器人项目打下基础。

1. 从“代码能跑但车不动”说起：这套 STM32 + Proteus 智能小车仿真到底解决什么问题

很多同学做智能小车，第一步就卡在硬件上：电机驱动模块买回来焊好，上电一跑，轮子要么不转，要么只往一个方向转，调了两天发现是 PWM 通道映射错了。更麻烦的是，板子烧了、电机堵转、电池没电，这些物理故障排查起来成本极高。这套基于 STM32 和 Proteus 的智能小车仿真方案，核心价值就是把“硬件调试”前移到“软件仿真”阶段——在 Proteus 里把电机、传感器、驱动芯片全部虚拟化，代码先在仿真环境里跑通逻辑，再上真实硬件。它适合正在做嵌入式课程设计、毕业设计的学生，也适合需要快速验证电机控制逻辑的从业者。关键词 stm32、电机、proteus、仿真、智能小车，本质上对应的是“控制算法 + 虚拟外设 + 可视化验证”这条完整链路。

2. 需求拆解与技术选型：为什么是 STM32 + Proteus 而不是别的组合

2.1 功能需求先立住：小车到底要跑出哪几种行为

做任何仿真项目，第一步不是打开软件，而是把“车要干什么”写成可验收的条目。这套方案里，智能小车的核心行为通常拆成四类：直行、后退、左转、右转，进阶一点加上调速和循迹。直行和后退考验的是双电机同向驱动的对称性，左右转考验的是差速控制——一侧正转、一侧反转或停转。调速则要求 PWM 占空比可调，循迹需要红外传感器反馈参与决策。

我一般会把这些行为写成一张行为-引脚-预期表，先不写代码，先把“哪个行为对应哪组引脚电平”定死。比如左轮电机接 TIM 的哪个通道、右轮接哪个通道，方向控制引脚是高电平正转还是低电平正转。这张表定不下来，后面代码写得再漂亮也是玄学。很多翻车案例的根源就是行为定义模糊，仿真里看着轮子转了，实际方向是反的，上硬件才发现。

从验收角度，每个行为都要有明确的观察指标：轮子转向、转速快慢、停止是否彻底。仿真环境的好处是这些指标可以直接在 Proteus 的电机模型上看转速和方向，不用拿手去摸轮子。

2.2 技术选型对比：STM32 仿真和 51 仿真差在哪

市面上单片机仿真方案不少，51 + Proteus 是最常见的入门组合，但为什么这套方案选 STM32？原因很实际：STM32 的定时器资源更丰富，一个通用定时器就能输出多路互补 PWM，做双电机差速控制时通道够用；而 51 的定时器数量有限，做两路独立 PWM 往往要软件模拟，仿真里时序容易失真。另外 STM32 的 GPIO 复用功能清晰，方向控制和 PWM 输出可以分到不同端口，代码结构更干净。

Proteus 这边，关键是要确认元件库里有对应的 STM32 模型和电机驱动模型。通常的做法是选一个通用 L298N 驱动模型加两个直流电机模型，STM32 选一个引脚数够用的型号即可，不必追求和实物完全同型号——仿真验证的是控制逻辑，不是芯片本身。这里有个血泪经验：Proteus 里 STM32 模型的时钟配置要和代码里的系统时钟初始化对上，否则 PWM 频率会偏得离谱，电机转速看着就不对劲。

提示：选型阶段就把“仿真能验证什么、不能验证什么”写清楚。仿真能验证引脚逻辑、PWM 占空比、状态机切换；不能验证真实电流、电机堵转、电源波动。别指望仿真替代全部硬件测试。

2.3 开发环境与仿真环境的边界划分

这套方案里，代码开发和仿真验证是两条并行但交汇的线。代码在 Keil 或 STM32CubeIDE 里写，编译出 hex 文件；Proteus 负责加载 hex、虚拟外设、可视化运行。边界在于：所有和“物理量”相关的参数（比如电机启动电压、PWM 频率）在仿真里用理想值，在代码里留成宏定义，方便上硬件时改。

我一般会把电机控制相关的宏单独放一个头文件，比如MOTOR_PWM_FREQ、LEFT_FORWARD_PIN这类，仿真和实物共用一套逻辑，只改宏。这样仿真跑通后，换硬件只需要改引脚定义和频率参数，控制流程一行不动。这个习惯能省掉大量“仿真对了实物不对”的排查时间。

3. 总体架构设计：三层结构与四个模块的职责划分

3.1 分层思路：应用层、控制层、驱动层各管什么

这套小车的软件架构按三层划分，目的是让“想干什么”和“怎么让电机转”彻底分开。应用层负责行为决策，比如收到“左转”指令后决定左右轮的目标状态；控制层负责把目标状态翻译成 PWM 占空比和方向电平；驱动层直接操作寄存器和定时器，输出波形。

这样分的好处是，循迹逻辑以后要加，只动应用层；换电机驱动芯片，只动驱动层。中间控制层保持稳定。很多同学把所有逻辑塞进 main 的 while 循环里，加一个功能就牵一发动全身，最后自己都看不懂。分层不是为了好看，是为了改需求时不崩溃。

四个核心模块分别是：电机驱动模块、PWM 调速模块、方向控制模块、行为调度模块。前三个属于控制层和驱动层，最后一个属于应用层。模块之间通过函数接口通信，不直接互相改全局变量。

3.2 模块职责与接口约定

电机驱动模块对外只暴露两个函数：初始化Motor_Init()和设置单侧电机状态Motor_Set(side, dir, duty)。side 区分左右，dir 区分正反转和停止，duty 是 0 到 100 的占空比。PWM 调速模块内部管理定时器通道，对外只给“设置某通道占空比”的接口。方向控制模块管理 GPIO，对外给“设置某侧方向”的接口。行为调度模块根据当前指令调用这些接口。

接口约定的关键是参数范围要卡死。duty 超过 100 要截断，dir 只接受枚举值，side 只接受左右。这些检查放在接口入口，仿真阶段就能暴露调用错误，而不是等电机乱转再回头找。我见过太多项目因为一个越界的占空比参数，仿真里电机直接不转，查了半天以为是定时器配置问题。

3.3 数据流：从指令到轮子转动的完整链路

一次“左转”指令的完整数据流是这样的：行为调度模块收到左转请求，计算出左轮反转、右轮正转，各自的目标占空比比如 60%；调用Motor_Set(LEFT, REVERSE, 60)和Motor_Set(RIGHT, FORWARD, 60)；电机驱动模块先设置方向 GPIO，再调用 PWM 模块设置对应通道占空比；PWM 模块写定时器比较寄存器；Proteus 里的电机模型根据引脚电平和 PWM 波形改变转速和方向。

这条链路里任何一环参数错了，现象都能在仿真里直接看到：方向反了看轮子转向，转速不对看占空比，完全不转看定时器是否使能。数据流清晰，排查就有路径，不用靠猜。

4. 关键模块实现：PWM 调速、方向控制与行为调度的代码落地

4.1 PWM 调速模块：定时器通道配置与占空比映射

PWM 是电机调速的核心，STM32 上通常用通用定时器的输出比较模式。下面这段初始化代码以某个通用定时器为例，配置两个通道输出 PWM，频率和占空比分辨率按电机驱动的常见需求设定。

// PWM 初始化：定时器计数频率 72MHz，预分频后 1MHz，周期 1000 -> 1kHz PWM void PWM_Init(void) { // 使能定时器和 GPIO 时钟（略，按实际端口补） TIM_TimeBaseInitTypeDef tim; tim.TIM_Prescaler = 71; // 72MHz / (71+1) = 1MHz 计数频率 tim.TIM_Period = 999; // 1MHz / 1000 = 1kHz PWM 频率 tim.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM3, &tim); TIM_OCInitTypeDef oc; oc.TIM_OCMode = TIM_OCMode_PWM1; oc.TIM_OutputState = TIM_OutputState_Enable; oc.TIM_Pulse = 0; // 初始占空比 0 oc.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1Init(TIM3, &oc); // 左轮通道 TIM_OC2Init(TIM3, &oc); // 右轮通道 TIM_Cmd(TIM3, ENABLE); } // 设置占空比，duty 范围 0~100 void PWM_SetDuty(uint8_t channel, uint8_t duty) { if (duty > 100) duty = 100; // 入口截断，防止越界 uint16_t pulse = duty * 10; // 周期 1000，100% 对应 1000 if (channel == 0) TIM_SetCompare1(TIM3, pulse); else TIM_SetCompare2(TIM3, pulse); }

这段代码的关键参数是预分频和周期：72MHz 经 71 分频得到 1MHz 计数频率，周期 999 对应 1kHz PWM。1kHz 对直流电机驱动是常见值，太低会有可听噪声，太高部分驱动芯片响应跟不上。占空比映射用duty * 10，因为周期是 1000，100% 对应比较值 1000。入口的截断检查是后悔药，防止上层传错参数导致比较值溢出。

仿真里验证这段代码，看的是 Proteus 电机模型上的转速是否随 duty 线性变化。如果 duty 从 0 加到 100 电机转速不变，先查定时器是否真的使能、通道是否配置成 PWM 模式，而不是怀疑电机模型。

4.2 方向控制模块：GPIO 电平与电机正反转的对应关系

方向控制比 PWM 简单，但最容易翻车。L298N 这类驱动芯片，每个电机有两个方向控制引脚，一高一低正转，一低一高反转，两个都低是停止。代码里要把这个真值表写死，并且和接线一一对应。

typedef enum { MOTOR_STOP = 0, MOTOR_FORWARD, MOTOR_REVERSE } MotorDir; // 设置单侧电机方向，side: 0 左 1 右 void Motor_SetDir(uint8_t side, MotorDir dir) { if (side == 0) { switch (dir) { case MOTOR_FORWARD: GPIO_SetBits(GPIOA, GPIO_Pin_0); GPIO_ResetBits(GPIOA, GPIO_Pin_1); break; case MOTOR_REVERSE: GPIO_ResetBits(GPIOA, GPIO_Pin_0); GPIO_SetBits(GPIOA, GPIO_Pin_1); break; default: GPIO_ResetBits(GPIOA, GPIO_Pin_0); GPIO_ResetBits(GPIOA, GPIO_Pin_1); break; } } else { // 右轮同理，换端口和引脚 } }

这段代码的设计说明只有一句：真值表必须和 Proteus 里的接线完全一致。仿真里如果左转变成右转，八成是某一侧的 FORWARD 和 REVERSE 电平写反了，或者 Proteus 里电机模型的接线极性接反了。排查方法很直接：单独给一侧发正转指令，看轮子转向，再对照真值表。

注意：方向切换前先把占空比降到 0，再改方向，最后恢复占空比。直接带载换向在仿真里可能看不出问题，但上硬件会冲击驱动芯片。这个习惯从仿真阶段就养成。

4.3 行为调度模块：直行、转向、停止的状态机写法

行为调度用简单的状态机就够了，不需要上 RTOS。每个行为对应一个状态，状态里设置左右轮的目标方向和占空比，然后等下一个指令。

typedef enum { ACT_STOP, ACT_FORWARD, ACT_BACKWARD, ACT_TURN_LEFT, ACT_TURN_RIGHT } Action; void Action_Execute(Action act) { switch (act) { case ACT_FORWARD: Motor_SetDir(0, MOTOR_FORWARD); Motor_SetDir(1, MOTOR_FORWARD); PWM_SetDuty(0, 60); PWM_SetDuty(1, 60); break; case ACT_TURN_LEFT: Motor_SetDir(0, MOTOR_REVERSE); Motor_SetDir(1, MOTOR_FORWARD); PWM_SetDuty(0, 50); PWM_SetDuty(1, 50); break; case ACT_STOP: PWM_SetDuty(0, 0); PWM_SetDuty(1, 0); Motor_SetDir(0, MOTOR_STOP); Motor_SetDir(1, MOTOR_STOP); break; default: break; } }

左转用左轮反转、右轮正转的差速方式，占空比给 50% 是为了转向平缓，直行给 60% 是常用巡航速度。这些数值不是死的，仿真里可以调，调到轮子转向看起来自然为止。状态机的价值在于每个行为是独立的，加一个“原地旋转”只是多一个 case，不影响已有逻辑。

4.4 Proteus 侧配置：元件选取、接线与 hex 加载

Proteus 这边的配置步骤决定仿真能不能跑起来。通常的做法是：从元件库取一个 STM32 模型、一个 L298N 驱动模型、两个直流电机模型，按原理图接线，把编译出的 hex 文件加载到 STM32 模型的程序属性里，设置好时钟频率，然后运行。

接线时特别注意两点：一是 STM32 的 PWM 输出引脚要接到 L298N 的使能端，方向引脚接到输入控制端；二是电机模型的电源和地要接对，否则轮子不转但代码没错，容易误判。hex 加载路径不要有中文，这是 Proteus 的老毛病，路径带中文有时加载失败还不报错。

仿真运行后，先测直行，再测转向，最后测停止。每个行为单独验证，不要一上来就跑复杂序列。出问题时按“代码逻辑 → 引脚映射 → Proteus 接线 → 模型参数”的顺序查，这个顺序能覆盖绝大多数翻车场景。

5. 避坑与常见问题排查：仿真跑不通时先看这五条

5.1 电机完全不转，但代码编译通过

现象是仿真运行后两个轮子纹丝不动，代码没有报错。原因通常有三个：定时器没使能、PWM 通道没配置成输出比较模式、或者 Proteus 里 hex 没加载成功。解决方法是先在代码里加一个 GPIO 翻转做心跳，用示波器虚拟仪器看有没有波形；再确认TIM_Cmd被调用；最后检查 Proteus 模型属性里的 hex 路径。我一般会先看心跳，心跳没有就是程序没跑起来，和电机无关。

5.2 轮子转向和预期相反

现象是发直行指令，一个轮子正转一个反转，车原地打转。原因是某一侧的方向真值表写反，或者 Proteus 里电机模型接线极性接反。解决方法是单独给每侧发正转指令，观察转向，对照代码里的 GPIO 设置。如果是模型接线问题，调换模型的两个输入端即可，不用改代码。这个坑很常见，因为仿真模型和实物驱动的极性定义不一定一致。

5.3 PWM 调速无效，占空比改了转速不变

现象是 duty 从 10 改到 90，轮子转速看起来一样。原因多半是 PWM 频率和电机模型不匹配，或者比较寄存器写错了通道。解决方法是先用虚拟示波器看 PWM 引脚波形，确认占空比真的在变；如果波形对但转速不变，检查 Proteus 电机模型是否支持 PWM 调速，有些简化模型只认电平不认占空比。换一个支持调速的电机模型通常能解决。

5.4 仿真运行卡顿或直接崩溃

现象是点运行后 Proteus 无响应，或者跑几秒就停。原因是仿真步长设置太小、模型太多、或者代码里有死循环没有喂看门狗（仿真里看门狗行为可能异常）。解决方法是在 Proteus 的仿真设置里适当放大步长，减少不必要的虚拟仪器，代码里避免在中断里做长延时。血泪经验是：仿真不是越精细越好，能验证逻辑就行，步长太小反而跑不动。

5.5 上硬件后行为和仿真不一致

现象是仿真里一切正常，烧到实物上电机抖动、方向乱、转速不对。原因是仿真用的是理想电源和理想电机，实物有压降、有惯性、有干扰。解决方法是把仿真里验证过的逻辑保留，参数重新整定：PWM 频率按实际驱动芯片手册调，占空比起步值降低，方向切换加死区延时。仿真负责逻辑正确，实物负责参数整定，两者分工要清楚。

6. 验收与答辩：怎么证明这套仿真方案真的跑通了

验收这套方案，不能只说“仿真能跑”，要拿出可复现的证据链。我一般按三步走：第一步，行为覆盖测试，把直行、后退、左转、右转、停止五个行为逐个运行，每个行为录一段仿真画面，记录左右轮转向和相对转速；第二步，参数边界测试，把占空比设成 0、50、100 三档，确认转速单调变化且 0 档彻底停止；第三步，异常输入测试，给一个越界占空比或非法方向值，确认接口截断生效、电机不出现异常动作。

答辩时最容易被问的是“仿真和实物差距怎么处理”。回答要具体：仿真验证的是引脚逻辑、PWM 占空比映射、状态机切换顺序；实物阶段需要重新整定的是 PWM 频率、启动占空比下限、换向死区时间。把这两类参数分开讲，评委能看出你清楚边界在哪。另一个高频问题是“为什么不用硬件直接调”，答案就是开头说的：硬件故障排查成本高，仿真把逻辑错误提前暴露，上硬件只调物理参数，效率完全不同。

下面这张表可以直接放进答辩 PPT 的验收页，把每个行为的观察点和通过标准列清楚。

最后说一个习惯：从那以后我每次做仿真项目，都强制先写行为-引脚-预期表，再动手接线写代码，验收时按表逐项打勾。这张表看着笨，但能挡住八成“跑起来了但不知道对不对”的情况。希望帮到你。

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