Friday, March 13, 2009

/dev/cu vs /dev/tty ( osx serial ports)

A while ago someone told me to use /dev/cu.usbserial rather than /dev/tty.usbserial as the former did not require hardware handshaking. I was looking for this justification again as my memory had gone a little hazey on the exact reason for using cu over tty. I found the following at http://lists.berlios.de/pipermail/gpsd-dev/2005-April/001288.html. Thought it a good thing to know and thought I'd remember it here for next time.

"The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn't have a carrier). During this, the callout device (typically /dev/cu* -- cu stands for "calling unit") can be freely used. Opening /dev/cu* doesn't require DCD to be asserted and
succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again.

That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions."


So this is what I use when programming with AVRDude as the butterfly doesn't have any DCD/DTR lines to assert. Its just TX, RX, and GND. If you have problems on the mac using a tty serial port you should try its cu equivalent.

1 Comments:

At 7:10 pm, Blogger Jack Ansi said...

I too was looking for more info and found this:

For those that are interested.

Serial ports are commonly misunderstood. Having been involved with them for a while I thought I clear up some of the confusion (to that end I'm cross posting this to darwin dev from the usb list thread).

The two ports are actually named after their traditional usage. A tty.* port was intended to run getty on a directly connected terminal, a terminal that, if wired correctly, asserts DTR (one of the RS232 signals). A getty process using a tty.* serial connection would block in open until the TTY asserted DTR (that is the terminal was switched on).

The cu (call unix) port was used mostly by the uucp family of unix communication tools, that is the unix email system used before the advent of the internet. To cause a typical modem to dial, it was necessary to open the port without waiting for DTR, which is typically only asserted one a connection has been established after dialing. WIth an open port uucp could then issue an AT command and wait for a connection with the other side. With an established connection the modem asserts DTR, from that point on the cu and tty ports are exactly the same. Note with many modems the DTR signal often tracks DCD (carrier detect).

With either port type once a raised DTR signal is dropped the port is disconnected and will start returning EIO errors. This is basically a hint to the client process that things have come to an end and need to terminate all processes in the process group connected to the terminal port.

One problem with this basic design is that sometimes tty or other serial devices are connected using only 3-wires, that is ground, txdata, rxdata. In this case the standard tty port will not open. You have two options in this circumstance. The more difficult option is to loopback the DSR to the DTR on the computer side of the rs232 plug, or alternatively you can open the port with O_NONBLOCK then use tcsetattr to set the CLOCAL flag indicating that DTR should be ignore.

Finally although this is the canonical interface the only serial drivers that I know implement the full RS232 signal protocol are Apple's 16x50 drivers. I'm not sure how much of this signalling is implemented by any other driver, so your milage will vary. In retrospect it perhaps would have been a good idea to document this somewhere ;-).


on http://lists.apple.com/archives/usb/2009/Nov/msg00039.html

I thought I'd leave this here as I found your page first in the google search I did.

 

Post a Comment

<< Home