Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is involves cygwin running under Windows XP. I have a genuine serial port (COM1) on this machine.

After booting up, a program I've written gets garbled responses when trying to communicate through the serial port. If I run Hyperterminal and set the "baud" rate, then exit, everything works normally from then onward.

I first attempted to set the speed from the program (using termios calls) and that didn't work. So I decided to try changing the speed using an existing utility. Using a command like stty -F /dev/ttyS0 9600 is accepted, and if I try a different speed I can see the change when I examine it with stty -F /dev/ttyS0. But it has no apparent effect on the actual speed.

I'm finding it hard to imagine that if cygwin couldn't change bit rates that I wouldn't find a statement to that effect in my searching. But I haven't found any such thing.

I suppose it could be some setting other than bits per second that needs to be straightened out. But I don't see anything in the returned report to suggest that. Perhaps I will test that by trying to discover what rate it comes up at.

Edit: I checked with an oscilloscope, and the baud rate (going out, at least), does indeed change to 9600 as I intended. So, I am now going to look at other possible settings that may interfere with the communications.

Solution: One thing that helped greatly was my discovery that a USB virtual serial port would reinitialize itself each time it was unplugged. This removed the necessity for rebooting the host in order to undo whatever HyperTerminal was doing to fix the problem. This way I was able to do many tests in a short time.

The solution came when I found the command stty -F /dev/ttyS0 -a to get all the port parameters. I ran it before and after letting HyperTerminal "fix" the problem, capturing the output to files and then using diff on results. The results: cs7. This is the number of bits in each character. Something initializes serial ports to N-7-1 by default. The solution, then, is as simple as:

stty -F /dev/ttyS0 9600 cs8

Note: The original problem started with termios calls. The same solution can be applied there. But that is a matter to be addressed on Stackoverflow.

share|improve this question
I looked at these settings in Device Manager and it claimed to be at 9600N81. But that's not what I see. So, maybe the setting is coming from a Cygwin library. – gbarry May 16 '13 at 18:36
up vote 0 down vote accepted

Use this command,

stty -F /dev/ttyS0

to get all the port settings. Then see what has changed after the port starts working.

share|improve this answer

You must log in to answer this question.

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