STM32智能家居安防系统Proteus仿真设计与实现

简介：本资源是一套基于STM32的智能家居安防系统Proteus仿真工程，面向嵌入式初学者、课程设计学生及物联网项目实践者，解决家庭环境多参数监测与远程告警的典型应用场景问题。压缩包共281个文件，含56个编译中间文件（.d）、55个C源码（.c）与头文件（.h）、39个目标文件（.o）、6个Proteus项目文件（.pdsprj）及OLED驱动、GSM/Wi-Fi通信、传感器数据采集等核心模块代码，整体大小为13.42MB。已有278人学习下载，资源结构完整，涵盖STM32F10x标准外设库底层驱动（如tim、rcc、adc、i2c等）、多传感器融合逻辑、短信报警协议实现、OLED动态界面刷新及Wi-Fi手机端监控基础框架，可直接导入Keil与Proteus进行联合仿真调试，具备较强的教学参考性与工程复用价值。 我曾经在学校实验室里完整跑通过一套基于STM32的智能家居安防系统，而且全程没有使用实物硬件，所有电路和逻辑都在Proteus仿真环境里验证完成。这套系统涵盖了烟雾检测、火焰报警、人体红外入侵侦测、声光报警、风扇联动排烟、LCD状态显示等多个功能模块，对于正在做课程设计、毕业设计，或者想低成本快速验证一套物联网安防方案的开发者来说，都是很好的参考模板。

很多人一听到仿真就觉得是“玩具”，实际用过Proteus做STM32项目的人才知道，仿真在前期逻辑验证阶段的价值远比你想象中大。它不需要买元件、不需要焊板子，甚至不担心烧坏芯片，你可以随时修改电路、调整参数、反复跑程序，这对初学STM32和嵌入式系统设计的人极其友好。下面我把这套系统的设计思路、电路搭建、代码逻辑、仿真调试中踩过的坑，以及从仿真迁移到实物的经验，全部整理出来。

1. 项目概述与整体设计

1.1 这套安防系统能做哪些事

先明确这套系统解决的痛点。传统家居安防往往需要多套独立设备，烟雾报警器、燃气探测器、入侵报警器各管各的，互不联动。我做这个项目的目标，是把几种常见安防传感器集中到一个主控平台上，由STM32统一下发判断逻辑，再驱动声光报警和排风设备，形成一套真正意义上的“智能联动”系统。

具体功能如下：

• 烟雾浓度检测：通过ADC采集烟雾传感器输出的模拟电压，软件判断浓度是否超过阈值，超限后触发火灾报警，同时自动启动继电器控制风扇排烟。
• 火焰检测：火焰传感器模块输出数字信号，检测到火焰时立即进入火警状态，蜂鸣器急促鸣叫、红色LED快速闪烁。
• 人体红外入侵检测：布防状态下检测到人体活动，触发入侵警报，蜂鸣器长鸣、LED常亮。
• 布防/撤防切换：通过按键切换系统状态。撤防时入侵检测不生效，避免家人正常活动触发误报；烟雾和火焰检测始终保持开启，确保火灾隐患随时被感知。
• 状态显示与日志输出：LCD1602实时显示系统状态、烟雾浓度等级和报警信息；USART1虚拟终端输出更详细的调试日志，方便观察系统运行流程。

这套功能设计参考了市面上常见的家用安防主机逻辑，复杂度适中，既能完整体现STM32的GPIO、ADC、定时器、串口、外部中断等核心外设的使用方法，又不会因为功能堆砌导致代码失控。

1.2 为什么选择Proteus仿真而不是直接做实物

如果直接做实物，你需要准备STM32最小系统板、各种传感器模块、继电器、蜂鸣器、杜邦线、电源模块，还有万用表、示波器甚至烙铁。这些投入对已经有一定基础的工程师不算什么，但对刚接触单片机的学生和转行开发者，是一道不低的门槛。

