请教：通讯协议Data中含0xA5、0xAA、0x55（即特殊字符），则...

bailao99 · 发表于 2018-9-20 11:44:56

读别人的通讯协议，看到规定为：
1.1串口通讯数据包的封装格式
通讯数据包的封装格式：FrameHead +Data+CheckSum+FrameTail，控制符为0xA5, FrameHead为连续的两个0xAA, FrameTail为连续的两个0x55，如果Data中含0xA5、0xAA、0x55（即特殊字符），则在发送该字符之前添加一个控制符0xA5。CheckSum为8位校验和，即Data的所有数据之和的低八位。

很不理解：为什么要加控制符？

我自己的做法：
通讯数据包的封装格式：FrameHead +Data+CheckSum+FrameTail
FrameHead，Data，CheckSum，FrameTail 长度和位置固定
在接收状态机里收到数据，先检测FrameHead；如果正确，接收设定长度的数据；然后再检测FrameTail；中间只要FrameHead或FrameTail检测不到，或者没有接收到设定长度的数据，都算错误接收帧，不予处理
接收到完整的帧，再做校验，确定收据是否有效

这样用了多次，没出啥问题，而且处理也很简单

真的不明白别人那么做的目的和好处何在

love_zjb · 发表于 2018-9-20 11:49:19

保持帧头尾唯一性

efen · 发表于 2018-9-20 11:55:25

不定长怎么办

XA144F · 发表于 2018-9-20 11:57:27

这种数据最好以时间间隔来区分。

dreampet · 发表于 2018-9-20 12:00:10

用转义更好一些，头尾可以只用一个字节

bg6agf · 发表于 2018-9-20 12:00:42

还有一种也是类似的

辣条 · 发表于 2018-9-20 12:21:44

在串口通信里,0XAA、55、5A、A5是几个特别的数据，拿示波器看数据波形就知道了。这类自己定义的通信协议大同小异

Doding · 发表于 2018-9-20 12:23:29

数据不定长，控制符用于区分是data还是帧尾。

aammoo · 发表于 2018-9-20 12:24:15

看一下这几个字符的二进制，画波形图出来就明白了

kayatsl · 发表于 2018-9-20 12:26:23

本帖最后由 kayatsl 于 2018-9-20 12:28 编辑

我自己的做法：
通讯数据包的封装格式：FrameHead +Data+CheckSum+FrameTail
FrameHead，Data，CheckSum，FrameTail 长度和位置固定
在接收状态机里收到数据，先检测FrameHead；如果正确，接收设定长度的数据；然后再检测FrameTail；中间只要FrameHead或FrameTail检测不到，或者没有接收到设定长度的数据，都算错误接收帧，不予处理
接收到完整的帧，再做校验，确定收据是否有效

------------------------------

1. 你现在固定长度还好, 一旦变长就挂了.
2. 协议都是为了通用数据而设计的, 预先不知道数据内容和格式, 此情况下, 无法确认数据中是否存在头和尾.
3. 不排除碰那么巧在数据中出现了头和尾, 而刚好chksum也对得上, 你收下来的包就错了.

程序和协议要考虑的是健壮性, 以不变应万变, 数据内容及长度不管怎么变都不出错, 而不是要求长度必须保证固定, 数据内不允许出现你的头尾.

leafstamen · 发表于 2018-9-20 13:16:00

bg6agf 发表于 2018-9-20 12:00
还有一种也是类似的

你说的是pppoe吧

Embedtech · 发表于 2018-9-20 13:33:40

辣条发表于 2018-9-20 12:21
在串口通信里,0XAA、55、5A、A5是几个特别的数据，拿示波器看数据波形就知道了。这类自己定义的通信协议大 ...

0x55貌似是LIN bus 同步场

yjysss · 发表于 2018-9-20 13:41:47

直接用modbus-rtu协议走不好吗

bblythe2017 · 发表于 2018-9-20 13:44:08

别瞎折腾，都标准的协议。

XA144F · 发表于 2018-9-20 13:47:00

head+len+data+checksum+end，加上一个长度信息，这样不定长有相同数字的都不怕。

dukelec · 发表于 2018-9-20 13:47:28

本帖最后由 dukelec 于 2018-9-20 13:49 编辑

這種封包方式只能用轉意，它的缺點：
傳輸的數據量最壞能到原始數據的兩倍長度；
數據來回解析的效率非常低。

優點：
一下子收到很多包，如果第一個包出錯，後面的包依然能正常解析。

