封裝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報錯標誌位。
即可檢測出丟字節的幀。