embedded - 如何为嵌入式系统设计串行命令协议(protocol)?

标签 embedded serial-port

我有一个嵌入式系统,通过串行方式与之通信。现在的命令结构被设计为交互式操作:它显示提示,接受一些命令,并以人类可读的形式显示结果。

我正在考虑将其更改为更适合机器使用的格式,这样我就可以通过 MATLAB GUI 与它对话,而不会遇到太多麻烦(现在它在交互式提示和不同消息长度等方面出现问题)。

那么是否有文档或标准描述如何为您的嵌入式系统设计良好的串行命令协议(protocol)?

最佳答案

我对编写使用 RS232 控制媒体和显示设备的软件有一些偏好(和烦恼)。根据您的硬件,其中一些可能不适用:

  • 我认为让您的协议(protocol)对自动化更加友好是个好主意。如果您需要交互式界面(命令行或其他),请单独构建它并让它使用自动化协议(protocol)。我不会太担心它是否可读,但这取决于你。

  • 始终返回响应,即使(特别是)您收到无效命令。一些简单的东西,例如 ACK 为 06 美元,NAK 为 15 美元。或者,如果您希望它更容易阅读,请将其拼写出来。

  • 如果您可以设置任何值,请确保有某种方法可以查询相同的值。如果您有很多值,则可能需要一段时间才能查询所有值。考虑使用一个或几个元查询一次返回多个值。

  • 如果您有无法设置但很重要的信息(型号、序列号、版本、版权等),请确保可以查询这些信息,而不是仅在启动或重置时显示一次.

  • 永远不要对有效命令做出错误响应。您可能认为这一点是显而易见的......

  • 说到显而易见,请记录您的硬件支持的串行设置。特别是如果它要由除您之外的任何人使用,并且您不希望他们在前 30 分钟内尝试弄清楚他们是否由于串行端口、连接、电缆或其他原因而无法与设备通信。他们的软件。并不是说我很苦……

  • 使用绝对命令而不是切换值。例如,使用单独的开机和关机命令,而不是发送相同的命令并打开和关闭电源。

  • 响应应包含有关其响应的命令的信息。这样,任何程序都不需要记住它要求的最后一件事来处理响应(请参阅下面的额外信用选项)。

  • 如果您的设备支持待机模式(关闭,但不是真正关闭),请确保在此状态下查询仍然有效。

取决于您对数据完整性的偏执程度:

  • 将您的消息放入信封中。 header 可以包括起始字符、消息长度和结束字符。以防万一您收到部分或格式错误的消息。也许开始时为 02 美元,结束时为 03 美元。

  • 如果您确实对消息完整性很偏执,请包含校验和。不过,它们可能有点痛苦。

额外积分:

  • 如果您的硬件设置可以手动更改,则可以将此更改发送到串行端口,就像用户已查询它一样。例如,您可能不希望用户能够更改公共(public)显示监视器的输入源。

我希望这会有所帮助。

更新:

我忘记了一些重要的事情。在你认真使用它之前,特别是在将它分发给其他人之前,请在一些琐碎的事情上尝试一下,以确保它按照你期望的方式工作,并且(更重要的是)确保你没有遗漏任何东西。如果您在较大的项目中发现问题,则需要更多的时间和精力来解决问题。

无论您是设计命令协议(protocol)、Web 服务、数据库模式还是类等,这都是一个很好的经验法则。

关于embedded - 如何为嵌入式系统设计串行命令协议(protocol)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1445387/

相关文章:

c - 更快读取串口

linux - "Real-Time"怎么是Linux 2.6?

c - 一根线串口通讯,回显错误

c - 串行编程 - Termios。从设备读取 0x00 字节时卡住

c - sleep 必须在 tcdrain() 之后吗?

interface - 处理器与高速外设之间的通信

c - 调试时从寄存器中提取单个位

c - STM32F103 在 RX 中断时无法通过 UART 接收数据

linux - 读取 VirtualBox 使用的端口的原始 USB 数据

c++ - Boost Asio串口问题