简介：这份压缩包面向单片机课程学习与电子设计入门者，聚焦 Keil 与 Proteus 的联合开发场景，提供一个可拆解的小型工程样例，帮助理解程序编写、编译输出到电路仿真的基本链路。包内共 21 个文件，压缩后约 124KB，涵盖 C 源文件、Keil 工程及工作区配置、Proteus 仿真工程与备份，以及 HEX 等编译输出；工程配置便于还原开发环境，仿真工程可用于对照软硬件联调，也便于初学者对照完整练习并理解工程结构。资源以 TempMeasure 工程为线索，适合查看源码组织、编译设置和仿真工程结构，也可作为课程设计、自学练习与排错参照，帮助定位工程打开、编译生成和仿真加载中的常见问题。目前已有 822 人学习，包体轻量、目录集中，适合快速浏览并取用其中的示例文件。

1. 板子还没到，代码先跑起来：一份 Keil + Proteus 的组合包

板子还在快递路上，器件还没下单，但时序对不对、状态机有没有死锁，这些事等不了。这时候最省事的组合就是：Keil 写代码、编译出 HEX，Proteus 搭电路、把 HEX 喂进去跑。这份 Keil Proteus.zip 把两套环境收在一起——一边是 Keil MDK 的编译工具链（8051 的 C51 和 Cortex-M 的 MDK-ARM 都在），另一边是 Proteus 的电路仿真环境，中间靠一个 .hex 文件对接。

单片机开发里最磨人的不是写代码，是“电路没搭好，我到底该怀疑软件还是怀疑硬件”。仿真把这个变量先按住：P1 口的电平、定时器的溢出、串口出去的每一个字节，你都能在同一个窗口里看到。这份资源适合正在做课程设计、毕业设计的人，适合带新人入门的工程师，也适合手上只有一块板、想同时验证四五个外设的老手。它不是硬件的替代品，是硬件到位之前的验证台。

2. 装完别急着新建工程：编译器分叉、路径规矩和 2KB 那道坎

2.1 先分叉：C51 和 MDK-ARM 装错半边等于白装

压缩包里通常并排放着两套安装程序：一套面向 8051 的 C51 编译器，一套面向 Cortex-M 的 MDK-ARM。两者共用同一个 uVision 界面，菜单长得几乎一模一样，但工程文件是不互通的。C51 工程里的 Device 选的是 AT89C51、STC89C52 这类 8 位机，头文件是reg52.h；MDK-ARM 工程选的是 Cortex-M 内核型号，寄存器定义来自器件包里的 CMSIS 头文件。新手最常翻的车是：拿 MDK-ARM 建了个工程，然后#include <reg52.h>编译不过；或者反过来，在 C51 里找 Cortex-M 的型号，翻遍器件树也找不到。

判断办法很直接，打开 Options for Target 看 Device 页。列表里每个器件都带内核描述、Flash 和 RAM 大小的，是 ARM 侧；只有一棵 8 位机型号树的，是 C51 侧。还有一个信号：MDK-ARM 需要额外装 Device Family Pack，Pack 没装的时候 Device 列表是空的或者只有两三个占位项——这不是装坏了，是器件支持还没落地。

提示：Proteus 的 VSM 模型库里，8051 系列的覆盖是最全的，Cortex-M 的模型要窄不少。第一次跑通整条链路，先用 51 走一遍，别一上来就拿 Cortex-M 试，否则你会同时面对“模型不支持”和“代码有问题”两个未知数。

2.2 路径、器件库、许可证：三条不能商量的硬规矩

第一条，安装路径全英文、无空格、无括号、无中文。这条听着像老生常谈，但它是后面所有“Unable to open hex file”“Cannot find file”报错的根源。C51 的编译器、链接器、以及 Proteus 读取 HEX 的那一步，对路径里的非 ASCII 字符处理得并不一致，你甚至能看到文件明明在那儿、软件却说找不到。我一般的做法是直接装到D:\MCU\Keil和D:\MCU\Proteus这种短路径下，工程目录同样放在这层下面，比如D:\MCU\proj\led_test。

第二条，工程不要放在桌面、OneDrive 同步目录或者带空格的“我的文档”下。同步盘会在编译过程中锁文件，表现为随机出现的Error: cannot open file；空格路径则会让部分命令行工具解析失败，这在后面用批处理跑编译时会直接暴露出来。

