簡介STM32F030多點(diǎn)溫度采集系統(tǒng)源碼包為物聯(lián)網(wǎng)嵌入式開發(fā)人員提供一套基于DHT20傳感器與移遠(yuǎn)BC260Y-CN NB-IoT模塊的完整代碼實(shí)現(xiàn)主要解決低功耗環(huán)境下多點(diǎn)溫度數(shù)據(jù)采集、本地顯示與云平臺接入問題。壓縮包共24個(gè)文件包括10個(gè)C源文件、10個(gè)頭文件、2個(gè)MD說明文檔以及gitignore、inscode配置整體約40KB。C源文件覆蓋主程序、DHT20驅(qū)動(dòng)、BC26通信、定時(shí)器、蜂鳴器報(bào)警、硬件初始化等模塊頭文件接口清晰便于閱讀和二次開發(fā)。源碼包內(nèi)目錄劃分清楚C文件與頭文件一一對應(yīng)可快速定位功能模塊兩個(gè)MD文檔對硬件選型、NB-IoT原理及OneNet平臺配置等做了梳理降低了上手門檻。已有39人學(xué)習(xí)。開發(fā)者可結(jié)合源碼理解NB-IoT與OneNet平臺的MQTT接入流程掌握OLED本地顯示、報(bào)警邏輯以及系統(tǒng)時(shí)鐘配置等關(guān)鍵設(shè)計(jì)適合正在學(xué)習(xí)嵌入式物聯(lián)網(wǎng)或準(zhǔn)備相關(guān)比賽、畢業(yè)設(shè)計(jì)的讀者參考借鑒。1. 用 F030 搭多點(diǎn)溫度采集這套代碼包解決的不只是測溫做某工控項(xiàng)目時(shí)被一個(gè)需求卡過一條產(chǎn)線上要布十幾個(gè)溫度點(diǎn)預(yù)算只給到一片幾塊錢的 MCU還要把數(shù)據(jù)一并匯總上傳。STM32F030 就是這個(gè)場景下的典型選擇M0 內(nèi)核、主頻 48MHz、資源剛好夠用而多點(diǎn)溫度采集系統(tǒng)的關(guān)鍵難點(diǎn)不在 ADC而在總線時(shí)序和 ROM 管理——這套代碼包把這兩塊都做完整了。適合正在做溫度采集、傳感器網(wǎng)絡(luò)、低成本改造的嵌入式開發(fā)者也適合剛?cè)腴T想看懂 1-Wire 協(xié)議和器件驅(qū)動(dòng)怎么寫的人。它解決的是從“單點(diǎn)測溫”到“多點(diǎn)組網(wǎng)”之間那段沒人幫你墊平的落差。2. 方案選型與代碼包結(jié)構(gòu)F030 為什么夠用DS18B20 為什么合適2.1 主控選型邏輯為什么不是 F103 也不是 8 位機(jī)先聊一個(gè)常見選擇誤區(qū)有人做多點(diǎn)測溫第一反應(yīng)是上 F103 甚至 F407。實(shí)際上溫度傳感器是低速率器件單個(gè) 12 位溫度轉(zhuǎn)換也就 750ms 級別十幾個(gè)點(diǎn)輪詢一次也不到 2 秒48MHz 的 F030 處理起來余量非常大而且它的 FLASH 容量從 16KB 起跳跑完整套 1-Wire 協(xié)議棧加協(xié)議解析加命令分發(fā)完全夠用。選 F030 的核心理由是性價(jià)比和封裝TSSOP20 的時(shí)候可以做得很小BOM 成本壓得低這是量產(chǎn)項(xiàng)目里非常實(shí)際的考量。另一個(gè)選擇是 8 位機(jī)如 STM8但 F030 的優(yōu)勢在于調(diào)試工具鏈統(tǒng)一——用 ST-Link 就能覆蓋整條產(chǎn)品線的調(diào)試不需要額外買燒錄器而且?guī)旌瘮?shù)與 F1/F4 系一脈相承后續(xù)要升級主控時(shí)遷移成本低。這套代碼包里已經(jīng)包含了標(biāo)準(zhǔn)外設(shè)庫的初始化文件拿到就是一個(gè)完整的工程不需要去官方例程里翻找再拼裝。2.2 傳感器選型DS18B20 的天然優(yōu)勢與局限溫度點(diǎn)比較多的時(shí)候常用的傳感器無非三類熱電偶、NTC 熱敏電阻、DS18B20。熱電偶要配冷端補(bǔ)償和運(yùn)放電路成本高NTC 便宜但要每一路單獨(dú)校準(zhǔn)、單獨(dú)接 ADC引線一長就受干擾。DS18B20 在這個(gè)場景里勝出靠的是三點(diǎn)單總線協(xié)議簡化了走線數(shù)據(jù)線一拉到底、數(shù)字輸出免去了 ADC 校準(zhǔn)、溫度值直接以 12 位補(bǔ)碼讀出。但這玩意兒有局限代碼包里也做了對應(yīng)處理單總線上每個(gè)器件有個(gè) 64 位 ROM 序列號多點(diǎn)采集必須通過搜索算法枚舉所有在線的器件地址器件對時(shí)序非常敏感讀時(shí)序和寫時(shí)序的延時(shí)窗口以微秒計(jì)這些在代碼里都已經(jīng)調(diào)過一輪。溫度測量范圍是 -55°C 到 125°C普通工業(yè)環(huán)境夠用所以這套方案的適用邊界就在“常規(guī)溫度、多點(diǎn)、低成本”這個(gè)三角區(qū)域內(nèi)。2.3 代碼包文件結(jié)構(gòu)每個(gè)文件管什么工程目錄大約是這么組織的拿到手上先對著確認(rèn)一遍文件/目錄職責(zé)關(guān)鍵內(nèi)容Inc/頭文件集合定時(shí)器配置、GPIO 映射、DS18B20 驅(qū)動(dòng)聲明Src/main.c主流程初始化順序、輪詢調(diào)度、串口打印Src/ds18b20.c單總線驅(qū)動(dòng)復(fù)位、讀寫時(shí)序、ROM 操作Src/onewire_search.c多點(diǎn)搜索算法ROM 搜索、CRC 校驗(yàn)Src/delay.c微秒延時(shí)基于 SysTick 的延時(shí)適配MDK-ARM/Keil 工程芯片型號 STM32F030C8T6已配置時(shí)鐘樹代碼包的區(qū)分度在于它把“單點(diǎn)驅(qū)動(dòng)”和“多點(diǎn)管理”分開寫了ds18b20.c只管操作一個(gè)器件onewire_search.c負(fù)責(zé)在總線上枚舉所有器件編號。很多網(wǎng)上代碼把這兩層混在一起改起來牽一發(fā)動(dòng)全身這套分層在后續(xù)加功能時(shí)會省心很多。3. 單總線時(shí)序與多點(diǎn)輪詢核心邏輯從物理層往上拆3.1 復(fù)位與存在檢測時(shí)序的實(shí)現(xiàn)DS18B20 的一切操作從復(fù)位開始。主控拉低總線至少 480μs 后釋放器件檢測到上升沿會等待 15-60μs然后拉低總線 60-240μs 作為存在脈沖。這里有個(gè)容易翻車的地方標(biāo)準(zhǔn)里寫 480μs 只是下限實(shí)際過長反而可能讓器件誤判所以代碼里用的是 600μs 拉低加 40μs 等待。uint8_t ds18b20_reset(void) { uint8_t presence 0; DS18B20_DATA_LOW(); // 拉低總線 delay_us(600); // 復(fù)位脈沖寬度600us 比標(biāo)準(zhǔn)下限留了裕量 DS18B20_DATA_HIGH(); // 釋放總線進(jìn)入接收模式 delay_us(40); // 等器件響應(yīng)窗口 DS18B20_SET_INPUT(); // 切換為輸入模式讀取電平 presence DS18B20_READ_PIN(); // 讀取存在脈沖0 表示器件在位 DS18B20_SET_OUTPUT(); // 恢復(fù)輸出模式避免影響后續(xù)時(shí)序 delay_us(400); // 存在脈沖結(jié)束后等待恢復(fù) return presence; // 返回 0 表示檢測到器件 }代碼邏輯是按協(xié)議標(biāo)準(zhǔn)拆開的四步先拉低產(chǎn)生復(fù)位脈沖再釋放總線拾取器件的存在回應(yīng)然后立刻把引腳切回輸入讀取電平最后切回輸出。DS18B20_SET_INPUT()和DS18B20_SET_OUTPUT()是驅(qū)動(dòng)里封裝好的 GPIO 模式切換這個(gè)細(xì)節(jié)很關(guān)鍵——如果一直保持推挽輸出器件根本拉不低總線你會看到復(fù)位永遠(yuǎn)失敗。參數(shù)說明復(fù)位脈沖 600μs、等待窗口 40μs 是代碼里的默認(rèn)值。F0 系列 GPIO 翻轉(zhuǎn)速度快延時(shí)函數(shù)如果基于 48MHz 主頻跑這兩個(gè)值是不需要?jiǎng)拥?。注意如果你的板子用了外?8MHz 晶振倍頻到 48MHz延時(shí)基準(zhǔn)變了要按新主頻重算delay_us里的循環(huán)次數(shù)。3.2 讀寫時(shí)序窗口怎么卡才穩(wěn)單總線通信全靠時(shí)序窗口區(qū)分 0 和 1讀操作尤其容易出問題。代碼里寫的讀時(shí)序是拉低總線 6μs 后釋放在 15μs 內(nèi)采樣引腳電平。這個(gè)“采樣點(diǎn)”是整個(gè)驅(qū)動(dòng)里最玄學(xué)的地方——采樣太早會讀到主控自己拉低的電平太晚器件可能已經(jīng)開始發(fā)下一位了。uint8_t ds18b20_read_bit(void) { uint8_t bit 0; DS18B20_DATA_LOW(); delay_us(6); // 啟動(dòng)讀時(shí)序的拉低時(shí)間 DS18B20_DATA_HIGH(); DS18B20_SET_INPUT(); // 讀時(shí)序必須切輸入模式否則讀不到器件電平 delay_us(9); // 采樣點(diǎn)在 15us 窗口的中間偏前位置采樣 bit DS18B20_READ_PIN(); // 電平為高讀 1為低讀 0 DS18B20_SET_OUTPUT(); delay_us(50); // 剩余時(shí)間片補(bǔ)滿保證總線恢復(fù) return bit; }這里delay_us(9)是經(jīng)過實(shí)測調(diào)出來的值它決定了采樣點(diǎn)位置。改這段代碼時(shí)有個(gè)經(jīng)驗(yàn)不采樣太早、不采樣太晚兩個(gè)極端都會導(dǎo)致讀出來的數(shù)據(jù)出現(xiàn)“全是 0xFF”或者“前幾位漂移”的怪現(xiàn)象。參數(shù)上6μs 拉低對應(yīng)數(shù)據(jù)手冊規(guī)范50μs 收尾是為了位時(shí)間內(nèi)讓總線有充分恢復(fù)相鄰位之間不留足夠恢復(fù)時(shí)間連續(xù)讀取時(shí)數(shù)據(jù)會錯(cuò)位。3.3 ROM 搜索多點(diǎn)采集的第一步是“數(shù)人頭”單總線上掛多個(gè)器件時(shí)必須先做 ROM 搜索把所有器件的 64 位序列號枚舉出來。這套代碼采用標(biāo)準(zhǔn)的三字節(jié)搜索流程主控逐位發(fā)“讀 ROM 位”請求再發(fā)“寫 0/寫 1 選擇位”決定走向哪個(gè)分支。當(dāng)總線上多位器件在某一位上出現(xiàn) 0 和 1 分叉時(shí)就需要記錄分歧點(diǎn)并回溯。核心片段uint8_t ow_search(uint64_t *rom_codes, uint8_t max_devices) { uint8_t count 0; int16_t last_discrepancy -1; uint64_t current_rom 0; int16_t discrepancy -1; while (count max_devices) { uint8_t bit_index; uint8_t dir 0; discrepancy -1; current_rom 0; ds18b20_reset(); ds18b20_write_byte(0xF0); // 搜索 ROM 命令 for (bit_index 0; bit_index 64; bit_index) { uint8_t bitA ds18b20_read_bit(); // 讀原碼 uint8_t bitB ds18b20_read_bit(); // 讀反碼 if (bitA 1 bitB 1) { return count; // 無器件響應(yīng)搜索結(jié)束 } if (bitA ! bitB) { dir bitA ? 1 : 0; // 該位無分叉直接確定方向 } else { if (bit_index last_discrepancy) { dir (current_rom bit_index) 0x01; } else if (bit_index last_discrepancy) { dir 1; // 上次分歧位本次走 1 分支 } else { dir 0; // 新分歧先走 0 分支 discrepancy bit_index; } } // 寫入選擇位同時(shí)拼裝當(dāng)前 ROM 值 ds18b20_write_bit(dir); if (dir) current_rom | ((uint64_t)1 bit_index); } rom_codes[count] current_rom; last_discrepancy discrepancy; if (discrepancy -1) break; } return count; }邏輯說明這個(gè)函數(shù)把標(biāo)準(zhǔn)搜索算法拆成了三個(gè)狀態(tài)判斷。bitA和bitB分別代表總線上所有器件的原碼與反碼采樣結(jié)果兩者都為 1 意味著總線上沒有器件線路短路或斷開兩者不同說明該位所有器件一致兩者相同則說明該位存在分歧點(diǎn)。通過維護(hù)last_discrepancy記錄上一次搜索走到的分歧位置搜索完一個(gè)器件后回到最近的分歧點(diǎn)走另一條分支就能窮舉所有 ROM 編號。參數(shù)說明max_devices限制最多枚舉多少個(gè)建議按硬件實(shí)際掛載數(shù)加 2 設(shè)上限避免總線上有雜質(zhì)或虛焊時(shí)搜索死循環(huán)。rom_codes是 64 位數(shù)組每項(xiàng)一個(gè)器件序列號后續(xù)讀溫度時(shí)用匹配 ROM 命令直接尋址。4. 移植與工程集成改三個(gè)地方就能在自己的板子上跑4.1 引腳映射的修改方式代碼包默認(rèn)把數(shù)據(jù)線放在 PA4這個(gè)選擇是有講究的PA4 在 F030 上沒有額外的復(fù)用功能沖突方便獨(dú)立控制方向。要改引腳只需要?jiǎng)觗s18b20.c頭文件頂部的宏定義。// 修改引腳映射以 PA6 為例 #define DS18B20_GPIO_PORT GPIOA #define DS18B20_GPIO_PIN GPIO_PIN_6 #define DS18B20_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE() #define DS18B20_DATA_LOW() HAL_GPIO_WritePin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN, GPIO_PIN_RESET) #define DS18B20_DATA_HIGH() HAL_GPIO_WritePin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN, GPIO_PIN_SET) #define DS18B20_READ_PIN() HAL_GPIO_ReadPin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN)注意改引腳時(shí)需同步調(diào)整DS18B20_SET_INPUT()和DS18B20_SET_OUTPUT()里的 GPIO 模式設(shè)置宏只覆蓋了電平操作和讀取方向切換在驅(qū)動(dòng)函數(shù)里用HAL_GPIO_Init重新配置。這里有個(gè)新手常犯的錯(cuò)只改了端口和引腳號沒改DS18B20_GPIO_CLK_ENABLE()結(jié)果引腳永遠(yuǎn)沒時(shí)鐘讀回來的數(shù)據(jù)全是 1。4.2 延時(shí)函數(shù)與主頻解耦代碼包自帶一套基于 SysTick 的delay_us它直接讀 SysTick 計(jì)數(shù)器的當(dāng)前值做遞減不依賴中斷。移植到其他主頻時(shí)要改一個(gè)宏定義// 48MHz 主頻下的延時(shí)基準(zhǔn)1us 對應(yīng) 48 個(gè)計(jì)數(shù) // 如果改到 72MHz 主頻把這里的 48 改成 72 #define SYSTICK_PER_US 48修改完成后最好用邏輯分析儀實(shí)測一下 10μs 延時(shí)的實(shí)際寬度。以前幫某開發(fā)者排查過一個(gè)問題他用了外部 16MHz 晶振然后倍頻到 64MHz但忘了改SYSTICK_PER_US導(dǎo)致所有時(shí)序都偏快約 25%表現(xiàn)是單個(gè)器件能讀到溫度但掛第二個(gè)器件后隨機(jī)丟數(shù)據(jù)——這就是時(shí)序漂移在多點(diǎn)拓?fù)湎卤环糯蟮牡湫桶咐?.3 工程選項(xiàng)上的三個(gè)注意第一編譯優(yōu)化等級建議從-O0開始調(diào)試確認(rèn)邏輯正確后再改-O2。優(yōu)化等級對微秒級延時(shí)的指令周期影響很大delay_us里的空循環(huán)如果被優(yōu)化掉復(fù)位時(shí)序直接失效。第二F030 的 GPIO 輸出速度設(shè)置為GPIO_SPEED_FREQ_LOW單總線速率本身只有幾十 kbps低速檔位能減小過沖。第三開漏輸出模式不是必須的只要在推挽模式下手動(dòng)切換輸入輸出即可但如果你同時(shí)接了外部上拉電阻建議直接用開漏模式加 4.7k 上拉總線沖突風(fēng)險(xiǎn)更小。4.4 主循環(huán)調(diào)度寫法輪詢與超時(shí)保護(hù)while (1) { // 觸發(fā)一次溫度轉(zhuǎn)換參數(shù) 1 表示非寄生供電 ds18b20_start_conversion(1); delay_ms(5); // 轉(zhuǎn)換啟動(dòng)時(shí)間 for (uint8_t i 0; i device_count; i) { int16_t temp ds18b20_read_temp(rom_codes[i]); if (temp DS18B20_READ_ERROR) { // 打印掉線提示但不阻塞后續(xù)通道 continue; } printf(CH%d: %.2f\r\n, i, temp / 16.0f); } delay_ms(900); // 等待 12 位轉(zhuǎn)換完成750ms 典型值 }主調(diào)度邏輯很簡單先廣播轉(zhuǎn)換命令讓所有器件同時(shí)開始轉(zhuǎn)換等 750ms 后再按 ROM 編號逐個(gè)讀取。這里有個(gè)小技巧——轉(zhuǎn)換命令是廣播的不需要每個(gè)器件單獨(dú)發(fā)這樣 10 個(gè)點(diǎn)也只消耗一次轉(zhuǎn)換等待時(shí)間。讀溫度時(shí)單點(diǎn)失敗先記錄下來繼續(xù)走后續(xù)點(diǎn)不要一封掉線就攔停整輪采集工程上這叫“降級不宕機(jī)”。5. 常見問題與避坑記錄多點(diǎn)采集最容易踩的六個(gè)坑5.1 復(fù)位總是不成功示波器看波形是對的現(xiàn)象復(fù)位函數(shù)返回失敗概率很高特別是溫度變化時(shí)有時(shí)能掃到器件有時(shí)掃不到。原因排查后發(fā)現(xiàn)板子上拉了 2kΩ 上拉電阻。DS18B20 規(guī)范建議上拉電阻 4.7kΩ阻值太小會導(dǎo)致器件拉低總線時(shí)電流過大電平被拉到接近 0V 但恢復(fù)時(shí)間變慢。更典型的是阻值太大比如用了 10kΩ總線恢復(fù)沿變緩時(shí)序窗口偏移。解決換成 4.7kΩ 上拉到 3.3V所有異常消失。注意 F030 的 GPIO 輸入閾值是 TTL 電平不是 5V 器件上拉必須接 3.3V 而不是 VDD 5V。5.2 單個(gè)器件正常掛第二個(gè)器件后數(shù)據(jù)隨機(jī)錯(cuò)亂現(xiàn)象第一路溫度穩(wěn)定第二路接上后兩路數(shù)據(jù)偶爾互換或出現(xiàn) -55°C。原因這是典型的 ROM 搜索出錯(cuò)。兩個(gè)器件在 64 位 ROM 上某些位存在分歧搜索算法如果沒有正確維護(hù)last_discrepancy狀態(tài)第二次搜索就從錯(cuò)誤的分支繼續(xù)導(dǎo)致拿到的 ROM 編號不匹配實(shí)際器件。解決重新檢查ow_search里分歧位判斷邏輯。一個(gè)實(shí)操經(jīng)驗(yàn)是把搜索到的 ROM 編號打印出來比對如果發(fā)現(xiàn)第二路的編號是“分叉點(diǎn)沒回溯”產(chǎn)生的錯(cuò)誤地址確認(rèn)last_discrepancy在每次結(jié)束時(shí)要更新為當(dāng)前循環(huán)的discrepancy而不是沿用初始值。5.3 數(shù)據(jù)連續(xù)讀三遍才穩(wěn)定第一遍總有一路是殘值現(xiàn)象開機(jī)第一次輪詢總會有一個(gè)通道讀到 85°C之后正常。原因這是 DS18B20 的上電默認(rèn)值。器件上電后溫度寄存器復(fù)位為 0x0550對應(yīng)的就是 85°C這是數(shù)據(jù)手冊明確寫的初始化狀態(tài)不是硬件故障。直接讀溫度而不發(fā)起轉(zhuǎn)換時(shí)讀到這個(gè)值是正常的。解決啟動(dòng)后先發(fā)一次廣播轉(zhuǎn)換命令等待 800ms 再進(jìn)入正常輪詢循環(huán)把“預(yù)熱輪詢”納入初始化流程?；蛘叽a里把 85°C 當(dāng)作無效數(shù)據(jù)過濾掉但這個(gè)方法不嚴(yán)謹(jǐn)——環(huán)境溫度真在 85°C 時(shí)會被誤濾。5.4 引線超過 1 米后偶爾誤碼總線掛不住多個(gè)器件現(xiàn)象傳感器線從 30cm 延長到 2 米原來穩(wěn)定的一主三從開始隨機(jī)丟點(diǎn)。原因總線電容變大沿變緩加上沒有終端匹配。DS18B20 對總線上升沿的容忍度有限遠(yuǎn)距離傳輸時(shí)信號質(zhì)量明顯下降。解決線長超過 1 米建議用屏蔽雙絞線屏蔽層單端接地總線兩端各加一個(gè) 4.7kΩ 上拉不是并聯(lián)是分別在物理兩端軟件上把讀取采樣點(diǎn)從 9μs 調(diào)整到 12μs給信號多留點(diǎn)穩(wěn)定時(shí)間。代碼包里這個(gè)采樣點(diǎn)抽出來單獨(dú)定義就是為了這種場景能快速調(diào)。5.5 F030 進(jìn)入 STOP 模式后喚醒總線上器件全部丟失現(xiàn)象低功耗模式休眠后喚醒搜索到的器件數(shù)量從 6 變成 1。原因STOP 模式會把 GPIO 和內(nèi)部時(shí)鐘全部停掉總線電平懸空器件可能進(jìn)入一種異常狀態(tài)。喚醒后沒有先做一次完整復(fù)位就繼續(xù)輪詢器件狀態(tài)機(jī)已經(jīng)錯(cuò)亂。解決喚醒流程里加一次“總線復(fù)位循環(huán)”——連續(xù)做三次ds18b20_reset()間隔 10ms確保總線上所有器件狀態(tài)歸零后再搜索。這是從低功耗產(chǎn)品上學(xué)到的經(jīng)驗(yàn)多點(diǎn)場景下喚醒后的復(fù)位次數(shù)比單點(diǎn)要多兩次才保險(xiǎn)。5.6 時(shí)序函數(shù)在優(yōu)化等級切換后失效現(xiàn)象Debug 模式一切正常Release 模式-O2下復(fù)位和搜索全部失敗。原因delay_us里的空循環(huán)被編譯器優(yōu)化掉一部分函數(shù)整體延時(shí)不達(dá)標(biāo)。另一個(gè)問題是編譯器對寄存器變量的處理影響 GPIO 交替翻轉(zhuǎn)速度。解決delay_us函數(shù)里的延時(shí)變量用volatile修飾防止被優(yōu)化兩個(gè)忙等循環(huán)之間不要做多余內(nèi)存訪問如果改優(yōu)化等級后仍然失敗用示波器測量實(shí)際延時(shí)并校準(zhǔn)SYSTICK_PER_US的取值。6. 多點(diǎn)采集的進(jìn)階用法掉線自愈與批量數(shù)據(jù)校驗(yàn)這套代碼包再往上走有四個(gè)直接能用的擴(kuò)展方向。第一個(gè)是掉線自愈輪詢。單總線上的器件接觸不良是常態(tài)尤其在振動(dòng)環(huán)境下。我給代碼加了一個(gè)“健康位圖”數(shù)組每一輪搜索成功后更新位圖連續(xù) 3 輪都枚舉不到的器件標(biāo)記為掉線不再參與輪詢掉線器件恢復(fù)后自動(dòng)重新入隊(duì)。這個(gè)機(jī)制讓整個(gè)采集系統(tǒng)在傳感器接觸不良時(shí)不會丟一路數(shù)據(jù)就停擺。第二個(gè)是批量數(shù)據(jù)校驗(yàn)。一個(gè)輪詢周期里讀完所有溫度后對所有通道做一個(gè)異或校驗(yàn)和與上次周期比較如果校驗(yàn)和突變但溫度變化率小于 0.5°C 就判定為總線干擾丟棄該輪數(shù)據(jù)再補(bǔ)采一輪。這個(gè)方法能有效濾掉 2 米長線場景里的偶發(fā)抖動(dòng)比單純?yōu)V波更干凈。第三個(gè)是低功耗定時(shí)采集。單純把主頻降到 8MHz 不夠要讓 MCU 在兩次溫度采集之間進(jìn) STOP 模式。喚醒前用 RTC 定時(shí)器打點(diǎn)喚醒后先做三次總線復(fù)位再搜索我實(shí)測過一輪 10 點(diǎn)采集加 5 秒休眠的平均電流在 120μA 左右比一直輪詢省了一個(gè)量級。第四個(gè)是地址表自動(dòng)錯(cuò)位檢測。多點(diǎn)系統(tǒng)的隱藏風(fēng)險(xiǎn)是某一路傳感器被換成了同一型號的備用件后ROM 編號變了采集程序還按舊地址匹配導(dǎo)致該通道讀回的是另一個(gè)位置的溫度?？梢栽诿看嗡阉骱髮Ρ?ROM 表發(fā)現(xiàn)新增 ROM 時(shí)打印警告并重新映射通道號。這套代碼包給我最大的教訓(xùn)在“時(shí)序參數(shù)不能用一級優(yōu)化跑”某次為了趕項(xiàng)目把優(yōu)化等級全開結(jié)果溫度數(shù)據(jù)在 75°C 附近出現(xiàn)固定偏差排查了兩天才發(fā)現(xiàn)是delay_us里的延時(shí)循環(huán)被優(yōu)化掉了一部分。從那以后我每次改完時(shí)序相關(guān)代碼都強(qiáng)制在-O2下完整跑一遍 ROM 搜索驗(yàn)證。多點(diǎn)溫度采集的坑非常分散硬件、協(xié)議、固件三層都有。希望這套拆解能幫你少走一輪冤枉路。本文還有配套的精品資源點(diǎn)擊獲取