
有人想使用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变量【箭头所指的地方】,是按照字节数来算的,这点要注意,这也是跟其它系列不一样的地方。 转载自 茶话MCU |
STM32U5低功耗测试
STM32怎么选型
内存配置的艺术:STM32为嵌入式系统高端UI优化RAM和闪存的三大策略
【STM32U545】实现CAN数据收发
【我的STM32U5 项目秀】+04-MPU6050在STM32U5上的移植
实战经验 | 基于 STM32U5 创建 USBx_CustomHID 通信
STM32U5 x E-BIKE,记录你的骑行多巴胺
基于STM32U5系列TIMER+DMA+DAC应用经验分享
实战经验 | 基于 STM32U5 片内温度传感器正确测算温度
【文末有礼】新款STM32U5:让便携产品拥有惊艳图效