第三条，评估版的代码尺寸限制要提前知道。C51 评估版在目标代码超过 2KB 时会抛*** FATAL ERROR L250: CODE SIZE LIMIT IN RESTRICTED VERSION EXCEEDED，MDK-ARM 的门槛是 32KB。很多人第一反应是“我代码明明很短”，其实链接器算的是最终代码段大小，带上printf、浮点格式化、没用到的库函数，很容易就顶上去了。常见做法是先关掉printf里的浮点支持、把没用到的库函数裁掉，用小工程验证通链路之后再考虑授权的事。

Proteus 这边要确认的是 Library 目录能被正确索引。如果放置元件时报No model specified for U1，说明你选的这个型号只有 PCB 封装没有仿真模型——元件库里有大量“同名不同模型”的坑，比如某些存储器和接口芯片，选型时看元件属性里有没有 “MODEL” 或 “VSM” 字样，比看名字可靠。

2.3 二十行代码把工具链验通

新建工程、选器件、加一个main.c，先不接任何外设，就点一个灯。这段代码的作用不是学 GPIO，是确认“编译→生成 HEX→Proteus 加载→运行”这条链没有断在某一环。

#include <reg52.h> sbit LED = P1^0; /* 接 P1.0，Proteus 里串一个 220Ω 电阻到 LED 再到 VCC */ void delay_ms(unsigned int ms) { unsigned int i, j; for (i = ms; i > 0; i--) for (j = 110; j > 0; j--); /* 12MHz、12T 模式下约 1ms，优化等级不同会有偏差 */ } void main(void) { while (1) { LED = 0; /* 灌电流接法：输出低电平点亮 */ delay_ms(500); LED = 1; delay_ms(500); } }

这段代码里有三个参数值得说清楚。sbit LED = P1^0用的是 8051 的位寻址，P1 口可位寻址，所以能直接定义单个引脚，换成 P0 口也一样，但 P0 口在实物上没有内部上拉，驱动 LED 时接法要改。delay_ms里的 110 是空循环次数，按 12MHz 晶振、12 个时钟一个机器周期估算出来的经验值，它不是精确延时，编译器优化等级从-O0调到-O2时循环可能被整个优化掉，所以它只适合点灯，不适合做通信时序。第三个是电平极性：低电平点亮意味着 LED 阳极经限流电阻接 VCC、阴极接 IO，如果你在 Proteus 里接成了 IO→电阻→LED→GND，现象就是“灯常亮不闪”，很多人会误判成程序没跑。

验证成功的标志不是“灯亮了”，而是“灯以肉眼可辨的节奏在闪”。常亮说明程序卡在初始化、或者 HEX 根本没加载；完全不亮先看电源和极性。等这二十行能稳定闪起来，后面所有外设都是往这个骨架上挂东西。

3. HEX 是唯一接口：晶振、波特率和四组必须对齐的参数

3.1 让 MDK 吐出 HEX：一个勾选项和一条输出路径

默认情况下 MDK 编译完只生成.axf（ARM）或.omf（C51 的绝对目标文件），不生成 HEX。要让它吐 HEX，打开 Options for Target → Output 页，勾上Create HEX File，下面的 HEX 文件名保持默认即可；编译完在Objects\目录下会多出一个和工程同名的.hex。这一步没勾，Proteus 里加载时就会提示找不到文件，而很多人会先怀疑路径问题——其实文件压根没生成。

如果还想在编译后自动跑一步检查，可以在 User 页的 After Build/Rebuild 里挂一条命令。比如 ARM 侧用fromelf --text -c -o "$L@L.lst" "#L"反汇编出清单，方便对照启动代码；51 侧一般不需要。这个挂载点还有个实用玩法：编译完立刻把 HEX 复制到一个固定的out\目录，Proteus 只需要认这一个路径，避免你每次换工程都要改一次 Program File。

至于 HEX 本身，它是 Intel HEX 格式：每行以冒号开头，跟着长度、地址、记录类型、数据和校验和。知道这一点在排错时有用——打开 HEX 看第一行是不是:020000040000FA这类扩展地址记录，能快速判断编译器输出的地址空间对不对；如果整个文件只有一行:00000001FF，说明根本没有代码被链接进去。

3.2 晶振频率必须两头对齐：12MHz 和 11.0592MHz 不是随便挑的

这是整篇文章里最容易翻车、也最容易被忽略的一组参数。Proteus 里双击 MCU，属性面板上有一个Clock Frequency，默认 12MHz；而你在 Keil 里算定时器初值、算波特率时用的也是某个频率。这两个值必须一样，否则延时全部失真。

