STM32消防预警系统设计与Proteus仿真实战：从传感器采集到报警状态机

做实验室消防预警控制系统，主题绕不开单片机采集、报警判断和可靠性验证这几件事。我这里整理的开源版本把代码、原理图和仿真三条线一起放了出来，主控平台选了STM32F103C8T6，整体流程覆盖温湿度、烟雾浓度、火焰信号的采集，再到声光报警、串口输出和继电器动作，属于很典型但很有教学价值的STM32项目。如果你正在做嵌入式方向的项目练手、毕业设计，或者想把实验室安全监控做个低成本方案，这套东西可以直接拿过去改。

很多朋友看到“消防预警”第一反应是传感器越多越好，实际上系统能不能用，拼的是采集稳定性和报警判据。这篇文章不聊虚的，我按设计思路、原理图、代码实现、仿真复现、常见坑位、开源发布顺序讲，尽量把每一步背后的取舍说清楚，这样你拿到代码和原理图之后能自己改，而不是只会烧录。

1. 方案选型与整体设计思路

1.1 这个项目的价值在哪儿

实验室、机房、仓库这类场景，环境参数一旦异常，早发现几秒钟可能就避免了设备损失。相比商场那种完整消防主机，实验室内部更需要低成本、可定制、能联网上报的小系统。STM32F103C8T6之所以被大家反复拿来用，一是价格便宜，二是资料极多，三是外设足够覆盖大多数传感器，即便是做基于STM32的毕业设计，也远比一个裸机跑马灯更能体现完整工程能力。

我开源这个项目，核心想让大家看到三件事：

• 传感器不是挂上去就完事，电气连接和驱动时序要单独设计；
• 报警模块不能一个if打天下，状态机加滤波才靠谱；
• 先用Proteus仿真把逻辑跑通，再上实物，能省大量调试时间。

这套东西真正的应用场景不只是抄作业，把阈值、传感器型号替换成自己的现场需求，它就能变成机房温度监控、厨房燃气报警、宿舍烟雾检测的底子。项目开放性就在这里：框架比具体实现值钱。

1.2 数据链路和执行链路

整个系统的数据流并不复杂，但每个环节都有讲究。

环境参数经过传感器变成电压或电平信号，进入STM32的GPIO、ADC或者定时器输入捕获；STM32内部做滤波、阈值判断和状态迁移；状态结果驱动蜂鸣器、LED、OLED显示、继电器模块，同时通过串口把调试信息发到上位机。这里最关键的一点是，采集和响应不能互相卡死，否则传感器延时读取时报警输出会被拖慢。所以我在代码里把传感器读取做成周期任务，把报警输出放在定时器回调里，保证任何时间点出现危险信号，蜂鸣器都能立刻响应。

从工程化角度看，消防预警系统最忌讳的就是“采集到了才报警”，而是要在主循环中不断轮询关键输入，在中断中快速响应紧急事件。STM32的定时器中断频率我设成1kHz，每1ms扫描一次火焰信号和紧急按键，这种硬实时设计在后期仿真里非常容易验证。

1.3 器件选型是怎么定的

核心器件列表如下，每个的选择我都说下理由：

有人可能会问，为什么不用ESP32或者更高级的芯片？Fire alarm系统本身以可靠性优先，STM32F103在裸机环境下完全可控，不引入操作系统复杂度，也方便观测每一个外设的寄存器行为。对学习和移植来说，这是最舒服的平台。DHT11精度虽然一般，但作为消防辅助温湿度监测已经够了，真要高精度环境检测建议换SHT30，代码改I2C即可。

2. 硬件原理图设计要点

2.1 最小系统和电源部分

MCU最小系统看着简单，但看原理图时往往有一堆新人的坑。STM32F103C8T6需要8MHz外部晶振，两个20pF左右的负载电容，3.3V电源引脚全部接上100nF去耦电容。复位引脚用10kΩ上拉到3.3V，再并联一个100nF电容稳定复位。BOOT0直接通过10kΩ下拉到GND，保证从Flash启动。你喜欢用内部HSI也可以省掉晶振，但这里我希望时钟源稳定，尤其后面DHT11时序和串口波特率都依赖系统时钟，外部晶振更靠谱。

