51单片机流水灯PROTEUS仿真：电路搭建、C51实现与定时器调参

简介：这是一份面向51单片机初学者、课程实验与电子设计入门者的流水灯仿真资料包，围绕8个LED轮流点亮、逐位累加点亮及全亮后蜂鸣器提示等效果展开，可用于理解端口输出、延时控制与循环结构。压缩包共18个文件，约985KB，包含C语言源码、HEX烧录文件、Keil工程与配置、A51启动代码、Proteus仿真相关文件以及MP4效果演示，便于直接编译、仿真对照和快速复现实验现象，省去从零搭建工程的时间。已有5389人学习下载，说明其作为课堂练习与自学案例具有较高参考价值。读者可据此观察多种流水灯模式的实现差异，借助源码与工程文件排查延时、端口驱动和蜂鸣器控制问题，也能用演示视频比对运行效果；对端口驱动、延时函数与循环结构的理解尤为直观，适合作为51单片机入门阶段的完整练习素材。

1. 流水灯不是交完就忘的入门题：51 单片机与 PROTEUS 仿真串起来的第一次闭环

很多人把流水灯当成学完就丢的作业，我带的几个新人里，十个有九个能背出“P1 口轮流输出低电平”，真到 PROTEUS 里搭一遍，八个会卡在灯不亮、程序加载不进去、仿真跑起来节奏完全不对。这套 C51 流水灯仿真资源的价值就在这儿：它把 51单片机 与 PROTEUS仿真 绑成一条可复现的链路——Keil 里编出 HEX，PROTEUS 里挂上晶振与复位电路，八个 LED 按自己的节奏跑起来。适合刚摸 51、想在不烧坏元件的前提下把 GPIO 输出、软件延时、循环移位一次过完的人，也适合拿它当模板去套其它外设 Demo 的熟手。八个灯看着简单，真要把“电路对、代码对、时序对”三件事同时按住，坑一点不少。

2. 先让电路立住：PROTEUS 里搭 51 最小系统与八路 LED 驱动

仿真跟实物最大的差别，是实物焊错了冒烟，仿真画错了只会安静地不亮，你连往哪儿查都不知道。所以电路这一章我建议一步一停：先把最小系统画对，再把 LED 挂上去，最后才谈代码。整份工程在 PROTEUS 里就是一张图纸，所有元件从左侧元件模式里的 P 按钮调库，搜索关键字直接输型号缩写即可。下面按我自己的搭建顺序走一遍，顺序别乱，乱了后面排查会很痛苦。

2.1 元件清单：最小系统的四类东西一次凑齐

51 的最小系统就四块：单片机本体、时钟（晶振 + 两个起振电容）、复位（电容 + 电阻）、电源与地。LED 部分再补限流电阻和发光二极管。我把关键元件列成一张表，按这张表搜库基本不会漏。

搭建顺序上，我一般先把 AT89C51 拖到图纸中央，再把晶振和两个 30pF 电容接到 XTAL1、XTAL2 两个脚上，电容另一端统一接地；接着画复位支路，10uF 电解电容正极接 VCC、负极接 RST，RST 再经 10k 电阻下地；最后给单片机补上 VCC 与 GND 端子。这一步做完，先别急着加 LED，用一个最简单的空 main 函数编个 HEX 加载进去，看 PROTEUS 有没有报“CPU 未运行”之类的告警，确认最小系统是活的，再往下走。

2.2 LED 接低电平侧：灌电流比拉电流靠谱得多

新手最容易在这里翻车：把 LED 阳极接 P1 口、阴极接地，写成 P1 = 0xFF 期望全亮，结果仿真里一片漆黑。原因是 51 的 I/O 口结构属于准双向口，输出高电平时靠内部弱上拉，能给出的拉电流只有几十微安级别，根本带不动 LED；而输出低电平时是强下拉，灌电流能力可以到十几毫安。所以正确接法是：VCC → 限流电阻 → LED 阳极 → LED 阴极 → P1 口，端口写 0 灯才亮，写 1 灯灭。

限流电阻的取值按欧姆定律算一遍就清楚了。假设 LED 正向压降约 1.8V，期望单路电流 8～10mA，则 R = (5V − 1.8V) / 0.01A ≈ 320Ω，取标称值 330Ω 即可。八路并联时总灌电流接近 80mA，已经超过单端口推荐值，仿真里不会烧，但如果你打算照着这份图去做实物，建议改成两路一组轮流点亮，或者用 74HC245 之类的缓冲器扩流，这一点在后面第 5 章还会提到。另外，如果你坚持用 P0 口，务必加 10k 上拉排阻，P0 是开漏结构，不加上拉连高电平都出不来。

