hugovincent / osx-pl2303 Goto Github PK

• 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

After opening up my USB<->serial line with C-Kermit, I'm able to converse with the device on the other end. After a few minutes, it freezes and I can no longer converse with the device.

If I unplug the USB<->serial cable from the Mac Pro and plug it back in, I can reconnect to my device and communication works normally once again.

This is the USB<->serial cable that I'm using:

http://www.monoprice.com/products/product.asp?c_id=103&cp_id=10311&cs_id=1031104&p_id=3726&seq=1&format=2

I'm running the latest version of your code, cloned from github today, September 22, 2011. I compiled it with Xcode 4.1.

Serial settings to communicate with this device is: 4800 baud 8/N/1, hardware flow control NONE, software flow control NONE

I'm not a software developer but I am an experienced systems administrator and I'm willing to help out in any way that's useful.

Thanks.

The latest kext works okay with my Qualcomm chipset based EVDO modem under 10.6.6, but it fails under 10.7.2 with the following messages. Please help.

Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::allocateResources failed - no fpInterface.
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::start Allocate resources failed
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::CheckSerialState - StartSerial failed
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:02 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:03 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:04 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set
Jan 7 12:41:04 xxxMacBook-Pro kernel[0]: ttyioss12000016: enqueueData rtn (e00002d7)
Jan 7 12:41:04 xxxMacBook-Pro kernel[0]: osx_pl2303(0xffffff800d37e600)::enqueueDataGated fTerminate set

This works fine, but — like failberg's fork — gives me a very strange device special name, complete with non-printing characters. Currently, it's attached on:

/dev/tty.PL2303-12345678Z qRz™�¨�l

That special name contains a newline, which is a bit difficult to use with applications.