防止傳感器串口數(shù)據(jù)紊亂將數(shù)據(jù)打包,關(guān)于包頭包尾概念?

ID:819146 · 發(fā)表于 2022-1-14 23:14

想把多個傳感器的數(shù)據(jù)通過串口上傳到上位機上，為了防止數(shù)據(jù)紊亂，我在網(wǎng)上找到的解決方案就是將數(shù)據(jù)打包，一包一包的將數(shù)據(jù)上傳到上位機上，沒有找到相關(guān)的教程，就是想問一下包頭包尾具體要怎么創(chuàng)建，使用的時候要注意些什么（問題可能有點蠢，萌新，請見諒）

ID:213173 · 發(fā)表于 2022-1-15 07:19

串口傳輸數(shù)據(jù)的基本單元是一個字節(jié)，所謂打包是按通信協(xié)議把一串字節(jié)集中傳輸。假設(shè)某設(shè)備需要準(zhǔn)確實時傳輸3個字節(jié)有效數(shù)據(jù)。那么制定一個自定義通信協(xié)議，由7個字節(jié)組成：0xaa、0x07、0x01、0x02、0x04、0x0d、0x55。數(shù)據(jù)頭，數(shù)據(jù)長度，3個有效數(shù)據(jù)，數(shù)據(jù)和得到的驗證碼，數(shù)據(jù)尾。當(dāng)串口收到0xaa，表示有傳輸要求，接著收到0x07表示數(shù)據(jù)長度7個字節(jié)。當(dāng)收完7個字節(jié)并且最后是0x55，就可以解析數(shù)據(jù)了。把除第6外其它6個字節(jié)相加，溢出部分拋棄，再與第6字節(jié)比較驗證，相同回復(fù)正確信息并執(zhí)行相應(yīng)任務(wù)，不同回復(fù)要求重發(fā)信息。簡單敘述，實際應(yīng)用中驗證方式多種多樣，不一而足。

ID:57657 · 發(fā)表于 2022-1-15 07:36

串口數(shù)據(jù)包就是所有字節(jié)緊挨著發(fā)送，超過規(guī)定時間沒有接收到字節(jié)就開始解析，所謂的包頭包尾就是固定的值比如A5 5A。

ID:807591 · 發(fā)表于 2022-1-15 12:15

如果不是很復(fù)雜很長的數(shù)據(jù)，無需所謂包頭包尾，最后一個字節(jié)設(shè)為CRC校驗即可，傳輸那么多包頭尾完全是浪費時間

ID:879809 · 發(fā)表于 2022-1-18 19:17

上位機實時性非常差的，利用超時標(biāo)記幀頭是非常不靠譜的�？梢岳肕ODBUS/ASC的做法，幀頭是":"，幀尾是"\r\n"，中間的數(shù)據(jù)不能出現(xiàn)這三個字符即可。

ID:824490 · 發(fā)表于 2022-1-18 21:18

給你一張圖參考一下：

1642511875(1).png

ID:879809 · 發(fā)表于 2022-1-19 01:53

名字不是重點發(fā)表于 2022-1-18 21:18
給你一張圖參考一下：

你這個邏輯上有問題的，要保證中間數(shù)據(jù)不會出現(xiàn)55AA、0D0A這樣的組合，否則會認(rèn)錯幀頭幀尾的。

ID:311903 · 發(fā)表于 2022-1-19 08:23

發(fā)表于 2022-1-19 01:53
你這個邏輯上有問題的，要保證中間數(shù)據(jù)不會出現(xiàn)55AA、0D0A這樣的組合，否則會認(rèn)錯幀頭幀尾的。

這種簡單的協(xié)議如果擔(dān)心數(shù)據(jù)里面有特殊值（包頭/包尾），就把數(shù)據(jù)部分出現(xiàn)包頭/包尾的做個轉(zhuǎn)義也可以

ID:824490 · 發(fā)表于 2022-1-19 09:27

發(fā)表于 2022-1-19 01:53
你這個邏輯上有問題的，要保證中間數(shù)據(jù)不會出現(xiàn)55AA、0D0A這樣的組合，否則會認(rèn)錯幀頭幀尾的。