2.3 晶振、复位与 EA 脚：三个最容易被漏画的连接

最小系统里最容易漏的是 EA 脚。AT89C51 的 EA（外部访问允许）必须接高电平，CPU 才会从内部 Flash 取指令；悬空或者接地，程序计数器指向外部存储器，仿真里表现为 PC 乱跑、灯完全没有规律。有些版本的器件模型把 EA 内部默认拉高，你换了模型之后行为就可能变，所以图纸上老老实实画一根线到 VCC，别赌。

晶振频率的选择也有讲究。12MHz 一分频后机器周期正好 1μs，算延时常数最省心；11.0592MHz 是为了串口波特率整除而生的，跑流水灯反而不如 12MHz 好算。这份仿真工程里我用的是 12MHz，后面所有延时的参数都按这个前提标注，你换晶振就得按比例重算，第 4 章会把换算关系写清楚。

复位电路需要注意的是电容极性：电解电容正极朝 VCC，画反了仿真不报错，但上电复位波形会不对。如果仿真里出现“程序只跑一次就停住”，先回头看一眼这个电容的方向和容值。

2.4 用总线把八根线收成一根，图纸才看得下去

八个 LED 各自拉一根线到 P1.0～P1.7，图纸会变成一团乱麻，改起来也容易接错位。常规做法是走总线：从 P1 口引一根 BUS 线，八个 LED 分支各自拉一小段线，末端用“线上标号”标成 P1.0 到 P1.7，PROTEUS 会按标号自动连通。这么画的好处是，你改端口时只改标号，不用重新拖线；排查时也能一眼看出哪一路的标号写错——这是最常见的一种“灯少亮一个”的原因，我在第 5 章会单独列出来。

总线画完，建议在每个 LED 支路旁边放一个电压探针（Voltage Probe），仿真时能直接看到该点的电平高低，比盯着灯的颜色猜要准得多。这一步算是白送的自检手段，很多人不用，排查时就只能靠删代码试错，效率差一大截。

3. C51 侧的三条实现路线：位操作、循环移位与查表法

电路画对之后，代码其实不复杂，但写法有好几种，各自适用的场景不一样。选哪一种，取决于你要的是“看懂原理”还是“后面好扩展”。我一般建议新手三条都写一遍，写完你就明白为什么老手最后都收敛到查表法上去了。下面三段代码都基于同一个前提：LED 阳极接 VCC，端口写 0 点亮。

3.1 位操作法：最直白，也最容易写死

位操作法的思路是把每个引脚当成一个独立的开关，用sbit定义出来，然后一条一条地赋值。这种写法对理解端口电平最直观，缺点是灯一多代码量就爆炸，而且改灯序要逐行改。

#include <reg52.h> /* 用 sbit 把 P1 口的 8 个引脚逐个命名，方便按位操作 */ sbit LED0 = P1^0; sbit LED1 = P1^1; sbit LED2 = P1^2; sbit LED3 = P1^3; sbit LED4 = P1^4; sbit LED5 = P1^5; sbit LED6 = P1^6; sbit LED7 = P1^7; /* 粗延时：12MHz 晶振下，内层约 1ms 一档，具体值需实测标定 */ void delay_ms(unsigned int ms) { unsigned int i, j; for (i = ms; i > 0; i--) for (j = 110; j > 0; j--); } void main(void) { while (1) { LED0 = 0; delay_ms(200); LED0 = 1; /* 点亮第 1 个，熄灭 */ LED1 = 0; delay_ms(200); LED1 = 1; LED2 = 0; delay_ms(200); LED2 = 1; LED3 = 0; delay_ms(200); LED3 = 1; LED4 = 0; delay_ms(200); LED4 = 1; LED5 = 0; delay_ms(200); LED5 = 1; LED6 = 0; delay_ms(200); LED6 = 1; LED7 = 0; delay_ms(200); LED7 = 1; } }

这段代码里delay_ms的内层循环次数 110 是个经验值，不是理论值。51 的每条指令周期数不一样，编译器优化等级也会影响，所以这个数字必须在你的编译环境下实测：把延时设成 1000ms，用 PROTEUS 的虚拟示波器或者秒表对着看，偏大就减、偏小就加，标定一次以后一直用。参数说明上，ms就是毫秒数，i控制外层循环次数，j是内层空转次数，两者相乘才是真正的延时，别只调其中一个。

