企业官网建设流程全解析

板子还没打样，代码已经改到第三版，这时候最省事的做法不是飞线，也不是拿洞洞板焊一版出来试，而是在 Proteus 里把整套逻辑先跑一遍。我做单片机项目有个固定习惯：凡是能用软件先验证的部分，绝不留给烙铁。Proteus 单片机仿真这套东西，本质上就是让你在一块虚拟的电路板上，把"电路"和"程序"这两件事提前对齐——芯片型号、引脚接法、外围器件、时钟频率、外设时序，全部在电脑里先跑通，再决定要不要花钱打板。它适合三类人：刚学 51 或 STM32、手里只有一块开发板却想做多个项目的人；正在赶课程设计、毕业设计，需要快速验证方案可行性的人；以及已经工作、要给客户做方案预演、想低成本试错的工程师。下面这些东西，是我这些年反复用 Proteus 之后攒下来的实操经验，不是软件说明书的复述。

1. 先想清楚 Proteus 能替你验证什么，不能验证什么

很多人用 Proteus 用得很憋屈，根源不在软件，而在预期错位。他们指望仿真通过就等于实物一定没问题，结果板子回来照样不亮，于是回头骂仿真不准。我的一般判断是：Proteus 是一个逻辑与时序验证器，不是一个电气验证器。你把这条线划清楚，后面所有的取舍都会变得容易。

1.1 值得先在仿真里解决的三类问题

第一类是程序逻辑正确性。按键流程、菜单跳转、状态机切换、显示刷新，这些东西出问题最多，排查最费时间，但在仿真里改代码只要几秒。我做一个多级菜单的项目，实物上调试一个层级跳转要反复按几十次键，在 Proteus 里我直接把按键接成脉冲源，让它自动按固定节奏触发，十分钟就能把整棵状态树跑一遍。

第二类是通信协议与时序波形。串口帧结构、I2C 的起始停止条件、SPI 的时钟极性相位、单总线的复位脉冲宽度，这些用示波器在实物上看，得先有示波器、还得探头接得稳。Proteus 里挂一个虚拟示波器或者数字图表，波形直接画在屏幕上，改一次代码刷新一次，效率差好几倍。

第三类是资源占用与中断冲突。51 的定时器只有那么几个，RAM 只有 128 字节，中断优先级一旦配错，现象是"偶尔死机"这种最难查的问题。仿真里你可以把定时器中断、串口中断、外部中断全部打开，看谁抢了谁。

1.2 仿真给不了你的三样东西

第一样是电气特性。在 Proteus 里，你给一个 LED 串一个 10 欧姆电阻它照样亮，不串电阻它也不会烧，因为模型不计算功耗。你在仿真里"验证通过"的驱动电路，实物上可能因为灌电流超限把口线烧了。凡是涉及三极管驱动继电器、MOS 管驱动电机、可控硅调光这一类功率环节，仿真只能验证"控制信号对不对",不能验证"器件扛不扛得住"。

第二样是模拟量的真实表现。Proteus 用的是 SPICE 内核做模拟仿真，理想化程度很高。你搭一个运算放大器电路，仿真出来的波形干净漂亮，实物上偏置电流、失调电压、寄生电容全都会来捣乱。涉及传感器采集的项目，仿真只能帮你验证"换算公式写得对不对",标定必须回到实物上做。

第三样是极限时序与机械负载。真正的中断响应延迟、晶振起振时间、电机的转动惯量、舵机的死区，这些仿真里都没有。我的做法是：凡是"能不能动"的问题放仿真里问，凡是"动得好不好"的问题留到实物上解决。

1.3 一个判断该不该继续仿真的经验标准

我给自己定了一条线：当仿真结果和我的预期不符，而我已经排查了三轮还找不到原因时，就不要再纠缠仿真了。这时候要么是模型本身和真实器件行为不同，要么是元件参数需要重新设定，继续调下去是纯消耗。反过来，如果仿真结果稳定且可复现，那就说明逻辑层面没问题，可以放心往下走。这个判断标准帮我省下了大量时间。

2. Keil 与 Proteus 的联调链路怎么搭才不折腾

标题里出现频率很高的 "keil5 proteus vsm simulator",说的其实是同一件事：代码在哪里编译，编译产物怎么送到仿真电路里去跑。这条链路搭得顺不顺，直接决定你后面是安心做项目还是一直在配环境。

2.1 安装与元件库路径上的几个老坑

安装本身没什么技术含量，但有几个细节踩过一次就会记一辈子。

