简介智能小车仿真工程以STM32F103C6为处理核心面向嵌入式入门与电子设计学习者使用Proteus搭建虚拟电路重点解决无实物条件下的电机控制验证难题可在软件中直观观察前进、后退与转弯效果。压缩包总计155个文件、大小6.08MB包含C/H源码、HEX/AXF编译文件、Proteus仿真工程及MDK-ARM项目配置还保留了多个编译备份与调试辅助文件结构清晰便于按模块查找。已有10226人学习下载工程中两个电机由独立按键控制正反转第三按键通过PWM占空比调节转速配合HAL库定时器与GPIO初始化示例可逐段阅读代码并结合仿真观察电机响应快速理解差速驱动实现方法。通过这套仿真资料读者能提前掌握电机驱动、脉宽调制、中断配置等基础技能减少实物搭建与重复烧录的时间成本为后续智能车或机器人项目积累可复用的设计思路。1. 基于STM32及Proteus智能小车仿真为什么先用仿真再上实车做智能小车最怕的不是代码写不出来而是电路焊到一半发现电机驱动芯片烧了、传感器极性接反了又或者跑起来之后只能看着小车撞墙却不知道是程序逻辑错还是硬件响应慢。基于STM32及Proteus智能小车仿真就是让量产前的翻车成本降到几乎为零在电脑上先把电路画出来把固件跑起来让电机转、传感器读值、逻辑判断全部可视化然后再决定要不要动电烙铁。适合正准备接触STM32的初学者也适合已经在实车调试中反复烧元器件的老手——仿真能帮你把「硬件玄学」和「程序bug」分开避免把时间浪费在无意义的排查上。我在做某课程设计时正是靠这套仿真流程把原本要一周的硬件调试压缩到半天还提前发现了电机驱动供电不足的隐患。2. 仿真小车架构与器件选型STM32最小系统、电机驱动与传感器怎么搭2.1 仿真环境的搭建Proteus版本与库文件常见做法是使用Proteus 8及以上的版本它自带STM32的模型库不需要额外装第三方库。但很多人打开Proteus发现器件列表里搜不到STM32F103原因是安装时没有勾选额外的MCU模型包或者当前工程模式选成了模拟电路模式而非混合电路模式。我一般会新建工程时直接选「Schematic Capture」然后在P2P模式下搜索STM32F103C6或STM32F103C8。如果还是找不到就去安装目录下的Library文件夹查看有没有STM32相关的库文件常见缺失文件是STM32.fet和STM32.IDX。这里有一个关键点Proteus里的STM32模型并不支持所有外设比如某些型号的CAN、USB模型是残缺的。做智能小车最常用的GPIO、定时器、PWM、ADC、外部中断都支持得很好所以选型时别追求高配STM32F103C6这款小封装芯片足够驱动一个双电机小车。选好芯片后要把晶振电路、复位电路、BOOT引脚配置画出来虽然仿真环境里内部时钟可以工作但为了贴近真实板子我建议还是画上8MHz晶振和两个20pF负载电容。复位电路用一个10kΩ电阻和100nF电容即可。2.2 核心器件选型从L298N到直流电机和红外循迹智能小车的动力部分最经典的组合是STM32 L298N驱动芯片 两个直流减速电机。L298N的逻辑电源是5V驱动电源范围是6-12V在Proteus仿真里直接用两个电源端子给它供7.2V。每个通道的ENA/ENB引脚接STM32的定时器输出脚用来做PWM调速IN1~IN4接普通GPIO用来控制正反转。为什么选L298N而不选TB6612因为Proteus自带的电机驱动模型怎么驱动就是怎么工作但L298N模型更成熟不容易出现仿真报错而且它用两个H桥对初学者理解原理更友好。电机模型在Proteus里叫DC Motor需要设置电枢电阻和电感。我通常把电枢电阻设为10Ω电感设为100mH这样仿真时电流变化不会太陡也便于观察PWM调速效果。传感器方面循迹小车最常用的是红外对管TCRT5000Proteus里有对应模型输出是模拟量可以直接接STM32的ADC引脚也可以接比较器电路转成数字量。但注意Proteus里的TCRT5000模型对反射物的距离非常敏感黑色的地面模拟要自己画一块带黑色笔刷的矩形区域否则它永远输出高电平会导致小车无法循迹。2.3 画电路图的思路模块化布局与虚拟终端画原理图不要把所有元件堆在一起否则后面查线非常痛苦。我通常会分三个区域左上角是STM32最小系统左下角是电源和复位右侧是电机驱动和传感器。每一个模块的电源旁都放一个100nF去耦电容Proteus仿真虽然不强制要求但加上去能避免一些莫名其妙的电平抖动。连线时尽量使用网络标签而不是跨页长线比如PB0、PB1、PA0这些引脚名直接标成网络标签再让驱动芯片那边使用同名标签这样连错了也能快速定位。为了调试方便我强烈建议从Proteus的虚拟仪器面板里拉出一个Virtual Terminal接到STM32的USART1发送引脚上。这样代码里用printf打印调试信息仿真运行时就能实时看到。很多人不知道Proteus的虚拟终端是支持ASCII码的USART配置为115200 8N1仿真时直接弹出来效果比实车配合串口助手还直观。调试完再把打印功能注释掉避免影响控制周期。3. 基于STM32的智能小车代码实现从GPIO到PWM调速与循迹逻辑3.1 建立工程固件库/寄存器方式的选择与启动文件代码层面我推荐用标准外设库SPL或寄存器方式。Proteus仿真对代码的编译产物只认HEX文件所以用什么IDE不重要只要最后能生成HEX。我用的是STM32标准外设库加Keil MDK注意在Device面板选择STM32F103C6在Target里勾选微库MicroLIB否则printf重定向时会卡在半主机模式。启动文件选择startup_stm32f10x_md.s这是中等容量产品的启动文件。工程结构上至少要有main.c、stm32f10x_it.c、以及针对电机和传感器单独建模块比如motor.c和sensor.c。初始化代码里最关键的是时钟配置。Proteus的STM32模型默认使用内部RC振荡器如果你的SystemInit把时钟配置成外部8MHz晶振倍频到72MHz但Proteus的晶振模型没有正确设置仿真时程序就会卡死在启动文件的时钟等待循环。我一般会直接使用内部时钟用SystemInit默认配置或者根据Proteus的灵活性在代码里将PLL倍频系数设为自动检测。#include stm32f10x.h #include motor.h #include sensor.h // 延时函数基于SysTick实现精度1ms static void Delay_Ms(uint32_t ms) { SysTick-LOAD 8000 - 1; // 假设SystemCoreClock 8MHz SysTick-VAL 0; SysTick-CTRL 0x5; // 使能SysTick使用HCLK while (ms--) { while (!(SysTick-CTRL (1 16))); // 等待COUNTFLAG置位 } SysTick-CTRL 0; // 关闭计数器 } int main(void) { Motor_GPIO_Init(); // 初始化电机GPIO Sensor_ADC_Init(); // 初始化ADC传感器 USART1_Init(); // 初始化串口调试 while (1) { uint16_t left Sensor_Read(0); // 读取左侧红外值 uint16_t right Sensor_Read(1); // 读取右侧红外值 printf(L%d R%d\r\n, left, right); if (left 2000 right 2000) { // 两边都看到白色背景说明在直道上 Motor_SetSpeed(60, 60); // 双轮同速直行 } else if (left 2000 right 2000) { // 左轮压到黑线右转修正 Motor_SetSpeed(30, 70); } else if (right 2000 left 2000) { // 右轮压到黑线左转修正 Motor_SetSpeed(70, 30); } else { // 两边都压线可能是交叉口直行 Motor_SetSpeed(60, 60); } Delay_Ms(20); // 控制周期20ms } }上面这段代码的要点在于传感器读值采用的是ADC采样返回的值越大代表反射越强。这里的2000阈值不是随手写的要依据你的仿真环境里TCRT5000的输出范围来定一般范围是0~4095黑色线反射系数低输出值通常在1000以下白色地面输出值在2500以上。如果发现小车循线乱窜第一件事就是打印出左右传感器的值看看阈值是不是需要调整。3.2 电机驱动代码PWM输出与方向控制电机控制部分我使用TIM2产生两路PWM通道1控制左电机ENA通道2控制右电机ENB。PWM频率设定为10kHz因为Proteus仿真里直流电机模型如果PWM频率太低电机转速会明显波动频率太高模型附带的电感会让电流还没上升到设定值就要关断导致输出力矩不足。10kHz是在仿真环境里稳定性和响应速度的均衡点。void Motor_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_OCInitTypeDef TIM_OCInitStructure; // 开启时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); // PA0(TIM2_CH1), PA1(TIM2_CH2) 复用推挽输出 GPIO_InitStructure.GPIO_Pin GPIO_Pin_0 | GPIO_Pin_1; GPIO_InitStructure.GPIO_Mode GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); // PB0~PB3 作为方向控制引脚 IN1~IN4 GPIO_InitStructure.GPIO_Pin GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOB, GPIO_InitStructure); // 定时器2时基时钟8MHz分频8计数1000得到10kHz TIM_TimeBaseStructure.TIM_Prescaler 8 - 1; TIM_TimeBaseStructure.TIM_CounterMode TIM_CounterMode_Up; TIM_TimeBaseStructure.TIM_Period 100 - 1; TIM_TimeBaseStructure.TIM_ClockDivision 0; TIM_TimeBaseInit(TIM2, TIM_TimeBaseStructure); // PWM模式1输出极性高 TIM_OCInitStructure.TIM_OCMode TIM_OCMode_PWM1; TIM_OCInitStructure.TIM_OutputState ENABLE; TIM_OCInitStructure.TIM_Pulse 0; TIM_OCInitStructure.TIM_OCPolarity TIM_OCPolarity_High; TIM_OC1Init(TIM2, TIM_OCInitStructure); TIM_OC2Init(TIM2, TIM_OCInitStructure); TIM_Cmd(TIM2, ENABLE); }这段初始化代码中TIM_Prescaler和TIM_Period共同决定了PWM频率。公式是频率时钟/(预分频1)/(自动重装载1)。这里8MHz/8/10010kHz。如果你使用内部RC振荡器实际内部频率可能是8MHz的±2%仿真环境里不用太较真但如果你改成外部晶振72MHz记得把预分频和重装载重新算否则PWM频率就不是10kHz而是90kHz电机模型会直接罢工。方向控制的逻辑很简单IN1高、IN2低时左电机正转IN1低、IN2高时反转IN3/IN4同理。但注意PWM引脚输出的是波形方向引脚输出的是电平两者不要接反。很多人把IN1接到了定时器通道上导致逻辑混乱。我在仿真时吃过这个亏现象是电机转动速度不受占空比控制要么全速要么停止。3.3 循迹传感器读取与阈值判断循迹传感器在仿真里的核心是ADC采样。STM32内置ADC是12位精度我使用ADC1的通道0和通道1分别接红外模块的A0输出。读取时不要用库函数反复初始化否则切换ADC通道时会产生毛刺。正确做法是初始化时设定规则组然后在主循环里切换通道并启动转换等待转换结束后读取结果。uint16_t Sensor_Read(uint8_t ch) { ADC_RegularChannelConfig(ADC1, ch, 1, ADC_SampleTime_239Cycles5); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) RESET); return ADC_GetConversionValue(ADC1); }这个函数每次切换通道都重新配置规则通道。为什么不用DMA在Proteus仿真里DMA和ADC同时使用偶尔会出现仿真速度变慢甚至卡死的现象所以我只做单次转换。每个传感器值读取只需要几微秒主循环20ms的周期足够跑了。值得注意的是ADC_SampleTime_239Cycles5这个参数如果你用的内部时钟频率不准采样时间可能不够导致转换值跳动这时把采样时间拉长到最大的239.5周期几乎能消除所有毛刺。3.4 主循环状态机直行、转弯、停车智能小车不是一直直行就完了它需要根据传感器输入决策动作这本质是一个状态机。上面的示例代码里我只写了最基本的三态判断但实际仿真中你会遇到一个问题小车转弯的幅度很难通过固定PWM差值来保证。因为Proteus仿真里的电机模型没有实际轮胎的摩擦力建模小车的转弯行为是理想化的匹配合适的参数就能跑得很好。我倾向于把动作分成四个状态S_FORWARD直行、S_LEFT左转、S_RIGHT右转、S_STOP停车。状态转移由传感器的组合决定。避免写一长串if-else的原因是要让控制周期稳定状态机结构更便于后期扩展PID算法。停车状态可以设为两个传感器都压到黑线的持续时长超过200ms判定为到达终点这在仿真里很有用因为仿真中黑线区域是相对固定的不会出现实车那样压线抖动。状态机的转换频率很重要。如果每20ms判断一次在穿过直角弯时会有可能因为传感器跨过线的时机恰好落在两次采样之间而漏判。我建议把控制周期缩短到10ms同时把延时函数改成非阻塞的SysTick计时这样主循环还能腾出时间做其他事情。4. Proteus仿真运行与调试加载固件、虚拟示波器与实时调参4.1 将编译后的hex文件加载到Proteus用Keil编译工程后在Output选项卡里打开Create HEX File选项编译通过后会生成一个.hex文件。然后在Proteus里双击STM32芯片在Program File一栏选择该hex文件。注意配置文件里的Crystal Frequency要填写你实际使用的晶振频率如果不确定先填8MHz。很多人忽略了Processor Clock频率如果这里设了72MHz但代码里用内部RC那么UART波特率计算就会错虚拟终端显示乱码。加载hex文件后点击运行按钮。如果代码有语法或逻辑问题Proteus的仿真不会崩溃而是芯片引脚没有输出。这时候最容易踩的坑是你以为程序没烧进去其实是芯片没有执行到main函数。解决办法是在代码启动文件里设置一个断点Proteus不支持单步调STM32的调试模式但你可以在main函数入口处用GPIO翻转来确认执行路径。4.2 使用虚拟终端和示波器监控PWM与传感器信号确认程序运行的第一件事是看虚拟终端有没有打印数据。如果虚拟终端没有任何输出先检查USART1的TX引脚是否接到了终端的RXD上共地是必须的。还有就是波特率设置Proteus虚拟终端默认波特率是9600如果你代码里配置了115200必须在终端属性里改过来。一个非常实用的技巧是把虚拟示波器Virtual Oscilloscope的探针夹在PD0和PD1上用来观测PWM波形。示波器的触发方式选AutoY轴增益调到2V/Div时基调到100us/Div能清晰看到PWM的占空比变化。不过虚拟示波器在Proteus里只支持模拟信号而STM32的PWM是数字信号你需要加一个简单的RC低通滤波器网络把PWM转换成模拟电压。我通常在示波器探头前加一个10kΩ电阻和1uF电容到地这样能看到占空比对应的平均电压值非常直观。如果不加这个滤波器示波器上显示的就是满幅方波看不出占空比差异。4.3 仿真速度与真实时序的差别时钟配置的秘密Proteus仿真STM32有一个很玄学的现象仿真界面里小车跑得飞快一秒就冲出赛道但你在代码里明明延时了10ms。原因是Proteus的仿真步长是动态的它不会严格按真实时间模拟每一条指令而是以「状态更新」为单位推进。如果你的控制循环依赖延时函数的绝对时间那么在仿真里可能比真实时间快几十倍这会导致小车的行为不可预测。解决办法是不要依赖裸延时来做控制周期。你应该使用定时器中断来产生一个固定的时间基准比如用TIM4产生1ms中断在中断里做传感器采样和电机控制。这样做的好处是无论Proteus仿真步长如何变化只要中断优先级正确控制动作的先后顺序是稳定的。仿真环境里还有一个技巧在Proteus的「System」菜单里选择「Set Animation Options」把Simulation Speed调到「Real Time」这样仿真尽量贴近真实时间步长但代价是仿真速度变慢复杂电路会卡。我建议先用全速仿真调逻辑再用Real Time仿真做最终验收。5. 智能小车仿真避坑指南5个让我翻车的典型问题5.1 现象小车原地打转或越走越偏原因PWM频率与占空比设置不合理我调试模拟项目X时小车在直道上行驶不到半秒就开始向右转无论怎么调整左右轮速度都偏。用示波器看两路PWM波形发现占空比相同但电机模型的响应速度不同。原因是左电机和右电机模型参数不一致比如电枢电阻一个设了10Ω另一个设了20Ω电流差异导致输出转矩不同。解决方法是先验证电机对称性给两个电机完全相同PWM占空比用虚拟转速表观察两个电机的转速波形把电枢电阻、电感参数调成一致。如果参数一致还是偏那就是PWM频率太低导致电机响应非线性。把频率从1kHz调到10kHz后两个电机的转速曲线基本重合。5.2 现象电机不转但代码逻辑正确原因Proteus电机模型驱动电压不足某次我把L298N逻辑电源引脚接了3.3V导致芯片内部逻辑电路和驱动输出之间电压转换出问题。电机模型需要的是驱动级电压而L298N的VS引脚接了5V把电机阳极电压拉得太低。现象是程序运行后电机端子电压只有0.8V根本带不动电机。解决方法是把L298N的VS接到12V电源VSS接5V并且给两个电机电源之间加一个100uF电容。在Proteus里电容的ESR模型默认值会影响电源轨的瞬态响应加了电容后电机启动电流大时电压纹波会明显减小。另外还有一种情况电机模型的“Motor Terminal”端子接反了正负极互换看起来是转的但方向反了循迹逻辑跟着全错。5.3 现象传感器读数乱跳原因ADC参考电压与红外模型输出范围不匹配我在循迹时发现虚拟终端打印的ADC值在黑色区域和高光区域都是4000左右完全没有区分度。检查后发现红外对管模型的输出电压在5V下才能体现反射差异而我在ADC_Ctair里配置的参考电压是3.3V直接把5V传感器的输出电压截断了。解决方法是给TCRT5000输出脚加一个电阻分压网络把输出范围映射到0~3.3V或者在Proteus里选中红外模型将其属性中的Voltage设定改为3.3V兼容。我后来用了一个更简单的方案把红外模型的输出当作数字量使用将其输出端接到STM32的输入捕获引脚用高低电平判断。这样避开ADC参考电压的坑但是精度丢失在高速过弯时可能误判。5.4 现象程序卡死在启动文件原因时钟初始化与仿真器PLL设置A同学在其他群里问过为什么同样的代码在开发板上跑得好好的放到Proteus就卡死不动。我打开他的工程发现他用了外部晶振并开启了PLL到72MHz但Proteus里的晶振模型频率没有设置默认是1MHz。然后SystemInit里等待HSE就绪的循环永远超时程序就停在启动文件的SystemInit调用里出不来。解决办法有两种一是干脆不用外部晶振在SystemInit里就把SYSCLK设为内部8MHz关闭PLL二是在Proteus芯片属性里把Crystal Frequency改成8MHz并把代码里的PLL参数改回来。我推荐新手用第一种因为仿真毕竟看的是逻辑不是精确时序等以后上实车再调时钟。5.5 现象hex加载后无反应原因芯片型号与项目配置不匹配我遇到过一种情况Keil里选的是STM32F103ZE大队列芯片而Proteus里用STM32F103C6两者Flash和RAM容量不同。Keil生成hex时是按ZE的地址布局分配变量和中断向量表的加载到C6上虽然大多数地址能对上但ADC或定时器外设的基地址可能不同导致外设寄存器写错了地方。解决方法是让Keil的Device型号和Proteus里的芯片严格一致。如果找不到完全相同的型号至少确保是同一系列、同一个中等容量子系列。还有一个容易忽略的项目配置项记得在C选项里把Block RAM起始地址设为0x20000000如果编译时默认设为0在所有外设初始化之前就会产生内存访问错误。6. 把仿真小车玩出花多传感器融合与PID循迹的仿真验证6.1 加入超声波避障模块仿真中的逻辑与实车差距Proteus里有超声波传感器模型HC-SR04它有一个TRIG引脚和ECHO引脚。发送一串10us的高电平给TRIG然后等待ECHO脉冲的宽度来换算距离。在Proteus里操作时要注意发射方向逻辑上距离测量是一个简化的时间窗口不会像实车那样有超声波束和障碍物反射面的锥形效应。所以仿真中测距精准但实车会有环境干扰这个差距要心里有数。我把超声波的ECHO引脚接到STM32的定时器输入捕获通道上通过捕获两次上升沿之间的脉冲周期来计算距离。在普通循迹的基础上加一个优先级更高的避障状态当距离小于20cm时优先执行停车或绕行而不是继续循迹。这个逻辑在Proteus里跑通了不代表实车一定行但至少验证了多传感器协调的状态机结构是对的。6.2 PID循迹在Proteus里调参数比实车更高效单靠阈值判断循迹在小车速度稍高时就会冲出赛道因为传感器的输出是连续量而阈值判断把它变成了离散量。我换了一种方案用左右传感器读值的差作为误差信号通过PID控制器实时调整左右轮PWM差。float error (float)(left_value - right_value); float P 0.02f; float I 0.001f; static float integral 0.0f; float D 0.01f; static float last_error 0.0f; integral error; float derivative error - last_error; int speed_adjust (int)(P * error I * integral D * derivative); last_error error; if (speed_adjust 30) speed_adjust 30; if (speed_adjust -30) speed_adjust -30; Motor_SetSpeed(60 - speed_adjust, 60 speed_adjust);这段代码里speed_adjust是左侧电机PWM的修正量右电机反向修正。为什么限幅30因为PWM基础值是60修正量过大时一侧电机占空比会到90以上会超出线性调压区域。Proteus里调PID参数非常方便你改完参数重新编译加载hex到仿真里跑一圈比实车换参数插拔下载器快得多。我一般是先设P让它能沿着线走但震荡再加一点点D消除震荡最后加I来消除稳态偏差。这个流程在仿真里一小时内就能跑出可用的参数组合而实车至少要半天。6.3 用虚拟逻辑分析仪验证控制周期最后一个技巧Proteus里自带的虚拟逻辑分析仪Virtual Logic Analyzer可以接数字引脚同时观察多个信号的时间关系。我在GPIOB5上做了一个周期翻转信号在每次控制周期开始时取反。接上逻辑分析仪后可以精确测量控制周期是否保持在10ms左右以及PWM更新是否在同一周期内完成。这个验证特别关键因为智能小车的实时性要求高如果控制周期被串口打印或传感器转换拖到30ms小车过弯时就会反应迟钝。我在仿真中发现使用USART的printf会在关闭中断时占用较长CPU时间导致定时器中断被延迟于是把调试打印改为放在主循环的空闲时间而不在中断里打印。逻辑分析仪清晰显示出了中断响应时间从原先的最大1.2ms降到了0.3ms。最后说点教训当年我第一次做智能小车直接买元器件焊板子结果电机驱动烧了两次红外对管极性接反四次总共花了三周才让车真正跑起来。后来改用Proteus仿真先行所有电路验证和调参都在电脑上完成实车第一次点火就能正常走线那种感觉简直像吃了后悔药。现在我的习惯是无论多简单的单片机项目先在Proteus里跑通再考虑动电烙铁。仿真不是代替实车调试而是把90%的低级错误拦在前面。希望这个方案对你也能有同样的帮助。本文还有配套的精品资源点击获取