C# 串口操作系列(3) -- 协议篇,二进制协议数据解析

    我们的串口程序,除了通用的,进行串口监听收发的简单工具,大多都和下位机有关,这就需要关心我们的通讯协议如何缓存,分析,以及通知界面。

    我们先说一下通讯协议。通讯协议就是通讯双方共同遵循的一套规则,定义协议的原则是尽可能的简单以提高传输率,尽可能的具有安全性保证数据传输完整正确。基于这2点规则,我们一个通讯协议应该是这样的:+数据长度+数据正文+校验

    例如:AA 44 05 01 02 03 04 05 EA

    这里我假设的一条数据,协议如下:

    数据头:     AA 44

    数据长度: 05

    数据正文: 01 02 03 04 05

    校验:       EA

    一般数据的校验,都会采用常用的方式,CRC16,CRC32,Xor。

    有的数据安全要求高的,不允许丢包的,可能还要加入重发机制或是加入数据恢复算法,在校验后根据前面数据添加恢复字节流以恢复数据。我这里采用的是简单的异或校验,包含数据头的所有字节,依次异或得到的。

    协议很简单,我也认为分析协议是很简单的事情,下面我们就如何分析协议来实际的结合c#看一下。

    er…再等等,在我们实际开始编码之前,还有一个规则需要了解,我们有了通讯协议,如何结合串口的协议来分析,需要关心什么呢?哦。一般就是4个问题:缓存收到的所有数据找到一条完整数据分析数据界面通知

    如果分的更详细一点,缓存收到的所有数据,我们想到最高效的办法就是顺序表,也就是数组,但数组的操作比较复杂,当你使用完一条数据后,用过的需要移除;新数据如果过多的时候,缓存过大需要清理;数据搬移等等,很有可能一个不小心就会丢数据导致软件出些莫名其妙的小问题。个人建议,使用List<byte>,内部是数组方式实现,每次数据不足够的时候会扩容1倍,数据的增删改都已经做的很完善了。不会出现什么小问题。

    找到一条完整数据,如何找到完整数据呢?就我们例子的这个协议,首先在缓存的数据中找AA 44,当我们找到后,探测后面的字节,发现是05,然后看缓存剩下的数据是否足够,不足够就不用判断,减少时间消耗,如果剩余数据>=6个(包含1个字节的校验),我们就算一个校验,看和最后的校验是否一致。

    分析数据:鉴于网络的开放性,我无法确定读者对c#的了解程度,介绍一下,常用的方式就是BitConvert.ToInt32这一系列的方法,把连续的字节(和变量长度一样)读取并转换为对应的变量。c++下使用memcpy,或直接类型转换后进行值拷贝,vb6下使用CopyMemory这个api。

    校验:前面说过了。完整性判断的时候需要和校验对比,大多系统都不太严格,不支持重发,所以数据错误就直接丢弃。导致数据错误的原因很多,比如电磁干扰导致数据不完整或错误、硬件驱动效率不够导致数据丢失、我们的软件缓存出错等。这些软件因素数据系统错误,需要修改,但是电磁干扰么,有这个可能的。虽然很少。

    其实我知道,就算是我,看别人的博客也是,喜欢看图片,看代码,文字性的东西,一看就头大。那我接下来贴出基于上一篇文章的改进版本,支持协议分析(协议不能配置,可配置的协议不是我们讨论的范畴。可以看看有DFA(确定性有限状态机))

    我们修改一下界面,以便能显示收到后分析的数据

    红色部分是新增的

代码如下:

 

 

至此,你只要按这个协议格式发送数据到软件打开的串口。就能在数据的data标签显示出你的数据内容,我们现在是直接显示为:

01 02 03 04 05

也就是数据段内容。

 

运行截图:

请注意红色部分

 

发送模拟数据的界面,使用通用工具SSCOMM32.exe

sscomm32.exe 发送模拟数据的界面

 

我们在回顾一下,一般二进制格式数据就是这样分析,分析数据长度是否足够,找到数据头,数据长度,校验,然后分析。

分析方式很多。结合各自实际情况操作,可以使用序列化方式,但是wince不支持,也可以用BitConvert方式将连续的字节读取为某个类型的变量。

 

希望看到这里,能给你带来帮助,欢迎大家和我讨论,希望经验丰富的朋友不吝赐教。上一篇中,有朋友说用BeginInvoke可以避免死锁问题,我暂时没有线,没有测试成功,改天测试后再公布结果。

 

DataReceived事件中,最高效的做法是指缓存数据,然后异步的去分析数据。但是,这样较复杂,在效率要求不是很高的情况下(大多数情况),可以在DataReceived事件中缓存数据后,立刻进行数据完整性检查,有效性检查,分析数据,以及更新界面。但这么做有一个隐患,底层串口操作的效率依赖于数据分析和界面更新,任何一个环节频繁耗时过长,都会造成数据的堆积。文章只假设都不拖时间的情况。

 

谢谢观赏,通讯协议分析系列,未完待续……

2010示例代码

2008示例代码

  • 33
    点赞
  • 247
    收藏
    觉得还不错? 一键收藏
  • 182
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 182
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值