Serial port determinism

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:

1. The foo program runs and begins writing "A_VERY_LONG_COMMAND"
2. The user terminates the program, but the program has only written, "A_VERY"
3. 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 o开发者_运维问答ut-of-control due to issues like this.

The required method depends on the device.

• Serial ports have additional control signal lines as well as the serial data line; perhaps one of them will reset the device's input. I've never done serial port programming but I think ioctl() handles this.
• There may be a single byte which will reset, e.g. some control character.
• There might be a timing-based signal, e.g. Hayes command set modems use “pause +++ pause”.
• It might just reset after not receiving a complete command after a fixed time.

It might be useful to know whether the device was originally intended to support interactive use (serial terminal), control by a program, or both.

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.