简介：这是一份面向STM32初学者及毕业设计选题学生的Proteus万年历仿真实验资源包，基于STM32完成温度显示与闹钟设置，将单片机程序设计、外设驱动与仿真调试思路融为一体，非常适合作为课程设计或毕设的参考方案。包内共291个文件，压缩包仅8.97MB，主要包含Proteus仿真工程文件、Keil工程配置、C语言源码与头文件、编译生成的hex烧录文件以及相关说明文档，既有可直接运行的工程，也有便于阅读的代码结构。目前已有489人学习下载，资源与B站视频内容一致，可配合视频边看边练，既能直接打开仿真观察运行效果，也能对照源码理解温度读取、按键控制、闹钟触发等功能的实现方式，并在此基础上进行二次修改和功能扩展。整个包体量小、模块清晰，是快速上手STM32与Proteus联调的实用资料。 单片机的万年历项目，几乎每个学嵌入式的人都做过或者打算做一次，但真要做到“能显示日期、能调时间、能设闹钟、还带温度”的一体化作品，仿真里外的坑还是挺多的。最近经常有人问我标题里这种“Proteus仿真 + STM32 + 温度显示 + 可设闹钟”的组合该怎么做，有人卡在Proteus里STM32跑不起来，有人万年历日期永远不对，还有人闹钟到点不响。这个项目最适合两类人：一是课程设计需要交仿真和源码的大学生，二是想从“点灯”进阶到“完整小系统”的自学者。看这篇文章，你能把项目从需求拆解、电路搭建、源码设计到仿真调试整条线走通，重点是避免我在Proteus里踩过的那一堆坑。
1. 项目整体规划：万年历并不是“堆硬件”
1.1 万年历项目的三层逻辑：时间、日期与人机交互
万年历乍一看就是“把时间和日期显示出来”，但真正拆开，它其实是三层独立逻辑的组合。
第一层是时间基准。STM32内部虽然有RTC模块，但在Proteus仿真和实际课程设计中，大家更常用外部RTC芯片，因为内部RTC依赖备份域和低速外部晶振，配置起来比较绕，而且在仿真环境里对新手不友好。第二层是日期换算，这部分是纯算法问题：闰年怎么判、每月多少天、今天星期几，这一层和硬件没关系，考验的是C语言基本功。第三层是人机交互，按键怎么识别、怎么进入设置模式、怎么调时间调闹钟，这需要状态机思路。
很多新手栽跟头，就是没把这三层分开想。他们以为“功能越多越难”，其实只要把每一层单独写成模块，整个项目反而清晰。比如万年历的日期算法单独写一个文件，DS1302驱动单独写一个文件，按键和闹钟再各管各的，后面调试哪一块都不会牵连到别的。这一层逻辑理顺了，Proteus里那个“电路不工作”的灵异现象也能少一半。
1.2 关键器件选型：DS1302、DS18B20和内部外设怎么选
做万年历第一个要定的就是时钟芯片。我比较过三种方案，直接说结论：Proteus仿真里，DS1302是性价比最高的选择。它虽然是三线串行接口，但Proteus里模型成熟，源码示例多，程序逻辑也简单。DS3231精度更高还带温度补偿，但I2C时序在仿真里有时会卡在ACK上，新手很难排查；STM32内部RTC虽然不用外接芯片，但仿真时要在备份寄存器里做标志位，复位后时间容易丢，反而麻烦。
温度采集上，绝大多数人用DS18B20，因为它是单总线，只占一根IO口，而且Proteus里有现成模型。但要提醒一句：DS18B20的时序真的很“挑”，仿真里反而比实物更容易出问题，后文我会专门说。如果你只想要“显示一个温度数字”，也可以退而求其次用STM32内部温度传感器，代码短很多，但那种方案不能代表实际工业场景，课程设计打分时也容易减分。
所以我的推荐组合是：STM32F103C8 + DS1302 + DS18B20 + OLED12864或LCD1602，按键四个，蜂鸣器一个。
1.3 Proteus仿真环境的短板：为什么“仿真能跑不代表实物能跑”
这里先泼一盆冷水：Proteus仿真成功不等于实物就能跑。仿真的时钟是理想化的，晶振不会不起振，按键不会抖动，电源不会掉电，这些“便利”反而会让你忽略很多真实问题。
比如DS18B20的读取时间，实物里基本要等几百毫秒，仿真里可能瞬间就能读到，但程序还是得按真实时序写，否则一上实物就死。再比如按键防抖，仿真里不加延时也“可能正常”，但实物里不加防抖就是乱跳。
反过来，仿真也有比实物“更严格”的地方。最典型的是Proteus对STM32的Flash配置和启动模式很敏感，你在实物里可能随便烧进去了，仿真里Boot0没接地、hex文件路径不对，它就直接黑屏不干活。这篇文章后面的章节会围绕这些差异展开，尽量让仿真和实物表现一致。
2. Proteus电路搭建与模块接线：细节都在引脚上
2.1 建立STM32最小系统工程：几件必须做对的事
Proteus里新建STM32工程时，最容易走弯路的地方不是画电路，而是选元件和配置芯片。很多人从元件库搜不到STM32F103C8，其实是因为Proteus 9里它的类别在“Microprocessor ICs”下面，关键词搜STM32F103C8T6或STM32F103都可能找不到，直接搜“Cortex-M3”反而更准。
放置芯片后，默认模型是带内核的Cortex-M3，不能直接用，必须双击芯片，在“Program File”里加载编译好的hex文件。这一步是新手最常忽略的。如果你用的Keil版本配好了编译器，也可以在“Debug”菜单选“Use Remote Debug Translator”实现联调，但我建议第一次做仿真别搞联调，老老实实加载hex文件，能省下80%的折腾时间。
STM32最小系统还需要VDD和VSS接地、NRST接上拉电阻到3.3V、BOOT0接GND保证从Flash启动。这些在Proteus里如果随手放一个电阻、不接地，仿真器照样跑，但如果你后续想下载实物PCB资料，就会踩大坑。我见过不少人在仿真里不画复位电路也能跑，最后上手画板子时全忘了，IO状态完全乱飞。
2.2 显示模块、按键和报警电路的引脚分配与连线
我常用的引脚分配方案如下，大家可以直接抄作业。显示用OLED12864（I2C版本）时，SDA接PB7、SCL接PB6；如果用LCD1602，则RS接PB0、RW接PB1、EN接PB10、数据口D4-D7接PB12-PB15。DS1302的CE、SCLK、IO分别接PA3、PA4、PA5。DS18B20接PA0，四个按键接PC13到PC15加PD2（利用STM32上的上拉输入），蜂鸣器通过NPN三极管接PB8，用定时器输出PWM驱动。
这个分配有个好处：I2C、SPI、串行单总线各自独立，不会互相干扰。同时按键接在具有外部中断能力的引脚上，后面如果想把按键改成中断触发，硬件不用重新画。
画完电路后一定要逐根线对一遍。Proteus里最坑的是芯片引脚容易空接，尤其是OLED的SCL和SDA，很多人画完发现屏幕上没内容，检查一下才发现I2C引脚根本没连到PB6/PB7。还有一个高频错误：DS1302的VCC1和VCC2接反，导致备用电池一直供电，仿真里显示正常但时间乱跳。
2.3 上拉电阻和驱动电路：仿真里偷懒最容易埋雷
DS18B20数据线必须接一个4.7kΩ上拉电阻到3.3V，这个电阻在Proteus里不接也能“偶尔”工作，因为仿真模型的默认电气特性比较宽松，但换到实物或换一个仿真模型版本，就完全不显示了。DS1302的IO引脚同理，习惯性加10kΩ上拉，保证总线空闲电平是确定的。
蜂鸣器电路更要按真实接法画：PB8通过1kΩ电阻连到NPN三极管（9013或2N2222）的基极，发射极接地，集电极接蜂鸣器负极，蜂鸣器正极接5V电源。不要直接把蜂鸣器串在IO口上，虽然Proteus里直接连也能响，但STM32的IO驱动能力不足以带动实物蜂鸣器，仿真和实物表现会差很多。我当初就是贪快直接驱动蜂鸣器，仿真里响得嘹亮，实物一接完全推不动。
3. 源码实现与关键算法：折腾最多的是日期和温度时序
3.1 万年历日期算法：从闰年判断到星期计算
万年历的核心是日期算法。给一个日期，你得知道这个月有多少天、下一天是哪天、星期几，这在C语言里其实很直白。闰年判断用经典公式：能被4整除且不能被100整除，或者能被400整除。然后按月份查表，2月特殊处理。
uint8_t is_leap_year(uint16_t year) { if ((year % 4 == 0 && year % 100 != 0) || (year % 400 == 0)) return 1; return 0; } uint8_t get_days_in_month(uint16_t year, uint8_t month) { uint8_t days_table[13] = {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if (month == 2 && is_leap_year(year)) return 29; return days_table[month]; }星期计算我推荐基姆拉尔森公式，不需要维护基准日，直接算出Weekday。
uint8_t calc_weekday(uint16_t year, uint8_t month, uint8_t day) { if (month < 3) { month += 12; year--; } uint8_t w = (day + 2 * month + 3 * (month + 1) / 5 + year + year / 4 - year / 100 + year / 400 + 1) % 7; return w; // 0=Sun, 1=Mon ... }这个公式我第一次用的时候，发现星期天显示成0，而OLED上可能默认显示“星期0”，看起来很怪。解决办法是做个映射表，把0映射成“日”，或者在显示时加一个判断。这个细节属于那种“代码没Bug但显示很诡异”的经典案例。
3.2 按键状态机：时间、日期和闹钟到底怎么“调”
万年历的按键交互，很多人用if-else硬写，代码一长就乱。正确做法是维护一个状态变量，每个状态对应一个界面和一套按键逻辑。我用的是这组状态：NORMAL（正常显示）、SET_YEAR、SET_MONTH、SET_DAY、SET_HOUR、SET_MINUTE、SET_ALARM_HOUR、SET_ALARM_MINUTE。
typedef enum { NORMAL = 0, SET_YEAR, SET_MONTH, SET_DAY, SET_HOUR, SET_MINUTE, SET_ALARM_HOUR, SET_ALARM_MINUTE } MenuState;主循环里读按键时，根据当前状态决定行为。比如NORMAL状态下，短按“设置”键进入SET_YEAR，此时显示Year并闪烁；每按一次“加”键，年份加1；按“确认”键，进入SET_MONTH。所有状态走完后，把临时变量写回DS1302时间寄存器，再回到NORMAL。注意“设置”和“确认”不能用一个键，否则状态切换会乱套。
还有一点容易被忽视：在设置状态下，时钟芯片仍然在走秒，但界面正在切换，如果你直接读取DS1302并显示，用户会看到数字跳得很乱。我的做法是进入设置状态后暂停秒级刷新，只显示等待修改的字段，退出设置时再重新同步一次时间。这样逻辑稳定，显示也干净。给课程设计答辩时，这个细节也很加印象分。
3.3 DS18B20单总线时序：温度不是读寄存器就能拿到的
DS18B20很多人误以为像I2C那样直接读寄存器，实际上它是一根总线，所有操作都要靠精确的时序。标准读取流程是：初始化时序（主机拉低480μs，释放，等待存在脉冲）→ 发送跳过ROM命令0xCC → 发送温度转换命令0x44 → 等待转换完成 → 再次初始化 → 发送跳过ROM → 发送读暂存器命令0xBE → 连续读两个字节。
uint16_t ds18b20_read_temp(void) { uint8_t low = 0, high = 0; ds18b20_reset(); ds18b20_write_byte(0xCC); // skip ROM ds18b20_write_byte(0x44); // start conversion delay_ms(750); // 等待转换，仿真里也建议保留 ds18b20_reset(); ds18b20_write_byte(0xCC); ds18b20_write_byte(0xBE); // read scratchpad low = ds18b20_read_byte(); high = ds18b20_read_byte(); return (high << 8) | low; }有一点必须多说一句：Proteus的DS18B20模型对延时没有实物那么严格，有时候你延时只给了100ms它也能出结果，但一旦你把这个程序烧到实物，温度就永远停在85℃——这是DS18B20上电复位的默认值，说明转换根本没完成。我见过太多人仿真正常、实物温度85℃，问题就出在这里。所以仿真代码里也要老老实实延时750ms，保持和真实芯片一致。
3.4 闹钟比较和防重复触发：让报警“响一次就收”
闹钟逻辑其实不复杂，难点在于“到了时间它应该只响一次，而不是每秒都触发”。最简单可靠的写法是在主循环里拿当前时间（时、分）和闹钟设定值比较，相等就置位闹钟标志，然后拉高蜂鸣器引脚。关键是响过之后必须清除标志，否则下一秒比较又成立，蜂鸣器会一直响。
if (current_hour == alarm_hour && current_minute == alarm_minute) { if (!alarm_triggered) { alarm_triggered = 1; buzzer_on(); // 可在这里加“响铃60秒后自动关闭”的逻辑 } } else { alarm_triggered = 0; }如果想让闹钟优雅一点，可以再用一个定时器，响10秒后自动关，或者按任意键停止。这种方式比单纯延时更好，因为主循环不会卡住。还有一点经验：千万别把秒数也参与闹钟比较，否则某一分钟内的60秒里，只有那一秒能触发，用户很可能错过，还以为闹钟坏了。
4. 仿真调试实战与常见问题速查：从hex烧录到“时间不走”
4.1 Keil5配置hex输出与Proteus加载固件
Keil5在Proteus仿真中报“No target connected”已经是我见过最多的问题了。其实只要按下面的步骤来，基本不会错。打开Keil工程，点击魔术棒“Options for Target”，切到Output选项卡，勾选“Create HEX File”。然后编译，确认工程目录下生成了.hex文件。
接着回到Proteus，双击STM32F103C8芯片，在“Program File”里点击文件夹图标，选中那个hex文件。然后点击左下角运行按钮。这里有个容易忽略的细节：如果芯片没有加载hex文件，Proteus不会报错，只会显示空白屏幕或没有任何运行动作。所以“确认hex文件已经加载成功”应该排在排查第一位。
如果你用Proteus的VSM调试器做联调，就要在Keil的Debug选项卡里选择“Proteus VSM Simulator”。但个人建议先去掉联调，用最原始的“编译→生成hex→Proteus加载”流程，因为联调时频繁断点和单步执行反而容易让Proteus卡死，体验不好。
4.2 常见故障速查表：现象、原因、处理办法
下面这张表是我从多次调试里整理出来的高频问题，几乎每个都能对应到具体操作错误。
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 仿真点运行，屏幕完全没反应 | hex文件没加载或加载错芯片 | 双击芯片，确认Program File指向最新hex |
| 时间不走，始终停在初始值 | DS1302初始化失败，或CE/IO/SCLK接错 | 重新核对三根线，检查电源和晶振是否接在DS1302 |
| 温度显示85℃或0℃ | DS18B20转换等待不够 | 在0x44命令后加750ms延时 |
| 温度显示正常但偶尔乱跳 | DS18B20上拉电阻缺失 | 数据线接4.7kΩ上拉至3.3V |
| 按键一按就跳多个值 | 没有做按键消抖 | 加10-20ms延时消抖，或用电容滤波 |
| 闹钟到点不响 | 比较条件没包含分钟，或标志位未清除 | 检查alarm_triggered是否在响铃后置1并停止 |
| OLED显示乱码 | I2C地址不对 | 确认器件地址是0x78（8位模式）还是0x3C（7位模式） |
| 仿真运行极慢，像死机 | 芯片CLK设置过小，或循环里有过长延时 | 调高系统时钟，或把打印/延时缩短 |
4.3 仿真提速和稳定性优化：我踩过的几个坑
Proteus仿真STM32时，如果代码里有大量延时，比如DS18B20的750ms，那整个仿真的响应速度会非常慢，经验上你可以把仿真速度调低到20%来观察是否能跑通，调高到200%快速跳过等待，但要注意某些时序在高速仿真下会变古怪，不是代码问题，纯粹是Proteus仿真引擎的采样间隔所致。
一个我反复踩的坑是：在代码里用printf重定向到串口输出调试信息，Keil里没问题，一放进Proteus仿真实机就卡死。原因是Proteus的虚拟串口终端模型需要额外配置，而且Stdio重定向代码在仿真环境里容易触发HardFault。建议调试信息用OLED显示或者用GPIO翻转+逻辑分析仪，别依赖printf。
另一个稳定性优化：STM32的GPIO初始化里，把没用的引脚都设成模拟输入或上拉输入，不要悬空。Proteus里悬空引脚可能带来不确定电平，一旦某个引脚被内部上拉驱动成低电平，就会莫名其妙地影响按键检测。这个细节在实物上影响不大，仿真里却非常致命。
最后分享一个个人体会：Proteus万年历这类仿真项目，千万不要“画完电路再写代码”，而是先把日期算法在Keil里用纯软件验证，再写DS1302和DS18B20驱动，最后才上仿真，顺序反了会导致你分不清是硬件问题还是算法问题。调完一个模块就立刻固定一个可复现的版本，别把所有代码写完再统一测，那样你会被一堆叠加的错误折磨到怀疑人生。这个项目做完后，如果你还愿意折腾，可以顺便把“整点报时”“倒计时”和“闹钟贪睡”加进去，代码架构不变，只是状态机里多几个分支而已，收获会更大。
本文还有配套的精品资源，点击获取