Proteus的价值在于“电路和程序的联合调试”。你可以把电路画出来，把Keil编译出来的hex文件加载进去，然后直接点运行，亲眼看到传感器数值变化、蜂鸣器动作、LED闪烁、LCD更新。这种即时反馈对理解“程序如何控制硬件”非常有帮助。更关键的是，仿真环境允许你故意把电路接错、反复修改参数，这些操作在实物上往往会损坏元件，而在仿真里成本为零。

不过必须说实话，仿真也有局限。Proteus里的传感器模型大多是用等效电路模拟的，比如用可调电阻代替烟雾传感器的电压输出，它不能真正还原传感器在不同气体浓度下的响应曲线。所以在做仿真时，我会刻意把“传感器采集”和“逻辑处理”解耦，仿真重点验证的是主控逻辑、阈值判断和联动控制，传感器本身的物理特性放到实物阶段再去标定。

1.3 系统架构与硬件选型总览

整个系统从信号流向上分为三层：

• 感知层：烟雾传感器（用电阻分压模拟）、火焰传感器（用按键模拟数字跳变）、人体红外传感器（用按键模拟）。
• 处理层：STM32F103C8T6主控芯片，负责采集、判断、状态机切换、输出控制。
• 执行层：蜂鸣器、LED指示灯、继电器控制的排风扇、LCD1602状态屏、USART1虚拟终端。

硬件选型上，主控选择了STM32F103C8T6，原因很直接：这是Proteus里支持最完善、资料最多、工程模板最多的ARM Cortex-M3芯片。整个项目用到的外设包括GPIO、ADC1、定时器、USART1，这些都是F103系列的看家本领。

传感器选型方面，我刻意避开了Proteus库里表现不稳定的MQ-2和DHT11模型。MQ-2在部分Proteus版本中缺失或工作异常，DHT11的时序仿真也经常让人头疼。更稳妥的做法是：烟雾传感器用精密可调电阻（POT-HG）输出的模拟电压代替，火焰和人体红外用按键切换高低电平代替。这套替代方案不依赖任何第三方模型，在任何Proteus 8.x版本上都能稳定运行。

2. 核心硬件电路设计与元件选型

2.1 主控选型：为什么是STM32F103C8T6

STM32F103C8T6是意法半导体Cortex-M3内核的经典芯片，主频最高72MHz，Flash 64KB（实际上部分批次是128KB），SRAM 20KB，配备3个USART、2个SPI、2个I2C、1个12位ADC（最多10通道）、多个定时器。这个配置放在安防系统里绰绰有余，而且它的LQFP48封装在Proteus里引脚齐全，仿真模型成熟稳定。

选择它的另一个原因是生态。国内学习STM32的群体里，F103C8T6是绝对的“启蒙芯片”，不管是标准库、HAL库还是LL库，资料数量都是所有MCU里最多的。这意味着你遇到任何问题，几乎都能在网上找到解决方案。Proteus运行时，芯片模型内置了完整的Cortex-M3内核和外设行为级模型，能够较为真实地模拟寄存器读写、中断响应、ADC转换等行为，这一点对调试非常有价值。

需要注意的是，Proteus里的STM32F103C8T6模型在加载程序时，默认使用芯片内部时钟进行仿真，不需要像实物那样外接8MHz晶振。如果你按照实物习惯画上晶振电路，不接也能跑；但如果代码里配置成等待HSE（外部高速时钟）就绪，仿真很容易卡死在启动阶段。后面软件章节我会给具体的解决方案。

2.2 传感器接口电路设计

烟雾传感器模拟电路

我用一个10kΩ电位器（POT-HG）模拟烟雾传感器模块的模拟输出引脚。电位器两端分别接3.3V和GND，中间抽头连接STM32的PA0（ADC1通道0）。旋动电位器，PA0上的电压在0~3.3V之间变化，经过STM32内部12位ADC转换后得到0~4095的数字量。

这里有一个关键点：STM32的ADC参考电压VREF+默认接3.3V，所以模拟输入电压不能超过3.3V。如果你给传感器电路供5V，就必须先分压再进ADC，否则会损坏单片机引脚。仿真阶段我用3.3V供电，省去了分压电阻，但在实物阶段务必注意这一条。

火焰传感器模拟电路

