关于RS485总线通信调试和编程代码需要注意的问题.docxVIP

关于RS485总线通信调试和编程时需要注意的问题以下经验是自己在开发广电1KW多类型激励器数字发射机项目时的一些经验之谈，尤其对于新同事可能在今后工作中遇到类似问题时，也许在读完本文之后或许有可能会让他们少走点弯路吧，于是乎，在此记录下来。关于RS485总线之于RS232的通讯距离更远、实现一对多通讯等等的多种优势就跳过直接不谈了，主要讲述一下实际工作中的遇到的问题、解决方法。在本次工作前期，更换激励器，无非首要任务是要让新激励器与CCU通讯上，原设备采用的是串口复用方式在同一个RS485串口上与主备切换板等多个模块进行通信，在与系统组态的时候如果发现部分设备通信不上，我们就应该注意以下问题。（一）、硬件层面：（1）、确保线路不短路，不断路。其实这应该不是问题，但却是我们部分（尤其是软件工程师）容易忽视的问题，往往认为线路没有人动应该肯定是没有问题的，结果在软件上找了半天，最后发现原来却是最基本的断路问题就尴尬了。之所以提出来是因为以前好像也有类似情况发生过，再者，大家不要笑话我，我在这也卡了一个下午，因为当时供应商只提供了一台新激励器，测试部和研发部以及其它部门都要用它，过于频繁的插拔线导致后面RS485与主备切换板的通讯线看似完好，实则里边断路了。（2）、确保RS232转RS485时转出来时的接口线序问题。很多时候惯性思路的以为，一般转出来的不就是RS232或者RS485的标准接口嘛，这不可能是问题，而一旦出现问题就很难发现，就比如这次德兴激励器，由于供应商德兴的激励器的硬件版本变化很快，他们做出来的RS232接口和配套的RS232转RS485的接头的数据收发TX和RX居然是与标准头是数据收发接头是反的。当时也正是自己的“以为”也给我的通讯调试造成了一点滴小困扰。（二）、系统层面：（1）、波特率配置这个应该一般人通讯不上，都会想到的，只是在这里再提一下。（2）、通讯协议通讯协议就相当于语言规范，二个模块和设备通讯上不时，我们在确保硬件线没有问题后再确保是否所发命令是否按相关通讯协议在通信的。（3）、地址位二个模块要通讯上，当然首先要能识别对方，一般采用地址位识别，如果通讯不上，我们首要检查的这个，事实上很多设备的地址位是可设的，就比如激励器，主备机的地址位不同且可调。感觉有点像也是属于通讯协议的范畴。以上是通讯调试时应该注意的问题。接下来要说的是一些关于RS485软件编程要注意的问题。（三）、软件编程：通信交互方式RS485基本上采用一问一答的交互方式，主设备向从设备（这里是激励器）发送一条指令，从设备执行指令之后，返回一条应答命令。为了减少数据流，德兴激励器的处理方法是在设置时并没有回复一个设置确认包来确认是否设置成功，而事实上我们是在不断查询激励器的数据回复包的，通过查询判断设置前后数据包的差异性来是完成可以判断是否设置成功的，这样很好的减少了没有必要的数据流在总线上的交互。数据接收处理方法（a）方法1：对于数据接收，最直观的想法是每接收到第1个字符之后，就立刻判断是否与本机地址匹配，否则停止接收数据，等待一段时间之后再接收。（停止接收数据的目的在于丢掉该帧后续的数据。）暂且把这个方法叫做方法1，事实上，对于这种方法，停止接收的时间段一般是固定的且预留得比较宽，有可能在停止接收的这个时间段内收到属于本机的数据帧，却没收到。如过总线上数据量大的话，可能会一直存在这种问题，一直通信不上。所以数据接收处理方法不合理也是会通讯不上的哦。（b）方法2：和方法1不一样的是，在收到第1个字符之后，不立即处理，直到接收完整的长度（德兴激励器数据回包是LEN=65字节）后，再根据长度描述符定义的长度，接收完一帧之后再处理。处理包括地址判断、CRC校验、以及协议解析等。此方法2的特点：能很快的接收到完整的数据包，但是不是本地的数据包也接收进来了，对低端的CPU来说是个压力。不过还好，我们公司的公司好歹是ARM9，应该问题不大。（c）方法3：目前采用的是方法3，它也许不应该叫方法3的，因为只是在方法2的基础上增加了超时处理机制，收到1个字符之后，如果超过多长时间没有接收到下一个字符，则认为是数据包结束，对数据进行处理。显然这样处理以后，虽然对CPU也许会有一定的压力（由于我们用的不是低端CPU，这里只是充分利用，不予以考虑），但是接收效果肯定是最好，且响应迅速。消息队列接收、发送阻塞与非阻塞的注意事项阻塞和非阻塞书上说的很专业，看起来有时也许都会晕，其实用我自己理解的意思就是：阻塞就是干不完不准回来;非阻塞就是你先干，我先看看有其他事没有，完了告诉我一声。之所以提出这点，是因为当时调试的时候一度CPU占用率过高，有怀疑过是这里的原因。消息队列可以说是Linux五大进程通信方法中比较经典的方法之一了，当然每种进程通信方式实现方式和功能不一样，