应用通信协议的处理过程

10 篇文章 0 订阅
7 篇文章 0 订阅

随着工业控制设备的需求增加,各种控制设备的研制,在日常的工作中,是经常遇到的事情。

在远动系统里面,控制器到控制器,控制器到PC机或者到服务器之间都存在着数据交互的过程,一般都是基于串行通信的通信规约来实现的。

可以是总线式的RS485,CAN总线等,也可以是点对点的RS232,或者以太网TCP或者是UDP。

而通信规约或者称为应用通信协议为了适应各种不同设备之间的数据交换,其实现的灵活性非常高。比如在单片机里,我们要实现modbus协议的子站程序,而在嵌入式linux设备中,我们也经常要实现modbus协议的子站程序,这两种需求是一样的,但是用于实现该功能的资源却相差甚远。包括处理器的处理能力,内存空间等等。

但是应用通信协议实现的大概过程是类似的:报文接收,报文缓存,报文解析,帧处理,报文编码,报文发送。

真正要把这几个过程都实现好,也非易事。


报文接收和报文发送:

对于单片机或者DSP来说,需要熟练操作各种寄存器,同时还要考虑如何提升处理器的执行效率。因为毕竟通信外设相对应处理器来说是慢速设备,你不能让处理器只用来处理通信数据的收发工作。一般地,可以开启FIFO功能,使用DMA,使用中断。这个时候需要处理好和CPU之间的异步和同步的问题。

而对于有操作系统的,比如PC机或者嵌入式linux的应用程序来说,可能只需要调用系统的读写函数即可。但是也要注意缓冲区的大小,异步通信的问题。

由于异步的关系,应该多考虑解析报文和接收报文可能不同步,编码报文和发送报文也不同步的情况。

缓冲区应该使用循环缓存队列的方式来实现。


报文解析:

对于程序员而言,应该尽量让他的代码可重用。报文解析这样的功能应该做成不管在什么平台,不管在什么项目中,代码都应该可以重用。

报文解析的时候需要注意,由于应用程序缓存住的报文是有限的,通信双方是异步的,对收到的报文既要及时丢弃无效的内容,又不能错过任何一种可能的报文顺序的帧。


帧处理:

只有解析到正确的报文时,才需要将该内容提交给处理程序来处理。这里也需要考虑一些情况,比如挂灯笼的方式连接的设备。收到的报文不见得就是给你的报文,还需要遴选出属于自己的报文。比如modbus协议中的设备地址字段。

帧处理包括对接收到的帧处理,当然还得包括组织需要发送的帧。

这块内容才应该是应用程序的核心业务。


报文编码:

报文编码和报文解析都应该是和报文结构相关的内容。而和具体的应用业务关系不大。我一般的处理方式会定义一个专门的帧类,来负责解析和编码工作。而提交给应用处理的就是帧内部的数据项了。


我们一般做程序,提前为调试做一些工作是很重要的。尤其是通信规约,除了调试自身的程序外,还应该为联调做一些工具。比如:查看收到报文,查看发送出去的报文之类的。




我自己也设计了一个规约处理框架。是基于C++实现的。目前在Ti DSP 28系列和67系列,以及Qt中都可以使用。


CProtocolBase实现了通信规约的基类功能。



规约使用时非常简单


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值