然而這個優點對單片機來說意義不大，單片機通常都是一來一回。

建議使用 CDBUS 打包格式。

1ongquan · 发表于 2018-9-20 13:48:15

单片机通信协议的编码利用率太高了，其实很多情况下没必要，asic码就足够使用了，速度降低一半，可以提高波特率补偿

nongxiaoming · 发表于 2018-9-20 13:55:03

1ongquan 发表于 2018-9-20 13:48
单片机通信协议的编码利用率太高了，其实很多情况下没必要，asic码就足够使用了，速度降低一半，可以提高波 ...

asic码多机通讯的时候不好解析内容，转换很耗资源。只是眼睛看直观。

dukelec · 发表于 2018-9-20 13:58:20

yjysss 发表于 2018-9-20 13:41
直接用modbus-rtu协议走不好吗

modbus 不能主動上報數據，只適合輪詢。
而串口通訊譬如 RS232 接口，很多時候是需要對等傳輸。

純字符串譬如 G-code 解析效率就更低了，且不方便支持總線。

dukelec · 发表于 2018-9-20 14:04:48

XA144F 发表于 2018-9-20 13:47
head+len+data+checksum+end，加上一个长度信息，这样不定长有相同数字的都不怕。 ...

是的，加長度很方便，也是我用的方式，但有長度之後結尾標記就沒必要了。

然而加了長度就有最大數據限制，數據大的話就要拆包，而電腦的網路數據包比較大，又懒的拆包解包，所以才用 ppp 這種打包方式。

有人看電腦用此方式，也不管單片機是否合適就强搬來用，非常不妥。

tangnyzl · 发表于 2018-9-20 16:01:37

定长，这种方式，效率很高

bg6agf · 发表于 2018-9-20 16:11:21

leafstamen 发表于 2018-9-20 13:16
你说的是pppoe吧

PPP协议

在异步链路中，特殊字符0x7d用作转义字符。当它出现在PPP数据帧中时，那么紧接
着的字符的第6个比特要取其补码，具体实现过程如下：

1) 当遇到字符0x7e时，需连续传送两个字符： 0x7d和0x5e，以实现标志字符的转义。
2) 当遇到转义字符0x7d时，需连续传送两个字符： 0x7d和0x5d，以实现转义字符的转义。
3 ) 默认情况下，如果字符的值小于0x20（比如，一个ASCII控制字符），一般都要进行转
义。例如，遇到字符0x01时需连续传送0x7d和0x21两个字符（这时，第6个比特取补码后变为
1，而前面两种情况均把它变为0）。

这样做的原因是防止它们出现在双方主机的串行接口驱动程序或调制解调器中，因为有
时它们会把这些控制字符解释成特殊的含义。另一种可能是用链路控制协议来指定是否需要
对这32个字符中的某一些值进行转义。默认情况下是对所有的32个字符都进行转义。

dgtg · 发表于 2018-9-20 16:15:39

我一直这样用:
head+len+data+checksum
head为特殊字符，如0xFA,0xAA...
几年了，暂时也没出问题...

rube · 发表于 2018-9-20 16:32:18

dgtg 发表于 2018-9-20 16:15
我一直这样用:
head+len+data+checksum
head为特殊字符，如0xFA,0xAA...

我也这么用

spacekey · 发表于 2018-9-20 16:43:11

如果一时出错，数据中又包含帧头怎么办？需要几帧来同步，没有第一种方法可靠和高效

waterghost · 发表于 2018-9-20 16:48:03

为了筛选出正确数据。还又一种方式：
FrameHead +len+Data+CheckSum.加入一个数据长度。

dukelec · 发表于 2018-9-20 16:59:11

spacekey 发表于 2018-9-20 16:43
如果一时出错，数据中又包含帧头怎么办？需要几帧来同步，没有第一种方法可靠和高效 ...

譬如用 DMA 接收串口數據，當檢測到錯誤之後，直接把緩衝中的數據全部丟掉就好了。根本就不用逐個字節向後掃描。

cqfeiyu · 发表于 2018-9-20 17:03:22

好像AVR的下载协议与楼主的协议类似

luhuaneda · 发表于 2018-9-20 17:06:12

一直也是用head+len+data+checksum+end 这种方式。有一次写上位机软件，len无端消失，data前移了一个byte，结果一直在接收循环。建议加上接收超时就完美了。

leafstamen · 发表于 2018-9-20 17:21:44

