Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request
From: LordBah@cup.portal.com
Newsgroups: comp.sys.sun
Subject: SunOS 4.0.3 and TIOCOUTQ
Keywords: SunOS
Message-ID: <4001@brazos.Rice.edu>
Date: 28 Dec 89 14:05:31 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 51
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 228, message 13 of 18

We're having a problem with the TIOCOUTQ ioctl call [see termio(4)].  This
call is supposed to tell how many bytes are waiting to be output to the
TTY.  Under 3.5 it appeared to work fine, but under 4.0.3 it returns zero
(meaning "everything you requested to be written has been sent") too
early.

There is a device on the other end of the serial cable which requires that
a "packet" be delimited by toggling the RTS line.  The example code below
is intended to drop RTS, send the packet, wait for the last byte to be
actually sent out the serial port, and then raise RTS.  What the device
sees, and what a protocol analyzer sees, is that RTS is raised *before*
the last byte is transferred.

QUESTION: Has anyone else seen this?  If so, how did you get around it?

Additional note: We see the return from TIOCOUTQ (as saved in the
"leftover" array below) drop by 2K at a time.  Is this a magic number
within the TTY driver or streams or something?

----------- begin example code -----------------------

#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>

static char junk[9999]="asdlfjk";

main()
{
int fd = open("/dev/ttyb",O_RDWR);
int leftover[9999],i = 0, num, rc;
int lines;

ioctl(fd,TIOCMGET,&lines);
lines |= TIOCM_RTS;
ioctl(fd,TIOCMSET,&lines);
write(fd,junk,5000);
do {
	rc = ioctl( fd, TIOCOUTQ, &leftover[i] );
   } while ( rc >= 0 && leftover[i++] > 0 );
lines &= ~TIOCM_RTS;
ioctl(fd,TIOCMSET,&lines);
num = i;

for(i=0;i<num;i++)
	printf("%d\n",leftover[i]);
}

------------ end example code -----------------------

Jeff Van Epps	lordbah@cup.portal.com OR rochester!kodak!bisco!jeffv