ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

STM32实验室消防预警系统:传感器融合与状态机设计实践

STM32实验室消防预警系统:传感器融合与状态机设计实践 1. 实验室消防预警这个需求究竟难在哪系统方案与需求拆解很久以前我在实验室等一批样品烘干结果忘了关加热台回来的时候一股焦糊味已经飘到楼道。那次之后我一直在想能不能用几十块钱的成本做一套不需要云平台、断电也能工作、源码完全看得懂的消防预警装置。于是有了这个开源项目——实验室消防预警控制系统。它基于STM32F103C8T6把烟雾、火焰、温湿度三个维度的传感器数据汇总到一个可维护的状态机里本地直接给出声光报警并联动排烟风机配套的代码、原理图和仿真全套放出想复现的人不需要多深的嵌入式基础。1.1 实验室火灾的几个容易被忽略的信号特征实验室火灾和住宅火灾有个明显区别大多不是猛火起燃而是设备长时间通电、线路过载、加热装置遗忘造成的高温阴燃。阴燃阶段烟雾产生得最早这时候温度还没有明显上升明火也还没出来。也就是说每一类传感器能覆盖的时段完全不同。烟雾传感器对早期阴燃最敏感是预警系统的第一道防线。温度传感器响应慢但一旦整片区域温度突破阈值基本可以确认事故已经升级。火焰传感器对突然出现的明火响应快能弥补烟雾传播慢的问题。我一开始也想过只做一个烟雾报警器后来发现实验室有人做焊接测试、酒精灯操作这些场景偶尔会产生短时烟雾单纯看烟雾浓度很容易误报。把温度、火焰和烟雾三个维度放在一起做交叉判断才算是一个真正能用的消防预警系统。1.2 从功能需求到系统模块预警控制到底要管哪些事这套系统的功能需求拆开看其实不复杂但每一项背后都有隐藏问题实时监测烟雾浓度、环境温度、火焰信号采集周期不能太慢否则失去预警意义。多级声光报警不能一报警就拉响最高级别否则实验室日常操作会被频繁打断。联动排烟风机报警后自动开启降低可燃气体积聚风险。OLED显示当前数据和报警状态方便现场人员判断。按键交互支持测试、静音和报警复位。串口输出原始数据给调试和阈值调参留一个口子。对应的系统模块就是传感器采集节点、主控决策单元、声光输出模块、风机联动模块、人机交互模块。主控决策单元是整个系统的核心我在设计时把报警逻辑做成独立模块而不是在main函数里堆if/else。后面软件章节会专门说这个。1.3 主控选型STM32F103C8T6为什么是这个项目的甜点位市面上做这类小系统的主控很多51、Arduino、ESP32都能干但STM32F103C8T6有几个非常贴合本项目的点。第一是ADC资源。系统要同时采集烟雾传感器模拟量、火焰传感器电平、温度传感器数据F103C8T6的ADC有16个通道留给扩展余量充足。第二是外设丰富I2C可以接OLEDUSART可以做调试和后续的RS485/WiFi扩展定时器可以输出蜂鸣器需要的PWM信号。第三是成本单个芯片几块钱加上最小系统板也不过十几块做成开源项目后别人复现的门槛很低。我还专门评估过资源占用程序逻辑完整实现后Flash占用大约18KBRAM占用大概在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.cADC初始化、采集、DMA搬运adc_read_channel()bsp_tim_pwm.c蜂鸣器PWM输出及频率切换buzzer_set_mode()bsp_i2c_oled.cSSD1306驱动、字符串显示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刷新一次OLED100ms打印一轮串口调试数据。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] smoke32.4% temp24.5C flame0 stateWARN [1402ms] smoke78.9% temp25.1C flame1 stateALARM打印时间戳这个习惯帮我解决过一个非常隐蔽的问题后面踩坑复盘会详细展开。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 案例1ADC读数跳变排查链路实记现象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二极管负极接电源正极保证反向电动势被钳位吸收排烟风机从独立开关电源取电不共用控制板5VPCB走线时把继电器驱动回路的地线加宽减少回流压降。修复之后反复测试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可靠得多尤其是涉及多级报警、连续确认、锁存复位这些逻辑的时候。希望这个项目能帮你省掉我当年踩坑的时间。
返回列表