Serial & reset of the device

[Dan Stromberg]

On Thu, Jul 7, 2011 at 12:34 PM, yorick <yorick.brunet at gmail.com> wrote:

> Hello,
>
> I'm trying to access a hardware board of my company through a serial
> connection using a Python script and the pyserial module.
>
> I use Python 2.7.1 with Ubuntu 11.04 (pyserial is the package python-
> serial with version 2.5.2,
> http://pyserial.sourceforge.net/pyserial_api.html).
>
> The board to which I'm trying to connect works correctly with serial
> as some other guys did some TCL scripts to manage it.
> My problem is that every time I open a new connection, the device is
> reset. I'd like to not have the device reset.<http://mail.python.org/mailman/listinfo/python-list>


A few suggestions:

1) You could try strace'ing the TCL, and then strace'ing the Python, and
comparing - especially if you're comfortable with low-level I/O in C, but
not only.  Hunt for the open() call to the relevant device file, and other
system calls near it.  Even if you aren't that cozy with C, you could try
putting the strace results on a website or ftp server, and posting links to
them here.

2) Check and double check and triple check your line discipline parameters:
bits per second, parity, word size, start/stop bits.

3) It's also possible the cable is bad (or merely inappropriate), especially
if the TCL is accessing such a device over a different cable.  There is no
"one true serial (RS-232) cable standard" - RS-232 is a rather large
collection of ways of doing communications, and they are frequently not
compatible with one another.

4) One of the more likely causes of a reset of a device that is accessed
serially, is sending it a break signal.  There are official ways of sending
a break, and accidental ways.  Sometimes the two boil down to the same thing
behind the scenes, but look very different in the code.  A break signal is a
longish sequence of unframed 0 bits (IE, with no start/stop bits separating
one byte from another).  An accidental way of sending a break, is to set
your bits per second too low, and then sending a 0 byte - because those 8 0
bits at the too-low speed will look like a long series of unframed 0's from
the perspective of the reader process that's running at the correct speed.
So I guess the gist of point #4 (this point), is "make sure your bps is set
correctly" and "check the device doc to see if a break signal causes a
reset"

5) If the protocol layered over the serial communication is ASCII-based, you
could try connecting to the device using something like minicom, to make
sure the device is behaving as expected.  If the device is speaking a binary
protocol, this is unlikely to help much

HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110707/6ee72ab3/attachment-0001.html>