企业官网建设流程全解析

智能药盒这个题目，算是我见过最经典的嵌入式毕设之一了。原因很简单，它几乎把STM32的基础外设用了个遍：定时器、GPIO、中断、时钟芯片、LCD、按键、蜂鸣器、掉电存储，功能闭环又贴近生活，答辩的时候也容易讲出实际意义。但正因为做的人多，网上的资料反而良莠不齐，我见过不少同学卡在Proteus仿真阶段，最典型的就是兴冲冲把程序烧进去，结果LCD屏幕只亮不显示，或者显示乱码。这篇文章就把我从需求拆解到Proteus仿真实战、再到代码编写和问题排查的完整过程写出来，重点聊聊那些常规教程里不会写、但你又一定会踩的坑。

1. 项目需求拆解与整体方案选型

1.1 先别急着写代码，把吃药的场景想清楚

做任何一个嵌入式项目，第一步都不是打开Keil，而是把需求写清楚。智能药盒的核心场景是什么？是帮助老人或者慢性病患者按时服药。那么从使用场景倒推，这个系统至少需要回答三个问题：现在是什么时间？该吃哪盒药？如果该吃而没吃，怎么提醒？

围绕这三个问题，功能就可以拆成四块。第一是实时时钟，系统必须知道当前的日期和时间，这是所有提醒功能的基础。第二是用户交互，需要用按键来设置当前时间、设置每组药的服药时间点和服药次数，设置完还要有反馈显示。第三是提醒输出，到了设定时间要能发出声音提醒，最好配合灯光或者屏幕文字提示。第四是存储记忆，设置好的参数掉电不能丢，不然每次重新上电都要重设一遍，那这个产品根本没法用。

把这些功能映射到硬件上，就得到了系统的基本组成：主控芯片负责逻辑处理，时钟芯片负责走时，LCD显示屏负责信息展示，独立按键负责交互输入，蜂鸣器和LED负责声光报警，再加一颗EEPROM芯片保存设置参数。这套架构看起来简单，但麻雀虽小五脏俱全，它已经是一个完整的嵌入式产品原型了。

1.2 主控芯片选型：为什么是STM32F103C8T6

主控我选的是STM32F103C8T6，这几乎是同类项目里的默认选择。这颗芯片是64引脚的Cortex-M3内核单片机，主频72MHz，Flash有64KB，SRAM有20KB，片上外设极其丰富，足够这个项目使用了。

选它的理由有三个。第一个是生态成熟，库函数版本的资料铺天盖地，HAL库和标准库都有大量参考资料，无论是用寄存器还是库函数，遇到问题都能查到解决方案。第二个是性价比高，市面上蓝板开发板十几块钱一块，就算烧坏了也不心疼，适合反复折腾。第三个是对Proteus仿真非常友好，Proteus里直接搜索STM32F103C8就能找到仿真模型，加载HEX文件就能跑起来，不用像51那样还要额外搭晶振电路。

实际上这个项目的负载很轻，系统里最耗资源的是LCD显示刷新和DS1302的时序模拟，这两部分都是毫秒级别的操作，F103同时处理这些任务完全没有压力。就算以后要加个WIFI模块远程提醒，这颗芯片的RAM和Flash也还够用。

1.3 时钟方案：DS1302与内部RTC的取舍

实时时钟是本项目的核心，这个方案选型时我纠结了一下。STM32内部自带RTC模块，理论上可以直接用，但在Proteus仿真里用内部RTC有个麻烦：它依赖外部低速晶振，仿真时晶振参数设置不好就容易不走时，而且掉电后时间数据全靠备用电池维持，逻辑上绕了一圈。

DS1302是DALLAS公司推出的串行实时时钟芯片，它最大的特点是通过三根线就能通信：CE、SCLK和I/O，一根一根地传数据。内部集成31字节的静态RAM，可以临时存一些数据。供电方面，它允许主电源和备用电源双路供电，主电源掉电后自动切换到备用电池，继续走时，非常符合药盒的应用场景。

