事實上串口實現(xiàn)了數(shù)據(jù)通信過程中的傳輸層，而應(yīng)用層就系統(tǒng)功能的業(yè)務(wù)邏輯，應(yīng)用層控制需要收發(fā)的各種數(shù)據(jù)內(nèi)容。

數(shù)據(jù)解析的前提是通信雙方都是用統(tǒng)一的數(shù)據(jù)幀格式，因此在這里將設(shè)計一個簡單的起止式的數(shù)據(jù)幀格式，保證設(shè)備之間進(jìn)行可靠的通信。

現(xiàn)在的很多無線模塊，為了使用簡單和易于集成，模塊對外使用UART接口，并采用AT指令來完成配置和使用，常見的有ESP8266的WiFi模塊、HC-05藍(lán)牙串口模塊。

AT指令的特點是易于人機交互，使用者對其發(fā)AT指令時，都是用ASCII字符發(fā)送，對于模塊的處理，也是以字符來處理。這樣的AT指令，它的起止式特點是以“AT”兩個字符開頭，并以回車換行“\\r\\n”字符結(jié)束。

HC-05藍(lán)牙模塊指令示例

但是項目工程中，數(shù)據(jù)在嵌入式設(shè)備是以HEX數(shù)據(jù)（16進(jìn)制）運算和處理，如果參考AT指令去設(shè)計幀結(jié)構(gòu)，那么在收發(fā)處理時候，必然要將收到的純數(shù)據(jù)（16進(jìn)制）按照字符處理。

比如一個終端設(shè)備，其功能就是環(huán)境檢測，可能包含溫濕度、光照強度、二氧化碳濃度、PM2.5濃度等等，如果要發(fā)出一個溫度采集結(jié)果24℃數(shù)據(jù)，采集設(shè)備將數(shù)據(jù)24分成2個字節(jié)發(fā)送，因為ASCII字符’2’對應(yīng)的16進(jìn)制是0x32、ASCII字符’4’對應(yīng)的16進(jìn)制是0x34，這樣的一個溫度數(shù)據(jù)就需要2個字節(jié)來發(fā)送。接收端接收到的是0x32、0x34后，再以查表方式逆向換算出原溫度數(shù)據(jù)’24’，這個過程就是采用字符處理的麻煩之一。

因此不考慮使用ASCII字符來組幀結(jié)構(gòu)。

精簡起止式結(jié)構(gòu)

最簡單的幀，就是有開頭+結(jié)尾做起止標(biāo)志。

比如 0x55 + 數(shù)據(jù)包 + 0xAA 。

在一長串的數(shù)據(jù)流中，接收端逐字節(jié)接收，并判斷是否存在0x55，如果存在則開始存入數(shù)據(jù)包緩沖器，直到接收了0xAA數(shù)據(jù)，認(rèn)為完成一幀數(shù)據(jù)的接收。

這個方法確實相當(dāng)簡單，不用太多的處理，只需要判斷開頭和結(jié)尾即可。

而這樣存在很大的問題，如果傳輸?shù)膬?nèi)容也有0xAA這樣的數(shù)據(jù)，這個0xAA并非結(jié)尾標(biāo)志，而程序接收過程就提前結(jié)束，這樣就不能保證完整接收一幀數(shù)據(jù)包了。

增加長度限制

在精簡起止式結(jié)構(gòu)基礎(chǔ)上，增加一數(shù)據(jù)來標(biāo)志數(shù)據(jù)包長度。

比如 0x55 + 長度 + 數(shù)據(jù)包 + 0xAA 。

這樣一來，接收端判斷接收到了0x55的開頭標(biāo)志，緊接著再接收一個“長度”的字節(jié)，基于這個長度來繼續(xù)接收后續(xù)剩余的數(shù)據(jù)。

可見如果有了長度的約束，那么最后都不需要0xAA作為結(jié)尾標(biāo)志了。

這樣的接口，即使有開頭、長度、結(jié)尾，還存在風(fēng)險。比如傳輸數(shù)據(jù)時，物理線路受到未知干擾，導(dǎo)致數(shù)據(jù)內(nèi)容出現(xiàn)了異常，那么接收端即使完整接收所有數(shù)量的數(shù)據(jù)下來，也是錯誤的內(nèi)容。

增加校驗檢查

解決在發(fā)送過程中出現(xiàn)的未知錯誤問題，必然需要對數(shù)據(jù)進(jìn)行校驗。再增加一字段來標(biāo)志數(shù)據(jù)內(nèi)容的校驗計算結(jié)果。

比如 0x55 + 長度 + 校驗值 + 數(shù)據(jù)內(nèi)容 + 0xAA 。

