先說個(gè)背景。我之前在學(xué)校實(shí)驗(yàn)室里負(fù)責(zé)過一段時(shí)間儀器設(shè)備維護(hù)跟不少同學(xué)聊過實(shí)驗(yàn)室安全管理的事。實(shí)驗(yàn)室跟普通辦公室不一樣里面有過夜充電的鋰電池、長期通電的烘箱、各種加熱設(shè)備真要出問題往往是下班后沒人看見的時(shí)候。商用消防報(bào)警器不是不好但一套下來價(jià)格不低而且大多是黑盒方案探測閾值、聯(lián)動邏輯都沒法按自己的場景調(diào)。所以我自己用 STM32 做了套實(shí)驗(yàn)室消防預(yù)警控制系統(tǒng)把代碼、原理圖和仿真工程一起開源了出去。這套東西能實(shí)時(shí)檢測煙霧濃度、火焰信號、溫濕度觸發(fā)聲光報(bào)警還能通過繼電器控制排風(fēng)扇或者電磁閥。對做嵌入式入門、電子設(shè)計(jì)課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)的同學(xué)來說它是很好的參考項(xiàng)目對實(shí)驗(yàn)室安全管理人員來說它也是個(gè)低成本的預(yù)警補(bǔ)充方案。這篇文章就把我做這個(gè)項(xiàng)目的完整思路拆開講從需求分析、原理圖設(shè)計(jì)、代碼邏輯到仿真調(diào)試最后說說開源發(fā)布時(shí)怎么整理文件才能讓別人快速跑起來。1. 消防預(yù)警系統(tǒng)到底解決什么問題需求拆解與整體方案選型很多人一上來就直接打開畫圖工具畫原理圖寫代碼其實(shí)這是最容易翻車的做法。我第一版就是這樣結(jié)果做到一半發(fā)現(xiàn)傳感器選型不合理ADC 通道不夠用蜂鳴器驅(qū)動電流不夠整個(gè)推翻重來。所以先花點(diǎn)時(shí)間把需求捋清楚比多寫一百行代碼都值。1.1 實(shí)驗(yàn)室火災(zāi)“早發(fā)現(xiàn)”為什么比家庭場景更難實(shí)驗(yàn)室里最危險(xiǎn)的不是瞬間爆燃而是緩慢的熱積累。比如烘箱溫控失靈、電熱套干燒、鋰電池過充發(fā)熱這類情況在初期幾乎沒有明火只有溫度升高和少量煙霧。家庭里大多數(shù)人能聞到焦糊味但在實(shí)驗(yàn)室化學(xué)試劑本身就有各種氣味通風(fēng)櫥一開人的嗅覺基本報(bào)廢等肉眼看到煙的時(shí)候已經(jīng)過了最佳處置窗口。所以消防預(yù)警系統(tǒng)要盯的核心不是“有沒有火”而是“有沒有異常趨勢”。煙霧濃度從正常到升高的過程、環(huán)境溫度是否異常爬升、是否存在紅外火焰特征信號這三個(gè)維度放在一起判斷比單一傳感器靠譜得多。1.2 為什么選 STM32 而不是 51 或者 ESP32這個(gè)項(xiàng)目最早我用 STC89C52 試過做是能做但很憋屈。煙霧傳感器輸出的模擬量51 單片機(jī)沒有 ADC需要外掛 ADC0809 之類火焰?zhèn)鞲衅骱?DHT11 都還好報(bào)警輸出也沒問題。問題是代碼一旦復(fù)雜起來比如要同時(shí)處理 ADC 采樣、DHT11 時(shí)序、按鍵掃描、狀態(tài)機(jī)切換8 位 MCU 的資源和代碼組織能力會很吃力調(diào)試效率也低。后來換成 STM32F103C8T6這塊板子現(xiàn)在可以說是嵌入式學(xué)習(xí)界的“標(biāo)配貨”了。四個(gè)理由讓我確定用它外設(shè)完整內(nèi)置 ADC、TIM、USART、I2C、SPI一顆芯片就能接煙霧傳感器、火焰?zhèn)鞲衅鳌HT11、OLED 顯示屏、繼電器不用東拼西湊。生態(tài)成熟標(biāo)準(zhǔn)外設(shè)庫和 HAL 庫資料鋪天蓋地遇到問題幾乎都能搜到答案。價(jià)格便宜小批量幾塊錢一片打樣做壞了幾塊也不心疼。性能余量夠后面想擴(kuò)展 4G 短信報(bào)警、ESP8266 聯(lián)網(wǎng)上報(bào)STM32F103 依然能帶得動。ESP32 我也考慮過它確實(shí)性能更強(qiáng)還自帶 Wi-Fi但問題是用在這個(gè)場景里有點(diǎn)“殺雞用牛刀”而且它的 ADC 線性度一般用來做煙霧濃度采樣不如 STM32 的 12 位 ADC 順手。再說實(shí)驗(yàn)室消防設(shè)備穩(wěn)定性比聯(lián)網(wǎng)功能優(yōu)先級更高。1.3 系統(tǒng)總架構(gòu)三個(gè)檢測維度加兩級響應(yīng)這套系統(tǒng)的整體架構(gòu)不復(fù)雜一句話描述就是傳感器采集環(huán)境參數(shù)單片機(jī)做濾波和閾值判斷根據(jù)危險(xiǎn)等級執(zhí)行不同動作。我設(shè)計(jì)的檢測維度是這三路檢測項(xiàng)目傳感器信號類型說明煙霧濃度MQ-2模擬電壓加熱型半導(dǎo)體傳感器對煙霧和可燃?xì)怏w均敏感火焰信號火焰?zhèn)鞲衅髂K數(shù)字電平紅外波段檢測帶靈敏度電位器調(diào)節(jié)溫濕度DHT11單總線數(shù)字輔助判斷環(huán)境異常比如溫度連續(xù)上升響應(yīng)端包括聲光報(bào)警和繼電器聯(lián)動。聲光報(bào)警用的是有源蜂鳴器加紅綠雙色 LED繼電器用來控制排風(fēng)扇、電磁閥或者切斷非關(guān)鍵設(shè)備電源。這一路是真正干活的不是只叫喚兩聲就完事。代碼層面分成三層底層驅(qū)動DHT11 時(shí)序、ADC 采集、GPIO 控制、業(yè)務(wù)中間層濾波、閾值判斷、消抖、應(yīng)用層狀態(tài)機(jī)、串口命令、OLED 顯示。這樣分層的好處是你想改傳感器型號只需要換底層驅(qū)動業(yè)務(wù)邏輯不受影響想調(diào)報(bào)警靈敏度也只需要改閾值參數(shù)。2. 硬件原理圖設(shè)計(jì)傳感器選型與接口電路的關(guān)鍵細(xì)節(jié)原理圖是整個(gè)項(xiàng)目的“骨架”很多初學(xué)者用開發(fā)板能跑通程序一到自己畫板就懵原因就是沒搞懂傳感器模塊的核心電路是怎樣的。我詳細(xì)說說每個(gè)功能模塊的接口電路。2.1 MQ-2 煙霧傳感器加熱電阻和負(fù)載電阻的老問題MQ-2 屬于半導(dǎo)體氣敏傳感器內(nèi)部有兩個(gè)部分一個(gè)是加熱絲需要 5V 供電持續(xù)加熱讓敏感層達(dá)到工作溫度另一個(gè)是二氧化錫敏感層遇到還原性氣體時(shí)電導(dǎo)率會變化。等效來看敏感層就是一個(gè)阻值隨氣體濃度變化的電阻從潔凈空氣中的幾十千歐到高濃度煙霧下的幾千米歐。如果直接把這個(gè)變化的電阻接 ADC你沒法獲得穩(wěn)定的電壓。標(biāo)準(zhǔn)做法是把敏感層和一個(gè)固定負(fù)載電阻串聯(lián)形成一個(gè)分壓電路。我原理圖里用的是 10k 負(fù)載電阻電源 5V分壓節(jié)點(diǎn)接 STM32 的 ADC 輸入。公式很簡單[ V_{out} 5V \times \frac{R_{load}}{R_{sensor} R_{load}} ]潔凈空氣時(shí)傳感器阻值高分壓點(diǎn)電壓低大概在 0.3V 到 0.6V 之間煙霧濃度升高傳感器阻值下降分壓點(diǎn)電壓上升。實(shí)測在打火機(jī)燃?xì)鉄熿F下這個(gè)電壓能沖到 3.5V 以上。這里有兩個(gè)容易被忽略的坑第一MQ-2 加熱絲冷態(tài)電阻小上電瞬間電流接近 200mA如果電源設(shè)計(jì)余量不足會把 3.3V 電壓拉垮導(dǎo)致單片機(jī)復(fù)位。我在原理圖上給傳感器單獨(dú)加了 100uF 電解電容和 0.1uF 陶瓷電容做電源去耦同時(shí)讓 MQ-2 的 5V 和單片機(jī)的 3.3V 在電源入口處做好隔離。第二STM32 的 ADC 輸入引腳耐壓在 VDD 以內(nèi)不能直接把 MQ-2 的分壓點(diǎn)接進(jìn)去要先用兩個(gè)電阻把 5V 分壓成 3.3V 可用的范圍。我習(xí)慣在 ADC 前端加一個(gè)跟隨器或者至少加 RC 低通濾波R 取 10kC 取 0.1uF截止頻率在 160Hz 左右既能濾掉工頻干擾又不會拖慢響應(yīng)。2.2 火焰?zhèn)鞲衅髂K紅外探頭加比較器火焰?zhèn)鞲衅髂K通常是一塊小板上面有紅外接收管、LM393 比較器和一個(gè)電位器。它能檢測火焰發(fā)出的紅外光譜檢測到火焰時(shí)數(shù)字輸出引腳從高電平跳變到低電平或者反過來取決于模塊的設(shè)計(jì)。接入 STM32 很簡單模塊的 DO 引腳直接接一個(gè) GPIO 輸入即可。但我要提醒三點(diǎn)模塊的靈敏度電位器非常敏感擰一點(diǎn)點(diǎn)就有很大變化最好用萬用表量著輸出電平來調(diào)而不是憑感覺。紅外火焰?zhèn)鞲衅鲗﹃柟?、白熾燈、甚至遙控器發(fā)出的紅外信號也可能誤觸發(fā)。在實(shí)驗(yàn)室里如果窗戶附近有陽光直射誤報(bào)率會很高。我的處理方式是在軟件里加了連續(xù)多次確認(rèn)機(jī)制5 次采樣里至少 4 次檢測到火焰才確認(rèn)報(bào)警。火焰?zhèn)鞲衅鞯捻憫?yīng)速度極快探測距離卻有限一般只有幾十厘米到一兩米。所以它更適合做近距離確認(rèn)而不是大范圍掃描。原理圖上的接口電路很簡單VCC 接 5VGND 接地DO 接單片機(jī) PA0 這類帶外部中斷能力的引腳?？紤]到 LM393 輸出是開集結(jié)構(gòu)模塊上一般已經(jīng)自帶上拉電阻不需要額外加。2.3 DHT11 溫濕度傳感器上拉電阻真的不能省DHT11 是單總線數(shù)字傳感器數(shù)據(jù)線在空閑時(shí)是高電平設(shè)備通過拉低特定時(shí)長來產(chǎn)生起始信號和數(shù)據(jù)位。因?yàn)閿?shù)據(jù)線是開漏輸出所以必須在外部接一個(gè) 4.7k 到 10k 的上拉電阻。我見過不少同學(xué)在面包板上直接插 DHT11 不加上拉結(jié)果讀出來全是 0 或 255就是這個(gè)原因。DHT11 的精度不高溫度正負(fù) 2 度濕度正負(fù) 5% RH但做消防預(yù)警完全夠用。我要測的不是精確溫濕度而是溫度的變化趨勢。如果兩分鐘內(nèi)溫度連續(xù)上升超過 3 度就算煙霧傳感器和火焰?zhèn)鞲衅鞫紱]觸發(fā)我也會讓系統(tǒng)進(jìn)入“注意”狀態(tài)。DHT11 的供電范圍是 3.3V 到 5V原理圖上我直接接 3.3V避免電平不匹配的問題。數(shù)據(jù)引腳接 PC6中間串了一個(gè) 100 歐姆限流電阻萬一接線短路也不至于燒引腳。2.4 電源樹、繼電器驅(qū)動與原理圖檢查重點(diǎn)整塊板子的電源樹是這樣外部 12V 適配器接入經(jīng)過 DC-DC 降壓模塊輸出 5V5V 再經(jīng) AMS1117-3.3 輸出 3.3V。之所以不用 USB 的 5V 直接供電是因?yàn)槔^電器吸合瞬間電流很大USB 口容易掉壓。繼電器驅(qū)動部分我只強(qiáng)調(diào)一點(diǎn)繼電器線圈必須用三極管或 ULN2003 驅(qū)動不能直接接單片機(jī)引腳。STM32 GPIO 輸出能力有限帶不動繼電器線圈。我用的是一片 ULN2003 里面的其中一路單片機(jī) GPIO 接 ULN2003 輸入輸出端接繼電器線圈線圈兩端反并聯(lián)一個(gè) 1N4007 二極管用于吸收斷電時(shí)的反向電動勢。這個(gè)二極管不定不能漏否則 ULN2003 很容易被擊穿。畫完原理圖別急著畫 PCB先自查幾項(xiàng)用 ERC 檢查看有沒有懸空引腳、電源短路。每個(gè) IC 的電源引腳旁邊有沒有去耦電容我習(xí)慣每個(gè) IC 配一個(gè) 0.1uF。按鍵和復(fù)位電路是否接上拉或下拉確保默認(rèn)電平穩(wěn)定。繼電器觸點(diǎn)端和信號端是否拉開安全距離防止強(qiáng)電干擾弱電。我自己用嘉立創(chuàng)EDA畫這個(gè)項(xiàng)目的原理圖導(dǎo)出為 PDF 和圖片放到了開源倉庫的 Hardware 目錄里。嘉立創(chuàng)EDA 的好處是國產(chǎn)、免費(fèi)、庫元件齊全MQ-2 和 ULN2003 這些常用模塊直接搜就有封裝不用自己畫。3. 核心代碼實(shí)現(xiàn)從外設(shè)初始化到狀態(tài)機(jī)管理原理圖搞定后最花時(shí)間的其實(shí)是固件代碼。我按“先通串口再通傳感器最后做業(yè)務(wù)邏輯”的順序開發(fā)每一步都能驗(yàn)證結(jié)果不會到最后堆了幾百行代碼一出錯(cuò)不知道從哪找。3.1 工程搭建Keil5 環(huán)境與關(guān)鍵初始化配置我用的 IDE 是 Keil5芯片選擇 STM32F103C8。如果你是用標(biāo)準(zhǔn)外設(shè)庫開發(fā)需要先找到對應(yīng)的芯片支持包如果你用 STM32CubeMX 生成工程可以省去不少時(shí)鐘配置的麻煩。整個(gè)工程的初始化流程在 main 函數(shù)里按這個(gè)順序設(shè)置系統(tǒng)時(shí)鐘為 72MHz初始化 GPIOLED、蜂鳴器、繼電器、火焰?zhèn)鞲衅鬏斎氤跏蓟?ADC煙霧傳感器采樣通道初始化 USART1串口調(diào)試輸出初始化 DHT11 數(shù)據(jù)引腳初始化定時(shí)器用做狀態(tài)機(jī)的時(shí)基10ms 中斷GPIO 初始化這部分需要注意“哪些引腳是推挽輸出哪些是上拉輸入哪些是模擬輸入”。很多人把輸入輸出模式搞反或者該用上拉輸入的場景用了浮空輸入導(dǎo)致按鍵和傳感器讀數(shù)不穩(wěn)定。下面這段是標(biāo)準(zhǔn)外設(shè)庫的寫法void GPIO_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; // 使能時(shí)鐘 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOC, ENABLE); // PA1: 蜂鳴器輸出 GPIO_InitStructure.GPIO_Pin GPIO_Pin_1; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); // PA2: 繼電器控制輸出 GPIO_InitStructure.GPIO_Pin GPIO_Pin_2; GPIO_Init(GPIOA, GPIO_InitStructure); // PC4: LED1 紅色報(bào)警燈 GPIO_InitStructure.GPIO_Pin GPIO_Pin_4; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_Init(GPIOC, GPIO_InitStructure); // PA0: 火焰?zhèn)鞲衅鬏斎肷侠斎?GPIO_InitStructure.GPIO_Pin GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode GPIO_Mode_IPU; GPIO_Init(GPIOA, GPIO_InitStructure); }ADC 初始化時(shí)我用了通道 1也就是 PA1 等下PA1 已被蜂鳴器占用了。實(shí)際項(xiàng)目里我用的是 PA4 作為 ADC 輸入。這里需要修正代碼中 PA1 是蜂鳴器PA4 是煙霧傳感器 ADC 輸入。ADC1 的通道 4 對應(yīng) PA4。void ADC_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; ADC_InitTypeDef ADC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_ADC1, ENABLE); RCC_ADCCLKConfig(RCC_PCLK2_Div6); // ADC時(shí)鐘 72MHz / 6 12MHz // PA4 模擬輸入 GPIO_InitStructure.GPIO_Pin GPIO_Pin_4; GPIO_InitStructure.GPIO_Mode GPIO_Mode_AIN; GPIO_Init(GPIOA, GPIO_InitStructure); ADC_InitStructure.ADC_Mode ADC_Mode_Independent; ADC_InitStructure.ADC_ScanConvMode DISABLE; ADC_InitStructure.ADC_ContinuousConvMode DISABLE; ADC_InitStructure.ADC_ExternalTrigConv ADC_ExternalTrigConv_None; ADC_InitStructure.ADC_DataAlign ADC_DataAlign_Right; ADC_InitStructure.ADC_NbrOfChannel 1; ADC_Init(ADC1, ADC_InitStructure); ADC_RegularChannelConfig(ADC1, ADC_Channel_4, 1, ADC_SampleTime_55Cycles5); ADC_Cmd(ADC1, ENABLE); }3.2 ADC 采樣與煙霧濃度的換算邏輯STM32 的 ADC 是 12 位的讀出的原始值范圍 0 到 4095。要得到實(shí)際電壓用這個(gè)公式float voltage (float)adc_value * 3.3f / 4095.0f;這里用的參考電壓是 3.3V就是板載 VDDA。因?yàn)?MQ-2 輸出經(jīng)過分壓后最高也只能到 3.3V 附近不會超出 ADC 量程。但我不建議直接用單次采樣值做判斷因?yàn)?MQ-2 本身受溫度、濕度影響會有緩慢的基線漂移。我寫的函數(shù)會對煙霧電壓做 10 次滑動平均然后保存最近 30 秒的均值作為“當(dāng)前基線”。判斷邏輯是當(dāng)前值與基線之差超過設(shè)定閾值才報(bào)警這樣能抑制傳感器自身漂移帶來的影響。下面是工程里 ADC 采樣的核心函數(shù)uint16_t ADC_GetAverage(uint8_t times) { uint32_t sum 0; for (uint8_t i 0; i times; i) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) RESET); sum ADC_GetConversionValue(ADC1); } return (uint16_t)(sum / times); } float Smoke_GetVoltage(void) { uint16_t avg ADC_GetAverage(10); float voltage (float)avg * 3.3f / 4095.0f; return voltage; }閾值參數(shù)的設(shè)置是一個(gè)關(guān)鍵點(diǎn)。實(shí)際使用時(shí)我先讓系統(tǒng)“自學(xué)習(xí)”30 秒取這段時(shí)間的平均電壓作為正?；€然后在這個(gè)基線上加一個(gè)偏移量作為報(bào)警閾值。偏移量我做成兩個(gè)檔位預(yù)警檔 0.2V報(bào)警檔 0.6V。這個(gè)數(shù)值不是拍腦袋定的而是實(shí)測打火機(jī)在不點(diǎn)火狀態(tài)下靠近傳感器半米處電壓跳變約 0.15V 到 0.3V在點(diǎn)火狀態(tài)下模擬煙霧電壓跳變可以到 1V 以上。如果你的使用環(huán)境有酒精揮發(fā)、灰塵大等情況需要現(xiàn)場重新標(biāo)定。3.3 DHT11 溫濕度讀取時(shí)序延時(shí)精度決定成敗DHT11 單總線的時(shí)序要求比較嚴(yán)格但也沒有難到要用定時(shí)器捕捉去做的程度。關(guān)鍵是把微秒級延時(shí)函數(shù)寫好并且確認(rèn)主頻是 72MHz否則延時(shí)和時(shí)間不對應(yīng)。DHT11 的讀時(shí)序分三步主機(jī)拉低數(shù)據(jù)線至少 18ms然后釋放并延時(shí) 20us 到 40us。DHT11 響應(yīng)拉低 80us再拉高 80us。DHT11 連續(xù)發(fā)送 40 位數(shù)據(jù)每位數(shù)據(jù)由 50us 低電平和 26us 到 70us 的高電平組成高電平長代表“1”短代表“0”。40 位數(shù)據(jù)依次是濕度整數(shù)、濕度小數(shù)、溫度整數(shù)、溫度小數(shù)、校驗(yàn)和。校驗(yàn)和的算法是前四個(gè)字節(jié)相加低 8 位等于校驗(yàn)字節(jié)。代碼中我用的微秒延時(shí)是基于 SysTick 的若是標(biāo)準(zhǔn)庫就簡單點(diǎn)static void Delay_us(uint32_t us) { uint32_t ticks (uint32_t)(us * (SystemCoreClock / 1000000)); SysTick-LOAD ticks - 1; SysTick-VAL 0; SysTick-CTRL | SysTick_CTRL_ENABLE_Msk; while (!(SysTick-CTRL SysTick_CTRL_COUNTFLAG_Msk)); SysTick-CTRL ~SysTick_CTRL_ENABLE_Msk; }需要注意的是如果直接用 delay_ms 函數(shù)去模擬 DHT11 的微秒延時(shí)非常容易翻車。因?yàn)楹芏?HAL 庫的延時(shí)函數(shù)內(nèi)部用了循環(huán)變量編譯器優(yōu)化等級一變實(shí)際延時(shí)時(shí)長就變了。我建議 DHT11 的底層時(shí)序盡量用寄存器操作或者 SysTick 硬延時(shí)。3.4 消防邏輯狀態(tài)機(jī)消抖、連續(xù)確認(rèn)與分級響應(yīng)代碼最能體現(xiàn)一個(gè)嵌入式工程師水平的地方不是某個(gè)傳感器驅(qū)動寫得多巧妙而是整個(gè)業(yè)務(wù)邏輯組織得是否清晰。我用一個(gè)枚舉變量表示系統(tǒng)狀態(tài)typedef enum { STATE_NORMAL, STATE_WARNING, STATE_ALARM } SystemState;狀態(tài)遷移規(guī)則是這樣的正常狀態(tài)煙霧電壓低于預(yù)警閾值火焰無觸發(fā)溫度正常。LED 綠色常亮蜂鳴器關(guān)閉。預(yù)警狀態(tài)煙霧電壓超過預(yù)警閾值或者溫度單次上升超過 3 度。LED 橙色快閃蜂鳴器滴滴響繼電器不動作。報(bào)警狀態(tài)煙霧電壓超過報(bào)警閾值或火焰觸發(fā)且連續(xù)確認(rèn)或溫度連續(xù) 5 次采樣都超過 50 度。LED 紅色快閃蜂鳴器長響繼電器吸合切斷/聯(lián)動外部設(shè)備。關(guān)鍵在“消抖”上面。我用了一個(gè)計(jì)數(shù)器只有連續(xù) 5 次掃描每次掃描間隔 100ms都達(dá)到報(bào)警條件才真正進(jìn)入報(bào)警狀態(tài)。這 500ms 的確認(rèn)窗口能擋住絕大多數(shù)誤觸發(fā)包括偶爾的電磁干擾、人手在傳感器附近揮動導(dǎo)致的瞬時(shí)煙霧讀數(shù)跳變。狀態(tài)機(jī)的主循環(huán)結(jié)構(gòu)如下while (1) { smokeVoltage Smoke_GetVoltage(); fireLevel Flame_GetLevel(); tempHumidity DHT11_Read(); System_Scan(smokeVoltage, fireLevel, tempHumidity); int view State_View(); OLED_Update(view); UART_SendState(view); Delay_ms(100); }我挺建議狀態(tài)機(jī)里加一個(gè)“手動測試模式”。按下按鍵后進(jìn)入測試模擬煙霧和火焰信號強(qiáng)制讓系統(tǒng)進(jìn)入報(bào)警狀態(tài)驗(yàn)證蜂鳴器、繼電器能不能正常動作。消防設(shè)備的自檢非常重要不然真到關(guān)鍵時(shí)刻才發(fā)現(xiàn)蜂鳴器不響那就成了擺設(shè)。4. 仿真與調(diào)試無硬件也能跑的調(diào)試路徑以及仿真和實(shí)物的典型偏差很多人看到“仿真”就以為是 Proteus 跑個(gè)流水燈其實(shí)一套完整的消防預(yù)警系統(tǒng)仿真能幫你把硬件和軟件邏輯分別驗(yàn)證出問題的時(shí)候快速定位到是哪一層的鍋。4.1 用仿真搭出最小驗(yàn)證環(huán)境這個(gè)項(xiàng)目我提供了 Proteus 仿真文件包含 STM32F103C8、MQ-2用可變電阻替代、火焰?zhèn)鞲衅饔冒存I模擬、DHT11 模型、蜂鳴器和 LED。把這些元件連好載入 Keil 編譯出來的 hex 文件點(diǎn)擊運(yùn)行就能看到完整邏輯狀態(tài)變化。用可變電阻模擬 MQ-2 的思路很巧妙。將可變電阻的分壓點(diǎn)接入 ADC 輸入轉(zhuǎn)動旋鈕調(diào)整電壓值就能模擬煙霧濃度升高。實(shí)測下來把電壓調(diào)整到 1V 以上時(shí)系統(tǒng)會從正常狀態(tài)跳轉(zhuǎn)到預(yù)警超過 1.5V 后進(jìn)入報(bào)警。這樣不用真的在仿真里找煙霧模型?；鹧?zhèn)鞲衅鞯姆抡婺M更簡單我用一個(gè)按鍵接一個(gè)上拉電阻按鍵按下時(shí)引腳拉低模擬火焰觸發(fā)。DHT11 在 Proteus 里有現(xiàn)成模型但它的時(shí)序響應(yīng)和真實(shí)器件有區(qū)別后面我會講到。仿真還有一個(gè)用處是看串口輸出。我在代碼里用 USART1 每 100ms 輸出一行狀態(tài)數(shù)據(jù)內(nèi)容包括voltage,fire,temp,humidity,state。仿真里用虛擬終端直接觀察這些數(shù)據(jù)能夠很方便地驗(yàn)證狀態(tài)機(jī)遷移是否正確。4.2 仿真和實(shí)物的差異哪些結(jié)論只能信一半仿真通過不等于硬件沒問題我列幾條真實(shí)的踩坑記錄DHT11 模型在仿真里的時(shí)序太理想真實(shí)器件在某些批次上響應(yīng)時(shí)間會有偏差。代碼在仿真里一次就讀通到實(shí)物上卻經(jīng)常第一次讀失敗需要重試三次以上。最終我在代碼里加了一個(gè)“讀失敗自動重試”的邏輯每次讀取最多重試 5 次如果全部失敗就返回上一次的有效值。ADC 在仿真中沒有噪聲你會覺得 10 次平均和單次采樣沒區(qū)別。但實(shí)物上如果電源紋波大單次采樣的數(shù)值會上下跳動幾十個(gè)數(shù)。這就讓平均濾波算法的重要性體現(xiàn)出來了。仿真的蜂鳴器只是“響與否”的邏輯但實(shí)物要區(qū)分有源蜂鳴器和無源蜂鳴器。有源蜂鳴器給高電平就響無源蜂鳴器需要給脈沖才能響。如果你照仿真里直接給高電平實(shí)物可能發(fā)出奇怪的聲音。我在代碼里用宏定義區(qū)分了兩種蜂鳴器工程里默認(rèn)是有源蜂鳴器?；鹧?zhèn)鞲衅髟诜抡胬锞褪歉叩碗娖降珜?shí)物對紅外干擾非常敏感夏天靠近白熾燈都可能誤觸發(fā)。所以代碼里必須加確認(rèn)次數(shù)這是仿真中完全暴露不出來的問題。這些差異提醒我一件事仿真最大的價(jià)值是驗(yàn)證“邏輯設(shè)計(jì)得對不對”無法驗(yàn)證“硬件電路穩(wěn)不穩(wěn)定”。凡是涉及模擬信號采集、電源完整性、傳感器真實(shí)響應(yīng)特性的地方最終必須上實(shí)物測試。4.3 ST-Link 調(diào)試和串口打印的實(shí)際經(jīng)驗(yàn)開發(fā)階段我堅(jiān)持用 ST-Link 配合 Keil 進(jìn)行在線調(diào)試遇到程序跑飛、硬件故障能在調(diào)試點(diǎn)打斷點(diǎn)看變量數(shù)值效率遠(yuǎn)高于燒錄后瞎猜。在線調(diào)試時(shí)最常用的是 Watch 窗口把systemState、smokeVoltage、fireCount加進(jìn)去每次執(zhí)行到關(guān)鍵斷點(diǎn)時(shí)查看數(shù)值變化。很多時(shí)候問題一看變量就明白了比如發(fā)現(xiàn)smokeVoltage一直顯示 0.01V那不是代碼問題而是 ADC 配置錯(cuò)誤或者引腳接錯(cuò)。串口打印是我排查問題最依賴的手段。我在代碼里每個(gè)傳感器讀取函數(shù)執(zhí)行完都會打一行日志但這個(gè)日志只在調(diào)試模式下開啟正式發(fā)布時(shí)用#ifndef DEBUG關(guān)掉避免頻繁打印拖慢主循環(huán)。還有個(gè)細(xì)節(jié)是在線仿真時(shí)如果開了串口中斷DHT11 時(shí)序讀取很容易被中斷打亂導(dǎo)致讀時(shí)序失敗。因?yàn)?DHT11 對微秒級時(shí)序有要求中斷服務(wù)函數(shù)一旦占用了太多時(shí)間就會錯(cuò)過數(shù)據(jù)位。我最后的處理方案是DHT11 讀取期間暫時(shí)關(guān)閉串口接收中斷__disable_irq(); DHT11_ReadRaw(); __enable_irq();這種方法簡單粗暴但確實(shí)能解決 DHT11 在開關(guān)中斷環(huán)境下讀取失敗的老大難問題。代價(jià)是串口可能在那一兩個(gè)毫秒內(nèi)丟字符對調(diào)試日志來說完全可接受。5. 開源項(xiàng)目怎么組織別人才會真的跑得起來開源不是把代碼往 GitHub 一丟就完事的。我做嵌入式開源也有幾年了感受特別深的一點(diǎn)是一個(gè)項(xiàng)目的“可復(fù)現(xiàn)性”直接決定它有沒有價(jià)值。你覺得自己代碼寫得很清楚但別人拿到后可能沒有對應(yīng)型號的芯片包沒有原理圖不知道怎么接線第一印象就被勸退。5.1 倉庫目錄結(jié)構(gòu)與核心文件說明這個(gè)消防預(yù)警項(xiàng)目的倉庫結(jié)構(gòu)如下lab-fire-prevention/ ├── README.md ├── Doc/ │ ├── 系統(tǒng)框架圖.png │ ├── 接線圖.png │ └── 使用說明.md ├── Hardware/ │ ├── FirePrevention_Sch.pdf │ ├── FirePrevention_Sch.png │ └── FirePrevention_PCB/ ├── Firmware/ │ ├── Core/ │ │ ├── Inc/ │ │ └── Src/ │ ├── Drivers/ │ │ ├── BSP/ │ │ └── SYS/ │ ├── Project/ │ │ └── MDK-ARM/ │ └── README.md ├── Simulation/ │ ├── FirePrevention.pdsprj │ └── 仿真說明.md └── Tools/ ├── STM32_ST-LINK_Utility.md └── 燒錄腳本.batDoc目錄里必須有接線圖。不要只放原理圖因?yàn)樵韴D是給電氣工程師看的很多做軟件的同學(xué)看著原理圖還是不知道模塊怎么連。我特意畫了一個(gè)簡化的面包板接線圖用不同顏色標(biāo)注電源線和信號線方便新手照著插線。Firmware里的項(xiàng)目路徑是Project/MDK-ARM這樣別人用 Keil 打開時(shí)能直接找到工程文件。很多開源項(xiàng)目把.uvprojx文件放在一堆源碼的地底下找起來費(fèi)勁。Simulation目錄放 Proteus 工程文件并在說明文檔里寫清楚用什么版本打開、是否需要安裝傳感器模型庫、如何加載 hex 文件。這些細(xì)節(jié)能省掉一批人在環(huán)境搭建上花的時(shí)間。5.2 README 怎么寫才有用一份“五段式”模板我整理了一個(gè)適合自己的五段式 README 結(jié)構(gòu)第一段放項(xiàng)目效果動圖和功能列表讓人 30 秒內(nèi)看懂這是什么第二段是硬件清單并標(biāo)注參考價(jià)格第三段是接線說明配一張圖第四段是軟件環(huán)境準(zhǔn)備和編譯燒錄步驟第五段是校準(zhǔn)與常見問題。硬件清單部分我建議把“必選”和“可選”分開。比如模塊型號/規(guī)格數(shù)量參考價(jià)格必選/可選主控STM32F103C8T6 最小系統(tǒng)板115 元必選煙霧傳感器MQ-2 模塊110 元必選溫濕度傳感器DHT1115 元必選火焰?zhèn)鞲衅骷t外火焰?zhèn)鞲衅髂K18 元必選蜂鳴器有源蜂鳴器模塊13 元必選繼電器5V 單路繼電器模塊18 元可選顯示屏0.96 寸 OLED115 元可選仿真燒錄器ST-Link V2120 元必選編譯燒錄部分寫得像“傻瓜教程”也沒關(guān)系寧可啰嗦也不讓讀者卡住。我寫的步驟大致是安裝 Keil5 和 STM32F1 芯片支持包。打開Firmware/Project/MDK-ARM下的工程。選擇 ST-Link 調(diào)試器在 Settings 里選 SW 模式。編譯工程確認(rèn) 0 Error0 Warning。用 USB-TTL 或 ST-Link 連接板子點(diǎn)擊 Download。打開串口助手波特率 115200觀察狀態(tài)日志。5.3 常見問題排查表把踩過的坑寫進(jìn)去開源項(xiàng)目的 README 除了教人怎么跑通還要寫“跑不通怎么辦”。我把開發(fā)過程中遇到的高頻問題整理成表格實(shí)際效果也不錯(cuò)不少人反饋看表格就解決了問題。問題現(xiàn)象可能原因解決方式上電后 MQ-2 電壓持續(xù)上升傳感器預(yù)熱未完成等待 2-5 分鐘觀察是否穩(wěn)定DHT11 讀取失敗上拉電阻缺失或時(shí)序中斷檢查上拉電阻確保讀取期間關(guān)閉串口中斷火焰?zhèn)鞲衅黝l繁誤報(bào)環(huán)境紅外干擾調(diào)節(jié)靈敏度電位器修改確認(rèn)次數(shù)繼電器吸合瞬間單片機(jī)重啟電源余量不足換更大功率適配器繼電器模塊單獨(dú)供電仿真正常但實(shí)物不工作引腳定義不一致對照原理圖逐一檢查 GPIO 映射5.4 后續(xù)可以擴(kuò)展的方向開源之后不少人問過我能不能加更多功能我這里給出幾個(gè)我認(rèn)為比較實(shí)用的擴(kuò)展方向加一個(gè) ESP8266 模塊通過 MQTT 協(xié)議把報(bào)警信息推送到手機(jī)做遠(yuǎn)程預(yù)警。加一個(gè)鋰電池加充電管理讓設(shè)備在斷電后還能繼續(xù)工作一段時(shí)間用于臨時(shí)實(shí)驗(yàn)室或戶外場景。加一個(gè) OLED 菜單系統(tǒng)用按鍵設(shè)置報(bào)警閾值、查看歷史記錄而不是每次改閾值都要重新編譯燒錄。把 DHT11 換成品 AHT20 或 SHT30溫濕度精度提升一個(gè)量級響應(yīng)速度也更快但成本和代碼復(fù)雜度也會增加。增加多個(gè)傳感器節(jié)點(diǎn)用 RS485 或 LoRa 組網(wǎng)實(shí)現(xiàn)整棟樓級別的消防預(yù)警覆蓋。我個(gè)人在實(shí)際操作中的體會是這套系統(tǒng)真正的價(jià)值不是把某個(gè)具體傳感器用好而是提供一個(gè)“感知—判斷—響應(yīng)”的完整閉環(huán)框架。你換掉任何一環(huán)比如把 MQ-2 換成激光粉塵傳感器把 STM32 換成國產(chǎn) GD32把繼電器換成可控硅整體架構(gòu)依然成立。這也是我堅(jiān)持把它開源出來的原因希望后來者不要重走我在選型和調(diào)試上走過的彎路。最后提醒一句這類設(shè)備可以做安全輔助參考但實(shí)際消防驗(yàn)收和應(yīng)用還是要以合規(guī)消防設(shè)備和制度為準(zhǔn)。