From owner-freebsd-hackers Fri May 28 5:16:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from linux.cca.usart.ru (linux.cca.usart.ru [194.226.230.161]) by hub.freebsd.org (Postfix) with ESMTP id 2BFA314CCB for ; Fri, 28 May 1999 05:16:02 -0700 (PDT) (envelope-from max@cca.usart.ru) Received: from localhost (max@localhost) by linux.cca.usart.ru (8.9.1/8.9.1) with SMTP id QAA06844; Fri, 28 May 1999 16:35:20 +0600 Date: Fri, 28 May 1999 16:35:16 +0600 (ESD) From: Max Gotlib To: "Louis A. Mamakos" Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Serial ports programming In-Reply-To: <199905272009.QAA51618@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 May 1999, Louis A. Mamakos wrote: > > > Hi! > > > > > > Some days ago I've faced with the following problem: > > > I need some kind of action (while coding user space > > > program actively handling the serial port) to get > > > sure all the bytes I've wrote to it are _transmitted_. > > > I know about "ioctl(fd, TIOCDRAIN)", but this ioctl > > > is accomplished with tty buffers draining to (probably) > > > FIFO buffer of the serial port. Is there any (portable > > > preferably) way to get an acknolege or to block until > > > FIFO buffer is cleared? The situation is that I can't > > > simply write additional 64 bytes (I did not see any > > > serial ports with FIFO larger than 64 bytes) and > > > drain the tty buffers - I have to catch the exact > > > moment ... > > > > You could close the device, but that may have an adverse effect on your > > application, as it will drop DTR. > > > > There is no other way, no. > > Generally speaking, when you have this type of concern regarding > communications between two devices, you have to rely on the remote device > to acknowledge the data. Even if you knew all the bits left the > UART in your serial port, the data could have been damaged along the way, > or might simply be queued up inside of an error-corrected modem that's > trying to deliver the data to the remote end. Yes, ut sounds resonable while speaking in "general" :) But the situation I'm digged in is the following: I have to handle some kinda radiomodem (DataRadio T96S, just the same the mars-walker was equipped with :). This modem really differs in interface from the "ordinary" RS-232 functionality. First it treats DTR being asserted as the command to switch to setup mode (that is known only to it's designers). Second, it uses RTS/CTS handshake to control it's transmitter, i.e. when RTS is asserted the tranmitter turns on and after some "heating" (marked with CTS assertion) modem is ready to be feeded with data. Then, after the data packet (we use short frames: 16-bytes length) is feeded, the RTS should be resetted to turn the transmitter off. On that stratum modem guarantees the last byte will be transmitted "uncuted" (so it is legal to reset RTS while the last byte is feeded). Because modem works in simplex mode only, the RTS line should be reseted as early as it is possible to "free the band". Looking throug the /sys/isa/sio.c and /sys/kern/tty* staff, I got an idea that: 1. it is impossible to be woken up on CTS dribble, more it is impossible to use current implementation of RTS/CTS flow control to follow such an ugly modem requirements; 2. it is impossible to be noted when the UART's FIFO is feeded to the wire; So, as far as I can imagine I have a choice between handling the interface "by hand" and writing my own sio driver. The second is not acceptable because I'd like to left some scope of portablity to my software. The first approach leeds to high CPU load values and a number of "tricks" while trying to produce time delays (for example, when I try to sleep for 5000 usec in non-realtime userspace process, usually I'm being woken up at the beginning of the next time-tick my process is granted with...). So the question was: are the things so bad as it seems to me ? I know that FreeBSD (as many other UNIX clones) is general-perpouse OS and is not designed for such situations, BUT i thought it's flexible enough to be "shrinked"... With best regards, Max. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message