0

-late 2013 MBP, with Yosemite 10.10.2 While using a USB --> Serial cable(FTDI chipset), I am unable to get a set baud-rate and get it to stick while the device is not being open/wrote/read. For example:

If I execute, "stty -f /dev/cu.xxxxxxxx 19200" while not doing anything software related with it, it will reset the baud back to 9600 instantly after.

However, if I run "cat -u < /dev/cu.xxxxxxxx" and THEN set the baud to 19200 while the cat is running, the baud rate will stick. This is also the case when I write some test code and execute the C system command open("/dev/cu.xxxxxxxx") and freeze the program.

Under the old BSD roots, this seems to be standard behavior. When I attempt this on a Debian box, the baud-rate sticks. This hints to me that it's system dependent, but is there a way to get the baud-rate to be the default/stick forever?

  • The stty -f is for Open and use...so if nothing is open it will default to standard. – Ruskes Mar 19 '15 at 17:36
  • Well yes, I noticed that too under the stty man page for OS X, but the Debian stty man page indicates the same exact thing too. If OS X wants to use default settings when using the -f flag, is there a location where the defaults can be set per device? I would hate to have to run C system() commands in order to easily set this. – user3022479 Mar 19 '15 at 22:13
1

For anyone who may later stumble upon this, I was not able to find any trick to help keep a set baud-rate "stick" using stty -f /dev/cu.xxxxxxxx 19200. I ended up writing a simple little C program that would open() and sleep() indefinitely while I performed any other bash magic, which effectively emulated what I originally wanted.

1

For anyone who stumble upon this (yes, another...), here a shell solution (Bash at least):

The 'trick' is to open a file descriptor for the serial port before using stty. And keeps it open during all the reading/writing.

Example:

exec 3<>/dev/cu.xxxxxxxx           # open a file descriptor
stty -f /dev/cu.xxxxxxxx raw 19200 # configure the serial port
cat /dev/cu.xxxxxxxx               # do stuff...
exec 3<&-                          # close the file descriptor

Thanks to @crasysim for his comment on the same question.

0

I was having a similar issue and the answer you posted got me thinking about whether there was a way to run stty and then another command before stty exited. This is essentially what piping does albeit with the stdin and stdout linked together which is irrelevant in this instance.

From my experimentation, the following will allow you to change the cu config and then access it with those settings.

stty -f /dev/cu.xxxxxxxx 115200|cat /dev/cu.xxxxxxxx

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .