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

Question

我正在研究嵌入式设备之间的通信协议。该协议将来肯定需要新的命令和字段。我需要做什么才能确保自己不会陷入困境？

Answer 1

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

1. 留下备件。
2. 使用带有“遵循的字节数”字段的非常基本的标头。
3. 如果有枚举的消息类型，请确保类型字段可以容纳
   生长。
4. 如果您使用位标志，请保留备用位。
5. 可能包括“原始数据”消息，该消息可用于包装后代想到的任何协议。

总结一下，留备件。

Answer 2

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

__DATE__ ": " __TIME__

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

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

• 将自己限制为人类可以阅读和输入的字符。
  避免特殊控制字符。利用纯文本的力量。
• 始终在每个数据包末尾发送 CR+LF（按照许多 Internet 协议的规定）。
• 接受任何速率的字符，从 PC 的最大速度文件上传到非触摸打字的人慢慢地敲击键盘。

您可能还想浏览一下嵌入式系统的常用协议列表。
也许其中一个已经满足您的要求了？
是否有任何理由使用比标准 Netstring 格式更难解码的格式？

Answer 3

这个问题有点太笼统，无法给出明确的答案。嵌入式系统可能需要在很多方面进行通信，例如：

它需要与多少个同行进行通信？
需要多少数据才能通信？
系统需要有多紧密的同步？
协议的物理介质是什么？带宽限制和错误敏感性考虑因素是什么？

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

Answer 4

我会使用HDLC。我过去在这方面运气很好。对于点对点串行，只需使用 异步帧 并忘记所有其他控制的东西，因为它可能是矫枉过正的。

此外还使用 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 >= 4 且 pklen=len+4 以及 crc 是否有效。请注意，不要仅依赖 crc 来处理小数据包，在检查长度时您也会得到很多误报。如果长度或 crc 不匹配，只需重置长度和 crc 并开始解码新帧。如果匹配，则将数据包复制到新缓冲区并将其传递给命令处理函数。当收到标志时，总是重置长度和 crc。

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

例如，传感器设备可以具有计时器或响应命令来读取读数。然后它会格式化一个数据包并将其发送到 PC，PC 会响应它收到了该数据包。如果不是，则传感器设备可能会在超时时重新发送。

此外，当您进行网络传输时，您应该将其设计为网络堆栈，例如 OSI 模型 。 HDLC 是数据链路层和RPC 和命令处理是应用层。