嵌入式中通讯协议的设计.docVIP

嵌入式中通讯协议的设计 导语：?公司里做项目，嵌入式系统大大小小，到处都是。因为都是一个系统里的，所以都需要通讯，既然通讯就涉及到协议问题。 公司里做项目，嵌入式系统大大小小，到处都是。因为都是一个系统里的，所以都需要通讯，既然通讯就涉及到协议问题。 谈及协议，很多工程师觉得协议的设计相对简单，主要是报文的设计。大多数时候，协议的应用场景简单，没有复杂的交互。这么做的确也是没什么太大的问题。然而，就是这么简单的场景，仍有一些协议会在实际中发生意想不到的问题。归根结蒂，还是没有把握协议涉及的规律。下面我们简单的聊聊协议设计的规律。 协议设计中面临的问题： 1.设计者大多数情况下，从应用出发，仅仅考虑了基本需求的满足，没有考虑扩展需求的满足； 2.从osi七层理论上，我们往往设计的协议时站在比较高层的角度去设计，往往忽视了RS485/RS232,I2C,CAN,ETHERNET等物理层承载特点，设计缺乏对具体应用的针对性，导致潜在问题的产生； 3.容错和效率的考虑不足。 基本需求肯定是完成系统的基本功能。然而可能因为需求定义的不完整，系统设计人员没有前瞻性；协议中没有定义版本号，没有对协议兼容性的测试，导致老产品和新产品协议不兼容，而又无法采用简单的软件办法解决。这是个常见问题，最简单的办法是在握手协议中增加协议的版本号，用以判断是否对该协议支持以及为后续的软件做兼容准备。协议看似好像只有报文设计，就像一个人一样，他在父母的眼里永远是个孩子，在自己的孩子面前是父母，在朋友面前是朋友。我相信所有这些侧面合起来才是一个完整的人。UML从不同的角度去观察系统会得到不同的图。协议也是如此，协议的报文只是协议静态特性的一个方面，协议还有更重要的动态特性。如出错后怎么办，重发？重发几次？节点损坏如何从网络中剔除？怎么样才是一个完整的通讯过程？持续的时间是多少？最坏情况下是怎么样的？最好的情况下是什么样的？谁发起通讯？重要的协议可能要保证非常可靠，如何确定接受者接收的完全正确，并且可靠执行？往往这些问题已经超出了对报文自身的考虑，而是对系统解决方法的一种设计。这里有个小例子，一个RS485的半工通讯，主机向从机发送数据，希望从机可靠保存该数据；从机接收到该数据验证完毕后，写入自身的存储装置，然后再回应主机，写入成功或者失败。但这里有个问题，rs485是个主/从结构，无法同时发送数据，只能由主机点名从机回应。如果写入时间过长，从机回应报文的时间也必定过长；如果从机很多的话，这个时间就经不起浪费了。可能修改为，从机收到主机的信息后，立即应答收到。主机再分发其他从机的数据，分发完毕后，再由主机采用查询协议查询从机写入的成功与否。当然，也可以采用一些系统级的办法，只要从机收到数据后，从机一定保证数据写入成功，那么这个问题也变得简单了。主机也不用再查询写入是否成功了。软件的设计也就相对简单很多。 RS485/RS232也有双工通讯，但在实际中用得少。这里除了省线材之外，恐怕最重要的是因为RS485/RS232不带冲突检测，要么采用大家轮桩做主机，要么一个主机，点名让大家发言的办法。所以，通讯采用一问一答的方法比较多，这比较符合半工的工作状态。当然不排除一些双工的应用场景。实际应用中，大多数还是采用半工的办法。这里协议的设计主要考虑单点较多；多播和单播，因为不能确定从机是否接收成功，所以重要的协议在多播和广播之后还要查询，这个是很麻烦的事情。软件过程因此而复杂很多。RS485/RS232的通讯有自己的检测错误的办法，比如说奇偶校验，奇偶校验是一种简单的错误校验，并不能100%的挡住错误；对于可靠地协议，可能还是要设计自己的CRC或者校验和等方法。但CRC校验虽然可以用查表的办法，但计算时间比奇偶校验和校验和等方法计算量还是过大了些。在一些实时性和低端应用场合，可能时间开销大了些。所以，如果报文不是过大，还是可以考虑奇偶校验和校验和；如果过大，先考虑crc8，再考虑crc16和crc32，不要一竿子切。 I2C的通讯一般只用于板级，但现在也有用于现场总线的趋势。I2C设计之初是支持多主多从，两个主机可以同时发送信息，仲裁获胜的主机获得总线，继续发送。有仲裁不代表可以同时双向发送信息，即主机和从机的地位还是不同的，主机点名从机回应信息；虽然现在的CPU所带的I2C硬件同时支持主模式和从模式，但在同一时刻，这两个模式是不相容的。对于一个节点要么是主要么是从，而每次通讯都是由主发起，从被动接收，这就导致了和rs232无本质的区别。且，I2C的物理层协议也决定了，其通讯方式也没有rs232灵活，只能工作在半工状态。两个CPU传递一些简单的信息，在CPU无多余的rs232情况