Mail Archives: cygwin/2007/02/18/17:13:34
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/
- Raw text -