楼上怎么这么多head+len+data+check+end的方式，这种方式也有一个很明显的bug啊。

加入head没收到，后面的data里包含head，这个位置之后的数据会被解析成len，这个len可能是一个异常大的数值，这样会连续吞掉后面的很多包数据的。

lbhj310 · 发表于 2018-9-20 17:27:25

这种转义字符方式还是比较严谨的

shell.albert · 发表于 2018-9-20 17:31:48

leafstamen 发表于 2018-9-20 17:21
楼上怎么这么多head+len+data+check+end的方式，这种方式也有一个很明显的bug啊。

加入head没收到，后面的 ...

你这是极端出错情况下才可能发生的。
如果物理通路真的出错了，导致len变大，后面的确会吃掉不少数据包。
但一般会规定这个len的最大值，比如一个字节，那也顶多吃掉256个字节的数据。

momo_li · 发表于 2018-9-20 17:33:31

不改硬件的话ppp协议最安全，实际上楼主的这种也一直在用，没出过什么问题，但总是觉得会有出问题的时候，所以最好是ppp协议吧，然后改进一下帧尾加一个转义字符，就更好了

dukelec · 发表于 2018-9-20 17:53:00

leafstamen 发表于 2018-9-20 17:21
楼上怎么这么多head+len+data+check+end的方式，这种方式也有一个很明显的bug啊。

加入head没收到，后面的 ...

譬如 len 被誤判爲 200，但實際只收到 20 字節，那麼接下來超時會丟掉當前的數據，並復位接收狀態。

如果設備真的可以支持一下子接收多個數據包（正常是一收一回），那麼是要配合軟件（或硬件）流控的（譬如 CDNET 協議的流控），譬如最多 pending 3 個數據包，那麼也就同時丟掉 3 個包而已（且這 3 個包會重傳）。
出錯畢竟極少發生，如果經常發生，那麼應該整改硬件。

如果是總線，雖然設備自己是一收一回的命令方式，但會持續 pending 其它節點的無關數據，這些數據丟掉亦無妨，且同樣可以通過超時來復位接收狀態。

重複一下，檢測到錯誤，丟掉全部接收緩衝數據，無需逐個字節向後掃描。

FireBrain · 发表于 2018-9-20 18:02:54

保证数据完整性和正确性

bailao99 · 发表于 2018-9-20 18:22:20

kayatsl 发表于 2018-9-20 12:26
我自己的做法：
通讯数据包的封装格式：FrameHead +Data+CheckSum+FrameTail
FrameHead，Data，CheckSum，F ...

谢谢您的提示！受教了！
程序和协议要考虑的是健壮性, 以不变应万变, 数据内容及长度不管怎么变都不出错, 而不是要求长度必须保证固定, 数据内不允许出现你的头尾.
看来以后要注意这些了，免得出了Bug都不知道啥原因
谢谢后面各位提供的PPP协议提示

bg6agf · 发表于 2018-9-20 19:07:40

ppp广泛使用N年N个领域了…自然有他的道理

y595906642 · 发表于 2018-9-20 19:14:13

你说的是usb can模块这个协议的确做的不好。

kinsno · 发表于 2018-9-20 19:20:13

spacekey 发表于 2018-9-20 16:43
如果一时出错，数据中又包含帧头怎么办？需要几帧来同步，没有第一种方法可靠和高效 ...

你是针对 head + len + data + crc + tail 吗？
这里面有几个制约条件，不可能同时满足的啊。。
head tali 都是在固定的位置，这个位置是与len有关的，这2个值通过相关计算读出来，不可能同时满足吧，即便满足了，也还有crc来制约啊。相当于3重制约。。。

kinsno · 发表于 2018-9-20 19:34:46

momo_li 发表于 2018-9-20 17:33
不改硬件的话ppp协议最安全，实际上楼主的这种也一直在用，没出过什么问题，但总是觉得会有出问题的时候， ...

为啥要改进帧尾啊？愿闻其详。
0x7E作为头尾，挺好的啊。也只有0x7D 0x7E需要转义啊。简单粗暴。唯一蛋疼的是，最后的2字节CRC有可能正好是0x7D或0x7e的组合，那样就演变成了4个字节。。

XA144F · 发表于 2018-9-20 19:39:35

