Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 May 1999 16:35:16 +0600 (ESD)
From:      Max Gotlib <max@cca.usart.ru>
To:        "Louis A. Mamakos" <louie@TransSys.COM>
Cc:        Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG
Subject:   Re: Serial ports programming 
Message-ID:  <Pine.LNX.3.95.990528160405.6660B-100000@linux.cca.usart.ru>
In-Reply-To: <199905272009.QAA51618@whizzo.transsys.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.990528160405.6660B-100000>