设计前向兼容通信协议的指南？

Question

我正在研究嵌入式设备之间的通信协议。该协议将来肯定需要新的命令和字段。我需要做些什么来确保我不会把自己画成一个角落？

Answer 1

这是一个广泛的问题。以下是一些关于它的随机想法：

1. 留下备件。
2. 使用一个非常基本的标题，其中包含“要遵循的字节数”字段。
3. 如果存在枚举的消息类型，请确保类型字段可以容纳 增长。
4. 如果您使用位标志，请留下备件。
5. 可能包含“原始数据”消息，可用于包装后代想到的任何协议。

总之，留下备件。

Answer 2

如果可能，请让电缆一端的人员弄清楚电缆另一端的内容。 理想情况下，人类可以连接一个哑终端并敲击键盘三次（输入问号输入），然后会返回一条长而详细的消息来描述它是什么类型的机器，它的型号是什么，名称和构建它的组织的电话号码和网站，“官方”协议版本号和非正式构建时间：

__DATE__ ": " __TIME__

每次机器启动时也会发送相同的详细信息。

如果可能的话，尝试设计您的协议，以便有哑终端的人可以与您的设备通话。 HTTP是一种这样的人类可读协议，我怀疑这是它受欢迎的原因之一。 人类可读意味着，除其他外：

• 限制自己可以阅读和输入的字符。 避免特殊控制字符。利用the power of plain text。
• 始终在每个数据包的末尾发送CR + LF（按照许多Internet协议的要求）。
• 无论如何都要接受字符，从最高速度的文件上传到PC，再到非触摸打字的人慢慢啄食键盘。

您可能还想浏览common protocols for embedded systems列表。 也许一个已满足您的要求？ 有没有理由使用比标准Netstring format更难解码的东西？

Answer 3

对于一个明确的答案，这个问题有点过于笼统。嵌入式系统可能需要与许多方面进行通信;

需要与多少同伴进行通信？ 沟通需要多少数据？ 系统需要紧密同步的程度如何？ 协议的物理介质是什么，带宽限制和错误敏感性考虑因素是什么？

所有这些要求和资源限制肯定会限制系统，然后您就可以开始弄清楚协议需要什么。一旦您了解了这些问题，就可以预测未来某些要求可能会如何变化/扩展。从那里，您可以设计协议以适应（或不适应）最坏情况的用例。

Answer 4

我会使用HDLC。我过去好运。我想要点串口只使用Asynchronous framing并忘记所有其他控件的东西，因为它可能会有点过分。

除了使用HDLC进行数据包的成帧外。我格式化我的数据包如下。这是使用802.11

传递选项的方式

U8 cmd;
U8 len;
u8 payload[len];

每个命令包的总大小为len +2

然后定义像

这样的命令

#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02

另一个优点是你可以添加新命令，如果正确设计解析器以忽略未定义的命令，那么你将具有一些向后兼容性。

因此将数据包放在一起将如下所示。

 // total packet length minus flags len+4
 U8 sflag;   //0x7e start of packet end of packet flag from HDLC
 U8 cmd;     //tells the other side what to do.
 U8 len;     // payload length
 U8 payload[len];  // could be zero len
 U16 crc;
 U8 eflag;   //end of frame flag

系统将监视串行流的标志0x7e，当它在那里时，检查长度，看它是pklen＆gt; = 4和pklen = len + 4，并且crc是有效的。注意不要只依靠crc来获取小包，你会得到很多误报也检查长度。如果长度或crc不匹配，只需重置长度和crc，然后从解码新帧开始。如果匹配则将数据包复制到新缓冲区并将其传递给命令处理函数。收到标志时，务必重置长度和crc。

对于命令处理函数，请抓取cmd和len，然后使用开关处理每种类型的命令。我还要求某些事件发送响应，因此系统的行为类似于事件驱动的远程过程调用。

因此，例如，传感器设备可以具有计时器或响应命令以获取读数。然后它会格式化数据包并将其发送到PC，PC将响应它收到的数据包。如果没有，则传感器设备可以在超时时重新发送。

此外，当您进行网络传输时，您应将其设计为OSI modle之类的网络堆栈。 HDLC是data link layer和RPC and command handling is the Application Layer。