This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Lost support for baud rate of 230400 after minor Cygwin upgrade


Thank you for your response Corinna.

When I did my upgrade to include cron, I just upgraded the "admin" section. I came in
to work on the weekend, and did a full upgrade and everything is back to normal.
I must have got something out of whack with something else by only doing a
partial upgrade?


My reference to a baud rate of 250000 was a mistake, and I apologise for the
consequent confusion, I should have written 256000 bps.

I noted that this 256000 bps rate was included in termios.h and that cfset<io>speed
did not complain to this rate. tcsetattr(), as I recall, may have complained, but I think
I assumed this was because the serial port driver for my USB connected serial
port did not support that rate.


Part of my termios.h file (at the time)
.....
#define B230400  0x01004
#define B256000  0x01005
.......

My USB serial port card can support 9216000 bps, and all power of 2 sub-multiples
to 115200, then the "usual suspects" below that. Is this list a subset of your new list of
supported baudrates? When might I expect (roughly) that this new release might
happen. If I can help in some way, please let me know.


I am very appreciative of the work that you and the others are doing, by the way.

best regards,

David le Comte

[BTW, I was very impressed at how easy it was to get cron up and working -
though I do have a question: /ect/rc does not appear to be automatically
invoked; is that possible?  What is the best way to ensure that cron is
started automatically - maybe add it to the Windows list of Services?]

Corinna Vinschen wrote:
On Feb 16 10:27, David le Comte wrote:
Two days ago, I upgraded my Cygwin to extend my "admin" components so that
I could use cron. When I did this I found that a program I had previously
written to set a baudrate on a serial port to 230400bps is now failing, whereas
before it was OK. Note that using stty -F /dev/comX where X is the
"Comm port number" still works, ie it can still set the baud rate to 230400
(or even 250000).


Here is my C code:
/if ((cfsetispeed(&t,local_rate) != -1) && (cfsetospeed(&t,local_rate) != -1))
{
if (tcsetattr(rtnval,TCSANOW,&t) == -1)
{
rtnval = -1;
fprintf(stderr,"tcsetattr() could not handle the selected baud rate.\n");
}
}
else
{
rtnval = -1;
fprintf(stderr,"cfsetispeed() or cfsetopseed() couldnt handle the selecetd baud rate.\n");
}
}
/Prior to the day before yesterday, the cfsetispeed() and cfsetospeed() and tcsetattr() calls
all worked, now tcsetattr() is returning -1 on any baud rate above 115200.

This is suspect. If stty works but your application doesn't, even though they use basically the same interface...

Up to 1.5.24, the only baudrate supported above B115200 is B230400 btw.

In an earlier posting, it was noted that whilst Windows had informal support for
_any_ baudrate above 115200, Cygwin did not. It was noted that for baudrates
above 115200, Windows XP would pass (via SetCommState()?) the actual
(long) value of the baudrate, to the vendor's driver, which would then either
handle it (or not). This was in contrast to 115200 or lower baud rates, where it
would pass a number "#defined" (In the form SBR_nnnnnn) in an include file.

CBR_nnnn, but they are just defines for the same value, e.g.


#define CBR_9600 9600

so actually there's no difference between using a number and a define.

Now, at the time, I found out by experimentation, and from what I found
in my termios.h file, that Cygwin did support 230400 and 250000 bps.
I decided that, whilst I would have liked to go as high as 9216000 bps,
that I could live with 230400. Now, though, that has been lost.

250000 is not supported and never was. As I wrote above, B115200 and B230400 are supported for now. The next Cygwin version will support baudrates up to 3000000 (7 digits), which includes 256000, but 250000 is not amongst them. It's not a baudrate defined on Linux either.

What you could do is to create a simple, as-short-as-possible,
self-contained testcase in plain C, which builds OOTB and which allows
to reproduce the problem.


Corinna




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]