Date: Fri, 7 Mar 1997 18:50:16 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: swallace@ece.uci.edu (Steven Wallace) Cc: bde@zeta.org.au, bugs@freebsd.org, current@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: serial driver Message-ID: <199703070820.SAA21309@genesis.atrad.adelaide.edu.au> In-Reply-To: <199703070809.AAA22214@newport.ece.uci.edu> from Steven Wallace at "Mar 7, 97 00:09:45 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Steven Wallace stands accused of saying: > > Okay, by Mike suggestion, here is an example of what happens: > I got out my break box and looked at the levels of the line > > Terminal Device <-----straight 25 pin to COM1-----> FreeBSD BOX > > Pin 2 TD OFF > Pin 3 RD OFF > Pin 4 RTS OFF > Pin 6 DSR OFF > Pin 8 CD OFF > Pin 20 DTR OFF Ok, so you are confusing DTR and DCD. You are complaining that data pending reading on the PC is lost when your peripheral drops DCD. This is normal; you need to use some technique to handshake the end of the data properly. > What I would expect is to receive the data transmitted before DTR was > dropped. According to what Bruce says, data not read by the read() > call is dropped after DTR is dropped in real time. That would appear to be correct. Your device should keep DCD high for some arbitrary period of time after sending the last of its data before dropping DCD. Please use the right terminolgy, you're giving me a headache 8) > Is there any way to get the functionality I desire? I want the cat > program to close / read to fail after all data is read before the DTR > was dropped. Don't you think that makes more sense anyways? I'd > hate to lose data because the load was too high or whatever and > my process was not able to read() it before DTR/carrier was lost. You could write a small reader program that understands the tty calls required to determine carrier state in CLOCAL mode. There is still a race in that you could poll the DCD status as low, read, and get no data because your read occurred before the FIFO timeout generated an interrupt. You can either brute-force around this (with a small sleep after determining that carrier is low before the final read), or you can improve the communications protocol with your peripheral (if possible). > Steven -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703070820.SAA21309>