火焰传感器模块在真实硬件中通常输出数字电平，检测到火焰时DO引脚输出低电平（也有高电平版本，取决于模块设计）。仿真时，我用一个按键连接PA1（配置为上拉输入），按键另一端接地。平时PA1读到高电平，表示无火情；按下按键，PA1被拉到低电平，表示检测到火焰。为了方便观察，我在PA1上还并联了一个LED，按键按下时LED点亮，直观显示传感器信号状态。

人体红外传感器模拟电路

同样采用按键模拟方案，PA2复用为上拉输入，按键一端接GND。按下时电平拉低，表示有人在区域内活动。这个方案避免了在Proteus里寻找PIR模型的麻烦，也让整个系统搭建过程更专注在主控逻辑上。

按键模块

系统需要两个手动控制按键：一个是布防/撤防切换键，连接到PA3；另一个是报警复位/消音键，连接到PA4。两个按键都采用“按下接地”的接法，配合STM32内部上拉电阻，不需要外部上拉。

这里要特别提醒：仿真里按键的抖动和实物一样存在，我在代码里做20ms软件消抖，不能省。否则你会发现按下一次按键，系统状态跳变了两次。

2.3 报警联动与显示电路

蜂鸣器驱动电路

蜂鸣器选用Proteus自带的BUZZER模型（有源蜂鸣器，低电平触发型），连接到PB0。为了避免直接驱动电流过大，中间串一个1kΩ限流电阻。在实际工程中，蜂鸣器需要三极管驱动，因为单片机GPIO的驱动能力一般只有20mA左右；但在Proteus仿真模型里，直接用GPIO驱动BUZZER通常也没问题。我在设计原理图时仍然保留了三极管驱动电路，这样从仿真转到实物时电路结构不需要大改。

LED指示灯电路

两个LED指示灯连接到PB1和PB2，分别代表火警和入侵警报。LED串联330Ω限流电阻接地，GPIO输出高电平点亮。这个电路最简单，但却是排查系统是否正常工作的第一道“信号灯”。

继电器与排风扇

PB3控制继电器模块，驱动一个排风扇模型。继电器驱动电路使用2N2222三极管，基极串联1kΩ电阻，继电器线圈两端并联1N4007续流二极管。当烟雾浓度超限时，PB3输出高电平，三极管导通，继电器吸合，常开触点闭合，排风扇通电运转。

续流二极管一定要画上。继电器线圈是感性负载，断电瞬间会产生反向电动势，没有续流二极管的话，轻则干扰单片机复位，重则击穿三极管。这个经验我在实物调试中踩过，教训深刻。

LCD1602显示电路

LCD1602在Proteus中通常搜“LM016L”，是经常被新手忽略的坑。我使用4位数据模式连接，以节省GPIO：

• D4~D7 → PC0~PC3
• RS → PC4
• EN → PC5
• RW直接接地（只写不读）

LCD的VO对比度引脚接一个10kΩ电位器到GND，调节显示清晰度。在Proteus里，如果发现LCD显示方块或者无字符，绝大多数情况是VO引脚电位没调好，而不是代码问题。

串口虚拟终端

USART1的TX（PA9）接虚拟终端的RX端，GND接GND。波特率设为115200。这个串口输出在联调阶段帮了大忙，可以把ADC采集值、系统状态切换等信息实时打印到虚拟终端上，方便确认程序跑到了哪个分支。

3. 软件设计与核心逻辑实现

3.1 开发环境与工程配置

软件部分我选择Keil MDK uVision5 + 标准外设库（StdPeriph_Lib 3.5）。为什么不选HAL库？不是HAL不好，而是很多大学课程和网上教程（比如流传很广的江科大STM32教程）都以标准库为主线，初学者对照起来更容易。如果你想用STM32CubeMX生成工程再用HAL库写代码，逻辑也是相通的，只要把外设初始化部分换成HAL接口，主程序框架完全可以复用。

新建工程时要注意几个关键配置：