校驗值是對數(shù)據(jù)包采用算法計算而得，接收方完整收下所有數(shù)量的數(shù)據(jù)，再對數(shù)據(jù)包采用同樣的算法計算出校驗值，從而對比校驗值來確定數(shù)據(jù)包的準(zhǔn)確性。

對于校驗值的運算，采用CRC-16運算的方式，檢錯能力強，開銷小。

設(shè)計協(xié)議幀結(jié)構(gòu)

綜上所述，基于起止式的幀結(jié)構(gòu)可以設(shè)計成：**0x55 + 長度 + CRC校驗 + ** 數(shù)據(jù)包 。

在這里，幀頭標(biāo)志采用0x55一個字節(jié)。

0x55二進(jìn)制是01010101，這樣在UART物理線路上輸出的信號將會是占空比50%的方波，方波是最容易進(jìn)行測量和診斷的，在實際波形觀測時可以確定穩(wěn)定性、噪聲毛刺等。

要說0xAA(二進(jìn)制10101010)也是可以，但是UART發(fā)送時候是有一個起始位0，并且是以LSB方式先發(fā)送bit0的最低位，0xAA的bit0已經(jīng)是0，而0x55的bit0是1，因此想得到方波當(dāng)然優(yōu)先考慮用0x55。

長度采用一個字節(jié)表示，則后續(xù)的CRC校驗 + 數(shù)據(jù)包的總數(shù)量最多能放255個字節(jié)。

CRC校驗采用CRC-16算法，占2個字節(jié)，此時后續(xù)的數(shù)據(jù)包最多能放253個字節(jié)。

終上所述，得出最終的起止式幀結(jié)構(gòu)：

接下來開始設(shè)計處理程序。

根據(jù)幀結(jié)構(gòu)，可以定義如下的結(jié)構(gòu)體：

typedef struct {

*uint8_t **head;*

*uint8_t** len;*

*uint8_t** crc16L;*

*uint8_t** crc16H;*

*uint8_t** packet[253];*

}sst_frame_t;

其中要特別說明的：

packet 數(shù)據(jù)包最大長度設(shè)為253 ，是因為len是uint8_t類型，len 最大255 ，而CRC校驗值占了2個字節(jié)，因此packet數(shù)據(jù)包最多可253個字節(jié)。

CRC校驗值采用的是CRC-16標(biāo)準(zhǔn)，校驗值是個uint16_t類型的數(shù)據(jù)，傳輸時采用的是LSB模式，因此將CRC校驗值設(shè)為兩個uint8_t類型的數(shù)據(jù)，這樣做便于在源碼移植過程中，不同平臺的大小端差異能夠得到正確處理。

簡述嵌入式設(shè)備內(nèi)存大小端差異在結(jié)構(gòu)體定義以及使用時存在的問題：

假如對幀結(jié)構(gòu)定義了如下的結(jié)構(gòu)體：

typedef struct {

*uint8_t **head;*

*uint8_t** len;*

*uint16_t  **crc16;*

*uint8_t** packet[253];*

}sst_frame_t;

計算后得到某一次的校驗值結(jié)果是 0xDC66 ，這是一個uint16_t**類型的數(shù)據(jù)，如果直接使用這個結(jié)構(gòu)體來處理數(shù)據(jù)發(fā)送，那么:

在LSB的小端模式平臺下，數(shù)據(jù)的發(fā)送順序是 **

head 、len 、0x66 、0xDC 、packet[0] 、packet[1] 、...

反之在MSB大端模式的平臺里，數(shù)據(jù)的發(fā)送順序是 **

head 、len 、0xDC 、0x66 、packet[0] 、packet[1] 、...

因此采用2個字節(jié)uint8_t數(shù)據(jù)類型代替uint16_t來定義結(jié)構(gòu)體中的CRC校驗值，使得在跨平臺收發(fā)數(shù)據(jù)時無需做差異化處理。

構(gòu)建幀結(jié)構(gòu)

使用起止式進(jìn)行數(shù)據(jù)傳輸時，把應(yīng)用層的數(shù)據(jù)包進(jìn)行組幀，這樣可構(gòu)造一個完整的數(shù)據(jù)幀，便于在應(yīng)用層將完整的一幀數(shù)據(jù)傳遞給傳輸層發(fā)出。

這里的構(gòu)造過程，事實上是對幀結(jié)構(gòu)的“填充”過程。

首先是計算數(shù)據(jù)包的CRC校驗值，隨后就是“填充”的過程。

為了防止應(yīng)用層調(diào)用接口時，傳進(jìn)來的數(shù)據(jù)包的地址、組幀結(jié)果的首地址指向同一個內(nèi)存地址，所以在組幀前需要將源數(shù)據(jù)內(nèi)容單獨緩存，再進(jìn)行“填充”的操作。

