有人想使用STM32U5系列的GPDMA的burst【分组、节拍、突发】传输功能，似乎遇到了点阻碍。我这里尝试下，稍作演示，仅供参考。

* U! x9 ^" Z7 G- M  i8 d+ Y: x

我用TIMER1更新事件触发DMA， DMA工作在非循环模式，DMA将数据从源内存区传输到目的内存区。我先准备下面两个数组。

; I% F! q1 L  z! H$ h+ m

当两端访问数据宽度设置一样，burst大小始终为1时，传输是很顺畅的，不会有啥问题，结果符合预期。

基于上面配置，结果就很正常。结果如下图，也正是我期望的结果。

当我们尝试使用DMA burst功能时，发现结果就不对劲了，比方我希望源端按字节读取，然后基于BURST功能打包，目的端按半字来提取，发现结果跟预期不一样。我们一起看看：

; Q9 o1 F' z/ e& @. V3 F

显然，每半个字的高字节都是填充的0。那是怎么回事呢？

我们再看看源端按字节读取，然后基于BURST功能打包，目的端按字来提取，看看结果又会怎么样？

" T7 K2 ^: p3 X( r" q, h6 H

- h9 l  C8 f/ ?( K' N/ F8 y

结果变成了上面的那个样子，显然结果严重不符合预期。

% a3 h0 }' {" W3 o9 q

那是怎么回事呢？ 经过反复修改参数，结合我之前之前玩过F4系列DMA burst传输功能以及对STM32 DMA burst功能的理解，感觉这里的BUSRT传输应该是工作了。对DMA burst的基本配置以及我的用户实现代码还是比较自信的。 而且目前结果上来看，有数据传输，且数据结果是有规律的，数据并不混乱，程序也没跑飞，就是感觉数据好像在DMA BURST传输过程中被处理过。

刚好这两天也就随机性瞄了下这块，隐约记得它是有数据处理功能的。【说实话，U5系列DMA好复杂，比其它M4核STM32的DMA复杂很多。要沉下心来细看真不易！！】

, P/ G2 v8 k7 M' {: _" K' g

想到这里，不禁自我怀疑。难道配置哪里还有问题，没做到位？

继续查看CubeMx界面下有关GPDMA的配置，嗯？我看到了一直被我无视的一个地方：

1 }& G4 a* J  n% G$ B

0 x$ l1 n. t% G* \% H

难道问题是在这里？此处有乾坤？

! P6 }6 I& y  I7 c( r" v* \

。。。。。。其实，问题真的就在这里。

当我将那个Data Handling 配置由Disable转为Enable基本恍然大悟了。

7 D( D1 K$ n# L3 h9 F4 N

我们回过头去查看手册，手册里面对GPDMA的数据处理功能也做了描述。下图是相关描述里的一个表格截图。

! V, m7 |1 R+ a* k  {, S4 ~

关于GPDMA的数据处理功能，这里就不解读了，需要时我们可以自行研读手册。对STM32U5的DMA功能，我只能说：哇塞！功能真强大！

5 Q9 R. w8 M) d$ [0 W7 T  x  U$ _

我们还是继续回到上面的测试。当我使能Data handling功能，并选中满足我当前需求的一个选项后，一切便拨云见日。

+ Y  B, d% Z+ X# _6 n6 n2 s

, [8 k" X! J" E/ I0 u# g& O( t2 ?

注意上面截图中那个关于数据对齐的选项。意思还是比较简单明了，当源数据宽度小于目的端数据宽度时，按照目的端数据宽度打包摆放。

9 ]) L* d; }! E! `9 N" W) O

当我在前面BURST配置的前提下，再加上这个Data Handling配置就能输出符合预期的结果了。

, D' x* u. O0 ~; j

换句话说，我前面的DMA Burst基本配置是没有问题的，只是没有选择合适的Data Handling方式导致没有呈现我们预期的效果，这也正是它跟其它系列不一样的地方。

8 z. B% s, x9 x& f

这里涉及的用户代码很简单，也干脆贴过来，供有需要的参考【初始化配置使用CubeMx】：

最后顺便提醒一点，上面那个DMA启动函数里的size变量【箭头所指的地方】，是按照字节数来算的，这点要注意，这也是跟其它系列不一样的地方。

, i5 X/ D& I# ~2 Q0 ~

转载自 茶话MCU