电源部分我用USB的5V输入，经过LM1117-3.3稳压到3.3V给MCU和传感器供电。注意不要混乱：DHT11数据口和OLED、FLASH、按键这些外设都在3.3V域工作，而MQ-2的加热电阻和继电器模块的线圈可能用到5V，所以原理图里至少需要5V和3.3V两个电源网络。画图时要习惯用电源符号和网络标签，而不是把导线从板子一端拉到另一端，否则电源扇出会把图面塞成一团，DRC检查也不好查。

2.2 DHT11传感器接入电路

DHT11是单总线器件，数据线空闲时被上拉到高电平，主机发送起始信号，DHT11拉低响应后开始传输40位数据。它的数据引脚内部没有强上拉，所以外部必须在数据线和VCC之间加一个4.7kΩ上拉电阻。有些模块板载了上拉电阻，但如果你自己打样板，必须预留。

原理图绘制时，容易犯的错是把GPIO直接当成主机推挽输出，又在同一根线上挂另一个I2C器件。DHT11不是标准I2C，它的时序更多是微秒级电平翻转，我在代码里会临时切IO模式，原理图设计上保证这根线只连DHT11和单片机的PA0，不共享总线。如果条件允许，在数据线上预留一个100Ω串联电阻和一个小电容，能吸收长导线带来的反射噪声。仿真里看不到这种细节，实物调试时很有用。

2.3 MQ-2烟雾传感器电路

MQ-2传感器内部是一个气敏加热电阻，随着可燃气体浓度变化，其输出电阻也会变化，常见模块会输出模拟电压A0和数字电压DO。数字输出是模块上板载比较器生成的，阈值固定，没法微调，所以我更建议把A0信号引入STM32的ADC通道，通过软件动态设置报警阈值，这样在现场校准时非常方便。

MQ-2加热部分通常要求5V供电，模拟输出信号在模块工作电压5V时最高接近5V，超过STM32引脚耐压范围。实际上模块厂商多做了一个电位器分压，加上LM393比较器，A0输出一般在0-5V之间浮动。稳妥起见，原理图上A0经过电阻分压网络缩到3.3V以内再进PA1。常用的做法是10kΩ串联、10kΩ下拉，在ADC引脚并联一个100nF电容做低通滤波。这样即使用5V供电模块，采样电压也不会超过3.3V。如果你买的模块本身已经是3.3V供电版本，直接连接即可。

2.4 蜂鸣器、继电器和按键电路

报警输出这一类大功率器件，千万不能直接把GPIO接到蜂鸣器和继电器线圈。STM32引脚是弱驱动，最多输出几毫安到十几毫安，推有源蜂鸣器偶尔还行，但继电器线圈的驱动电流都几十毫安，直接接会损坏GPIO。

我的原理图里蜂鸣器使用NPN三极管S8050驱动，基极通过1kΩ限流电阻接PA12，发射极接地，集电极接蜂鸣器负极，蜂鸣器正极接5V。继电器则使用NPN或ULN2003驱动，线圈两端必须并联一个反向续流二极管1N4007，否则断电瞬间反向电动势容易打坏三极管。这一段我特别想强调，消防设备的安全性和稳定性优先，驱动电路留足够余量，上电自检时继电器多吸合几次也是测试重点。

按键采用独立上拉输入模式，按下引脚接地，软件里用HAL库读取GPIO电平做去抖。报警解除按键可以直接接到外部中断输入，也可以在扫描循环里轮询。我推荐外部中断方式，因为这属于“紧急操作”，中断响应更及时，且不受DHT11读取阻塞影响。

2.5 嘉立创EDA画原理图的实操习惯