在Proteus里DS1302模型做得很逼真，必须外接32.768kHz晶振才能工作。很多教程里省事不画晶振，结果仿真的时候时间不走，就是这个原因。我后面的仿真搭建章节会专门讲这个坑。

1.4 提醒器件：无源蜂鸣器与有源蜂鸣器的区别

提醒输出最常用的是蜂鸣器，但蜂鸣器有有源和无源之分，这在Proteus里尤其容易搞混。很多人不知道“有源”和“无源”指的是什么，“源”是振荡源。有源蜂鸣器内部集成了振荡电路，只要给它通直流电就能发声；无源蜂鸣器内部没有振荡电路，必须给方波信号才响，直接通直流电只会有轻微的咔嗒声，甚至完全无声。

Proteus元件库里有两种蜂鸣器，一个叫BUZZER，一个叫SOUNDER。前者是有源的，后者是无源的。如果用了SOUNDER，程序里就必须产生一定频率的方波驱动它，比如设置定时器输出2.7kHz的PWM信号；如果用的是BUZZER，直接给高电平就能响，但音色比较单调。

我最终选择了无源蜂鸣器加定时器PWM驱动的方式。这样做的原因有两个：一是声音频率可调，可以用不同音调和节奏区分不同药盒的提醒；二是无源蜂鸣器的成本确实比有源的低几分钱，对于产品设计来说是合理的选型习惯。仿真的时候要注意，无源蜂鸣器要接一个三极管驱动，IO口直推拉不动。

2. Proteus仿真环境搭建与元件库避坑

2.1 版本选择与芯片包安装

Proteus版本建议选8.x版本，比如Proteus 8.15或者8.17，这些新版本对STM32的支持更完善。老版本的Proteus 7对CM3内核芯片支持得不好，有些元件模型根本不带，非常折腾。

安装仿真芯片包是个容易卡住的地方。Proteus默认只带了一部分元件库，STM32系列虽然内置了一部分，但如果你用的型号不在默认库里，就需要下载对应的芯片包。搜索“Proteus STM32F103C8”就能找到对应的芯片库文件，下载后解压得到两个文件，一个是.pmn文件，一个是.pdsprj文件，把它们复制到Proteus安装目录下的LIBRARY文件夹里，重新打开软件就能搜索到了。

还要顺带提一句Keil的兼容性问题。很多人的电脑里已经装了支持C51的Keil C51，又装了Keil MDK，这两个版本的管理程序可以共存，但安装顺序有讲究，建议先装C51再装MDK，装完会看到两个不同的编译器入口。如果工程提示找不到ARM编译器，多半是MDK没装或者破解不完全，重新安装并激活即可。

2.2 STM32最小系统在Proteus中怎么连

在Proteus里放置STM32F103C8芯片后，它不会自动运行，必须给它构建最小系统。STM32的启动方式通过BOOT0和BOOT1引脚的电平决定，从主Flash启动要求BOOT0=0、BOOT1任意，所以BOOT0引脚要接一个10k下拉电阻到GND，BOOT1脚可以直接接地。

复位电路方面，NRST引脚接一个10k上拉电阻到3.3V，再接一个104电容到地，或者用一个按钮模拟复位。虽然Proteus仿真时按钮复位不是必需，但有总比没有好。电源引脚VDD接3.3V，VSS接地，VDDA和VSSA也要按同样的规则接好。有些同学刚放上芯片说不工作，多半是忘了接BOOT0下拉或者电源引脚没连全。

晶振电路在Proteus里反而简单，因为仿真的是芯片模型，内部时钟和外接时钟都能起振。但为了贴近实物，习惯上还是在OSC_IN和OSC_OUT之间跨接8MHz晶振加两个20pF电容。这颗8MHz晶振是系统主晶振，后面SystemInit函数会把它倍频到72MHz，如果仿真里不接，系统也大概率不会跑。

2.3 LCD选型：LM016L与LCD1602的对应关系

