Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!munnari.oz.au!csource!david
From: david@csource.oz.au (david nugent)
Newsgroups: comp.os.msdos.programmer
Subject: Re: U8250 Questions
Message-ID: <794@csource.oz.au>
Date: 15 Jan 91 14:31:38 GMT
References: <2535@sparko.gwu.edu>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 103


In <2535@sparko.gwu.edu> viraf@seas.gwu.edu (Viraf Bankwalla) writes:

>   The Interrupt Identification Register indicates if an 
>   interrupt is pending, and which one it is.  The interrupts
>   are assigned priorities, the higest one being serviced first.

> 	   PRIORITY        Interrupt ID
> 	   --------        -------------------------------
> 		  1            Receive Line Status
> 		  2            Receive Data Available
> 		  3            Transmit Holding Register Empty
> 		  4            Modem Status Changed

>   Say I'm in my isr, processing Receive Data Available,
>   and the modem status changes, am I interrupted, or
>   will I notice the change the next time I poll the
>   IIR in the loop, as I havn't issued the End Of Interrupt ?


Hmm, since you mention the 8250 you touch on a sort point.

There's a bug in the 8250 relating to interrupt priorities. Specifically,
if you are servicing an RLSI or RDAI, you can loose both THRE and
MSI interrupts during their service since they won't be flagged in 
the IIR (bit 0).

But to answer your questions...

No, you aren't interrupted.  At least not if you've kept interrupts 
disabled and not rearmed the PIC.  Until and unless you do both, you 
won't, but as I've said, you'll often miss the interrupt anyway, since 
the UART is buggy.  The result is loosing track of whether the 
transmitter is ready to fire again and often results in a "stuck 
transmitter".

I used to read the line status register and specifically test for the
transmit holding register empty bit, but experience turned out to
be a good teacher - that lies too. :-(  It won't indicate that it's
empty unless the UART has seen the interrupt as well.

So, the solution is:

	rearm the PIC prior reading the IID (and before each time 
		it is read, but DON'T enable interrupts)

	Toggle the THE/MSI bit in the interrupt enable register on 
	  the UART before servicing either an RDAI or RLSI

Actually, I found turning OFF the THR on the interrupt enable register
when the transmitter wasn't active helped a great deal.  You keep a 
static flag when it's idle, and enable it as soon as you have anything
to send.  As soon as you re-enable it, the UART will generate an interrupt
and you have your transmitter auto-firing instead of having to manually
send the first character to kick off transmitter interrupts.  All
in all a better, more robust approach and you end up having all UART I/O
isolated inside the ISR where it should be anyway.

One other warning if you're using this approach.  Don't enable transmit
interrupts if they are already enabled on the INS8250B (the National
Semiconductor one).  It doesn't seem to register that the THRE state
should be low for some time after you actually place a character in the
holding register for transmission.  As a result, there's a time period
in between in which this could possibly trigger another interrupt,
resulting in transmitter overflow and, of course, loss of characters
in transmission.  Also, the line status register can't be trusted during
this period since it suffers the same fate (not correctly reflecting the
transmitter's real state).

Also, don't expect this to work with the 82450C.  It doesn't (the UART
that is :-)).  But that particular UART has more bugs than I cared to
investigate, so I completely dropped supporting it quite some time ago.

The end result of that is that it's very difficult to build a driver which
both allows for this bug in the UART and is somewhat tolerant of some
interrupt latency in the environment which might occasionally cause loss
of interrupts. I'm still attempting to find a simple and elegant workaround 
to this problem that I'm completely comfortable with.


>   I've also noticed, that on turning the modem OFF, the DCD,
>   and other bits in the Modem Status Register get set, resulting
>   in me returning a false result.

That's simply the modem.  The powerdown does this on many of them.


>   Assuming that DCD always reflects the true state of the
>   carrier, how could I avoid the above problem ?

Not a real problem since you'll find DCD will almost immediately (well,
I guess 'immediately' in terms of an ISR is a long time...) drop again.


>   Any help, and references would be greatly appreciated.

Hope this helps.  The above is the result of a long long battle with
these damned UART thingies over around 3 years off and on. :-)


Regards,

  david