Lost support for baud rate of 230400 after minor Cygwin upgrade

[David le Comte]

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/