首先是安装路径。Proteus 的元件库、模型文件、临时文件都依赖路径解析，路径里只要出现中文或者空格，就可能出现"元件库列表为空""打开工程提示找不到模型"这类玄学问题。我的习惯是统一装在D:\EDA\Proteus这种纯英文、无空格的目录下，Keil 装成D:\EDA\Keil_v5。这样做还有一个好处：换电脑或者重装系统时，把整个目录拷过去，重新指定一下路径就能用。

其次是元件库缺失。Proteus 的库分成好几块，LIBRARY目录下是基础的原理图符号，MODELS目录下是仿真模型，两者缺一不可。很多人从别人那里拷来一个工程，打开后元件全是红色方块，提示 "No model specified for ...",这就是只拷了.DSN文件没拷模型。正确做法是让对方用 "Project Clip" 或者直接打包整个工程目录。

再就是版本差异。Proteus 8.x 之后的元件名和早期版本有变化，同一个型号在不同版本里可能叫AT89C51也可能叫AT89C51RD2。碰到找不着元件的情况，先别怀疑自己，用元件选择框顶部的关键词搜索，把完整型号的中间部分输进去（比如搜 "89C52" 而不是全称），命中率会高很多。

2.2 两种协作方式的对比与选择

把 Keil 里编译出来的程序送进 Proteus 的芯片，有两条路。

第一条路是手动加载 HEX。在 Keil 里勾上生成 HEX 文件，编译成功后把.hex文件的路径记住，回到 Proteus 双击单片机，在 "Program File" 那一栏选中它。这条路听起来笨，但它有两个巨大优势：一是稳定，不受两个软件版本匹配的影响；二是可追溯，你清楚地知道现在跑的是哪个文件。

第二条路是 VSM 联调。原理是把 Keil 的调试驱动指到 Proteus 上，让 Keil 把编译产物自动推过去，还能在 Keil 里单步、看变量。它需要在 Keil 的配置里指定仿真驱动，并保证驱动文件的路径正确。这条路在版本匹配的时候非常好用，尤其是调中断的时候，你可以在 Keil 里断点停下来，看 Proteus 那边引脚电平是不是真的变了。但版本不匹配的时候，会出现连不上、程序不更新、仿真卡死等各种问题，我通常只在自己熟悉的固定环境里用它。

我的实际选择是：前期搭逻辑用 VSM 联调，后期跑稳定性用手动 HEX。

2.3 编译配置里最容易被忽略的三项

在 Keil 的 "Options for Target" 里，有三项必须确认。

第一项是Create HEX File。默认不开，不开就找不到 HEX 文件，很多人卡在这里半小时。

第二项是晶振频率。这个值填多少，直接影响编译器对延时函数的计算，也影响你心里的时序预期。更关键的是，这个值必须和 Proteus 里双击芯片后设置的 Clock Frequency 一致。我曾经遇到过串口全是乱码，查了半天代码，最后发现 Keil 里填的是 11.0592MHz，Proteus 芯片属性里是 12MHz，波特率自然对不上。这一类问题有一个统一的判断方法：凡是涉及时间的现象都不对，但逻辑是对的，先去看两边的时钟设置。

第三项是优化等级。Keil 的优化等级会影响软件延时循环的指令数，调高优化等级后，原本延时不准确的代码可能刚好变准，也可能偏差更大。做时间敏感的项目（比如单总线协议），我建议用定时器而不是空循环延时。下面是一段最典型的最小系统点灯代码，可以拿来当模板：

#include <reg52.h> sbit LED = P1^0; void delay_ms(unsigned int ms) { unsigned int i, j; for (i = 0; i < ms; i++) for (j = 0; j < 110; j++); /* 11.0592MHz 下约 1ms，仅作演示 */ } void main(void) { while (1) { LED = 0; /* 低电平点亮，与仿真中的接法保持一致 */ delay_ms(500); LED = 1; delay_ms(500); } }

代码本身没难度，值得注意的是LED = 0这句话和电路是绑定关系：共阳接法低电平点亮，共阴接法高电平点亮。仿真里最容易出现的一种"代码明明没错但不亮",就是极性搞反了。

3. 从画原理图到跑起来的最小系统搭建顺序

电路图在 Proteus 里画，和你在纸上画没本质区别，但有几步顺序上的讲究。顺序对了，出问题的时候你能快速定位；顺序乱了，最后所有问题混在一起，根本不知道从哪查。

3.1 元件选型与模型映射