3.2 循环移位：_crol_与_cror_的正确打开方式

只要灯序是“一位一位往后挪”，移位法就是最省事的写法。C51 的 Keil 编译器在<intrins.h>里提供了_crol_（循环左移）和_cror_（循环右移），它们跟普通的<<不一样：普通左移会把移出去的高位丢掉、低位补 0，循环移位则是把移出的位补回另一端，八个灯才能转成一个闭环。

#include <reg52.h> #include <intrins.h> /* _crol_ / _cror_ 都在这个头文件里 */ void delay_ms(unsigned int ms) { unsigned int i, j; for (i = ms; i > 0; i--) for (j = 110; j > 0; j--); } void main(void) { unsigned char led = 0xFE; /* 1111 1110：P1.0 为低，第一个灯亮 */ while (1) { P1 = led; /* 整字节输出，比逐位赋值快且不易错 */ delay_ms(200); led = _crol_(led, 1); /* 循环左移一位，0 的位置往高位走 */ } }

这里有两个参数值得说清楚：0xFE是初始图案，最低位为 0 表示第一个灯亮；_crol_的第二个参数是移动位数，写 1 就是每次挪一格，写 2 就是隔一个灯亮，用来做“跳灯”效果很方便。想看反向流动就把_crol_换成_cror_，初始值改成0x7F。忘加<intrins.h>是最常见的编译错误，报错信息通常是undefined identifier，看到这几个字先翻头文件。

从仿真观感上说，整字节赋值比逐位赋值更“整”，因为八个引脚是同一时刻被改写的；逐位写法在两次赋值之间存在极短的时间差，理论上会出现一个灯还没灭另一个就亮的瞬间，人眼看不出来，但如果你的示波器探针挂着看波形，能抓到毛刺。这也是我推荐移位法的实际理由，不只是代码短。

3.3 查表法：用一张表管住所有灯效序列

当灯效从“单向流”变成“来回流 + 全亮全灭 + 呼吸”这类组合时，移位法就开始别扭了。这时候把每一帧的端口值预先写进一个code数组，主循环只负责按索引取值和延时，逻辑与数据就分开了。

#include <reg52.h> /* code 关键字把表放进 Flash，不占宝贵的 128 字节 RAM */ code unsigned char pattern[] = { 0xFE, 0xFD, 0xFB, 0xF7, 0xEF, 0xDF, 0xBF, 0x7F, /* 正向流一遍 */ 0x7F, 0xBF, 0xDF, 0xEF, 0xF7, 0xFB, 0xFD, 0xFE, /* 反向流回来 */ 0x00, 0xFF /* 全亮一下，全灭 */ }; #define PATTERN_LEN (sizeof(pattern) / sizeof(pattern[0])) void delay_ms(unsigned int ms) { unsigned int i, j; for (i = ms; i > 0; i--) for (j = 110; j > 0; j--); } void main(void) { unsigned char i = 0; while (1) { P1 = pattern[i]; /* 取第 i 帧图案输出 */ delay_ms(150); i++; if (i >= PATTERN_LEN) /* 走到表尾回到表头 */ i = 0; } }

sizeof(pattern) / sizeof(pattern[0])这行算的是表长，好处是你往表里加帧、删帧都不用改循环边界，这是把“魔法数字”从代码里赶出去的标准做法。code关键字必须加，51 的 RAM 只有 128 字节，一张几十字节的表丢进 RAM 很容易跟其它变量打架，症状是程序跑着跑着图案乱了——这类问题在仿真里也照样复现，别以为仿真就不会内存溢出。

3.4 从 Keil 到 PROTEUS：HEX 文件是怎么被吃进去的

代码写完，编译链路有三步必须逐个确认，少一步仿真就只会给你一个不动的画面。第一步，Keil 新建工程时器件要选对，必须选 Atmel 的 AT89C51 或 AT89C52，选成别的型号，寄存器地址和中断向量可能对不上；第二步，工程选项的 Output 页里勾上“Create HEX File”，这一步不做，编译成功也不产生 HEX；第三步，回到 PROTEUS，双击单片机元件，在 Program File 一栏里选中刚生成的.hex，同时把 Clock Frequency 填成与图纸晶振一致的值。