• 在“Options for Target → Output”页面勾选“Create HEX File”，否则Proteus无法加载烧录文件。
• 选择正确的芯片型号：STM32F103C8。
• C/C++选项卡里添加宏定义：USE_STDPERIPH_DRIVER, STM32F10X_MD。这两个宏是标准库编译的基础，忘了定义会出现一堆头文件错误。

工程结构上，我分成几个模块文件：main.c（主循环与状态机）、adc_drive.c（ADC采集）、key_drive.c（按键扫描）、buzzer_drive.c（报警输出）、lcd_drive.c（显示）、usart_drive.c（串口日志）。模块化写代码的好处是调试阶段可以单独验证每个文件，出问题不用从头翻。

3.2 主循环与按键处理

主程序采用“初始化 + 超级循环”的结构，这是嵌入式裸机最经典的写法。系统状态用枚举变量定义：

typedef enum { SYS_INIT = 0, SYS_DISARMED, // 撤防 SYS_ARMED, // 布防 SYS_ALARM_FIRE, // 火警 SYS_ALARM_INTRU // 入侵 } SysState; static SysState g_state = SYS_INIT;

按键扫描采用非阻塞方式，在主循环中周期性调用。核心代码如下：

void Key_Scan(void) { static uint8_t key_last[2] = {1, 1}; uint8_t key_buf[2]; key_buf[0] = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_3); // key1 布防 key_buf[1] = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_4); // key2 消音 for (uint8_t i = 0; i < 2; i++) { if (key_buf[i] == 0 && key_last[i] == 1) { Delay_Ms(20); // 消抖 if (GPIO_ReadInputDataBit(GPIOA, (i ? GPIO_Pin_4 : GPIO_Pin_3)) == 0) { Key_Action((KeyId)i); // 触发有效操作 } } key_last[i] = key_buf[i]; } }

这里有两个细节值得说。第一，消抖不能用delay阻塞太长，尤其主循环里还有其他实时任务时，20ms左右的短延时是能接受的，但如果是更复杂的系统，建议改用定时器扫描，每5ms扫描一次按键，两次连续读到低电平再确认有效。第二，按键触发动作后要更新key_last状态，否则长按会重复触发。

布防/撤防切换逻辑放在Key_Action里：如果当前是撤防态，按Key1进入布防态；如果是布防态且没有报警，按Key1回到撤防态。如果在报警状态，按Key2则清除报警、恢复布防或撤防状态，同时关闭蜂鸣器、继电器、LED。

3.3 模拟量采集与阈值判断

烟雾浓度通过ADC1的通道0（PA0）采集，温度传感器也通过ADC1的通道1（PA1）采集。我使用规则组非扫描模式，每次轮询一个通道，转换完成后读取数据寄存器。

uint16_t ADC_ReadChannel(uint8_t channel) { ADC_RegularChannelConfig(ADC1, channel, 1, ADC_SampleTime_55Cycles5); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET); return ADC_GetConversionValue(ADC1); }

实际调用时，分别读取PA0和PA1的ADC值。烟雾值变量smokeAdc的范围是0~4095，我在阈值判断中规定：

• smokeAdc < 1500：正常。
• smokeAdc在1500~2500区间：预警，不触发蜂鸣器，但LCD提示“SMOKE NORMAL/HIGH”交替刷新。
• smokeAdc > 2500：火警，触发联动。

这里要提醒初学者：阈值不是死数字。你在Proteus里旋转电位器，ADC值会连续变化，完全可以自定义一个“火警触发点”。比如，我把电位器往右旋到大约2/3位置时，ADC值超过2500，系统报火警。在做实物时，这个阈值需要根据真实MQ-2传感器在洁净空气中的基准电压来重新标定，因为MQ-2的模拟输出基线会随环境温湿度漂移。更规范的做法是开机后采集一段基线，动态计算阈值增量。

温度通道同理，温度Adc > 1800时认为温度异常偏高，可以与烟雾组合判断，进一步提高火警准确率。但在仿真阶段，单独看烟雾通道已经足够演示联动过程，温度通道更多是给后续扩展留位置。

3.4 报警状态机与联动控制