选芯片是整个搭建过程的第一步，也是决定后面顺不顺的一步。常见的对应关系是这样的：

这里有一条血泪经验：别指望仿真模型和实物芯片一模一样。STC 系列的很多特殊功能寄存器在 Proteus 里根本不存在，你写P1M0 = 0x00设置推挽输出，仿真里没反应，但实物上有效。所以我的做法是：在仿真里只使用标准 51 的内核功能（P0-P3、TMOD、SCON、TCON、IE、IP），把所有和厂商相关的增强功能留到实物上验证。

3.2 那些"看不见"的元件怎么处理

最小系统里有几个元件在画原理图时很容易漏，但它们决定了仿真能不能正常启动。

晶振。在 Proteus 的元件库里搜CRYSTAL，接在 XTAL1 和 XTAL2 之间。有意思的是，Proteus 的 51 模型在大多数情况下不接晶振也能跑，因为芯片属性里的 Clock Frequency 才是仿真真正使用的时钟源。但我的建议是照样把晶振画上，理由有两点：一是原理图本来就应该反映真实接法，方便后面迁移到实物；二是有些模型确实会检查时钟引脚的状态。

复位电路。经典的 RC 复位加一个按键，搜RES、CAP-ELEC、BUTTON就能凑齐。仿真里按下复位按键，程序确实会从头开始跑，这个功能在做按键复位测试时很好用。

电源与地。Proteus 里电源和地是特殊符号，从左侧工具栏的 "Terminals Mode" 里取POWER和GROUND。TTL 和 CMOS 器件的隐藏电源引脚会自动连接到全局的 VCC 网络，所以你看不到电源引脚并不代表它没供电。

3.3 门电路与逻辑器件的画法

标题热词里有个问题被问了很多次：非门在 Proteus 里怎么画。答案不止一个。

最直接的做法是在元件库里搜74LS04或7404，取出来的芯片里有六个反相器，用其中任意一个都行。也可以在Digital分类里直接搜NOT,取一个单门器件，引脚更少、图面更干净。如果你需要的是带施密特特性的反相器，搜74LS14。

这里有个必须提醒的细节：TTL 器件的悬空输入在仿真里默认是高电平（逻辑 1）。这和很多人的直觉相反，也和 CMOS 器件不同。我曾经画过一个用与非门做按键检测的电路，输入悬空，仿真一直输出低电平，查了很久才发现是这个默认值的问题。处理办法很简单：所有不用的输入端一律明确接地或者接 VCC，不要悬空。

另外一个实用技巧：如果你要用门电路搭一个 RS 触发器或者振荡电路，Proteus 的数字仿真对这类电路的收敛性不太好，有时候会稳定在中间态。这时候换成D触发器或者直接用 555 定时器模型，仿真会稳定得多。

3.4 上电无响应的排查链路

程序加载进去、点了运行，芯片一点反应都没有，这是新手最常见的困境。我总结的排查顺序是这样的，从前往后逐条查：

1. 确认程序真的加载了。双击芯片，看 "Program File" 栏里有没有路径，路径指向的文件是不是最新编译出来的那个。
2. 确认时钟频率对了。芯片属性里的 Clock Frequency 和 Keil 里的设置是否一致。
3. 确认引脚方向对了。51 的 P0 口作为普通 IO 使用时是开漏结构，必须外接上拉电阻才能输出高电平、才能读到高电平输入。这是 51 最经典的坑，仿真和实物上都会犯。
4. 确认极性和接法。LED 是共阳还是共阴，按键是按下接地还是按下接 VCC。
5. 在程序入口打断点看能不能停下来。如果连断点都停不住，说明程序根本没跑起来，回到第 1 步。
6. 换一个最简单的测试程序。就三行代码点一个灯，排除掉自己写的复杂逻辑的干扰。

这个顺序看起来啰嗦，但它是收敛的:每一步都能给出明确的"是"或"否"，不会让你在一个模糊的范围里瞎猜。

4. 外设仿真的具体打法：数码管、串口、按键、测速

把最小系统跑通之后，真正花时间的部分是外设。每个外设都有它自己的一套仿真脾气。

4.1 数码管动态扫描的刷新率问题

Proteus 里的数码管模型有很多种，搜7SEG会出来一长串：7SEG-MPX4-CC是四位共阴，7SEG-MPX4-CA是四位共阳，7SEG-BCD是带译码器的。选的时候一定要看清楚 CC 和 CA，选错了不管你代码怎么写都不会正常显示。