更麻烦的是串口。8051 方式 1 的波特率由定时器 1 的溢出率决定：baud = (2^SMOD / 32) × (fosc / (12 × (256 - TH1)))。把 9600 代进去算一下就知道为什么老工程师死守 11.0592MHz：这个频率能被 9600 整除得干干净净，TH1 取0xFD时误差为 0；换成 12MHz，最近的整数取值带来的误差接近 8.5%，接收端采样点会一路漂到帧边缘。

表里能读出一个结论：12MHz 下要么把波特率降到 2400，要么接受乱码。115200 在 12T 的 8051 上基本无解，得上 1T 型号或者换用定时器 2 作波特率发生器。

定时器初值同理，与其每次拿计算器按，不如写个小脚本固化下来：

def reload_16bit(fosc_hz, ms, prescaler=12): """12T 8051：一个机器周期 = prescaler / fosc 秒 返回 16 位定时器（方式 1）需要的初值，直接写 TH/TL""" machine_cycle = prescaler / fosc_hz # 12MHz 下 = 1us counts = int(round((ms / 1000.0) / machine_cycle)) if counts > 65536: raise ValueError("单次定时超出 16 位范围，改用多次中断累加") return 65536 - counts for ms in (1, 10, 20, 50): v = reload_16bit(12_000_000, ms) print(f"{ms:>3}ms TH=0x{v >> 8:02X} TL=0x{v & 0xFF:02X}")

prescaler这个参数是关键，它对应 12T 和 1T 单片机的差别：传统 8051 是 12 个时钟一个机器周期，很多增强型 1T 型号是 1 个或 6 个。填错这个数，定时会差 12 倍，现象是“数码管刷新快得像流水”或者“一秒变十二秒”。脚本里做了越界检查，因为 12MHz 下 16 位定时器最多只能定约 65.5ms，超过就得靠中断里累加计数，这是新手写长延时常踩的坑。

3.3 在 Proteus 里把 HEX 挂上去，让 MCU 真的开始跑

接线之前先说加载。双击 MCU 元件 →Program File一栏点文件夹图标，选Objects\下的 HEX →Clock Frequency改成和你代码里假设的一致（12MHz 就填 12M）→ 确定。如果你改了代码重新编译，Proteus 不会自动重载，必须手动再选一次文件或者重启仿真，这一点后面还会提。

然后是让 8051 跑起来的三件事。第一，EA 引脚（第 31 脚）必须接高电平，它决定从内部 ROM 还是外部存储器取指，悬空时模型的行为是不确定的，现象就是“灯一点反应没有”。第二，复位电路要画上，一个 10uF 电容到 VCC 加一个 10k 电阻到 GND 是最小配置，虽然 Proteus 的模型通常会自动上电复位，但画上它你能顺便验证复位逻辑。第三，电源和地别忘加——Proteus 里 MCU 的 VCC/GND 是隐藏引脚，默认连到同名网络，但如果你在别处用了VCC这个网络名又接了别的东西，就可能出现意外的电平。

判断“到底跑没跑”有个笨办法但很有效：在main的第一行翻转一个闲置 IO，然后用 Proteus 的电压探针或者示波器挂上去。有方波说明程序进去了，问题在外设；没方波说明连启动都没到，回头查 EA、复位、HEX 路径。

4. 外设仿真：数码管、矩阵键盘、串口和 ADC 的接线与代码骨架

4.1 数码管动态扫描与按键消抖：两段能直接抄的骨架

数码管在 Proteus 里有两类模型，共阴和共阳，段码表不一样。用错的表现很有辨识度：该显示1的时候出来个-或者乱码段，因为段码按位取反了。共阴的段码表是0x3F,0x06,0x5B,0x4F,0x66,0x6D,0x7D,0x07,0x7F,0x6F，共阳就是逐位取反。位选和段选共用一组 IO 时，动态扫描要在切换位选前先关段选，否则会有鬼影——这是仿真和实物都会出现的问题，只是仿真里看起来更干净，容易被忽略。

