簡介本資源是一套基于STM32F103平臺實現(xiàn)的高完成度智能家居系統(tǒng)項目專為計算機、電子信息、自動化等專業(yè)學生設計適用于畢業(yè)設計、課程設計及期末大作業(yè)等實踐場景尤其適合缺乏嵌入式項目經(jīng)驗但希望快速上手的初學者。項目經(jīng)導師指導并獲99分高分評審代碼完整可直接編譯運行配套PDF報告文檔詳述設計思路、硬件選型、通信協(xié)議與功能測試過程。壓縮包共332個文件涵蓋40個C源碼、43個頭文件.h、78張界面與電路截圖.png、41個前端交互腳本.js、24個Vue組件及HTML/CSS頁面另有Keil工程配置文件、Hex固件、APK安卓控制端、調試腳本bat及編譯中間文件整體容量100.83MB。資源已獲92人學習下載內容組織清晰模塊劃分明確含傳感器采集、WiFi通信、本地控制、手機APP聯(lián)動等核心功能附帶實操演示MP4與詳細注釋顯著降低調試門檻。1. 畢設題目怎么定才不算爛大街需求拆解與選題思路每年畢業(yè)季STM32 智能家居這個題目幾乎能占到嵌入式方向畢設的半壁江山。你可能覺得這題目太大眾化了但說實話大眾化有大眾化的好處參考資料多、方案成熟、不容易翻車。關鍵在于你怎么在這個老框架里做出自己的差異化而不是交一個誰都能寫出來的萬能智能家居。我拿到這個題目后的第一件事不是急著寫代碼而是先做需求拆解。所謂智能家居系統(tǒng)本質上就是一個以 MCU 為核心的嵌入式數(shù)據(jù)采集、處理、顯示與控制系統(tǒng)。拆開來看至少包含四大塊環(huán)境感知、人機交互、執(zhí)行控制、數(shù)據(jù)通信。環(huán)境感知對應的是溫濕度、光照、煙霧或空氣質量這類傳感器人機交互對應按鍵、屏幕或者手機 App 界面執(zhí)行控制對應繼電器、蜂鳴器、LED 這類被控對象數(shù)據(jù)通信則是決策數(shù)據(jù)指令在各個環(huán)節(jié)之間流轉的通道。這個思路確定了你的題目方向就不會散。很多同學上來直接說我要做一個智能家居系統(tǒng)結果做完只有一塊板子加兩個傳感器報告寫得再長也撐不起這個題目。如果你想拿高分我建議在智能二字上做文章。比如加上本地語音識別模組做語音開關燈或者用 ESP8266 打通手機遠程控制再或者增加一個簡單的 OLED 顯示界面展示環(huán)境數(shù)據(jù)曲線。這些點都能讓評審老師一眼看出你在系統(tǒng)設計上是花了心思的而不是僅僅做完一個最小原型。題目拆解完成后下一步就是技術選型。主控芯片的選擇上STM32F103C8T6 是最主流的方案這顆芯片價格便宜、資料多、引腳夠用而且市面上幾乎所有開發(fā)板都圍繞它做教程。如果你用的是正點原子或者野火的板子很多外設驅動可以直接參考例程改寫。有一點需要提醒開發(fā)板自帶的資源測評報告里不要直接寫使用了正點原子/野火開發(fā)板要寫你自己設計的電路和外設接法這是很多同學在報告查重和答辯中被問倒的重災區(qū)。用到的傳感器和模塊方面我建議選 DHT11 或 DHT22 做溫濕度采集、BH1750 或光敏電阻做光照檢測、MQ-5 或 MQ-135 做空氣質量監(jiān)測、HC-SR501 做人體紅外感應再加上一個 OLEDSSD1306 驅動做本地顯示繼電器模組控制燈光或風扇。這套組合的成本不高但覆蓋了采集、顯示、控制三要素邏輯閉環(huán)也很清晰。如果你有富余預算可以加一個 ESP8266 模組走 MQTT 協(xié)議連上云平臺這樣就能在手機 App 端看到實時數(shù)據(jù)實現(xiàn)遠程控制這個加分項。2. 系統(tǒng)框架怎么搭硬件選型、通信協(xié)議與軟件分層框架設計是整個項目的地基地基打不好后面跑起來全是問題。我從硬件選型、通信協(xié)議和軟件架構三個維度拆開來講。2.1 硬件選型清單與理由拿我的方案來說核心物料如下模塊型號接口作用主控STM32F103C8T63.3V/GPIO核心處理單元溫濕度DHT11/DHT22單總線 GPIO環(huán)境溫濕度采集光照BH1750 數(shù)字光強I2C光照強度采集空氣質量MQ-135ADC(PA1)有害氣體檢測人體感應HC-SR501GPIO 外部中斷人來自動開燈顯示OLED 0.96寸 SSD1306I2C本地數(shù)據(jù)顯示繼電器2路/4路繼電器模組GPIO控制燈光/風扇無線ESP8266-01SUSART2上云/手機控制這套選型有幾個細節(jié)值得說DHT11 雖然精度一般但勝在協(xié)議簡單適合把精力放在系統(tǒng)集成上BH1750 是 I2C 接口能和 OLED 共用一條 I2C 總線節(jié)省引腳MQ-135 輸出的是模擬電壓正好用 STM32 的 ADC 采集順便把 ADC 多通道掃描的知識點帶進去HC-SR501 輸出電平變化用外部中斷處理最合適還能體現(xiàn)你在中斷設計上的能力。2.2 通信協(xié)議選擇I2C、單總線、USART 與 MQTT 的取舍這個項目里你至少要接觸三種通信方式這是報告的天然素材。I2C 總線用于連接 BH1750 和 OLED。兩個設備共用一個 I2C 外設地址不同STM32 的硬件 I2C 在 F1 系列上偶爾有 Bug尤其在某些低功耗模式下所以我習慣用軟件模擬 I2C管腳隨便配時序自己控制代碼雖然多了幾十行但穩(wěn)定性反而更好。當然如果你想展示自己會用硬件 I2C 且處理過總線鎖死問題也可以嘗試硬件方式然后在報告里寫明你是如何用超時機制避免死鎖的——這個細節(jié)非常加分。單總線用于 DHT11。單總線的關鍵點是時序要嚴格主機拉低總線發(fā)起起始信號后必須精確延時 18ms 以上然后釋放總線等待傳感器響應。DHT11 返回 40 位數(shù)據(jù)8 位濕度整數(shù)、8 位濕度小數(shù)、8 位溫度整數(shù)、8 位溫度小數(shù)、8 位校驗和。讀取時每一位的時序要用延時配合 GPIO 輸入完成這也是經(jīng)常出 Bug 的地方。USART 用于 ESP8266 通信。ESP8266 出廠默認波特率通常是 115200注意和 STM32 的串口波特率匹配。使用 AT 指令集進行配置常見流程是先 AT 測試指令通不通 → 設置 Wi-Fi 模式 → 連接路由器 → 開啟透傳模式 → 建立 TCP 連接。這套流程每一步都要等到模塊返回 OK 或具體狀態(tài)碼再繼續(xù)不能悶頭往下發(fā)。MQTT 協(xié)議則是在 ESP8266 與云平臺之間使用。云平臺是你選擇的物聯(lián)網(wǎng)平臺設備端通過 MQTT 發(fā)布主題比如dev/room1/temp手機端訂閱該主題即可實時收到數(shù)據(jù)。如果不想自己搭服務器直接用公共的 MQTT Broker 也行記得改默認端口或者干脆用平臺自帶的移動端調試工具查看數(shù)據(jù)。2.3 軟件分層不要把業(yè)務邏輯全部寫進 main 函數(shù)很多新手愛把整個項目全都堆在 main.c 里。傳感器初始化、輪詢、按鍵掃描、屏幕刷新、串口打印全塞在一起幾百行代碼下來別說答辯了自己調試都頭疼。軟件分層這件事能做到的同學基本都是亮眼的存在。我的代碼結構長這樣SmartHome/ ├── Core/ │ ├── Inc/ │ └── Src/ │ ├── main.c │ ├── gpio.c │ ├── usart.c │ ├── i2c.c軟件模擬 │ └── adc.c ├── Drivers/ │ ├── BSP/ │ │ ├── bsp_led.c │ │ ├── bsp_relay.c │ │ ├── bsp_key.c │ │ └── bsp_beep.c │ └── Middleware/ │ ├── dht11.c │ ├── bh1750.c │ ├── mq135.c │ ├── ssd1306.c │ ├── esp8266.c │ └── mqtt.c ├── App/ │ ├── app_sensor.c傳感器數(shù)據(jù)采集與濾波 │ ├── app_control.c邏輯控制、閾值判斷、狀態(tài)機 │ └── app_display.cUI更新 └── Doc/ ├── 系統(tǒng)框圖 ├── 原理圖 └── 狀態(tài)機說明這樣分層的好處是硬件驅動放在 BSP 和 Middleware 層業(yè)務邏輯放在 App 層。以后你想給某個傳感器換型號比如 DHT11 換成 DHT22只需要改對應的驅動文件而 App 層的控制代碼完全不用動。答辯時老師問你你系統(tǒng)擴展性怎么樣你就可以直接拿這個結構說事。3. 硬件電路設計主控、傳感器接入與 OLED 顯示硬件這一塊很多同學會直接買一塊開發(fā)板插幾個傳感器模塊然后就開始寫軟件。這樣確實省事但報告里就沒什么硬件知識可以寫了。想要拿高分少說也要畫一個自己的最小系統(tǒng)板原理圖再不濟也要把傳感器怎么接、為什么這么接說得頭頭是道。3.1 主控最小系統(tǒng)復位電路、晶振與 BOOT 設置STM32F103C8T6 的最小系統(tǒng)包含四部分電源、晶振、復位、BOOT。電源部分用 AMS1117-3.3 把 5V 穩(wěn)壓到 3.3V輸入輸出各并一個 10uF 和 100nF 電容去耦。晶振用 8MHz 無源晶振兩個 20pF 負載電容這個 8MHz 是 HSE內部 PLL 倍頻到 72MHz 供系統(tǒng)使用。復位電路就一個 10K 上拉電阻加一個按鍵電容。BOOT0 下拉到 GND從 Flash 啟動BOOT1 隨意。這里有個大坑如果你用的是最小系統(tǒng)板而不是開發(fā)板每次燒錄程序后需要手動復位才能運行。很多同學第一次用 ST-Link 下載后發(fā)現(xiàn)程序不跑就是這個原因。解決方法是把 ST-Link 的 RST 引腳也連到板子的 NRST 上燒錄后 ST-Link 會自動復位運行。相關熱詞里有 stm32 st-link utility 和 stm32 禁用jtag這兩個點都是調試中會碰到的坑后面我再展開。3.2 傳感器接入電路的細節(jié)DHT11 的數(shù)據(jù)線需要接一個 4.7K 上拉電阻到 3.3V。別小看這個電阻沒有它單總線的高電平會拉不起來讀取的數(shù)據(jù)全是 0xFF。另外 DHT11 的數(shù)據(jù)腳一定要選一個支持推挽輸出的引腳不推薦用開漏模式去靠外部上拉驅動。BH1750 和 OLED 掛在同一條 I2C 總線上SDA 和 SCL 都需要接 4.7K 上拉電阻。如果你用的是現(xiàn)成模塊模塊上通常已經(jīng)有上拉電阻了就不用額外加自己畫板子的話千萬別漏。還有個小細節(jié)BH1750 的 ADDR 引腳如果接低電平I2C 地址是 0x23接高電平是 0x5C。OLED 一般固定是 0x3C所以兩者不會沖突。這個地址區(qū)分問題在報告里寫一下就很有含金量。MQ-135 模塊有一個模擬輸出AOUT和一個數(shù)字輸出DOUT。接 STM32 的 ADC 時用 AOUTDOUT 單獨接一個 GPIO 做閾值報警也行。不過我更推薦用 ADC 實時采集然后在軟件里做閾值判斷這樣系統(tǒng)更靈活因為你不需要物理調整模塊上的電位器來改報警閾值。MQ-135 上電后需要預熱幾分鐘前幾秒讀數(shù)會偏大軟件里可以做個上電延時丟棄前面幾次采樣。HC-SR501 模塊上有兩個可調電位器一個調靈敏度檢測距離一個調延時時間。接 MCU 的引腳最好設置為上拉輸入或者外部中斷模式。模塊輸出高電平時表示檢測到人體低電平表示沒有。3.3 執(zhí)行器接口繼電器與蜂鳴器繼電器模組是低電平觸發(fā)還是高電平觸發(fā)取決于模塊上的光耦設計。市面上常見的 1 路/2 路繼電器模組大多是低電平觸發(fā)IO 拉低繼電器吸合。這個一定要看模塊的絲印或者原理圖別想當然。如果你用高電平觸發(fā)去寫邏輯結果發(fā)現(xiàn)繼電器不工作排查半天。繼電器線圈是感性負載斷電瞬間會產(chǎn)生反向電動勢所以繼電器模組上必須有續(xù)流二極管。如果你用的是現(xiàn)成模組可以不管自己畫板子必須在繼電器線圈兩端并聯(lián)一個 1N4007 二極管。STM32 的 GPIO 輸出電流能力有限最大 25mA不能直接驅動繼電器線圈模組上一般已經(jīng)帶了 PNP/NPN 三極管或 ULN2003 驅動電路這也是為什么大家都愛用繼電器模組而不是裸繼電器。蜂鳴器分有源和無源兩種有源蜂鳴器通電就響無源蜂鳴器需要給不同頻率的方波才能發(fā)出不同音調。畢設項目里用有源蜂鳴器就夠了接一個 NPN 三極管比如 S8050驅動。引腳輸出高電平三極管導通蜂鳴器響。注意蜂鳴器聲音很響如果放在宿舍測試建議先用杜邦線接一個按鍵把蜂鳴器報警功能做成手動觸發(fā)測試避免一直吵室友。3.4 OLED 顯示與 UI 布局OLED 0.96 寸 128x64 分辨率SSD1306 控制器I2C 接口。你需要把官方 SSD1306 驅動移植過來通常包括初始化、設置光標、顯示字符/字符串、清屏等函數(shù)。4 針 I2C 接法GND、VCC3.3V、SCL、SDA。如果是 7 針 SPI 版本就復雜一些不建議選。UI 布局方面我的建議是做一個簡單的多頁面切換而不是一頁把所有數(shù)據(jù)塞滿。第一頁顯示溫濕度和空氣質量第二頁顯示燈光/風扇狀態(tài)和控制方式自動/手動第三頁顯示 Wi-Fi 連接信息。按鍵切換頁面KEY1 翻頁KEY2 切換自動/手動模式KEY3 手動模式下切換繼電器。如果你想讓 OLED 顯示的東西更出彩可以研究一下顯示中文字庫通常需要自己取?；蛘弋媯€簡單的曲線圖把溫濕度歷史變化畫出來。這些在答辯時都是實打實的亮點。4. 核心代碼實現(xiàn)從初始化到控制閉環(huán)代碼是項目的靈魂。這部分我不給你貼完整的工程代碼而是把核心模塊的實現(xiàn)思路和關鍵代碼片段講清楚讓你拿到后能直接照著改。4.1 系統(tǒng)時鐘與 GPIO 初始化STM32F103 上電默認使用 HSI8MHz 內部高速時鐘如果你不配置時鐘樹主頻只有 8MHz外設運行會很慢。使用 STM32CubeMX 可以圖形化配置HSE 選擇 Crystal/Ceramic ResonatorPLL 倍頻系數(shù) 9 倍System Clock 設為 72MHz。GPIO 初始化注意點繼電器、LED、蜂鳴器推挽輸出初始電平為不動作狀態(tài)繼電器斷開、LED 滅、蜂鳴器不響按鍵上拉輸入按下為低電平可以開啟內部上拉省去外部電阻DHT11 數(shù)據(jù)線在讀取過程中要切換輸入/輸出方向建議用宏定義封裝一下 GPIO 模式切換OLED/BH1750 的 I2C 引腳開漏輸出 外部上拉或者直接推挽輸出也行軟件 I2C 無所謂4.2 多傳感器采集與濾波算法傳感器數(shù)據(jù)采集不是 read 一下就完了。DHT11 的時序要求很嚴格我之前提到過 40 位數(shù)據(jù)每位高電平的時間長度決定該位是 0 還是 1。核心讀取函數(shù)大致邏輯uint8_t DHT11_ReadByte(void) { uint8_t i, data 0; for (i 0; i 8; i) { // 等待低電平結束開始位 while (DHT11_PIN_READ() 0); // 延時 30us delay_us(30); if (DHT11_PIN_READ() 1) { data | (0x80 i); // 高位在前 } // 等待高電平結束 while (DHT11_PIN_READ() 1); } return data; }這段代碼的關鍵在于 30us 的判斷閾值。DHT11 的數(shù)據(jù)位0高電平約 26~28us1高電平約 70us。你延時到 30us 左右再去讀引腳電平讀到 1 說明是1讀到 0 說明是0。這個延時可以用 SysTick 實現(xiàn)也可以用簡單的循環(huán)空轉。但注意編譯優(yōu)化級別別開太高否則循環(huán)會被優(yōu)化掉導致延時失效。MQ-135 的 ADC 采集用 STM32 的 ADC1 通道。F103 的 ADC 是 12 位分辨率參考電壓 3.3V所以采集值 V ADC_Value / 4096 * 3.3。你拿到的電壓值還需要換算成 PPM 或者直接做閾值比較。很多項目里并沒有把電壓轉成真正的 PPM而是直接用電壓值或者一個比例值來判斷空氣質量好壞。這也沒關系報告里說清楚你的判斷邏輯就行。數(shù)據(jù)濾波也是一個加分點。我用了滑動平均濾波維護一個長度為 5 或 10 的緩沖區(qū)每次采樣后將新值放入隊尾去掉隊首然后求平均值。這樣做能明顯減少 MQ-135 輸出值的波動顯示在 OLED 上的曲線也會平滑很多。代碼很簡單uint16_t MovingAverage(uint16_t newValue, uint16_t *buffer, uint8_t len, uint8_t *index) { buffer[*index] newValue; *index (*index 1) % len; uint32_t sum 0; for (uint8_t i 0; i len; i) sum buffer[i]; return sum / len; }4.3 業(yè)務邏輯狀態(tài)機設計智能家居的智能體現(xiàn)在哪就是系統(tǒng)能根據(jù)傳感器數(shù)據(jù)自動做出決策而不是只能手動操作。我用了一個簡單狀態(tài)機來管理自動模式狀態(tài) IDLE空閑實時采集并顯示數(shù)據(jù)狀態(tài) LIGHT_ON檢測到人體HC-SR501 高電平或光照低于閾值比如 50 lux自動開燈狀態(tài) FAN_ON溫度高于 28℃ 或 MQ-135 讀數(shù)超過閾值自動打開風扇狀態(tài) ALARM溫濕度或空氣質量超過安全范圍蜂鳴器報警狀態(tài)機的好處是邏輯清晰不會出現(xiàn)多條 if 語句互相沖突的情況。比如你拿多條 if 去判斷開燈和開風扇很容易出現(xiàn)一個動作被重復執(zhí)行。用狀態(tài)機后每次進入一個狀態(tài)只執(zhí)行一次對應的動作拉高/拉低 GPIO狀態(tài)不切換就不重復執(zhí)行。void App_Control_Update(void) { switch (currentState) { case STATE_IDLE: if (人體檢測到 光照不足) 狀態(tài)切換到 LIGHT_ON; else if (溫度過高 || 空氣質量差) 狀態(tài)切換到 FAN_ON; else if (溫濕度超限 || 空氣嚴重污染) 狀態(tài)切換到 ALARM; break; case STATE_LIGHT_ON: 執(zhí)行開燈動作; 進入 LIGHT_ON 后 如果條件不滿足 恢復 IDLE; break; // 其他狀態(tài)同理 } }手動模式就簡單多了按鍵直接翻轉繼電器狀態(tài)并通過 OLED 顯示當前狀態(tài)。自動/手動切換用 KEY2 實現(xiàn)每次按鍵在兩種模式之間翻轉。4.4 ESP8266 上云AT 指令解析與數(shù)據(jù)上報如果你要給項目加分ESP8266 是一個性價比極高的選擇。ESP8266-01S 引腳比較少但接 STM32 的 USART2 足夠。接線VCC 接 3.3V注意 ESP8266 的峰值電流很大最好單獨供電不要和 STM32 共用同一個 3.3V LDO 輸出否則 Wi-Fi 連上一瞬間電壓跌落會導致系統(tǒng)復位GND 共地RX 接 STM32 的 TXTX 接 STM32 的 RX。ENCH_PD引腳必須拉高。AT 指令發(fā)送要注意每個指令后帶\r\n。我封裝了一個ESP8266_SendCmd()函數(shù)發(fā)送指令后等待模塊返回OK或ERROR超時 2 秒后重試。連接云平臺的流程ATRST ATCWMODE1 ATCWJAPWiFi名稱,WiFi密碼 ATCIPMUX0 ATCIPSTARTTCP,MQTT服務器地址,端口 ATCIPMODE1 ATCIPSEND之后所有發(fā)到串口的數(shù)據(jù)都會被透傳到服務器。注意千萬別漏了透傳模式設置否則每次發(fā)送數(shù)據(jù)都要先發(fā) ATCIPSEND 再等提示符。云端這一側你可以用現(xiàn)成的物聯(lián)網(wǎng)平臺它支持自定義數(shù)據(jù)流和設備管理。創(chuàng)建一個智能家居項目添加溫度、濕度、光照、空氣質量四個數(shù)據(jù)流然后生成一個設備 ID 和 API Key。ESP8266 通過 HTTP POST 或者 MQTT 上報數(shù)據(jù)到云端然后手機 App 或網(wǎng)頁端就能看到實時數(shù)據(jù)。HTTP 方式最簡單通過 AT 指令發(fā)一個 HTTP 請求把 JSON 數(shù)據(jù) POST 上去但每次請求都要建立/斷開 TCP 連接效率低一些。MQTT 方式需要自己在 MCU 端實現(xiàn) MQTT 客戶端協(xié)議或者使用現(xiàn)成庫稍微復雜但更符合物聯(lián)網(wǎng)場景。相關熱詞里有個 stm32 http庫 和 stm32 作為主機掛載U盤前者可以用在這個場景后者我建議不要輕易嘗試F103 的 USB 外設做 Host 掛 U 盤坑太多了畢設時間不夠用。5. 聯(lián)調階段最容易翻車的地方我的踩坑記錄說實話這個項目寫代碼可以很快但聯(lián)調階段才是真正燒時間的地方。我把自己踩過的大坑列出來希望你提前避開。5.1 STM32 被鎖死與 JTAG 禁用問題相關熱詞里出現(xiàn)了 stm32 禁用jtag 和 stm32 st-link utility這倆是真有關系。如果你在代碼里把 PB3、PB4、PA15 這些引腳配置成了普通 GPIO 輸出而這些引腳恰恰是 JTAG 接口的部分信號那么恭喜你下次燒錄程序時 ST-Link 可能連不上芯片了。具體原因是STM32F103 上電后PB3JTDO、PB4NJTRST、PA15JTDI默認復用為 JTAG 調試功能。如果你把它們當作普通 GPIO 使用必須先把 AFIO 寄存器里的 JTAG 配置改成 SW-DP 模式GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)。但是如果你在代碼里執(zhí)行完這個操作后程序沒跑起來或者進入了死循環(huán)JTAG 已經(jīng)被關閉了ST-Link 就再也連不上了。解決辦法是按住板子上的復位鍵在 ST-Link Utility 里點擊 Connect然后再松開復位鍵在芯片啟動早期把調試口搶回來。具體操作是先連接 ST-Link目標板保持復位狀態(tài)點擊 Connect 的同時釋放復位。如果這招不行就只能用串口 ISP 方式全片擦除了。經(jīng)驗教訓不要在項目初期就急著禁用 JTAG。如果你必須用 PB3/PB4/PA15 做 GPIO先把代碼其他部分調通最后再啟用這些引腳并且確保程序不會一上電就死機。我的做法是加一個延時 500ms 再禁用 JTAG這樣每次復位后至少還有 500ms 的調試窗口萬一出了問題也能搶連。5.2 STM32 延時函數(shù) delay 卡死熱詞里有 stm32 延時函數(shù)delay卡死我猜你也遇到過。最常見的卡死原因是 SysTick 中斷優(yōu)先級沒配置好。如果你在主循環(huán)里用HAL_Delay()而此時來了一個更高優(yōu)先級的中斷比如外部中斷、串口中斷在中斷服務函數(shù)里調用了HAL_Delay()那么就會死鎖因為 SysTick 中斷被高優(yōu)先級中斷阻塞而高優(yōu)先級中斷又在等 HAL_Delay 完成。解決辦法有兩種一是確保所有中斷服務函數(shù)里不要調用 HAL_Delay二是把 SysTick 中斷優(yōu)先級調到最高。在 CubeMX 里SysTick 中斷優(yōu)先級默認是 15最低但我習慣把它改成 0最高并且在中斷服務函數(shù)里不用阻塞延時改用狀態(tài)機或者定時器計數(shù)。這樣能避免絕大多數(shù)卡死問題。另外還有一種卡死原因DHT11 的讀取時序里如果使用while (GPIO_PIN 0)這類死等語句而傳感器沒有正確響應比如線沒接好、上拉電阻丟了程序就會一直卡在 while 循環(huán)里。所有涉及外部設備響應的地方都必須加超時退出機制。比如uint16_t timeout 10000; while (DHT11_PIN_READ() 0 timeout--);5.3 ESP8266 串口通信亂碼與數(shù)據(jù)沖突很多同學會遇到 STM32 和 ESP8266 通信時串口輸出亂碼。原因大概率是波特率不匹配或者接線錯誤。ESP8266-01S 默認是 115200但有些模塊固件版本可能默認 9600所以先用 USB-TTL 接模塊獨立測試一遍確認波特率和 AT 指令響應正常再往 STM32 上接。另一個隱蔽的問題是串口沖突。如果你把 ESP8266 接在 USART1 上而 USART1 又是調試打印口那么 STM32 打印調試信息時會把數(shù)據(jù)發(fā)給 ESP8266ESP8266 會把它們當成 AT 命令解析返回 ERROR 或者進入奇怪狀態(tài)。所以調試打印和 ESP8266 通信要分兩個串口調試用 USART1PA9/PA10ESP8266 用 USART2PA2/PA3。CubeMX 配置時還要注意 PA2/PA3 的復用功能。5.4 OLED 白屏與地址問題OLED 白屏幾乎可以斷定是 I2C 地址不對或者初始化時序問題。先用 I2C 掃描程序查一下總線上設備的實際地址。如果是 0x3C 那沒問題如果掃描不到檢查接線、上拉電阻和供電。然后初始化函數(shù)要嚴格按照 SSD1306 的時序來不能省略前面的延時。還有一點容易忽略OLED 的 VCC 必須穩(wěn)定在 3.3V不要用 STM32 的 3.3V 引腳去供多個模塊尤其是 ESP8266 如果和 OLED 共用同一個 3.3VWi-Fi 發(fā)射瞬間的大電流很容易把 OLED 拉復位導致白屏。供電要分開或者說獨立給 ESP8266 供電。5.5 ADC 多通道掃描采樣的坑熱詞里提到 stm32 adc 多通道掃描循環(huán)采樣 dma這是高級玩法了。如果你的項目里不只 MQ-135 一個模擬量比如還要采集光敏電阻或者其他傳感器那么多通道 DMA 采樣確實很優(yōu)雅。但用起來有兩個坑第一多通道掃描模式下ADC 的轉換序列要正確配置。F103 的 ADC 1 最多有 16 個外部通道你可以用ADC_RegularChannelConfig()逐個配置通道和采樣順序。采樣時間不要都用默認的 1.5 周期有些高阻抗信號源需要更長的采樣時間否則數(shù)值不穩(wěn)定。第二DMA 傳輸完成后要清標志。DMA 循環(huán)模式下數(shù)據(jù)會持續(xù)填充到緩沖區(qū)但你的主循環(huán)可能只拿到了上一次的數(shù)據(jù)。CubeMX 的 ADC DMA 配置相對簡單但你需要理解 DMA 半傳遞/全傳遞中斷并維護自己的緩沖區(qū)索引。如果你不想在這個地方花太多時間最簡單的做法是先不用 DMA直接在循環(huán)里HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, 100);依次讀幾個通道數(shù)據(jù)量不大完全夠用。DMA 只是錦上添花不要為了炫技把自己困住。6. 項目報告怎么寫才能拿到高分文檔框架與圖表建議源碼容易寫報告難寫。很多同學源碼寫得很漂亮代碼能跑但報告寫得像流水賬最后答辯被老師說分析不深入、工作量不夠。這里我分享一個報告框架按這個結構寫基本不會出大問題。6.1 報告的整體結構我建議把報告分成六個章節(jié)第一章 緒論研究背景與意義、國內外研究現(xiàn)狀、本文主要工作。研究現(xiàn)狀不用寫太深點到為止重點突出本文在現(xiàn)有基礎上做了哪些改進。第二章 系統(tǒng)需求分析功能需求數(shù)據(jù)采集、自動控制、遠程監(jiān)控、非功能需求響應時間、穩(wěn)定性、功耗。第三章 系統(tǒng)總體設計硬件架構圖、軟件架構圖、通信協(xié)議設計、狀態(tài)機設計。這章是整個報告的核心圖表要多。第四章 硬件詳細設計主控最小系統(tǒng)、各模塊電路設計、PCB 設計說明如果有的話。第五章 軟件詳細設計各驅動模塊設計、核心算法設計數(shù)據(jù)濾波、狀態(tài)機、異常判斷、云端通信設計。第六章 系統(tǒng)測試與結果分析單元測試、集成測試、性能測試穩(wěn)定性、響應時間、功耗給出測試數(shù)據(jù)和截圖。6.2 圖表怎么畫才專業(yè)報告中的圖至少包含系統(tǒng)總體框圖、系統(tǒng)硬件接線圖、軟件流程圖、狀態(tài)遷移圖、界面設計圖、實物連接圖。系統(tǒng)框圖用 Word 的 SmartArt 或者 Visio 畫都可以。分三層感知層傳感器、處理層STM32 主控、執(zhí)行層繼電器/蜂鳴器和應用層OLED 顯示、手機 App。層與層之間用帶箭頭的線連接標明數(shù)據(jù)流向。軟件流程圖主要畫主循環(huán)流程和中斷服務流程。注意流程圖的符號規(guī)范起止框用圓角矩形、處理框用矩形、判斷框用菱形。別用 PPT 隨意畫幾個方塊就行格式越規(guī)范越顯得專業(yè)。狀態(tài)遷移圖是這個項目報告里的亮點圖。把狀態(tài)機用圖形化表示出來每個狀態(tài)一個圓圈狀態(tài)之間用帶箭頭的線連接線上標注觸發(fā)條件。這張圖畫出來老師一眼就知道你的業(yè)務邏輯是結構化的不是簡單 if-else 堆出來的。6.3 測試部分要有數(shù)據(jù)、有對比測試不是寫系統(tǒng)運行正常功能全部實現(xiàn)就完了。要像發(fā)論文一樣嚴謹給出測試環(huán)境室溫、供電方式、設備列表、測試步驟每個功能點的操作方式、預期結果和實際結果。還有一個關鍵點——性能測試數(shù)據(jù)。例如傳感器采集周期每 1 秒采集一次溫濕度實際抖動 5msOLED 刷新率每 500ms 刷新一次無閃爍繼電器響應時間從傳感器數(shù)值越過閾值到繼電器動作 200ms設備 24 小時連續(xù)運行無死機、無數(shù)據(jù)丟失這些數(shù)據(jù)從哪里來就是你自己在聯(lián)調階段實測記錄的。所以我在你調試過程中勸你一定要加串口打印時間戳方便統(tǒng)計毫秒級的響應時間。沒有數(shù)據(jù)的測試結果等于白測。6.4 報告的避坑點不要直接照搬開發(fā)板例程最容易被老師識破的代碼風格和開發(fā)板例程一模一樣注釋都沒改。千萬別這樣。你可以參考例程的寫法但變量名、函數(shù)名、注釋、代碼風格都要改一遍最好是自己重新組織邏輯哪怕功能一樣代碼結構也要不同。否則不僅查重過不了答辯時老師隨便問一個你寫的函數(shù)你說不出來那基本就坐實了抄代碼。另外報告語言要規(guī)范別用口頭語。比如眨眼功夫就顯示出來了要改成系統(tǒng)響應時間小于 100 毫秒滿足實時性要求。還有引用文獻至少 8 篇以上中文核心期刊、碩士論文、IEEE 論文都可以不要只引用開發(fā)板的教程帖子。6.5 源碼交付時文件組織建議認真負責的學長會教你報告交一份源碼壓縮包交一份兩者規(guī)范命名。源碼包建議包含SMART_HOME_SOURCE/ ├── README.md編譯環(huán)境、燒錄步驟、接線說明 ├── STM32_Project/整個工程文件 ├── 硬件資料/原理圖PDF、引腳分配表 ├── 上位機或云平臺配置說明/設備ID、數(shù)據(jù)流創(chuàng)建步驟 └── 參考資料/數(shù)據(jù)手冊、芯片手冊README 一定要寫清楚用什么 IDEKeil MDK 5.3x 還是 STM32CubeIDE、芯片型號、配置外設、默認引腳分配、下載方式ST-Link 還是串口 ISP、波特率、Wi-Fi 配置信息等。這一步看著不起眼但老師驗收項目時不用自己摸索接線和配置第一印象就會好很多。就我個人經(jīng)驗來看畢設項目拿到高分的關鍵不在于功能有多花哨而在于邏輯閉環(huán) 細節(jié)完整。你的系統(tǒng)可能只是溫濕度采集加繼電器控制但如果你把需求分析、原理圖設計、軟硬件分層、狀態(tài)機設計、測試數(shù)據(jù)、問題排查過程全部講清楚這就是一個完整的工程級項目而不是一個課設 Demo。反過來哪怕你功能再多但代碼一團亂、報告沒有圖表、測試數(shù)據(jù)為零老師也一樣不會給高分。按我上面這套思路來做一個月之內把代碼、實物、報告全部落地問題不大。本文還有配套的精品資源點擊獲取