系统状态机的核心思想是：正常情况下停留在“撤防”或“布防”状态，一旦传感器条件满足，立刻切换到对应报警状态；报警状态下，所有传感器继续监测，但不再重复触发同一个报警，避免状态抖动。

主循环里核心判断逻辑如下：

void System_Handler(void) { uint16_t smoke_adc = ADC_ReadChannel(ADC_Channel_0); uint8_t flame_level = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_1); uint8_t pir_level = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_2); if (g_state == SYS_ALARM_FIRE) { // 持续报警，等待人工复位 Fire_Alarm_Run(); return; } if (g_state == SYS_ALARM_INTRU) { Intrusion_Alarm_Run(); return; } // 烟雾和火焰检测在所有状态下都生效 if (smoke_adc > FIRE_THRESHOLD_H || flame_level == 0) { g_state = SYS_ALARM_FIRE; Fire_Alarm_Enter(); return; } // 入侵检测仅在布防状态下生效 if (g_state == SYS_ARMED && pir_level == 0) { g_state = SYS_ALARM_INTRU; Intrusion_Alarm_Enter(); return; } }

Fire_Alarm_Enter里做的事包括：打开蜂鸣器（PB0输出高），红色LED（PB1）以200ms间隔闪烁，继电器吸合（PB3输出高），风扇开始排烟，LCD显示“FIRE! EXTRACTOR ON”。这里用SysTick定时器做非阻塞延时，不能再用Delay_Ms死等，否则蜂鸣器的间歇鸣叫和LED闪烁会卡住主循环。

SysTick中断服务函数里维护一个毫秒计数器：

volatile uint32_t g_ticks = 0; void SysTick_Handler(void) { g_ticks++; } void Delay_Ms(uint32_t ms) { uint32_t start = g_ticks; while (g_ticks - start < ms); }

注意g_ticks用volatile修饰，并且减法方式可以避免计数器回绕问题。在报警运行函数里，通过对比当前g_ticks和上一次动作时间，决定是否翻转LED状态。

3.5 LCD显示与串口日志

LCD1602驱动代码是标准套路。4位模式下，写入一个字节需要分两次发送，先发高4位再发低4位，中间插入足够的延时。初始化时序要严格按照数据手册来：延时40ms、写0x33、写0x32、写0x28进入4位模式、开显示、清屏、光标设置。

主循环每一轮更新一次显示信息，第一行显示系统状态，第二行显示烟雾ADC值：

char line1[17]; char line2[17]; switch (g_state) { case SYS_DISARMED: sprintf(line1, "State: DISARMED "); break; case SYS_ARMED: sprintf(line1, "State: ARMED "); break; case SYS_ALARM_FIRE: sprintf(line1, "ALARM: FIRE "); break; default: sprintf(line1, "ALARM: INTRUSION"); break; } sprintf(line2, "Smoke:%04d ", smoke_adc); LCD_SetPosition(0, 0); LCD_WriteString(line1); LCD_SetPosition(0, 1); LCD_WriteString(line2);

注意字符串长度要控死在16字符以内，否则LCD1602第二行会显示错乱。我习惯在格式串后面补空格，覆盖上一次残留字符。

USART1打印函数做成类似printf的重定向，方便调试：

int fputc(int ch, FILE *f) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, (uint8_t)ch); return ch; }

然后在Keil里勾选“Use MicroLIB”，这样printf就能直接走串口输出。开机时打印一行版本信息，每次状态切换打印一次原因，例如“State: ARMED, reason: key pressed”。这在排查“为什么状态没切过去”时非常有用。

4. Proteus仿真搭建全流程

4.1 新建工程与放置元件

Proteus版本我建议8.9及以上，对STM32F103系列支持更完善。新建工程时直接选“Creative Schematic”，然后进入元件模式，点击“P”打开元件库搜索面板。

需要用到的元件清单：

