X-Spam-Check-By: sourceware.org Date: Fri, 16 Feb 2007 10:22:10 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Lost support for baud rate of 230400 after minor Cygwin upgrade Message-ID: <20070216092210.GK4158@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <45D4EC76 DOT 50404 AT avegasystems DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D4EC76.50404@avegasystems.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/