Not raising DTR

[candlerb]

• Using git HEAD (7cb3a78, Tue Aug 9 2011), OSX Lion on Macbook Air, Xcode 4.1
• Device is a Sitecom CN-116 which identifies as 0x067b/0x2303
• Testing with picocom-1.6 and minicom-2.4 built from Homebrew

When I connect to a USR Courier modem, it's clear that DTR is not being raised. Upon starting picocom the RS (RTS) LED comes on, but not the TR (DTR) LED.The modem echoes AT commands but won't respond, unless I flip DIP switch 1 from "DTR Normal" to "DTR Always On" at which point it works.

Starting minicom I get the same, unless I issue "hang-up line" (meta-H) command; after that DTR is raised.

This could of course be bugs in picocom and minicom (not ported correctly to OSX) rather than the osx PL2303 driver. I tried to recompile the driver with debugging enabled; however when I go into USB Prober > USB Logger, select level 7 and hit Start, I still don't see any messages from the driver. The same is true after unload/load and even a full system reboot. I know I'm doing something wrong here, but I don't know what it is.

From dmesg I just get this:

$ sudo dmesg | grep -i pl2303
Password:
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED
osx_pl2303(0xffffff800d725400)::dequeueDataGated - INTERRUPTED

If I issue the Picocom key to toggle DTR (^A ^T) then nothing happens on DTR but each time it says DTR is up:

*** DTR: up ***

*** DTR: up ***

*** DTR: up ***

If I issue the Picocom key to pulse DTR (^A ^P) then I get

*** pulse DTR ***
*** FAILED

Running picocom under dtruss and typing ^A ^T shows:

ioctl(0x3, 0x40487413, 0x7FFF6EB218A0)       = 0 0
ioctl(0x3, 0x80487414, 0x7FFF6EB218A0)       = -1 Err#22
write(0x1, "\r\n*** DTR: up ***\r\n\0", 0x13)        = 19 0

picocom source shows that for non-Linux systems, to drop DTR it calls tcsetattr after using cfsetospeed and cfsetispeed to B0, and to raise DTR it just tcsetattr's back to the right settings. This looks like something of a frig because there is no more specific API, but in any case I think it is the driver's responsibility to raise DTR when the port is opened: see http://www.steve.org.uk/Reference/Unix/faq_4.html#SEC54

[candlerb]

I found a simple workaround: disable DTR/DSR handshaking in the driver.

diff --git a/osx_pl2303.h b/osx_pl2303.h
index a92d6b2..78f5337 100644
--- a/osx_pl2303.h
+++ b/osx_pl2303.h
@@ -83,7 +83,7 @@
 #define CAN_NOTIFY                             ( PD_RS232_N_MASK )
 #define EXTERNAL_MASK                  ( PD_S_MASK | (PD_RS232_S_MASK & ~PD_RS2
 #define INTERNAL_DELAY                 ( PD_RS232_S_LOOP )
-#define DEFAULT_AUTO                   ( PD_RS232_A_DTR | PD_RS232_A_RFR | PD_RS232_A_CTS | PD_RS232_A_DSR )
+#define DEFAULT_AUTO                   ( PD_RS232_A_RFR | PD_RS232_A_CTS )
 #define DEFAULT_NOTIFY                 0x00
 #define DEFAULT_STATE                  ( PD_S_TX_ENABLE | PD_S_RX_ENABLE | PD_R

In my opinion, using DTR/DSR for handshaking is misguided. This is what RTS and CTS are for. If your incoming buffer fills and you drop DTR, then most modems will drop the call!!

However in any case it seems that it doesn't work properly, because DTR isn't raised in the first place.