解析幀結(jié)構(gòu)

解析幀結(jié)構(gòu)其實就是對一長串的數(shù)據(jù)流進(jìn)行解析處理，從而提取出數(shù)據(jù)包。

這里被解析的數(shù)據(jù)來源是一個循環(huán)緩沖區(qū)，對循環(huán)緩沖區(qū)內(nèi)的可讀數(shù)據(jù)進(jìn)行解析。因此需要使用循環(huán)緩沖區(qū)配合。

代碼截圖：

解析思路是：

1.確保環(huán)形緩沖區(qū)有足夠一個幀結(jié)構(gòu)的數(shù)據(jù)量，否則返數(shù)據(jù)量不足的錯誤；

2.接著讀出一個字節(jié)判斷幀頭標(biāo)志是否為0x55，否則返幀頭錯誤；

3.再次讀一個字節(jié)作為幀長度數(shù)據(jù)，且長度至少3個字節(jié)（2個CRC校驗值+至少1字節(jié)數(shù)據(jù)包），否則返幀長度錯誤；

4.讀出幀長度數(shù)據(jù)，如果此時環(huán)形緩沖區(qū)的可讀數(shù)量比長度數(shù)值小，出現(xiàn)這情況的原因可能是幀長度字段在發(fā)送期間出現(xiàn)異常，或是對端設(shè)備串口傳輸慢而未完整傳輸一幀，此時可做適當(dāng)?shù)难訒r等待，如果超時退出，且返幀長度錯誤；

5.繼續(xù)讀出2個字節(jié)作為CRC校驗值，且需要注意先收到的是crc16L，先收到小端數(shù)值；

6.緊接著把數(shù)據(jù)包讀出，此時讀的長度應(yīng)該是第4步中的幀長度數(shù)據(jù)少2個字節(jié)；

7.最后對數(shù)據(jù)包計算一個CRC校驗值，對比接收到的校驗值，校驗值不一致則返錯誤校驗碼。

函數(shù)返回值符合以下枚舉的錯誤碼：

被解析數(shù)據(jù)源

看到這里也許仍有疑問，用于解析的數(shù)據(jù)源哪來？數(shù)據(jù)什么時候被寫進(jìn)環(huán)形緩沖區(qū)內(nèi)？

dclib_ringbuffer這個模塊屬于應(yīng)用庫模塊層，而如果直接把dclib_rb_writebyte這一個接口放在串口接收中斷里執(zhí)行，這就破壞了系統(tǒng)的架構(gòu)層次，對工程代碼的維護和移植是個麻煩事，因此采用回調(diào)函數(shù)的方式。

嵌入式開發(fā)工程師都知道，一般在使用官方的庫時，經(jīng)常會遇到需要自己實現(xiàn)一些回調(diào)函數(shù)，從而利用注冊接口把回調(diào)函數(shù)傳遞給庫或者驅(qū)動層，使庫或者驅(qū)動層在執(zhí)行時調(diào)用該回調(diào)函數(shù)。

根據(jù)這個思路，同樣的這里也采用回調(diào)函數(shù)的形式，回調(diào)函數(shù)內(nèi)完成了把串口接收到的數(shù)據(jù)寫入環(huán)形緩沖區(qū)內(nèi)。

回調(diào)函數(shù)的實現(xiàn)源碼截圖：

事實上僅僅調(diào)用了dclib_ringbuffer功能里的寫一字節(jié)接口dclib_rb_writebyte，回調(diào)函數(shù)傳進(jìn)來的參數(shù)dat就是串口接收到的數(shù)據(jù)。

有了回調(diào)函數(shù)，還要把這個回調(diào)函數(shù)的地址傳給底層驅(qū)動，這也就是常說的“注冊”的過程，注冊接口在固件板級接口層里串口模塊dcbsp_uart實現(xiàn)，注冊接口時dclib_uart_callback_reg函數(shù)：

又偏題了，關(guān)于回調(diào)函數(shù)在此不做深入論述。

簡而言之，環(huán)形緩沖區(qū)寫入一字節(jié)的執(zhí)行過程，放在回調(diào)函數(shù)里，當(dāng)串口接收中斷觸發(fā)后，中斷里會根據(jù)注冊的回調(diào)函數(shù)地址，進(jìn)而執(zhí)行回調(diào)函數(shù)，實現(xiàn)對環(huán)形緩沖區(qū)寫入一個字節(jié)數(shù)據(jù)。如此操作的理由是不改變工程代碼的分層架構(gòu)，并且便于維護與移植！

為了縮減篇幅，最后貼上測試代碼的部分：

最后也附上調(diào)試期間串口打印的解析結(jié)果：