Is it possible to use python to get True Full Duplex on a Serial port?

[Hendrik van Rooyen]

On Saturday 15 August 2009 04:03:42 Terry Reedy wrote:
> greg wrote:
> > You can't read and write with the same stdio file object
> > at the same time. Odd things tend to happen if you try.
>
> I believe the C standard specifies that the behavior of mixed reads and
> writes is undefined without intervening seek and/or flush, even if the
> seek is ignored (as it is on some Unix systems). With two threads, the
> timing is undetermined.

For a serial port, flush on write makes some sense, but seek is complete 
nonsense because it is undefined, and besides-  the point you try to seek to 
may never come around.  So the message I am getting loud and clear is that 
the basic thing I am doing wrong is to use the ordinary python open() instead 
of os.open().

As for the timing in two threads - Yes you are right, but there is not a lot 
one can do about it - The right solution depends to a large extent on what 
you are doing - for instance, if you are writing a polling protocol (such as 
Burroughs poll-select, or Uniscope), then you want a loop that transmits 
something, and waits for an answer or time out.  This is essentially half 
duplex, and in a high level language the natural structure to write this is 
in one thread.   On the other hand, if you are writing a sliding window type 
protocol that is capable of pouring stuff into a link asynchronously from 
both ends, then the natural way to do it is to use two threads - one to 
handle incoming stuff, and the other to squirt out the data that must go out.  
If, as is true in my case, the source of outgoing data and the sink for 
incoming data is a TCP/IP socket, then one can accomplish this with blocking 
I/O quite efficiently, provided you have a third thread looking after overall 
timing Issues.  For such a case, the timing is essentially determined by the 
flow of the data (provided of course that you can keep up with the link 
speed).   When one introduces another variable into the equation, namely the 
requirement to do a transmission at least every n milliseconds, (a feel-good 
keepalive) then you need a time out on the sources, so that you can either do 
a transmission or raise an alarm because a reporting period was missed.  So 
then you are back at a loop waiting for input or timeout, and doing a 
transmission afterwards.  Only now there are two of them, facing in opposite 
directions. 

I think this sort of thing is better written at a lower level where one has 
access to the interrupts from the ports, as well as a timer interrupt to 
handle timing and timeout issues.  But that is a lot of work, so I make do 
with python.

- Hendrik