<br><div class="gmail_quote">On Thu, Jul 7, 2011 at 12:34 PM, yorick <span dir="ltr"><<a href="mailto:yorick.brunet@gmail.com">yorick.brunet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello,<br>
<br>
I'm trying to access a hardware board of my company through a serial<br>
connection using a Python script and the pyserial module.<br>
<br>
I use Python 2.7.1 with Ubuntu 11.04 (pyserial is the package python-<br>
serial with version 2.5.2, <a href="http://pyserial.sourceforge.net/pyserial_api.html" target="_blank">http://pyserial.sourceforge.net/pyserial_api.html</a>).<br>
<br>
The board to which I'm trying to connect works correctly with serial<br>
as some other guys did some TCL scripts to manage it.<br>
My problem is that every time I open a new connection, the device is<br>
reset. I'd like to not have the device reset.<font color="#888888"><a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank"></a></font></blockquote><div><br>A few suggestions:<br><br>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.<br>
<br>2) Check and double check and triple check your line discipline parameters: bits per second, parity, word size, start/stop bits.<br><br>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.<br>
<br>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"<br>
<br>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<br>
<br>HTH<br><br></div></div><br>