1. 实验室消防预警这个需求，究竟难在哪：系统方案与需求拆解
很久以前我在实验室等一批样品烘干，结果忘了关加热台，回来的时候一股焦糊味已经飘到楼道。那次之后我一直在想：能不能用几十块钱的成本，做一套不需要云平台、断电也能工作、源码完全看得懂的消防预警装置。于是有了这个开源项目——实验室消防预警控制系统。它基于STM32F103C8T6，把烟雾、火焰、温湿度三个维度的传感器数据汇总到一个可维护的状态机里，本地直接给出声光报警并联动排烟风机；配套的代码、原理图和仿真全套放出，想复现的人不需要多深的嵌入式基础。
1.1 实验室火灾的几个容易被忽略的信号特征
实验室火灾和住宅火灾有个明显区别：大多不是猛火起燃，而是设备长时间通电、线路过载、加热装置遗忘造成的高温阴燃。阴燃阶段烟雾产生得最早，这时候温度还没有明显上升，明火也还没出来。也就是说，每一类传感器能覆盖的时段完全不同。
- 烟雾传感器：对早期阴燃最敏感，是预警系统的第一道防线。
- 温度传感器：响应慢，但一旦整片区域温度突破阈值，基本可以确认事故已经升级。
- 火焰传感器：对突然出现的明火响应快，能弥补烟雾传播慢的问题。
我一开始也想过只做一个烟雾报警器，后来发现实验室有人做焊接测试、酒精灯操作，这些场景偶尔会产生短时烟雾，单纯看烟雾浓度很容易误报。把温度、火焰和烟雾三个维度放在一起做交叉判断，才算是一个真正能用的消防预警系统。
1.2 从功能需求到系统模块：预警控制到底要管哪些事
这套系统的功能需求拆开看其实不复杂，但每一项背后都有隐藏问题：
- 实时监测烟雾浓度、环境温度、火焰信号，采集周期不能太慢，否则失去预警意义。
- 多级声光报警，不能一报警就拉响最高级别，否则实验室日常操作会被频繁打断。
- 联动排烟风机，报警后自动开启，降低可燃气体积聚风险。
- OLED显示当前数据和报警状态，方便现场人员判断。
- 按键交互，支持测试、静音和报警复位。
- 串口输出原始数据，给调试和阈值调参留一个口子。
对应的系统模块就是：传感器采集节点、主控决策单元、声光输出模块、风机联动模块、人机交互模块。主控决策单元是整个系统的核心，我在设计时把报警逻辑做成独立模块，而不是在main函数里堆if/else。后面软件章节会专门说这个。
1.3 主控选型：STM32F103C8T6为什么是这个项目的甜点位
市面上做这类小系统的主控很多，51、Arduino、ESP32都能干，但STM32F103C8T6有几个非常贴合本项目的点。
第一是ADC资源。系统要同时采集烟雾传感器模拟量、火焰传感器电平、温度传感器数据，F103C8T6的ADC有16个通道，留给扩展余量充足。第二是外设丰富，I2C可以接OLED，USART可以做调试和后续的RS485/WiFi扩展，定时器可以输出蜂鸣器需要的PWM信号。第三是成本，单个芯片几块钱，加上最小系统板也不过十几块，做成开源项目后别人复现的门槛很低。
我还专门评估过资源占用：程序逻辑完整实现后Flash占用大约18KB，RAM占用大概在8KB左右，C8T6的64KB Flash和20KB RAM已经留出了二次开发的余量。如果想把远程报警加进去，空余的串口、定时器和Flash空间正好可以塞下一个ESP8266或ESP32模块。
2. 原理图设计：传感器选型、驱动电路和电源规划的几个关键决策
原理图是整个项目的“地基”，这块出问题，软件写得再好都是白搭。我在画图时踩过不少坑，这里挑最关键的几个决策讲清楚，尤其是一般教科书里不会写透的电源和电平匹配问题。
2.1 传感器选型与接口电路：烟气、火焰、温湿度各管一段
传感器选型遵循的原则是：不追高精度，只追“够用、稳定、便宜、容易替换”。
| 传感器 | 检测对象 | 输出形式 | 关键参数 | 选型理由 |
|---|---|---|---|---|
| MQ-2 | 烟雾/可燃气体 | 模拟电压0-5V | 检测范围300-10000ppm | 对阴燃烟雾敏感，模块化设计，带DO/AO双输出 |
| 火焰传感器 | 红外火焰 | 数字电平/模拟 | 检测波长760-1100nm | 响应毫秒级，弥补烟雾扩散慢的问题 |
| DHT11 | 温湿度 | 单总线数字 | 温度精度±2℃，湿度±5%RH | 做温升辅助判断，成本和接线最低 |
MQ-2值得多说一句。它是半导体气敏传感器，内部有加热丝，上电后需要一段时间预热，输出才会稳定。它的AO引脚在5V供电下，输出范围是0-5V，而STM32的ADC输入范围是0-3.3V，这中间必须做电平匹配。我在原理图上加了两个10K电阻串联分压，把AO输出砍一半再进PA0引脚，并在ADC引脚对地加了一个100nF电容，滤掉传感器本身的高频噪声。DHT11是单总线协议，只需要一个上拉电阻，我选了4.7K。火焰传感器模块一般用比较器输出数字信号，直接接普通GPIO即可。
2.2 电源树与电平匹配：大部分原理图问题的根源在供电
很多初学者画的原理图看着功能齐全，焊完一上电要么传感器读数乱跳，要么继电器一动作单片机就复位，问题十有八九出在电源规划上。
这套系统的电源树分三层：
- 5V主电源：来自USB口或外部5V开关电源，给STM32最小系统板供电，同时给MQ-2、火焰传感器模块供电。
- 3.3V逻辑电源：由最小系统板上的AMS1117从5V降压得到，给STM32、OLED、DHT11和逻辑电路供电。
- 风机电源：排烟风机单独走12V或220V，通过继电器控制，和控制板在物理上保持隔离。
地线处理是最容易忽视的。继电器吸合瞬间电流变化很大，如果功率地线和传感器地线共用一段细走线，会在地线上产生不小的压差，直接体现在ADC采集值乱跳上。我画板时把模拟地、数字地、功率地分开走，最后在电源输入端一点汇合，传感器地线也单独引回主控的GND引脚，而不是就近随便接。
另外，MCU的VDDA和VSSA是模拟部分专用电源，务必加一个1uF和一个100nF电容，很多STM32 ADC精度问题都是这里偷懒导致的。每个传感器模块的电源引脚附近也并一个10uF钽电容加100nF陶瓷电容，用来吸收模块自身工作时产生的纹波。
2.3 执行机构驱动：蜂鸣器、继电器和排风机的正确接法
执行机构不能直接挂在GPIO上，这是我在原理图里重点标注过的部分。
蜂鸣器分有源和无源两种。有源蜂鸣器内部自带振荡源，给高电平就响，驱动简单，但声音单一；无源蜂鸣器要外部输入PWM信号才能发声，好处是可以通过改变PWM占空比和频率，实现“预警低频滴声”和“报警高频急促声”的区别。我选的是无源蜂鸣器，由STM32定时器输出2kHz PWM驱动，通过一个NPN三极管做电流放大，基极串联1K电阻限流，蜂鸣器两端反向并联一个续流二极管。这里二极管方向千万不能接反，否则关断瞬间的感性电动势会击穿三极管。
继电器驱动也类似，小信号GPIO经过三极管或ULN2003驱动继电器线圈，线圈两端必须并联1N4007续流二极管。我实际项目中用过继电器模块和裸继电器两种方式，裸继电器更节省空间，但线圈驱动电路必须自己做；用模块则自带上拉电阻和光耦，接线方便，缺点是体积大。排烟风机接在继电器常开触点上，这样报警才吸合，正常情况下风机不转。
2.4 画原理图与开源发布的工具选择
原理图我用嘉立创EDA绘制，不是因为它功能最强，而是因为生态最省心。DHT11这类常用器件的封装库里面直接就有，MQ-2模块也有现成的器件，关键是导出BOM、生成Gerber、绘制PCB非常顺滑。浏览器版的工程文件还能直接分享链接出去，别人拿到链接就能完整查看和克隆，非常适合开源场景。
开源发布时，我除了放出可编辑的工程文件，还额外导出了PDF版原理图和BOM表。这样即使有人不想安装EDA工具，也能直接看PDF核对引脚，拿着BOM表去采购元件。PCB部分，我建议在文档里给出生产文件，这样有需要的朋友可以直接投板，不用自己重新布局一遍。
3. 软件实现：分层架构、滤波算法与报警状态机的完整思路
软件是这个项目的灵魂。很多同类项目把代码全塞进main.c，逻辑多起来之后根本没法维护。我的做法是分层组织，每个模块只干一件事，并且把最关键的报警判定交给状态机处理。
3.1 工程目录与模块划分：别把代码全塞进main.c
工程目录如下，这个结构可以直接抄：
Firmware/ ├── MDK-ARM/ ├── Core/ │ ├── main.c │ ├── stm32f1xx_it.c │ └── system_stm32f1xx.c ├── Drivers/ │ ├── BSP/ │ │ ├── bsp_adc.c │ │ ├── bsp_tim_pwm.c │ │ ├── bsp_i2c_oled.c │ │ └── bsp_usart.c ├── App/ │ ├── app_sensor.c │ ├── app_alarm.c │ ├── app_display.c │ └── app_debug.c └── Sensors/ ├── dht11.c └── smoke_sensor.c用表格说明每个模块的职责，编程时能避免模块间互相污染：
| 模块 | 职责 | 对外接口 |
|---|---|---|
| bsp_adc.c | ADC初始化、采集、DMA搬运 | adc_read_channel() |
| bsp_tim_pwm.c | 蜂鸣器PWM输出及频率切换 | buzzer_set_mode() |
| bsp_i2c_oled.c | SSD1306驱动、字符串显示 | oled_show_all() |
| bsp_usart.c | 串口初始化、printf重定向 | printf() |
| app_sensor.c | 传感器数据滤波、浓度计算 | get_smoke_percent() |
| app_alarm.c | 状态机、报警判定、联动输出 | alarm_task() |
| app_display.c | 屏幕内容刷新逻辑 | display_task() |
主循环里不再出现任何业务判断，只做任务调度。我采用简单的时间片轮转，每个任务固定周期执行：200ms读一次传感器并进入滤波，200ms跑一次报警状态机，500ms刷新一次OLED，100ms打印一轮串口调试数据。
3.2 ADC采集与软件滤波：从跳动的裸数据到稳定浓度值
MQ-2输出的模拟信号即使加了硬件滤波电容，采样值依然会上下跳。我实测过，同一个浓度下ADC原始值波动幅度能达到几十个LSB，直接拿去做阈值判断肯定误报。
解决思路是软件再叠一层滤波。我采用的是“中位值平均滤波”，也叫防脉冲干扰平均滤波：连续采10个值，去掉最大、最小各两个，剩下6个求平均。这样既滤掉了随机脉冲干扰，又不会像单纯滑动平均那样把真实变化拉得过于平滑。
#define ADC_SAMPLE_COUNT 10 uint16_t adc_filtered_sample(void) { uint16_t temp[ADC_SAMPLE_COUNT] = {0}; uint16_t sum = 0; uint8_t i = 0, j = 0; /* 连续采集10次 */ for (i = 0; i < ADC_SAMPLE_COUNT; i++) { temp[i] = adc_read_once(ADC_CHANNEL_SMOKE); } /* 冒泡排序，样本少，不用追求效率 */ for (i = 0; i < ADC_SAMPLE_COUNT - 1; i++) { for (j = i + 1; j < ADC_SAMPLE_COUNT; j++) { if (temp[i] > temp[j]) { uint16_t t = temp[i]; temp[i] = temp[j]; temp[j] = t; } } } /* 去掉两个最大值、两个最小值，剩下6个求平均 */ for (i = 2; i < ADC_SAMPLE_COUNT - 2; i++) { sum += temp[i]; } return sum / (ADC_SAMPLE_COUNT - 4); }浓度换算不要直接拿电压绝对值和固定阈值比，因为每个MQ-2模块的零漂都不一样。我提供了一个校准函数，上电后先采集200次空气环境下的ADC基值，然后存储起来参与计算，浓度百分比 = (当前值 - 基值) / (满量程值 - 基值)，这样在室内不同环境下都能自动适应当前基线。
3.3 多级报警状态机：用状态表替代一长串if/else
报警逻辑看起来简单，实际写的时候很容易写成十几层嵌套的if/else，调试起来痛苦不堪。我的做法是定义三个状态，把“从哪个状态来、满足什么条件、执行什么动作”完全表格化：
| 当前状态 | 跳转条件 | 下一状态 | 进入动作 |
|---|---|---|---|
| 正常 | 烟雾浓度达到预警值且连续5次确认 | 预警 | 蜂鸣器低频间歇响，OLED显示预警 |
| 预警 | 烟雾浓度超过报警值，或火焰触发，或温度超限 | 报警 | 蜂鸣器高频连续响，继电器吸合，LED快闪 |
| 预警 | 烟雾浓度回落到正常范围，且保持30秒 | 正常 | 蜂鸣器停，LED灭 |
| 报警 | 人工按下复位键 | 正常 | 蜂鸣器停，继电器断开，恢复监测 |
状态机的价值在于：每个状态的“进入动作”只执行一次，不会像if/else那样在当前条件满足时反复执行蜂鸣器鸣叫、继电器抖动。我用一个枚举变量管理状态，主循环直接调用：
typedef enum { ST_NORMAL, ST_WARNING, ST_ALARM } alarm_state_t; static alarm_state_t g_alarm_state = ST_NORMAL; static uint8_t g_normal_to_warn_count = 0; static uint8_t g_warn_to_alarm_count = 0; void alarm_task(void) { uint16_t smoke = get_smoke_percent(); uint8_t flame = get_flame_digital(); switch (g_alarm_state) { case ST_NORMAL: if (smoke >= SMOKE_WARN_PERCENT) { if (++g_normal_to_warn_count >= 5) { g_normal_to_warn_count = 0; set_state(ST_WARNING); } } else { g_normal_to_warn_count = 0; } break; case ST_WARNING: if ((smoke >= SMOKE_ALARM_PERCENT) || flame || (temp_c >= TEMP_ALARM_C)) { if (++g_warn_to_alarm_count >= 3) { g_warn_to_alarm_count = 0; set_state(ST_ALARM); } } else if (smoke < SMOKE_WARN_PERCENT) { g_warn_to_alarm_count = 0; set_state(ST_NORMAL); } break; case ST_ALARM: /* 报警属于锁存状态，只有外部按键才能复位 */ break; } }连续计数的设计是重点。强制要求“连续5次确认”才跳转，能过滤掉绝大多数偶发波动；从预警升到报警又要求连续3次确认，避免因为瞬间烟雾波动直接拉响最高级警报。报警状态我设计成锁存式，因为真发生火灾时，环境条件可能一会儿超标一会儿回落，自动复位会让维护人员误以为隐患已经解除。人工确认恢复，反过来也减少了无人值守期间的重复报警。
3.4 显示与交互输出：OLED、蜂鸣器、串口各自承担什么
OLED只显示三个核心信息：当前状态、烟雾浓度、温度。SSD1306驱动代码网上很多，我做了两层封装，底层只负责写显存，上层app_display.c负责拼字符串。屏幕刷新周期设置在500ms，太快没有意义，反而会占用I2C带宽。
蜂鸣器声音模式必须和状态严格对应。预警状态使用1Hz低频滴声，报警状态切换到深响，我用定时器通道直接改PWM比较值实现。静音键按下后，报警蜂鸣器停止，但状态灯继续闪烁，这样既不打搅人员操作，也不会让报警被完全忽略。
串口调试是排查问题最重要的工具。我在初始化时用宏开关控制printf重定向，需要时打开，发布时关闭。调试阶段每一轮状态机跳变都会打印带时间戳的日志，例如：
[1205ms] smoke=32.4% temp=24.5C flame=0 state=WARN [1402ms] smoke=78.9% temp=25.1C flame=1 state=ALARM打印时间戳这个习惯帮我解决过一个非常隐蔽的问题，后面踩坑复盘会详细展开。
4. 仿真先行：Proteus里跑通逻辑的正确姿势与仿真/实测差异
我习惯先把逻辑在Proteus里跑通再动手焊板。整套代码不用烧到真实芯片，就能验证状态切换、显示刷新和继电器动作顺序，省去大量焊接和反复烧录的时间。
4.1 仿真工程搭建：传感器模型用虚拟电位器替代
Proteus里并没有直接可用的MQ-2模型，强行找第三方模型反而不稳定。最稳妥的做法是用一个滑动变阻器POT-HG接在ADC引脚上，手动拖动人变阻器的值，就模拟出烟雾浓度缓慢上升的效果。火焰传感器模块在仿真里用一个按键代替，按下表示检测到火焰，释放表示无火焰。DHT11在仿真里也难跑真实时序，我直接在代码里用一个全局变量模拟温度值，通过按键加减。
仿真中最容易出错的是STM32芯片的配置。双击Proteus里放置的STM32F103C8T6芯片，在Program File里加载Keil编译生成的hex文件，Clock Frequency要手动填8MHz。很多人在这一步漏填或填错，仿真跑起来芯片完全不工作或者定时不准。如果仿真工程里使用了外部晶振电路，Proteus默认模型精度不够的话，我建议直接选择内部RC或按PLL倍频参数精确设置。
4.2 用虚拟示波器和状态变量判断逻辑是否正确
仿真阶段比写代码更花时间的是验证边界条件。我会做三组固定测试：
- 把电位器缓慢从最小值拧到预位置，观察报警状态是否按正常、预警、报警三级顺序推进。
- 快速来回拧电位器，模拟烟雾浓度抖动，确认连续计数消抖逻辑是否生效。
- 按下火焰按键的瞬间，确认状态机是否立即进入报警，蜂鸣器和继电器的虚拟模型是否动作。
Proteus的虚拟终端可以捕获串口打印内容，我把printf日志打开，在跳变瞬间能看到状态变化前进行了几次确认，从而判断计数阈值是否合理。虚拟示波器GRAPHCSCOPE则用于观察蜂鸣器PWM输出和ADC输入波形，我曾在仿真里发现预警状态蜂鸣器频率参数配错，导致声音变成超声波频段，这种问题在实物上很难用万用表定位，但在虚拟示波器里一眼就能看出来。
4.3 仿真通过不等于实物通过：两者差异清单
仿真能解决逻辑问题，但解决不了模拟电路问题。我整理了这份差异清单，给准备做实物的朋友打个预防针：
| 项目 | 仿真中的表现 | 实物中的差异 |
|---|---|---|
| 传感器 | 电位器输出线性且无噪声 | MQ-2预热慢、输出带噪声、存在温漂 |
| 继电器 | 吸合动作理想化 | 线圈产生反电动势，触点弹跳可能干扰电源 |
| 按键 | 无弹跳 | 机械按键存在几十毫秒抖动，GPIO需要滤波 |
| 蜂鸣器 | PWM输出直接看到 | 声音大小受三极管放大倍数和电压影响 |
| 电源 | 理想电压源无内阻 | 继电器吸合瞬间电流冲击会造成电压跌落 |
另一个提醒：不要因为仿真里继电器工作正常，就看轻续流二极管的作用。仿真模型不会因为缺少续流而击穿虚拟三极管，但实物不装续流二极管，继电器驱动管很容易报废。仿真通过了，只能说明逻辑链通了，焊接前仍要逐项核对原理图上的保护器件。
5. 踩坑复盘：误报、ADC跳变、继电器抖动的完整排查链路
这部分是项目最值钱的经验。我把实际调试中遇到的三个典型问题完整复盘，每个都按“现象、排查过程、根因、修复”四个步骤来写，方便你遇到类似问题时照猫画虎。
5.1 案例1：ADC读数跳变，排查链路实记
现象：OLED上显示的烟雾浓度在没有任何烟雾时，数值在15%到60%之间来回跳，完全没法用。
排查过程我开始以为MQ-2质量差，换了一个新模块，现象依旧。用万用表直接测模块AO引脚对地电压，读数稳定在0.2V左右，说明传感器本身没问题。再测单片机PA0引脚，电压在0.2V到0.9V之间跳，问题出在单片机这一侧。检查原理图才发现，我在分压电阻和ADC引脚之间虽然放了滤波电容，但电容接地是接到数字地，而分压电阻的参考地是模拟地，两个地之间又有压差。更隐蔽的是，软件中ADC读取函数没有加采样稳定时间，连续读取间隔太短，芯片内部采样电容还没来得及充满就下一次读取。
根因总结：一是地线规划不干净，二是软件采样时序不严谨。
修复动作：把模拟地、数字地在电源入口单点汇合，ADC引脚的滤波电容也统一接到模拟地；软件里每次ADC转换结束后留出几十微秒稳定时间，再叠加前面的中位值平均滤波。修复后浓度显示稳定在2%以内波动。
5.2 案例2：上电瞬间误报警，日志时间戳找到了真凶
现象：每次系统上电后约2秒，蜂鸣器突然急促响起，过了3秒又自动消失。状态机逻辑在仿真里完全正常，实物却总是触发报警。
排查链路先怀疑DHT11单总线首次读取超时导致温度数据异常，于是把温度读取临时注释掉，误报警依旧。再怀疑火焰传感器受红外干扰，拔掉火焰传感器连线，依旧报警。最后打开串口时间戳日志，看到上电瞬间打印的烟雾浓度数值高达90%，随后逐渐回落。对照时间线发现，报警恰好发生在MQ-2预热阶段。
根因：MQ-2的加热丝在上电瞬间经历一个电阻突变过程，AO输出电压会冲到很高的位置，此时传感器本身还没进入正常工作状态。手册里也明确写了首次通电预热时间约1分钟，我没把它当回事。
修复：代码中增加“开机预热等待”状态，上电后前30秒只显示系统正在预热，不参与任何报警判定。预热结束后自动校准基线并进入正常监测。这个坑在仿真电位器模型里永远复现不出来，只有实物会踩中。
5.3 案例3：继电器吸合瞬间单片机死机
现象：继电器第一次吸合时，OLED屏幕闪烁，紧接着STM32复位重启，蜂鸣器发出上电初始化短响。多试几次以后，成了每隔几秒就复位一次。
排查链路：用示波器钩在3.3V电源轨上，看到继电器吸合瞬间电压跌落到了2.4V左右，持续约几十毫秒，足以触发STM32的掉电复位。检查继电器驱动电路，发现线圈两端没有续流二极管，继电器关断瞬间产生的反向电动势直接冲击了公共电源。另一个问题是排烟风机和控制板共用同一个5V电源适配器，风机启动时拉低了整条电源轨。
根因：线圈反向电动势没泄放路径 + 功率负载和控制逻辑共用电源。
修复：继电器线圈并联1N4007二极管，负极接电源正极，保证反向电动势被钳位吸收；排烟风机从独立开关电源取电，不共用控制板5V；PCB走线时把继电器驱动回路的地线加宽，减少回流压降。修复之后反复测试200次吸合，系统运行稳定。
这里多说一句：如果是做220V风机控制，继电器触点端的强电布线必须满足安全间距，控制板和强电之间要开槽隔离，继电器最好选带外壳的防触点电弧类型。这个项目面向的是实验室基础环境，如果你要接入市电设备，请务必找专业电气人员评估。
6. 开源代码和资料怎么用：从下载到上电的完整复现流程
资料包发布之后，很多朋友拿工程打开就懵了，不是Keil编译报错，就是Proteus加载不出芯片。这里给一份我看过的、最省心的复现步骤。
6.1 开源源码目录与资料说明
整个仓库分四个目录：
Project/ ├── Hardware/ │ ├── schematic_eda/ # 嘉立创EDA可编辑工程 │ ├── schematic.pdf # 便于直接查看的PDF版原理图 │ └── BOM.csv # 替换物料清单 ├── Firmware/ │ ├── MDK-ARM/ # Keil工程 │ ├── Core/ # 启动文件和main │ ├── Drivers/ # BSP驱动 │ ├── App/ # 传感器、报警、显示应用层 │ └── Sensors/ # DHT11等传感器驱动 ├── Simulation/ │ ├── lab_fire_alarm.pdsprj # Proteus仿真工程 │ └── readme_sim.txt # 仿真环境要求和加载说明 └── Docs/ ├── README.md # 整体说明和FAQ └── calibration.md # 传感器基线校准方法其中Hardware目录里的BOM.csv是我额外花时间整理的，每颗料的型号、数量、封装、参考单价都列清楚了。照着买，一套下来大概六十块左右，不含风机。
6.2 从零复现的三步流程与工具环境
复现前先确认工具：
- Keil MDK 5.x，并安装STM32F1xx器件支持包。这个包经常被漏装，漏装后编译会直接提示找不到“stm32f1xx.h”。
- Proteus 8.15及以上，老版本对STM32F103模型支持不完整。
- 烧录工具可以是ST-Link、J-Link或USB转TTL串口，这里ST-Link最稳妥。
第一步，用Keil打开Firmware/MDK-ARM目录下的.uvprojx工程，点Build编译，在Output目录里得到hex文件。编译前确认C/C++宏定义用的是STM32F10X_MD，这个宏对应C8T6的中容量芯片。第二步，打开Proteus仿真工程，双击STM32芯片，加载上一步生成的hex，频率填8M，运行仿真。第三步，实物焊接按原理图接好传感器和继电器模块，用ST-Link通过SWD接口烧录，上电后OLED显示预热倒计时，预热结束系统进入正常监测。
常见问题无非三种：编译报错多半是器件包没装；仿真芯片不动多半是频率没填；ADC采出来全是4095或者0，先查分压电阻是否焊接正确、传感器地线是否和主控共地。
6.3 二次开发方向：远程报警、多点布防和总线扩展
这个项目留了很多扩展口，尤其是系统稳定跑通后，你可以往这几个方向继续加东西。
远程报警是最实用的一步。板上空余一个USART2，接一个ESP8266或ESP32模块，用MQTT把报警状态和传感器数据推到手机。代码里我预留了app_remote.c的位置，报警状态机跳变时调用remote_send_event()即可，不需要改内部逻辑。
多点布防则推荐走RS485总线。实验室如果面积大，可以每个房间放一套预警节点，节点间用MAX485芯片组网，统一上报到值班室上位机。方向控制引脚需要精准切换，这也是市面上很多485模块的核心处理逻辑，正好可以在扩展时练习一把。
执行机构方面，除了排烟风机，还能用继电器控制燃气电磁阀，报警时自动切断气源；或者在消防水路上加电磁阀，联动启动喷淋。系统框架本身不需要大改，只是把app_alarm.c里ALARM状态的输出对象扩充一下。
我现在已经把代码、原理图、仿真全部整理好放进了开源仓库，需要的直接拿去用。复现中卡住，先看Docs里的README和校准文档，绝大多数问题都集中在供电、共地和传感器预热这三件事上。整套项目做下来，我最想分享的经验只有两条：硬件上，电源和地线的优先级永远高于功能电路，顺序不能反；软件上，状态机比堆if/else可靠得多，尤其是涉及多级报警、连续确认、锁存复位这些逻辑的时候。希望这个项目能帮你省掉我当年踩坑的时间。