#include <reg52.h> /* 共阴段码 0-9，段选接 P0，位选接 P2 低 4 位 */ code unsigned char SEG[] = {0x3F,0x06,0x5B,0x4F,0x66,0x6D,0x7D,0x07,0x7F,0x6F}; void display(unsigned int val) /* 显示 0-9999，四位动态扫描 */ { unsigned char i; unsigned char buf[4]; buf[0] = val / 1000 % 10; buf[1] = val / 100 % 10; buf[2] = val / 10 % 10; buf[3] = val % 10; for (i = 0; i < 4; i++) { P0 = 0x00; /* 先关段选，消鬼影 */ P2 = ~(1 << i); /* 位选低有效 */ P0 = SEG[buf[i]]; delay_ms(2); /* 每位 2ms，整屏刷新约 125Hz */ } } unsigned char key_scan(void) /* 4x4 矩阵键盘，返回 1-16，无键返回 0 */ { unsigned char row, col, key = 0; for (row = 0; row < 4; row++) { P1 = ~(1 << row); /* 逐行拉低，其余行保持高 */ col = P1 & 0xF0; /* 读列线 */ if (col != 0xF0) { delay_ms(10); /* 消抖，别省 */ col = P1 & 0xF0; if (col != 0xF0) { while ((P1 & 0xF0) != 0xF0); /* 等松手，注意这里会阻塞扫描 */ key = row * 4 + (col >> 4) + 1; return key; } } } return 0; }

display里delay_ms(2)这个参数决定刷新率：每位 2ms、四位共 8ms，整屏约 125Hz，人眼看不到闪烁；调到 10ms 就会明显抖。key_scan里那个while等松手是个隐患，它会把整个扫描流程卡住，数码管在这段时间是停的。正确做法是把松手检测做成状态机、每轮扫描过一遍就返回，而不是死等——这段代码贴出来就是让你看到这个边界，实际项目里我不会这么写。另外矩阵键盘的行线要接上拉，Proteus 里如果你用的是BUTTON元件，记得在属性里把Pullup打开或者自己加排阻，否则读回来全是 0。

4.2 串口和虚拟终端：先对齐波特率，再谈协议

Proteus 里的VIRTUAL TERMINAL是验证串口最快的手段，接到 TXD/RXD 上，属性里设好波特率和数据位，运行后就能看到单片机吐出来的字符。它的坑集中在一个地方：终端上显示的波特率必须和你代码里初始化的一致，而且两边都要和晶振匹配，这就是 3.2 那张表的意义。

void uart_init(void) { TMOD &= 0x0F; TMOD |= 0x20; /* 定时器 1，方式 2：8 位自动重装，专门做波特率发生器 */ TH1 = 0xFD; /* 11.0592MHz + 9600bps + SMOD=0 的取值 */ TL1 = 0xFD; TR1 = 1; SM0 = 0; SM1 = 1; /* 串口方式 1：8 位 UART，波特率可变 */ REN = 1; EA = 1; ES = 1; } void uart_send(unsigned char b) { SBUF = b; while (!TI); /* 等发送完成标志 */ TI = 0; }

TH1 = 0xFD这个值只对 11.0592MHz 成立，换成 12MHz 必须改，否则终端上出现的是乱码而不是错误提示——乱码比报错更难查，因为你分不清是波特率错了还是数据内容错了。SMOD在 PCON 寄存器里，默认 0，如果要用翻倍的波特率记得先置位再算初值，很多人只改 TH1 忘了 SMOD，结果速度差一倍。中断方式接收时还要注意RI的清除时机，在中断服务函数里手动清零，别指望硬件自动清。

4.3 模拟器件的隐藏属性：LCD1602、ADC 和温度传感器

带“智能”的模型都有一堆属性面板上的参数，默认值往往不对，表现是“接线完全正确但屏幕不亮”。

LCD1602 的 VEE 是对比度电压，实物上接个 10k 电位器，仿真里直接接 GND 常常就能显示，但有些模型版本需要接一个中间电压，接错就是一行黑块。ADC0808 的 CLOCK 引脚是最容易被忘的，模型不会自己产生时钟，得挂一个DCLOCK激励源，频率设到 500kHz 左右，否则 EOC 永远不置位。DS18B20 读回 85℃ 是经典的“复位没成功”默认值，说明时序里的延时不对——仿真里延时是“真实时间”，你的delay_us如果被编译器优化掉了，时序立刻崩。

5. 排查清单：五个“编译过了但仿真不动”的现场

5.1 编译与链接阶段的三处拦截

现象一：编译报*** FATAL ERROR L250: CODE SIZE LIMIT IN RESTRICTED VERSION EXCEEDED，但代码看着不长。原因：链接器统计的是最终代码段，评估版 C51 的限制是 2KB。带一个printf加浮点格式化就能吃掉大半，sprintf更狠。 解决：先把printf换成自己写的串口输出函数，关掉浮点支持；再检查有没有把大数组定义成code之外的存储类型，无意中把常量放进了代码段。真需要大工程就上正式授权，别在这上面耗时间。

