關鍵字：回調函數，HAL庫

目錄預覽

1.回調函數

2.STM32固件庫里的回調函數

3.STM32庫函數里的回調機制及觸發事件

4.常見問題

01 回調函數

有人對STM32固件庫里的回調函數有些好奇甚至糾結，這里簡單地介紹下，以供參考。其實從用法及功能上講他們并沒有什么特別的，跟其他函數一樣，也是實現特定功能的代碼段。一般來講，所謂回調函數，泛指基于事件觸發而被調用執行的函數，簡單點說，就是條件滿足了就調用的函數，往往會跟函數指針結合起來通過函數指針實現調用。

經常會有人基于類似下面的代碼介紹回調函數：

在上面代碼中，那四個有關加減乘除的函數可以看成回調函數，具體何時被調用，根據函數Compute(float a,float b,float(*Action)(float a,float b))里的函數指針的賦值情況來定，被賦予哪個回調函數的地址就調用哪個回調函數。當然，使用函數指針并不是回調函數的核心特征，因事件驅動而被調用才是其核心特征。

生活中我們有時會對某人說，回頭再談、回頭再聊。潛臺詞往往就是等時機成熟了、條件滿足了再來具體交涉。這里就充滿著濃濃的回調意味。

回調函數可以理解為事件響應函數或者說事件驅動函數。即使相同的事件、基于不同的場景可能會有不同應對處理，從軟件代碼角度講就對應不同的回調函數代碼。

我們不妨看個生活中的例子。生活中有人中了六合彩了，針對這一事件，中獎人可能有下面諸多舉動之一【這里簡化下，多選一】。但這件事發生在不同人身上，右邊的選擇很可能不盡一樣。換言之，中獎了，到底會選擇右邊哪一項還得結合具體的人來定。

圖1 中六合彩的可能后續行為

我們再切換到STM32的嵌入式開發中來，以UART接收完成事件為例。針對這一事件，不同的應用場景的應對處理往往也是五花八門、五彩繽紛。

圖2 UART接收完成后可能后續動作

顯然，特定的應用場景對應著特定的回調函數，一般來講，沒法簡單地僅僅基于事件就擬定一段既能適用于各種場景而又富有針對性的代碼。

結合上面的描述，稍微小結下。回調函數除了具有基于事件的觸發而被調用執行的特征外，還具有相同事件因應不同應用場景可能需要不同的回調函數之特征，即基于特定應用場景的回調函數其內容具有特定性。

02

STM32固件庫里的回調函數

說到這里，我們具體結合STM32外設固件庫里回調函數來聊聊。

首先，作為一個函數庫，除了個別初始化函數外，里面不存在現存的完整的回調函數。結合前面的介紹，我們知道回調函數需要結合具體場景而擬定，作為函數庫根本做不到這一點，它沒法事先知曉發生某個事件時不同的應用會需要采取怎樣的操作。

其次，STM32庫函數的確采用了回調機制，并基于可能的各種事件為STM32開發者預留了只有函數定義而無具體內容的空回調函數，或者是只定義了一些基于各類事件的函數指針，具體的回調函數需要用戶完成并將函數地址賦給相應的函數指針而被調用。簡單點說，函數庫給我們事先預留了眾多的回調函數接口。

STM32固件庫里的回調函數采用了兩種調用方式：

第一種是legacy方式，傳統的回調方式，庫以weak方式定義了各種空的回調函數，像下面這些。STM32庫里都給我們準備好了?！鞠旅媸怯嘘PUART部分事件的弱回調函數體，內容為空】

圖3 UART傳輸事件相關弱回調函數定義

具體開發時，我們根據事件和應用場景基于類似上面的weak函數進行重寫，重寫時拿掉weak，庫里預留的弱定義函數盡量不用動它。比方像下面這些都是最終的用戶回調函數。

圖4 UART傳輸事件相關的用戶回調函數

另外一種就是指針方式，或稱注冊方式。即函數庫里事先基于各類事件定義好了各種回調函數指針，具體的回調函數由用戶基于不同事件和應用需求撰寫，然后將函數地址賦給函數指針，這個動作我們稱之為回調函數進行注冊，之后回調函數就可以通過函數指針而被適時調用。

