有人想使用STM32U5系列的GPDMA的burst【分組、節(jié)拍、突發(fā)】傳輸功能，似乎遇到了點阻礙。我這里嘗試下，稍作演示，僅供參考。

我用TIMER1更新事件觸發(fā)DMA， DMA工作在非循環(huán)模式，DMA將數(shù)據(jù)從源內(nèi)存區(qū)傳輸?shù)侥康膬?nèi)存區(qū)。我先準備下面兩個數(shù)組。

當兩端訪問數(shù)據(jù)寬度設(shè)置一樣，burst大小始終為1時，傳輸是很順暢的，不會有啥問題，結(jié)果符合預期。

基于上面配置，結(jié)果就很正常。結(jié)果如下圖，也正是我期望的結(jié)果。

當我們嘗試使用DMAburst功能時，發(fā)現(xiàn)結(jié)果就不對勁了，比方我希望源端按字節(jié)讀取，然后基于BURST功能打包，目的端按半字來提取，發(fā)現(xiàn)結(jié)果跟預期不一樣。我們一起看看：

顯然，每半個字的高字節(jié)都是填充的0。那是怎么回事呢？

我們再看看源端按字節(jié)讀取，然后基于BURST功能打包，目的端按字來提取，看看結(jié)果又會怎么樣？

結(jié)果變成了上面的那個樣子，顯然結(jié)果嚴重不符合預期。

那是怎么回事呢？ 經(jīng)過反復修改參數(shù)，結(jié)合我之前之前玩過F4系列DMA burst傳輸功能以及對STM32 DMA burst功能的理解，感覺這里的BUSRT傳輸應該是工作了。對DMA burst的基本配置以及我的用戶實現(xiàn)代碼還是比較自信的。而且目前結(jié)果上來看，有數(shù)據(jù)傳輸，且數(shù)據(jù)結(jié)果是有規(guī)律的，數(shù)據(jù)并不混亂，程序也沒跑飛，就是感覺數(shù)據(jù)好像在DMABURST傳輸過程中被處理過。

剛好這兩天也就隨機性瞄了下這塊，隱約記得它是有數(shù)據(jù)處理功能的?！菊f實話，U5系列DMA好復雜，比其它M4核STM32的DMA復雜很多。要沉下心來細看真不易??！】

想到這里，不禁自我懷疑。難道配置哪里還有問題，沒做到位？

繼續(xù)查看CubeMx界面下有關(guān)GPDMA的配置，嗯？我看到了一直被我無視的一個地方：

難道問題是在這里？此處有乾坤？

。。。。。。其實，問題真的就在這里。

當我將那個DataHandling 配置由Disable轉(zhuǎn)為Enable基本恍然大悟了。

我們回過頭去查看手冊，手冊里面對GPDMA的數(shù)據(jù)處理功能也做了描述。下圖是相關(guān)描述里的一個表格截圖。

關(guān)于GPDMA的數(shù)據(jù)處理功能，這里就不解讀了，需要時我們可以自行研讀手冊。對STM32U5的DMA功能，我只能說：哇塞！功能真強大！

我們還是繼續(xù)回到上面的測試。當我使能Datahandling功能，并選中滿足我當前需求的一個選項后，一切便撥云見日。

注意上面截圖中那個關(guān)于數(shù)據(jù)對齊的選項。意思還是比較簡單明了，當源數(shù)據(jù)寬度小于目的端數(shù)據(jù)寬度時，按照目的端數(shù)據(jù)寬度打包擺放。

當我在前面BURST配置的前提下，再加上這個Data Handling配置就能輸出符合預期的結(jié)果了。

換句話說，我前面的DMA Burst基本配置是沒有問題的，只是沒有選擇合適的Data Handling方式導致沒有呈現(xiàn)我們預期的效果，這也正是它跟其它系列不一樣的地方。

這里涉及的用戶代碼很簡單，也干脆貼過來，供有需要的參考【初始化配置使用CubeMx】：

最后順便提醒一點，上面那個DMA啟動函數(shù)里的size變量【箭頭所指的地方】，是按照字節(jié)數(shù)來算的，這點要注意，這也是跟其它系列不一樣的地方。

審核編輯 ：李倩