數(shù)據(jù)處理時為什么要從DMA緩存空間中獲??？

筆記中最后得出一個串口接收的總結(jié)“空閑中斷 + DMA + 隊列 + 內(nèi)存管理 + 定時控制”。因為空閑中斷的誤觸發(fā)，導(dǎo)致我們不得不使用定時器來達到接收完整一幀的效果，這樣一來，就會導(dǎo)致一些問題：1、數(shù)據(jù)吞吐率低，發(fā)送方需要延時一段時間后才能發(fā)送下一幀；2、響應(yīng)不及時，因為有延時，必然導(dǎo)致接收方回復(fù)慢。3、空間利用率不高，如果一個短幀到來，會導(dǎo)致整幀緩存空間（這個空間大小一般是最大幀長）無法使用。

今天魚鷹自己對自己進行一次升級，改用“空閑中斷 + 循環(huán)DMA + 無鎖隊列”的方式進行最為高效的接收方式（無鎖隊列以后有時間再寫，這次的重點不在這）。這種接收方式魚鷹在接觸了循環(huán)隊列后就開始思考了，那個時候工作沒多久，然后一位前輩使用的就是空閑中斷 + DMA 的方式接收，也算是驚到魚鷹了。后來魚鷹在想，循環(huán)隊列的優(yōu)勢顯而易見，而DMA在設(shè)置為循環(huán)模式時，天然就是一個循環(huán)隊列，我是否能將循環(huán)隊列和DMA相結(jié)合，實現(xiàn)一個循環(huán)緩存空間呢？具體當(dāng)時是如何思考的魚鷹已不記得了，只知道當(dāng)時利用KEIL的模擬功能貌似是實現(xiàn)了想要的效果，但是在實際測試過程中應(yīng)該是出現(xiàn)了問題，所以導(dǎo)致這個想法擱置了。這個實現(xiàn)代碼魚鷹會一并上傳到公眾號，讓各位道友參考一二，自認(rèn)為自己符合條件的自行獲取就是了。直到最近看到頭條一位讀者的評論，魚鷹的心思才又活泛起來了，通過評論交流，終于理解了其中是如何實現(xiàn)的，也想到了如何將其和無鎖隊列相結(jié)合，也就有了這一次筆記的分享。

實習(xí)時初次接觸空閑中斷時，用的接收方式是 空閑中斷 + 串口接收中斷，這個算是 V1.0版。后來正式工作后接觸到的是 “空閑中斷 + DMA”這個是V2.0，后來魚鷹在此基礎(chǔ)上進行改進，加入了隊列，加入了定時器，算V2.5好了。這次效率更高，而且空間利用率也高，中斷處理簡單到到極致，定為V3.0?？赡芎芏嗳嗽谥暗墓P記中根本無法真正理解魚鷹的本意，因為這份筆記太長，如果沒有一定的經(jīng)驗根本無法體會，盡管有一份參考代碼放在后臺供各位道友進行參考，但是因為那份代碼只解決了一個定時器控制問題，注釋也不詳盡，還是魚鷹的初次思考，所以相信很多人看到這份代碼都是云里霧里的，還是無法實現(xiàn)其中的細(xì)節(jié)。那么今天魚鷹就來簡單描述其中的關(guān)鍵細(xì)節(jié)實現(xiàn)：

串口接收實現(xiàn)V1.01、初始化時開啟串口的接收中斷和空閑中斷2、串口中斷處理時，每接收一個字節(jié)存入緩存空間（注意控制越界問題）3、一旦空閑中斷來了，停止接收，設(shè)置標(biāo)志位，通知上層已完成一幀數(shù)據(jù)的接收，上層負(fù)責(zé)數(shù)據(jù)的處理工作。當(dāng)然為了防止誤觸發(fā)，也可以使用定時器進行進一步控制，也可以在此基礎(chǔ)上加入緩存隊列。

串口接收實現(xiàn)V2.01、初始化時開啟串口的空閑中斷，并且初始化為正常DMA。2、觸發(fā)空閑中斷時，通知上層接收完成并且將其拷貝到一個緩存中供上層使用，然后重新啟動DMA進行下一次的接收，因為幀與幀之間有空閑時間，只要保證這段時間大于中斷處理時間，那么接收一般不會出現(xiàn)問題。這里有一個關(guān)鍵點就是，如何獲取這次接收的數(shù)據(jù)長度：

Rev_Size = DMA_Set_Size - CNDTR

Rev_Size 是實際接收的長度，DMA_Set_Size是初始化DMA時設(shè)置的緩存大小，這個大小一般大于等于一幀數(shù)據(jù)的最大長度，并且最好是它的2倍以上，這樣極端情況下不容易被下一幀數(shù)據(jù)所覆蓋（怕中斷處理不及時導(dǎo)致覆蓋了之前已接收的數(shù)據(jù)）。而 CNDTR就是 DMA 寄存器中記錄目前剩余需要接收的大小，當(dāng)它為 0 時表示接收完成，DMA自動關(guān)閉。好好理解一下，實現(xiàn)起來不難。 串口接收實現(xiàn)V3.0

1、初始化時開啟串口的空閑中斷，并且初始化為循環(huán)DMA。2、觸發(fā)空閑中斷時，更新索引，這個索引表示當(dāng)前寫入索引值，用于上層判斷緩存空間已寫入的數(shù)據(jù)（魚鷹前面寫了關(guān)于循環(huán)FIFO的筆記，可自行查看，如果不懂這個，下面的你理解不了，數(shù)據(jù)結(jié)構(gòu)系列文章之隊列 FIFO）。3、如果加入無鎖FIFO，更新in索引值。數(shù)據(jù)處理時只要從DMA緩存空間中獲取即可。