第三步里的 Clock Frequency 经常被忽略。它不影响电路里晶振元件的行为，只影响 PROTEUS 内部对 CPU 指令时序的模拟速度。填错了不会报错，只会让你觉得“延时怎么跟算出来的不一样”。我在第 4 章会专门讲这三处频率怎么对齐。

4. 节奏从哪儿来：软件延时标定、定时器中断与晶振频率对齐

流水灯真正的技术含量不在“灯会不会亮”，而在“节奏对不对”。同样一份代码，延时参数差一倍，观感就差出一个档次；再往深里说，软件延时和定时器中断是两种完全不同的时间管理思路，前者简单但会阻塞 CPU，后者复杂一点但能腾出主循环干别的事。这一章把两条路都走一遍，顺带把晶振这个隐变量按住。

4.1 软件延时不是抄来的：用循环次数标定真实毫秒

网上流传的for(j = 110; j > 0; j--)这类写法，本质上是“在某个特定编译器、特定优化等级、特定晶振下大约 1ms”，换个环境就失效。你不能把它当成常数用，只能当成一个待标定的系数。

标定方法很土但有效：把延时函数改成delay_ms(1000)，在 PROTEUS 里跑起来，用虚拟示波器接一个 LED 引脚，量两个下降沿之间的时间；没有示波器就用秒表数 10 次闪烁的总时长再除以 10。偏差在 ±5% 以内就可以接受，人眼对流水灯节奏的敏感度大概就是这个量级。偏差大了就按比例缩放内层循环次数。

提示：Keil 的优化等级（Options for Target → C51 → Optimization）会显著改变空循环被编译成几条指令，标定必须在最终使用的优化等级下做，不能在 Debug 档标完再切到 Level 8 发布。

软件延时的代价是 CPU 全程空转。八个灯 200ms 一帧，一轮下来 1.6 秒，这一秒多里单片机什么都干不了。如果你的项目后面还要读按键、扫数码管，软件延时会让按键响应变得极其迟钝——这是新手做多功能小系统时最典型的“按键要按很久才有反应”的成因。

4.2 定时器 0 方式 1 中断：把节拍从主循环里拆出去

把节拍交给硬件定时器，主循环就解放了。思路是：定时器每 1ms 溢出一次，中断服务程序里累加计数，攒够 200 次就切换一帧图案。主循环只负责“看到标志就换图”，其余时间爱干嘛干嘛。

#include <reg52.h> #include <intrins.h> volatile unsigned int tick = 0; /* 毫秒计数，中断里改，必须加 volatile */ volatile bit frame_flag = 0; /* 换帧标志，主循环轮询 */ /* 定时器 0 初始化：方式 1，16 位定时，12MHz 下 1ms 一中断 */ void timer0_init(void) { TMOD &= 0xF0; /* 清掉 T0 的低 4 位，保留 T1 配置 */ TMOD |= 0x01; /* T0 工作在方式 1（16 位定时器） */ TH0 = 0xFC; /* 65536 - 1000 = 64536 = 0xFC18 */ TL0 = 0x18; ET0 = 1; /* 开定时器 0 中断 */ EA = 1; /* 开总中断 */ TR0 = 1; /* 启动定时器 0 */ } /* 中断服务程序：入口编号 1 对应定时器 0 */ void timer0_isr(void) interrupt 1 { TH0 = 0xFC; /* 方式 1 不自动重装，必须手动补初值 */ TL0 = 0x18; tick++; if (tick >= 200) /* 攒够 200ms */ { tick = 0; frame_flag = 1; /* 通知主循环换帧 */ } } void main(void) { unsigned char led = 0xFE; timer0_init(); P1 = led; while (1) { if (frame_flag) { frame_flag = 0; led = _crol_(led, 1); P1 = led; } /* 这里可以插入按键扫描、串口收发等其它任务 */ } }

参数上有三处要盯死。第一，TH0/TL0的初值按公式65536 − 定时机器周期数算，12MHz 下机器周期 1μs，1ms 就是 1000 个周期，得0xFC18；换成 11.0592MHz，1ms 对应 921.6 个机器周期，初值要改成约0xFC66，差一点点，累积几分钟就能看出走时偏差。第二，方式 1 不自动重装，中断里必须手动补初值，忘了补，第二次中断的间隔就变成 65.536ms，灯会突然变慢。第三，tick和frame_flag在中断与主循环之间共享，必须加volatile，否则编译器优化可能把它缓存进寄存器，主循环永远等不到标志变化——这个坑在仿真里同样会翻车，而且现象非常像“中断没进”。