所以，综上所述，为了增加可靠性的措施就是这些:
1.时间间隔，超时机制，比如10ms作为两帧数据的区分标志，超过这个时间就认为是第二帧数据，可以处理了。
2.header要用好，1个字节重复的概率是1/256，两个字节（比如 aa cc）的概率是1/65536，4字节时要等到猴年马月，用你的身份证号当header的话就要等到天荒地老了。
3.指定长度，这是紧箍咒，而且还可以让dma来处理，多方便。
4.结尾加校验，抗干扰很有用。
5.如果可以就加个end，同第二条。

momo_li · 发表于 2018-9-20 19:45:14

kinsno 发表于 2018-9-20 19:34
为啥要改进帧尾啊？愿闻其详。
0x7E作为头尾，挺好的啊。也只有0x7D 0x7E需要转义啊。简单粗暴。唯一蛋 ...

使用不一样的帧尾只会增加转义的概率，不会增加最大字节数，
有了不一样的帧尾就更加容易判断完整一帧数据了，就这么简单，
其实这种结构连数据长度都不需要，得到帧头帧尾之后将数据解码，然后就得到数据长度了，然后用校验判断数据正确性，完全没有增加两个字节来标识长度的必要啊，
另外ppp协议就是当今以太网的基础，网络上跑的数据底层都是ppp协议，
所以如果数据会通过以太网传输的话，不建议使用ppp一样的转义字符，这样会增加以太网传输时编码的负担

kinsno · 发表于 2018-9-20 19:48:07

momo_li 发表于 2018-9-20 19:45
使用不一样的帧尾只会增加转义的概率，不会增加最大字节数，
有了不一样的帧尾就更加容易判断完整一帧数 ...

是啊，从你的第1行话表明，你认可原PPP协议的嘛，可是从你的第2行话又表明你不认可原PPP协议的7E帧尾。。何解？

momo_li · 发表于 2018-9-20 19:51:39

XA144F 发表于 2018-9-20 19:39
所以，综上所述，为了增加可靠性的措施就是这些:
1.时间间隔，超时机制，比如10ms作为两帧数据的区分标志， ...

超时是通信结构必须的，发出一条命令必必然要有等待回复的时间。
但是超时作为分割两个数据帧的依据我觉得并不是很好，这个超时就需要协议栈具有严格定时功能，增加了复杂性。
当然超时可以作为不回复的依据，比如收到请求后，如果超过一定时间就不要回复了，主机早就等的不耐烦去查询下一个从机了，这个时候再往总线上发送数据就是添乱了。这个时间久没那么严格了，只要有个时间戳大概判断一下就可以了

momo_li · 发表于 2018-9-20 19:56:37

kinsno 发表于 2018-9-20 19:48
是啊，从你的第1行话表明，你认可原PPP协议的嘛，可是从你的第2行话又表明你不认可原PPP协议的7E帧尾。。 ...

实际上没啥区别，纯粹是自己觉得别扭，实际上用啥都可以，ppp的这种结构我是很喜欢的，以后我设计的协议都会用他，除非是有限制不让我用的

bailao99 · 发表于 2018-9-20 19:58:20

y595906642 发表于 2018-9-20 19:14
你说的是usb can模块这个协议的确做的不好。

改进的建议由哪些？

kinsno · 发表于 2018-9-20 19:58:56

本帖最后由 kinsno 于 2018-9-20 20:03 编辑

momo_li 发表于 2018-9-20 19:56
实际上没啥区别，纯粹是自己觉得别扭，实际上用啥都可以，ppp的这种结构我是很喜欢的，以后我设计的协议 ...

是啊，这种协议确实不错。。我自己也是随意定的时候，就用它，确实很方便。。但有的时候，项目或团队定好了规则，要么就是MODBUS，要么就是CANOPE，要么就是上面所说的方式。。
并且我把它改了，我只用2个头部分 7E 和 FF，03那个位置我给演变成了功能码，哈哈。。
PS: 并且我自己用，ASCII码是不作转义的，太繁琐了。

momo_li · 发表于 2018-9-20 20:06:58

kinsno 发表于 2018-9-20 19:58
是啊，这种协议确实不错。。我自己也是随意定的时候，就用它，确实很方便。。但有的时候，项目或团队定好 ...

ppp只是个编码协议而已，我觉得应该归到比协议层更低的传输层，做个转接器很容易和其他协议互转，

dukelec · 发表于 2018-9-20 20:17:20

本帖最后由 dukelec 于 2018-9-20 20:31 编辑

