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