簡介這是一套面向STM32入門學習與嵌入式課程設計的溫濕度實時監(jiān)測工程。以STM32F103C8為主控通過DHT11傳感器采集環(huán)境溫濕度并驅動OLED屏完成數(shù)據(jù)展示搭配Keil uVision5開發(fā)環(huán)境源碼組織清晰適合用來理解GPIO、定時器延時、單總線通信及OLED顯示驅動等基礎外設的協(xié)作流程既可作為智慧農業(yè)、小型氣象站、家居環(huán)境監(jiān)測等場景的原型也適合初學者由零開始跟進一個完整的小型顯示項目。壓縮包共75個文件以C源碼與頭文件為主體包含硬件驅動、標準外設庫、啟動文件、Keil工程配置及輔助清理腳本整體僅306KB目錄按Hardware、System、User、Library等功能模塊劃分可快速定位DHT11與OLED驅動、延時函數(shù)和main主邏輯便于二次開發(fā)與移植。目前已有7934人學習下載無論是完成課程設計還是積累STM32嵌入式項目經(jīng)驗都是一份輕量而完整的參考資料。 自己買過DHT11模塊照著網(wǎng)上代碼抄了一遍結果屏幕亂碼、溫度不更新、傳感器讀數(shù)卡死——最后查出來是I2C地址搞錯了、DHT11時序不滿足、OLED復位腳沒拉高。這幾乎是每個STM32新手都會踩的三連坑。所以當看到“基于STM32的溫濕度傳感器OLED屏顯示項目文件壓縮包”這個壓縮包的名字時我第一反應是這玩意兒要是里面代碼能直接編譯通過、連上硬件就能跑那真的省掉一大半的排查時間。但光能用還不夠如果不懂背后原理換個引腳、換個芯片型號項目又得從頭折騰。這篇文章我就以這個壓縮包項目為線索把從硬件選型、環(huán)境搭建、DHT11驅動時序、OLED取模顯示到工程管理踩過的坑一條龍講清楚。適合剛入門STM32、想做一個完整小項目的同學也適合那些手上有板子但不知道從哪兒下手的自學者。1. 項目整體思路與硬件選型1.1 為什么是STM32DHT11OLED這個組合很多新手一上來就想搞復雜的比如加WiFi、上云、搞APP控制。但坦白說能把手頭這塊STM32F103C8T6用明白把傳感器數(shù)據(jù)采集準確、把屏幕顯示調通這個基本功比什么都重要。這個項目的核心鏈路很簡單STM32通過GPIO讀取DHT11的溫濕度數(shù)據(jù)然后通過I2C接口把數(shù)據(jù)發(fā)送給OLED屏幕顯示出來。這個組合經(jīng)典到什么程度呢江科大、正點原子、野火幾乎所有STM32開發(fā)板的例程里都有這個Demo。原因有三DHT11便宜、易買、單總線協(xié)議邏輯簡單適合理解時序概念。OLED通常是0.96寸SSD1306控制器功耗低、顯示清晰、I2C接口只占兩根線接線方便。STM32F103C8T6性能和外設足夠幾十塊錢一塊板子壞了不心疼。所以哪怕你以后要去做更復雜的項目比如智能家居中控、小型氣象站、大棚環(huán)境監(jiān)測這套框架都能直接復用只需要把DHT11換成DHT22、SHT30或者把OLED換成TFT彩屏而已。1.2 溫濕度傳感器的選型差異DHT11、DHT22、SHT30、485工業(yè)傳感器很多人看到熱搜詞里有“恒智微鑫485溫濕度傳感器原理圖”會疑惑為什么我的項目用了DHT11還要扯485工業(yè)傳感器因為這是兩種完全不同的應用場景。DHT11是消費級、低成本、單總線數(shù)字傳感器精度是±2℃和±5%RH測量范圍0-50℃、20-90%RH適合室內環(huán)境、桌面小玩意、課程設計。它的優(yōu)勢就一個字便宜幾塊錢一個。DHT22也叫AM2302精度高一些是±0.5℃和±2%RH測量范圍也更寬-40~80℃但價格翻好幾倍。SHT30是I2C接口的傳感器精度更高、穩(wěn)定性更好而且不用自己寫單總線時序直接用I2C讀寄存器就行。缺點是價格更高。至于485輸出的工業(yè)傳感器那一般是24V供電、RS485總線傳輸、Modbus協(xié)議用在工廠、機房、糧庫這種長距離、多節(jié)點、強干擾的場合。一塊錢和一百塊錢的傳感器應用場景完全不同。我這個壓縮包項目用的DHT11核心價值在于讓你理解時序和協(xié)議而不是追求精度。1.3 OLED屏的選型I2C還是SPI0.96寸還是1.3寸OLED這塊0.96寸的SSD1306是最常見的有I2C接口和SPI接口兩個版本。我強烈建議新手選I2C版本因為只接4根線VCC、GND、SCL、SDA代碼也好寫。SPI版本雖然刷新速度快但要多接好幾根線而且SPI時序比I2C復雜一些對新手不友好。這里插一句熱搜詞里提到的“oled屏的像素點由幾層組成”這個問題。其實這個問題挺有意思的OLED屏幕的像素點從物理結構來說主要是基板、陽極ITO透明導電層、有機發(fā)光層空穴傳輸層、發(fā)光層、電子傳輸層這幾層有機薄膜、陰極金屬反射層加上封裝層。不過從單片機驅動角度來說你只需要關心屏幕的分辨率和顏色就行了。0.96寸OLED是128x64像素單色每個像素只能亮或不亮通過SSD1306控制器的GRAM來控制。你往GRAM里寫1這個像素就亮寫0就滅。屏幕刷新時控制器會自動把GRAM映射到物理像素上這個映射關系、掃描方向是可以通過命令配置的不同的庫實現(xiàn)可能會因此出現(xiàn)鏡像、反色之類的差異。2. 開發(fā)環(huán)境準備與工程搭建2.1 CubeMX配置引腳分配與時鐘樹拿到這個壓縮包項目第一步不是打開代碼看而是確認你的開發(fā)板是不是STM32F103C8T6以及代碼里引腳配置是否和你手上的板子一致。我用STM32CubeMX重新生成一份工程這是最穩(wěn)妥的路徑。打開STM32CubeMX芯片選擇STM32F103C8Tx然后按下面的方式配置RCCHSE選擇Crystal/Ceramic Resonator外部晶振這個是8MHz無源晶振常用的配置方式。SYSDebug選擇Serial Wire這一步非常關鍵不然你燒錄一次程序之后第二次就連接不上芯片了因為默認的JTAG引腳被程序占用了SWD也被關了。這就是為什么熱搜詞里有“stm32禁用jtag”踩過坑的都懂。I2C1選擇I2C默認PB6是SCL、PB7是SDA。GPIODHT11數(shù)據(jù)腳我一般接PA0配置為Output Push Pull速度Low就行。讀時序時再手動切換為輸入模式。如果使用開漏輸出外部上拉也可以但DHT11的時序要求比較嚴格用推挽輸出切換輸入方向這個方式更可控。USART1可選用于調試打印接PA9TX和PA10RX。時鐘樹要注意STM32F103系列最高主頻72MHz一般我們在Clock Configuration里把PLL倍頻調到x9系統(tǒng)時鐘選PLLCLK最終得到72MHz。我見過有人直接在CubeMX里默認配置就跑了結果系統(tǒng)時鐘才8MHz直接用HSII2C通信速率不對OLED顯示就會出問題。有一點要特別說明I2C的速率配置為100KHzStandard Mode就行OLED的SSD1306控制器雖然支持400KHzFast Mode但實際走線、上拉電阻和代碼實現(xiàn)都可能影響穩(wěn)定性。我調試的時候遇到過100KHz穩(wěn)定、400KHz偶發(fā)亂碼的情況后來干脆統(tǒng)一用100KHz。這個項目顯示內容不多100KHz完全夠用。2.2 KEIL5工程配置與Pack安裝CubeMX生成代碼后用KEIL5打開MDK-ARM目錄下的工程文件。但在這之前你要確認KEIL5的Pack裝了沒有。很多新手上來就打開工程然后報一堆“device not found”或者“cannot open source file xxx.h”大部分原因就是Pack沒裝好。STM32F103C8T6對應的是Keil.STM32F1xx_DFP這個Pack。打開KEIL的Pack Installer搜索STM32F1xx安裝對應版本就行。這個Pack里面包含了芯片的SVD描述文件、Flash算法、啟動文件沒有它KEIL根本不知道你要燒錄的芯片是什么。編譯前還有幾個設置我要提醒一下C/C選項卡里Define一欄加上USE_HAL_DRIVER,STM32F103C8Tx這是CubeMX生成代碼的標配如果你用的是現(xiàn)成工程看看有沒有漏掉。勾選Use MicroLIB這樣可以省不少Flash空間因為標準的C庫printf會引入很多浮點格式化代碼MicroLIB是精簡版對單片機完全夠用。Debug選項卡里選擇ST-Link Debugger或者其他你手上的下載器比如DAP-Link然后在Settings里確認能識別到芯片ID。如果你看到的是“No Target Connected”或者“Cannot access Target”先檢查接線SWDIO、SWCLK、GND三根線必須接對VCC也要接但不要接下載器的目標供電除非你確定板子沒有獨立供電。還有一個常見坑下載器質量不好或線太長導致SWD時鐘頻率太高連不上把Flash Download里的下載速度調到100kHz甚至10kHz試試。2.3 工程文件結構拆解打開這個壓縮包項目我猜里面大概有這幾個文件夾Core包含main.c、stm32f1xx_it.c、system_stm32f1xx.cDriversSTM32官方HAL庫的源碼和頭文件HAL_LIB或Middlewares一些額外的庫文件BSP或User我們自己寫的DHT11驅動、OLED驅動MDK-ARMKEIL工程文件這種分層思路是對的HAL庫是ST官方的不要動BSP層是板級支持包每個外設一個文件User層是主邏輯。如果你拿到手的壓縮包沒有這種結構也沒關系只要main.c是完整的你完全可以自己把DHT11和OLED的驅動文件整理出來這也是我下面要重點講的。3. 核心實現(xiàn)拆解DHT11驅動與OLED顯示3.1 DHT11單總線時序從波形到代碼DHT11的通信協(xié)議叫單總線1-Wire一根線既做電源又做數(shù)據(jù)嚴格說是數(shù)據(jù)線電源是獨立的核心邏輯就是靠不同長度的低電平脈沖來表示0和1。完整的一次通信流程是這樣主機STM32先把數(shù)據(jù)線拉低至少18ms然后釋放拉高DHT11檢測到這個起始信號后會先拉低80us再拉高80us作為響應信號緊接著發(fā)送40bit的數(shù)據(jù)8bit濕度整數(shù)部分、8bit濕度小數(shù)部分、8bit溫度整數(shù)部分、8bit溫度小數(shù)部分、8bit校驗和。40bit的數(shù)據(jù)里面每一位的編碼規(guī)則是先拉低50us然后拉高拉高持續(xù)26~28us表示0拉高持續(xù)70us表示1。注意這個時序不是絕對的DHT11的手冊上給的是范圍值不同的批次的傳感器可能會有細微差別。所以讀時序的代碼里一般會有超時判斷防止死等。下面這段代碼是我整理過的DHT11讀取邏輯使用HAL庫的微秒延時函數(shù)// 注意需要自己實現(xiàn)微秒延時HAL_Delay只支持毫秒 static void DHT11_Delay_US(uint16_t us) { // 使用DWT計數(shù)器實現(xiàn)精確延時或者用SysTick重載 DWT_Delay_Init(); DWT_Delay_US(us); } uint8_t DHT11_Read_Data(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5] {0}; uint8_t i, j, temp 0; // 主機拉低起始信號至少18ms GPIO_Set_Pin(DHT11_PIN, 0); HAL_Delay(20); // 釋放總線拉高等待DHT11響應 GPIO_Set_Pin(DHT11_PIN, 1); DHT11_Delay_US(30); // 切換為輸入模式讀取數(shù)據(jù) GPIO_Set_Mode_Input(DHT11_PIN); // 等待低電平響應信號80us低80us高 // 超時保護防止死循環(huán) uint16_t timeout 10000; while (GPIO_Read_Pin(DHT11_PIN) 1) { if (--timeout 0) return 1; // 超時傳感器未響應 } timeout 10000; while (GPIO_Read_Pin(DHT11_PIN) 0) { if (--timeout 0) return 1; } timeout 10000; while (GPIO_Read_Pin(DHT11_PIN) 1) { if (--timeout 0) return 1; } // 讀取40bit數(shù)據(jù) for (j 0; j 5; j) { for (i 0; i 8; i) { timeout 10000; while (GPIO_Read_Pin(DHT11_PIN) 0) { if (--timeout 0) return 1; } DHT11_Delay_US(40); // 40us后采樣 if (GPIO_Read_Pin(DHT11_PIN) 1) { temp | 0x01; // 高電平持續(xù)較久說明是1 } while (GPIO_Read_Pin(DHT11_PIN) 1) { if (--timeout 0) return 1; } if (i 7) temp 1; } buf[j] temp; temp 0; } // 校驗 if ((buf[0] buf[1] buf[2] buf[3]) buf[4]) { *humidity buf[0]; *temperature buf[2]; return 0; } return 2; // 校驗失敗 }這里最關鍵的是那個DHT11_Delay_US(40)在第28~30us的時候采樣電平如果你延時不準確、偏長讀出來的數(shù)據(jù)會全部是錯誤的。這也是為什么我強調要用DWT或者SysTick做微秒延時而不是靠空循環(huán)?？昭h(huán)在不同優(yōu)化等級下時間變化很大Debug模式下能跑通Release模式下就掛了。另外每次讀取完DHT11之后建議間隔1秒以上再讀下一次DHT11手冊上寫的最高采樣頻率是1Hz也就是每秒最多一次。你如果在一個while循環(huán)里連續(xù)讀取中間不加延時傳感器會反應不過來讀到的數(shù)據(jù)永遠是舊的或者直接超時。3.2 SSD1306 OLED驅動I2C通信與初始化序列OLED用的SSD1306控制器支持6800/8080并行接口、SPI、I2C三種方式我們用的是I2C。SSD1306的I2C地址一般是0x3C如果你的模塊是0x3D多半是因為地址引腳SA0被拉高了。這個地址在初始化代碼里寫死如果你發(fā)現(xiàn)屏幕沒反應先查地址不要急著改代碼。I2C通信的流程是主機發(fā)送起始信號→發(fā)送設備地址寫位0x78或0x7A→發(fā)送控制字節(jié)0x00表示后續(xù)是命令0x40表示后續(xù)是數(shù)據(jù)→發(fā)送命令或數(shù)據(jù)。SSD1306初始化是一長串命令序列設置顯示關閉、電荷泵開啟、對比度、掃描方向、行地址模式等。這里我強烈建議用現(xiàn)成的、驗證過的初始化序列不要自己改除非你仔細讀過SSD1306的數(shù)據(jù)手冊。下面是常用的一段uint8_t oled_init_cmds[] { 0xAE, // 關閉顯示 0x20, 0x00, // 設置內存尋址模式為水平尋址 0xB0, // 設置頁地址第0頁 0xC8, // 設置掃描方向從右上到左下和常見屏幕方向一致 0x00, 0x10, // 設置列地址低/高四位 0x40, // 設置顯示起始行 0x81, 0x7F, // 設置對比度 0xA1, // 設置段重映射避免鏡像 0xA6, // 正常顯示非反色 0xA8, 0x3F, // 設置多路復用比 0xD3, 0x00, // 設置顯示偏移 0xD5, 0x80, // 設置時鐘分頻 0xD9, 0xF1, // 設置預充電周期 0xDA, 0x12, // 設置引腳配置 0xDB, 0x40, // 設置VCOMH 0x8D, 0x14, // 開啟電荷泵 0xAF, // 開啟顯示 };有些初始化序列里如果有0xA1段重映射而你的屏幕又是鏡像的那就改成0xA0試試。同理掃描方向0xC8和0xC0互為鏡像。OLED這行就是個靠命令調鏡像的事情別懷疑芯片壞了。I2C讀寫用HAL庫的HAL_I2C_Mem_Write就很方便因為它能自動處理設備地址、寄存器地址這里就是控制字節(jié)和數(shù)據(jù)緩沖區(qū)。寫一個命令void OLED_Write_Cmd(uint8_t cmd) { HAL_I2C_Mem_Write(hi2c1, OLED_ADDR, 0x00, I2C_MEMADD_SIZE_8BIT, cmd, 1, 100); } void OLED_Write_Data(uint8_t data) { HAL_I2C_Mem_Write(hi2c1, OLED_ADDR, 0x40, I2C_MEMADD_SIZE_8BIT, data, 1, 100); }這里有個小坑HAL_I2C_Mem_Write的第二個參數(shù)是設備地址SSD1306的7位地址是0x3C但HAL庫內部會在發(fā)送時自動左移一位并拼接讀寫位所以你傳的就是0x3C不用自己移位成0x78。我見過有人在代碼里寫0x78結果I2C總線上的地址變成了0xF0屏幕完全不響應。3.3 OLED漢字取模與顯示邏輯OLED顯示漢字和字符的本質是往GRAM里填像素數(shù)據(jù)。128x64分辨率一列8個像素為一個字節(jié)16x16的漢字就是32字節(jié)數(shù)據(jù)。取模工具我用的是PCtoLCD2002設置如下取模方式陰碼點陣內為1表示點亮逐行式取模每行16個點共16行取出來的效果是0x00,0x00,0xFC,0x04, ...這種代碼可以直接定義成const數(shù)組節(jié)省RAM。顯示時要注意SSD1306在頁尋址模式下一次可以從某個頁page的某列開始連續(xù)寫數(shù)據(jù)。頁地址范圍是0~7每頁8行像素所以64行像素被分成8頁。你往某個頁寫一個字節(jié)這個字節(jié)的8個bit就代表該頁這8行對應列的亮滅。這在顯示16x16漢字時需要跨兩個頁寫數(shù)據(jù)上半部分16行像素位于第0頁和第1頁從page p開始寫兩輪每輪16字節(jié)。顯示函數(shù)的核心邏輯大概這樣void OLED_Show_CN(uint8_t x, uint8_t page, const uint8_t *font_data) { // 先寫漢字上半部分前16字節(jié) OLED_Set_Cursor(x, page); for (uint8_t i 0; i 16; i) { OLED_Write_Data(font_data[i]); } // 再寫下半部分后16字節(jié) OLED_Set_Cursor(x, page 1); for (uint8_t i 16; i 32; i) { OLED_Write_Data(font_data[i]); } }這里有個注意點漢字庫通常是16x16像素但“溫”、“濕”、“度”這些字有些筆畫比較復雜取模出來效果可能差強人意。如果顯示效果不好可以把取模的字號改成16x16標準或者換成12x12的字體減少空間占用。還有一個很實用的技巧顯示變量。DHT11讀出來的是整數(shù)比如濕度45%、溫度25度。我們可以在OLED上顯示“Temp: 25 C”和“Hum: 45 %”。但注意DHT11的精度整數(shù)顯示就夠了。如果你想顯示小數(shù)做浮點格式化會很消耗Flash和RAM建議整數(shù)和小數(shù)分開算比如25.3度就分別取25和3手動拼字符。3.4 main.c主循環(huán)邏輯設計主程序邏輯非常簡單但有一些細節(jié)值得講究。我的main函數(shù)里外設初始化完成后主循環(huán)大概是這樣int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_UART_Init(); OLED_Init(); OLED_Clear(); OLED_Show_String(16, 0, Temp:, 16); OLED_Show_String(16, 2, Hum:, 16); uint8_t hum, temp; char buf[20]; while (1) { if (DHT11_Read_Data(hum, temp) 0) { // 成功讀取更新顯示 sprintf(buf, %d C, temp); OLED_Show_String(64, 0, buf, 16); // 顯示溫度 sprintf(buf, %d %%, hum); OLED_Show_String(64, 2, buf, 16); // 顯示濕度 } else { // 讀取失敗可以顯示錯誤標記 OLED_Show_String(0, 7, DHT11 ERR, 8); } HAL_Delay(1000); // 每秒讀一次 } }這里有個細節(jié)每一輪更新前不用清屏因為你要更新的區(qū)域只是數(shù)字部分而且數(shù)字是用固定位置寫上去的。如果數(shù)字從“25”變成“5”之前十位的“2”如果不擦掉顯示就成了“52”。最簡單的辦法是每次先在這個區(qū)域填充空白字符比如寫三個空格再寫新數(shù)據(jù)。還有一點OLED_Init之后要做一次OLED_Clear不然上電屏幕可能是花屏因為GRAM里的初始數(shù)據(jù)是不確定的。4. 常見問題與排查技巧實錄4.1 I2C通信異常的排查思路I2C通信異常是最讓人頭痛的問題因為看起來代碼沒錯、接線沒錯但就是沒反應。我總結了幾個排查方向按優(yōu)先級排列查硬件接線SCL和SDA有沒有接反VCC和GND有沒有接對OLED模塊的VCC雖然標稱3.3V~5V都能工作但STM32的I2C引腳是3.3V電平所以最好統(tǒng)一用3.3V供電。如果你把OLED的VCC接到了5V而SCL/SDA是3.3V的IO口長期運行還是有風險的。查I2C地址前面已經(jīng)提過0x3C和0x3D的問題。你可以在初始化OLED之前用HAL_I2C_IsDeviceReady檢測一下設備是否在線if (HAL_I2C_IsDeviceReady(hi2c1, 0x3C, 5, 100) ! HAL_OK) { // 設備未響應這里可以點一個LED提示 }查外部上拉電阻STM32的I2C引腳是開漏輸出必須要有外部上拉電阻才能輸出高電平。大多數(shù)開發(fā)板和OLED模塊上已經(jīng)帶了4.7k或10k上拉電阻但如果你的OLED是那種裸屏模塊或者你用了杜邦線外接沒有上拉電阻I2C通信是絕對不工作的。查I2C速率如果通信不穩(wěn)定把速率從400KHz降到100KHz試試。這個問題在長線連接時特別明顯杜邦線一長寄生電容就會影響信號邊沿速率越高越容易出錯。4.2 DHT11讀取失敗和數(shù)據(jù)恒為0的調試方法DHT11讀取失敗最常見的三個原因引腳配置不對、微秒延時不準、總線競爭多個設備共用引腳。調試方法有一個很好用的用邏輯分析儀抓波形沒有邏輯分析儀也可以用printf打印每個階段的電平狀態(tài)。我分享一段調試思路把DHT11數(shù)據(jù)引腳配置為輸入模式后在主循環(huán)里只打印引腳電平的翻轉時間。如果你看到的是大約20ms低電平→80us低→80us高→數(shù)據(jù)段說明時序基本正常。如果你看到引腳一直高電平說明傳感器沒供電或者數(shù)據(jù)線沒接對。如果一上電就是低電平可能是傳感器壞了或者數(shù)據(jù)線短路到地。數(shù)據(jù)恒為0還有一個可能性讀取成功后你打印的是buf[0]和buf[2]但實際接收的濕度值是整數(shù)部分buf[0]如果你看錯位了把buf[1]小數(shù)部分當成濕度打印那確實經(jīng)常是0因為DHT11的濕度小數(shù)部分大多數(shù)時候就是0。關于微秒延時我再補充一下DWT的實現(xiàn)。DWTData Watchpoint and Trace是Cortex-M3內核里的一個調試組件它的CYCCNT寄存器可以計數(shù)CPU周期。通過它實現(xiàn)微秒延時非常精準而且不受優(yōu)化等級影響void DWT_Delay_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } void DWT_Delay_US(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) ticks); }這個方案比SysTick更省事因為SysTick可能被HAL庫的HAL_Delay占用。4.3 OLED顯示亂碼、花屏和鏡像問題OLED顯示亂碼的排查如果屏幕上全是雪花點或者滿屏亮塊大概率是初始化序列不對或者GRAM寫入方式不匹配。檢查一下你是不是用了SPI接口的OLED但代碼是按I2C寫的——這兩種接口的屏長得幾乎一樣容易拿錯模塊。如果字符顯示出來是上下左右顛倒的那基本就是段重映射和掃描方向的問題。把初始化序列里的0xA1改成0xA00xC8改成0xC0排列組合試一遍就能找到正著的方向。如果字符顯示正常但位置不對比如從中間開始顯示看看頁地址和列地址的設置。OLED_Set_Cursor這個函數(shù)必須同時設頁地址和列地址有些人只設了列地址沒設頁地址所有內容都寫在第一頁上就會重疊成一坨?；ㄆ吝€有一個特殊原因I2C通信本身沒問題但OLED的電源電壓不穩(wěn)。OLED的電荷泵開啟后電流會增大如果你用的是電腦USB口供電電壓可能被拉低導致屏閃或者花屏。換獨立5V/3.3V電源或者在電源引腳旁邊加一個10uF的電解電容和一個100nF的瓷片電容能緩解這個問題。4.4 STM32燒錄失敗SWD連不上和JTAG禁用問題燒錄失敗這個坑我必須單獨說因為它太常見了。有兩種典型情況第一種第一次燒錄沒問題燒完之后第二次就報“No target connected”。這種基本都是程序里配置了GPIO把PA13/PA14/PA15/PB3/PB4這些調試腳給重新定義了或者把SWD功能關了。CubeMX里在SYS選項卡設置Debug為Serial Wire這樣SWD引腳就不會被重映射下載器還能連上。如果已經(jīng)連不上了解決辦法是把BOOT0引腳拉高重新上電讓芯片進入ISP模式這時候SWD是恢復的擦除一下Flash再重新下載。第二種下載器本身驅動有問題。ST-Link/V2在Win10/Win11上有時會因為驅動沖突導致電腦識別不到。解決辦法是在ST官方工具STM32CubeProgrammer里重新安裝驅動。如果你用的是盜版ST-Link或者那種9塊9的DAP-Link固件不穩(wěn)定的情況更多建議先換一根數(shù)據(jù)線試試——沒錯數(shù)據(jù)線問題導致下載失敗的案例我見過不止一次。我在實際使用中最推薦下載方式的是ST-Link UtilitySTM32 ST-LINK Utility它可以直接擦除、編程、校驗整個Flash對于排查程序運行異常非常有用。程序跑飛了、芯片鎖死了用它一鍵全片擦除干干凈凈。4.5 這個壓縮包項目的可擴展方向把這個基礎項目吃透之后后續(xù)擴展的空間很大這里列幾個我實際做過的方向換成DHT22或者SHT30傳感器只需要改驅動層顯示層完全不用動。增加歷史溫度曲線顯示OLED刷新改成局部刷新每秒畫出溫度變化的像素點就能做一個微型趨勢圖。增加按鍵切換到不同顯示頁面比如一頁顯示溫濕度一頁顯示最大值最小值。把串口打印加上通過USART把數(shù)據(jù)發(fā)到電腦的串口助手方便調試和分析。加一個ESP8266或者ESP32模塊通過串口把溫濕度數(shù)據(jù)傳到云端——這就是智能家居的雛形了。把OLED換成1.3寸的I2C OLEDSH1106驅動代碼大部分可以復用只要改初始化序列和窗口設置函數(shù)就行。從底層驅動的角度你可以深入研究一下CubeMX的HAL庫源碼看看I2C的狀態(tài)機是怎么實現(xiàn)的、DMA模式怎么處理、中斷回調里能不能觸發(fā)數(shù)據(jù)讀取。這些內容才是從一個抄代碼的新手變成能獨立做項目的人的分水嶺。5. 最后想說的話這個壓縮包項目說大不大說小也不小。它沒有用到復雜的外設沒有RTOS沒有復雜的算法但它把嵌入式開發(fā)最基本的幾個環(huán)節(jié)全部串起來了芯片配置、GPIO操作、外設通信協(xié)議、時序控制、顯示驅動、以及最重要的——排查問題的思路。我的建議是拿到任何項目壓縮包不要急著燒錄看效果先用CubeMX打開工程文件或者自己重建一份把每一行代碼都過一遍搞清楚時鐘怎么配的、引腳怎么選的、I2C速率設了多少、DHT11時序怎么實現(xiàn)的、OLED初始化序列里每一條命令干嘛用的。全部搞清楚之后再燒錄到板子上。這樣就算出問題你也知道往哪兒查。如果你在調試過程中遇到和我當年一樣的坑——OLED不亮、DHT11讀不出來、燒錄第二次就失敗——歡迎回來對照這篇文章一條條排查。實在解決不了可以看看板子型號、引腳接線、報錯信息這三個信息很多時候問題就藏在最基礎的細節(jié)里。本文還有配套的精品資源點擊獲取