串口决定论
这看似简单的问题，却很难寻找。我需要通过串行端口与设备连接。如果我的程序（或其他程序）未完成向设备写入命令，如何确保程序的下一次运行可以成功发送命令？
示例：
foo程序运行并开始写入“A_VERY_LONG_COMMAND”- 用户终止程序，但程序仅写入“A_VERY”
- 用户再次运行程序，并重新发送命令。除此之外，设备看到“A_VERYA_VERY_LONG_COMMAND”，这不是我们想要的。
有什么办法可以让这个更加确定吗？由于这样的问题，串行端口编程感觉非常失控。
This seems like a simple question, but it is difficult to search for. I need to interface with a device over the serial port. In the event my program (or another) does not finish writing a command to the device, how do I ensure the next run of the program can successfully send a command?
Example:
- The
fooprogram runs and begins writing "A_VERY_LONG_COMMAND" - The user terminates the program, but the program has only written, "A_VERY"
- The user runs the program again, and the command is resent. Except, the device sees "A_VERYA_VERY_LONG_COMMAND," which isn't what we want.
Is there any way to make this more deterministic? Serial port programming feels very out-of-control due to issues like this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我猜想，如果您调用 write("A_VERY_LONG_COMMAND")，然后用户在字节在线传出时按 Ctrl+C，则驱动程序层应该完成发送完整缓冲区。如果用户在调用过程中中断，驱动程序层可能会忽略整个事情。
以防万一，当您打开新的 COM 端口时，清除该端口总是明智的。
你对设备端有控制权吗？实现超时以使设备忽略未完成或以其他方式损坏的数据包可能是有意义的。
I would guess that if you call
write("A_VERY_LONG_COMMAND"), and then the user hits Ctrl+C while the bytes are going out on the line, the driver layer should finish sending the full buffer. And if the user interrupts in the middle of the call, the driver layer will probably just ignore the whole thing.Just in case, when you open a new COM port, it's always wise to clear the port.
Do you have control over the device end? It might make sense to implement a timeout to make the device ignore unfinished or otherwise corrupt packets.
应该实现嵌入式设备，以便您可以发送中止/清除/中断字符，该字符将转储其命令缓冲区的内容，并在客户端应用程序启动时为您提供一个干净的状态。
否则它应该提供一个软件重置字符，它将重置命令缓冲区和所有状态。
否则，它的设计方式是您可以发送命令终止（可能是换行符等，具体取决于命令协议），并且可能在解析其缓冲区中的部分乱码命令时生成错误，查询/清除错误，然后就可以开始了。
在连接客户端程序时，重复发送一些运行状况/状态/错误查询，直到获得良好的响应，然后才开始发送配置或操作命令，这不是一个坏主意。除非您可以通过查询确定设备处于合适的状态，否则您可能不想采取任何假设并在配置重置（如果可用）后从头开始配置它。
The embedded device should be implemented such that you can either send an abort/clear/break character that will dump the contents of its command buffer and give you a clean slate on your client app startup.
Or else it should provide a software reset character which will reset the command buffer and all state.
Or else it so be designed so that you can send a command termination (perhaps a newline, etc, depending on command protocol) and possibly have an error generated on the parsing of a garbled partial command that was in its buffer, query/clear the error, and then be good to go.
It wouldn't be a bad idea upon connection of your client program to send some health/status/error query repeatedly until you get a sound response, and only then commence sending configuration or operation commands. Unless you can via a query determine that the device was left in a suitable state, you probably want to assume nothing and configure it from scratch, after a configuration reset if available.
所需的方法取决于设备。
+++暂停”。了解设备最初是否旨在支持交互式使用（串行终端）、程序控制或两者兼而有之，可能会很有用。
The required method depends on the device.
ioctl()handles this.+++pause”.It might be useful to know whether the device was originally intended to support interactive use (serial terminal), control by a program, or both.