Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!van-bc!sl
From: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Newsgroups: comp.sys.ibm.pc
Subject: Re: NS16550 ACE question
Message-ID: <1878@van-bc.UUCP>
Date: 18 Sep 88 07:09:10 GMT
References: <1357@sun.soe> <8045@bigtex.uucp>
Reply-To: sl@van-bc.UUCP (Stuart Lynne)
Organization: Wimsey Associates, Vancouver, BC.
Lines: 56

In article <8045@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
>In article <1357@sun.soe>, nelson@clutx.clarkson.edu wrote:
>
>> According to the documentation, the NS16550 ACE (essentially an 8250 with
>> a FIFO) asserts THRE *only* when the transmit queue is empty.  [...]
>> And it WILL work but only if THRE is asserted as long as there is room in
>> the FIFO.
>
>I can't find my documentation at the moment, but I believe that the
>THRE is asserted when the queue becomes empty, with the implication
>that the shift register is still processing the last byte.  This means
>there is a full character time before the output channel becomes idle.
>-- 

Correct. To quote from the data sheet, section 8.4 Line Status Register
about Bit 5:

	This bit is the Transmitter Holding Register Empty (THRE)
	indicator. Bit 5 indicates that the UART is ready to accept a
	new character for transmission. In addition, this bit causes the 
	UART to issue an interrupt.......

	In FIFO mode this bit is set when the XMIT FIFO is empty; it is
	cleared when at least 1 byte is written to the XMIT FIFO.

Bit 6 is TEMT, or Transmitter Empty register. It is set when the Transmitter
Register (and XMIT FIFO) is empty.

The big problem with the FIFO's on this chip are that you cannot tell how
full they are. In the case of the XMIT FIFO you are told when it is empty. 
You can then place as little (none or one byte) or as much (up to sixteen
bytes) data as you like into it. Unfortunately once in you can only wait for
THRE to be asserted again. You can't stop it sending what's in there already
short of flushing it (but if you flush it, you arn't told how much was sent
and how much was flushed). This means for example if you notice that CTS has
dropped you may still end up sending up to sixteen characters (plus the one
that is already in the transmit register). 

The basic tradeoff is interrupt overhead vs. increased slop in response to
CTS changes. This may or may not be a problem depending on what's at the far
end of the wire. For example Trailblazers don't seem to mind. This could be
fixed by having the next version of the chip implement the RTS/CTS full
duplex flow control itself.

The other problem with this scheme is that some processors (ie slow 286)
can have problems responding to the interrupt and filling the FIFO before
the transmit register actually emptys. This could be fixed with by allowing
you to specify a trigger level for interrupts similiar to the RCVR FIFO.
I.e. allow you to specify that you want to be interrupted when there are
four or two bytes left in the XMIT FIFO.

In any respect if you can live within the limitations of the 16550 it can
reduce interrupt overheads *dramatically*.

-- 
Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532