不管用什么數(shù)值作同步，這個問題都會存在。但用代碼可以輕松解決：
我之前用過的如下：
同步頭：
如果接收計數(shù)==1，且接收（計數(shù)-1）==0x55 && 接收（計數(shù)）== 0xaa ,則接收計數(shù)+1，
否則接收計數(shù)=0；
幀尾：
連續(xù)收到0x0d && 0x0a 時判斷幀長度：
如果接收計數(shù)==幀長度，且接收（計數(shù)-1）==0x0d && 接收（計數(shù)）== 0x0a,則接收OK=1；
否則接收OK=0；繼續(xù)下一個字節(jié)接收。
在main()中只要讀到接收OK=1就開始分配工作了。

歡迎指正~~

ID:236035 · 發(fā)表于 2022-1-19 11:43

可以參考一些成熟協(xié)議，如包頭是4個 0xFF ,再加一個 0x55,包尾只需有校驗字。

ID:899981 · 發(fā)表于 2022-1-19 11:53

自己定義，不過包頭包尾要找的不常用好記的字節(jié)，例如AA.BB.FF,00，最好加簡單校驗，例如取反加一等。

ID:879348 · 發(fā)表于 2022-1-19 14:14

就是用特殊符號做開頭結(jié)尾方便寫程序，這些符號在正式數(shù)據(jù)中不會出現(xiàn)

ID:824490 · 發(fā)表于 2022-1-19 15:07

wufa1986 發(fā)表于 2022-1-19 14:14
就是用特殊符號做開頭結(jié)尾方便寫程序，這些符號在正式數(shù)據(jù)中不會出現(xiàn)

嚴(yán)格意義上來講，沒有什么特殊符號，因為數(shù)據(jù)傳輸?shù)膬?nèi)容不可預(yù)知的，只能通過軟件代碼來過濾。

ID:879809 · 發(fā)表于 2022-1-19 15:31

名字不是重點發(fā)表于 2022-1-19 15:07
嚴(yán)格意義上來講，沒有什么特殊符號，因為數(shù)據(jù)傳輸?shù)膬?nèi)容不可預(yù)知的，只能通過軟件代碼來過濾。

怎么可能不可預(yù)知？？？MODBUS/ASC的精髓就是幀頭":"幀尾“\r\n”，中間數(shù)據(jù)不可能出現(xiàn)這三個字符，只能是“01234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ+-.”。小伙子你還是見識的太少。

ID:824490 · 發(fā)表于 2022-1-19 15:46

你是說，“01234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ+-.”這幾個字符就能代表0-255內(nèi)的任何值了。
嗯呢，受教了！

ID:879809 · 發(fā)表于 2022-1-19 16:02

名字不是重點發(fā)表于 2022-1-19 15:46
你是說，“01234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ+-.”這幾個字符就能代表0-255內(nèi)的任何值了。
嗯呢，受 ...

ASCII碼當(dāng)然可以表示任意值，“-9999.888”也是ASCII，可比你以為的0~255范圍大太多了。

ID:824490 · 發(fā)表于 2022-1-19 16:05

發(fā)表于 2022-1-19 15:31
怎么可能不可預(yù)知？？？MODBUS/ASC的精髓就是幀頭":"幀尾“\r\n”，中間數(shù)據(jù)不可能出現(xiàn)這三個字符，只能 ...

如果傳送一幅240*320的圖片，本來只要傳240*320*2（16位色值）的圖片，是不是要多傳一倍的數(shù)據(jù)量？
MODBUS/ASC貌似對大數(shù)據(jù)傳輸不太友好來的。。

ID:824490 · 發(fā)表于 2022-1-19 16:10

發(fā)表于 2022-1-19 16:02
ASCII碼當(dāng)然可以表示任意值，“-9999.888”也是ASCII，可比你以為的0~255范圍大太多了。