Proteus里的LCD1602元件不叫LCD1602，叫LM016L。这是一个很典型的搜索陷阱，直接输入LCD1602搜不到元件，输入LM016L就有。LM016L是16字符乘2行的液晶模块，内部是HD44780控制器，正好和实际常用的LCD1602完全兼容，引脚定义也一样，一共16个引脚。

LCD1602的引脚中，第1脚VSS接地，第2脚VDD接5V，第3脚VEE接电位器中间抽头用来调对比度。第4脚RS是寄存器选择，第5脚RW是读写选择，第6脚E是使能信号，后面8个引脚是并行数据线。Proteus仿真中数据线我们常只接4根，用4位模式通讯，省IO口。

关于引脚命名还有个细节，Proteus里LM016L的引脚标号和芯片丝印的标号是一致的，比如D0到D7、RS、RW、E等，照着接就行。很多新手纠结电位器怎么调，仿真里我直接把VEE那根线通过一个10k电位器接到GND，电位器位置拉到一半左右，对比度刚好。

2.4 DS1302的仿真接法：晶振和电池缺一不可

这是仿真里最隐蔽的一个坑，我单独拿出来说。DS1302在Proteus里的默认模型带XT1和XT2两个引脚，必须接32768Hz的晶振，否则芯片内部振荡器不工作，时间就永远停在初始化那刻。很多教程给的电路图里没有画这个晶振，照着做时间不走，查半天查不出原因。

DS1302还有一个VCC2引脚做主电源，VCC1引脚接备用电池。仿真时如果完全不接备用电池，当主电源掉电后时间就会丢失，但这种仿真场景一般不会测试，所以电池端的接法反而随便。实际实物设计时，这里会接一个CR2032纽扣电池座。

DS1302的数据线I/O引脚和SCLK、CE引脚都要接上拉电阻，我习惯统一用10k的，串行总线的上拉电阻值在这个范围都没有问题。

2.5 AT24C02与I2C总线上拉

保存参数的EEPROM我用的是AT24C02，2Kbit容量，256字节，存几组提醒时间完全够用。它挂在I2C总线上，SCL和SDA两根线都必须接上拉电阻，通常选4.7k或10k。I2C协议规定空闲时总线是高电平，不接上拉的话通信会失败，仿真里面表现就是读写数据一直是255。

AT24C02的地址引脚A0、A1、A2接GND，把设备地址固定为0xA0写地址、0xA1读地址，这是I2C通信的约定。如果这几个引脚不小心接高了，后面程序里地址就要改成0xA8，很多同学程序写死了地址，仿真却因为一个引脚电平不同导致通信失败，百思不得其解。

2.6 把Keil生成的HEX文件加载进Proteus

仿真电路的最后一个关键操作是加载HEX文件。双击STM32芯片，在Program File一栏点文件夹图标，选择Keil工程Output目录下生成的.hex文件。这里要注意，Keil里默认生成的是AXF文件，需要在Options for Target里的Output选项卡勾选Create HEX File，否则编译一万次也找不到hex文件。

加载完后点左下角的运行按钮，仿真就开始跑了。如果程序里用了printf重定向或者是调试输出，Proteus里不会显示这些，需要虚拟终端来接收串口信息，我项目里没用串口调试，所以这点暂时不展开。

3. STM32工程代码架构与核心驱动实现

3.1 整体代码结构与初始化流程

仿真跑通以后，重点就放到代码编写上。我的工程基于STM32标准外设库开发，文件结构清晰，主要分成四层：底层驱动文件（如DS1302驱动、LCD驱动、按键扫描）、中间应用层（提醒逻辑、菜单逻辑）、芯片初始化层（时钟配置、GPIO配置、外设配置）、以及主循环。

