From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14531 invoked by alias); 19 Dec 2008 21:23:52 -0000 Received: (qmail 14522 invoked by uid 22791); 19 Dec 2008 21:23:51 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtiwmhc13.worldnet.att.net (HELO mtiwmhc13.worldnet.att.net) (204.127.131.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Dec 2008 21:23:12 +0000 Received: from dfw5rb41 (h-68-164-8-192.chcgilgm.dynamic.covad.net[68.164.8.192]) by worldnet.att.net (mtiwmhc13) with SMTP id <2008121921231011300b0b0de>; Fri, 19 Dec 2008 21:23:10 +0000 From: "Gary R. Van Sickle" To: References: <494BE168.1020600@rettc.com> <494C01A8.8040200@rettc.com> <494C0B68.1040207@rettc.com> Subject: RE: printf goes to serial port? Date: Fri, 19 Dec 2008 21:23:00 -0000 Message-ID: <2D740E5CDF374EC6B5AA2AFD6C8CFBB4@DFW5RB41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <494C0B68.1040207@rettc.com> Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2008-12/txt/msg00497.txt.bz2 > From: Alex Martin > Gary R. Van Sickle wrote: > >> From: Alex Martin > >> > >> Well, I was using a port monitor to debug some of the > traffic between > >> my serial device, and my software, when I noticed the output > >> accidentally. > >> > >> I am not sure when the behavior started. It used to work > fine, I was > >> using printf to debug things, then I turned off all of > those printf > >> statements, and continued development on the gui side (fox > toolkit) > >> of my application, and then had to go in and modify my low level > >> serial class and was trying to get my printf debug output > again, to > >> no avail. > >> > >> I have updated cygwin a few times, otherwise I cannot think of > >> anything specific. > >> > >> What other details can I provide? > >> > > > > Well, whatever details you have. I'm still in "pull mode" > here, which > > isn't conducive to problem-solving. So far I've been able > to gather: > > > > 1. You are developing some sort of app that communicates over a > > serial port to some other device. > > 2. You "have a cygwin environment". > > 3. The app has a GUI, using something called "fox toolkit" (with > > which I am not familiar). > > 4. You had debug printf()s that used to work, then a bunch > of stuff > > changed, and now they work differently. > > > > A few gaps that need filling before anything better than SWAGs can > > come your > > way: > > - Is this app a Cygwin app, > > No, it is a windows app. > > I am using cygwin primarily because I get the /dev/ttyS* > devices. ...ok, so it's a Cygwin app. You won't have /dev/anything otherwise. > I could not find info on how to talk to a serial > port in the windows world without using "MFC" which I refuse to touch. > I... Um, you can most certainly talk to serial ports under Windows without using MFC (is MFC even still around? I thought it was all ".NET" this and "ATL" that nowadays. I must not be getting as old as I thought I was). Search MSDN for... Well, here: http://msdn.microsoft.com/en-us/library/ms810467.aspx > or is Cygwin involved only perhiperally (e.g. > > you're using Cygwin make to run the MinGW toolchain), > > No mingw. Using all of cygwin's make, g++, etc. > Ok, again, that's a Cygwin app. You're linking with the Cygwin DLL. > or is Cygwin not > > directly involved at all and you're saying "My > non-Cygwin-related app > > was working fine, I changed a bunch of stuff in the app and also > > upgraded Cygwin, and now the app is broke and I'm thinking > Cygwin could be to blame"? > > I do not think the app is broken. I never do either, until I find out where I broke it. ;-) > Somehow stdout is going to > the serial port, my code relating to file descriptors (a > serialio class that provides functions like open, close, > read, write, flush), opening and closing the devices, etc has > never changed (that is, the code is the same code since back > when printf worked). Other code has changed, that is, the gui > layout, function flow, etc. > > > - Since your app is a GUI app, where did you expect your > printf()s to go? > > Well, someone taught me to use cygwin in this manner, and I > have been doing so for a long time, that is, I can use a > cygwin window to invoke my windows app, and the cygwin > console would catch printfs (stdout chatter), so you can use > it as a debug console. Hmm, well, maybe you have uncovered a Cygwin bug, or a deliberate change in Cygwin behavior. Next step: Which Cygwin DLL version behaved as above, and which version now is sending that info to the serial port? Make sure to use the same app (which you have assured me is not broken ;-)) when you test this; rule #1 is to change only one thing at a time so you can rule it out without the confounding factors of other things changing on you. -- Gary R. Van Sickle -- 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/