是的，我沒接觸過MODBUS的相關(guān)協(xié)議。。如我上一貼所言，傳輸速度會不會被打折扣了？因為你每一個字節(jié)都被拆成2個字節(jié)來發(fā)送，上位機要拆分、下位機要組合，感覺對實時性要求高的地方不太適用，比如在電機控制方面，速度慢了可能會出事的。望指點~~

ID:879809 · 發(fā)表于 2022-1-19 16:10

名字不是重點發(fā)表于 2022-1-19 16:05
如果傳送一幅240*320的圖片，本來只要傳240*320*2（16位色值）的圖片，是不是要多傳一倍的數(shù)據(jù)量？
MOD ...

傳圖片用串口，你是不是有點兒什么疾患？

ID:879809 · 發(fā)表于 2022-1-19 16:21

名字不是重點發(fā)表于 2022-1-19 16:10
是的，我沒接觸過MODBUS的相關(guān)協(xié)議。。如我上一貼所言，傳輸速度會不會被打折扣了？因為你每一個字節(jié)都被 ...

上位機本來就沒實時性你要求本身就不合理。

單片機和單片機之間我更喜歡用MODBUS/RTU的形式來進行，幀數(shù)據(jù)一個字節(jié)內(nèi)容可以是0~255之間任意值，總線空閑3.5字節(jié)時間，下面到來的第一個字符就是幀頭。

ID:824490 · 發(fā)表于 2022-1-19 16:24

別急躁！
一些設(shè)備只有串口。即使看上去是USB的接口，但還是走串口的通道的。你不能更換新設(shè)備。沒得說。

ID:824490 · 發(fā)表于 2022-1-19 16:30

發(fā)表于 2022-1-19 16:10
傳圖片用串口，你是不是有點兒什么疾患？

手持對講機（用的就是1.77的屏），終端客戶要求能更換開機LOGO，以及一些特定聲音文件，而主控不支持USB，又沒有插卡接口，只能走串口通道。這事多了去了。

ID:824490 · 發(fā)表于 2022-1-19 16:36

發(fā)表于 2022-1-19 16:21
上位機本來就沒實時性你要求本身就不合理。

單片機和單片機之間我更喜歡用MODBUS/RTU的形式來進行，幀 ...

客戶的要求，就是合理的。。
即使以專業(yè)的角度來分析不合理，我們也要將就他們的不合理。。說的很窩囊、很委曲，事實如此，競爭太激烈了。。

ID:236035 · 發(fā)表于 2022-1-20 11:09

包頭不與數(shù)據(jù)重復(fù)可以加長字節(jié)。小概率事件不用考慮，非要考慮，還有糾錯機制。

ID:624769 · 發(fā)表于 2022-1-20 21:40

個人覺得，如果不用 ASCII 傳輸，沒什么必要加包頭包尾的，開啟串口的9位模式，外加每發(fā)送16個字節(jié) + 接收端回應(yīng)一個效驗值，就足夠了。

ID:1017183 · 發(fā)表于 2022-4-10 12:15

發(fā)表于 2022-1-19 15:31
怎么可能不可預(yù)知？？？MODBUS/ASC的精髓就是幀頭":"幀尾“\r\n”，中間數(shù)據(jù)不可能出現(xiàn)這三個字符，只能 ...

請問，為什么以“:”為幀頭，數(shù)據(jù)中可以出現(xiàn)冒號呀

ID:883242 · 發(fā)表于 2022-4-10 18:48

嵌入式大菜雞發(fā)表于 2022-4-10 12:15
請問，為什么以“:”為幀頭，數(shù)據(jù)中可以出現(xiàn)冒號呀

你要傳輸什么數(shù)據(jù)一定要有冒號？寫出來看々。

ID:310441 · 發(fā)表于 2022-4-11 07:40

包頭即可。用一串不會或者極小概率出現(xiàn)的數(shù)據(jù)作為你要傳輸數(shù)據(jù)的頭。僅用來表示數(shù)據(jù)的起點。

ID:958310 · 發(fā)表于 2022-4-11 09:20

數(shù)據(jù)頭-功能碼-數(shù)據(jù)長度-有效數(shù)據(jù)~-CRC校驗

帳號		自動登錄	找回密碼
密碼			立即注冊