动态扫描的关键参数是刷新周期。人眼的视觉暂留时间大约在 10 到 20 毫秒这个量级，所以整个四位数码管扫描一轮的时间要控制在 5 毫秒以内，每位的点亮时间在 1 毫秒左右比较合适。我见过很多人写扫描程序，每一位延时 5 毫秒，一轮下来 20 毫秒，仿真里看起来在闪，实物上更闪。

在仿真里判断刷新率是否合适，有个很直观的方法：把仿真速度调慢，慢速观察每一位的点亮顺序，确认扫描是逐位进行的，而不是某一位一直亮着。如果发现只有一位亮，那多半是位选信号没有正确切换，或者switch语句里漏了break。

限流电阻这件事要单独说。仿真里数码管的段串联不串电阻都能亮，实物上不串就可能烧段。我的习惯是在原理图里照常画上 220 欧姆到 470 欧姆的电阻，仿真的时候它们不影响结果，迁移到实物时它们就是保险。

4.2 串口仿真：虚拟终端与数据流验证

串口是仿真里性价比最高的外设。在 Proteus 里搜VIRTUAL TERMINAL，取出来是一个虚拟的串口终端，把它和单片机的 TXD、RXD 交叉接好（TXD 接终端的 RXD，RXD 接终端的 TXD），就能在仿真里看到单片机发出来的字符。

几个必须注意的点：

波特率必须严格一致。仿真里没有晶振误差，只要两边设置一样就能通。但如果 Keil 里的时钟频率和 Proteus 芯片属性里的不一致，波特率就会错，现象是终端里显示乱码。这也是前面强调时钟频率保持一致的原因。

虚拟终端的显示格式。右键终端属性可以看到 "ASCII" 和 "HEX" 之类的显示选项。调二进制协议的时候一定要切成 HEX 显示，否则你会看到一堆不可见字符。

发不出去的情况。51 发送一个字节前要先判断TI标志，很多人忘了清TI，结果只发出第一个字节就卡住了。这里给一个我常用的最简发送函数：

void uart_init(void) { SCON = 0x50; /* 方式1，允许接收 */ TMOD &= 0x0F; TMOD |= 0x20; /* 定时器1，方式2，做波特率发生器 */ TH1 = 0xFD; /* 11.0592MHz 下 9600bps */ TL1 = 0xFD; TR1 = 1; } void uart_send_byte(unsigned char dat) { SBUF = dat; while (TI == 0); /* 等待发送完成 */ TI = 0; /* 软件清零，这行不能少 */ }

热词里提到的 "c51单片机串口升级架构",本质上就是一个跑在串口上的引导程序：上电后先等一小段时间，如果收到约定的握手帧就进入升级流程，否则跳转到应用区。这个架构在仿真里能验证的只有状态跳转逻辑，真正的 Flash 擦写时序、分区跳转、向量重定位，必须回到实物上验证。仿真阶段你可以用虚拟终端手动敲几个字节，模拟上位机发送握手帧，看看程序有没有正确进入等待状态。

4.3 按键处理与 P0 口上拉

按键模型搜BUTTON，一个按键两个引脚，一端接地、一端接 IO，同时接一个上拉到 VCC，按下时 IO 读到低电平。这套接法在 P1、P2、P3 口上没问题，因为这几个口内部有弱上拉。但 P0 口不行，P0 是开漏的，必须外接 10K 上拉电阻，否则不管你按不按，读到的永远是低电平。

消抖这件事在仿真里有个便利：你可以把按键接到脉冲源上，让它按精确的时间间隔触发，省掉自己手按的随机性。比如让脉冲源每 200 毫秒给一个下降沿，就相当于一个很稳定的自动按键。用这个办法测按键计数功能，能很快发现计数值偶尔多一或者少一的问题，这类问题在实物上因为手按速度不稳定，反而很难复现。

4.4 电机与测速仿真的边界

小车上用的直流电机，在 Proteus 里搜MOTOR或者DC MOTOR,能找到一个带两个引脚的电机模型，仿真时它会显示转速和转向。测速的常规做法是在轮子上装编码器，输出脉冲给单片机的计数器引脚或者外部中断引脚。

仿真的局限就在这里：Proteus 的电机模型不输出编码器脉冲，你得自己用DCLOCK或者脉冲源模拟编码器信号，接到计数器引脚上。这样做能验证的程序部分是：计数器的初值配置、中断里的计数累加、单位时间内的脉冲换算成转速、显示的刷新。验证不了的部分是：真实电机启动时的堵转、加减速曲线、脉冲抖动。我的经验是，把测速算法在仿真里调通，然后实物上只调滤波和标定这两个参数，工作量能减少一半以上。

