pyserial not communicating with /dev/ttyUSB0

Bug #543331 reported by billmania
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
pyserial (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I have a LinkUSB dongle. When this device is attached to the notebook, the file /dev/ttyUSB0 is created. If I use minicom to interact with this device, all works correctly.
However, the following does not work correctly:

from serial import *
l = Serial(port='/dev/ttyUSB0', baudrate=9600)
l.write('r')
print l.read(3)

The read() statement should return '\r\nP' but instead never returns.

It seems as if the pyserial methods aren't actually writing to the serial port.

The source package is python-serial

ProblemType: Bug
Architecture: i386
Date: Sun Mar 21 06:08:45 2010
DistroRelease: Ubuntu 9.10
Package: python-serial 2.3-1
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic-pae
SourcePackage: pyserial
Uname: Linux 2.6.31-14-generic-pae i686

Revision history for this message
billmania (maniabill) wrote :
Revision history for this message
billmania (maniabill) wrote :

This condition occurs on a Toshiba Tecra A8, PTA83U-0EQ021. It has BIOS version 3.40 and Firmware Revision 5.20.

The LinkUSB vendor code is 0x0403 and the product code is 0x6001. If I connect this LinkUSB device to a different ubuntu 9.10 notebook, both minicom and pyserial can successfully communicate with it. However, if I connect the LinkUSB device to this Toshiba Tecra A8 notebook, only minicom can communicate with it. pyserial cannot communicate with the LinkUSB device.

Also, if I connect two different USB-to-serial dongles to the Toshiba Tecra A8 notebook and then connect those two dongles with a null modem cable, both minicom and pyserial can communicate across the two dongles and the null modem cable.

Revision history for this message
billmania (maniabill) wrote :
Download full text (5.1 KiB)

Using strace, here are the difference between minicom and python. The test consisted of connecting to the /dev/ttyUSB0 device and then sending several 'r' characters in succession. The device at /dev/ttyUSB0 normally responds to an 'r' character with the three characters 'P\r\n'. minicom will handle this two-way exchange indefinitely. python and pyserial, on the other hand, will only ever read from /dev/ttyUSB0 once. After the second 'r' is sent, the call to read() blocks until the timeout value is reached.

minicom:

9011 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
9011 fcntl64(3, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
9011 fcntl64(3, F_SETFL, O_RDWR) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, TIOCMGET, [TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, TIOCMGET, [TIOCM_CTS]) = 0
9011 ioctl(3, TIOCMSET, [TIOCM_RTS|TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 stat64("/dev/ttyUSB0", {st_mode=S_IFCHR|0660, st_rdev=makedev(188, 0), ...}) = 0
9011 chown32("/dev/ttyUSB0", 1000, 1000) = -1 EPERM (Operation not permitted)
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, TCFLSH, 0x2) = 0
9011 ioctl(3, TIOCMGET, [TIOCM_RTS|TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, TIOCMGET, [TIOCM_RTS|TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 ioctl(3, TIOCMGET, [TIOCM_RTS|TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 write(3, "r", 1) = 1
9011 ioctl(3, TIOCMGET, [TIOCM_RTS|TIOCM_CTS]) = 0
9011 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
9011 read(3, "P"...

Read more...

Revision history for this message
billmania (maniabill) wrote :

I found a way to make pyserial work on the Toshiba Tecra A8:

After instantiating the Serial() object, add a call to setDTR(level = True) and setRTS(level = True)

I only have to do this with the Toshiba notebook, not with my other notebook. I'll let someone sharper than me decide if this is a defect with pyserial, or the underlying Python logic, or if it is instead an "enhancement".

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pyserial (Ubuntu):
status: New → Confirmed
Revision history for this message
Lawrence (lorrin) wrote :

I have a similar issue on Ubuntu. Communicating with a /dev/ttyUSB device works with minicom, but it doesn't with PySerial with the same settings. It works for about 20% of the time, while other times it messes with the data, or it hangs indefinitelly/until timeout.

There doesn't seem to be any development regarding this bug for the past few years.

The solution from billmania didn't work for me, my device requires no flow control whatsoever.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.