通过串行端口通信有更高级别的协议吗？
我们正在开设机器人学课程，Xbee 是学生最喜欢的通信协议。在过去的两年里，我们帮助他们建设了大约 62 个不同的项目（还有 40 个项目正在筹备中）。
几乎所有项目都涉及向机器人发送不同类型的数据。有时它是一个 1 字节命令，有时它是一个要解释的长字符串。有时，当一个 xbee 在广播模式下使用一个 xbee 向多个机器人中的一个特定机器人发送消息时，我们会遇到寻址机器人的问题。学生们每次都发挥自己的创造力来解决这个问题。
我个人觉得这是重新投资轮子。我想知道串行端口通信是否存在任何更高级别的协议提案，如果没有任何特定的协议设计，我想知道是否值得为学生的需求设计一个协议。
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您的意思是您系统的内部仅协议吗？如果是的话，嵌入式软件工程师通常倾向于推出自己的协议。他们中的大多数人都说这可以让他们制作出最优化的系统。
这不是理想的方法。我同意你的观点，学生学习好的例子是有好处的。
不幸的是，我不知道任何协议栈适合机器人应用程序。但我建议您尝试 Google 的协议缓冲区系统，它能够简化构建协议引擎的大部分工作，并且它也可以与普通 c 一起使用。
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
如果您想使用已经开放的标准协议，则可以实施 Modbus ASCII。
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli 是一种主/从协议，用于某些较旧的设备或无法使用以太网时。如果您询问，您可能可以从 ABB 获得规格 - 这不是什么秘密。
也就是说，您可以在其之上放置一个 OPC 服务器/客户端架构，以获得更强大的通信，例如，
这将使您的 OPC UA 客户端协议独立，从而使事情变得更容易。
Modbus 是另一种广泛使用的串行协议，
我相信 OPC 将为您提供您想要的高级操作。
看
www.opcfoundation.org
www.abb.com
PS。 OPC UA 与旧的 OLE 版本不同，因此与 COM/DCOM 无关
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
正如mjh2007所说，Modbus是标准的、开放的、简单的。我能看到的唯一问题是，如果您希望机器人“快速”响应命令，因为串行 Modbus 使用超时来检测数据包的结尾。您可以通过忽略超时要求并根据接收数据包的功能代码和参数计算数据包的预期大小来解决此问题，然后您可以在收到最后一个字节并验证任何校验和后立即开始处理命令。 此页面提供了有关实施此类方案的更多详细信息。
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
请务必使用在 API 模式下运行且 ATAO 设置为 1 的 XBee 模块的“显式传输”帧（类型 0x11）。您可以单播到网络上的特定机器人，而不是始终广播帧。在网状 ZigBee 网络上，您希望尽可能避免广播。
我猜您要么使用“AT 模式”发送原始数据，要么使用 ATAO 设置为 0 的“API 模式”（有时称为“透明串行”）。
如果查看该帧类型 (0x11)，您将看到接收者收到一个 0x91 帧，其中已包含多个字段（源/目标端点、集群、配置文件 ID）。您可以重新调整这些字段的用途，因为您不尝试进行 ZigBee 网络。
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.