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

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

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

它需要与多少同龄人沟通？ 通信需要多少数据？ 系统需要有多紧密的同步？ 协议的物理介质是什么？带宽限制和易出错因素是什么

---

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

这是一个悬而未决的问题。以下是一些随机的想法：

留下备用的

使用带有“要跟随的字节数”字段的非常基本的标题

如果存在枚举消息类型，请确保类型字段可以容纳 成长

如果使用位标志，请保留备用

可能包含一条“原始数据”消息，可用于包装后代想出的任何协议

总之，请留下备件。

我会使用。我过去在这方面运气很好。对于点对点串行，我只需要使用，而忘记所有其他控制内容，因为这可能会有点过头

除了使用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将响应它已收到该数据包。如果没有，则传感器设备可以在超时时重新发送

---

此外，在进行网络传输时，还应将其设计为网络堆栈，如。HDLC是最重要的，如果可能的话，允许电缆一端的人找出电缆另一端的内容。 理想情况下，一个人可以连接一个哑终端并敲击键盘三次（输入问号Enter），然后会返回一条长而详细的消息，描述它是什么类型的机器，它的型号是什么，它的名称和电话号码以及制造它的组织的网站，“官方”协议版本号，以及非官方的构建时间：

__DATE__ ": " __TIME__

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

如果可能的话，试着设计你的协议，让一个有哑终端的人可以和你的设备通话。 HTTP就是这样一种人类可读的协议，我怀疑这是它流行的原因之一。 除其他外，人类可读性意味着：

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

您可能还想浏览一下列表。 也许其中一个已经满足了你的要求？

---

有什么理由使用比标准更难解码的东西吗？

我不是在征求关于整个设计的建议，只是在寻求关于使其具有未来性的建议。也许一个更好的问题是，“我应该避免哪些特定的事情来创建一个前向兼容的comms协议？”