DMA 串口传输原理解析

控制/MCU

1883人已加入

描述

之前有个同事因为用串口查询方式发送数据,被我说了一顿,明明有 DMA 资源,竟然放着不用,对于鱼鹰这种性能强迫症来说,肯定无法忍受,所以当时就和他说,有时间你把它改一下。

谁知道过了好几个月他才有时间弄这个,然后还是出了问题,没法子,只能找我解决了。

现象是这样的,使用查询方式,一点问题没有,从机可以正常接收数据,一旦换成 DMA,从机就无法正常解析数据了,从机缓存的数据也不正确。

因为当时我也一脸懵逼,也不知道他做了什么操作导致的,毕竟他调用的 DMA 发送函数都是鱼鹰很久以前写的,也是久经考验的代码,不可能出现问题才对。

所以在没有头绪的情况下,直接同时调试两颗单片机了。

对,你没有看错,就是使用两个调试器同时调试两个单片机。

很简单,就在下面的图中选择即可,估计有很多老司机都不知道这个吧。(不同工程)

单片机

这样一台电脑就可以同时调试主机和从机了。

当时首先查看了 DMA 外设和 UART 寄存器情况,发现并没有问题(毕竟如果这个错了,再怎么查应用代码也是没用的,排查问题要讲究先后顺序)。

又在线查了一会发现,如果我在 DMA 发送函数后打上断点,从机是可以正常解析的,这一点又让我疑惑了,所以为了防止从机代码可能有问题,直接让同事用一个串口模块接收数据。

串口助手显示,发送的字节数是正确的,但是只有帧头几个字节对的,其它字节全是错的。

一看到这里,鱼鹰大概就知道了,大概率是 DMA 发送缓冲区被篡改了,一查函数调用,瞬间就明白了是怎么回事,函数调用大概如下(细节没有展示):

void dma_send(DMA_Channel_TypeDef *DMAx, void *buff, uint8_t size){  DMAx->CNDTR = size;  DMAx->CMAR  = buff;}

void send_data(){  uint8_t buff[8];  buff[0] = 1;  buff[1] = 2;     ……  dma_send(dma1, buff, 8); }

竟然用局部数组变量作为 DMA 发送的缓冲区,鱼鹰也是醉了。

那么为什么查询方式下,这样的代码不会出错,DMA 方式就错了?

要解答这样的问题,基础必须扎实:

1、DMA 传输原理

2、局部变量存放位置与特性。

只要知道这两点,这个问题就很容易避免。

但事实上,很多人只会大概用,根本没有真正理解。

DMA  串口传输凭什么说效率高?是因为它让串口速率传输更快了吗?一个字节传输本来要 1 ms,用 DMA 只要 0.5 ms?估计很多人都是这么理解的吧。

事实上,DMA 并没有加快传输速率,只不过是把传输的任务转交给专业的而言《数据传输还用 CPU?不如交给 DMA 吧!》,而 CPU 就可以专心干剩下的事情。

注意这里的转交一词,CPU 把必要的传输信息(比如传输地址、大小等)告诉 DMA 后,一般会启动 DMA,之后立刻运行后面的代码,但此时 DMA 缓存地址里面的数据并没全部发送出去,如果这个缓存用的是局部变量,离开这个函数后,局部变量被回收,并会继续给其他函数使用,此时这个缓存的数据就被篡改了,这样 DMA 发送出去的数据当然不正确。

所以,从这个角度来说,DMA 并没有加快串口本身的传输速度,只是解放了 CPU 资源而已。但是 CPU 被解放了, DMA 所使用的 缓存 资源可不能也随之解放呀,只能等发送完毕后才能释放。所以最简单的方法是在 缓存 前面加一个 static 。

那么为什么查询不会出问题呢?查询是把所有缓存中的数据发送出去后,才会离开当前函数,这样局部变量始终存在,也就不会有问题了,不像 DMA 一样扔到缓存里面就溜之大吉,局部变量也随之溜了。

但是,还有一种特殊的局部变量,也能达到全局的效果。这就是操作系统中的主函数的局部变量。

void  task(){  uint32_t buff[32]; // 局部变量,但效果和全局变量差不多。  while(1)  {  }}

因为任务一般会被死循环包含,永不退出(前提条件),所以这里的局部变量也就不会被释放掉,所以有些情况下,为了更好的使用资源,会采用这种方式。

好了,今天的分享到此结束,有收获的话,记得三连支持一波呦!

编辑:黄飞

 

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分