用嘉立创EDA画这套图时，有几个习惯值得从一开始就建立起来。一是所有网络都需要有意义的名字，比如5V、3V3、SMOKE_ADC、FIRE_IN、BEEP_CTL，不要只靠连线判断。二是放置器件后马上写位号，不要等画完再统一标，不然很容易漏。三是熟练使用“电气规则检查”，DRC会在你删除电源引脚、悬空输入、短路网络时报错，及时处理。

嘉立创EDA里DHT11的符号有多个版本，注意选带VCC、DATA、GND、NC四脚的标准封装，自建符号时把电源引脚勾选为“电源”类型会更方便统一布线。原理图画好之后，我习惯导出一份PDF示意和一份BOM表，BOM表里的封装一定要与实际元件库对应，这样打样后焊接效率会高很多。

3. 代码逻辑与核心模块实现

3.1 工程初始化和传感器驱动写法

代码工程基于STM32CubeMX生成初始化，时钟配置为外部8MHz晶振倍频到72MHz，ADC1、USART1、I2C1、定时器和GPIO外设在Cubemx里勾选后自动生成。有人对Cubemx生成的一堆代码有抵触，但工程实践里生成代码是常态，你要改的是业务逻辑层，而不是寄存器初始化，效率高很多。

DHT11读取是这套代码里最容易让人翻车的点。它的通信协议是单总线，总线上只有一根数据线，主机要把GPIO模式从输出切到输入，并且时序精确到微秒级。先给一个基本代码片段：

#define DHT11_PORT GPIOA #define DHT11_PIN GPIO_PIN_0 void DHT11_Start(void) { GPIO_InitTypeDef io; __HAL_RCC_GPIOA_CLK_ENABLE(); io.Pin = DHT11_PIN; io.Mode = GPIO_MODE_OUTPUT_PP; io.Speed = GPIO_SPEED_HIGH; HAL_GPIO_Init(DHT11_PORT, &io); HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_RESET); delay_ms(20); HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_SET); delay_us(40); io.Mode = GPIO_MODE_INPUT; io.Pull = GPIO_NOPULL; HAL_GPIO_Init(DHT11_PORT, &io); } uint8_t DHT11_ReadBit(void) { uint32_t cnt = 0; while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_RESET); while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET && cnt++ < 100); if (cnt < 50) { return 0; } while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET); return 1; }

为什么ReadBit要数高电平持续长度？这正是STM32测频法在单总线时序里的变体，和超声波测距里测回波高电平宽度的思路一样。DHT11用高电平持续26-28微秒表示逻辑0，70微秒左右表示逻辑1，测量高电平宽度比盲delay更可靠。实际的OTDR，如果你手头有示波器，会看到心率波动，单靠delay_us很容易因为中断打断读出错误数据，计时方式容错性更强。

读取完整40位并校验数据格式也很重要。40位分别是湿度整数、湿度小数、温度整数、温度小数、校验和，如果前四个字节累加和等于最后一个字节，才认为这次采集有效。要注意DHT11的模块质量差异极大，有些廉价模块在初次上电前几百毫秒响应不稳定，代码里要连续读取失败多次后保留上一次有效值，不能把乱码直接送进显示。

3.2 报警状态机与消抖滤波

报警逻辑如果只是“温度高于50度就报警”，系统会敏感到没法用。实验室里的电炉、消毒设备都可能瞬时产生高温或异常烟雾，一两个误报就会让人对系统失去信任。

我的处理方法是设计一个三态报警状态机：正常、预警、报警。预警状态是连续两次采样超阈值才进入，报警状态是连续三次超阈值并且持续时间超过500ms才触发。温度、烟雾、火焰三种参数分开计数，互相取或，但每种参数都要有自己的触发次数。代码里可以这样实现：

typedef enum { STATE_NORMAL, STATE_WARN, STATE_ALARM } AlarmState; AlarmState smoke_state = STATE_NORMAL; uint8_t smoke_over_count = 0; if (adc_value > SMOKE_HIGH_THRESHOLD) { smoke_over_count++; if (smoke_over_count >= 3) smoke_state = STATE_ALARM; else smoke_state = STATE_WARN; } else { smoke_over_count = 0; smoke_state = STATE_NORMAL; }