这里有几个易错点。第一，LCD1602在很多Proteus版本中的显示模型叫LM016L，搜索LCD1602有时候搜不到。第二，STM32F103C8在“Pick Devices”面板中位于“Microprocessor ICs → ST ARM Processor”分类下，如果你打开的是旧版本Proteus，可能没有这个分类，建议直接升级到8.9以上。第三，电机模型用MOTOR，在旋转动画中可以看到风扇叶片转动；如果只想验证继电器通断，用LED代替电机观察更方便。

4.2 连接电路与配置仿真参数

放置元件后开始连线。STM32芯片引脚密度高，建议先用电源端子把VDD接到3.3V、VSS接地、VCAP接100nF电容（这部分在Proteus里有时可以省略，但画上更规范）。BOOT0接一个10kΩ下拉电阻到GND，保证从主Flash启动。

PA0和PA1分别接两个电位器的中间抽头，电位器两端接线到3.3V和GND。PA1、PA2、PA3、PA4接按键到GND。PB0接蜂鸣器驱动三极管的基极，PB1、PB2接LED，PB3接继电器驱动三极管基极。PC0~PC3接LCD D4~D7，PC4接RS，PC5接EN。PA9接虚拟终端的RXD。

有几个细节影响仿真成败：

• STM32模型默认内部有上拉和下拉选项，你需要在“Edit Component”里确认，或者干脆在代码中使能内部上拉。我在按键扫描中配置的是GPIO_Mode_IPU，也就是内部上拉输入，所以外部不需要再外加电阻。
• 电位器POT-HG的调节：仿真运行时，点击电位器，按键盘“+/-”或直接拖动旋钮可以改变阻值。很多新手仿真时不会调电位器，以为固定阻值导致ADC值永远不变，实际上只需要在运行状态下用鼠标操作电位器。
• 虚拟终端要设置波特率115200、8N1，和代码里的串口配置保持一致，否则打印出来是乱码。虚拟终端的属性面板在双击后打开，把Baud Rate改成115200即可。
• 如果不使用外部晶振，千万不要在代码里长时间等待HSE就绪。标准库默认的SystemInit里配置了外部晶振，直接把时钟源切换成内部HSI，并配置PLL将8MHz倍频到72MHz，或者最简单粗暴地用默认内部8MHz跑，仿真速度反而更快。

下面给出一段在仿真中稳定工作的时钟配置修改思路。如果你用标准库，在system_stm32f10x.c中找到SystemInit函数，注释掉等待HSE就绪部分，改为直接设置PLL源为HSI：

// 修改后关键片段 RCC->CR |= RCC_CR_HSION; // 打开HSI while (!(RCC->CR & RCC_CR_HSIRDY)); // 等待HSI就绪 RCC->CFGR = RCC_CFGR_PLLSRC_HSI_Div2 | RCC_CFGR_PLLMULL16; // 8MHz/2*16=64MHz RCC->CR |= RCC_CR_PLLON; while (!(RCC->CR & RCC_CR_PLLRDY)); RCC->CFGR |= RCC_CFGR_SW_PLL;

这样系统主频是64MHz而不是72MHz，但外设逻辑不受影响，仿真速度还快一点。如果你不想改系统文件，直接用HAL库在CubeMX里选HSI作为时钟源也可以。

4.3 加载固件与运行联调

Keil编译通过后，在工程目录的Objects文件夹下找到.hex文件。回到Proteus，双击STM32F103C8芯片，在“Program File”栏选择该hex文件，点击确定。点击左下角绿色三角运行仿真。

第一次联调时不要急着看整体效果，建议按以下步骤循序渐进：

1. 先验证最小系统：不加载任何传感器模块，只烧录一个点亮LED的测试程序，确认STM32模型能正常运行。
2. 验证LCD：单独测试LCD显示功能，确认字符正确、无乱码。如果LCD显示方块，优先调VO对比度电位器。
3. 验证ADC：打开虚拟终端，打印ADC原始值，旋动电位器观察数值是否在0~4095之间线性变化。
4. 验证报警联动：把烟雾电位器旋到高阈值以上，观察蜂鸣器、LED、继电器是否按要求动作。
5. 最后把所有模块合起来：完整跑一遍布防→入侵→火警→复位的流程。

