Debugging Python serial I/O errors

[Stephen]

> Having a hell of a time trying to read serial I/O on my
> redhat 7.2 machine, with a variety of methods ~

Doh, what a dork. I forgot the CRLF at the end of each command !


The USPP version works fine now but raises a question of whether
to use blocking comms or not (see below).  PosixSerial also
works sweet.  The f=open("/dev/ttyS1", "rw") still doesn't work
and I'm starting to think that the post I saw that used 
such syntax was perhaps a bit dubious :)

Playing with USPP did raise a question though ~ should one use
blocking comms on a serial port ?  It seems to be the only way
to get fast response, derived as follows ~ 

Let's say you use a timeout of say 1000 ms and read() from the port.

>>> p = uspp.SerialPort("/dev/ttyS1", 1000, 19200) 
>>> p.write("AT\015\012")
>>> p.read()
'\015'
>>> p.read()
'\012'
>>> p.read()
'O'
>>> p.read()
'K'

You get the idea, p.read() is tiresome, getting one char at a time.'
So, let's get several characters at once ? How many ? We don't know
yet, so let's be safe and get 64 chars.

>>> p.write("AT\015\012")
>>> p.read(128)

Bang, it hangs.  

The only way to get around this seems to be to use a timeout of 0 which
denotes blocking. 

>>> p = uspp.SerialPort("/dev/ttyS1", 1000, 19200) 
>>> p.write("AT\015\012")
>>> p.read(128)
'\015\012OK\015\012'

And this is by far the easiest way to interact with the serial port.
>From my previous work with socket servers last month, it seemed that
blocking was frowned upon.  Using a serial RS-232, performance
is never an issue since it's crap period, but if the hardware connected
to the serial port should fail for some reason, I that a blocking
call could be left waiting indefinitely. Is this correct ? 

Anyway, sorry for disturbing you all with such a trivial original
query ~ the error messages I got in response made me think it was
a comms problem.  I'm sure there's an axiom that says you'll always 
spot the bug after posting to the mailing list ! 

Stephen.