这个“连续N次确认”的方案虽然简单，但在消防这类场景足够务实：现场烟雾浓度会波动，不会像软件开关一样瞬间突变。如果你还想更平滑，可以对ADC值做滑动平均滤波，保留最近10次采样，每次算平均值和当前值差，差大于阈值才认为真的变化了。我建议在真实硬件上做一次土味标定：用打火机气体短暂触碰MQ-2，观察串口打印的原始ADC值，然后按照“正常值的三倍”设阈值，这个比例比拍脑袋定一个固定数值可靠。

火焰传感器的处理比较特殊，它反应极快，一旦检测到红外火焰信号，不能走“连续三次确认”的慢路径，要立即报警。实践中的处理方式是把火焰信号接到外部中断，中断服务函数里置一个紧急报警标志，主循环检测到这个标志后立刻拉响蜂鸣器并点亮红灯。这个设计让我在Proteus仿真时看得很清楚：普通烟雾报警有几百毫秒延迟，但火焰中断几乎是立竿见影的。

3.3 OLED显示和串口打印

系统里有一块0.96寸OLED，走I2C接口，只占用PB6和PB7两个引脚。因为分辨率和刷新能力有限，我不建议每次刷新全屏，更合理的做法是把画面分成固定区域，温度湿度区域、烟雾状态区域、报警状态区域，每秒刷新一次。OLED驱动的字体库会占不少Flash，选一个3232的小图标和1616英文字体就够用了，没必要把整个中文字库塞进去，否则64KB Flash会吃紧。

串口调试是这套系统里最好用的工具。初始化USART1，波特率115200，8N1，PA9接TX，PA10接RX。我把HAL库的printf重定向到串口，每两秒打印一帧结构化数据，比如：

[SYSTEM] Temp=26.1C Hum=45% SmokeAdc=198 Fire=OK State=NORMAL

很多人在仿真阶段喜欢看虚拟终端，但一搬到实物就看不到内容，原因往往是串口打印里包含了浮点格式的%f，而Keil MDK默认的微库没办法正确输出浮点，需要在Keil的配置里勾选“Use MicroLIB”或者自己写整数定点格式。把浮点乘10转成整数再打印，是我的习惯做法：temp_x10 = (uint16_t)(temp * 10);，用整数格式打印，既稳定又方便上位机解析。

3.4 按键交互和非阻塞延时设计

主循环里不能写一个大delay_ms(5000)之类的阻塞延时，否则报警响应会完全失灵。STM32项目里，除非你在初始化过程中需要等待上电稳定，其他地方尽量使用非阻塞式设计。按键消抖用定时器扫描的方式，每10ms读一次按键状态，连续两次读到不同状态才认为有效。报警解除按键送入外部中断，中断里设置标志位，由主循环决定什么时候关掉蜂鸣器和继电器，而不是中断里直接操作GPIO，这样可以避免函数重入问题。

有人会把所有事情都堆在主循环里，DHT11阻塞230ms读一次，OLED刷新又要100ms，串口打印再来几十毫秒，整个循环周期可能超过400ms。这个循环周期对消防预警来说太慢了。我的代码结构里，主循环拆成三个任务：第一优先级检查紧急标志，第二优先级更新传感器数据和报警状态，第三优先级刷新显示和串口。任务之间通过共享变量和标志位传递数据，核心思想是紧急路径永远不被普通路径卡死。

4. 用Proteus把整套系统仿真跑起来

4.1 为什么要先在Proteus里做仿真

这次开源包里的仿真文件用的是Proteus 8.x工程。仿真不是摆设，它能让你在没有实物元件、没有示波器的情况下，提前验证STM32代码逻辑是否合理。尤其是DHT11这种带严格时序的传感器，网上资料容易抄错，在仿真里跑不过去时，多半是代码问题；实物跑不过去时，可能是硬件问题。先把代码问题在仿真里滤掉，后面焊板子的成功率会明显更高。