系统上电后的初始化顺序很讲究。第一步是调用SystemInit配置系统时钟，STM32F103默认使用外部8MHz晶振，经过PLL锁相环9倍频后得到72MHz主频。第二步是初始化所有用到的GPIO引脚：LCD数据口、控制口，DS1302的数据线，按键对应的输入口，蜂鸣器的PWM输出口，LED指示灯的推挽输出口。第三步是配置定时器产生一个1ms的时基中断，这个时基是全系统的心脏，按键消抖、界面刷新、提醒超时判断全靠它累加时间。第四步是初始化DS1302时钟和AT24C02存储，读取上次保存的设置参数。

初始化完成后进入主循环，主循环里做的事情在while(1)里反复执行：扫描按键状态、处理菜单界面刷新、检查当前时间是否和设置的提醒时间匹配。我把这几件事分成了几个函数，每个函数执行时间都很短，保证了系统响应的实时性。

3.2 DS1302驱动时序：三线协议的关键节奏

DS1302的通信协议不算复杂，但细节极多。CE引脚从低拉高表示一个通信周期开始，然后每个SCLK上升沿传输一位数据。写一个字节需要先发送命令字节，再发送数据字节；读一个字节需要先发送命令字节，然后每个SCLK下降沿从IO线上读回一位数据。

代码里我封装了几个底层函数。DS1302_WriteByte负责写一个字节，DS1302_ReadByte负责读一个字节，DS1302_WriteTime和DS1302_ReadTime分别负责写入和读取时间数据。时间数据是以BCD码格式存储的，比如秒寄存器里的0x59代表秒数是59，不是十进制编码。

这里要特意强调BCD码转换。比如我们要设定12点30分，写入DS1302的是0x12和0x30，而单片机内部的十进制变量是12和30，两者需要通过位运算转换：十进制转BCD是(12 / 10) << 4 | (12 % 10)；BCD转十进制是(0x12 >> 4) * 10 + (0x12 & 0x0F)。如果忘了转换，时间会显示成乱码，而且整个提醒逻辑都会失效。这个坑百分之百会踩，我先给你打个预防针。

DS1302还有一个隐藏特性：读操作时数据是在SCLK的下降沿被驱动的，所以程序里要先发完命令字节，然后在下降沿读取IO引脚的电平，顺序不能反。很多网上的代码直接抄过来在实物上能用但在仿真里不行，很可能就是时序的时钟沿搞反了，需要结合数据手册微调。

时间读出来以后，主循环会每100ms刷新一次当前时间的显示。DS1302的秒寄存器在第7位有一个暂停标志，正常工作时这一位是0。初始化写时间时我把这个位清零了，避免芯片被置为暂停状态。

3.3 LCD1602驱动：初始化时序与显示刷新

LCD1602驱动是另一个考验耐心的模块。它的初始化过程非常讲究，需要发送一串特定的命令序列。我在代码里封装了LCD_Init、LCD_WriteCommand、LCD_WriteData、LCD_SetCursor、LCD_ShowString等函数。

LCD_WriteCommand的时序是先把RS置低，然后拉低E，把8位命令数据放到数据线上，再拉高E并延时，E上的一个高脉冲通知液晶模块锁存数据。LCD_WriteData类似，只是RS要置高。时序是全系统的关键，E脉冲宽度要满足至少450ns，所以我写了几个延时函数保证节奏。

初始化序列我用的标准流程：延时30ms，写命令0x30进入8位模式，延时4ms，再写0x30，延时4ms，第三次写0x30，然后写0x38设置为8位数据接口、2行显示、5x7点阵字体，再写0x0C关闭光标显示，0x06设置写入后光标右移，0x01清屏。完整的初始化在仿真里不是必须全部执行，但不按流程走容易出现显示不稳定。

显示刷新这一块，我设计了一个两行的界面布局。第一行显示当前时间，格式是“时间: 12:30:45”；第二行显示最近一组药的提醒信息，比如“药1 08:00”。按键触发设置菜单时，LCD进入参数设置界面，显示闪烁的数字，这个时候光标就会打开，方便用户看到当前正在修改哪一个数据位。

