如何为嵌入式系统设计串行命令协议？ [英] How do you design a serial command protocol for an embedded system?

问题描述

我有一个嵌入式系统，我正在与串口进行通信。命令结构现在被设计为交互式操作：它显示提示，接受几个命令，并以人类可读的形式显示结果。

我是考虑将其更改为更多的机器可用格式，所以我可以通过MATLAB GUI与它进行交谈，而不会有太多麻烦（现在它在交互式提示和不同的消息长度等方面打嗝）。

是否有文档或标准描述如何为嵌入式系统设计好的串行命令协议？

解决方案

从编写软件到使用RS232控制媒体和显示设备时，我有一些偏好（和宠物小费）。取决于您的硬件，其中一些可能不适用：

• 我认为使您的协议更友好是一个好主意自动化。如果您需要交互式界面（命令行或其他），请单独构建并使用自动化协议。我不会太担心使它变得人性可读，但这取决于你。




• 总是返回一个响应，甚至（特别是）如果你得到无效命令。一些简单的例如$ 06，ACK和$ 15为NAK。或者拼写出来，如果你想让它更容易人性化。




• 如果你可以设置任何值，请确保有一些方法来查询相同的值。如果你有很多价值观，可能需要一段时间才能查询。考虑有一个或几个元数据查询一次返回几个值。




• 如果您的信息无法设置，但重要（型号，序列号，版本，版权等），请确保这些可以被查询，而不是在启动或重置时只显示一次。




• 对于有效的命令有错误。你会认为这一点会很明显...




• 说明一下，记录您的硬件支持的串行设置。特别是如果它将被除了你以外的任何人使用，并且你不希望他们花上30分钟的时间，试图弄清楚他们是否因为串行端口，连接，电缆或者电缆他们的软件。不是我很苦...




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




• 响应应包括有关他们正在回应的命令。这样，任何程序都不需要记住为了处理响应而要求的最后一件事情（见下面的额外信用选项）。




• 如果您的设备支持待机模式（关闭但不是真正关闭），请确保在处于此状态时，查询仍然可以工作。

根据数据完整性的偏执程度如何：

• 将信息包裹在信封中。标题可以包括起始字符，消息的长度和结束字符。以防万一发生部分或格式错误的邮件。也许$ 02开始，$ 03结束。




• 如果您对邮件完整性真的偏执，请包括一个校验和。

额外的功劳：

• 如果您的硬件设置可以手动更改，可能会将该更改发送到串口，就像用户已经查询一样。例如，您可能不希望用户能够更改公共显示器的输入源。

我希望这有助于

更新：

我忘了一些重要的事情。在你使用这个方法之前，特别是在把它交给别人之前，请尝试一下这些东西，以确保它按照你期望的方式工作（更重要的是）确保你没有留下任何东西。如果在更大的项目中发现问题，需要更多的时间和精力才能解决问题。

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

I have an embedded system I'm communicating with over serial. The command structure right now is designed to be operated interactively: it displays a prompt, accepts a few commands, and displays results in a human-readable form.

I'm thinking about changing this to a more machine-usable format, so I can talk to it through a MATLAB GUI without too much trouble (right now it's hiccuping on the interactive prompts and varying message lengths, etc.).

So is there a document or standard somewhere that describes how to design a good serial command protocol for your embedded system?

解决方案

I have some preferences (and pet peeves) from writing software to control media and display devices using RS232. Depending on your hardware, some of these may not apply:

• I think it's a good idea to make your protocol more friendly for automation. If you need an interactive interface (command line or other), build it separately and have it use the automation protocol. I wouldn't worry too much about making it human readable, but it's up to you.

• Always return a response, even (especially) if you get an invalid command. Something simple like $06 for ACK and $15 for NAK. Or spell it out if you want it to be slightly more human readable.

• If you can set any value, make sure there's some way to query that same value. If you have a lot of values, it could take a while to query them all. Consider having one or just a few meta-queries that return several values at once.

• If you have information that can't be set, but is important (model no, serial no, version, copyright, etc), make sure these can be queried instead of just displaying them once on startup or reset.

• Never respond with an error for a valid command. You'd think this one would be obvious...

• Speaking of obvious, document the serial settings your hardware supports. Especially if it's going to be used by anyone other than you and you don't want them to spend the first 30 minutes trying to figure out if they can't talk to the device because of the serial port, the connections, the cable or their software. Not that I'm bitter...

• Use absolute commands instead of toggle values. For example, have separate commands for Power On and Power Off instead of sending the same command and having the power toggle on and off.

• Responses should include information on the command they are responding to. This way any program doesn't need to remember the last thing it asked for in order to deal with the response (see extra credit option below).

• If your device supports a standby mode (off, but not really off), make sure queries still work while you're in this state.

Depending on how paranoid you are about data completeness:

• Wrap your message in an envelope. The header could include a starting character, the lengeth of the message and a closing character. Just in case you get partial or malformed messages. Maybe $02 for the start and $03 for the end.

• If you're really paranoid about message integrity, include a checksum. They can be a bit of a pain, though.

For extra credit:

• If your hardware settings can be changed manually, maybe send this change out the serial port as if the user had queried it. For example, you might not want the user to be able to change the input source for a public display monitor.

I hope this helps.

Update:

I forgot something important. Before you either use this seriously and especially before you give it out to someone else, try it out on something trivial to make sure it works the way you expect it to and (more importantly) to make sure you haven't left anything out. It will take more time and effort to fix things if you find a problem in the middle of a bigger project.

This is a good rule of thumb whether you're designing a command protocol, a web service, a database schema or a class, etc.

这篇关于如何为嵌入式系统设计串行命令协议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！