【转】C# 串口操作系列(4) -- 协议篇,文本协议数据解析

上一篇已经介绍了协议的组成,一个协议,一般具有 :协议头+长度+数据+校验 , 文本格式可以直观的定义回车换行是协议的结尾,所以我们可以省略数据长度,增加协议尾。即: 协议头 + 数据 + 校验 + 数据尾 。

文本方式的数据比较容易分析。如果数据缓存,可以考虑用StringBuilder。或是不缓存也可以。文本格式数据大多有换行结尾。稍微修改即可。例如分析常见的NMEA 0183格式的卫星坐标数据GGA。

$GPGGA,121252.000,3937.3032,N,11611.6046,E,1,05,2.0,45.9,M,-5.7,M,,0000*77

$              开始

GPGGA     命令字

*              结尾

77            校验

对上一篇代码稍作修改就可以了。例子不贴了。文本格式比较简单,只是为了内容完整。贴来做参考。只有分析的地方简化很多。

[c-sharp] view plaincopy

  1. void comm_DataReceived(object sender, SerialDataReceivedEventArgs e)
  2. {
  3. if (Closing) return;//如果正在关闭,忽略操作,直接返回,尽快的完成串口监听线程的一次循环
  4. try
  5. {
  6. Listening = true;//设置标记,说明我已经开始处理数据,一会儿要使用系统UI的。
  7. //文本格式比较简单,你可以死等。
  8. string line = comm.ReadLine();//这就得到回车换行结尾的了。但是不是从头开始的就要检查了
  9. /////////////////////////////////////////////////////////////////////////////////////////////////////////////
  10. //<协议解析>
  11. //因为恢复的代码在finally中。你可以直接的return
  12. if(line[0] != ‘$‘) return;//虽然可能有点垃圾,但是数据不重要。直接丢弃就可以了。后续的都是对的
  13. int star = line.IndexOf("*",1);
  14. if(star == -1) return;
  15. //根据$后面数据计算异或校验,并和*后面的数字对比。如果不同,也不进行分析。因为校验错误
  16. //当确定头尾存在,校验正确。就可以分析数据了。
  17. //分析数据
  18. //略
  19. //因为要访问ui资源,所以需要使用invoke方式同步ui。
  20. this.Invoke((EventHandler)(delegate
  21. {
  22. //判断是否是显示为16禁止
  23. if (checkBoxHexView.Checked)
  24. {
  25. //依次的拼接出16进制字符串
  26. foreach (byte b in buf)
  27. {
  28. builder.Append(b.ToString("X2") + " ");
  29. }
  30. }
  31. else
  32. {
  33. //直接按ASCII规则转换成字符串
  34. builder.Append(Encoding.ASCII.GetString(buf));
  35. }
  36. //追加的形式添加到文本框末端,并滚动到最后。
  37. this.txGet.AppendText(builder.ToString());
  38. //修改接收计数
  39. labelGetCount.Text = "Get:" + received_count.ToString();
  40. }));
  41. }
  42. finally
  43. {
  44. Listening = false;//我用完了,ui可以关闭串口了。
  45. }
  46. }
时间: 2024-11-10 15:15:03

【转】C# 串口操作系列(4) -- 协议篇,文本协议数据解析的相关文章

C# 串口操作系列(2) -- 入门篇,为什么我的串口程序在关闭串口时候会死锁 ?

C# 串口操作系列(2) -- 入门篇,为什么我的串口程序在关闭串口时候会死锁 ? 标签: c#objectuibyte通讯.net 2010-05-19 08:43 55212人阅读 评论(188) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 第一篇文章我相信很多人不看都能做的出来,但是,用过微软SerialPort类的人,都遇到过这个尴尬,关闭串口的时候会让软件死锁.天哪,我可不是武断,算了.不要太绝对了.99.9%的人吧,都遇到过这个问

【转】C# 串口操作系列(1) -- 入门篇,一个标准的,简陋的串口例子。

我假设读者已经了解了c#的语法,本文是针对刚打算解除串口编程的朋友阅读的,作为串口编程的入门范例,也是我这个系列的基础. 我们的开发环境假定为vs2005(虽然我在用vs2010,但避免有些网友用2005,不支持lambda,避免不兼容,就用2005来做例子) 一个基本的串口程序,既然是个程序了.我们就先从功能说起,包含 串口选择 波特率选择 打开 关闭 接受数据显示 发送数据输入 发送数据 数据量提示以及归零 好吧,有了这些功能,我们就先画出界面.例如: 这里,波特率就定死几种好了.直接界面上