关于1602显示中文的常见疑问，LCD1602的字符库是英文ASCII字符，它不能直接显示中文字符，厂家内置的字模里根本没有中文字。想显示“药”字，要么用专业取模软件生成自定义字符存入CGRAM，要么就退而求其次用拼音或者编号代替，我在项目里用了“M1”“M2”表示药盒编号。

3.4 定时器中断：系统的心跳与提醒判定

我配置了TIM2作为系统时基，让它每隔1ms产生一次中断。在中断服务函数里，变量sys_tick_ms累加，同时处理三个任务：按键消抖计时、界面刷新周期计时、提醒延时判定。

按键消抖这个模块值得多写几句。机械按键按下和松开瞬间会产生抖动，如果不处理，一次按下会被识别成多次。我的处理方式是每隔10ms采样一次按键状态，连续两次采样都一致才认为按键状态改变。这个逻辑我放在了主循环里，定时器中断只负责提供时间基准。这样按键逻辑不会阻塞中断，代码也清爽。

提醒判定逻辑是这样实现的：在DS1302读取到当前时间后，把时分秒解析成三个变量，然后每500ms比较一次当前时间和预置提醒时间。如果当前小时和分钟都等于设定值，并且秒在0到20之间，就往蜂鸣器控制寄存器写入输出比较值，同时点亮LED指示灯，进入提醒状态。这个“秒在0到20”的条件是为了防止因为主循环执行周期不固定导致同一分钟内重复触发提醒。

蜂鸣器响30秒后自动关闭，防止一直叫吵到人。这个30秒我同样用sys_tick_ms来计时，中断里每500ms检查一次提醒开启标志，如果超过30秒还没等到用户按键确认就强制关闭提醒。

3.5 用定时器输出PWM驱动无源蜂鸣器

无源蜂鸣器需要方波驱动，我选的是TIM3的通道1，也就是PA6引脚。配置TIM3输出频率为2kHz的PWM，占空比调成50%，每次要响就直接修改CCR寄存器，让输出一组方波给蜂鸣器驱动三极管。2kHz这个频率是蜂鸣器发声效率较高的区间，实测听感也比较响亮。

有源蜂鸣器的话，这段代码可以全部省掉，直接写GPIO_SetBits拉高蜂鸣器控制引脚就能响。但为了做到定时提醒音调有区分度，比如药1响三短声，药2响两长声，PWM方式确实更灵活。中断里用一个计数器控制响的次数和间隔，就能做出不同的提醒节奏。

3.6 EEPROM参数存储与掉电恢复

设置好的提醒时间，如果一断电就丢失，那这个产品就没有实用价值。我使用AT24C02存储三组提醒时间和对应的药盒编号。EEPROM写入有最大擦写寿命，大概一百万次，频繁写入会缩短寿命，所以我在代码里只在用户完成设置并按下确认键后才执行写入，主循环里不写。

写入时按字节写会更稳，AT24C02的页写功能一次可以写8个字节，但页写要求首地址页对齐，否则会翻页出错。为了简单可靠，我没有用页写，而是逐字节循环写入，每字节写入后加5ms延时。I2C时序严格按照起始、发送地址、发送数据、停止的流程走，每发送完一个字节都要等待从设备的应答信号。

上电初始化时读取EEPROM，如果读出的数据全是0xFF（代表EEPROM是空的或者写入失败），就自动把默认提醒时间写入并重新保存。这样即使第一次使用没做过设置，药盒在默认时间也会准时提醒，不会哑火。

4. 仿真不显示与不工作的完整排查链路

4.1 LCD只亮屏不显示文字

这是Proteus仿真里最常见的故障，搜索“lcd仿真不显示”的热度一直居高不下。遇到这种现象，我习惯按下面的顺序去查。

第一查对比度。LM016L的VEE引脚如果直接接地，对比度会过高，屏幕显示成一团黑色的方块，看起来就是“不显示”。如果VEE悬空或者接错，屏幕就白茫茫一片。正确做法是通过一个10k电位器分压，调节电位器让屏幕出现清晰但不黑块的状态。仿真里可以用键盘改变电位器的阻值，或者直接双击电位器修改阻值百分比。