联调时我发现最常用的工具组合是“虚拟终端 + LCD + LED指示灯”。虚拟终端负责显示内部逻辑走向，LCD和LED负责验证最终输出。通过这个过程，我第一次跑这套系统大概花了一个下午，把大部分问题都集中在时钟初始化、LCD驱动细节和按键消抖上。

5. 常见问题与排查技巧实录

5.1 元件找不到或模型缺失怎么办

Proteus库检索问题排在所有坑的第一位。STM32F103C8在部分旧版本Proteus中压根不存在，建议直接安装Proteus 8.9以上。即便在新版本中，你搜索“STM32F103C8”时可能只看到“STM32F103C6”或“STM32F103R6”，这两个型号在仿真中也可以烧录F103C8的代码，只是Flash大小模型不同，对本项目没有任何影响。

LCD1602搜不到就搜“LM016L”，这是Proteus自带的16字符2行LCD模型。如果连LM016L都搜不到，检查是不是“The simulator is not installed”之类的安装问题，重装Proteus并勾选“Simulation”组件。

火焰传感器、人体红外模块、MQ-2等模块即便在最新版Proteus中也没有官方模型，网上有人做过第三方库，但加载步骤繁琐且容易冲突。我的建议是放弃这些模型，用按键+电位器模拟，既稳定又省事。仿真阶段验证的是逻辑，不是传感器物理特性。

5.2 仿真不起来或程序不运行

现象一：点击运行后芯片无反应，程序没有执行。先按顺序排查：

• 芯片Program File里是否加载了hex文件？加载后文件路径不能有中文和空格。
• 电源引脚是否都连接？有的Proteus版本隐藏了VDD/VSS，需要右键芯片选择“Edit Properties”，确保电源网络正确。
• 启动配置BOOT0是否下拉到GND？BOOT0悬空可能导致芯片进入BootLoader而不是运行你的程序。
• 代码里是否卡死在HSE等待循环？如前文所述，仿真中改内部时钟源是王道。

现象二：运行后LCD全黑或全方块。检查VO引脚电位，把10kΩ电位器调节在1/3左右位置。实测很多LCD显示问题都是对比度电位器没调好。

现象三：虚拟终端没有输出。检查虚拟终端和PA9是否交叉连接（终端RX接单片机TX），波特率是否匹配，GND是否共地。还有一点，Proteus每次重新加载hex后，虚拟终端可能需要点击“Pause”再“Run”才能重新抓取串口数据。

现象四：系统运行一切正常，但蜂鸣器不响。部分Proteus版本的BUZZER模型默认工作电压是5V，如果你给蜂鸣器供电3.3V，驱动电流不够，不会发声。可以尝试把蜂鸣器电源改成5V，通过三极管控制开关。如果仍然无声，换用SOUNDER模型代替。

5.3 传感器状态不变、报警不触发

这类问题大概率出在ADC配置和电位器操作上。先确认虚拟终端打印的ADC值是否会随电位器变化，如果一直为0或一直为4095，检查PA0是否真的连到电位器中抽头，以及电位器两端电源是否正确。

如果ADC值会变但不触发报警，那就是阈值和实际值的匹配问题。你把电位器旋到头，记录最大ADC值，然后把阈值设在最大值往下一点的位置，比如最大4096，阈值设2500，这样稍微多旋一点就能触发。更科学的办法是：打开虚拟终端实时观察，缓慢旋转电位器同时观察打印值，在你想触发的位置记下数值，再写回代码作为阈值。

火焰传感器和人体红外的按键模拟电平，如果按键按下没反应，用万用表测量PA1/PA2在按键按下时是否为低电平。如果是，说明GPIO配置有问题——检查内部上拉是否使能，或者外部是否接了上拉电阻。如果GPIO配置的是开漏模式且没有外部上拉，读取电平永远是0，这一点特别容易踩。

6. 从仿真到实物的迁移要点

6.1 硬件差异：从电位器到真实传感器

仿真跑通只是第一步，真正做实物时你会发现还要面对几个现实问题。