PWM 调速部分，用虚拟示波器看输出引脚，能直接看到占空比的变化，这部分仿真非常可靠。要注意的是 Proteus 的电机是惯性模型，PWM 频率太低的时候，你会看到转速剧烈波动，这个现象在实物上也存在，不算仿真误差。

4.5 示波器波形怎么看、怎么"锁住"

热词里有人问 "在 proteus 内的哪个示波器可以锁住图像",这个问题背后的真实需求是：波形一直在动，看不清一次触发的完整时序。

Proteus 里有两个工具可以做这件事。一个是OSCILLOSCOPE，四个通道，适合看模拟波形和低频数字波形。它的触发设置里有电平调节和边沿选择，把触发电平调到一个稳定的位置，波形就不会乱滚了。另一个是Digital Analysis（数字分析图表）,这个工具比示波器更适合抓协议时序，因为它记录的是逻辑电平的变化历史，把时间轴拉宽之后，一帧串口数据或者一段 I2C 时序能完整显示在一屏里，不会像示波器那样只能看一个瞬间。

真正意义上的"锁住"图像，最简单的办法是暂停仿真。Proteus 界面下方有一个暂停按钮，运行中按下它，整个电路的时间就停住了，波形定格在屏幕上，你可以慢慢用光标测量。这个方法我几乎每次调时序都会用，比调触发器设置快得多。

5. 仿真发散、时间不走、突然卡死的处理

热词里出现了 "仿真发散" 这个词，说明不少人碰到过仿真跑着跑着就崩掉的情况。这类问题的成因和解决办法，和前面讲的纯数字逻辑问题完全不是一回事。

5.1 仿真发散的本质是迭代不收敛

Proteus 的数字部分用的是事件驱动仿真，模拟部分用的是 SPICE 类的迭代求解。迭代求解需要一个收敛的过程：电路里每个节点在每个时间步上都要算出一个电压值，算到前后两次结果足够接近才算收敛，然后进入下一个时间步。如果电路里有强非线性元件（可控硅、开关电源的开关管、运放的正反馈、二极管整流的非线性），可能出现无论怎么迭代都收敛不了的情况，这时候仿真就报错或者直接停住。

常见的处理手段有这么几条，按优先级排：

1. 给理想元件加"现实一点"的寄生参数。比如在两个节点之间并联一个很大的电阻（1M 欧姆以上），或者串联一个很小的电阻（零点几欧姆）。这些元件在实际电路里本来就存在，加上它们往往能让迭代稳定下来。
2. 降低仿真精度要求。在仿真设置里放宽相对误差和绝对误差的阈值，牺牲一点点精度换取收敛。
3. 把开关器件换成理想模型。可控硅、MOS 管的非线性模型最难收敛，如果只是验证控制逻辑，换成理想开关模型会好很多。
4. 减小最大时间步长。步长太大，迭代容易在跳变点附近震荡，把最大步长调小能改善，代价是仿真变慢。

5.2 时间不走和突然变慢

有一种情况和发散完全相反：仿真看起来在运行，但时间轴不动，什么反应都没有。

最常见的原因是程序卡在某个等待循环里。比如等一个永远不会到来的中断标志、等一个被误清除的标志位、串口接收时忘了判断。仿真不会报错，就是安静地卡着。判断方法很直接：看仿真时间有没有在走。如果时间在走但功能不对，是逻辑问题；如果时间根本不动，是程序卡死了。

另一种情况是仿真突然变得极慢。原因通常是模拟元件数量太多、示波器一直开着、或者虚拟终端的输出缓冲爆了。我处理这类问题的办法是：把示波器关掉再跑一遍，如果速度恢复正常，就说明是波形记录拖慢的，需要的时候再打开。另外，串口输出如果是在主循环里不停地发，也会严重拖慢仿真速度，调逻辑的时候先把这些输出注释掉，需要看数据的时候再打开。

5.3 常见报错信息对照

这张表我建议存下来，下次碰到报错先对号入座，比从零开始猜效率高太多。

6. 从仿真迁移到实物时必须重做的部分

仿真跑通了，接下来是打板、焊件、上电。这一步如果直接把仿真里的设计照搬，大概率会翻车。下面这几件事是我每次迁移都会重新过一遍的。

6.1 电路层面必须补的东西