另外，仿真文件对跨平台协作也有意义。导师或同事不一定有完整硬件环境，只要装了Proteus就能打开工程看整体电路、加载HEX文件，一键看到运行效果。所以我认为，一个开源项目只要包含原理图，就应该尽量附带对应的仿真工程，这是嵌入式开源项目管理里很加分的一项。

4.2 仿真搭建步骤

如果你想自己搭一遍仿真，过程大致是这样的：先在Proteus里新建一个工程，从元件库搜索STM32F103R6或STM32F103C8，放置到原理图区。接着放置DHT11模型、OLED模型、两个LED、电阻、按键、一个虚拟终端和一对电源端子。DHT11的模型在部分Proteus版本中可能不在默认元件库，如果搜不到，需要从外部导入一个第三方模型库文件，或者用DS18B20这类类似单总线传感器替换验证“读传感器”流程，但最终代码要回到DHT11。

连接电路时注意DHT11的信号线同样需要上拉电阻。打开MCU属性，指定Program File为你用Keil编译生成的HEX文件，并把Clock Frequency设置为8MHz，这和代码里的外部晶振参数保持一致。运行仿真后，虚拟终端里如果能看到串口打印的环境数据，逻辑就基本通了。OLED模型在Proteus里不一定会显示中文，只显示英文是正常的，不影响判断程序流程是否正常。

4.3 仿真中的DHT11时序问题

很多同学第一次在Proteus里跑单总线传感器，发现数据全是FF，或者在“data busy”期间卡死。这是因为仿真模型的微秒级行为和你代码里的延时并不完全等价，主频配置不对时更是差之毫厘谬以千里。

比较有效的调试方式是在代码里加一个调试脚，每次DHT11时序变化时翻转一个GPIO，然后在Proteus通过虚拟示波器抓这个脚的电平波形。因为没有示波器时，逻辑分析仪也是一种办法。把DHT11的DATA引脚和调试引脚一起接到示波器通道，一眼就能看出起始信号的反转是否完整、40位数据波形是不是基本平整。仿真中暴露出来的问题，90%出在超时判断和GPIO方向切换这两个地方，不一定是硬件连接错误。

还要提醒一句：仿真环境对传感器的响应速度和时序都是理想化模拟，它只能证明你“程序逻辑”是通的，不能替代真机上MQ-2的飘移校准。仿真里你把烟雾阈值设成150能触发，实物上MQ-2的ADC值可能稳定在200以上，所以拿到硬件后必须重新标定阈值。

4.4 仿真看门狗和边界情况测试

推荐大家在仿真阶段专门做几组边界测试，而不只是让系统正常跑。第一组是模拟传感器断线，比如把DHT11数据线断开，看系统会不会死循环卡住；第二组是模拟烟雾超限，调整烟雾传感器的模拟输入电压，让它从正常值缓慢升上阈值，确认报警状态机进入警报；第三组是同时给火焰信号和烟雾信号，确认紧急通道优先响应。

这些边界测试在开源项目里尤其重要，因为看代码的人最担心的就是这个系统在异常工况下会不会完全瘫痪。我的代码里给DHT11读取函数加了重试上限，如果连续读取6次都失败，系统会进入传感器故障状态，蜂鸣器按特定节奏响三短一长，用来区分传感器故障和真实火灾，这个细节实践性很强。

5. 常见问题与排错实录

5.1 STM32无法识别USB设备

实物调试阶段最扫兴的问题，就是用ST-LINK连接开发板时电脑提示无法识别USB设备。出现这个现象，先别急着怀疑硬件坏了。大多数ST-LINK无法识别的根源是驱动没装好或者接触不良。STM32开发板上常见的ST-LINK/V2使用的是专用驱动，在Win10/Win11上偶尔会掉到蓝牙或通用USB设备类别里。处理办法是插上ST-LINK，进入设备管理器，右键更新驱动，手动指向STM32 ST-LINK Utility安装目录下的驱动文件。

