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

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

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

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

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

Rev_Size = DMA_Set_Size - CNDTR

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

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

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

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

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

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

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