》串列埠協議開發
以下解析正規化都是採用資料佇列的形似來儲存，並且根據裝置執行速度差異，還需增加資料報佇列來儲存解析完畢的資料報
1.正規化一《固定長度》無校驗
0x6b----------20位元組--------0xb6
上面資料中有乙個幀頭0x6b，幀尾0xb6，中間資料20個。
每次資料要找到幀頭0x6b才開始儲存，讀取完22個位元組後結束儲存，並判斷最後乙個位元組是否為0xb6.
這種正規化如果出現誤碼，整個包就會變成錯誤包，會比較危險。
1.正規化二《固定長度》有校驗
0x6b----------20位元組--------校驗-0xb6
上面資料中有乙個幀頭0x6b，幀尾0xb6，中間資料20個，幀尾前面有乙個校驗碼。
每次資料要找到幀頭0x6b才開始儲存，讀取完23個位元組後結束儲存，並判斷最後乙個位元組是否為0xb6.
並且判斷校驗碼。
這種正規化解決上述出現的誤碼問題。
1.正規化三《不固定長度》無校驗
0x6b----------n位元組---------0xb6
上面資料中有乙個幀頭0x6b，幀尾0xb6，中間資料n個，幀尾前面有乙個校驗碼。
每次資料要找到幀頭0x6b才開始儲存，讀取到0xb6後結束儲存，並判斷最後乙個位元組是否為0xb6.
這種正規化會出現錯誤解包的問題，例如資料中出現了0xb6的資料，這個包就丟了。
依然會有誤碼的問題。
1.正規化四《不固定長度》有校驗
0x6b----------n位元組--------校驗-0xb6
上面資料中有乙個幀頭0x6b，幀尾0xb6，中間資料n個，幀尾前面有乙個校驗碼。
每次資料要找到幀頭0x6b才開始儲存，讀取到0xb6後結束儲存，並判斷最後乙個位元組是否為0xb6.
並且判斷校驗碼。
這種正規化解決上述出現的誤碼問題。
這種正規化會出現錯誤解包的問題，例如資料中出現了0xb6的資料，這個包就丟了。
1.正規化五《不固定長度》有校驗，加入轉義字元
0x6b----------n位元組--------校驗-0xb6
如果資料中有0xb6資料，那麼資料報就被提前結束了，並不是我們想要的資料。
這裡需要加入轉義字元
0xb6 -> 0xbf,0x01
0xbf -> 0xbf,0x02
上面資料中有乙個幀頭0x6b，幀尾0xb6，中間資料n個，幀尾前面有乙個校驗碼。
每次資料要找到幀頭0x6b才開始儲存，讀取到0xb6後結束儲存，並判斷最後乙個位元組是否為0xb6.
並且判斷校驗碼。
需要去解析特定的轉義字元
這種正規化解決上述出現的誤碼問題。
這種正規化不會出現錯誤解包的問題。
1.正規化6《不固定長度》有校驗
0x6b-0xb6-n資料長度---------n位元組--------校驗
上面資料中有乙個幀頭0x6b，0xb6，資料長度，中間資料n個，校驗碼。
每次資料要找到幀頭0x6b才開始儲存，讀取到資料長度後讀取對應長度，再讀取乙個校驗碼。
判斷校驗碼即可。
這種正規化解決上述出現的誤碼問題。
這種正規化不會出現錯誤解包的問題。
2018-2-13：
以上都是單幀頭，為了保證安全最好使用雙幀頭，三幀頭，四幀頭。根據實際情況而定。
我部落格中第六種串列埠協議實現
編寫語言 c 編寫平台 vs 運用平台 stm32和pc 非常實用的乙個解析程式，自己編寫的也簡單。h define buf len 1024 buf長度 define conf buf len 128 儲存代解析資料 define data buf len 100 儲存解析資料 此處為最大傳輸資料...
使用DSL優雅的實現串列埠協議
kotlin fun ledonboardinstruction index byte,ledindex byte,r short,g short,b short rj25instruction 這段 的作用,是完成這樣一條藍芽串列埠協議 協議需要的是動態計算的,長度不定的byte陣列,能寫成這樣,...
Linux 上串列埠PRC 協議的實現
最近一直在研究如何實高效能cortex a 處理器在工業控制，物聯網領域的應用。cortex a 核心的soc 晶元通常執行linux os 直接支援的硬體介面不多，而且不夠靈活。我們傾向採用cortex m 微控制器作為cortex a的擴充套件io來使用。為了提高軟體研發的效率cortex m ...