中断方式的观感比软件延时稳得多，因为定时精度由晶振决定，不受主循环里其它代码执行时间的影响。

4.3 晶振频率必须三处一致：图纸、代码、PROTEUS 属性

晶振这件事，我见过太多人栽在同一处：图纸上画的是 12MHz，代码里的定时器初值按 12MHz 算，但 PROTEUS 里单片机元件的 Clock Frequency 属性还留着默认的 12MHz 或者被误改成 6MHz，三处只要有一处不一致，节奏就全乱。

对齐的方法是把它当成一个检查清单来走：先看图纸上 CRYSTAL 元件的频率值，再看代码里TH0/TL0或延时循环是按哪个频率算的，最后双击单片机看属性面板里的 Clock Frequency。三处必须字面一致。PROTEUS 里这个属性填的是“仿真时假定 CPU 跑多快”，它跟图纸上的晶振元件是两套东西，初学者很容易只改一处。

顺便说个血泪经验：PROTEUS 的仿真速度受电脑性能影响，跑复杂图纸时会掉帧，看起来像“流水灯偶尔卡一下”。这不是你的代码问题，把图纸里无关的探针和虚拟仪器关掉，帧率就回来了。判断依据是——如果在暂停后单步执行时序正常，那多半就是仿真帧率的事，别去改代码。

5. 避坑排查：仿真里灯不流水时的五类故障与定位顺序

仿真最大的好处是错了不会烧东西，最大的坏处是错了没有任何提示。下面这五条是我在实际带人过程中反复见到的，按“现象 → 原因 → 解决”的顺序写，遇到问题照着对号入座，比盲目删代码快得多。

5.1 五条典型故障的现象、原因与处理

现象一：八个灯全亮或者全灭，怎么改代码都不动。原因通常出在电平极性上。如果你的 LED 是阳极接 VCC、阴极接端口，那么端口输出 0 才亮；反过来接成阳极接端口、阴极接地，就只能靠那点微弱拉电流，仿真里基本不亮。另一种情况是初始值写成了0xFF加移位，等于从一个全灭的状态开始挪，看起来就是“一直不亮”。 解决方式是先断开代码，手动在 PROTEUS 里给 P1 口强制赋值（用 Stimulus 或者直接改元件属性），确认硬件极性没问题，再回去查代码。

现象二：Keil 编译 0 错误 0 警告，PROTEUS 里毫无反应。原因八成是没勾“Create HEX File”，或者勾了但 PROTEUS 里没加载。还有一种隐蔽情况：加载了旧版本的 HEX，你没注意编译输出路径改了。 解决方式是到工程目录下确认.hex文件的修改时间是不是刚刚，再双击单片机核对 Program File 路径。养成习惯：每次改完代码先看一眼文件时间戳。

现象三：灯只亮一个，不往下走。最常见的原因是移位函数没用对。用了普通左移<<而不是_crol_，移几次之后低位全是 0，图案就卡死在全亮；或者忘了#include <intrins.h>，编译直接报未定义标识符。 还有一种可能：延时太短，200ms 变成 2ms，人眼看到的就是“一个灯常亮”。把延时临时调到 1000ms 观察一下就能区分是逻辑问题还是节奏问题。

现象四：灯序错位，比如该第二个亮的结果第四个亮。原因是总线标号和引脚没对上。用总线画图时，八个分支靠线上标号连接，标号写成P1.1却接到了第三路 LED 上，图上看不出来，仿真就错位。 解决方式是逐个点开每个分支的标号核对，或者干脆先把所有 LED 直接拉到 P1.0～P1.7 跑一遍验证代码，确认代码没问题再切回总线画法。

现象五：仿真跑起来一顿一顿，或者比预期快很多。两个方向查。慢，多半是图纸太复杂导致仿真帧率下降，关掉虚拟示波器和多余探针；快，基本可以锁定是单片机属性里的 Clock Frequency 跟代码假设不一致，或者定时器初值没在中断里重装。 判断方法很直接：把延时从 200ms 改成 2000ms，如果观感变化比例对得上，说明是帧率问题（比例一致但整体偏慢），如果比例完全不对，就是频率配置错了。

5.2 一套从编译到仿真的定位顺序