第二查使能E引脚是否有信号。如果程序已经初始化过LCD，E引脚上应该能看到周期性的脉冲，用Proteus的逻辑探针或者示波器挂在E引脚上就能看到。如果完全没有波形，说明程序没有走到LCD初始化这一步，可能卡在了时钟配置或者前面的某个外设初始化函数里。

第三查数据线接线。D4到D7的数据线是不是对应到了单片机正确的GPIO口？如果程序里用的是PA0到PA3，电路却接在PB0到PB3，那显示出来的必然乱码或空白。这个低级错误在实物接线中很常见，仿真里也要仔细对照。

第四查HEX文件是否真的加载上了。有一种情况非常气人——程序改了好几版，Proteus里却是旧程序在跑，因为HEX文件路径没更新或者是加载错误文件。双击芯片重新选择HEX文件，并确认文件路径输出文件夹里确实有新生成的HEX，这个问题就能解决。

4.2 LCD有显示但全是乱码

乱码问题和初始化时序强相关。首先确认初始化流程是否走完了标准序列，很多人为了偷懒只发几个关键命令，或者把0x38随便改成了0x3F之类的值，导致液晶进入错误的模式。

其次检查数据位顺序。并口LCD在8位模式下DB0到DB7顺序不能错，在4位模式下只接高四位DB4到DB7，低四位悬空。如果电路里高四位和低四位接反，或者程序里发送字节时移位方向搞反了，就会乱码。我的驱动里统一使用了高四位先发的写法，底层代码定义清晰，不容易乱。

还有一个容易被忽略的点是延时时间。LCD控制器HD44780比较慢，执行一条命令要几十微秒，清屏要1.64毫秒。如果初始化序列的延时不够长，LCD内部状态机还没准备好就收到下一条命令，数据就会乱。我把延时长于数据手册要求，宁多勿少。

4.3 蜂鸣器不响

蜂鸣器不响，先确认用的是有源还是无源。如果用无源蜂鸣器但程序只给了个高电平，它不会发声；相反，如果用有源蜂鸣器但程序给了它PWM方波，声音会变得很奇怪甚至无声。仿真里选SOUNDER且程序配置了PWM的话，可以直接用虚拟示波器看PWM有没有输出。

如果PWM波形正常但不响，检查驱动电路。无源蜂鸣器内部线圈阻抗低，直接接IO口可能带不动，需要一个NPN三极管扩流。Proteus里三极管型号选2N2222就够，基极串联一个1k电阻接单片机IO，发射极接地，蜂鸣器一端接5V另一端接集电极。PD二极管反向并联在蜂鸣器两端泄放尖峰，仿真效果不明显但实物必须有。

如果用的是BUZZER有源蜂鸣器，程序只需要拉高IO口电平。有些人在程序里用PWM模式配置了输出，导致IO口一直输出方波而不是纯直流，有源蜂鸣器内部振荡器被混乱的电源波形干扰，反而不响。

4.4 DS1302时钟不走时

时钟不走时，各种奇葩原因我都见过，最普遍的就是缺少晶振。前面已经说过DS1302的XT1和XT2之间必须接32.768kHz晶振，Proteus模型不会自动内置，必须手动放置。放上去之后还要注意电容配置，一般外接两个15~30pF的负载电容到地，晶振才容易起振。

其次是初始化时不小心把秒寄存器的最高位写成了1。这个位叫CH，时钟暂停标志，写1芯片立刻进入暂停状态。如果你设置时间的时候直接把整个秒值0x55写进去了，那CH位就是0，没问题；但如果你把暂停标志位一起清零，比如写0x00，也会把CH位置0同时秒归零，不会有问题。真正容易出错的是用位运算修改秒寄存器时，不恰当地操作了最高位。这是一个容易被忽略的细节，写代码时要注意区分“设置时间”和“读取时间”两种操作。

