I think what @ShapeShifter has been suggesting is to write some code so that STDIN and STDOUT for my Python program piggy-back on top of the connection to ATH0 established in the startup process.
No, that's not quite it. But first:
But if I were to do that I believe I would lose the ability to have two streams of communication.
Correct, you would lose that second communications stream. But in most cases, that second stream wouldn't be there in the first place. You are manually launching the command from the SSH command line, so STDIN/STDOUT/STDERR for the process are connected to the SSH session. But once you get past the development stage, are you still going to be manually launching that process through the command line? Probably not, you're likely to use an automated method like rc.local to launch it so it starts whenever the system is booted. Once you do that, STDIN/STDOUT/STDERR are not going to be connected to anything useful. Or perhaps you will have the sketch launch it (discussed below) in which case STDIN/STDOUT/STDERR will already be automatically connected to ATH0.
Which brings us back to the original point, piggy-back STDIN/STDOUT on top of the ATH0 connection: what I was saying is that if you write your process to use STDIN/STDOUT as the main I/O channel, for example, by sending all your output through Python print statements, it will automatically be connected to the right communications stream in most cases, and can be manually connected in the more unusual cases.
In the standard configuration, what's happening is that Linux is running a command interpreter on ATH0. When the sketch starts the Bridge, it is literally typing a command to the command interpreter to run Python and execute the Python code to handle Bridge communications. In this case, the STDIN/STDOUT of the process is connected to ATH0. Nothing special is needed to open that serial port connection.
Now, if the sketch then launches another process using the Process class, that request is sent to the Python side of the Bridge code, a process is spawned, and the STDIN/STDOUT of that process is connected to a net socket, the other end of which is connected to the Process object in the sketch. Anything that the spawned process sends to STDOUT is available to be read from the Process object in the sketch, and anything written to the process object in the sketch is available to the spawned process by reading STDIN.
Now, say you don't want to use the bridge. If you don't disable the command processor on the Linux side, the sketch can start your Linux side process by sending a command to start the process through the serial port. You would send the exact same sequence of characters that you would type on the SSH command line. By sending those characters out Serial1, you are literally typing that command out on the command interpreter connected to ATH0, and the process will be started in exactly the same way. The difference is that once running, STDIN/STDOUT of the process will automatically be connected to ATH0 and any writes to STDOUT will be available by reading Serial1, and anything written to Serial1 will be available to the process by reading STDIN.
The key to it all is that here are three different scenarios that communicate under three different connections, with absolutely no change to the code of the process. In each case, the process simply reads from STDIN and writes to STDOUT:
- Process: communicates with the sketch through a Process object when it is launched by the Process object using the Bridge.
- Serial: communicates with the sketch over ATH0 when it is launched by the sketch writing the name of the process to Serial1.
- SSH: communicates with you over the SSH connection when it is launched by you typing the name of the process on the SSH connection.
That's just three examples. In reality, the process can communicate over any stream by redirecting STDIN/STDOUT to that stream. But in most cases, you don't have to do that manually, it is automatically done by the system (like in the examples above.)
Just as the Linux process can handle a variety of communications methods without change by using the abstraction of STDIN/STDOUT, the sketch could also use a variety of communications methods by being written to use the underlying Stream object from which the hardware serial, software serial, Process, network client, and other communications classes are derived. We talked about that in the other thread.
Now, you express the desire to have two communications streams: ATH0 and the SSH shell. That throws a wrench into the equation. I assume that you are using the SSH connection for debug messages? If they are output only, that could possibly be handled by writing to STDERR, and having STDERR connected to the SSH session. That way, STDIN/STDOUT would go to the sketch (using whatever communications method) and STDERR would go to the SSH session. You could accomplish this by using redirection operators in the command line that launches the process, so that STDIN and STDOUT go to /dev/ttyATH0, while leaving STDERR alone so it stays with the SSH connection.
What are you doing with the SSH stream connection (which is currently connected to STDIN/STDOUT)? Maybe there is a better (or at least more generic) way to handle it?
Yes, it does add a little more complexity to the way of thinking, and in some cases might involve a little extra code. In that way, it may not be appropriate for something targeted at rank beginners (as we mentioned in that other thread.) But it does provide a very powerful and generic way of handling I/O, one which is a standard programming model (for good reason!) and one which opens up a wide range of possibilities with no additional coding.
And a final unrelated comment:
The only (?) linkage between Linux and Arduino is via ATH0 on the Linux side and Serial1 on the Arduino side.
That's the normal connection, but not the only one. There is also a handshaking line between D7 on the Arduino side, and GPIO22 on the Linux side. This is normally disabled (high impeadence on both sides) but can be enabled in code.
There is also an SPI connection between the two processors. This is also disabled by default, but could also be used (and is used when loading sketches over the network.)