nelson@sun.soe (Russ Nelson) (09/14/88)
According to the documentation, the NS16550 ACE (essentially an 8250 with a FIFO) asserts THRE *only* when the transmit queue is empty. This makes no sense to me. If the FIFO is to be transparent, then you would like existing software to continue working. And it WILL work but only if THRE is asserted as long as there is room in the FIFO. Am I reading the spec wrong or is the spec itself wrong? -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Shuzan held out his short staff and said, "If you call this a short staff, you oppose its reality. If you do not call it a short staff, you ignore the facts. Now, what do you wish to call it?"
james@bigtex.uucp (James Van Artsdalen) (09/16/88)
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. You're not considering another important purpose of the 16550A (don't use the 16550!): to lessen the system load. If the 16550A gave an interrupt each time there was a free spot in the queue, you would get an interrupt for each character sent. Instead of this, it generates an interrupt each time the queue is nearly empty, meaning every 16 interrupts. Much less overhead. 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. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (09/18/88)
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