【温馨提醒：手机模式下，图片可点击放大查看】
有人想使用STM32U5系列的GPDMA的burst【分组、节拍、突发】传输功能，似乎遇到了点阻碍。我这里尝试下，稍作演示，仅供参考。
我用TIMER1更新事件触发DMA， DMA工作在非循环模式，DMA将数据从源内存区传输到目的内存区。我先准备下面两个数组。
当两端访问数据宽度设置一样，burst大小始终为1时，传输是很顺畅的，不会有啥问题，结果符合预期。
基于上面配置，结果就很正常。结果如下图，也正是我期望的结果。
当我们尝试使用DMA burst功能时，发现结果就不对劲了，比方我希望源端按字节读取，然后基于BURST功能打包，目的端按半字来提取，发现结果跟预期不一样。我们一起看看：
显然，每半个字的高字节都是填充的0。那是怎么回事呢？
我们再看看源端按字节读取，然后基于BURST功能打包，目的端按字来提取，看看结果又会怎么样？
结果变成了上面的那个样子，显然结果严重不符合预期。
那是怎么回事呢？ 经过反复修改参数，结合我之前之前玩过F4系列DMA burst传输功能以及对STM32 DMA burst功能的理解，感觉这里的BUSRT传输应该是工作了。对DMA burst的基本配置以及我的用户实现代码还是比较自信的。 而且目前结果上来看，有数据传输，且数据结果是有规律的，数据并不混乱，程序也没跑飞，就是感觉数据好像在DMA BURST传输过程中被处理过。
刚好这两天也就随机性瞄了下这块，隐约记得它是有数据处理功能的。【说实话，U5系列DMA好复杂，比其它M4核STM32的DMA复杂很多。要沉下心来细看真不易！！】
想到这里，不禁自我怀疑。难道配置哪里还有问题，没做到位？
继续查看CubeMx界面下有关GPDMA的配置，嗯？我看到了一直被我无视的一个地方：
难道问题是在这里？此处有乾坤？
。。。。。。其实，问题真的就在这里。
当我将那个Data Handling 配置由Disable转为Enable基本恍然大悟了。
我们回过头去查看手册，手册里面对GPDMA的数据处理功能也做了描述。下图是相关描述里的一个表格截图。
关于GPDMA的数据处理功能，这里就不解读了，需要时我们可以自行研读手册。对STM32U5的DMA功能，我只能说：哇塞！功能真强大！
我们还是继续回到上面的测试。当我使能Data handling功能，并选中满足我当前需求的一个选项后，一切便拨云见日。
注意上面截图中那个关于数据对齐的选项。意思还是比较简单明了，当源数据宽度小于目的端数据宽度时，按照目的端数据宽度打包摆放。
当我在前面BURST配置的前提下，再加上这个Data Handling配置就能输出符合预期的结果了。
换句话说，我前面的DMA Burst基本配置是没有问题的，只是没有选择合适的Data Handling方式导致没有呈现我们预期的效果，这也正是它跟其它系列不一样的地方。
这里涉及的用户代码很简单，也干脆贴过来，供有需要的参考【初始化配置使用CubeMx】：
最后顺便提醒一点，上面那个DMA启动函数里的size变量【箭头所指的地方】，是按照字节数来算的，这点要注意，这也是跟其它系列不一样的地方。
好，关于这个话题就分享到这里！祝君好运！共进！
******************************************
往期话题阅读链接【点击即可阅读】：
