Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Wed, 18 May 2005 10:28:22 -0400 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Serial programming - Writing bytes in a blocking mode - Problem with tcdrain() ? Message-ID: <20050518142822.GA4502@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i On Wed, May 18, 2005 at 10:10:28AM +0200, pbenito@cemitec.com wrote: >>I wonder if you're just seeing the effects of a buffer on the comm >>device itself not draining even though Windows has flushed everything >>from its own memory. > >I'm not reading any buffer, the idea of my program is the following: Put >the RTS signal low, write some bytes, wait until everything is transmitted >and then raise again the RTS signal... I didn't say you were reading any buffer. Most modern serial devices contain buffers so when you send a byte to a com device it may be stored in a buffer. Cygwin (and Window?) won't know about this buffer. tcdrain() will only report that the byte has left the OS buffer. It won't know if the byte is still sitting in the device's buffer. -- 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/