很多想入门 STM32 的朋友第一反应都是先买一块开发板。这话本身没毛病但我见过太多人栽在“板子到手之后”烧录器驱动装不上、照着视频敲了两天代码点灯没反应、不知道是硬件坏了还是代码错了最后只能让板子吃灰。我自己也经历过这个阶段所以后来干脆把入门路线做成了一套“纯软件”版本——不买板、不焊接、不花钱直接用仿真环境把 GPIO、串口、定时器、ADC 这些外设一个个跑通。这篇文章就把这套方案完整拆开怎么选仿真工具、怎么搭环境、每个外设怎么在仿真里跑、哪些坑只有仿真里才有以及仿真学完之后怎么丝滑过渡到真板子。如果你是一个零基础想入门 STM32 的学生、想低成本验证方案的硬件工程师或者还在犹豫要不要入坑嵌入式的小白这篇内容都是照着做就能复现的实操记录不是泛泛而谈的科普。1. 为什么我会想到用“纯软件”学 STM321.1 一个真实的学习困境先说我自己踩过的经历。我是从 Arduino 转到 STM32 的最初的想法很简单STM32 功能强、资源多、价格也不算离谱买一块最小系统板也就几十块钱。结果下单之后问题一个接一个。板子到手没法第一时间开搞因为电脑上还缺驱动装好驱动之后烧录器识别不到芯片好不容易能烧录了第一段点灯代码却怎么都不亮。我在网上查了两天有人说晶振没起振有人说 Boot 跳线帽没接对还有人说开发板出厂就有问题。后来我发现这些问题里有一大半跟“硬件环境”相关供电不稳、引脚接触不良、焊接虚焊、晶振起振条件不对。而我想学的其实是“怎么用 STM32 控制外设”这件事却被硬件折腾得筋疲力尽。更别提如果代码里同时涉及 MCU 和外设出了问题到底是软件时序不对还是硬件连接错误排查起来非常痛苦。这让我意识到对入门阶段的人来说最大的阻碍往往不是“STM32 难学”而是“硬件环境的不确定性”拉高了学习门槛。那为什么不先在一个完全可控的软件环境里把外设用法、寄存器流程、HAL 库函数这些核心知识跑通再上真板子呢1.2 “纯软件”方案到底解决什么问题我这套纯软件方案解决的是三件事成本、快速迭代和可观测性。成本不用多说仿真环境最大的优势就是不花钱。不过很多人忽视的是后面两点。拿“快速迭代”来说在真板子上改一次代码要经历编译、烧录、复位、观察这一套流程一分钟算快的。但在仿真里改完代码直接重新编译、点一下运行整个过程十几秒而且不需要反复插拔 USB。我有一次调试 PWM 频率半小时内改了十几次分频参数放到真板子上至少得折腾一整个晚上。“可观测性”则是我认为仿真最值钱的地方。真板子上你想看某个引脚的波形得有示波器想确认定时器计数器的实时值只能暂停在调试器里翻寄存器。而在仿真工具里GPIO 状态、外设寄存器、总线时序、波形图都是直接可视化呈现的。你甚至可以故意把两个引脚短接看看逻辑冲突会怎么表现——这种事情在真板子上一般是“啪”一声冒烟仿真里只是改个状态而已。这套方案适合的人群也很明确零基础准备入门的学生、想要低成本验证某段外设代码逻辑的工程师、以及纯粹好奇 STM32 但还没决定要不要买板子的小白。当然我也得先泼一盆冷水仿真毕竟不是真板子后面我会专门讲它替代不了什么但作为“入门”和“外设理解”这两个目标它完全够用。2. 仿真方案怎么选四条路线的横向对比很多人听到“STM32 仿真”第一反应是 Proteus。确实Proteus 是老牌 EDA 工具画个电路、放个 STM32、接个 LED跑起来非常直观。但“仿真跑通外设”这件事市面上其实有好几条路线各有各的脾气选错路会走很多弯路。我先把我实测过的方案整理成一张对比表再逐条分析。方案上手难度外设可视化与真实代码的贴近度适合场景Keil MDK 内置仿真器低中寄存器/逻辑分析仪高直接编译烧录的同一套代码纯代码逻辑学习Proteus 电路仿真中高电路图/示波器/虚拟终端高跑的是编译好的 hex外设电路连接的学习Wokwi 网页仿真低中组件图串口终端中Arduino/仿真器框架快速验证小段代码QEMU/Renode高低命令行外设高裸机最真实嵌入式系统级调试2.1 Keil MDK 内置仿真器为什么我把它当作主力先说我最常用的组合。Keil MDK 本身自带了面向 ARM Cortex-M 内核的模拟器不需要任何外部硬件就能直接以 Debug 模式运行 STM32 程序。它的优势在于仿真环境里跑的二进制就是你最终要烧录到真板子上的同一个工程工具链、启动文件、链接脚本完全一致唯一的差别只是 CPU 执行方式是从模拟器执行而不是真实芯片执行。这意味着你在仿真里调通的逻辑移植到真板子上几乎不会因为“代码版本不同”而出问题。Keil 仿真器对 STM32F103 系列的支持尤其成熟GPIO、USART、TIM、ADC 这些外设都有对应的寄存器视图和调试窗口。比如你可以打开 Peripherals → GPIO 面板实时看到每个引脚是输入还是输出、电平是高还是低打开 Serial Window就能看到虚拟串口打印的内容。再加上断点、单步、观察窗口这些传统调试手段学外设的时候非常顺手。2.2 那其他方案什么时候用Proteus 的价值在于“电路”层面。Keil 仿真只能看到寄存器数值看不到“一个 LED 是不是真的会亮”。Proteus 里你可以把 STM32、电阻、LED、按键、电位器这些元件放在一张电路图上用 .hex 文件加载程序然后看到 LED 真的在闪、示波器真的在画波形。我的建议是Keil 仿真用来学“代码怎么写”Proteus 用来学“引脚该连到哪里”。Wokwi 是一个网页版的电路仿真开箱即用浏览器一开就能拖一个 STM32F103 出来。它上手比 Proteus 更快适合在别人电脑上演示、或者临时验证一段传感器代码。但它对 STM32 的支持没有 F103 之外那么完善代码框架也偏向 Arduino 风格如果你以后要走 HAL 库路线Wokwi 只能当辅助。至于 QEMU 和 Renode我个人认为入门阶段真的不建议碰。它们面向的是嵌入式系统开发、操作系统移植、自动化测试这类场景需要手动搭建工具链、处理命令行仿真参数外设模拟也不直观。入门学外设用它们纯粹是给自己加难度。2.3 我最终选定的组合与环境搭建步骤综合下来我最终采用的组合是STM32CubeMX 生成初始化工程 Keil MDK 编译与内置仿真 Proteus 按需做电路级验证。三个工具各司其职CubeMX 帮我快速配置时钟和外设生成标准的 HAL 库代码Keil 负责编译、调试、逻辑分析Proteus 只有在需要看“外设真实连接效果”时才出场。搭建步骤我整理成清单照着做就行安装 Keil MDK版本无所谓只要包含 ARM Compiler 5 或 6 之一即可评估版功能就够用。安装 STM32CubeMX安装时它会自动识别 Keil 的安装路径这样生成的工程可以直接用 Keil 打开。在 CubeMX 里新建工程选芯片型号。建议选 STM32F103C8T6资源够多、资料全网最全。配置时钟树HSE 选外部晶振频率填 8MHz然后让系统时钟跑到 72MHz。仿真环境中 HSE 的起振过程可能不完全模拟但 72MHz 这个主频模拟器能正确执行。先用默认配置生成一个最小工程在 Keil 里编译一次确认没有报错。Keil 进入仿真模式Options for Target → Debug 页把 Use Simulator 勾上Dialogue 里选 STM32F103C8然后点击 Debug 按钮进入仿真环境。到这一步你的“纯软件”开发环境就搭好了。后面每一个外设的验证都从这个模板工程出发。3. 第一个外设GPIO 点灯在仿真里究竟怎么“亮”3.1 用 CubeMX 配置 GPIO 的完整过程点灯是所有嵌入式教学的第一个程序仿真里也一样。我用 CubeMX 配置的最小流程是选择 STM32F103C8T6 → System Core 里选 GPIO把 PA5 设为 GPIO_Output默认推挽输出、无上下拉然后到 Clock Configuration 里保证 PLLCLK 后主频是 72MHz最后 Project Manager 里给你的工程起名、选择 MDK-ARM 工具链、生成代码。生成完代码后打开 main.c 的 main 函数在 while(1) 循环里加上点灯逻辑。HAL 库写法很简单while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(500); }这里有一个非常关键的点HAL_Delay 依赖 SysTick 中断。仿真器会模拟 SysTick所以这个延时函数在仿真里能正常工作。如果你发现仿真里 HAL_Delay 不生效或者时间不对第一件事不是查代码而是去 Keil 的 Options for Target → Target 页确认晶振频率和仿真器配置一致。3.2 仿真点灯和真实板子的差异哪些“看起来正常”其实不正常在真板子上跑这个程序你看到的物理结果是 PA5 以 1Hz 频率翻转电平LED 亮灭交替。在 Keil 仿真里你可以用两种方式验证一种是停到断点上看寄存器另一种是打开逻辑分析仪看波形。先说寄存器方式。进入 Debug 后运行程序打开 Peripherals → GPIO → GPIOA你会看到 Port A Pin 5 的 Output Data Bit 在持续翻转。这证明代码在正常工作。但这个观测粒度还不够因为软件上“GPIO 寄存器的值变了”和“芯片引脚的电平真的变了”在仿真里是同一个事件而在真实芯片上GPIO 输出还受端口配置、复用功能、开漏/推挽模式的影响。仿真器通常会省略掉这些硬件细节所以你在仿真里容易产生一个错觉只要寄存器翻转了LED 就一定会亮。在 Proteus 里这种错觉会被立刻纠正。Proteus 里的 LED 不是“寄存器指示灯”它是一个真实的器件模型要求引脚必须有足够电压和电流才会点亮。我就在 Proteus 里犯过一个低级错误在 CubeMX 里把 PA5 配成开漏输出并且没有接上拉电阻真板子上 LED 会非常暗甚至不亮仿真里寄存器照常翻转Keil 里看不出任何问题但放到 Proteus 里LED 就是不亮。这让我意识到仿真点灯的意义不只是“让寄存器动起来”而是逼你想清楚“电流路径”和“引脚电气特性”。3.3 用波形和断点组合验证仿真里最有用的调试姿势我后来养成了一个习惯凡是涉及时间、频率、占空比这类外设特性一律用 Keil 的逻辑分析仪Logic Analyzer来看波形。Keil 仿真的逻辑分析仪可以跟踪 GPIO 引脚、外设事件、甚至自定义信号。以点灯为例添加 PA5 到逻辑分析仪之后你会看到一条 0/1 跳变的方波。把这个波形放大测量两次上升沿之间的时间你会发现它和你设置的 500ms 延时基本一致。这里有个值得留意的细节HAL_Delay 的延时精度受 SysTick 频率影响仿真环境下 SysTick 时钟配置可能和真板子不同所以波形周期不一定严格等于 500ms飘几毫秒都正常不用纠结。断点配合波形的用法也很实用。输入捕获、PWM 占空比这类“事件驱动”的外设调试在真板子上要示波器加逻辑分析仪双管齐下仿真里只需要在中断服务函数入口加断点看进入的顺序、次数和波形对应关系就行。我见过很多初学者在真板子上调 PWM 调到头大脑子里完全没有波形图像其实在仿真里先把标准波形看熟了真板子上的差距就只剩“示波器探头接触不良”这种物理问题了。4. 外设逐个跑通UART、定时器、ADC、I2C/SPIGPIO 跑通之后后面的外设就好办多了。我总结了一个通用套路先用 CubeMX 生成对应外设的初始化代码写好业务逻辑然后在 Keil 仿真里验证寄存器行为最后到 Proteus 里把“外设器件”接上验证真实电气效果。下面逐个拆开讲。4.1 UART 仿真虚拟串口也能跟串口助手对话UART 在仿真里验证起来非常直观。CubeMX 里配置 USART1波特率 115200、8 位数据、无校验、1 位停止位生成工程之后你要做的第一件事是把 printf 重定向到串口。最省事的做法是在工程里加一个 fputc 函数。用 MDK 加上 MicroLIB 时printf 最终会调用 fputc 来输出字符所以只需要写int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }编译、进入 Keil 仿真、全速运行打开 View → Serial Windows → UART #1你就会看到 printf 打印的内容一行行出现在窗口里。这个虚拟串口窗口本质上模拟了芯片的 UART 发送寄存器它的存在让你可以完全在没有物理串口的情况下调试所有基于文本协议的交互逻辑。更有意思的是你还可以做回显测试。在 Keil 仿真里往 UART #1 窗口输入字符代码里调用 HAL_UART_Receive 或者进入接收中断再把收到的数据原样发回去就能看到你输入的内容被“回显”出来。这一步在真板子上需要接 USB-TTL 模块和上位机在仿真里只是点两下窗口的事。Proteus 里更直观放一个 Virtual Terminal 接在 PA9、PA10 上程序往串口发什么虚拟终端屏幕上就出现什么你在终端里敲字符芯片的中断也能收到。这里有一个仿真特有的小坑Keil 的仿真器在默认状态下并不会自动处理 UART 接收你需要打开 UART 窗口并且保持它处于激活状态仿真器模拟的接收事件才会触发。所以如果你发现“接收中断进不去”先检查窗口是不是开着而不是怀疑代码。4.2 定时器仿真PWM 波形可以直观抓取定时器是 STM32 外设里最有代表性的一个因为它同时涉及计数、分频、比较、中断和 DMA 五个维度。入门阶段我建议从 PWM 输出入手理由很实际PWM 有稳定的波形方便用逻辑分析仪验证。配置步骤是CubeMX 里启用 TIM1选择 Channel 1 为 PWM Generation CH1预分频器 PSC 设为 72-172MHz / 72 1MHz 计数频率自动重载 ARR 设为 1000-1PWM 频率 1MHz / 1000 1kHz初始脉冲宽度 CCR1 设为 500占空比 50%。生成代码后在 main 里启动 PWM 输出HAL_TIM_PWM_Start(htim1, TIM_CHANNEL_1);在 Keil 仿真里把 PA8TIM1_CH1 的默认映射引脚添加到逻辑分析仪全速运行之后你就能看到 1kHz、50% 占空比的方波。相比 GPIO 点灯验证 PWM 有两个进阶动作很值得做一是修改 CCR 的值观察波形占空比实时变化二是修改 ARR 的值观察频率变化。这两个动作在真板子上都需要重新烧录才能验证仿真里直接改寄存器或者单步执行赋值语句就能看效果。我第一次在仿真里看到 PWM 波形时最大的感触是之前学 PWM 概念时教材上画的方波图始终是静态图片而仿真里我能亲手调出任意频率和占空比物理量之间的因果关系一下就通了。这个“亲手调参验证”的过程比看十页理论都有用。4.3 ADC 仿真用虚拟电位器模拟真实采样ADC 仿真有个独特的优势你可以动态改变输入电压这在真板子上需要接电位器或者信号发生器仿真里只需要拖动一个滑动条。CubeMX 里启用 ADC1通道选 IN0对应 PA0采样时间可以保持默认。生成代码后最简单的读取方式是轮询HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, 100); uint16_t value HAL_ADC_GetValue(hadc1);在 Keil 仿真里进入 Debug 后打开 Peripherals → ADC 面板你可以直接修改 ADC 的数据寄存器或者使用命令窗口给模拟输入端写入电压值。更贴近实际的做法是在 Proteus 里接一个电位器POT一端接 3.3V一端接地滑动端接 PA0。然后你拖动电位器观察 ADC 转换结果变化再把结果通过串口打印出来。有意思的扩展是做一个简易电压表ADC 采样、换算成电压、printf 打印然后根据电压值反转 LED。这四个步骤在仿真里全部可观测你既能通过串口窗口看到数值变化又能通过逻辑分析仪看到 LED 翻转频率变化。这个项目如果放在真板子上做你得同时准备电位器、USB-TTL、LED 模块外加一堆杜邦线而在仿真里零成本复现。4.4 I2C/SPI 仿真和虚拟传感器打交道I2C 和 SPI 这类总线外设仿真里验证的逻辑是一样的用一个虚拟器件充当从机验证主机的读写时序。I2C 最经典的虚拟器件是 24C02 EEPROM。在 Proteus 里放一个 24C02SDA 接 PB7、SCL 接 PB6上拉电阻别忘了。然后用 CubeMX 配置 I2C1生成代码后写一个页写/读校验的程序先往某个地址写入一串数据再读回来比对。在仿真里你可以直接打开 Proteus 里 24C02 的属性面板看到写入的数据“真实地”存在了 EEPROM 的存储单元里。这个反馈非常直观——它证明总线时序是对的数据真的传输过去了。SPI 方面比较适合用虚拟的 OLED 显示屏或者 SPI 接口的温度传感器。OLED 的验证非常直观屏幕上的像素点会按照你发送的显存数据点亮如果 SPI 时序里 CS、SCLK、MOSI 任何一根线接错显示就会花屏甚至白屏你的排查思路和真板子一模一样。我还试过直接在 Keil 仿真里用 SPI 向虚拟存储设备写入数据再用逻辑分析仪抓取 SCLK 和 MOSI 的波形对照时序图核对每比特的相位。这种“逐比特核对总线时序”的经验到了真板子上调试带 SPI 屏、SPI 存储卡时会非常有用。5. 仿真替不了的部分中断时序、硬件误差与真实调试写了这么多仿真多好其实我也得负责任地说说它的边界。我在用这套纯软件方案跑了两个多月之后最大的体会是仿真能教你“外设该怎么用”但教不了你“硬件世界里那些乱七八糟的事”。5.1 仿真环境的理想化偏差首先是中断时序的偏差。Keil 模拟器对 Cortex-M 内核的指令执行是“逐条指令模拟”的理论上精确但外设事件比如定时器溢出、外部引脚跳变的产生时机取决于模拟器的调度粒度。也就是说两个中断谁先谁后、嵌套优先级是否按预期生效在仿真里可能和真芯片有细微差别。遇到底层时序排查比如一个 10kHz 的中断里做耗时操作仿真结果只能当参考不能当最终结论。其次是硬件误差。真芯片有引脚上拉/下拉电阻、有开漏输出的灌电流限制、有浮空输入时的不确定电平、有晶振频率漂移这些在仿真里要么被简化成正负逻辑要么干脆不存在。仿真里你写出“读取一个浮空引脚”的代码可能每次都能稳定返回同一个值真板子上你取到的可能是一个随机的、受电磁干扰影响的值。这类问题没有任何仿真工具能替你提前发现只有真板子会告诉你答案。5.2 我在仿真里踩过的几个坑第一个坑是时钟配置。仿真器默认认为主频已经稳定不会去模拟晶振起振等待和 PLL 锁定过程。这导致一个问题在真板子上需要几百微秒到几毫秒才稳定下来的时钟树在仿真里“瞬间”就绪。我一开始没意识到在代码里用了非常短的延时就去读外设寄存器仿真里一切正常后来移植到真板子就偶发异常排查了很久才想到是时钟稳定时间不足。第二个坑是看门狗。仿真器对独立看门狗的模拟比较粗糙时基可能和预期的喂狗节奏对不上导致程序在仿真里频繁复位让你以为代码有问题。我建议入门阶段先别看门狗等真板子阶段再学。第三个坑是外部中断的毛刺。仿真里产生一个外部中断信号就是一次干净的电平跳变但在真实电路里按键按下会有机械抖动产生一串毛刺仿真里的按键不会抖动导致你的消抖代码在仿真里完全用不上。这不能怪仿真只能说你学到的“消抖知识”在仿真里没有用武之地得等真板子才能实践。5.3 仿真学完再上手真板子的衔接建议我见过不少同学仿真玩得很溜一到真板子就手足无措。这个落差主要来自三件事烧录器驱动、硬件连接、以及“没有虚拟窗口时的调试手段缺失”。我的建议是仿真阶段就要有意识地为真板子做准备。第一代码风格从第一天起就按真板子标准写初始化外设后加一点延时再进入主循环、所有 GPIO 都显式配置上下拉、外设错误处理不要留空。这些好习惯在仿真里看似多余到真板子上全是救命稻草。第二仿真验证时多问自己一个问题“如果这个外设接到真实电路上我该怎么观察它的行为” 如果你能在仿真里说清楚“我应该用示波器测哪根引脚、期待看到什么波形”那么到真板子上你的调试思路基本就通了。第三等你把外设全部跑通一遍之后其实可以买一块最便宜的板子做最终验证。并不是说仿真不够好而是真板子能给你仿真给不了的两个反馈一个是物理世界的电磁干扰和接触可靠性另一个是“亲手焊线、接杜邦线、看 LED 亮起”的成就感和动手能力。这两样东西对嵌入式工程师来说都不可或缺。6. 按外设划分的六周路线照着走就行6.1 一张表看清楚每个阶段该干什么最后分享一个我自己整理的路线图。这不是随便排的完全按照外设依赖关系和难度递进设计仿真里照着走基本不会卡住。阶段时间外设主题仿真验证方式核心知识点第一周环境搭建 GPIO点灯、按键扫描Keil 逻辑分析仪 / Proteus LED引脚模式、上下拉、读写引脚第二周UART printf串口打印、回显Keil UART 窗口 / Proteus 虚拟终端波特率、中断、重定向第三周定时器PWM、输入捕获Keil 逻辑分析仪波形预分频、自动重载、比较值第四周ADC DMA电压采样、DMA 传输Proteus 电位器 串口打印采样精度、DMA 搬运第五周I2C / SPIEEPROM 读写、OLED 显示Proteus 虚拟器件 逻辑分析仪总线时序、从机地址第六周综合小项目简易电压表 串口监控全仿真联动外设组合、状态机6.2 为什么把外设按这个顺序排这条路线我有意把每个阶段都设计成“上一个外设的输出是下一个外设的输入”第一周点亮 LED第二周用串口打印第三周用定时器产生 PWM 控制 LED 亮度第四周用 ADC 采样电位器来控制 PWM 占空比第五周把结果写入 EEPROM第六周整合成一个完整项目。这样学起来不枯燥每一步都能立刻看到成果也不会出现“学完不知道学了啥”的感觉。6.3 学习过程中的几个额外提醒我特别想强调的一点是入门阶段千万别一开始就纠结寄存器和 HAL 库哪个更重要。先用 HAL 库把外设流程跑通建立“轮询、中断、DMA”这三种交互方式的概念等你对 GPIO、串口、定时器、ADC 的寄存器结构有感觉了再回头啃参考手册里的寄存器位定义效率会高非常多。仿真环境里对着寄存器面板改一位就立刻能看到外设行为变化这个学习闭环在真板子上很难实现。最后说个我的实际操作体会这套纯软件方案最大的价值不是省钱而是降低了“试错的心理成本”。真板子上你每写一个可能有风险的实验比如短接引脚、超频、看门狗复位都会担心烧坏东西于是不敢试仿真里你随便试反正最坏结果就是重新启动一个进程。这种“随便试”的勇气才是入门阶段最宝贵的东西。等你把胆子练出来了、该踩的坑在仿真里踩过一遍了再拿真板子上手你会发现大部分问题都不是问题剩下的那些才是真正属于硬件工程师的乐趣。 
长河君 · 2026/10/13 1:31:21 · 阅读 1.2k STM32入门不烧钱：纯软件仿真跑通GPIO、UART、定时器、ADC的完整实操
很多想入门 STM32 的朋友第一反应都是先买一块开发板。这话本身没毛病但我见过太多人栽在“板子到手之后”烧录器驱动装不上、照着视频敲了两天代码点灯没反应、不知道是硬件坏了还是代码错了最后只能让板子吃灰。我自己也经历过这个阶段所以后来干脆把入门路线做成了一套“纯软件”版本——不买板、不焊接、不花钱直接用仿真环境把 GPIO、串口、定时器、ADC 这些外设一个个跑通。这篇文章就把这套方案完整拆开怎么选仿真工具、怎么搭环境、每个外设怎么在仿真里跑、哪些坑只有仿真里才有以及仿真学完之后怎么丝滑过渡到真板子。如果你是一个零基础想入门 STM32 的学生、想低成本验证方案的硬件工程师或者还在犹豫要不要入坑嵌入式的小白这篇内容都是照着做就能复现的实操记录不是泛泛而谈的科普。1. 为什么我会想到用“纯软件”学 STM321.1 一个真实的学习困境先说我自己踩过的经历。我是从 Arduino 转到 STM32 的最初的想法很简单STM32 功能强、资源多、价格也不算离谱买一块最小系统板也就几十块钱。结果下单之后问题一个接一个。板子到手没法第一时间开搞因为电脑上还缺驱动装好驱动之后烧录器识别不到芯片好不容易能烧录了第一段点灯代码却怎么都不亮。我在网上查了两天有人说晶振没起振有人说 Boot 跳线帽没接对还有人说开发板出厂就有问题。后来我发现这些问题里有一大半跟“硬件环境”相关供电不稳、引脚接触不良、焊接虚焊、晶振起振条件不对。而我想学的其实是“怎么用 STM32 控制外设”这件事却被硬件折腾得筋疲力尽。更别提如果代码里同时涉及 MCU 和外设出了问题到底是软件时序不对还是硬件连接错误排查起来非常痛苦。这让我意识到对入门阶段的人来说最大的阻碍往往不是“STM32 难学”而是“硬件环境的不确定性”拉高了学习门槛。那为什么不先在一个完全可控的软件环境里把外设用法、寄存器流程、HAL 库函数这些核心知识跑通再上真板子呢1.2 “纯软件”方案到底解决什么问题我这套纯软件方案解决的是三件事成本、快速迭代和可观测性。成本不用多说仿真环境最大的优势就是不花钱。不过很多人忽视的是后面两点。拿“快速迭代”来说在真板子上改一次代码要经历编译、烧录、复位、观察这一套流程一分钟算快的。但在仿真里改完代码直接重新编译、点一下运行整个过程十几秒而且不需要反复插拔 USB。我有一次调试 PWM 频率半小时内改了十几次分频参数放到真板子上至少得折腾一整个晚上。“可观测性”则是我认为仿真最值钱的地方。真板子上你想看某个引脚的波形得有示波器想确认定时器计数器的实时值只能暂停在调试器里翻寄存器。而在仿真工具里GPIO 状态、外设寄存器、总线时序、波形图都是直接可视化呈现的。你甚至可以故意把两个引脚短接看看逻辑冲突会怎么表现——这种事情在真板子上一般是“啪”一声冒烟仿真里只是改个状态而已。这套方案适合的人群也很明确零基础准备入门的学生、想要低成本验证某段外设代码逻辑的工程师、以及纯粹好奇 STM32 但还没决定要不要买板子的小白。当然我也得先泼一盆冷水仿真毕竟不是真板子后面我会专门讲它替代不了什么但作为“入门”和“外设理解”这两个目标它完全够用。2. 仿真方案怎么选四条路线的横向对比很多人听到“STM32 仿真”第一反应是 Proteus。确实Proteus 是老牌 EDA 工具画个电路、放个 STM32、接个 LED跑起来非常直观。但“仿真跑通外设”这件事市面上其实有好几条路线各有各的脾气选错路会走很多弯路。我先把我实测过的方案整理成一张对比表再逐条分析。方案上手难度外设可视化与真实代码的贴近度适合场景Keil MDK 内置仿真器低中寄存器/逻辑分析仪高直接编译烧录的同一套代码纯代码逻辑学习Proteus 电路仿真中高电路图/示波器/虚拟终端高跑的是编译好的 hex外设电路连接的学习Wokwi 网页仿真低中组件图串口终端中Arduino/仿真器框架快速验证小段代码QEMU/Renode高低命令行外设高裸机最真实嵌入式系统级调试2.1 Keil MDK 内置仿真器为什么我把它当作主力先说我最常用的组合。Keil MDK 本身自带了面向 ARM Cortex-M 内核的模拟器不需要任何外部硬件就能直接以 Debug 模式运行 STM32 程序。它的优势在于仿真环境里跑的二进制就是你最终要烧录到真板子上的同一个工程工具链、启动文件、链接脚本完全一致唯一的差别只是 CPU 执行方式是从模拟器执行而不是真实芯片执行。这意味着你在仿真里调通的逻辑移植到真板子上几乎不会因为“代码版本不同”而出问题。Keil 仿真器对 STM32F103 系列的支持尤其成熟GPIO、USART、TIM、ADC 这些外设都有对应的寄存器视图和调试窗口。比如你可以打开 Peripherals → GPIO 面板实时看到每个引脚是输入还是输出、电平是高还是低打开 Serial Window就能看到虚拟串口打印的内容。再加上断点、单步、观察窗口这些传统调试手段学外设的时候非常顺手。2.2 那其他方案什么时候用Proteus 的价值在于“电路”层面。Keil 仿真只能看到寄存器数值看不到“一个 LED 是不是真的会亮”。Proteus 里你可以把 STM32、电阻、LED、按键、电位器这些元件放在一张电路图上用 .hex 文件加载程序然后看到 LED 真的在闪、示波器真的在画波形。我的建议是Keil 仿真用来学“代码怎么写”Proteus 用来学“引脚该连到哪里”。Wokwi 是一个网页版的电路仿真开箱即用浏览器一开就能拖一个 STM32F103 出来。它上手比 Proteus 更快适合在别人电脑上演示、或者临时验证一段传感器代码。但它对 STM32 的支持没有 F103 之外那么完善代码框架也偏向 Arduino 风格如果你以后要走 HAL 库路线Wokwi 只能当辅助。至于 QEMU 和 Renode我个人认为入门阶段真的不建议碰。它们面向的是嵌入式系统开发、操作系统移植、自动化测试这类场景需要手动搭建工具链、处理命令行仿真参数外设模拟也不直观。入门学外设用它们纯粹是给自己加难度。2.3 我最终选定的组合与环境搭建步骤综合下来我最终采用的组合是STM32CubeMX 生成初始化工程 Keil MDK 编译与内置仿真 Proteus 按需做电路级验证。三个工具各司其职CubeMX 帮我快速配置时钟和外设生成标准的 HAL 库代码Keil 负责编译、调试、逻辑分析Proteus 只有在需要看“外设真实连接效果”时才出场。搭建步骤我整理成清单照着做就行安装 Keil MDK版本无所谓只要包含 ARM Compiler 5 或 6 之一即可评估版功能就够用。安装 STM32CubeMX安装时它会自动识别 Keil 的安装路径这样生成的工程可以直接用 Keil 打开。在 CubeMX 里新建工程选芯片型号。建议选 STM32F103C8T6资源够多、资料全网最全。配置时钟树HSE 选外部晶振频率填 8MHz然后让系统时钟跑到 72MHz。仿真环境中 HSE 的起振过程可能不完全模拟但 72MHz 这个主频模拟器能正确执行。先用默认配置生成一个最小工程在 Keil 里编译一次确认没有报错。Keil 进入仿真模式Options for Target → Debug 页把 Use Simulator 勾上Dialogue 里选 STM32F103C8然后点击 Debug 按钮进入仿真环境。到这一步你的“纯软件”开发环境就搭好了。后面每一个外设的验证都从这个模板工程出发。3. 第一个外设GPIO 点灯在仿真里究竟怎么“亮”3.1 用 CubeMX 配置 GPIO 的完整过程点灯是所有嵌入式教学的第一个程序仿真里也一样。我用 CubeMX 配置的最小流程是选择 STM32F103C8T6 → System Core 里选 GPIO把 PA5 设为 GPIO_Output默认推挽输出、无上下拉然后到 Clock Configuration 里保证 PLLCLK 后主频是 72MHz最后 Project Manager 里给你的工程起名、选择 MDK-ARM 工具链、生成代码。生成完代码后打开 main.c 的 main 函数在 while(1) 循环里加上点灯逻辑。HAL 库写法很简单while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(500); }这里有一个非常关键的点HAL_Delay 依赖 SysTick 中断。仿真器会模拟 SysTick所以这个延时函数在仿真里能正常工作。如果你发现仿真里 HAL_Delay 不生效或者时间不对第一件事不是查代码而是去 Keil 的 Options for Target → Target 页确认晶振频率和仿真器配置一致。3.2 仿真点灯和真实板子的差异哪些“看起来正常”其实不正常在真板子上跑这个程序你看到的物理结果是 PA5 以 1Hz 频率翻转电平LED 亮灭交替。在 Keil 仿真里你可以用两种方式验证一种是停到断点上看寄存器另一种是打开逻辑分析仪看波形。先说寄存器方式。进入 Debug 后运行程序打开 Peripherals → GPIO → GPIOA你会看到 Port A Pin 5 的 Output Data Bit 在持续翻转。这证明代码在正常工作。但这个观测粒度还不够因为软件上“GPIO 寄存器的值变了”和“芯片引脚的电平真的变了”在仿真里是同一个事件而在真实芯片上GPIO 输出还受端口配置、复用功能、开漏/推挽模式的影响。仿真器通常会省略掉这些硬件细节所以你在仿真里容易产生一个错觉只要寄存器翻转了LED 就一定会亮。在 Proteus 里这种错觉会被立刻纠正。Proteus 里的 LED 不是“寄存器指示灯”它是一个真实的器件模型要求引脚必须有足够电压和电流才会点亮。我就在 Proteus 里犯过一个低级错误在 CubeMX 里把 PA5 配成开漏输出并且没有接上拉电阻真板子上 LED 会非常暗甚至不亮仿真里寄存器照常翻转Keil 里看不出任何问题但放到 Proteus 里LED 就是不亮。这让我意识到仿真点灯的意义不只是“让寄存器动起来”而是逼你想清楚“电流路径”和“引脚电气特性”。3.3 用波形和断点组合验证仿真里最有用的调试姿势我后来养成了一个习惯凡是涉及时间、频率、占空比这类外设特性一律用 Keil 的逻辑分析仪Logic Analyzer来看波形。Keil 仿真的逻辑分析仪可以跟踪 GPIO 引脚、外设事件、甚至自定义信号。以点灯为例添加 PA5 到逻辑分析仪之后你会看到一条 0/1 跳变的方波。把这个波形放大测量两次上升沿之间的时间你会发现它和你设置的 500ms 延时基本一致。这里有个值得留意的细节HAL_Delay 的延时精度受 SysTick 频率影响仿真环境下 SysTick 时钟配置可能和真板子不同所以波形周期不一定严格等于 500ms飘几毫秒都正常不用纠结。断点配合波形的用法也很实用。输入捕获、PWM 占空比这类“事件驱动”的外设调试在真板子上要示波器加逻辑分析仪双管齐下仿真里只需要在中断服务函数入口加断点看进入的顺序、次数和波形对应关系就行。我见过很多初学者在真板子上调 PWM 调到头大脑子里完全没有波形图像其实在仿真里先把标准波形看熟了真板子上的差距就只剩“示波器探头接触不良”这种物理问题了。4. 外设逐个跑通UART、定时器、ADC、I2C/SPIGPIO 跑通之后后面的外设就好办多了。我总结了一个通用套路先用 CubeMX 生成对应外设的初始化代码写好业务逻辑然后在 Keil 仿真里验证寄存器行为最后到 Proteus 里把“外设器件”接上验证真实电气效果。下面逐个拆开讲。4.1 UART 仿真虚拟串口也能跟串口助手对话UART 在仿真里验证起来非常直观。CubeMX 里配置 USART1波特率 115200、8 位数据、无校验、1 位停止位生成工程之后你要做的第一件事是把 printf 重定向到串口。最省事的做法是在工程里加一个 fputc 函数。用 MDK 加上 MicroLIB 时printf 最终会调用 fputc 来输出字符所以只需要写int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }编译、进入 Keil 仿真、全速运行打开 View → Serial Windows → UART #1你就会看到 printf 打印的内容一行行出现在窗口里。这个虚拟串口窗口本质上模拟了芯片的 UART 发送寄存器它的存在让你可以完全在没有物理串口的情况下调试所有基于文本协议的交互逻辑。更有意思的是你还可以做回显测试。在 Keil 仿真里往 UART #1 窗口输入字符代码里调用 HAL_UART_Receive 或者进入接收中断再把收到的数据原样发回去就能看到你输入的内容被“回显”出来。这一步在真板子上需要接 USB-TTL 模块和上位机在仿真里只是点两下窗口的事。Proteus 里更直观放一个 Virtual Terminal 接在 PA9、PA10 上程序往串口发什么虚拟终端屏幕上就出现什么你在终端里敲字符芯片的中断也能收到。这里有一个仿真特有的小坑Keil 的仿真器在默认状态下并不会自动处理 UART 接收你需要打开 UART 窗口并且保持它处于激活状态仿真器模拟的接收事件才会触发。所以如果你发现“接收中断进不去”先检查窗口是不是开着而不是怀疑代码。4.2 定时器仿真PWM 波形可以直观抓取定时器是 STM32 外设里最有代表性的一个因为它同时涉及计数、分频、比较、中断和 DMA 五个维度。入门阶段我建议从 PWM 输出入手理由很实际PWM 有稳定的波形方便用逻辑分析仪验证。配置步骤是CubeMX 里启用 TIM1选择 Channel 1 为 PWM Generation CH1预分频器 PSC 设为 72-172MHz / 72 1MHz 计数频率自动重载 ARR 设为 1000-1PWM 频率 1MHz / 1000 1kHz初始脉冲宽度 CCR1 设为 500占空比 50%。生成代码后在 main 里启动 PWM 输出HAL_TIM_PWM_Start(htim1, TIM_CHANNEL_1);在 Keil 仿真里把 PA8TIM1_CH1 的默认映射引脚添加到逻辑分析仪全速运行之后你就能看到 1kHz、50% 占空比的方波。相比 GPIO 点灯验证 PWM 有两个进阶动作很值得做一是修改 CCR 的值观察波形占空比实时变化二是修改 ARR 的值观察频率变化。这两个动作在真板子上都需要重新烧录才能验证仿真里直接改寄存器或者单步执行赋值语句就能看效果。我第一次在仿真里看到 PWM 波形时最大的感触是之前学 PWM 概念时教材上画的方波图始终是静态图片而仿真里我能亲手调出任意频率和占空比物理量之间的因果关系一下就通了。这个“亲手调参验证”的过程比看十页理论都有用。4.3 ADC 仿真用虚拟电位器模拟真实采样ADC 仿真有个独特的优势你可以动态改变输入电压这在真板子上需要接电位器或者信号发生器仿真里只需要拖动一个滑动条。CubeMX 里启用 ADC1通道选 IN0对应 PA0采样时间可以保持默认。生成代码后最简单的读取方式是轮询HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, 100); uint16_t value HAL_ADC_GetValue(hadc1);在 Keil 仿真里进入 Debug 后打开 Peripherals → ADC 面板你可以直接修改 ADC 的数据寄存器或者使用命令窗口给模拟输入端写入电压值。更贴近实际的做法是在 Proteus 里接一个电位器POT一端接 3.3V一端接地滑动端接 PA0。然后你拖动电位器观察 ADC 转换结果变化再把结果通过串口打印出来。有意思的扩展是做一个简易电压表ADC 采样、换算成电压、printf 打印然后根据电压值反转 LED。这四个步骤在仿真里全部可观测你既能通过串口窗口看到数值变化又能通过逻辑分析仪看到 LED 翻转频率变化。这个项目如果放在真板子上做你得同时准备电位器、USB-TTL、LED 模块外加一堆杜邦线而在仿真里零成本复现。4.4 I2C/SPI 仿真和虚拟传感器打交道I2C 和 SPI 这类总线外设仿真里验证的逻辑是一样的用一个虚拟器件充当从机验证主机的读写时序。I2C 最经典的虚拟器件是 24C02 EEPROM。在 Proteus 里放一个 24C02SDA 接 PB7、SCL 接 PB6上拉电阻别忘了。然后用 CubeMX 配置 I2C1生成代码后写一个页写/读校验的程序先往某个地址写入一串数据再读回来比对。在仿真里你可以直接打开 Proteus 里 24C02 的属性面板看到写入的数据“真实地”存在了 EEPROM 的存储单元里。这个反馈非常直观——它证明总线时序是对的数据真的传输过去了。SPI 方面比较适合用虚拟的 OLED 显示屏或者 SPI 接口的温度传感器。OLED 的验证非常直观屏幕上的像素点会按照你发送的显存数据点亮如果 SPI 时序里 CS、SCLK、MOSI 任何一根线接错显示就会花屏甚至白屏你的排查思路和真板子一模一样。我还试过直接在 Keil 仿真里用 SPI 向虚拟存储设备写入数据再用逻辑分析仪抓取 SCLK 和 MOSI 的波形对照时序图核对每比特的相位。这种“逐比特核对总线时序”的经验到了真板子上调试带 SPI 屏、SPI 存储卡时会非常有用。5. 仿真替不了的部分中断时序、硬件误差与真实调试写了这么多仿真多好其实我也得负责任地说说它的边界。我在用这套纯软件方案跑了两个多月之后最大的体会是仿真能教你“外设该怎么用”但教不了你“硬件世界里那些乱七八糟的事”。5.1 仿真环境的理想化偏差首先是中断时序的偏差。Keil 模拟器对 Cortex-M 内核的指令执行是“逐条指令模拟”的理论上精确但外设事件比如定时器溢出、外部引脚跳变的产生时机取决于模拟器的调度粒度。也就是说两个中断谁先谁后、嵌套优先级是否按预期生效在仿真里可能和真芯片有细微差别。遇到底层时序排查比如一个 10kHz 的中断里做耗时操作仿真结果只能当参考不能当最终结论。其次是硬件误差。真芯片有引脚上拉/下拉电阻、有开漏输出的灌电流限制、有浮空输入时的不确定电平、有晶振频率漂移这些在仿真里要么被简化成正负逻辑要么干脆不存在。仿真里你写出“读取一个浮空引脚”的代码可能每次都能稳定返回同一个值真板子上你取到的可能是一个随机的、受电磁干扰影响的值。这类问题没有任何仿真工具能替你提前发现只有真板子会告诉你答案。5.2 我在仿真里踩过的几个坑第一个坑是时钟配置。仿真器默认认为主频已经稳定不会去模拟晶振起振等待和 PLL 锁定过程。这导致一个问题在真板子上需要几百微秒到几毫秒才稳定下来的时钟树在仿真里“瞬间”就绪。我一开始没意识到在代码里用了非常短的延时就去读外设寄存器仿真里一切正常后来移植到真板子就偶发异常排查了很久才想到是时钟稳定时间不足。第二个坑是看门狗。仿真器对独立看门狗的模拟比较粗糙时基可能和预期的喂狗节奏对不上导致程序在仿真里频繁复位让你以为代码有问题。我建议入门阶段先别看门狗等真板子阶段再学。第三个坑是外部中断的毛刺。仿真里产生一个外部中断信号就是一次干净的电平跳变但在真实电路里按键按下会有机械抖动产生一串毛刺仿真里的按键不会抖动导致你的消抖代码在仿真里完全用不上。这不能怪仿真只能说你学到的“消抖知识”在仿真里没有用武之地得等真板子才能实践。5.3 仿真学完再上手真板子的衔接建议我见过不少同学仿真玩得很溜一到真板子就手足无措。这个落差主要来自三件事烧录器驱动、硬件连接、以及“没有虚拟窗口时的调试手段缺失”。我的建议是仿真阶段就要有意识地为真板子做准备。第一代码风格从第一天起就按真板子标准写初始化外设后加一点延时再进入主循环、所有 GPIO 都显式配置上下拉、外设错误处理不要留空。这些好习惯在仿真里看似多余到真板子上全是救命稻草。第二仿真验证时多问自己一个问题“如果这个外设接到真实电路上我该怎么观察它的行为” 如果你能在仿真里说清楚“我应该用示波器测哪根引脚、期待看到什么波形”那么到真板子上你的调试思路基本就通了。第三等你把外设全部跑通一遍之后其实可以买一块最便宜的板子做最终验证。并不是说仿真不够好而是真板子能给你仿真给不了的两个反馈一个是物理世界的电磁干扰和接触可靠性另一个是“亲手焊线、接杜邦线、看 LED 亮起”的成就感和动手能力。这两样东西对嵌入式工程师来说都不可或缺。6. 按外设划分的六周路线照着走就行6.1 一张表看清楚每个阶段该干什么最后分享一个我自己整理的路线图。这不是随便排的完全按照外设依赖关系和难度递进设计仿真里照着走基本不会卡住。阶段时间外设主题仿真验证方式核心知识点第一周环境搭建 GPIO点灯、按键扫描Keil 逻辑分析仪 / Proteus LED引脚模式、上下拉、读写引脚第二周UART printf串口打印、回显Keil UART 窗口 / Proteus 虚拟终端波特率、中断、重定向第三周定时器PWM、输入捕获Keil 逻辑分析仪波形预分频、自动重载、比较值第四周ADC DMA电压采样、DMA 传输Proteus 电位器 串口打印采样精度、DMA 搬运第五周I2C / SPIEEPROM 读写、OLED 显示Proteus 虚拟器件 逻辑分析仪总线时序、从机地址第六周综合小项目简易电压表 串口监控全仿真联动外设组合、状态机6.2 为什么把外设按这个顺序排这条路线我有意把每个阶段都设计成“上一个外设的输出是下一个外设的输入”第一周点亮 LED第二周用串口打印第三周用定时器产生 PWM 控制 LED 亮度第四周用 ADC 采样电位器来控制 PWM 占空比第五周把结果写入 EEPROM第六周整合成一个完整项目。这样学起来不枯燥每一步都能立刻看到成果也不会出现“学完不知道学了啥”的感觉。6.3 学习过程中的几个额外提醒我特别想强调的一点是入门阶段千万别一开始就纠结寄存器和 HAL 库哪个更重要。先用 HAL 库把外设流程跑通建立“轮询、中断、DMA”这三种交互方式的概念等你对 GPIO、串口、定时器、ADC 的寄存器结构有感觉了再回头啃参考手册里的寄存器位定义效率会高非常多。仿真环境里对着寄存器面板改一位就立刻能看到外设行为变化这个学习闭环在真板子上很难实现。最后说个我的实际操作体会这套纯软件方案最大的价值不是省钱而是降低了“试错的心理成本”。真板子上你每写一个可能有风险的实验比如短接引脚、超频、看门狗复位都会担心烧坏东西于是不敢试仿真里你随便试反正最坏结果就是重新启动一个进程。这种“随便试”的勇气才是入门阶段最宝贵的东西。等你把胆子练出来了、该踩的坑在仿真里踩过一遍了再拿真板子上手你会发现大部分问题都不是问题剩下的那些才是真正属于硬件工程师的乐趣。