故障现象千奇百怪，但排查路径可以固定下来，按这个顺序走，能砍掉大部分无效试错。

第一步，脱离电路看代码。把P1的赋值临时换成一个固定值0xAA，编译烧进去，如果灯呈现“亮灭亮灭亮灭亮灭”，说明端口和电路是通的，问题在逻辑；如果还是全亮全灭，问题在硬件。这一步能把问题域一刀切成两半。

第二步，看 HEX 是否真的更新。文件时间戳、加载路径、工程输出目录，三样逐一对。

第三步，看时序配置三处是否一致：图纸晶振、代码初值、PROTEUS 属性里的 Clock Frequency。

第四步，简化到最小可复现。把查表法退回移位法，把中断退回软件延时，把八个灯退回两个灯，一步步砍到能跑为止，再一步步加回去。这个方法笨，但对“改了十处不知道哪处坏的”这种情况最有效。

第五步，用探针而不是用眼睛。PROTEUS 的电压探针能直接告诉你某个引脚是高还是低、什么时候翻转，比盯着 LED 猜颜色可靠得多。尤其是排查“翻转了但灯不亮”这类问题时，探针一挂，问题立刻现形——要么是引脚翻了灯没接对，要么是灯接了引脚没翻。

6. 往上再走半步：把流水灯写成表驱动的灯效引擎与验证手法

三段代码写下来，你会发现真正能复用的不是某一段具体逻辑，而是“把灯效数据从执行逻辑里剥离出来”这个结构。我在第 3 章给的查表法还算原始，往上一层可以做成结构体数组，每一条记录描述一种灯效：图案指针、帧数、帧间隔、是否循环。主循环只做一件事——按当前灯效的节奏取帧输出。这么改完，加一种新灯效是往表里加一行数据，不用碰主循环一个字符。

#include <reg52.h> typedef struct { code unsigned char *pattern; /* 指向该灯效的图案表 */ unsigned char len; /* 该灯效共几帧 */ unsigned int interval; /* 帧间隔，单位 ms */ unsigned char loop; /* 1 循环，0 播完停住 */ } Effect; code unsigned char pat_flow[] = {0xFE,0xFD,0xFB,0xF7,0xEF,0xDF,0xBF,0x7F}; code unsigned char pat_blink[] = {0x00, 0xFF}; code Effect effects[] = { {pat_flow, 8, 150, 1}, /* 单向流动，150ms 一帧，循环 */ {pat_blink, 2, 500, 1} /* 全亮全灭，500ms 一帧，循环 */ }; #define EFFECT_CNT (sizeof(effects) / sizeof(effects[0]))

结构体的好处是把“节奏”和“图案”这两个正交的维度分开了。想让流动变快，改interval；想加一种新花样，加一行图案、加一条 Effect 记录，主循环里的索引逻辑完全不用动。这种改法在你后面要把流水灯扩成跑马灯、呼吸灯、甚至接上串口做远程控制时，能省掉大量重写成本。

验证手法上，有两个东西我建议养成习惯用。一是电压探针，挂在 P1.0 和 P1.7 两个端点，同时观察首尾两路，能一眼看出移位方向对不对、循环接缝处有没有跳变。二是 PROTEUS 的虚拟终端（Virtual Terminal），把它接到单片机的 TXD 上，在代码里给每次换帧打一个字符，你就能拿到一份带时间戳的换帧日志，用来核对实际帧间隔跟你设定的interval差多少。这比肉眼看灯准得多，尤其是在调 50ms 以下的高帧率效果时，肉眼根本分辨不出来。

还有一个容易被忽略的验证点：循环接缝。用移位法时如果忘了循环移位，从最后一帧跳回第一帧会闪一下；用查表法时如果表尾和表头的图案不衔接，同样会闪。把pattern表的首尾两帧都打印出来对比一下，或者干脆在探针上看跨越接缝那一次的波形，衔接是否平滑一目了然。

我踩过最不值当的一次坑，是花了一个下午怀疑定时器初值算错，最后发现是图纸上晶振元件的属性被我误设成了 6MHz，而代码和单片机属性都是 12MHz。从那以后我每次开新仿真工程，都强制走一遍“三处频率对齐 + HEX 时间戳确认 + 单灯极性验证”这三步，哪怕只是改一行代码。这三步加起来不到两分钟，能挡掉后面几小时的玄学排查。希望帮到你。

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