还有一个原因是I/O引脚上拉电阻没接。DS1302的IO是双向线，开漏输出，不接上拉的话高电平写不进去，数据读出来也是低电平，时间数据全是0或者乱码。很多实物电路里这里很讲究，仿真漏接一个上拉同样出问题。

4.5 按键无反应或跳跃误触发

按键按下没反应，先看按键的引脚接法。Proteus里的BUTTON元件一端接GND，一端接单片机输入引脚，单片机内部开启上拉电阻，这样按下时引脚被拉低。如果你没开启内部上拉，引脚就处于浮空状态，按键操作完全不可控。

按键跳跃误触发则说明消抖没做好。默认抖动时间是10到15毫秒，如果在主循环里直接读引脚状态且不做延时消除，那按一下可能会被识别成几十次按键事件，菜单里设置数字就直接翻飞了。我在代码里用状态机采集按键，每次按键事件只上报一次，直到松手后才允许下一次触发。用了这个方法以后，仿真和实物上的按键行为都很稳定。

4.6 仿真不跑和实物完全不同步

还有一类问题是程序在实物上跑得正常，放到Proteus里却不工作。这通常是外设模型差异导致的。比如STM32的定时器PWM驱动LCD背光这种操作，实物上亮灯正常，但Proteus里LM016L并不支持背光引脚控制，电路上背光引脚接错电平就可能导致整个显示模块行为异常。

LCD对比度调节用的电位器也是一样，实物里要手动调，仿真里直接用鼠标拖动或者改阻值。如果仿真里整个界面黑乎乎的，不是程序的问题，是电位器旋钮位置不对。

总之在Proteus里排查问题要养成一个习惯：多用虚拟示波器、逻辑探针和分步单步执行。双击芯片在程序里设置断点，单步跑几行代码，观察GPIO寄存器变化，很快就会找到是软件问题还是电路连接问题。

5. 仿真移植实物、报告撰写与答辩讲解的核心要点

5.1 从仿真到实物的引脚对应和接线差异

仿真跑通后，如果要做实物，最头疼的就是接线的差异。仿真里芯片引脚随便连，实物上必须对着数据手册仔细核对，尤其是电源和地的走线。我整理了一张对照表，方便你参考，这是从几十次焊接元件的经验里归纳出来的：

外形元件对照表：

实物接线时有一点容易被忽略：STM32的系统板供电电压是3.3V，而LCD1602和DS1302虽然逻辑电压是5V兼容，但如果买的是5V模块，就要考虑电平匹配问题。建议用3.3V供电版本的模块，或者加逻辑电平转换电路。否则5V逻辑电平输入到3.3V的IO口上，长期工作会有烧毁风险。

5.2 写报告和设计文档时如何组织内容

报告是答辩的重要部分，不要最后三天熬夜写，建议实现功能的过程中就同步记录。一个完整的报告大致包含这些章节：项目背景与意义、系统总体方案设计、硬件电路设计与原理分析、软件设计与核心代码分析、系统仿真与实物调试、总结与展望。

硬件部分重点画三张图：系统框图、原理图、PCB布局图。Proteus里画的原理图可以直接截图保存，不要手绘。软件部分重点附上关键代码段，特别是DS1302读写时序、LCD初始化序列和提醒算法的代码，每段代码要配至少三行文字说明逻辑，不要整段代码大段粘贴。

“基于STM32智能药盒定时提醒服药系统”这个题目自带三个关键词：嵌入式的软硬结合、医疗健康应用场景、智能硬件交互设计。写摘要的时候要把这三个关键词体现进去，官方语言的摘要可以这么写：本项目设计并实现了一种基于STM32单片机的智能药盒定时提醒服药系统，采用DS1302实时时钟模块计时，通过按键交互方式设置服药时间，系统到点时使用LCD显示、蜂鸣器报警与LED闪烁协同提醒，并利用AT24C02实现参数掉电保存。Proteus平台中完成了软硬件联合仿真验证。