momo_li 发表于 2018-9-20 19:45
使用不一样的帧尾只会增加转义的概率，不会增加最大字节数，
有了不一样的帧尾就更加容易判断完整一帧数 ...

PPP 適合電腦和電腦之間通訊用，不適合單片機用。

電腦之所以用它是因爲協議分層分的很細。上層有 TCP/IP 支持亂順、流控、重傳、拆包等，所以底層用 PPP 比較簡單方便。

對於單片機，數據幀就是數據包，也是應用層的命令，且資源性能有限，用 PPP 只會放大其缺點，而享受不到其優點。
譬如，同時接收了 5 個數據包，第 2 個數據包錯了，其後的 3 個包你收不收呢？第 2 個包要不要重新傳呢？
如果先收了 3 4 5, 再收重傳的 2, 那麼是否還要重新整理順序呢？
如果不想太複雜，3 4 5 也丟掉，那用 PPP 的目的又是啥呢？上面討論半天 PPP 的好處不就是 3 4 5 也能正確接收嗎。

單片機使用 PPP, 既浪費 CPU 資源又浪費帶寬，且實時性也變差很多，單片機的應用很多時候是對實時性有要求的。
譬如發送方 20 ms 週期性發送命令，那麼接收方響應是會不斷抖動的，因爲數據幀一下子長一下子短。

PS.:
PPP 只是用在老式的串口 Modem, 以太網用的是以太網幀，跟 PPP 沒有關係。
PPPoE 只不過是一個上層程序層面的東東，且因爲性能等問題已經逐步淘汰。

dreampet · 发表于 2018-9-20 20:34:29

dukelec 发表于 2018-9-20 20:17
PPP 適合電腦和電腦之間通訊用，不適合單片機用。

電腦之所以用它是因爲協議分層分的很細。上層有 TCP/I ...

你的CDBUS想法不错，但是为了推广自己的协议，一味贬低其他协议，这样好吗？既然能设计出CDBUS这样的协议，难道还不明白，在产品中，没有最好的协议，只有最合适的协议。

dukelec · 发表于 2018-9-20 21:07:37

本帖最后由 dukelec 于 2018-9-20 21:29 编辑

dreampet 发表于 2018-9-20 20:34
你的CDBUS想法不错，但是为了推广自己的协议，一味贬低其他协议，这样好吗？既然能设计出CDBUS这样的协议 ...

不是贬低其他协议，想討論 PPP 是否真的適合單片機使用，譬如
它支持任意長度傳輸，再大的數據都不用分包，只不過單片機用不到這個好處。
它能完全拋開時間信息，也可以拆分所有接收到的數據包，但真正完全一點時間信息都沒有的場合是否又存在呢？特別是對於單片機的使用場合？

我之前寫解析程序也是習慣性的一個字節一個字節的掃描幀頭，不久之前的一天，我突然意識到只比對開頭、出錯清掉所有緩衝，這樣會更簡單、高效、穩健。
這個細節真的很容易有誤區，所以想拿出來跟大家探討，如果沒有問題的話，可以解決掉這種通訊方式的弊端（主要是數據段也含有跟幀頭相同的數據和對時間有嚴格要求）。

CDBUS 協議的前兩個字節是地址，用於總線時並沒有固定的幀頭，所以我討論的點跟 CDBUS 的關係不大。

編輯，添加：
（當然，我也想過，同樣的方式，在沒有固定幀頭的情況下也是可以用的。譬如 modbus 也可以用，不用嚴格通過時間區分數據幀，粘包也照常解析即可。）

dgdzas · 发表于 2018-9-20 21:14:52

没有最好，只有最适合，楼上正解。

momo_li · 发表于 2018-9-20 21:35:13

dukelec 发表于 2018-9-20 20:17
PPP 適合電腦和電腦之間通訊用，不適合單片機用。

電腦之所以用它是因爲協議分層分的很細。上層有 TCP/I ...

只是引用了ppp的编码机制，其他的特性太多了，全部移植过来太占内存不合适。
至于应答和重传机制自然是需要考虑的，但是就不在这一层的范围了。
这个协议非常简单切容易理解。还是有参考价值的。
我一直以为目前的以太网传输层还在用这个协议，真不知道已经不用了。

kayatsl · 发表于 2018-9-20 21:55:18

bailao99 发表于 2018-9-20 18:22
谢谢您的提示！受教了！
程序和协议要考虑的是健壮性, 以不变应万变, 数据内容及长度不管怎么变都不出错, ...

