戰(zhàn)：串口、SPI、OLED與避坑指南)
簡介STM32F4 HAL庫V1.27.0是ST官方推出的外設(shè)驅(qū)動庫集成于STM32Cube MCU軟件包中面向使用STM32F4系列芯片的嵌入式軟硬件開發(fā)者尤其適合需要統(tǒng)一外設(shè)接口、在不同型號間快速遷移項(xiàng)目的團(tuán)隊(duì)。較之傳統(tǒng)標(biāo)準(zhǔn)庫HAL庫在API抽象和可移植性上更優(yōu)可配合STM32CubeMX可視化配置顯著降低入門門檻目前已成為ST主推的開發(fā)方式。壓縮包為ZIP格式整體約642.7MB內(nèi)含HAL庫、底層API、CMSISCORE、DSP、RTOS核心組件并整合USB、TCP/IP、文件系統(tǒng)、RTOS和圖形中間件隨包附有官方使用說明書以及基于Nucleo、探索套件與評估板的示例工程可支撐從基礎(chǔ)外設(shè)到復(fù)雜系統(tǒng)的完整開發(fā)流程。已有2034人學(xué)習(xí)下載適合學(xué)生、工程師和科研人員在開發(fā)原型或量產(chǎn)項(xiàng)目中直接參考。通過本包可獲得全套官方驅(qū)動與中間件支持規(guī)范外設(shè)調(diào)用流程、減少重復(fù)代碼編寫同時(shí)借助示例工程快速搭建項(xiàng)目框架有效縮短開發(fā)周期。 最近剛把手頭一批F4項(xiàng)目的HAL庫從舊版本整體升到最新的1.27.0順手幫群里幾個(gè)朋友把新工程從零到一搭了一遍。折騰完這一圈說實(shí)話挺有感觸的HAL庫這幾年被吐槽不少但真到實(shí)際項(xiàng)目里它已經(jīng)把大部分寄存器操作包成了穩(wěn)定的API尤其是像STM32F4這個(gè)量級的芯片用HAL庫做原型驗(yàn)證和中小批量產(chǎn)品效率是真的高。這篇不打算講什么大而全的教程更多是我基于1.27.0這版把網(wǎng)上高頻出現(xiàn)的問題、我自己踩過的坑、以及幾個(gè)常用外設(shè)串口、SPI、模擬時(shí)序、OLED的實(shí)際配置過程集中整理一份筆記。適合剛接觸F4 HAL庫的初學(xué)者也適合從標(biāo)準(zhǔn)庫轉(zhuǎn)過來、想知道HAL庫某些接口到底怎么用的老手。1. HAL庫生態(tài)現(xiàn)狀與1.27.0版本定位1.1 為什么F4用戶還在守著HAL庫不少從標(biāo)準(zhǔn)外設(shè)庫切過來的朋友一開始都會覺得HAL庫太“重”初始化結(jié)構(gòu)體多、調(diào)用鏈長、回調(diào)機(jī)制反直覺。但真跑過幾個(gè)項(xiàng)目就會明白HAL庫的價(jià)值在于它對芯片系列差異做了統(tǒng)一封裝同一份代碼在F4、F1甚至部分國產(chǎn)兼容芯片上外設(shè)接口高度相似移植成本遠(yuǎn)低于標(biāo)準(zhǔn)庫。另一個(gè)實(shí)際原因是生態(tài)。STM32CubeMX生成的初始化代碼、ST官方的所有應(yīng)用筆記、包括網(wǎng)上大量開源的驅(qū)動OLED、DHT11、各類傳感器默認(rèn)都是HAL庫。像鐵頭山羊那套HAL庫筆記確實(shí)幫很多人把“初始化結(jié)構(gòu)體怎么填”這件事講透了。只要調(diào)試手段跟上HAL庫并不比標(biāo)準(zhǔn)庫難用只是換了一套思維。1.2 1.27.0到底改了什么從Release Notes來看1.27.0整體屬于穩(wěn)定性修復(fù)版本沒有動框架級的東西。我實(shí)際測試下來變化主要集中在三塊串口Ex系列接口的完善尤其是HAL_UARTEx_ReceiveToIdle_IT這類帶空閑檢測的接收接口比老版本更穩(wěn)定。SPI在部分F4型號上的DMA傳輸收尾邏輯有調(diào)整之前偶爾出現(xiàn)“DMA傳輸完成后回調(diào)不觸發(fā)”的問題有所緩解。CubeMX生成的代碼在編譯時(shí)告警更少對ARMCC和GCC的兼容性都有修正。如果你是從1.26.x升上來的風(fēng)險(xiǎn)不大直接替換庫文件、重新編譯即可。但如果是跨大版本升級比如從1.21直接跳到1.27需要重點(diǎn)檢查串口和定時(shí)器回調(diào)函數(shù)的簽名是否有變化。2. 工程搭建與底層配置CubeMX還是手動擼2.1 CubeMX生成工程的兩個(gè)隱藏坑大多數(shù)新手會直接用CubeMX生成工程這個(gè)流程本身沒問題但有兩個(gè)坑我見得特別多。第一個(gè)坑是固件包版本和實(shí)際庫版本不一致。CubeMX默認(rèn)下載的STM32F4固件包可能不是1.27.0如果你的項(xiàng)目指定了舊版本生成的代碼里stm32f4xx_hal_conf.h和庫文件都是舊的。正確做法是在CubeMX的Help - Manage Embedded Software Packages里檢查并更新F4固件包版本生成代碼后再核對stm32f4xx_hal_conf.h里的HAL_UARTEX_MODULE_ENABLED這類宏是否開啟。第二個(gè)坑是時(shí)鐘樹配置。F4的SYSCLK最高168MHz部分型號180MHz很多人在CubeMX里直接拉滿但忽略了APB1和APB2總線分頻后的外設(shè)時(shí)鐘上限。串口波特率算不準(zhǔn)、定時(shí)器溢出時(shí)間不對多半是這里的時(shí)鐘樹沒設(shè)置對。2.2 手工創(chuàng)建F4工程的關(guān)鍵文件清單stm32f103c8t6 hal庫 手工創(chuàng)建項(xiàng)目這個(gè)搜索詞最近熱度挺高說明確實(shí)有人不想依賴CubeMX。手工創(chuàng)建F4項(xiàng)目其實(shí)比想象中簡單核心文件就幾類startup_stm32f407xx.s啟動文件定義棧大小、中斷向量表、復(fù)位處理函數(shù)。system_stm32f4xx.c系統(tǒng)時(shí)鐘初始化默認(rèn)配置HSE和PLL。stm32f4xx_hal.c、stm32f4xx_hal_rcc.c、stm32f4xx_hal_gpio.c、stm32f4xx_hal_uart.c等按需添加的HAL源文件。stm32f4xx_hal_conf.h總配置文件決定編譯哪些模塊。main.cstm32f4xx_it.c用戶代碼和中斷服務(wù)函數(shù)。手工創(chuàng)建時(shí)最容易漏掉的是stm32f4xx_hal_msp.c。這個(gè)文件負(fù)責(zé)外設(shè)底層的GPIO和時(shí)鐘初始化CubeMX會自動生成手工創(chuàng)建時(shí)需要在里面實(shí)現(xiàn)如HAL_UART_MspInit、HAL_SPI_MspInit等回調(diào)函數(shù)否則外設(shè)初始化后不工作。3. 四大高頻外設(shè)實(shí)戰(zhàn)記錄3.1 串口空閑中斷HAL_UARTEx_ReceiveToIdle_IT的正確打開方式串口接收是HAL庫被問得最多的功能。老版本里做不定長接收通常要靠自己開USART的IDLE中斷在中斷里清標(biāo)志位、停DMA、手動切接收狀態(tài)代碼寫起來很繞。1.27.0里HAL_UARTEx_ReceiveToIdle_IT成了推薦做法。用法是uint8_t rx_buf[256]; HAL_UARTEx_ReceiveToIdle_IT(huart1, rx_buf, sizeof(rx_buf));調(diào)用后HAL庫會在每收到一字節(jié)時(shí)進(jìn)入中斷直到發(fā)生空閑總線上一段時(shí)間沒有新數(shù)據(jù)或者緩沖區(qū)收滿再調(diào)用回調(diào)?；卣{(diào)里通過參數(shù)區(qū)分是“收到空閑”還是“收滿緩沖”void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { // Size表示本次接收到的有效字節(jié)數(shù) // 處理rx_buf中的數(shù)據(jù) // 重新調(diào)用HAL_UARTEx_ReceiveToIdle_IT準(zhǔn)備下一幀 HAL_UARTEx_ReceiveToIdle_IT(huart1, rx_buf, sizeof(rx_buf)); } }這里有兩個(gè)容易踩的問題。第一回調(diào)函數(shù)執(zhí)行完后必須重新調(diào)用一次接收函數(shù)否則后續(xù)數(shù)據(jù)不會再觸發(fā)中斷。第二HAL_UARTEx_ReceiveToIdle_IT一次只能接收一個(gè)緩沖區(qū)如果上一幀數(shù)據(jù)還沒處理完下一幀就到了會丟數(shù)據(jù)。解決辦法是用雙緩沖或者在回調(diào)里快速把數(shù)據(jù)拷貝到自己的環(huán)形隊(duì)列中。3.2 SPI1驅(qū)動MT6701磁編碼器的9位數(shù)據(jù)幀問題MT6701是磁編碼器芯片做電機(jī)控制時(shí)常用它讀角度。網(wǎng)上不少人卡在stm32f4配置spi1驅(qū)動mt6701這個(gè)問題上核心難點(diǎn)其實(shí)不在SPI配置而在數(shù)據(jù)幀長度。MT6701的SSI輸出本質(zhì)上是一種9位數(shù)據(jù)幀而STM32F4的SPI外設(shè)原生只支持8位或16位幀。直接配成8位讀取數(shù)據(jù)會錯(cuò)位配成16位又多了7位無用數(shù)據(jù)。我試過兩種可行方案第一種配置成16位幀讀取后把數(shù)據(jù)右移7位再和0x1FF與運(yùn)算。這種方案實(shí)現(xiàn)簡單但浪費(fèi)了半個(gè)SPI周期如果SPI時(shí)鐘較高可以忽略。第二種更推薦。配置成8位幀連續(xù)讀兩幀把第一幀的高7位和第二幀的最高位拼起來。代碼看起來是這樣uint8_t data[2]; uint16_t angle_raw; HAL_SPI_Receive(hspi1, data, 2, 10); angle_raw ((data[0] 0x7F) 1) | ((data[1] 0x80) 7);SPI的極性配置也很關(guān)鍵。MT6701手冊明確要求SCK空閑為低、數(shù)據(jù)在上升沿采樣對應(yīng)SPI的CPOL0, CPHA1也就是Mode 1。如果配成Mode 0或Mode 3讀出來的角度數(shù)據(jù)會間歇性跳變。我的建議是連接好硬件后先靜態(tài)旋轉(zhuǎn)編碼器看輸出是否平滑變化這一步能同時(shí)驗(yàn)證接線、SPI參數(shù)和拼接邏輯是否正確。3.3 用HAL庫GPIO裸仿真DHT11時(shí)序DHT11這類單總線傳感器協(xié)議本身不難但用HAL庫驅(qū)動時(shí)有一個(gè)典型問題HAL_Delay只有毫秒級精度而DHT11的時(shí)序是微秒級的。初始化時(shí)主機(jī)拉低18ms可以用HAL_Delay但讀取數(shù)據(jù)位時(shí)50us低電平 26~70us高電平必須用微秒級延時(shí)。我習(xí)慣的做法是關(guān)閉SysTick中斷干擾后用DWTData Watchpoint and Trace的CYCCNT寄存器做精確延時(shí)。F4主頻168MHz時(shí)一個(gè)時(shí)鐘周期約5.95ns要做1us延時(shí)只需循環(huán)約168個(gè)周期。寫個(gè)簡單的延時(shí)函數(shù)static void delay_us(uint32_t us) { DWT-CYCCNT 0; while (DWT-CYCCNT us * (SystemCoreClock / 1000000)); }讀取數(shù)據(jù)位的判斷邏輯也很固定每位數(shù)據(jù)開始時(shí)總線拉低50us然后釋放如果是高電平持續(xù)26~28us則是邏輯0持續(xù)70us則是邏輯1。在GPIO上升沿后延時(shí)40us左右再采樣能避開信號邊沿抖動這個(gè)“延后采樣”細(xì)節(jié)能讓讀數(shù)據(jù)成功率大幅提升。順帶提一下DHT11每次讀之間的間隔至少要1秒讀太頻繁傳感器會不響應(yīng)。這個(gè)不是HAL庫的問題但用HAL庫做循環(huán)輪詢時(shí)容易忽略。3.4 OLED驅(qū)動I2C/SPI兩條路的取舍hal庫驅(qū)動oled代碼也是高頻搜索詞。SSD1306作為I2C設(shè)備時(shí)HAL庫的做法是每次寫命令或數(shù)據(jù)都調(diào)用HAL_I2C_Mem_Write從設(shè)備地址、控制字節(jié)、數(shù)據(jù)內(nèi)容逐段傳。這種方法有一個(gè)經(jīng)典坑I2C時(shí)鐘配置太高會失敗。F4的I2C1掛在APB1上如果APB1時(shí)鐘是42MHzI2C時(shí)鐘寄存器配置不當(dāng)會導(dǎo)致通信不穩(wěn)定。建議把I2C時(shí)鐘調(diào)到400kHz以下并在初始化后加一個(gè)短延時(shí)。另一個(gè)要注意的是OLED刷新策略。不要在需要顯示的地方臨時(shí)拼一個(gè)命令幀發(fā)過去那樣閃爍明顯。正確做法是維護(hù)一整塊顯存128*64/8 1024字節(jié)需要更新時(shí)修改顯存數(shù)據(jù)然后一次性把整塊顯存發(fā)送到OLED的GDDRAM。SSD1306的頁地址模式可以按頁寫但最穩(wěn)妥的方式是關(guān)閉頁面滾動效果后設(shè)為水平尋址模式連續(xù)寫入。如果追求刷新率建議用SPI接口的OLED模塊。SPI寫SSD1306只需要4根線主頻可以跑到10MHz以上整屏刷新時(shí)間遠(yuǎn)低于I2C。對應(yīng)的HAL調(diào)用是HAL_SPI_Transmit注意OLED的DC引腳要在寫命令和寫數(shù)據(jù)之間切換CS引腳在傳輸前拉低、傳輸后拉高即可。4. 燒錄調(diào)試與固件運(yùn)行問題4.1 Keil5燒錄F4的常見失敗原因keil5燒錄程序stm32f4是每個(gè)新手都會搜的詞。燒錄失敗的原因不外乎三類第一類是Flash下載算法缺失。Keil5如果沒有安裝對應(yīng)的F4器件支持包燒錄時(shí)Flash區(qū)域是空的。解決辦法是在Pack Installer里安裝STM32F4系列的Device Family Pack安裝后keil會自動匹配STM32F4xx Flash下載算法。第二類是芯片型號選錯(cuò)。同一個(gè)F407和F405Flash容量和內(nèi)存映射不同選錯(cuò)型號后下載算法對不上燒錄會報(bào)“Flash Download failed - Cortex-M4”。建議在Options for Target - Device里仔細(xì)核對具體型號而不是只選個(gè)F407VG大概就行。第三類是燒錄器接線不穩(wěn)這是最隱蔽的。SWD只需要SWDIO、SWCLK、GND三根線但很多人燒錄時(shí)沒接復(fù)位線導(dǎo)致偶爾能連上、偶爾連不上。使用ST-LINK或DAP-Link時(shí)如果反復(fù)出現(xiàn)“Cannot access target”先檢查復(fù)位引腳是否有干擾然后把燒錄速度從5MHz降到1MHz再試。4.2 燒錄成功卻不運(yùn)行的排查路徑程序能燒錄但板上沒反應(yīng)這種問題比燒錄失敗還讓人頭疼。我的排查路徑基本是固定的先看復(fù)位引腳電平是否正常NRST有沒有被外部電容拉得太死。再看時(shí)鐘是否起振F4靠外部晶振通過PLL倍頻到168MHz晶振沒焊好或者負(fù)載電容不對系統(tǒng)時(shí)鐘會卡在HSI的16MHz但很多外設(shè)時(shí)序就不對了。排除這些問題后重點(diǎn)查啟動文件中堆棧大小設(shè)置。HAL庫的DMA中斷、串口中斷、RTOS任務(wù)棧都是占用系統(tǒng)棧的如果Stack_Size設(shè)置過小程序會在某個(gè)時(shí)刻進(jìn)入HardFault表現(xiàn)就是燒錄后能跑但運(yùn)行一段時(shí)間就不動了。把啟動文件里的Stack_Size從默認(rèn)0x400加到0x1000是一個(gè)成本極低但見效很快的修改。還有個(gè)小細(xì)節(jié)F4內(nèi)核帶FPU如果工程里啟用了浮點(diǎn)運(yùn)算但不能正常執(zhí)行檢查編譯器選項(xiàng)里是否勾選了FPU: Single Precision同時(shí)確認(rèn)stm32f4xx.h里的__FPU_PRESENT和__TARGET_FPU_VFP宏都已經(jīng)定義。這個(gè)配置不對浮點(diǎn)運(yùn)算會走軟件模擬性能降低十倍以上。5. 從eMMC到國產(chǎn)兼容芯片HAL庫的邊界在哪里5.1 F4外接eMMCSDIO協(xié)議層的復(fù)用stm32f4 emmc這個(gè)關(guān)鍵詞最近被搜得比較多很多人想在F4上掛一個(gè)eMMC當(dāng)大容量存儲。思路其實(shí)很簡單eMMC的物理接口和SD卡高度相似都是走CLK、CMD、DATA0-3這些信號線F4的SDIO外設(shè)本身就可以當(dāng)eMMC控制器用。關(guān)鍵區(qū)別在于初始化流程。SD卡上電后要先發(fā)CMD0進(jìn)入空閑態(tài)然后CMD8、ACMD41判斷SD版本。eMMC有自己的Boot Partition和RPMB分區(qū)不能用ACMD41那種方式直接切到數(shù)據(jù)傳輸模式需要發(fā)CMD1SEND_OP_COND等待eMMC進(jìn)入Ready狀態(tài)再通過CMD2獲取CID、CMD3分配RCA、CMD7選擇分區(qū)最后用CMD17/CMD18讀數(shù)據(jù)、CMD24/CMD25寫數(shù)據(jù)。HAL庫里的HAL_SD_Init已經(jīng)封裝了一部分初始化邏輯但針對eMMC建議把底層卡類型檢測函數(shù)看一下。如果開發(fā)板上的eMMC是4GB以上的高容量版本注意F4的SDIO是SD Spec Version 2.0只支持SD 2.0的容量尋址方式大于2GB的扇區(qū)需要走SDHC模式還好HAL庫默認(rèn)按512字節(jié)塊尋址一般不會有問題。5.2 國產(chǎn)M0/M0芯片的“類HAL庫”回調(diào)兼容性最近在討論py32f003的hal庫中斷回調(diào)函數(shù)有bug嗎這個(gè)問題。這類國產(chǎn)芯片為了兼容ST的生態(tài)確實(shí)也提供了一套命名很像HAL庫的驅(qū)動但底層是基于自家外設(shè)實(shí)現(xiàn)的與ST HAL并不完全等價(jià)。我個(gè)人經(jīng)驗(yàn)是移植這類芯片時(shí)中斷回調(diào)不能無腦照搬ST HAL的邏輯。比如GPIO外部中斷回調(diào)里ST HAL在每次中斷觸發(fā)時(shí)會自動清除中斷標(biāo)志但某些國產(chǎn)芯片的庫不會清需要自己在回調(diào)開頭調(diào)用HAL_GPIO_EXTI_IRQHandler對應(yīng)的底層清除函數(shù)。UART回調(diào)也有差異有些芯片在回調(diào)里直接讀數(shù)據(jù)寄存器會導(dǎo)致丟字節(jié)需要先判斷狀態(tài)位。我的建議是用這類芯片時(shí)第一優(yōu)先讀芯片廠商自己的參考手冊和例程不要依賴ST HAL的使用習(xí)慣。如果確實(shí)發(fā)現(xiàn)回調(diào)在某些情況下不觸發(fā)先用調(diào)試器確認(rèn)中斷標(biāo)志位是否置位再決定是改庫還是改應(yīng)用邏輯。大多數(shù)情況下所謂的“bug”其實(shí)是芯片寄存器行為與ST不同。6. 常見問題速查與避坑筆記6.1 速度、優(yōu)先級、堆棧三件套這三大類問題幾乎覆蓋了90%的HAL庫運(yùn)行異常。整理成表格方便對照排查問題現(xiàn)象常見原因排查與解決辦法串口偶爾丟一幀中斷優(yōu)先級過低被其他中斷打斷在HAL_NVIC_SetPriority中把串口中斷優(yōu)先級設(shè)為高于DMA中斷I2C通信卡死I2C時(shí)鐘配置錯(cuò)誤或總線被別設(shè)備拉死檢查APB1時(shí)鐘設(shè)置時(shí)鐘低于400kHz在初始化后重新HAL_I2C_DeInit再InitSPI讀取數(shù)據(jù)錯(cuò)亂CPOL/CPHA配置錯(cuò)誤或幀長度不匹配對照傳感器手冊確認(rèn)Mode和幀長用邏輯分析儀看波形DMA傳輸完成但回調(diào)不觸發(fā)DMA中斷未開啟或回調(diào)函數(shù)名寫錯(cuò)檢查HAL_DMA_Start_IT參數(shù)、__HAL_DMA_ENABLE_IT配置程序運(yùn)行一段時(shí)間后HardFault棧溢出或數(shù)組越界查看Stack_Size檢查回調(diào)中緩沖區(qū)是否越界寫入PWM輸出無波形RCC時(shí)鐘分頻錯(cuò)誤或預(yù)分頻值超限用CubeMX重新計(jì)算PSC和ARR確認(rèn)輸出引腳是復(fù)用模式6.2 我在1.27.0上踩過的三個(gè)坑最后分享三個(gè)這次升級過程中切切實(shí)實(shí)踩過的坑。第一個(gè)坑是串口接收回調(diào)的參數(shù)含義變了。在舊版本里HAL_UART_RxCpltCallback不帶接收長度數(shù)據(jù)量要自己記。1.27.0里引入的HAL_UARTEx_RxEventCallback雖然好用但如果你同時(shí)使用了老接口接收長度會錯(cuò)亂。我的建議是新工程統(tǒng)一用RxEventCallback老工程升級時(shí)把所有串口接收邏輯全部換到新API不要混用。第二個(gè)坑是DMA傳輸完成后的收尾時(shí)序。SPI DMA傳輸完成后芯片手冊要求等待SPI外設(shè)完全空閑再去訪問數(shù)據(jù)寄存器。1.27.0在某些F4型號上修復(fù)了這個(gè)問題但如果你用的是其他品牌兼容芯片建議在DMA回調(diào)里加上__HAL_SPI_CLEAR_OVRFLAG之類的宏手動清除溢出標(biāo)志。第三個(gè)坑和堆棧有關(guān)。1.27.0版本里如果啟用了HAL_UARTEx_ReceiveToIdle_IT和DMA同時(shí)工作系統(tǒng)棧占用會比純中斷模式高不少。我在一個(gè)跑FreeRTOS的項(xiàng)目里把任務(wù)棧考到1KB結(jié)果系統(tǒng)頻繁進(jìn)入HardFault。最后把任務(wù)棧提到2KB徹底解決。HAL庫的封裝方便是方便但背后的棧開銷確實(shí)比直接操作寄存器高這個(gè)在資源緊張的芯片上要提前評估?；仡^再想HAL庫這個(gè)東西用好的關(guān)鍵在于不把它當(dāng)黑盒。跑起來有問題時(shí)先看庫源碼再看寄存器手冊最后才改應(yīng)用邏輯。1.27.0整體上是一個(gè)值得升級的穩(wěn)定版本如果你手頭項(xiàng)目還不是特別緊急可以找一塊開發(fā)板先跑通我上面提到的這幾個(gè)外設(shè)再遷到正式項(xiàng)目里能省不少事。本文還有配套的精品資源點(diǎn)擊獲取 STM32F4 HAL庫1.27.0實(shí)戰(zhàn)：串口、SPI、OLED與避坑指南
簡介STM32F4 HAL庫V1.27.0是ST官方推出的外設(shè)驅(qū)動庫集成于STM32Cube MCU軟件包中面向使用STM32F4系列芯片的嵌入式軟硬件開發(fā)者尤其適合需要統(tǒng)一外設(shè)接口、在不同型號間快速遷移項(xiàng)目的團(tuán)隊(duì)。較之傳統(tǒng)標(biāo)準(zhǔn)庫HAL庫在API抽象和可移植性上更優(yōu)可配合STM32CubeMX可視化配置顯著降低入門門檻目前已成為ST主推的開發(fā)方式。壓縮包為ZIP格式整體約642.7MB內(nèi)含HAL庫、底層API、CMSISCORE、DSP、RTOS核心組件并整合USB、TCP/IP、文件系統(tǒng)、RTOS和圖形中間件隨包附有官方使用說明書以及基于Nucleo、探索套件與評估板的示例工程可支撐從基礎(chǔ)外設(shè)到復(fù)雜系統(tǒng)的完整開發(fā)流程。已有2034人學(xué)習(xí)下載適合學(xué)生、工程師和科研人員在開發(fā)原型或量產(chǎn)項(xiàng)目中直接參考。通過本包可獲得全套官方驅(qū)動與中間件支持規(guī)范外設(shè)調(diào)用流程、減少重復(fù)代碼編寫同時(shí)借助示例工程快速搭建項(xiàng)目框架有效縮短開發(fā)周期。 最近剛把手頭一批F4項(xiàng)目的HAL庫從舊版本整體升到最新的1.27.0順手幫群里幾個(gè)朋友把新工程從零到一搭了一遍。折騰完這一圈說實(shí)話挺有感觸的HAL庫這幾年被吐槽不少但真到實(shí)際項(xiàng)目里它已經(jīng)把大部分寄存器操作包成了穩(wěn)定的API尤其是像STM32F4這個(gè)量級的芯片用HAL庫做原型驗(yàn)證和中小批量產(chǎn)品效率是真的高。這篇不打算講什么大而全的教程更多是我基于1.27.0這版把網(wǎng)上高頻出現(xiàn)的問題、我自己踩過的坑、以及幾個(gè)常用外設(shè)串口、SPI、模擬時(shí)序、OLED的實(shí)際配置過程集中整理一份筆記。適合剛接觸F4 HAL庫的初學(xué)者也適合從標(biāo)準(zhǔn)庫轉(zhuǎn)過來、想知道HAL庫某些接口到底怎么用的老手。1. HAL庫生態(tài)現(xiàn)狀與1.27.0版本定位1.1 為什么F4用戶還在守著HAL庫不少從標(biāo)準(zhǔn)外設(shè)庫切過來的朋友一開始都會覺得HAL庫太“重”初始化結(jié)構(gòu)體多、調(diào)用鏈長、回調(diào)機(jī)制反直覺。但真跑過幾個(gè)項(xiàng)目就會明白HAL庫的價(jià)值在于它對芯片系列差異做了統(tǒng)一封裝同一份代碼在F4、F1甚至部分國產(chǎn)兼容芯片上外設(shè)接口高度相似移植成本遠(yuǎn)低于標(biāo)準(zhǔn)庫。另一個(gè)實(shí)際原因是生態(tài)。STM32CubeMX生成的初始化代碼、ST官方的所有應(yīng)用筆記、包括網(wǎng)上大量開源的驅(qū)動OLED、DHT11、各類傳感器默認(rèn)都是HAL庫。像鐵頭山羊那套HAL庫筆記確實(shí)幫很多人把“初始化結(jié)構(gòu)體怎么填”這件事講透了。只要調(diào)試手段跟上HAL庫并不比標(biāo)準(zhǔn)庫難用只是換了一套思維。1.2 1.27.0到底改了什么從Release Notes來看1.27.0整體屬于穩(wěn)定性修復(fù)版本沒有動框架級的東西。我實(shí)際測試下來變化主要集中在三塊串口Ex系列接口的完善尤其是HAL_UARTEx_ReceiveToIdle_IT這類帶空閑檢測的接收接口比老版本更穩(wěn)定。SPI在部分F4型號上的DMA傳輸收尾邏輯有調(diào)整之前偶爾出現(xiàn)“DMA傳輸完成后回調(diào)不觸發(fā)”的問題有所緩解。CubeMX生成的代碼在編譯時(shí)告警更少對ARMCC和GCC的兼容性都有修正。如果你是從1.26.x升上來的風(fēng)險(xiǎn)不大直接替換庫文件、重新編譯即可。但如果是跨大版本升級比如從1.21直接跳到1.27需要重點(diǎn)檢查串口和定時(shí)器回調(diào)函數(shù)的簽名是否有變化。2. 工程搭建與底層配置CubeMX還是手動擼2.1 CubeMX生成工程的兩個(gè)隱藏坑大多數(shù)新手會直接用CubeMX生成工程這個(gè)流程本身沒問題但有兩個(gè)坑我見得特別多。第一個(gè)坑是固件包版本和實(shí)際庫版本不一致。CubeMX默認(rèn)下載的STM32F4固件包可能不是1.27.0如果你的項(xiàng)目指定了舊版本生成的代碼里stm32f4xx_hal_conf.h和庫文件都是舊的。正確做法是在CubeMX的Help - Manage Embedded Software Packages里檢查并更新F4固件包版本生成代碼后再核對stm32f4xx_hal_conf.h里的HAL_UARTEX_MODULE_ENABLED這類宏是否開啟。第二個(gè)坑是時(shí)鐘樹配置。F4的SYSCLK最高168MHz部分型號180MHz很多人在CubeMX里直接拉滿但忽略了APB1和APB2總線分頻后的外設(shè)時(shí)鐘上限。串口波特率算不準(zhǔn)、定時(shí)器溢出時(shí)間不對多半是這里的時(shí)鐘樹沒設(shè)置對。2.2 手工創(chuàng)建F4工程的關(guān)鍵文件清單stm32f103c8t6 hal庫 手工創(chuàng)建項(xiàng)目這個(gè)搜索詞最近熱度挺高說明確實(shí)有人不想依賴CubeMX。手工創(chuàng)建F4項(xiàng)目其實(shí)比想象中簡單核心文件就幾類startup_stm32f407xx.s啟動文件定義棧大小、中斷向量表、復(fù)位處理函數(shù)。system_stm32f4xx.c系統(tǒng)時(shí)鐘初始化默認(rèn)配置HSE和PLL。stm32f4xx_hal.c、stm32f4xx_hal_rcc.c、stm32f4xx_hal_gpio.c、stm32f4xx_hal_uart.c等按需添加的HAL源文件。stm32f4xx_hal_conf.h總配置文件決定編譯哪些模塊。main.cstm32f4xx_it.c用戶代碼和中斷服務(wù)函數(shù)。手工創(chuàng)建時(shí)最容易漏掉的是stm32f4xx_hal_msp.c。這個(gè)文件負(fù)責(zé)外設(shè)底層的GPIO和時(shí)鐘初始化CubeMX會自動生成手工創(chuàng)建時(shí)需要在里面實(shí)現(xiàn)如HAL_UART_MspInit、HAL_SPI_MspInit等回調(diào)函數(shù)否則外設(shè)初始化后不工作。3. 四大高頻外設(shè)實(shí)戰(zhàn)記錄3.1 串口空閑中斷HAL_UARTEx_ReceiveToIdle_IT的正確打開方式串口接收是HAL庫被問得最多的功能。老版本里做不定長接收通常要靠自己開USART的IDLE中斷在中斷里清標(biāo)志位、停DMA、手動切接收狀態(tài)代碼寫起來很繞。1.27.0里HAL_UARTEx_ReceiveToIdle_IT成了推薦做法。用法是uint8_t rx_buf[256]; HAL_UARTEx_ReceiveToIdle_IT(huart1, rx_buf, sizeof(rx_buf));調(diào)用后HAL庫會在每收到一字節(jié)時(shí)進(jìn)入中斷直到發(fā)生空閑總線上一段時(shí)間沒有新數(shù)據(jù)或者緩沖區(qū)收滿再調(diào)用回調(diào)?；卣{(diào)里通過參數(shù)區(qū)分是“收到空閑”還是“收滿緩沖”void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { // Size表示本次接收到的有效字節(jié)數(shù) // 處理rx_buf中的數(shù)據(jù) // 重新調(diào)用HAL_UARTEx_ReceiveToIdle_IT準(zhǔn)備下一幀 HAL_UARTEx_ReceiveToIdle_IT(huart1, rx_buf, sizeof(rx_buf)); } }這里有兩個(gè)容易踩的問題。第一回調(diào)函數(shù)執(zhí)行完后必須重新調(diào)用一次接收函數(shù)否則后續(xù)數(shù)據(jù)不會再觸發(fā)中斷。第二HAL_UARTEx_ReceiveToIdle_IT一次只能接收一個(gè)緩沖區(qū)如果上一幀數(shù)據(jù)還沒處理完下一幀就到了會丟數(shù)據(jù)。解決辦法是用雙緩沖或者在回調(diào)里快速把數(shù)據(jù)拷貝到自己的環(huán)形隊(duì)列中。3.2 SPI1驅(qū)動MT6701磁編碼器的9位數(shù)據(jù)幀問題MT6701是磁編碼器芯片做電機(jī)控制時(shí)常用它讀角度。網(wǎng)上不少人卡在stm32f4配置spi1驅(qū)動mt6701這個(gè)問題上核心難點(diǎn)其實(shí)不在SPI配置而在數(shù)據(jù)幀長度。MT6701的SSI輸出本質(zhì)上是一種9位數(shù)據(jù)幀而STM32F4的SPI外設(shè)原生只支持8位或16位幀。直接配成8位讀取數(shù)據(jù)會錯(cuò)位配成16位又多了7位無用數(shù)據(jù)。我試過兩種可行方案第一種配置成16位幀讀取后把數(shù)據(jù)右移7位再和0x1FF與運(yùn)算。這種方案實(shí)現(xiàn)簡單但浪費(fèi)了半個(gè)SPI周期如果SPI時(shí)鐘較高可以忽略。第二種更推薦。配置成8位幀連續(xù)讀兩幀把第一幀的高7位和第二幀的最高位拼起來。代碼看起來是這樣uint8_t data[2]; uint16_t angle_raw; HAL_SPI_Receive(hspi1, data, 2, 10); angle_raw ((data[0] 0x7F) 1) | ((data[1] 0x80) 7);SPI的極性配置也很關(guān)鍵。MT6701手冊明確要求SCK空閑為低、數(shù)據(jù)在上升沿采樣對應(yīng)SPI的CPOL0, CPHA1也就是Mode 1。如果配成Mode 0或Mode 3讀出來的角度數(shù)據(jù)會間歇性跳變。我的建議是連接好硬件后先靜態(tài)旋轉(zhuǎn)編碼器看輸出是否平滑變化這一步能同時(shí)驗(yàn)證接線、SPI參數(shù)和拼接邏輯是否正確。3.3 用HAL庫GPIO裸仿真DHT11時(shí)序DHT11這類單總線傳感器協(xié)議本身不難但用HAL庫驅(qū)動時(shí)有一個(gè)典型問題HAL_Delay只有毫秒級精度而DHT11的時(shí)序是微秒級的。初始化時(shí)主機(jī)拉低18ms可以用HAL_Delay但讀取數(shù)據(jù)位時(shí)50us低電平 26~70us高電平必須用微秒級延時(shí)。我習(xí)慣的做法是關(guān)閉SysTick中斷干擾后用DWTData Watchpoint and Trace的CYCCNT寄存器做精確延時(shí)。F4主頻168MHz時(shí)一個(gè)時(shí)鐘周期約5.95ns要做1us延時(shí)只需循環(huán)約168個(gè)周期。寫個(gè)簡單的延時(shí)函數(shù)static void delay_us(uint32_t us) { DWT-CYCCNT 0; while (DWT-CYCCNT us * (SystemCoreClock / 1000000)); }讀取數(shù)據(jù)位的判斷邏輯也很固定每位數(shù)據(jù)開始時(shí)總線拉低50us然后釋放如果是高電平持續(xù)26~28us則是邏輯0持續(xù)70us則是邏輯1。在GPIO上升沿后延時(shí)40us左右再采樣能避開信號邊沿抖動這個(gè)“延后采樣”細(xì)節(jié)能讓讀數(shù)據(jù)成功率大幅提升。順帶提一下DHT11每次讀之間的間隔至少要1秒讀太頻繁傳感器會不響應(yīng)。這個(gè)不是HAL庫的問題但用HAL庫做循環(huán)輪詢時(shí)容易忽略。3.4 OLED驅(qū)動I2C/SPI兩條路的取舍hal庫驅(qū)動oled代碼也是高頻搜索詞。SSD1306作為I2C設(shè)備時(shí)HAL庫的做法是每次寫命令或數(shù)據(jù)都調(diào)用HAL_I2C_Mem_Write從設(shè)備地址、控制字節(jié)、數(shù)據(jù)內(nèi)容逐段傳。這種方法有一個(gè)經(jīng)典坑I2C時(shí)鐘配置太高會失敗。F4的I2C1掛在APB1上如果APB1時(shí)鐘是42MHzI2C時(shí)鐘寄存器配置不當(dāng)會導(dǎo)致通信不穩(wěn)定。建議把I2C時(shí)鐘調(diào)到400kHz以下并在初始化后加一個(gè)短延時(shí)。另一個(gè)要注意的是OLED刷新策略。不要在需要顯示的地方臨時(shí)拼一個(gè)命令幀發(fā)過去那樣閃爍明顯。正確做法是維護(hù)一整塊顯存128*64/8 1024字節(jié)需要更新時(shí)修改顯存數(shù)據(jù)然后一次性把整塊顯存發(fā)送到OLED的GDDRAM。SSD1306的頁地址模式可以按頁寫但最穩(wěn)妥的方式是關(guān)閉頁面滾動效果后設(shè)為水平尋址模式連續(xù)寫入。如果追求刷新率建議用SPI接口的OLED模塊。SPI寫SSD1306只需要4根線主頻可以跑到10MHz以上整屏刷新時(shí)間遠(yuǎn)低于I2C。對應(yīng)的HAL調(diào)用是HAL_SPI_Transmit注意OLED的DC引腳要在寫命令和寫數(shù)據(jù)之間切換CS引腳在傳輸前拉低、傳輸后拉高即可。4. 燒錄調(diào)試與固件運(yùn)行問題4.1 Keil5燒錄F4的常見失敗原因keil5燒錄程序stm32f4是每個(gè)新手都會搜的詞。燒錄失敗的原因不外乎三類第一類是Flash下載算法缺失。Keil5如果沒有安裝對應(yīng)的F4器件支持包燒錄時(shí)Flash區(qū)域是空的。解決辦法是在Pack Installer里安裝STM32F4系列的Device Family Pack安裝后keil會自動匹配STM32F4xx Flash下載算法。第二類是芯片型號選錯(cuò)。同一個(gè)F407和F405Flash容量和內(nèi)存映射不同選錯(cuò)型號后下載算法對不上燒錄會報(bào)“Flash Download failed - Cortex-M4”。建議在Options for Target - Device里仔細(xì)核對具體型號而不是只選個(gè)F407VG大概就行。第三類是燒錄器接線不穩(wěn)這是最隱蔽的。SWD只需要SWDIO、SWCLK、GND三根線但很多人燒錄時(shí)沒接復(fù)位線導(dǎo)致偶爾能連上、偶爾連不上。使用ST-LINK或DAP-Link時(shí)如果反復(fù)出現(xiàn)“Cannot access target”先檢查復(fù)位引腳是否有干擾然后把燒錄速度從5MHz降到1MHz再試。4.2 燒錄成功卻不運(yùn)行的排查路徑程序能燒錄但板上沒反應(yīng)這種問題比燒錄失敗還讓人頭疼。我的排查路徑基本是固定的先看復(fù)位引腳電平是否正常NRST有沒有被外部電容拉得太死。再看時(shí)鐘是否起振F4靠外部晶振通過PLL倍頻到168MHz晶振沒焊好或者負(fù)載電容不對系統(tǒng)時(shí)鐘會卡在HSI的16MHz但很多外設(shè)時(shí)序就不對了。排除這些問題后重點(diǎn)查啟動文件中堆棧大小設(shè)置。HAL庫的DMA中斷、串口中斷、RTOS任務(wù)棧都是占用系統(tǒng)棧的如果Stack_Size設(shè)置過小程序會在某個(gè)時(shí)刻進(jìn)入HardFault表現(xiàn)就是燒錄后能跑但運(yùn)行一段時(shí)間就不動了。把啟動文件里的Stack_Size從默認(rèn)0x400加到0x1000是一個(gè)成本極低但見效很快的修改。還有個(gè)小細(xì)節(jié)F4內(nèi)核帶FPU如果工程里啟用了浮點(diǎn)運(yùn)算但不能正常執(zhí)行檢查編譯器選項(xiàng)里是否勾選了FPU: Single Precision同時(shí)確認(rèn)stm32f4xx.h里的__FPU_PRESENT和__TARGET_FPU_VFP宏都已經(jīng)定義。這個(gè)配置不對浮點(diǎn)運(yùn)算會走軟件模擬性能降低十倍以上。5. 從eMMC到國產(chǎn)兼容芯片HAL庫的邊界在哪里5.1 F4外接eMMCSDIO協(xié)議層的復(fù)用stm32f4 emmc這個(gè)關(guān)鍵詞最近被搜得比較多很多人想在F4上掛一個(gè)eMMC當(dāng)大容量存儲。思路其實(shí)很簡單eMMC的物理接口和SD卡高度相似都是走CLK、CMD、DATA0-3這些信號線F4的SDIO外設(shè)本身就可以當(dāng)eMMC控制器用。關(guān)鍵區(qū)別在于初始化流程。SD卡上電后要先發(fā)CMD0進(jìn)入空閑態(tài)然后CMD8、ACMD41判斷SD版本。eMMC有自己的Boot Partition和RPMB分區(qū)不能用ACMD41那種方式直接切到數(shù)據(jù)傳輸模式需要發(fā)CMD1SEND_OP_COND等待eMMC進(jìn)入Ready狀態(tài)再通過CMD2獲取CID、CMD3分配RCA、CMD7選擇分區(qū)最后用CMD17/CMD18讀數(shù)據(jù)、CMD24/CMD25寫數(shù)據(jù)。HAL庫里的HAL_SD_Init已經(jīng)封裝了一部分初始化邏輯但針對eMMC建議把底層卡類型檢測函數(shù)看一下。如果開發(fā)板上的eMMC是4GB以上的高容量版本注意F4的SDIO是SD Spec Version 2.0只支持SD 2.0的容量尋址方式大于2GB的扇區(qū)需要走SDHC模式還好HAL庫默認(rèn)按512字節(jié)塊尋址一般不會有問題。5.2 國產(chǎn)M0/M0芯片的“類HAL庫”回調(diào)兼容性最近在討論py32f003的hal庫中斷回調(diào)函數(shù)有bug嗎這個(gè)問題。這類國產(chǎn)芯片為了兼容ST的生態(tài)確實(shí)也提供了一套命名很像HAL庫的驅(qū)動但底層是基于自家外設(shè)實(shí)現(xiàn)的與ST HAL并不完全等價(jià)。我個(gè)人經(jīng)驗(yàn)是移植這類芯片時(shí)中斷回調(diào)不能無腦照搬ST HAL的邏輯。比如GPIO外部中斷回調(diào)里ST HAL在每次中斷觸發(fā)時(shí)會自動清除中斷標(biāo)志但某些國產(chǎn)芯片的庫不會清需要自己在回調(diào)開頭調(diào)用HAL_GPIO_EXTI_IRQHandler對應(yīng)的底層清除函數(shù)。UART回調(diào)也有差異有些芯片在回調(diào)里直接讀數(shù)據(jù)寄存器會導(dǎo)致丟字節(jié)需要先判斷狀態(tài)位。我的建議是用這類芯片時(shí)第一優(yōu)先讀芯片廠商自己的參考手冊和例程不要依賴ST HAL的使用習(xí)慣。如果確實(shí)發(fā)現(xiàn)回調(diào)在某些情況下不觸發(fā)先用調(diào)試器確認(rèn)中斷標(biāo)志位是否置位再決定是改庫還是改應(yīng)用邏輯。大多數(shù)情況下所謂的“bug”其實(shí)是芯片寄存器行為與ST不同。6. 常見問題速查與避坑筆記6.1 速度、優(yōu)先級、堆棧三件套這三大類問題幾乎覆蓋了90%的HAL庫運(yùn)行異常。整理成表格方便對照排查問題現(xiàn)象常見原因排查與解決辦法串口偶爾丟一幀中斷優(yōu)先級過低被其他中斷打斷在HAL_NVIC_SetPriority中把串口中斷優(yōu)先級設(shè)為高于DMA中斷I2C通信卡死I2C時(shí)鐘配置錯(cuò)誤或總線被別設(shè)備拉死檢查APB1時(shí)鐘設(shè)置時(shí)鐘低于400kHz在初始化后重新HAL_I2C_DeInit再InitSPI讀取數(shù)據(jù)錯(cuò)亂CPOL/CPHA配置錯(cuò)誤或幀長度不匹配對照傳感器手冊確認(rèn)Mode和幀長用邏輯分析儀看波形DMA傳輸完成但回調(diào)不觸發(fā)DMA中斷未開啟或回調(diào)函數(shù)名寫錯(cuò)檢查HAL_DMA_Start_IT參數(shù)、__HAL_DMA_ENABLE_IT配置程序運(yùn)行一段時(shí)間后HardFault棧溢出或數(shù)組越界查看Stack_Size檢查回調(diào)中緩沖區(qū)是否越界寫入PWM輸出無波形RCC時(shí)鐘分頻錯(cuò)誤或預(yù)分頻值超限用CubeMX重新計(jì)算PSC和ARR確認(rèn)輸出引腳是復(fù)用模式6.2 我在1.27.0上踩過的三個(gè)坑最后分享三個(gè)這次升級過程中切切實(shí)實(shí)踩過的坑。第一個(gè)坑是串口接收回調(diào)的參數(shù)含義變了。在舊版本里HAL_UART_RxCpltCallback不帶接收長度數(shù)據(jù)量要自己記。1.27.0里引入的HAL_UARTEx_RxEventCallback雖然好用但如果你同時(shí)使用了老接口接收長度會錯(cuò)亂。我的建議是新工程統(tǒng)一用RxEventCallback老工程升級時(shí)把所有串口接收邏輯全部換到新API不要混用。第二個(gè)坑是DMA傳輸完成后的收尾時(shí)序。SPI DMA傳輸完成后芯片手冊要求等待SPI外設(shè)完全空閑再去訪問數(shù)據(jù)寄存器。1.27.0在某些F4型號上修復(fù)了這個(gè)問題但如果你用的是其他品牌兼容芯片建議在DMA回調(diào)里加上__HAL_SPI_CLEAR_OVRFLAG之類的宏手動清除溢出標(biāo)志。第三個(gè)坑和堆棧有關(guān)。1.27.0版本里如果啟用了HAL_UARTEx_ReceiveToIdle_IT和DMA同時(shí)工作系統(tǒng)棧占用會比純中斷模式高不少。我在一個(gè)跑FreeRTOS的項(xiàng)目里把任務(wù)棧考到1KB結(jié)果系統(tǒng)頻繁進(jìn)入HardFault。最后把任務(wù)棧提到2KB徹底解決。HAL庫的封裝方便是方便但背后的棧開銷確實(shí)比直接操作寄存器高這個(gè)在資源緊張的芯片上要提前評估?；仡^再想HAL庫這個(gè)東西用好的關(guān)鍵在于不把它當(dāng)黑盒。跑起來有問題時(shí)先看庫源碼再看寄存器手冊最后才改應(yīng)用邏輯。1.27.0整體上是一個(gè)值得升級的穩(wěn)定版本如果你手頭項(xiàng)目還不是特別緊急可以找一塊開發(fā)板先跑通我上面提到的這幾個(gè)外設(shè)再遷到正式項(xiàng)目里能省不少事。本文還有配套的精品資源點(diǎn)擊獲取