#20 setTimeout() changes value of DTR

[Tetsujin]

I am using pyserial to interface with a circuit in
which the DTR line is used to reset the circuit. In
one version of the circuit, the circuit operates when
DTR is low, and is reset when DTR is high. When I make
certain calls to Serial.setTimeout(), however, the DTR
state is reset to high, meaning my circuit has been
turned off.

This is on a PC Linux system using pyserial version 2.1
on Debian (python-serial 2.1-1). The circuit is a
kitsrus PIC programmer, interfaced over USB using the
FTDI 232BM chip.

[Michael Grollman]

Logged In: YES
user_id=549056
Originator: NO

I am experiencing a similar issue with pyserial version 2.2 running on an x86 Linux Debian Sarge system, 2.6.15, using python 2.4. I am trying to use pyserial to communicate with an ARM device (Coridum Corp ARMite module) also interfaced over USB using the FTDI 232BM chip The setDTR(0) does not appear to work, and DTR must be low to get the embedded device to run. I cannot get DTR to go low if pyserial reading the port. I can solve this OK in TCL with the command "fconfigure $serial -mode "19200,n,8,1" -handshake xonxoff -translation auto -blocking 0 -buffering none -ttycontrol {RTS 0 DTR 0}" so I am confident the communication between the USB device and the Linux system is operational, but it seems I cannot simultaneously read data from the port and hold DTR low with pyserial 2.2. Is this a bug, a feature, or a mess up by me, I am not sure, but since someone else hit something like it at one point, I am asking the question.

[Bob Stein]

I also ran into this annoying bug with pyserial 2.7 on Windows 7, 64-bit. Using pyserial to communicate over a USB CDC connection with an Arduino Due using AtmelStudio.

serial.timeout = serial.timeout

Setting of the timeout property causes a rising edge or some kind of set event for the simulated DTR signal. This triggers the UDI_CDC_SET_DTR_EXT event in the Arduino.

Oddly, instantiation of the serial object, passing a timeout value to __init__(), does not do this. So destroying and creating the entire object has less effect than changing the timeout property.

[Chris Liechti]

I think this is a different issue as the one described under Linux. The Windows supplied CDC driver seems to be buggy since years (and it looks like the vendor does not care). I've also noticed that calls setDTR() do not have immediate effect (as it would have on any other COM port driver), the change of the DTR state is only transferred to the device when some other setting on the port is also changed...

https://www.google.com/search?q=usbser.sys+dtr+issues

if you do not use the RTS or DTR line for your own purposes, enabling hardware flow control may change the behavior of the driver. maybe..