現(xiàn)在我們來分析一下更細(xì)節(jié)的東西1、緩存大??？2、如何獲取數(shù)據(jù)？3、好處？4、隱患，缺點？緩存大小可以根據(jù)需要設(shè)置，這個需要看你數(shù)據(jù)處理的延遲時間。比如說發(fā)送者10 ms發(fā)送一幀數(shù)據(jù)，你的數(shù)據(jù)處理正常時候10 ms處理一次，但有時候CPU 負(fù)擔(dān)重，你的數(shù)據(jù)處理優(yōu)先級較低，那么可能20 ms才會處理，那么緩存空間必然需要大于兩幀數(shù)據(jù)才行，這個空間需要測試后才能確定，而且需要留有一定的富余才行。那么如何獲取數(shù)據(jù)？通過學(xué)習(xí)循環(huán)FIFO的知識我們知道，循環(huán)FIFO由兩個變量in和out進行數(shù)據(jù)管理，如果我們的in可以根據(jù)DMA剩余量進行更新，那么就可以根據(jù)in和out之間的關(guān)系知道目前緩存空間里面到底有多少未處理的數(shù)據(jù)了。那么如何更新呢？魚鷹就不藏私了，直接在此說明，不過加入無鎖FIFO的就自己從參考代碼中獲取了，這個其實都差不多。

In = DMA_Set_Size - CNDTR（CNDTR永遠不會是0）

是不是很驚訝，是不是不可思議，你和終極接收方式只差一層窗戶紙？當(dāng)年魚鷹為了更新這個值，用了老長一段代碼實現(xiàn)：

而現(xiàn)在再看這個代碼，已經(jīng)忘記當(dāng)初是咋想的了，但是這個式子確實可以更新in的值，即上面的offset，只是當(dāng)初想的有點復(fù)雜了。簡單來說，就是先通過CNTR和之前的 offset 獲取目前的接收的長度（這個應(yīng)該是受V2.0版本影響），然后根據(jù)長度更新目前的offset。但是通過讀者的評論，發(fā)現(xiàn)根本不需要這樣麻煩。只要有了in的值，然后又有out，那么獲取隊列中的數(shù)據(jù)也就不難了。

其實如果說采用循環(huán)DMA只是減少了中斷的代碼，讓中斷處理時間更短，那么魚鷹還是會選擇以前的V2.0的接收方式，畢竟這種方式實現(xiàn)了幀隔離，但是讀者的一個評論提醒了我，那就是這種方式不需要重新啟動DMA。這意味著什么？意味著高效，意味著DMA持續(xù)工作，意味著不存在因為DMA的短暫關(guān)閉而導(dǎo)致數(shù)據(jù)丟失。這就是魚鷹接下來要說的優(yōu)點：1、中斷代碼及其簡單，像上面那種只是更新in的話只需要三條代碼即可完成。2、不需要重啟DMA3、因為不需要重啟DMA，也就減少了這段時間串口數(shù)據(jù)的丟失4、數(shù)據(jù)吞吐量可以達到最大化，每幀數(shù)據(jù)只需間隔一個空閑時間即可繼續(xù)發(fā)送。最大程度的利用了串口的接收能力，而且不用擔(dān)心數(shù)據(jù)丟失，這對于快速數(shù)據(jù)的接收是非常有好處的。5、就算你不想數(shù)據(jù)幀之間出現(xiàn)空閑間隔時間，你也可以通過一個定時器定時更新in的值。6、即使在串口中斷更新in的值時DMA又在接收數(shù)據(jù)，也不會出現(xiàn)問題，這個原理和無鎖FIFO一樣。7、不需要定時控制，防止空閑中斷的誤觸發(fā)。8、即使因為中斷體系短暫關(guān)閉，而導(dǎo)致空閑中斷不能及時處理，也不會影響DMA在后臺自動接收數(shù)據(jù)。 優(yōu)點很多，缺點也有，下面就來嘮叨嘮叨缺點：1、因為所有數(shù)據(jù)都在一個緩存中，無法實現(xiàn)幀與幀之間的硬性隔離，所以必須通過數(shù)據(jù)本身確定一幀數(shù)據(jù)，對于數(shù)據(jù)的處理難道較高，這一點目前魚鷹采用狀態(tài)機處理，但是總感覺效率較低，后期看看能不能升個級啥的。2、因為無法實現(xiàn)幀隔離，所以一旦因為硬件干擾啥的導(dǎo)致多或少接收一個字節(jié)數(shù)據(jù)，又或者數(shù)據(jù)接收錯誤，那么再從緩存中得到一幀完整數(shù)據(jù)就比較耗時了，所以狀態(tài)機一定要有自恢復(fù)機制，能夠繼續(xù)處理后續(xù)的數(shù)據(jù)幀。3、一旦數(shù)據(jù)處理比較慢，而剩余緩存空間不夠大，那么未處理的數(shù)據(jù)將自動被DMA接收的新數(shù)據(jù)所覆蓋，所以緩存大小一定要有富余。4、一次發(fā)送的數(shù)據(jù)大于或等于緩存空間，那么in的值就有問題，所以發(fā)送者發(fā)送的一幀數(shù)據(jù)一定不能大于或等于緩存空間，切記這一點。 上面的第3點可以通過處理來提醒用戶緩存不夠（有些無法情況無法發(fā)覺），這個魚鷹在代碼中做了處理，各位可參考。而第四點一般不會出現(xiàn)，這是在設(shè)計DMA緩存時就會考慮的。
責(zé)任編輯:pj