比方下面是UART外設里定義的一些函數指針：【星號所指的是與UART傳輸完成事件有關的回調函數所用的指針】

圖5 UART傳輸事件相關的回調函數指針

當我們將回調函數寫好后，將函數地址賦給函數指針即可在相應事件發生時被調用。比方類似下面的操作代碼。紅星標所指代碼就是在做回調函數的注冊。

圖6 UART傳輸完成事件用戶回調函數及注冊

給函數指針賦地址可以直接賦地址或通過調用庫函數xxx_RegisterCallback完成【見上圖星標代碼】。

這種指針方式需要我們對C語言中的結構體、函數指針有相應的了解，庫只是給我們提供了相應的函數指針，具體的用戶回調函數由用戶根據需要來編寫，將其地址賦給相應的函數指針以供調用。

而前面介紹的傳統型回調函數，庫則幫我們把可能涉及到的回調函數全部以弱定義的方式都準備好了，我們按需針對性選用，去掉weak填空重寫。使用起來相對更直觀些，無需我們對函數指針有太多了解。

目前STM32庫回調機制中，作為用戶到底使用上面的哪種回調方式呢？在每個系列的固件庫的配置頭文件中有針對各個外設事件回調函數使用方式的選擇，比方以STM32F4系列為例，這里有個stm32f4xx_hal_conf.h的頭文件，我們可以看到基于各個外設事件回調函數使用方式選擇的宏。

圖7 回調函數調用方式的選擇配置

若我們不對該頭文件的相應外設事件的回調函數調用方式的宏定義做調整，則默認傳統回調方式，即legacy方式，非指針方式。若將相應的宏值改為1，則該外設事件相關回調函數采用指針注冊方式。

03 STM32庫函數里的回調機制及觸發事件

整體上講，STM32外設庫里的API函數大體由三部分組成，分別是：

初始化函數

啟動型執行函數

回調函數【弱定義函數或回調函數指針，最終靠用戶具體完成編寫】

這樣的安排，讓整個工程代碼結構比較清晰，可以讓人快速了解庫結構，同時現存的API函數大大減少開發工作量，預留的回調函數接口一方面給開發者提供了便利，另一方面讓用戶基于不同應用場景自由組織代碼而又不破壞整個軟件架構。

對于回調函數，可以由哪些事件觸發呢？大致分三類，分別是外設初始化操作、外設處理完成【中斷】事件、外設出錯【中斷】事件。我們關注最多是外設處理完成中斷事件相關的回調函數。

圖8 回調函數觸發事件的分類

04 常見問題

4.1 STM32庫函數里的回調函數是什么，有何用？

回調函數終究乃用戶所編寫，是用戶基于特定事件和應用需求而編寫的功能模塊，與其他函數并無本質區別。形式上講，STM32庫預先為用戶做了回調函數的弱定義或基于事件的函數指針的定義。因基于特定條件發生后被調用執行而被冠以回調稱號。

嚴格來講，庫函數里沒有完整的回調函數，只有基于各類事件的弱定義的不具備實際功能的空回調函數，或者是針對各類事件而定義的各種用于調用回調函數的函數指針。我們的程序監測相應條件或事件往往是有的放矢，當相應事件出現時我們需要做相應的處理，這正是回調函數要實現的功能，也是其功用所在。

4.2 STM32工程里的回調函數與中斷函數有什么區別？

STM32外設庫里的回調函數的確多數時候跟中斷事件及中斷服務程序息息相關，往往在中斷服務程序中基于特定事件調用相應的用戶回調函數。很多時候，我們完全可以將用戶回調函數看成中斷函數的一個調用模塊或延伸。

一個中斷服務程序里可以因不同事件而調用不同的回調函數，即一個中斷服務程序里可能包含多個不同的回調函數。比方，我們在定時器中斷服務程序里可以涉及多個事件及相應的用戶回調函數，定時器中斷服務程序可能涉及更新事件、不同通道的比較事件或捕獲事件，相應的用戶回調函數往往因應用場景而異。