限流电阻和上拉电阻。前面反复提过，仿真里它们不影响结果，实物上它们决定器件活不活。LED 串 220 欧姆到 1K，P0 口上拉 10K 排阻，按键上拉 10K，这些都是肌肉记忆。

电源滤波。仿真里的电源是理想的，纹波为零。实物上的电源要加 100nF 的高频去耦电容和 10μF 到 100μF 的电解电容，而且位置要尽量靠近芯片的电源引脚。我见过太多"程序跑着跑着复位"的案例，最后都是去耦电容没放好。

驱动能力评估。单片机一个 IO 口的灌电流和拉电流是有限制的，驱动继电器、电机、蜂鸣器这类负载，必须加三极管或者专用的驱动芯片，不能直接接。仿真里你直接接上去它照样"工作",这是它最危险的误导。

复位电路和看门狗。仿真里很少会因为干扰复位，实物上干扰无处不在。RC 复位电路的电容取值要考虑上电时间和可靠性，如果有条件，把看门狗也打开，程序跑飞之后能自动恢复。

6.2 延时函数的重新标定

软件延时函数在仿真里的执行时间和实物上基本一致，因为两者都基于指令周期。但有两个变量会让它偏掉：一是晶振的实际频率误差，二是编译器优化等级的变化。同一个空循环，优化等级从 Level 0 调到 Level 8，实际延时可能差一倍。

我的建议很明确：凡是超过 1 毫秒的延时，一律用定时器实现。定时器的延时由硬件计数决定，不受编译器优化影响，唯一的变量是晶振频率，而这个误差通常在几十 ppm 级别，可以忽略。单总线、红外解码这类对时序敏感度高的协议，更是必须用定时器或者精确的汇编延时。

6.3 分模块迁移的验证顺序

不要一次性把所有外设都焊上去调试，那样出了问题你完全不知道是哪个模块引起的。我的迁移顺序是这样的：

第一步，最小系统单独验证。只焊单片机、晶振、复位、电源，烧一个点灯程序，灯亮了说明基础没问题。这一步能排除掉大部分焊接和电源问题。

第二步，逐个外设单独验证。先焊数码管，验证显示；再焊按键，验证输入；再焊串口，验证通信。每个模块验证完就固定下来，不要再动。

第三步，保留一个调试窗口。不管项目多小，我都会留出一路串口作为调试输出，把关键变量和状态码打出来。这一步在实物调试阶段的救命程度，怎么强调都不过分。

第四步，联调并记录现象。所有模块合在一起之后，观察是否出现单独测试时不存在的现象，比如按键按下时显示闪一下，这种往往是电源或者中断优先级引起的。

7. 课程设计与毕业设计场景下的高效用法

最后说一个很实际的场景。我帮不少人看过单片机相关的课程设计和毕业设计，发现一个共性问题：时间都花在了重复搭环境上，真正做方案的时间反而很少。这里分享几个提高效率的做法。

元件库自己整理一份。把常用的单片机、数码管、按键、电阻电容、串口终端、示波器这几个元件放在一个自建的工程模板里，存成.DSN文件。下次开新项目直接另存为，省掉每次从库里翻找元件的时间。我用这个方法把开工准备时间从半小时压缩到两分钟。

仿真录像比截图更有说服力。Proteus 的动画录制功能可以把仿真的运行过程存成文件，答辩或者汇报的时候放一段运行录像，比一张静态截图直观得多。录制前记得把仿真速度调快，同时把示波器和虚拟终端关掉，不然录出来的画面又卡又乱。

代码框架分成三层。底层是硬件驱动（GPIO、定时器、串口），中间层是设备驱动（数码管、按键、传感器），上层是业务逻辑（菜单、状态机、算法）。这三层分开写，仿真阶段验证底层和中间层，实物阶段重点调底层，业务逻辑基本不用动。这个结构看起来是"多写了代码",实际上省下的是反复重写的成本。

每条结论都留一份可复现的最小工程。这句话是我这些年体会最深的一条。调试过程中确认"某个接法可行"或者"某个参数不对"的时候，随手存一个最小工程，命名写清楚结论。等到几个月后再遇到同类问题，直接打开那个工程对照，比重新推理快十倍。仿真这件事最大的价值不在于省下几块板子的钱，而在于它让你有机会把每一个判断都变成可重复验证的实验。我用 Proteus 快十年，真正帮到我的从来不是它漂亮的界面，而是它让我在动手焊之前，就已经把该犯的错都犯过一遍了。