其实这种协议定制方式不只是在某几种通信协议上能看到.

事实上应用非常广泛, 有兴趣可以翻一下通信原理或者交换技术的书看.

举最常见一个例子, 在 C 语言里面定义一个字符串, 使用 "" 作为头尾标识符.

但是如果需要中间字符内容出现 " , 必须先通过 \ 来转义, " \" "

所以如果需要输入 '\' 本身, 也需要先用自身作为转移符也就是 \\

这情况同样适用于 printf 中需要打 % 的时候, 必须先用自己转义, 也就是 "%%" , 且 '\' 转义也同时支持.

事实上没有任何规定转义附只能出现一个, 或者头尾必须不同, 只要你能准确提取数据即可.

当然, 为了提高通讯效率, 应对通信的内容数据分布概率有个统计, 适当选择出现概率最低的来当头尾和转义.

dukelec · 发表于 2018-9-20 22:02:42

本帖最后由 dukelec 于 2018-9-20 22:05 编辑

momo_li 发表于 2018-9-20 21:35
只是引用了ppp的编码机制，其他的特性太多了，全部移植过来太占内存不合适。
至于应答和重传机制自然是需 ...

是的，除了轉義有點噁心，其它非常完美。。。

轉義的時候，需要多準備一個 buffer, 一個字節一個字節的對比搬運，即使是不比對，直接按字節拷貝也比調用 memcpy 函數低效很多，後者是以 CPU 字長爲單位來拷貝的（除了多出來的幾個字節）。

momo_li · 发表于 2018-9-20 22:08:19

不需要额外的buf的，只需要使用的buf大一个字节的就可以，转义的时候把收到的最后一个字节放到buf的最后一个位置，然后转义倒数第二个字节，也就是说，倒序解码，这样只需要额外的一个字节就能搞定

No.5 · 发表于 2018-9-21 04:53:45

时间同步的最好了

y595906642 · 发表于 2018-9-22 17:39:38

bailao99 发表于 2018-9-20 19:58
改进的建议由哪些？

改成定长帧加校验就好很多我有做好

witbrave2014 · 发表于 2018-9-22 17:51:03

目前只用最简单的定长通讯，学习了！

mtswz.213 · 发表于 2018-9-22 17:52:28

这很正常啊，我之前的公司自己做的测试架就是用0xaa,0x55开头跟结尾的，不过我更习惯用modbus

liyang121316 · 发表于 2018-9-23 09:31:11

这些特殊字符可能对检测flash是否损坏有一定意义。都是些01之类的

huangqi412 · 发表于 2018-9-23 13:40:37

有长度方便

knight_avr · 发表于 2018-9-23 19:40:56

用转义字符是最高效率的，而且协议解释没有歧义，如果接收错误，在接到下一帧数据的头时可以马上重启帧接收状态，死循环很少出现

heimareed · 发表于 2018-9-27 09:23:08

看完了全部评论，发现前面的对话内容跟楼主头像很匹配。

或许这就是技术发展之路吧，感谢前面各位大神的分享。自己受益匪浅。

楼主说的控制符其实也就是转义的一种说法而已。总的就是为了区分帧头帧尾。
之前做过一个转发控制系统，8路485 + 2路CAN上行，解析并重新组包后转发给上一层ARM处理，ARM下行分发数据拆包解析后给前面10路+两路自身控制系统。
用的差不多也是这种方案，加上超时管理，很适合状态机使用。

PPP协议，以前在网路上用过，诚如@dukelec所言，不太适合MCU这种小资源设备，CDBUS之前没用过，刚简单了解了下，好像很强大的样子。回头学习下。

zhugean · 发表于 2018-9-27 10:08:28

人家是为了上位机编程方便

nonez · 发表于 2018-9-27 13:20:51

帧头命令字长度数据域校验帧尾
一般协议都差不多这样的

pen245760036 · 发表于 2018-9-27 21:28:12

本帖最后由 pen245760036 于 2018-9-27 21:30 编辑

1、首先转义是必要的，防止出现帧尾字符提前解析这包就丢失 A5是区分转义的标志（控制符）方便计算
2、两个帧头帧尾是避免其他坑货写的解析有问题（提高兼容性），遇到过一个帧头包会丢失就是因为接收方写的串口解析有点LOW

请教：通讯协议Data中含0xA5、0xAA、0x55（即特殊字符），则...

阿莫论坛20周年了！感谢大家的支持与爱护！！