有人使用STM32H7芯片做些事情，發現基于ST公司的HAL庫開發UART1的DMA收發時可以輕松實現，而當使用ST的LL庫組織代碼時，卻沒法實現UART的DMA傳輸。

感覺上就是使用HAL庫編寫代碼功能正常而基于LL庫則不行。真是這樣嗎？

使用STM32CubeMx進行圖形化配置，并生成基于HAL庫的初始代碼，要實現UART收發功能的DMA傳輸的話，除了安排好的收發緩沖內存外，再就只需調用下面兩個HAL庫的API函數即可進行功能驗證。

從功能實現上講，使用HAL庫及相應API還是很方便、很簡單的。每個API函數就像個黑盒子，對于里面的內容，如果你不點進去閱讀是不會知曉的。

不過，建議盡可能地多點進去瞧瞧，那里往往別有洞天。

如果基于LL庫來組織代碼的話，先使用STM32CubeMx進行配置并生成基于LL庫的初始化代碼。

基于CubeMx配置完畢后生成初始化工程，準備收發緩沖內存，然后添加用戶代碼。

剛開始用戶代碼是這樣編寫安排的。見下面代碼截圖。

上圖中A處代碼的作用就是開啟兩個DMA stream的功能，即對相關DMA Stream的控制寄存器的使能位進行使能置1。

編譯無錯后運行代碼，可是根本沒有數據的收發動作發生。看來，跟反饋者的癥狀一樣。

沒辦法，硬著頭皮核查代碼。除了核查我添加的用戶代碼外，還核查UART及DMA的初始化代碼。看來看去，似乎該有的都有了，該寫的都寫了。

后來，根據代碼里涉及到的寄存器去跟STM32H7手冊里寄存器做比較閱讀。

在查看DMA各個stream配置控制寄存器【DMA_SxCR】內容時，突然發現并想起了點什么。

其實也是之前在別的DMA應用場合也碰到過的類似問題。

下面為該寄存器的內容布局截圖。

隱約記得，該DMA Stream或Channel的控制使能位為0時才能做DMA相關其它參數的配置的。

我們可以在手冊里找到針對該位的明確描述：

這里的意思是說，要想讓某DMA stream工作，必須令該EN位為1。

不過，當該EN位為1時時，是不允許對DMA及相應FIFO寄存器做配置的。

換言之，若要針對某Stream做DMA相關配置，得先讓該控制寄存器的EN位保持為0狀態。

而在我的用戶代碼里，對EN位寫1操作則放在了對DMA做各種配置的前面，即上面代碼截圖的A處。

既然這樣，我們把對DMA控制寄存器EN位的置1操作放在其它DMA相關配置之后就應該可以了，即從上面代碼截圖中的A處拉到B處。

然后，進行測試，結果果真正常了。

其實就是一個配置代碼順序問題，卡了半天。

如果不是用LL庫而是用HAL庫可能就不太容易碰到這個問題。前面說過了，基于HAL庫的API函數像個黑盒子，它幫我們處理了很多細節性、判斷性的東西。

基于LL庫組織的代碼，相比HAL庫組織的代碼，代碼精簡、流程清晰、運行高效。不過，使用LL庫做開發需要開發者對芯片各個模塊的工作原理，操作流程有更清晰、更精準的了解，同時往往還需要開發者對應用相關的寄存器有更細致、深入的把握。

而HAL庫往往事先幫我們充分考慮到了基于硬件需求的操作流程、時序，基于軟件層面的諸多事件及狀態的互斥管理，以及不同STM32系列的代碼兼容性，并做了很好、很全面的封裝。

所以我們在利用HAL庫來實現相應功能時，往往無須對操作流程、時序以及寄存器本身做過多的了解就可以完成。

從開發角度講，利用HAL庫往往比利用LL庫能更快地完成任務，同時基于HAL庫的代碼也有更好的移植性，代價就是代碼相對LL庫要龐大些。

對應STM32開發者而言，即使基于HAL庫開發了一些STM32項目，對于芯片的諸多功能細節以及寄存器的了解往往可能比較有限。當然，這點因人而異吧，不可說死。

對于HAL庫和LL庫的選用，我們每個人可以根據自身情況來。比方，對芯片軟硬件不熟悉時、任務緊急時先使用HAL庫，等對芯片及庫函數熟悉、任務不緊急時可以切換到LL庫。

或者說，只是做些功能性驗證確認，使用HAL庫組織代碼也是非常快捷方便的。

當然，一個工程里HAL庫、LL庫是可以同時并存的。另外，當我們對芯片寄存器、內核指令系統足夠熟悉時，甚至可以嘗試使用匯編語言做MCU編程開發。

作為開發人員，基于HAL庫組織代碼和基于匯編指令組織代碼實現相同功能時，對我們自身的挑戰及相應的收獲是不可同日而語的。

審核編輯：劉清