现象二：#include <reg52.h>报cannot open source input file。原因：工程建在 MDK-ARM 侧了，ARM 的器件包里没有 8051 的头文件，反之亦然。 解决：看 Options for Target 的 Device 页确认编译器分支，重建工程。这个错误一旦出现，说明你整条链路的起点就选错了，别试图手动拷头文件绕过。

现象三：编译通过，但Objects\下没有 HEX。原因：Create HEX File没勾，或者勾了但工程被设成了“只编译不链接”（Build 而非 Rebuild 时增量跳过了链接）。 解决：勾上选项后做一次 Rebuild All。顺便看一眼 Build Output 窗口末尾有没有creating hex file...这一行，没有就是没生成。

5.2 仿真运行阶段的两种沉默

现象四：点了运行，MCU 一点反应没有，电压探针全是低电平。原因：按概率排，EA 引脚没接高电平排第一，HEX 没加载或加载了旧版本排第二，晶振频率填错排第三。还有一种隐蔽情况：Proteus 在你修改代码期间一直开着，它缓存了旧的 HEX。 解决：先看 EA 有没有接 VCC，再看 Program File 路径是不是指向最新编译出来的那个文件，然后手动重新选一次文件、停掉仿真再启动。养成“改代码→重新编译→重新加载 HEX→重启仿真”这个固定动作，能省掉一半的自我怀疑。

现象五：串口终端里全是乱码，或者数码管显示的数字明显跑快/跑慢。原因：晶振频率两边不一致，或者波特率初值按 11.0592MHz 算、Proteus 里填的却是 12MHz。定时器类问题多半是prescaler用错，12T 和 1T 混了。 解决：把 Proteus 里 MCU 的Clock Frequency和代码里假设的频率写在纸上对一遍，再用 3.2 的脚本重算初值。串口调不通时先降到 2400bps 试，能通说明是误差累积问题而不是接线问题。

6. 把仿真当回归测试用：一条命令和一张偏差表

6.1 用命令行跑通“编译→检查→加载”的闭环

点鼠标点多了会发现，真正浪费时间的不是写代码，是“改一行→切窗口→点编译→切回来→重新加载 HEX”这套动作。uVision 支持命令行构建，把这一步固化成脚本，配合一个固定输出目录，Proteus 那边的 Program File 就永远不用改。

#!/bin/bash # 在工程根目录执行；UV4 的路径按实际安装位置改 UV4="D:/MCU/Keil/UV4/UV4.exe" PRJ="led_test.uvproj" "$UV4" -b "$PRJ" -j0 -o build.log || { echo "构建失败，看 build.log"; exit 1; } # 把 HEX 复制到 Proteus 固定读取的目录，文件名保持不变 cp "Objects/led_test.hex" "D:/MCU/proj/out/firmware.hex" || exit 1 # 检查 HEX 结尾是否有结束记录，只有一行说明没链接进代码 tail -n 1 "D:/MCU/proj/out/firmware.hex" | grep -q ":00000001FF" \ && echo "HEX 正常，可以去 Proteus 里启动了" \ || echo "HEX 异常：没有结束记录"

-b是批处理构建，-j0表示不弹窗、把输出写进日志，-o指定日志文件名。返回值非 0 就是失败，脚本直接中断，避免你拿着上一次的 HEX 去仿真还以为是新代码。最后那个grep检查的是 Intel HEX 的结束记录，看着简陋，但它拦下过一次“编译成功但链接被跳过”的事故——那次Objects\下躺着的是三天前的 HEX，我在 Proteus 里调了两个小时时序。

Proteus 侧没法完全脚本化，但有个替代方案：把整个仿真工程存成模板，MCU 的 Program File 固定指向out/firmware.hex，每次新建项目复制一份模板改电路，省掉重复配置。

6.2 仿真和实物的三处偏差，心里要有数

这张表的意思是：仿真能验证逻辑，不能验证电气。我吃过一次亏，仿真里 P0 口直接驱动数码管段选跑得好好的，实物上亮度暗得几乎看不见，因为 P0 没有内部上拉，灌电流也不够。从那以后我每次在 Proteus 里画完电路，都会强制走一遍“把上拉、限流、复位、去耦按实物补齐”的流程，哪怕仿真根本不需要这些元件——仿真跑得顺不代表板子上能跑，但仿真里就把电路画全，至少能提前发现逻辑上的冲突。

这套东西的价值不在于替代打板，而在于把“软件对不对”和“硬件对不对”这两件事拆开验证。压缩包里的两套环境按第 2 章的路径顺序装一遍，用第 2.3 节那二十行代码点通第一个灯，后面所有外设都是往这个骨架上挂。希望帮到你。

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