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

　　解析思路是：

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

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

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

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

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

　　6.緊接著(zhù)把數據包讀出，此時(shí)讀的長(cháng)度應該是第4步中的幀長(cháng)度數據少2個(gè)字節;

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

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

　　被解析數據源

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

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

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

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

　　回調函數的實(shí)現源碼截圖：

　　事實(shí)上僅僅調用了dclib_ringbuffer功能里的寫(xiě)一字節接口dclib_rb_writebyte，回調函數傳進(jìn)來(lái)的參數dat就是串口接收到的數據。

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

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

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

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

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

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

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