【转】C# 串口操作系列(2) -- 入门篇,为什么我的串口程序在关闭串口时候会死锁

第一篇文章我相信很多人不看都能做的出来,但是,用过微软SerialPort类的人,都遇到过这个尴尬,关闭串口的时候会让软件死锁.天哪,我可不是武断,算了.不要太绝对了.99.9%的人吧,都遇到过这个问题.我想只有一半的人真的解决了.另外一半的人就睁只眼闭只眼阿弥佗佛希望不要在客户那里出现这问题了. 你看到我的文章,就放心吧,这问题有救了.我们先回顾一下上一篇中的代码 [c-sharp] view plaincopy void comm_DataReceived(object sender, Se

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

C# 串口操作系列(3) -- 协议篇,二进制协议数据解析 标签: c#bufferobject通讯byte硬件驱动 2010-05-27 09:54 51565人阅读 评论(215) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 我们的串口程序,除了通用的,进行串口监听收发的简单工具,大多都和下位机有关,这就需要关心我们的通讯协议如何缓存,分析,以及通知界面. 我们先说一下通讯协议.通讯协议就是通讯双方共同遵循的一套规则,定义协议的原则是尽可

C# 串口操作系列(4) -- 协议篇,文本协议数据解析

C# 串口操作系列(4) -- 协议篇,文本协议数据解析 标签: c#uiobjectstringbyte 2010-06-09 01:50 19739人阅读 评论(26) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 上一篇已经介绍了协议的组成,一个协议,一般具有 :协议头+长度+数据+校验 , 文本格式可以直观的定义回车换行是协议的结尾,所以我们可以省略数据长度,增加协议尾.即: 协议头 + 数据 + 校验 + 数据尾 . 文本方式的数据比

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

我们的串口程序,除了通用的,进行串口监听收发的简单工具,大多都和下位机有关,这就需要关心我们的通讯协议如何缓存,分析,以及通知界面. 我们先说一下通讯协议.通讯协议就是通讯双方共同遵循的一套规则,定义协议的原则是尽可能的简单以提高传输率,尽可能的具有安全性保证数据传输完整正确.基于这2点规则,我们一个通讯协议应该是这样的:头+数据长度+数据正文+校验 例如:AA 44 05 01 02 03 04 05 EA 这里我假设的一条数据,协议如下: 数据头:     AA 44 数据长度: 05 数据

C# 串口操作系列(4) -- 协议篇,文本协议数据解析(转)

上一篇已经介绍了协议的组成,一个协议,一般具有 :协议头+长度+数据+校验 , 文本格式可以直观的定义回车换行是协议的结尾,所以我们可以省略数据长度,增加协议尾.即: 协议头 + 数据 + 校验 + 数据尾 . 文本方式的数据比较容易分析.如果数据缓存,可以考虑用StringBuilder.或是不缓存也可以.文本格式数据大多有换行结尾.稍微修改即可.例如分析常见的NMEA 0183格式的卫星坐标数据GGA. $GPGGA,121252.000,3937.3032,N,11611.6046,E,1

【转】C# 串口操作系列(5)--通讯库雏形

串口是很简单的,编写基于串口的程序也很容易.新手们除了要面对一堆的生僻概念,以及跨线程访问的细节,还有一个需要跨越的难题,就是协议解析,上一篇已经说明了: 一个二进制格式的协议一般包含: 协议头 + 数据段长度 + 数据  + 校验 一个Ascii格式的文本协议,一般包含: 数据头 + 正文 + 数据结束标识 类似的命令可能很多,类似的代码也会重复写很多次.对于我,并不觉得这个有任何难度,但是,很多时候,需要写点类似东西的时候呢,我往往不想写,不是别的,要搭建一个这样的框架,这绝对是个体力活,而

Docker系列-第五篇Docker容器数据卷

1.是什么 在生产环境中使用 Docker,往往需要对数据进行持久化,或者需要在多个容器之间进行数据共享,这必然涉及容器的数据管理操作 . 容器中的管理数据主要有两种方式 : 数据卷 ( Data Volumes ) : 容器内数据直接映射到本地主机环境: 数据卷容器( Data Volume Containers ) : 使用特定容器维护数据卷. 一句话:有点类似我们Redis里面的rdb和aof文件 将运用与运行的环境打包形成容器运行 ,运行可以伴随着容器,但是我们对数据的要求希望是持久化的