Is it possible to use python to get True Full Duplex on a Serial port?
Hendrik van Rooyen
hendrik at microcorp.co.za
Sat Aug 15 06:29:28 EDT 2009
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
More information about the Python-list
mailing list