封裝STM32串口的底層時，遇到了串口幀同步的問題。雖然以前也遇到類似場合，寫出來的代碼基本能夠解決問題，但是在邏輯上總是不能徹底的解釋一些細節。

當前的工作環境：

由于代碼想用在一個簡單的PID閉環上，做在線的參數整定。假設當前PID解算周期是1ms，即每1ms，做一次串口的收包，解包，Pid解算，數據采集，然后打包，發包。也就是說是固定步長的解包。

串口的方案是開啟收發的DMA以及DMA的中斷。（堅決不考慮直接使用串口中斷。一個字節中斷一次太費資源）。DMA數組作為串口的FIFO隊列（并不是真正意義上的隊列）。

當前的需求：

1、時間節拍到來時，檢查是否有收到數據。沒有則跳出，有則進入下一步

2、檢查數據中的包格式，比如包頭是否正確，幀長度是否對齊，CRC（目前還沒有做進去）等

3、包格式檢查出錯誤，回包時添加標志位，聲明包格式錯誤請求重發。包格式沒有錯誤則進行解包并設置對應的寄存器和賦值。

4、具有合理的接收緩沖區，大于緩沖區的數據進行放棄。

5、能夠及時檢測出丟字節，多字節等幀長度出錯的問題。

幾套嘗試過的方案：

1、DMA數組的長度和幀長度相等。

觸發條件：DMA計數值減到0（即已經收滿一個幀的長度的數據）產生DMA中斷，將觸發標志位寫1。PC機上可以通過開啟一個線程監視緩沖區數量實現。

解包操作：設置共用體，其中結構體為幀協議，同時公用一個u8 數組作為DMA數組。判斷觸發條件，若滿足，讀取共用體中的包頭包尾，若正確，繼續讀取成員，解包賦值。

緩沖機制：無。DMA設置為normal模式，計數減到0后即停止。有新的數據到來也不會被傳入數組。PC機上可以手動關閉串口。

報錯機制：

幀錯位：在包頭檢查中會發現，舍棄當前幀，設置重發標志位請求重發。

字節缺失：字節缺失的幀發送完成后不會滿足觸發條件，等到第2幀的數據的前幾個字節填滿缺失的幀后，觸發解包操作。在檢查包圍的時候，報錯響應。舍棄字節缺失幀，但是難以保證字節缺失幀的后幾幀能順利接收。而且出錯和報錯響應不同步。即報錯響應出現在錯誤的下一幀。

字節超出：字節超出的幀會及時響應，并且由于包尾錯誤，會立即響應報錯并請求重發。

解包過快：不會出現解包速度大于收包速度。因為數據滿一個幀長度才會解包。

2、DMA數組指向元素類型為幀結構體的鏈表

觸發條件：DMA計數值減到0（即已經收滿一個幀的長度的數據）產生DMA中斷，DMA中斷中對List進行Push_back操作，增加一個element，然后將DMA的內存地址指向新的element的首地址。觸發條件是List的size大于1（在沒有收到任何報文之前，得有一個空element用于放置馬上要到來的報文）；

解包操作：檢查List第1個元素的包頭包尾，如果正確，讀取成員解包賦值，然后對List進行pop_front，直到list的size等于1.

緩沖機制：鏈表天然的緩沖機制，唯一擔心的是堆溢出，可以設置一個上限，在中斷里判斷。

報錯機制：

幀錯位：在包頭檢查中會發現，但是需要丟棄緩沖區內錯位幀之后所有的幀。因為后邊的必然都錯位了。

字節缺失：第2幀到來時，檢查包尾時發現。同樣存在報錯響應不同步的問題。

字節超出：報錯同步響應。丟棄緩沖區中所有幀

解包過快：不存在這個問題。理由同 方式1.

3、DMA數組指向多倍于幀長度的數組首地址

觸發條件：緩沖隊列非空。觸發響應后，立即將緩沖隊列memcpy到臨時數組進行解包。同時清空隊列。

