之前有個同事因為用串口查詢方式發(fā)送數據，被我說了一頓，明明有 DMA 資源，竟然放著不用，對于魚鷹這種性能強迫癥來說，肯定無法忍受，所以當時就和他說，有時間你把它改一下。

誰知道過了好幾個月他才有時間弄這個，然后還是出了問題，沒法子，只能找我解決了。

現象是這樣的，使用查詢方式，一點問題沒有，從機可以正常接收數據，一旦換成 DMA，從機就無法正常解析數據了，從機緩存的數據也不正確。

因為當時我也一臉懵逼，也不知道他做了什么操作導致的，畢竟他調用的 DMA 發(fā)送函數都是魚鷹很久以前寫的，也是久經考驗的代碼，不可能出現問題才對。

所以在沒有頭緒的情況下，直接同時調試兩顆單片機了。

對，你沒有看錯，就是使用兩個調試器同時調試兩個單片機。

很簡單，就在下面的圖中選擇即可，估計有很多老司機都不知道這個吧。（不同工程）

這樣一臺電腦就可以同時調試主機和從機了。

當時首先查看了 DMA 外設和 UART 寄存器情況，發(fā)現并沒有問題（畢竟如果這個錯了，再怎么查應用代碼也是沒用的，排查問題要講究先后順序）。

又在線查了一會發(fā)現，如果我在 DMA 發(fā)送函數后打上斷點，從機是可以正常解析的，這一點又讓我疑惑了，所以為了防止從機代碼可能有問題，直接讓同事用一個串口模塊接收數據。

串口助手顯示，發(fā)送的字節(jié)數是正確的，但是只有幀頭幾個字節(jié)對的，其它字節(jié)全是錯的。

一看到這里，魚鷹大概就知道了，大概率是 DMA 發(fā)送緩沖區(qū)被篡改了，一查函數調用，瞬間就明白了是怎么回事，函數調用大概如下（細節(jié)沒有展示）：

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 發(fā)送的緩沖區(qū)，魚鷹也是醉了。

那么為什么查詢方式下，這樣的代碼不會出錯，DMA 方式就錯了？

要解答這樣的問題，基礎必須扎實：

1、DMA 傳輸原理

2、局部變量存放位置與特性。

只要知道這兩點，這個問題就很容易避免。

但事實上，很多人只會大概用，根本沒有真正理解。

DMA  串口傳輸憑什么說效率高？是因為它讓串口速率傳輸更快了嗎？一個字節(jié)傳輸本來要 1 ms，用 DMA 只要 0.5 ms？估計很多人都是這么理解的吧。

事實上，DMA 并沒有加快傳輸速率，只不過是把傳輸的任務轉交給專業(yè)的而言《數據傳輸還用 CPU？不如交給 DMA 吧！》，而 CPU 就可以專心干剩下的事情。

注意這里的轉交一詞，CPU 把必要的傳輸信息（比如傳輸地址、大小等）告訴 DMA 后，一般會啟動 DMA，之后立刻運行后面的代碼，但此時 DMA 緩存地址里面的數據并沒全部發(fā)送出去，如果這個緩存用的是局部變量，離開這個函數后，局部變量被回收，并會繼續(xù)給其他函數使用，此時這個緩存的數據就被篡改了，這樣 DMA 發(fā)送出去的數據當然不正確。

所以，從這個角度來說，DMA 并沒有加快串口本身的傳輸速度，只是解放了 CPU 資源而已。但是 CPU 被解放了， DMA 所使用的 緩存 資源可不能也隨之解放呀，只能等發(fā)送完畢后才能釋放。所以最簡單的方法是在 緩存 前面加一個 static 。

那么為什么查詢不會出問題呢？查詢是把所有緩存中的數據發(fā)送出去后，才會離開當前函數，這樣局部變量始終存在，也就不會有問題了，不像 DMA 一樣扔到緩存里面就溜之大吉，局部變量也隨之溜了。

但是，還有一種特殊的局部變量，也能達到全局的效果。這就是操作系統中的主函數的局部變量。

void task()

{

uint32_t buff[32]; // 局部變量，但效果和全局變量差不多。

while(1)

{

}

}因為任務一般會被死循環(huán)包含，永不退出（前提條件），所以這里的局部變量也就不會被釋放掉，所以有些情況下，為了更好的使用資源，會采用這種方式。

好了，今天的分享到此結束，有收獲的話，記得三連支持一波呦！

往期推薦：

解析內核的Makefile、Kconfig和.config之間的關聯！

極客感十足的電子胸牌 ART-Badge V2.0開發(fā)記錄！