嵌入式硬件通信接口協議-UART（四）設計起止式的應用層協議

　　解析思路是：

　　1.確保環形緩沖區有足夠一個幀結構的數據量，否則返數據量不足的錯誤;

　　2.接著讀出一個字節判斷幀頭標志是否為0x55，否則返幀頭錯誤;

　　3.再次讀一個字節作為幀長度數據，且長度至少3個字節(2個CRC校驗值+至少1字節數據包)，否則返幀長度錯誤;

　　4.讀出幀長度數據，如果此時環形緩沖區的可讀數量比長度數值小，出現這情況的原因可能是幀長度字段在發送期間出現異常，或是對端設備串口傳輸慢而未完整傳輸一幀，此時可做適當的延時等待，如果超時退出，且返幀長度錯誤;

　　5.繼續讀出2個字節作為CRC校驗值，且需要注意先收到的是crc16L，先收到小端數值;

　　6.緊接著把數據包讀出，此時讀的長度應該是第4步中的幀長度數據少2個字節;

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

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

　　被解析數據源

　　看到這里也許仍有疑問，用于解析的數據源哪來?數據什么時候被寫進環形緩沖區內?

　　參考上一篇《嵌入式硬件通信接口-使用RingBuffer處理數據(二)詳細設計過程》介紹的關于向環形緩沖區寫入一個字節，但dclib_ringbuffer這個模塊屬于應用庫模塊層，而如果直接把dclib_rb_writebyte這一個接口放在串口接收中斷里執行，這就破壞了系統的架構層次，對工程代碼的維護和移植是個麻煩事，因此采用回調函數的方式。

　　嵌入式開發工程師都知道，一般在使用官方的庫時，經常會遇到需要自己實現一些回調函數，從而利用注冊接口把回調函數傳遞給庫或者驅動層，使庫或者驅動層在執行時調用該回調函數。

　　根據這個思路，同樣的這里也采用回調函數的形式，回調函數內完成了把串口接收到的數據寫入環形緩沖區內。

　　回調函數的實現源碼截圖：

　　事實上僅僅調用了dclib_ringbuffer功能里的寫一字節接口dclib_rb_writebyte，回調函數傳進來的參數dat就是串口接收到的數據。

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

　　又偏題了，關于回調函數在此不做深入論述。

　　簡而言之，環形緩沖區寫入一字節的執行過程，放在回調函數里，當串口接收中斷觸發后，中斷里會根據注冊的回調函數地址，進而執行回調函數，實現對環形緩沖區寫入一個字節數據。如此操作的理由是不改變工程代碼的分層架構，并且便于維護與移植!

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

　　最后也附上調試期間串口打印的解析結果：

　　起止式幀結構的講解稍有匆忙，篇幅也略大，文中基礎技術要點未能細致講解，后續統籌規劃再做單獨介紹!

　　接下來在此幀結構基礎上，講述如何設計在數據包放置應用層的交互指令，敬請期待下回分!