还有一种情况是板子由外部额外供电，但ST-LINK的SWD接口没有先接地线。ST-LINK与目标板之间至少需要SWDIO、SWCLK、GND这三条线，有些偷懒只接两根线，系统识别IDCODE不稳定，看起来就是不识别。如果USB插上后设备管理器有感叹号，卸载设备后重插，一般能恢复。另外，如果你用串口ISP烧录而不是ST-LINK，烧录前要把BOOT0拉高，烧完再拉回来，否则复位后进不了用户程序。

5.2 Keil MDK环境兼容问题

Keil MDK安装时最容易被坑的是版本路径和包管理器。可能有人的电脑之前装了Keil C51，后装MDK后两个环境混在一起，导致工程打开后找不到器件型号，或者编译时报找不到头文件。这个问题的本质是C51和MDK是两套不同的工具链，放在同一个目录会造成组件混乱。建议分开安装到不同目录，或者用不同的IDE版本工具链管理。新建STM32工程时，一定要在Pack Installer里安装对应的STM32F1系列Device Pack，否则连器件型号都选不出来。

还有一种很典型的绿色安装问题：打开Keil或STM32CubeProgrammer提示“由于找不到msvcp140.dll，无法继续执行代码”。这不是项目工程的问题，而是系统缺少Visual C++ 2015-2022运行库。STM32CubeMX、Keil、STM32CubeProgrammer很多基于Qt工具链，都需要这个运行库。下载对应版本安装后重启，这个问题一般马上消失。如果你用的是绿色版Keil，尤其容易在别人电脑上遇到这种缺库问题，我会在开源仓库的README里明确写上这一步。

5.3 DHT11读不到数据的实战排查

DHT11读不到数据，往往不是一种原因。我的排查路径是这样的：

• 先确认GPIO方向切换有没有生效，很多代码里用了开漏模式，但没有及时打开外部上拉，导致引脚浮空，数据一直是0xFF；
• 检查数据线电压，正常情况下总线上空闲高电平是3.3V，如果示波器测量只有零点几伏，大概率是上拉电阻缺失或板载模块本身有问题；
• 检查时序里有没有被中断打断，DHT11要求微秒级精度，如果系统开启了一堆定时器中断且优先级设置不当，读取过程中会夹进中断，导致位宽错乱；
• 确认DHT11供电不是稳压器刚启动的不稳定阶段，传感器上电后需要至少1秒稳定，如果主程序上电立即读取，成功率很低。

调试时最有效的办法是把40位原始数据通过串口打出来，而不是只打印最终温湿度。当你能看到checksum error或者zero byte时，至少说明时序通道是通的，问题只在校验或者引脚模式。加一个测频计数也可以辅助分析，比如在两次读位之间用定时器计数，统计高电平持续了多长时间，串口打印后对照标准的26-70微秒数据，这比反复猜测可靠得多。

5.4 仿真中的配置细节坑

Proteus仿真跑不起来或者波形不对，大部分是配置细节疏忽。第一，MCU属性里的Crystal Frequency要填实际值，默认1MHz会让你代码里的延时完全不在正常量级。第二，要确认工程没有放在带中文或空格的路径下，老版本Proteus对路径中文支持不好。第三，虚拟终端的波特率设置要与代码一致，很多工程师在串口助手看到乱码第一反应是代码问题，结果只是虚拟终端波特率错了。

还有一个常见问题是仿真里放置了多个LED，但有些LED接地方式不对。Proteus里LED的属性包含正向导通压降，如果直接接3.3V且没有限流电阻，仿真会报警甚至不亮。你说“系统能跑但灯不亮”，先看LED是不是反了。STM32 GPIO默认推挽输出，驱动LED时电源正极接MCU引脚、负极经过电阻接地是没什么问题的，但那种嵌在模块原理图里的LED低电平点亮方式，在仿真里很容易忘记引脚状态。

5.5 传感器误报警怎么压下来

