单片机消防预警项目，说实话是个老掉牙的题目，但每次看到有人把它重新做出来开源，我还是会点进去看一眼。原因很简单：这个题目麻雀虽小，五脏俱全，几乎把嵌入式开发里最常见的那套东西全过了一遍——多传感器采集、ADC转换、单总线时序、状态机调度、声光报警、按键交互，甚至还能牵扯到继电器控制和电源设计。对正在找毕业设计方向、或者刚入门想找个完整项目练手的人来说，这比单纯点个LED灯有价值得多。这次分享的是一个实验室消防预警控制系统的完整开源方案，带代码、原理图和Proteus仿真工程，我把它从需求拆解到硬件选型到代码逻辑再到仿真调试全流程过一遍，顺便把我在实际调试中踩过的坑也一并整理出来。
1. 项目概览与设计思路
1.1 实验室消防隐患与项目定位
实验室跟普通办公区最大的区别在于，里面同时存在易燃试剂、大功率设备和密闭或半密闭空间。一旦出现火情，烟雾和温升往往比明火更早出现，所以做消防预警的核心逻辑是“尽早感知异常，快速声光提醒，争取人工处置窗口期”，而不是等火烧起来再启动什么自动灭火——对实验室这种场景，自动喷淋反而可能造成二次事故。
基于这个定位，系统用到的传感器就很明确了：烟雾浓度、环境温度、以及可选的火焰信号。我的方案里，烟雾用的是MQ-2，温度湿度走DHT11，火焰检测预留了一个数字量接口。主控用STM32F103C8T6，这板子便宜、资料多，板载资源对一个预警系统来说完全不紧张。输出侧包括蜂鸣器报警、LED闪烁指示、继电器控制排风扇或电磁阀，外加一块OLED屏显示实时数据和阈值状态。
整个项目解决的核心问题，就是让一个只有基础电路知识的开发者，能够在一周左右把一套完备的消防预警原型机跑起来——既能理解原理，又能复制实现，还能源码级二次开发。
1.2 系统功能架构拆解
先看整体数据流，逻辑非常清晰：
烟雾传感器(MQ-2) → ADC通道 → 数据滤波 → 阈值比较 → 异常判定 温湿度传感器(DHT11) → 单总线时序 → 数据解析 → 阈值比较 → 异常判定 火焰传感器(数字量/模拟量) → GPIO/ADC → 状态读取 → 异常判定 ↓ STM32F103C8T6 主控（状态机调度 + 按键设置） ↓ OLED显示(实时数据) / 蜂鸣器报警 / LED指示 / 继电器联动排风功能上我分了三个层级，第一层是“采集显示”，实时刷新温湿度和烟雾浓度，让值班人员能随时看到环境状态；第二层是“阈值预警”，超过预设阈值触发蜂鸣器和灯光；第三层是“联动控制”，异常持续一定时间后继电器动作，自动打开排风扇。这个三层设计的好处是，就算传感器误报，最坏结果也只是排风扇转一会儿，不至于直接触发报警器吓到满楼人。
按键交互部分，我用了三个按键：一个进菜单、一个加、一个减。长按进入设置模式后可以调整烟雾和温度的上限值，设置完自动存入内部Flash，下次开机不用重新设。OLED上会同步显示当前阈值和实测值，方便校准。
1.3 功能选型背后的取舍
为什么不直接买现成的烟雾报警器模块？因为市面上绝大多数模块只给出一个“是否超标”的数字量输出，你拿不到确切的浓度变化曲线，更没法自己设定阈值。消防预警系统的核心恰恰就在阈值逻辑上——不同实验室的允许值不一样，烟感探头安装距离不一样，环境基线也不一样，固定阈值的模块根本没法适配。
所以我在设计里特意把MQ-2的模拟量输出接入了STM32的ADC，做实时浓度采样。这带来的额外好处是：阈值能软件可调，而不是焊死在电路上。代价就是需要处理传感器的上电漂移问题，这部分我在代码章节详细讲。
DHT11选择它的理由只有一个：够用且时序简单。实验室消防预警不需要高精度温湿度测量，DHT11的±2℃和±5%RH精度足够判断环境是否异常，代码层面只需要严格按单总线时序来读。假如你有更高要求，代码里预留了DHT22的替换位置，只需要改一下读取函数的时序参数。
2. 硬件原理图设计与器件选型
2.1 主控最小系统：STM32F103C8T6典型电路
原理图的核心是STM32F103C8T6最小系统，这部分没什么可发挥的，照着数据手册搭就行。我的电源方案是USB的5V进来，先用一个100uF电解电容做输入滤波，再经过AMS1117-3.3输出3.3V给主控和传感器供电。选AMS1117的原因简单——封装大，好焊接，输出稳定，对DIY项目来说不容易烧。
复位电路用的是经典的RC复位，10K上拉电阻加100nF落地电容，搭配STM32内部的NRST引脚。有人问过为什么不用专用复位芯片，这个项目是用在实验室环境，不是汽车电子的严苛场景，RC复位配合内部看门狗完全够用，没必要多花成本。
晶振部分我用了8MHz主晶振加两个20pF负载电容。注意，STM32F103也能用内部HSI振荡器省掉外部晶振，但在ADC采样场景下，内部RC振荡器的精度会对采样稳定性产生微妙影响，建议还是把外部晶振焊上。另外我还引出了一个用于RTC的32.768K晶振位置，虽然这个项目没有用到RTC，但原理图上留了封装，后面要扩展定时记录历史数据的时候不用改板子。
下载调试接口用的是标准的SWD四线制：SWDIO、SWCLK、GND、3V3。有条件就接一个5脚的杜邦座出来，调试的时候方便很多。当然，如果你习惯用串口ISP下载，原理图上也预留了BOOT0和BOOT1的跳线帽位置。
2.2 采集端：MQ-2烟雾与DHT11温湿度
MQ-2的接法有个容易翻车的地方。模块上通常有两种输出：数字量DOUT和模拟量AOUT。很多新手图省事只接DOUT，结果就是只能判断“有没有超阈值”，完全丧失浓度监测能力。我接的是AOUT到PA0（ADC1通道0），配合一个10K电位器在模块本身上调灵敏度，两个自由度配合起来，阈值设置才真正灵活。
MQ-2上电时需要预热。它的内部是一个加热电阻，冷启动时采样值会从很低慢慢爬升，大约三到五分钟才稳定。代码里我加了一个“启动稳定期”逻辑——开机前60秒只显示不上报，避免开机瞬间的飘高值误触发报警。这个细节一定要做，否则每次断电重启系统都会乱叫一通。
DHT11的数据线接PB11，需要外接一个4.7K上拉电阻到3.3V。这个上拉电阻是单总线通信的硬性要求，不能省。有朋友直接把DHT11模块的PCB小板往杜邦线上一插，模块上本身自带上拉电阻，但如果你是自己焊的传感器裸体，上拉忘了加，时序会全线崩溃，读出的数据全是0xFF漂移值。我在原理图上是画了上拉电阻的，焊板时注意一下就好。
DHT11的供电电压理论上可以在3.3V到5V之间跑，我建议统一使用3.3V。为什么？因为STM32的GPIO耐压有限，如果你用5V给DHT11供电，它的数据线输出高电平也是5V，直接怼在PB11上长期运行会缩短MCU寿命，甚至直接烧GPIO。3.3V供电虽然让DHT11的测量范围略微受限，但在这个项目里完全够用，安全第一。
2.3 执行与交互：声光报警、继电器、OLED
蜂鸣器这里有个经典坑。有源蜂鸣器自己带震荡源，给电就响，可控性好；无源蜂鸣器需要外部PWM驱动才能发声，代码复杂度更高。我做消防预警当然选有源的，用一只NPN三极管（S8050）做开关驱动，而不是直接把蜂鸣器接在GPIO上——蜂鸣器工作电流普遍要20mA以上，GPIO直接拉会超手册额定值，时间长了GPIO口可能损坏。
三极管驱动电路的接法是：GPIO通过1K限流电阻接三极管基极，蜂鸣器接在集电极和5V电源之间，发射极接地，基极再并一个10K下拉电阻防止上电误触发。注意蜂鸣器是感性器件，断开瞬间会产生反向电动势，我并了一个1N4148续流二极管在蜂鸣器两端，方向反接（正极对地），这个二极管能把反向尖峰泄放掉，没有它的话，报警频率高的时候三极管容易被击穿。
继电器控制排风扇用的是低电平触发继电器模块，同样通过三极管驱动，线圈两端并联一个LED做状态指示。我实际选的是5V单路继电器，触点容量10A，控制一个实验室排气扇绰绰有余。需要提醒的是，继电器驱动和单片机逻辑地一定要共地，否则模块没法触发。
显示用的0.96寸I2C接口OLED，SCL接PB6，SDA接PB7，程序里用软件模拟I2C还是硬件I2C都可以。我实测下来，STM32F103的硬件I2C偶尔会出现总线锁死问题，为了稳定性，在代码里直接用的软件模拟I2C，牺牲一点CPU时间换可靠性，对于这种显示频率不高的场景非常划算。
2.4 电源与PCB布局要点
整个系统的电源树是：USB 5V进来后分三路——第一路直接给继电器模块供电，第二路过AMS1117转为3.3V给STM32、OLED、DHT11供电，第三路经过滤波电感给MQ-2的加热回路供电。为什么把MQ-2单独拉一路？因为它的加热电阻在工作时会有明显的电流波动，如果跟MCU共用一条电源线，ADC的参考电压会被污染，采样值一跳一跳的，看起来像传感器坏了。
PCB布局方面，我画的是双层板。模拟地和数字地在主控芯片下方单点汇合，ADC采样电路尽量靠近MCU引脚，走线短而粗。DHT11的放置位置要远离蜂鸣器和继电器，这两个器件工作时会产生机械振动和电磁干扰，离得太近会让温湿度读数在报警瞬间发生跳变。OLED用排针引出，做成可插拔结构，方便调试时拆下来看主板。
3. 软件代码核心逻辑与调试经验
3.1 工程结构与初始化流程
软件部分我用的是标准库开发的STM32F103工程，代码目录结构从写好到现在一直保持三块：Hardware放外设驱动，Core放主逻辑和中断，System放系统时钟和延时函数。这种分层的思路对新手特别友好——传感器出问题就查Hardware，逻辑判断出错就查Core，不要到处乱翻。
主函数的初始化顺序有讲究，我按这个顺序来：
int main(void) { SystemInit(); // 系统时钟初始化，设为72MHz Delay_Init(); // 延时函数初始化 OLED_Init(); // OLED初始化 ADC1_Init(); // ADC配置，用于MQ-2采样 DHT11_Init(); // DHT11 GPIO配置 Key_Init(); // 按键GPIO配置 Buzzer_Init(); // 蜂鸣器GPIO配置 Relay_Init(); // 继电器GPIO配置 ReadThresholdFromFlash(); // 从Flash读取用户设定的阈值 MQ2_WarmUp_Delay(60); // MQ-2预热稳定期，60秒 while(1) { StateMachine_Update(); // 主循环状态机 } }初始化顺序里最容易被忽略的是读取Flash阈值的时机，一定要在进入主循环之前完成，因为OLED第一屏就要显示阈值。另外，预热期间虽然不上报报警，但OLED还是要正常刷显示，我把“预热状态”作为一个变量传入显示函数，让界面上直接显示“WARMING UP”字样，这样用户不会以为死机了。
3.2 传感器读取与数据滤波
MQ-2的ADC读取我配置为12位分辨率，VREF是3.3V，所以采样值范围是0到4095。代码里我不能直接拿原始采样值跟阈值比较，需要转成电压值再换算成跟浓度相关的无量纲数值。我实用性地做了一个映射：
float MQ2_GetVoltage(void) { uint16_t adc_val = ADC_GetValue(); return (float)adc_val * 3.3f / 4096.0f; }这个电压值作为判据已经够了，因为MQ-2的电阻随可燃气体浓度变化，输出电压单调变化。阈值默认是1.2V，约等于室内刚有烟味时的水平，用户可以手动调整。
ADC数据我是用滑动窗口滤波的，取最近10次采样的平均值。这里有个性能小技巧：用循环队列维护窗口，每次进一个新值就加进去、踢掉最旧的值，再除以窗口大小，而不是每次重新累加10次，否则100Hz的采样频率下CPU开销会白白高10倍。
DHT11的读取代码是全项目里最讲究时序的地方。它的单总线协议要求主机先拉低总线至少18ms，然后释放并延时20~40us，之后读取传感器返回的80us低电平响应和80us高电平准备信号，再开始逐位读取40bit数据。每一位的时间窗口在70us左右，微秒级延时必须精准。
我调试DHT11时发现，在72MHz主频下，用简单的循环空转做微秒延时，编译器开O2优化后延时时间会缩水，导致时序错乱。解决方案有两个：一是查表校正延时函数的循环次数，二是直接用DWT硬件定时器做微秒延时。我后来改用了DWT（数据观察点与跟踪单元）来精确计时，代码稳定多了。
3.3 消防判定逻辑与消抖
消防预警最怕误报。直接阈值比较的做法在实机上会有问题：MQ-2在有人抽烟或者炒菜的实验室里，电压值会瞬间飙高又回落，如果判定逻辑太灵敏，蜂鸣器会跟着一阵狂响。我设计的判定状态机是三态模型：
typedef enum { STATE_NORMAL, // 正常态：不报警 STATE_WARNING, // 预警态：超过阈值，进入倒计时确认 STATE_ALARM // 报警态：预警持续确认后触发 } FireAlarmState;从NORMAL进入WARNING的条件是烟雾电压连续3秒超过阈值（不是一瞬间），这个连续3秒的判断通过周期计数实现——每100ms检测一次，连续30次超标才切换状态。进入WARNING后蜂鸣器不响，只是OLED提示“疑似烟雾”；从WARNING进入ALARM的条件是累计超标时长超过10秒。这样做之后，偶发性烟雾干扰几乎不会触发报警，只有持续的浓度异常才会导致真正的警报。
温度判定同理，DHT11读到的温度超过设定上限（默认55℃）且持续5秒以上才进入预警。温度与烟雾的逻辑是“或”关系——任何一个超限都会触发预警，因为实验室火灾往往伴随温度上升，而有些燃烧是不产生大量烟雾的。
报警触发后的处理逻辑也要写清楚：蜂鸣器以2Hz频率鸣响、LED快速闪烁、继电器吸合排风扇工作。复位报警的方式有两种，一是手动按键确认，当浓度回落到阈值以下后按OK键清除警报；二是自动恢复，浓度低于阈值80%且持续30秒后系统自动复位——自动复位的滞回区间一定要有，否则浓度在阈值边缘震荡时系统会在报警和正常之间疯狂跳变。
3.4 按键阈值设置与OLED显示
阈值设置接口我做成了菜单模式，这是整个交互逻辑里最磨人的部分。OLED上显示两行，上面是当前参数名，下面是对应的数值。按键逻辑长按OK键2秒进入设置模式，短按切换参数项，加键减键调节数值。每调一个参数，都会实时把新值写入Flash，避免退出菜单时忘记保存。
Flash写入用的是内部Flash最后一个扇区，地址0x0800FC00（F103C8T6有64KB Flash，最后1KB留给用户参数）。写入前先擦除整个扇区，再写入64字节的结构体数据，里面包含参数结构体和校验字段（我用了简单的CRC8）。开机读Flash时先校验CRC，通过才加载用户设置，不通过就用默认值——这能避免读到全0xFF的空白Flash时把阈值默认成0，直接引发误报的尴尬。
OLED显示界面分三个页面：主页循环显示温度和湿度、烟雾电压值、系统状态；第二页显示当前阈值设置；第三页是历史报警记录次数。页面切换用短按OK键实现。字体方面我用的是中景园8x16字符点阵，数据量小、刷新快，在0.96寸OLED上显示四行信息刚刚好。
4. 仿真环境搭建与Proteus联调
4.1 Proteus器件准备与电路搭建
很多人在Proteus里搭这个电路会发现几个元件找不到：MQ-2模块、DHT11模块、OLED的I2C模型。我的做法是分开搭——烟雾传感器用“滑动变阻器+电压源”的组合模拟，因为MQ-2对STM32来说本质就是一个电压源，浓度变化反映为电压变化，仿真时用一个电位器分压模拟烟雾浓度升降，效果非常直观；温度传感器用Proteus里的LM35代替。虽然DHT11也能输出温度，但Proteus没有现成的DHT11仿真模型，硬要用的话得自己写SPICE模型，成本太高，不如用LM35实现“温度采集”这个功能等价物。
这背后其实是一个重要仿真思路：仿真验证的核心是逻辑，而不是传感器本身行为。你不需要在仿真里复现MQ-2的加热漂移特性，只需要验证“电压超阈值→系统报警→排风扇启动”这条链路是否通了。所以我仿真工程的传感器部分全部用等效模型，而代码层我把MQ2_GetVoltage()、DHT11_Read()这些函数做了条件编译——在仿真模式下走等效接口，在实机模式下走真实驱动，同一套主逻辑跑两边都不用改。
4.2 仿真中的传感器等效模拟
烟雾浓度部分，我用一个10K电位器，滑片接ADC输入通道，两端分别接3.3V和地。旋转电位器时ADC采样电压从0到3.3V连续变化，这样就能复现烟雾浓度变化的完整过程。阈值设置成1.2V时，旋钮转到大约36%的位置就会触发预警，模拟实验操作非常方便，不用真的去点烟。
温度部分用的是LM35加一个电压源。LM35的输出电压是10mV/℃，室温下约300mV。为了模拟温度异常升高，我接了一个可调电压源叠加到LM35的输出上，用一个加法电路把两个信号合起来送入ADC。旋转电压源就能模拟温升过程，很方便验证温度报警路径。
有了这些等效模拟，联调的关键操作路径就清晰了：电路上电后，OLED虚拟屏幕应显示当前环境电压值（0.5V左右）；慢慢旋转烟雾电位器，当电压超过阈值时，系统进入WARNING状态，OLED显示变化；保持该状态超过10秒后，进入ALARM状态，蜂鸣器虚拟器件响起，继电器动作使风扇电机旋转。这一整套链路跑通，整个项目的核心逻辑就算验证通过了。
4.3 仿真调试技巧与实物一致性问题
Proteus里最容易被坑的是晶振设置和MCU时钟频率不匹配。我吃过一次大亏：原理图上画的8MHz晶振，但Proteus的STM32模型默认外部时钟是72MHz，直接导致代码里所有依赖时间基准的逻辑混乱——延时缩短到原来的1/9，OLED初始化一半就卡死。解决方法是双击STM32芯片模型，在Clock Frequency里改成72MHz，或者干脆把代码里的延时函数改成查询周期计数器的方式，不依赖固定的循环延时。
仿真中OLED模型嵌入的是SSD1306的接口，但Proteus自带的OLED模型对I2C的时序容错比较差，软件模拟I2C的延时在仿真里会影响显示。我最后把仿真工程的显示驱动切换成了硬件I2C版本，仿真通过后烧回实机时才改为软件模拟I2C。这里借用一个思想：仿真工程和实物工程的驱动代码可以不一样，两者之间的桥梁是统一的应用层接口——OLED_ShowString()、OLED_ShowHexNum()这些函数在两端都叫同一个名字，内部实现各归各，应用层逻辑完全复用。
仿真还有一个容易被忽略的点是：Proteus里复位电路有时会发生复位引脚毛刺导致芯片反复重启。我的处理是把这个RC复位电路的复位电容加大到1uF，确保上电后复位信号能持续足够长的时间让晶振稳定起来。这个改法在实物上不能照抄（1uF复位电容会导致复位太慢，按键复位体验差），但仿真里运行稳定即可。
5. 常见问题与排查实录
5.1 经典故障速查表
我把从原理图到代码的整个调试过程中遇到的典型问题整理了一下，大部分都是新手项目里反复出现的高频故障：
MQ-2电压值一直为0先量模块供电是否正常，再看AOUT引脚是否真的连接到PA0。我遇到过一次是杜邦线插错位，AOUT插到了GND丝印旁边，排查了半小时才反应过来。软件层面，检查ADC初始化有没有开启GPIO的模拟输入模式，没有的话读到的值恒为0。
DHT11一直读到0xFF或超时大概率是上拉电阻缺失或引脚初始化模式不对。数据脚一定要配成开漏输出+外部上拉，用推挽输出或浮空输入都会失败。另外，连续两次读取DHT11之间要间隔至少1秒，读得太频繁传感器会不响应。
蜂鸣器不响但LED正常先把代码里的GPIO配置改成推挽输出、翻转电平测试；如果还是无声，检查三极管基极电阻——我见过有人把1K焊成了10K，驱动电流不够，蜂鸣器只能发出微弱的“嘶嘶”声。更隐蔽的问题是蜂鸣器正负极接反，有源蜂鸣器反接不会响但也不会烧，现象跟没驱动一模一样。
继电器频繁抖动继电器线圈断电时产生的反向电动势干扰了MCU电源，表现为系统复位或ADC值突变。在继电器线圈两端并联续流二极管后，这个现象基本消失。如果是模块化的继电器板，板上一般自带续流二极管，直连MCU控制信号时注意模块输入端的电平匹配就行。
烧录后程序不跑，但下载正常ST-Link能识别芯片能烧录，说明SWD和电源基本没问题。程序不跑常见原因是BOOT0被拉高，芯片进入了ISP模式，不会从Flash启动。检查BOOT0引脚是否有跳线帽或者外接电阻把它误拉高到3.3V。另一个原因是复位电容太大，上电后复位时间过长，主程序其实在跑但OLED初始化还没完成，要等三五秒才显示。
ADC采样值跳变超过100个单位MQ-2的加热电阻在工作时电流变化会影响到模拟参考电压，尤其是用USB供电时更明显。拉大ADC采样窗口到20次平均，或者用软件均值滤波能压住一部分。硬件上把MQ-2供电单独用LC滤波隔离开是最彻底的方案。
5.2 实测中的坑与心得
先说传感器预热的问题。我第一次实机调试时就翻过车，通电后系统立刻报警，蜂鸣器一通狂响，当时还以为是阈值设得太低。后来看打印的电压曲线才明白，MQ-2冷启动时输出会先冲到2.5V再慢慢降到0.8V稳定值，这个过程持续两三分钟。如果代码不做预热屏蔽，系统一上电就误报，观感极差。所以“开机60秒预热”这个逻辑不是可有可无的，是必须加的。
关于按键消抖，很多人都知道用延时消抖，但在这个项目里光延时不够。因为面板按键和蜂鸣器靠得近，报警时蜂鸣器振动会引起机械抖动，表现为按键一次触发变成两三次。我在按键扫描里用的是状态机消抖——连续检测到稳定电平超过20ms才算一次有效按下，并且在按键松开前不响应第二次触发。
DHT11的读取频率我也要特别提醒。它的数据手册上写得清清楚楚，读取间隔要大于1秒。新手容易犯的错误是在主循环里反复快速读，结果就是传感器不响应或者CRC校验失败。我最后把DHT11的读取频率限制在每2秒一次，主循环里加了个时间戳判断，时间未到就跳过读取直接显示上一次的缓存值。这个缓存策略同样适用于OLED刷新——每200ms刷一次就够了，不必要的快速刷新会加重I2C总线负担。
还有一个比较隐蔽的问题：我一开始把ADC采样放在主循环里，用的是阻塞式读取，结果DHT11的微秒级时序延时被ADC阻塞打断了，导致DHT11频繁超时。后来把ADC读取改成了DMA模式，MCU在后台持续把ADC值搬运到内存环形缓冲区，DHT11读取期间不会被ADC占用打断。主循环里只需要取缓冲区最新的平均值即可。这个改动让两个传感器都能稳定工作，强烈建议同样被时序问题困扰的朋友试试。
5.3 扩展方向与二次开发建议
代码和原理图开源出去之后，很多朋友问下一步还能往哪改。我给几个实际可行的方向：第一是增加WiFi模块，比如ESP8266或ESP32，用串口跟STM32对接，把实时数据和报警信息推送到钉钉或微信机器人，这样人不在实验室也能收到通知。第二是换成4G模块做远程短信报警，适合没有WiFi覆盖的旧实验室。第三是加一个火焰传感器（模拟量输出版本），作为第三路判据，三路信号之间用“或”逻辑综合判定，能显著降低单一传感器失效带来的漏报风险。
如果想把系统升级成更符合工业消防规范的版本，可以考虑替换核心传感器：把MQ-2换成电化学式一氧化碳传感器，把DHT11换成SHT30这类I2C接口的高精度温湿度传感器，ADC前端加一级运放放大电路以适配不同传感器的输出电压范围。主控端如果觉得F103的Flash不够用，可以换F103RCT6或者F407，代码移植成本极低，因为用的标准库API大部分兼容。
对了，还有一个日常维护的小经验：MQ-2这类半导体传感器的敏感材料会随着时间老化，基线输出电压会漂移，建议每半年做一次阈值校准——把传感器放在干净空气中通电稳定半小时，记录此时的基线电压，然后把阈值改成“基线电压+固定偏移”的形式存进Flash。我在代码里留了这个接口，开机时长按加减键组合进入校准模式，屏幕上会自动显示当前基线值，一键写入。
最后再说一个我一直坚持的习惯：原理图、代码和仿真工程三者必须同步更新。很多人只改代码不改原理图，过两个月自己都忘了哪个引脚被改了。我的做法是在原理图每个网络标号上标注对应的GPIO宏定义名称，代码里的引脚定义直接引用原理图上的标签，这样两边对不起来的时候，一眼就能发现不一致。开源项目最怕的就是文档和代码脱节，哪怕只是一个人自用，把“原理图-代码-仿真”的对应关系维护好，后续版本的迭代会轻松十倍。
