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

當前的工作環(huán)境：

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

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

當前的需求：

1、時間節(jié)拍到來時，檢查是否有收到數(shù)據(jù)。沒有則跳出，有則進入下一步

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

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

4、具有合理的接收緩沖區(qū)，大于緩沖區(qū)的數(shù)據(jù)進行放棄。

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

幾套嘗試過的方案：

1、DMA數(shù)組的長度和幀長度相等。

觸發(fā)條件：DMA計數(shù)值減到0（即已經(jīng)收滿一個幀的長度的數(shù)據(jù)）產(chǎn)生DMA中斷，將觸發(fā)標志位寫1。PC機上可以通過開啟一個線程監(jiān)視緩沖區(qū)數(shù)量實現(xiàn)。

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

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

報錯機制：

幀錯位：在包頭檢查中會發(fā)現(xiàn)，舍棄當前幀，設置重發(fā)標志位請求重發(fā)。

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

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

解包過快：不會出現(xiàn)解包速度大于收包速度。因為數(shù)據(jù)滿一個幀長度才會解包。

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

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

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

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

報錯機制：

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

字節(jié)缺失：第2幀到來時，檢查包尾時發(fā)現(xiàn)。同樣存在報錯響應不同步的問題。

字節(jié)超出：報錯同步響應。丟棄緩沖區(qū)中所有幀

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

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

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

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

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

報錯機制：

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

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

字節(jié)超出：同字節(jié)缺失

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

小結：

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

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

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

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

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

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

波特率：115200

發(fā)送幀率：5f/s

發(fā)送幀長：20 Bytes

接收幀檢測周期：1ms

接收幀長度：10 Bytes

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

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

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

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

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

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

但是對于PC機端，如果同樣為1ms間隔檢測觸發(fā)條件，接收幀的時常變?yōu)?.736毫秒，那么一個間隔內是必然收不滿1幀的。

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

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

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

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

判斷幀是丟字節(jié)還是未發(fā)完的區(qū)分方式其實是在時間上。

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

因此，當：接收緩沖區(qū)有數(shù)據(jù)，單數(shù)據(jù)未到達20Bytes時，若這種狀態(tài)維持超過2ms，則說明傳輸已經(jīng)完成，缺字節(jié)。

而程序本身的step timer已經(jīng)有了計時的功能。因此，實現(xiàn)方式如下。

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

聲明一個計數(shù)器1：標志位1的計數(shù)。

當FIFO隊列數(shù)據(jù)從0跳變到1時，set標志位1。

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

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

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

即可檢測出丟字節(jié)的幀。