解包操作：在臨時數組中搜索包頭的第1個字節，一單滿足，立即檢查：包頭第2字節，包尾是否在緩沖區長度內，包尾是否正確。如果4個條件均滿足，立即開始解包賦值。完成后重復上一步，在數組中搜索第2個包頭。直到最后在緩沖區末端，殘留幀的前一部分，舍棄該無尾幀。

緩沖機制：由緩沖隊列作為緩沖。

報錯機制：

幀錯位：在臨時數組中不存在幀錯位的概念，幀錯位完全可以被正確解包。

字節缺失：在解包步驟中被檢測到包尾有誤，則請求重發。而且能同步響應。

字節超出：同字節缺失

解包過快：由于觸發方式為緩沖隊列非空。如果查詢觸發條件時，恰好接收了部分幀，則仍然能滿足觸發條件。那么此時這個接收了一部分的幀會作為字節缺失的幀被舍棄并進行報錯

小結：

三種方式對比下來，第3種方式有著較優越的性能，而且能夠很好地移植到PC機上實現。但是對于解包過快的問題，仍然需要討論。

字節缺失同步響應和解包過快的矛盾：

問題可以被化簡為：一個10字節的幀，解包時，如果包里只有9個字節，那這一幀到底是沒發完還是字節缺失。

如果使用“已收到大于10個字節的數據”作為解包觸發條件，那么解包時永遠有10個字節，判斷最后一個字節是否是包尾，即可。但是字節缺失永遠只能在下一幀響應。

如果使用“緩沖區數據多于0”作為解包觸發條件，雖然字節缺失能立即被響應，但是也有可能將未發完的幀誤判。

因此需要針對當前的應用進行分析。目前對于單片機的幀率和幀長度為：

波特率：115200

發送幀率：5f/s

發送幀長：20 Bytes

接收幀檢測周期：1ms

接收幀長度：10 Bytes

傳送1Byte數據，由于沒有校驗位，1個停止位，因此需要10bits。

那么傳輸速率為11520B/s（約11KB/S），即傳輸1Byte需要86.8us（約0.1ms）。

發送幀每一幀20Bytes，需要1.736ms（約2ms）

接收幀每一幀10Bytes，需要0.858ms（約1ms）

因此對于當前的情況下單片機的接收條件，1ms解包一次，完全不需要緩沖區，但是卻有很大可能發生在幀截斷。

因此應該采用“已收到等于幀長度個字節的數據”作為觸發條件。放棄字節缺失幀的同步響應。

但是對于PC機端，如果同樣為1ms間隔檢測觸發條件，接收幀的時常變為1.736毫秒，那么一個間隔內是必然收不滿1幀的。

因此同樣可以采用“已收到等于幀長度個字節的數據”作為觸發條件。放棄字節缺失幀的同步響應。

但是對于Qt上的串口類，現在還沒有摸清他的工作原理，尚無法討論何種方法比較合適。

/**********************************11月1日更新分割線****************************************/

一個能夠提高缺字節幀報錯響應速度的方案：

判斷幀是丟字節還是未發完的區分方式其實是在時間上。

比如之前提到的115200波特率，20Bytes的幀，其傳送時間應該小于2ms。

因此，當：接收緩沖區有數據，單數據未到達20Bytes時，若這種狀態維持超過2ms，則說明傳輸已經完成，缺字節。

而程序本身的step timer已經有了計時的功能。因此，實現方式如下。

聲明一個標志位1：FIFO隊列有數據但不滿幀長度。

聲明一個計數器1：標志位1的計數。

當FIFO隊列數據從0跳變到1時，set標志位1。

CheckMailBox時，標志位1已置位，則將計數器1的值加1。

由于20Bytes的幀在2ms內應該發送完。而解算周期為1ms。

故，當計數器1的值大于2時，如果FIFO隊列數據長度仍然沒有達到幀長度，說明該包有數據丟失。set報錯標志位。

即可檢測出丟字節的幀。