How do I know a program exited, from serial console perspective

I have a program that communicates via serial port to the target. The target is likely a shell or similar program. In case I want to send several commands to the target, how can I know a command is end so that I can send the next command?

I have had some ideas, like catch the shell prompt or let the command output some text before exits. But these will increase开发者_开发知识库 the complexity. I'd like to know if there are some other simpler method to achieve it.

It would be impossible to know if a command ended without information going back to the agent issuing the commands with some sort of completion indication. Consider how a *nix terminal works. The *nix terminal was developed exactly for the same kind of situation -- issuing remote commands to another PC over some sort of pipe. In that case, how does the user know she can type another command? In the default case, it lets you know its done by giving you a prompt to issue another command. In an edge case it lets you have the process fork from the shell, in which you get an indication that the job has completed.

It seems the simplest solution is to echo something along the lines of "<< cmd >> complete".

Some basic psuedocode

 for (command in commands)
 {
     IssueCommand(command);
     result = "";
     while (result != "complete")
     {
         // read serial port append to result
         result += read(serialPort);
     }
 }

If you are sending commands to a shell program that returns a prompt, say "$" after you send a command, than you certainly could wait until you see the "$" before sending the next command. This is very rudimentary protocol but should work just fine.

To avoid having to worry about "$" being in the echoed data from the console turn echo off on the console or change the prompt to something unlikely to be in the echoed data.

Technically you could make use of the console input buffer (typeahead) by sending a batch of commands with a length less than the input buffer (you would have to test this) like cmd1[cr]cmd2[cr]cmd3[cr] but then don't send any more untill you get back [cr]$[cr]$[cr]$. The [cr] may need to be [cr][lf] and "$" may actually be "$ " depending on how the console works.

With XONN/XOFF turned on you could technically check for XOFF to stop sending and then resume when you see the XONN but I would not recommend this if you are sending to a command console. You would need to make sure the XONN/XOFF buffer matched the console input buffer and that would be more complicated indeed.

One approach you can use is emitting some sort of marker, such as EOF byte. Check all incoming bytes to see if they're EOF bytes. You could pick some other byte too.