當然，回調函數的調用還可以是中斷事件以外的其他事件觸發調用，比方可以基于初始化操作來調用相應初始化回調函數。當然，在庫里對某個外設的初始化可能有些默認操作，但這個默認操作很難是放之四海而皆準的操作，這時我們就得根據實際應用針對性編寫初始化代碼，即初始化型回調函數。

4.3 STM32庫函數里的回調函數是否可以不用？

STM32庫函數里的回調機制是庫設計者為了便于軟件框架清晰、減少開發者工作量等因素事先準備的函數聲明及接口，用戶使用時只需根據具體應用編寫相關函數體。當然，你如果不想理睬這些回調函數聲明及定義也是可以的，你根據具體應用自行組織代碼完全可行。

4.4 STM32庫函數里似乎存在著類似半成品的庫回調函數？

STM32庫函數里的確準備了一些包含用戶回調函數的由庫定義的回調函數，是庫設計者基于各類特定事件而準備的回調函數，它會針對特定事件做一些基本而必要的操作，比方狀態的檢查、標志監測及清除，但它沒有辦法徹底寫完整，因為它無法知道該事件發生后用戶的真實需求是什么，該如何操作，所以它終究還是需要調用真正的用戶回調函數。這樣做的目的還是為了給開發者減少開發工作量、以及減少出錯等。

我們不妨具體看個實例。下面的回調函數采樣的指針注冊方式，我們看看UART的DMA傳輸完成中斷里傳輸完成的回調函數的調用過程。

首先，在UART的DMA啟動函數HAL_UART_Transmit_ DMA()里有這樣一部分內容：

圖9 外設啟動運行代碼中庫回調函數的賦值

庫里就DMA傳輸事件準備了幾個回調函數【傳輸完成、半完成、出錯】，即上圖中紅線標示出來的。其實這幾個回調函數還不算完整的用戶回調函數，是庫定義的并會做一些在它看來用戶必定需要完成的一些操作，它事先幫助完成，之后才調用最終的用戶回調函數。我們以傳輸完成事件為例來看看，上圖星號所標的函數。

圖10 庫回調函數進一步調回用戶回調函數

在這個庫定義的UART_DMATransmitCplt()函數里，它對DMA的傳輸模式做了判斷，如果是Normal模式，就將UART的傳輸數據長度設置為0，禁止DMA后續傳輸功能，使能UART傳輸完成中斷的使能。然后才來調用用戶回調函數【上圖中箭頭所指】。如果DMA工作在循環模式，代碼進到UART_DMATransmitCplt()函數后就直接調用最終的用戶回調函數。也就說這些庫定義的回調函數在用戶回調函數的基礎上做了些必要操作，用戶回調函數可以看成這類庫回調函數的子集。

4.5 基于STM32庫來組織用戶回調函數要注意什么？

前面提過了，用戶回調函數主要基于初始化事件或中斷事件而組織的代碼。那些中斷事件的回調函數的調用基本都是在中斷服務程序里發生的。所以，我們在編寫回調函數時要結合具體情況靈活地組織代碼。要考慮中斷優先級、具體事件響應的實時性等。具體點說，我們在組織回調函數時，要考慮是否一定要一股腦地全寫在中斷服務程序里，會不會影響別的中斷響應。對于有些不緊急而又耗時的事件響應代碼，可以考慮只在回調函數里設置相應標志，真正的處理代碼放到主循環去完成。

還提醒一點，STM32庫設計者主動給我們準備了弱定義回調函數或基于各個事件的回調函數指針，盡管很豐富了，但未必能包羅萬象，必要時我們可能還得根據具體情況來額外組織些類似回調函數的事件/中斷響應代碼。

關于STM32 HAL庫里的回調函數就簡單介紹到這里，希望能幫到一些STM32開發者。

完整內容請點擊“閱讀原文”下載原文檔。

訂閱號

關注STM32

視頻號

B站賬號

▽點擊“閱讀原文”，可下載原文檔