做嵌入式课设或者毕业设计，最怕的不是题目难，而是题目看着简单，一上手全是坑。如果你正在做或者准备做“基于STM32智能药盒定时提醒服药系统LCD显示Proteus仿真”这个项目，我先把话放在这里：这个题属于典型的“入门简单、做精难”的类型，网上资料多但碎片化严重，你在B站和论坛上扒来的代码跟Proteus仿真文件经常对不上，一编译全是错，一仿真全黑屏。这篇文章我就把这套项目从需求拆解、硬件选型、仿真搭建、代码实现到报告答辩，完整地串一遍，把我在实际调试中踩过的坑和最终跑通的方案都写出来。内容适合大三、大四做课程设计或者毕业设计的同学，也适合想用Proteus仿真快速验证STM32逻辑的爱好者，看完以后你至少能少走三天的弯路。
1. 项目整体设计与方案选型分析
1.1 需求分析：智能药盒到底要解决什么问题
智能药盒这个题目，本质上不是一个硬件题，而是一个“产品思维”题。很多同学拿到题就直接开干，结果做了一个“能显示时间的LCD”，跟药盒一点关系都没有。我带你重新拆一拆需求，这才是拿高分的关键。
真实的服药场景里有几个痛点：第一，老年人记忆力衰退，经常忘记吃药，或者重复吃药；第二，慢性病患者一天需要吃三四种药，每种药的频次和时间都不一样，靠脑子根本记不住；第三，子女不在身边，没人监督，吃没吃、什么时候吃的完全没有记录。所以一个真正有用的智能药盒，至少要解决“按时提醒”和“区分药品种类”这两个核心问题。
对应到功能模块上，就应该拆成这样：需要一个实时的时钟系统（RTC或者软件计时），需要一组按键用来设置当前时间和每组药的服用时间，需要一个显示屏用来显示时间、药号、提醒状态，还需要蜂鸣器和LED灯做声光提醒。整个系统的工作流程是：开机后显示当前时间和药盒状态，用户通过按键进入设置模式，设定好各组药的提醒时间，主程序进入运行模式，实时比对当前时间和设定的提醒时间，一旦匹配，蜂鸣器响、LED闪、LCD上显示“该吃药了”和药号。
这个需求拆解过程，你在报告里写清楚，评审老师一眼就知道你是真懂还是抄代码。后面所有的硬件选型和软件架构，都是围绕这几点展开的。
1.2 核心器件选型的取舍：为什么是STM32F103C8T6
先说主控芯片。这个项目最常选的就是STM32F103C8T6，没有之一。为什么？先说性能，Cortex-M3内核，72MHz主频，64KB Flash、20KB RAM，跑一个时钟加一个LCD1602的显示逻辑绰绰有余，就算后面你加上DS1302、DS18B20、舵机、语音模块，这个配置也不会紧张。再说工具链，Keil MDK对STM32F1系列的支持非常成熟，标准外设库（StdPeriph_Lib）或者HAL库的资料铺天盖地，哪怕你是第一次接触ARM，照着教程也能把工程跑起来。
有同学会问：“我用51单片机不行吗？”行，但得看你的题目要求。如果题目明确写了“STM32”，你交一个51的板子上去，就算功能全对，评审也会觉得你是避重就轻。另外从学习价值上讲，51是8位单片机，IO直接操作，写惯了51的人转到STM32会有一段阵痛期，而STM32的时钟树、GPIO配置、中断优先级这些东西，才是嵌入式开发的常态。这个项目正好是个过渡的绝佳载体——它不算复杂，但足够让你把STM32的GPIO、定时器、外部中断都练一遍。
再说显示方案。这个题目里写的是“LCD显示”，最常见的搭配是LCD1602，也就是字符型液晶。LCD1602的好处是便宜、驱动简单、Proteus里的仿真模型稳定，显示两行、每行16个字符，对于“时间+药号”这种信息刚好够用。OLED（I2C接口的SSD1306）显示效果更好，但在Proteus里仿真时，I2C时序的稳定性不如LCD1602的并口驱动直观，不适合这个题目追求稳定复现的定位。TFT彩色屏太浪费了，这个功能用不上，还会把代码复杂度拉高。所以我建议就选LCD1602，后面我会把驱动逻辑讲透。
时钟方案比较微妙。STM32内部自带RTC，但用起来有坑：它的时钟源通常是LSE外部32.768kHz晶振，在Proteus仿真里，这个晶振模型偶尔会给你“掉链子”，跑着跑着时间不走。保险的做法是两种：一是直接用STM32的RTC，依赖内部LSI时钟，精度差点但仿真没问题；二是外挂DS1302时钟芯片，这是经典的方案，Proteus里模型非常成熟，代码也好写。我自己的做法是第一版用内部RTC，模块化封装好，想换DS1302的时候改一个接口就行。后面代码部分我会给出封装思路。
1.3 仿真方案的独特价值：Proteus到底在仿真什么
很多人对仿真的理解有偏差，觉得Proteus就是“画个电路图跑一下动画好看”，拿去做实物时不值一提。但你换个角度看：毕业设计做一个实物药盒，焊接、调试、元器件采购的周期至少要一两周，而在Proteus里搭仿真，半天就能把硬件逻辑跑通，代码验证完毕后再去画PCB、买元件，出错率会低很多。这个项目本质上是个“逻辑验证型”项目，硬件电路非常简单，真正的难点在软件逻辑，Proteus恰恰是最适合做这件事的工具。
另外一个容易忽略的点是：Proteus里的STM32仿真，跑的是你Keil编译出来的**.hex**文件，也就是说，它验证的不是C代码本身，而是“编译后的机器码+外围电路”的协同逻辑。这意味着你在仿真中看到的结果，基本就是实物跑起来的结果（前提是电路没画错）。这就是为什么我强烈建议你在仿真阶段就把代码逻辑完全调通，不要带着没验证的代码去打板子。
2. 硬件电路原理与Proteus仿真搭建要点
2.1 LCD1602显示模块的驱动原理
LCD1602是这套系统里的人机交互窗口，你必须把它的工作原理吃透。它的控制核心是HD44780芯片，这个芯片内部有两个寄存器：指令寄存器（IR）和数据寄存器（DR），你对它发的所有命令，本质上就是往这两个寄存器写东西，RS引脚决定你写的是指令还是数据：RS=0的时候，读写的是指令；RS=1的时候，读写的是数据。RW引脚控制读写方向，我们正常显示的时候基本只写不读，所以RW可以直接接地。E引脚是使能信号，一个下降沿，也就是从高电平跳变到低电平时，LCD锁存当前数据线上的内容。
LCD1602有8线模式也有4线模式。8线模式就是DB0-DB7全部接单片机，数据一次传一个字节；4线模式只用DB4-DB7，一个字节分两次传，先高四位后低四位。这个项目里，STM32的GPIO很富裕，我建议用8线模式，时序简单，代码直观，排查问题也容易。Proteus里设置显示对比度的那个电位器，接到V0引脚上，仿真时可调范围很大，如果LCD有显示但看不清，第一件事就是动这个电位器。
我在实际调试中发现，很多同学LCD不显示，不是代码问题，而是初始化时的时序不对。HD44780有一个固定的上电初始化等待时间，从5V电源稳定后，至少要等待15ms才能发第一条指令，之后还要再等待4.1ms发第二条。如果你用单片机的主频比较高，指令发的太快，LCD根本反应不过来，就会出现反复复位却显示不了内容的情况。所以初始化之前加延时函数是必须的，不可省略。
2.2 Proteus仿真工程的核心搭建步骤
Proteus搭建这个项目，我拆成几个关键步骤，每一步都有细节要注意。
第一步，新建工程后，从元件库里取元件。你至少需要添加这几个元件：STM32F103C8T6、LCD1602、RES（电阻）、CAP（电容）、CRYSTAL（晶振）、BUTTON（按键）、BUZZER（蜂鸣器）、LED-RED（发光二极管）以及POT-HG（电位器）。有些元件名字在Proteus里是简写，比如蜂鸣器，Proteus里可能是“SOUNDER”或者“BUZZER”，我建议选“BUZZER”这个有源蜂鸣器模型，仿真音量直接。找不到芯片时，记得在搜索框输入“STM32F103C8”而不是“STM32”，不然会过滤掉很多结果。
第二步，搭最小系统。STM32F103C8T6在Proteus里有两种放置方式：一种是直接放芯片，需要自己接晶振电路和复位电路；另一种是Proteus提供的“STM32最小系统板”封装。我强烈建议用前者，自己接，因为你的报告里需要这个电路图，评审会问。
最小系统电路的核心是：VDDA、VSSA这些电源引脚全部接3.3V和地；NRST复位脚接一个10k上拉电阻到3.3V，再串一个0.1uF电容到地，这是标准的复位电路；PD0和PD1接8MHz晶振，两个引脚各接一个20pF电容到地，组成晶振起振电路。这整套电路缺一不可，你少画一个电容，仿真可能都跑不起来。
第三步，LCD1602连接。RS、RW、E分别接PA0、PA1、PA2，数据引脚DB0-DB7接PB0-PB7，V0接电位器中间脚，电位器两端分别接3.3V和地。这些GPIO的分配不是随便定的，要跟你的代码一一对应，建议整理成一张表格，写报告的时候直接贴进去。
第四步，按键和蜂鸣器连接。PA3、PA4、PA5接按键到地，按键另一端接3.3V，也就是低电平触发；PA6接蜂鸣器、PA7接LED，这两个直接通过限流电阻接地。按键接3.3V的做法，是为了利用STM32内部上拉，外部不用再加电阻，简单省事。
这些都连好后，最关键的一步来了：给芯片加载hex文件。双击Proteus里的STM32芯片，在“Program File”那一栏选择你Keil编译生成的hex文件，注意路径不能有中文，这个坑我后面还会重点讲。加载完成后，点左下角的运行，仿真就跑起来了。
2.3 Keil工程配置：从编译到生成Hex的完整闭环
Proteus要跑你的程序，前提是你得生成hex文件。这里Keil的配置是很多新手的重灾区。
首先，你不会在Keil的默认安装里直接找到STM32F103C8T6这个型号。你需要先安装器件支持包（Device Family Pack）。打开Keil自带的Pack Installer，在“Device”列表里找到“STMicroelectronics”下的“STM32F1 Series”，点安装。如果没有这个选项，说明你的Keil版本太老，或者MDK升级没做，建议直接安装Keil 5.20以上的版本。
工程创建流程我快速说一下：Project→New μVision Project，选择保存路径（同样别有中文），在器件选择界面输入“STM32F103C8”，选中后弹出Manage Run-Time Environment，这个界面不用动，直接左上角“OK”关掉。然后右键Source Group，添加一个main.c文件，开始写代码。
然后是最容易被忽略的一步：配置Output选项。点击魔术棒图标（Options for Target），在“Output”标签页里勾选“Create HEX File”，然后用“C/C++”标签页里确认硬件浮点、宏定义没有配错。我见过太多人写了大半天代码，编译零错误，结果Proteus加载时找不到hex文件，就是因为忘了勾这个。
还有一点，STM32F103C8T6的内部Flash只有64KB，如果你的代码优化等级设得太低，一个简单工程也可能逼近这个上限。建议在“C/C++”选项卡里把Optimization设为“-O2”或者“Level 2”，代码量小的时候没有区别，但等你加了完整的中文注释、断言、官方的库代码，区别就出来了。
3. 软件代码架构与核心功能实现
3.1 系统状态机设计：让程序逻辑清晰可维护
智能药盒的程序逻辑，绝不能写成一坨在while循环里堆叠的if-else，不然过两天你自己都看不懂。我采用的方案是状态机架构。
整个系统分成四个状态：待机显示状态（STATE_DISPLAY）、设置模式状态（STATE_SETTINGS）、运行监控状态（STATE_MONITOR）和提醒触发状态（STATE_ALERT）。待机显示状态下，LCD显示当前时间、日期和药盒状态摘要；设置模式下，用户通过按键调整时间和各组药的提醒时间，这个状态里有子菜单，包括设置小时、设置分钟、设置药号1时间、设置药号2时间等；运行监控状态是默认状态，程序在死循环里不停比对时间；提醒触发状态下，蜂鸣器鸣响、LED闪烁、LCD显示醒目的提示语，直到用户按下确认键。
这个状态机用C语言来实现，核心就是一个switch-case结构，配合一个状态迁移函数：
typedef enum { STATE_DISPLAY, STATE_SETTINGS, STATE_MONITOR, STATE_ALERT } SystemState; SystemState currentState = STATE_DISPLAY; while (1) { switch (currentState) { case STATE_DISPLAY: displayCurrentStatus(); if (keyPress & KEY_MODE) currentState = STATE_SETTINGS; break; case STATE_SETTINGS: handleSettingsMenu(); if (keyPress & KEY_CONFIRM) currentState = STATE_MONITOR; break; case STATE_MONITOR: monitorTimeAndCheckAlarm(); break; case STATE_ALERT: handleAlert(); if (keyPress & KEY_CONFIRM) currentState = STATE_DISPLAY; break; } }状态机的好处是：第一，代码可读性强，评审老师看一眼状态定义就知道系统设计思路；第二，功能扩展容易，想加一个“用药记录”功能，就再加一个STATE_RECORD状态，不影响原有的逻辑。这个设计思路在答辩的时候非常加分，因为体现的是“软件工程”的意识，而不是单纯会调库。
3.2 按键扫描与时间设置：这个环节连老师都会问
按键处理是STM32入门里最基础的模块，但这个项目里它是整个系统的输入入口，处理不好会让用户崩溃。我用的方法是定时器扫描+状态标志，或者叫“非阻塞扫描”。
按键接法里我提过，用的是GPIO读电平的方式。核心逻辑是：按键按下时电平变化，但机械按键有抖动，常见的抖动时间是10-20ms，你直接读一次就判断按键按下，一定会出现按下一次系统响应好几次的问题。解决方法是延时消抖——检测到电平变化后，先延时10ms，再读一次，如果电平跟之前一致，才认定是有效按下。
uint8_t KEY_Scan(void) { static uint8_t keyUp = 1; if (keyUp && (KEY_MODE_PIN == 0)) { HAL_Delay(10); keyUp = 0; if (KEY_MODE_PIN == 0) { return KEY_MODE_PRESSED; } } else if (KEY_MODE_PIN == 1) { keyUp = 1; } return KEY_NONE; }这里有一个细节：keyUp这个静态变量是关键。它保证了只有按键“从松开到按下”这个变化时，函数才返回一次有效按键。如果你用了简单的“电平=0就返回按下”，那只要按键不松开，主循环里每跑一圈就触发一次，设置时间时数值会狂跳，根本停不下来。
时间设置流程我建议这样设计：按“模式”键进入设置状态，LCD第一行显示当前设置项（比如“SET HOUR:”），第二行显示当前小时数，按“加”键数值加1，按“减”键数值减1，设置完小时按“确认”进入分钟设置，依次设置完各药号的提醒时间后，按“确认”退出设置状态。这个流程用户很容易理解，代码逻辑也清晰。另外，设置过程中要做数值边界检查，小时不能超过23，分钟不能超过59，防止用户把时间加到溢出。
3.3 定时提醒的核心逻辑：时间比对与触发条件
提醒功能是这个系统的大脑。设计思路上，我们不是用中断去触发提醒，而是采用轮询比较的方式。这样更直观，也不容易出错。
具体实现是：写一个函数check_alarm()，在运行监控状态下每秒钟调用一次。函数里读取当前的时和分（小时变量currentHour和分钟变量currentMinute），然后跟所有已设置的提醒时间（药号1的小时alarm1Hour、分钟alarm1Minute，药号2的设置同理）逐一比对。只要时分完全相等，就认为到点了，把提醒标志位置1。
void check_alarm(void) { if ((currentHour == alarm1Hour) && (currentMinute == alarm1Minute) && (alarm1Enabled == 1)) { activeAlarmId = 1; systemState = STATE_ALERT; } if ((currentHour == alarm2Hour) && (currentMinute == alarm2Minute) && (alarm2Enabled == 1)) { activeAlarmId = 2; systemState = STATE_ALERT; } }这里有个小细节特别重要：分钟相等就触发，意味着同一分钟内让这个条件成立的时间和当前时间相差不能超过1分钟。如果程序检测频率是每秒一次，那么这个“到点”会被检测到大约60次，但因为检测到后立刻进入提醒状态、并且设置了提醒触发标志，所以不会重复触发。为了绝对安全，你还需要一个“本次提醒已触发”的防重入标志，否则每分钟的第一个检测周期通过后，系统会认为同一分钟内的第二个检测周期也是有效触发，就会发生“持续触发、无法确认”的假象。
提醒触发后，LCD在当前行显示“TAKE MEDICINE 1”或者“TAKE MEDICINE 2”，蜂鸣器鸣响、LED闪烁，直到用户按确认键才退出。这个过程里LED闪烁是可变频率的，我用一个计数器控制，让LED每200ms翻转一次，看起来很醒目。
3.4 LCD显示驱动与屏显规划
LCD1602的驱动代码网上很多，但很多是直接拷贝的，缺少解释。我把它拆成三层：底层是引脚操作函数，包括lcd_write_command()和lcd_write_data()，负责时序；中间层是初始化函数lcd_init()，负责按照HD44780的要求发送初始化指令序列；应用层是lcd_show_string()这样方便调用的功能函数。
void lcd_write_command(uint8_t cmd) { LCD_RS_GPIO_PORT->BSRR = LCD_RS_PIN; // RS=0 命令模式 LCD_DATA_GPIO_PORT->ODR = (LCD_DATA_GPIO_PORT->ODR & 0xFF00) | cmd; LCD_E_GPIO_PORT->BSRR = LCD_E_PIN; // E置高 delay_us(1); LCD_E_GPIO_PORT->BSRR = ((uint32_t)LCD_E_PIN << 16); // E拉低，下降沿锁存 delay_us(50); }初始化序列是HD44780最讲究的地方。我建议按这个顺序：延时50ms → 写0x30（8位模式）→延时5ms → 写0x30 →延时5ms → 写0x30 →延时5ms → 写0x38（8位数据、2行显示、5x7点阵）→ 写0x08（关闭显示）→ 写0x01（清屏）→写0x06（光标右移、不自动滚屏）→写0x0C（开显示、关光标）。每一步中间的延时必须给足，尤其是上电早期的几条命令，LCD自身还在初始化总线，你太快发它接收不了。
显示内容的规划上，我在第一行放当前时间和状态，比如"TIME: 12:30 OK"或者"TIME: 12:30 SET"；第二行放药盒提醒信息，比如"MED1:8:00 MED2:12:30"或者直接显示"REMINDER: MED1"。提醒触发时，再用第二行显示醒目的"TAKE MEDICINE 1"，配合蜂鸣器，保证用户一眼能看到。LCD1602显示不了中文，这是它天生的限制，所以在Proteus仿真图里，不能用中文提示语，你可以用英文，也可以定义你习惯的提示缩写。这些都是代码里的小细节，却是切切实实影响使用体验的地方。
3.5 RTC计时与UART调试选项：隐藏在每个环节里的“加分项”
这个项目要显示“当前时间”，所以时间基准是必不可少的。这里我提供两个方案：
方案一，用STM32内部RTC。RTC模块独立于内核运行，有自己的一套寄存器。在标准库里面，需要先开启电源管理的后备寄存器访问权限（PWR和BKP相关），然后选择LSI或LSE作为RTC时钟源。要注意的是，如果选了LSE外部晶振，Proteus仿真里没有真实的32.768kHz晶振模型的情况下，RTC时间可能不走，这时候切换LSI内部时钟源就好用了。这种方案的好处是省了一个外部芯片，缺点是日期比较蛋疼——STM32的RTC只有秒、分、时寄存器，闰年和月份逻辑全要自己算。
方案二比较简单直观，外挂DS1302。DS1302是个工业级经典芯片，Proteus里有现成的仿真模型，最早接触过的同学可能还记得它的“时钟芯片”标签。DS1302初始化、读写时间和内部RAM的代码网上非常多，可靠性也经过验证。我之所以推荐这个方案，是因为它把“当前时间哪来的”这个问题完全外包出去了，主程序只负责“读时间→比较→显示”，逻辑更清晰。
UART调试是我每次做嵌入式项目必留的后门。即使显示正常，在调试阶段，把关键状态变量通过串口打印出来，可以快速定位问题。我用ST-Link虚拟串口，也可以用Proteus里的Virtual Terminal（虚拟终端）元件，直接连在STM32的USART1引脚上，代码里加几句 printf，运行时虚拟终端会显示调试信息。这个技巧在仿真阶段尤其好使，因为Proteus里你根本不需要外接串口模块。
4. 常见问题排查与调试实录
4.1 LCD不显示或显示异常：先查硬件还是先查代码
我在帮人看这个项目的过程中，碰到最多的问题就是“LCD显示不出来了”。这里给你一套排查顺序，照着做能省很多时间。
第一步，检查Proteus仿真里的LCD对比度电位器。这是一个物理层的检查，你手动拖动调节电位器的滑动端，如果显示内容若隐若现，说明LCD本身工作正常，只是对比度电压不对。LCD1602的V0引脚电压一般要在0.5V到1V之间，你把电位器扭到中间位置附近基本都能兼顾。
第二步，检查接线。确认RS、RW、E、DB0-DB7没接错，尤其是RW，如果误接了高电平，LCD就进入读模式，你写什么它都不理。还要检查数据引脚跟电路图代码里定义的是否一致，比如你代码里用的是PB0-PB7，电路图里却接到了PA0-PA7，那显示一定是乱的。
第三步，检查初始化时序。这是代码层面的重点。我特意用自己的代码做测试，发现初始化时如果前面的延时只有1ms，确实会出现LCD无法正常工作的现象，而把关键位置的延时调整到5ms后，一切正常。所以你的HAL_Delay(50)、HAL_Delay(5)这些地方，宁可多不能少。
第四步，检查是否有在写LCD前正确设置RS和E的时序。很多人直接套网上代码，结果RS置高和置低的逻辑跟E的触发沿不匹配。你在打方向上是写数据还是写命令，必须在函数入口就确定，并且RS的电平要在E下降沿之前保持稳定，这个时序花了几天调试是真真实实的教训。
4.2 Proteus仿真常见的“黑屏”和“跑不动”问题
Proteus仿真的黑屏分两种情况：一是LCD黑屏，二是整个仿真界面完全没有反应。LCD黑屏按上一节的排查顺序来；整个仿真没反应，重点检查这几块：
第一个坑是hex文件加载位置。双击STM32芯片，看“Program File”的路径是不是备份过，里面有中文路径会让文件加载失败，芯片显示“No Program File”或者运行时提示内存访问错误。把工程路径改成纯英文，再重新编译、重新加载。
第二个坑是晶振没接。STM32F103C8T6内部有HSI振荡器，如果代码里设置的是默认启动方式（内部HSI），那你可能不接外部晶振也能跑；但如果你在代码或者CubeMX里配置了外部HSE，而Proteus里又没有给芯片加8MHz晶振和两个20pF负载电容，复位之后会一直卡在启动文件的状态检查里。这是最常见的原因。
第三个坑是复位电路的电容阻值不匹配。NRST的10k上拉和0.1uF电容到地是最经典的最小系统配置，你换成1k、或者把电容换成10uF，可能会发生上电瞬间复位信号不释放，芯片一直停留在复位状态，整个仿真的现象就是“点了运行什么都没发生”。
第四个坑是关于芯片型号。Proteus里的“STM32F103C8”这个型号可能需要到“PIR”这类第三方库才能用，不同版本Proteus的元件差异很大。建议使用Proteus 8.9以上版本，里面的STM32元件库更完整，能直接用自带模型，不需要额外装补丁包。
4.3 Keil编译报错的几种典型场景
编译报错里，“未定义标识符”和“找不到头文件”是最常见的，新手一半的报错是配置问题而不是代码问题。
“找不到头文件”多半是Include Path没配好，或者你用的stm32f1xx_hal_conf.h等配置文件不在工程目录里。配置Include Path的方法是：魔术棒→C/C++→Include Paths，把包含头文件的文件夹路径加进去。如果是标准外设库工程，通常需要加Libraries\CMSIS\Device\ST\STM32F1xx\Include、Libraries\CMSIS\Include等好几个路径。
“未定义标识符”，比如GPIO_PIN_0、RCC_APB2Periph_GPIOA报错，多半是没加对应的头文件，比如stm32f1xx_hal_gpio.h、stm32f1xx_rcc.h。如果你用的是标准库，还要确认定义了STM32F10X_MD这个宏，否则芯片型号对不上，寄存器定义全部无效。这个宏在魔术棒→C/C++→Preprocessor Symbols→Define里加。
如果你用HAL库的方式，编译报“undefined reference toHAL_Delay”之类的链接错误，八成是没把延迟函数所在的源文件加进工程，或者在启动文件里没有把对应的中断处理函数声明好。HAL库的报错大多集中在链接阶段，因为它有一大堆依赖文件，缺一个就整体崩。
“编译零错误但Proteus运行完全没反应”的情况，如果你确认hex加载成功、晶振复位都对，那就要看代码里的时钟树配置是否跟Proteus的仿真速度匹配。Proteus仿真器默认按实时运行，如果你的主频很高（比如72MHz）而仿真性能跟不上，会出现运行了一秒钟，实际上仿真时间只走了0.0001秒的现象。这时候你可以把仿真速度调快，或者把已有的128倍默认值改低，让仿真器更平滑地运行。
5. 报告撰写、答辩讲解与项目扩展思路
5.1 设计报告的架构与核心章节怎么写
很多同学功能做完了，报告却写得七零八落，分数直接砸了。一份完整的智能药盒设计报告，我给你按标准格式列个提纲，你照着填：
第一章，绪论。写背景和意义，重点突出“老龄化社会”、“慢性病管理”、“用药安全”这些关键词，注意不要大段抄网上的车轱辘话，要有自己的理解。比如可以写：“我国慢性病患者数量逐年上升，多药联用场景下错服、漏服事件频发，传统药盒缺乏定时提醒功能，因此设计一种成本可控、易于操作、适合老年人使用的智能药盒具有现实意义。”这一段50字就够了，别写1200字废话。
第二章，系统总体方案设计。画系统框图（用Visio或者PPT画，别用手画拍照），阐述STM32F103C8T6选型的理由，对比方案表里放上51、STM32、ESP32的优缺点对比。这点很加分，说明你做过选型调研。
第三章，硬件电路设计。每个模块单独一个小节：最小系统、LCD显示模块、按键模块、蜂鸣器模块、DS1302/内部RTC接法。每个模块都要有电路原理图，引脚分配表必须清晰，标注PA几、PB几。
第四章，软件程序设计。把状态机设计、主程序流程图、各模块驱动函数，尤其是LCD初始化和按键扫描的核心代码放上去。流程图建议用标准流程图符号画，清晰的逻辑结构能让评审迅速抓住你的设计思路。
第五章，仿真调试与结果分析。放Proteus仿真截图，每个功能场景截一张：正常显示图、设置时间界面图、提醒触发状态图。截图旁边写“图5-1 系统正常运行界面”，再配上文字说明运行状态。有条件的还可以放一段仿真视频的链接。
第六章不用单写“总结”，很多论文模板要总结，但你可以把它合并到“结论”小节里。写结论的时候不要用“本设计实现了……”这种空话，要写“系统经过仿真测试，能够在设定时间触发声光提醒，LCD显示内容清晰，按键响应灵敏，达到预期设计目标。局限在于未进行实物验证，后续可考虑移植至实物平台并增加远程通信功能。”评委会觉得你既务实又有后续规划意识。
5.2 答辩讲解的演示策略
答辩环节，很多人的问题不是不懂技术，而是不会“讲”技术。我用几个关键策略给你演示一下怎么讲。
开场30秒，你要解决的是“我做了什么”。话术可以是：“老师好，我这个题目的核心是设计一个智能药盒，解决老年人漏服药、重复服药的问题。整个系统由STM32F103C8T6作为主控，通过LCD1602显示当前时间和药物信息，用按键设置提醒时间，到点后蜂鸣器响、LED亮。我用了Proteus做了完整仿真，并且对系统进行了模块化测试。”这段话清晰、有逻辑、有落地感。
讲硬件时，不要去念引脚表，而要讲“为什么这么接”。比如被问到“为什么用LCD1602”，就回：“因为我只需要显示两行文本信息，1602的成本和复杂度都最低，如果题目要求显示中文我再换成OLED，但OLED在Proteus里时序仿真不稳定，所以选了1602。”这种对比思维是答辩高分的关键。
被问“为什么用状态机”，就回：“因为系统存在多个运行阶段，用if-else堆逻辑会让代码很难维护，状态机把每个阶段拆开，后续加功能只需要加新的状态，不需要改动原有逻辑。”这里如果老师追问“状态机是怎么存储的”，你就把枚举变量currentState拿出来讲一遍，没问题。
被问“如果做实物，仿真跟实物的差异在哪些方面”，这是个高概率考点。你从三个方面回：一，Proteus的按键无机械抖动，实物的抖动需要完善的消抖处理；二，LCD的对比度在实物上需要现场调，仿真里电位器默认给你调好了；三，实物要考虑供电方案，比如用USB供电或电池供电，需要额外的稳压电路。这个回答展示了从仿真到落地的完整思考。
最后可以再补一句：“这个项目后续我想再加一个GSM模块，到点后发短信给子女手机。”这句话点到为止，既展示了前瞻性，又不会让老师觉得你在吹牛。
5.3 从课程设计到真正产品：四个值得深挖的扩展方向
做一个项目如果不扩展，那它的价值就局限在课程分数里。我把这个智能药盒实物化过程中最有价值的几个扩展方向列出来，你带入报告和答辩时会有用：
方向一，远程通知。药盒到点提醒，老人可能没听到。加ESP8266或者GSM模块，把提醒事件推给子女的微信或者短信，这才能实现远程监护。STM32F103C8T6的USART2或者USART3正好可以串口接ESP8266，代码里在进入提醒状态时多调一个send_reminder_to_wechat()就行。
方向二，用药记录。系统记录用户每次药物提醒的确认时间，存储在EEPROM或者SD卡里，定期导出数据。这需要增加一个存储模块和一个数据导出的协议，代码上就是在提醒确认时打一个时间戳，唯一的难点是当前时间来源要稳定，所以这个方向适合换成DS1302方案。
方向三，多药格设计。当前方案用LCD显示“MED1、MED2”来区分药品种类，但物理上只有一个仓。改成4个仓位，每个仓位下面放一个微型舵机或者电磁锁，提醒时打开对应的格子，再配一个红外传感器检测是否取药，还能实现“喂药记录”闭环。这个方向对结构设计和步进电机的控制是考验，适合想做实物作品毕设的同学。
方向四，语音提示。蜂鸣器只能发出“嘀嘀”声，老年人可能不知道是哪个药。用语音播放模块（如WT588F）在提醒时播报“请服用白色药片”，交互体验会好很多，代码量和硬件成本都会上升，但这是产品化的必经之路。
这些扩展思路不用全部实现，在报告“总结与展望”里写出来，会让你的项目显得有深度，而不是“做完就完”。
最后分享几个我自己的实操心得
做这个项目最大的教训，是在别人代码里打转。刚开始我也图省事，从网上下载一个看着差不多的工程，想改改就能交，结果光是库版本不匹配、引脚定义混乱就折腾了两天，最后还是一行一行重写才跑通。所以我的建议是：主逻辑，尤其是LCD初始化和按键扫描，一定要自己写，这两块代码量不大，但写一遍你对系统的理解会完全不一样。
另外一个心得是存储路径的事，群里有同学因为工程保存在桌面（路径含中文“桌面”），Proteus加载不了hex，一晚上都觉得是代码问题，最后才查出来是路径问题。从建工程那一步开始，全部用英文路径，这是最省钱的经验。
最后一个建议是关于“仿真通过之后”。仿真只是第一步，如果你有条件，强烈建议买一块STM32F103C8T6最小系统板和一块LCD1602，把仿真里的电路一比一搭出来验证一遍。仿真里没有的接线问题、供电噪声、按键抖动，实物上都会显现。真到那个阶段，你才真正算是迈进了嵌入式开发的门。
在这条路上踩过的坑，写出来就是这篇文字。希望你能少走弯路，一次跑通。