5.3 答辩讲解时怎么突出自己的工作

答辩时最容易犯的错误是照着PPT读代码，或者一上来就讲工作原理。更好的思路是讲清楚“从需求到实现的决策过程”。可以分三条线展开。

第一条线是方案选型。讲清楚为什么选DS1302而不是STM32内部RTC，为什么选无源蜂鸣器而不是有源蜂鸣器。哪怕只讲一两个关键对比，也能显得你有深度思考。

第二条线是系统逻辑。重点描述用户使用流程：开机显示时间、按键进入设置菜单、设置提醒时间、保存参数到EEPROM、到点响铃提醒、按任意键消音。可以用流程图的方式展示，会非常清晰。

第三条线是调试过程。挑一两个自己解决的困难展开说，比如Proteus仿真中LCD不显示的排查思路，这是最能体现你掌握调试方法的地方。答辩老师特别吃这一套。

5.4 可扩展的方向：从药盒到智慧医疗终端

如果学有余力，这个项目的扩展空间也很充足。最简单的是增加多个药盒仓位指示，用不同颜色的LED对应不同药盒，到点时亮灯加声音提醒，成本只要几块钱。

再进一步，可以加一个ESP8266或者ESP32模组，通过WiFi把服药记录同步到手机APP或者微信小程序，家人远程就能看到老人有没有按时吃药。这个功能在养老场景里很有需求，报告里写“可扩展为远程服药监护系统”，立意就高了。

更进阶的玩法是加语音识别模块，比如离线语音识别芯片，老人到点提醒时不需要按键消音，喊一声“收到”系统就能识别并关闭提醒，这对行动不便的老年人更友好。不过这个放在这个项目里偏复杂，当成展望写在报告里就行。

6. 关于Proteus仿真的一些额外心得

最后分享一些我在实际调试中的经验。Proteus仿真有它的优点，也有它的局限性。优点是改硬件不用焊接，改程序不用烧录，排查逻辑错误非常快；缺点是它毕竟不是真实的芯片，外设模型的时序和真实芯片存在差异。所以我在仿真功能全部通过后，仍然建议有条件的话做一块实物验证一次。

仿真和实物的差异主要体现在两个地方。一是时序精度差异，Proteus里的中断响应和IO翻转速度是模型化的，和真实硬件不完全一致。比如DS1302的读写延时，在仿真里正常工作不代表实物上没问题，实物上还要用示波器量一下时序波形。二是电源差异，仿真里仿真器不会告诉你电源噪声有多大、地弹有多大，但实物上这些问题直接会导致LCD花屏或者蜂鸣器误触发。

如果调试时遇到现象和仿真不一致，我倾向于先在实物上拿万用表量关键点的电压：3.3V电源、IO口高电平输出、DS1302的晶振两个引脚电压。很多时候故障原因就是一根杜邦线接触不良，重新插拔就好了。

7. 最后再分享几个小技巧

代码规范方面，我习惯在所有函数的开头写一段注释，说明函数的功能、输入参数和调用场景。这个习惯帮助我后来写完报告之后回头读代码效率极高。特别是DS1302和LCD这种驱动类的文件，半年后再看也能快速上手。

另一个小技巧是在Keil的Debug窗口打开外设寄存器视图，调试时直接观察GPIO的ODR寄存器、定时器的CNT计数值，比在代码里打断点然后计算变量值直观得多。仿真时开着这个窗口，对理解整个系统的运行流程非常有帮助。

Keil工程文件记得定期备份，我吃过一次亏，程序写到一半工程文件损坏。如果你也在做这个课题，建议每个阶段完成就导出一次工程备份，这个习惯真的能救命。

希望这篇文章能帮你顺利做完智能药盒的课题设计，从仿真到实物一步一个脚印地打通全程。如果你在做的时候还遇到了什么奇怪的坑，欢迎在评论区留言，我看到就会回复。