报警系统的核心指标是“该报的时候一定要报，不该报的时候别乱报”。误报警通常有几个来源：MQ-2在刚上电预热阶段会有一个短暂高输出，如果立即参与判断，基本都会误报一次；继电器吸合瞬间产生的电磁干扰也可能让ADC抖动；实验室通风橱抽风时烟雾浓度大幅波动，连续几次超阈值也不一定代表火灾。

我的建议是代码里加两个机制：预热屏蔽和第二阈值迟滞。上电前30秒内不参与烟雾报警；一旦进入报警后，要让数值低于阈值的80%才解除报警，而不是下降一丁点就恢复，这样可以避免蜂鸣器在阈值附近反复开关。把这两个机制写进状态机里，实际测试时误报数量会明显下降。这些也是我在代码注释里写得最详细的部分，因为它们在现象上看不见，但直接影响用户信任度。

6. 开源发布方式与仓库结构建议

6.1 仓库里需要放哪些文件

既然标题带了“开源”，代码只是仓库的一半，原理图和仿真文件同样重要。我建议的仓库结构是这样的：

stm32-fire-alarm/ ├─ firmware/ │ ├─ Core/ │ ├─ Drivers/ │ ├─ MDK-ARM/ │ └─ README.md ├─ hardware/ │ ├─ schematics_v1.0/ │ ├─ bom/ │ └─ 原理图说明.md ├─ simulation/ │ └─ proteus/ ├─ docs/ │ ├─ 接线说明.md │ ├─ 校准说明.md │ └─ 常见问题.md └─ README.md

firmware目录放完整的Keil工程，不要只丢一个.hex文件，因为别人要改功能就必须有源码和库文件。Hardware目录放原理图源文件。因为我用嘉立创EDA画图，会导出一份PDF和一份工程源文件，PDF方便直接看连线，BOM表格标好每个器件的型号、数量、封装。Simulation目录放Proteus工程文件，尽量附带使用说明，告诉别人要用哪个版本打开，以及如何加载hex。

6.2 README必须写清楚的事

README不是摆设，它是开源项目的第一道门槛。我见过太多好项目因为没有清晰的README，别人克隆下来根本跑不起来。README里至少要把环境版本写完整：Keil MDK版本、STM32CubeMX版本、HAL库版本、Proteus版本、STM32F1Pack版本。不要只写“使用Keil打开”，版本不匹配时启动会直接卡住或者编译报错。

接线表必须和原理图完全对应。我画一个简单的接线表就可以避免大部分新手插错线：

另一个很容易被忽略的是烧录方式。README里写明三行命令或操作步骤：安装ST-LINK驱动，配置Keil Debug选项为ST-Link，然后烧录，任何人按条执行基本不会错。如果你用的是串口ISP，请额外标注BOOT0操作。开源项目想要有人用、有人反馈，降低复现门槛比代码本身更重要。

6.3 开源项目的维护心得

把开源项目放出来，后续要持续维护的不是功能新增，而是让运行说明和实际代码不脱节。每次改动代码，至少要同步更新README和仿真工程，否则过两个月你自己再看都记不清当时做了哪些调整。我习惯在每次提交里带上“测试记录”，比如什么环境下验证通过、测量到的ADC基值范围是多少。这样其他人在自己硬件上跑，如果数值出入很大，他能更快判断是硬件电源问题还是标定差异。

有朋友问这个项目后面还能怎么扩展，方向其实很多。温度传感器换SHT30，通信加ESP8266走局域网通知，或者把串口改成485总线接入宿舍管理平台。这些扩展点我和代码里的模块划分都预留了位置。控制逻辑和硬件耦合不强，大可以沿着自己的实验室环境继续改。

最后说点个人体会。这套系统我从原理图到代码到仿真，前后迭代了几轮，最大的收获不是逻辑怎么顺畅，而是“预警系统的价值不在报警那一瞬间，而在不误报、不误动的基础上，必要时刻一定报”。不要小看状态机加连续确认这种朴素的方案，它在嵌入式系统里永远比华而不实的花活可靠。动手焊板之前先花半小时把仿真和代码调顺，后面能少走很多弯路。