From: brennan@merk.com (Rich Brennan)
Subject: Re: Com Fix on HP95LX
Summary: Some corrections and other workarounds
Keywords: HP95LX COM UART
Organization: Technology Partners, Inc.
Date: Thu, 08 Oct 1992 07:56:10 GMT

In article <1992Oct6.132704.27946@netcom.com> smuegge@netcom.com (Shad Muegge) writes:
>1) If the THRE interrupt is continuously enabled (in the IER), the
>   95LX will hang as soon as the first interrupt occurs following
>   transmission of a character.  Even if the interrupt is not
>   continuously enabled, transmitted characters may be lost due to
>   false THRE indications in the IIR.

Unless there were some later Hopper changes, this isn't true. The built in
com driver leaves transmit interrupts enabled nearly all the time, and
interrupts arrive fine. The IIR bits can mislead you and fail to indicate a
transmit interrupt is pending, though. I can't remember what caused this,
but bidirectional UART traffic involving lots 'o interrupts seemed to cause
the problem to occur more often.

>2) Received characters may be duplicated when using the data
>   available interrupt, especially at slow data rates (<2400).  This
>   is also due to false indications in the IIR.

Tis true. This IIR is not your friend, except in one case (see below). Also
note that on slow lines you can get two, two, two interrupts for one. For
example, you can get a parity error interrupt as the UART receives the
(incorrect) parity bit for a character, and then you can receive the
"receive data ready" interrupt when the stop bit is received. Above 1200?
or 2400? bps this isn't a problem since the parity and stop bits arrive
quickly enough that you'll likely see one interrupt.

>One More Problem
>----------------
> 
>There is an additional problem involving the 95LX serial port.  At
>the time of this writing, the cause is not known (whether hardware
>or software):
> 
>If an external program that uses the THRE interrupt is run while
>FILER is open, the serial port will be unusable by internal
>applications (FILER, COMM) after the program exits.

The built in com driver assumes (yes, I know the old adage....) that the
any DOS apps will be nice, and re-enable the transmitter interrupts. If they
don't, I believe this cause the above problem.



Ahem. My Workarounds. Ahem. That is to say, the Workarounds that are mine.

by

Ann Engineer [Miss]
-------------------

As previously stated, the IIR is not your friend, and should not be trusted
*except* in one case. If it says an interrupt is outstanding, then there is,
or will be (shortly). The built in com driver doesn't use the IIR bits to
vector to the proper handler, because transmit interrupts can get lost
trusting this lying, scumy register. Ptoooey on this register.

To get around this problem, use a combination of the IIR's valid "there's an
interrupt pending" status (i.e. the LSB of the IIR register is 0), and your
friend, the line status register (LSR) to figure out what to do. When you
take an interrupt, scan your buddy the LSR for work. I use the same
priority that the 8250 does (since it makes perfect sense anyway):
received character error, received data available, transmit holding
register empty, and finally modem status (ignored: ain't no modem pins),
and process interrupts in that order.

Note that since you will be getting THRE indications from the LSR even though
you may not be transmitting, keep a software "transmit interrupt enabled"
flag around, or monitor the state of the transmit interrupt enable bit in the
IER. Use this status to conditions whether the THRE bit should be processed
during the interrupt service routine. If the flag or IER bit isn't set,
ignore THRE.

When you are done with a pass through the LSR, go take a look at the IIR
again. If it says an interrupt is still outstanding, *don't* rely on
receiving another interrupt, it may not arrive (the missing THRE interrupt
problem). Simply make another pass through the LSR scanning function again,
and keep doing so until the IIR says no interrupt is pending. At this point
it is safe to trust that the UART will interrupt again when it has traffic,
so you may exit your "interrupt service" routine.

To get rid of the double interrupt (parity error interrupt followed by a
receive data ready interrupt for the same character): if you get a parity
error, simply loop until the LSR also asserts RDR, and you're all set.



Rich
-- 
brennan@merk.com	...!uunet!merk!brennan		Rich Brennan
Newsgroups: comp.sys.m88k