MQ-2烟雾传感器的模拟输出不是理想的电压源，它内部是一个加热电阻加气敏电阻，上电初期需要预热，输出会缓慢漂移。你需要给MQ-2通电5分钟以上再采集基线电压，然后以基线电压为参考设置阈值。另外MQ-2工作时加热丝电流约150mA，不能用单片机GPIO直接供电，需要额外的5V电源。

火焰传感器和人体红外模块的输出电平逻辑不完全相同。有的模块输出高电平表示检测到目标，有的输出低电平表示检测到目标，做实物前必须查清楚模块说明书，然后对应修改代码里的判断条件。我吃过这个亏：买回来的火焰传感器模块是“检测到火焰输出低电平”，而我代码里先入为主写的是高电平触发，结果现场调试半天没反应。

继电器和蜂鸣器的驱动电路在仿真里可以偷懒，实物完全不能。必须严格按照三极管或MOSFET驱动方案设计，继电器线圈加续流二极管，蜂鸣器如果是无源蜂鸣器还要接RC振荡电路或用定时器输出PWM驱动。我建议从一开始就按实物标准画原理图，仿真和实物尽量用同一份电路。

6.2 代码层面的移植注意事项

仿真代码在做实物移植时，时钟初始化部分需要改回外部晶振，否则依靠内部HSI的PLL配置在实物上是也能工作的，但实时性和ADC精度不如外部晶振稳定。如果你在Proteus里用了我前面推荐的内部HSI配置，移植到实物时务必改回HSE + 8MHz晶振 + PLL到72MHz。

ADC参考电压在实物上要更在意。STM32F103的VREF+引脚如果和VDDA分开供电，必须用高精度基准源；如果直接用3.3V供电，要确保电源纹波小，否则ADC采出来的数值会在低位数上跳动。传感器输出的模拟信号如果距离很长，还要在ADC引脚加一个RC低通滤波器，截止频率大约100Hz，滤掉高频噪声。

LCD驱动代码基本可以直接复用，I/O口速度在实物上建议配置为GPIO_Speed_2MHz，太高反而可能因为PCB走线问题引入振铃。串口波特率如果只是为了调试，115200没问题；如果要接蓝牙模块或WiFi模块，经常需要9600，做一个宏定义统一管理波特率，方便切换。

6.3 系统扩展思路

这套系统设计时我刻意留了扩展余地。PA5、PA6、PA7引出来可以接一个ESP8266WiFi模块，把报警信息通过MQTT推送到手机；或者增加OLED显示替代LCD1602；再加上一个DHT11温湿度传感器，就能在本地LCD上同时显示温湿度和烟雾浓度。如果你手头有GSM模块，也可以通过串口发短信告警。

另一个扩展方向是电源管理和低功耗设计。实物安防系统一般常年运行，使用电池供电时必须设计睡眠和唤醒机制。STM32的停机模式（Stop Mode）配合外部中断唤醒，可以把静态功耗压到几十微安级别。仿真工具可以验证逻辑，但低功耗电流必须实测，这一点仿真代替不了。

如果后续想做得更工程化，还可以把RTOS引进来，用FreeRTOS管理传感器采集、按键扫描、显示刷新、报警联动这几个任务。小车跑通了裸机，再上RTOS，你会对嵌入式实时系统有更深的理解。我现在的做法，是在裸机逻辑基础上先在Proteus里验证可跑，再往FreeRTOS上迁移，这样即使出问题，也知道是系统调度问题还是外设驱动问题。

我自己在反复跑这套仿真过程中，最深的体会是：Proteus仿真真正的价值不在于“模拟得有多真”，而在于它逼着你把硬件连接和软件逻辑理清楚。很多初学者上来就埋头写代码，写到一半发现引脚接错、外设配置冲突、阈值不合理，回头改代码又得重头查电路。仿真环境里一次点击就能复位重来，试错成本极低，但收获的经验是完整的。先仿真、后实物，这套流程我已经推荐给身边好几届做课程设计的学弟学妹，真心建议你也在动手买元件之前，先用一个下午把Proteus这边跑通，再去找实物材料，你会发现后续的实物调试顺利很多。

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