EOS serial port interrupts

The ICU in the 486s operates by receiving edges (the transition from inactive to active state) in the interrupt signal from the various devices. For the clock, this doesn't cause any particular problem, since its signal only goes active for a microsecond or so, but it is not the same case with the USARTs.

Transmitting alone is unlikely to cause problems, since these interrupts are spaced about 1 ms apart so you should have plenty of time to service one before the next one comes along, and the ICU will properly catch the next edge. However, if you have both transmit and receive interrupts going at the same time, then there is a possibility that a new receive signal could come along just as you are in the middle of servicing the current transmit (or vice versa). This situation will make it so that the interrupt signal from the USART stays active after you have finished the original interrupt and after you do whatever to re-enable the original interrupt in the ICU. What should happen in this case is that the ICU should go into another interrupt immediately, but it won't, since there is no edge to trigger it.

What you need to do is to generate an edge for the ICU to insure that this situation is handled properly. You do this right after re-enabling the USART interrupt by reading the value that is in the Interrupt Enable Register (IER) (or by remembering what is supposed to be there), writing a 0x00 into the IER (to clear the interrupt signal), and then writing back the value that was originally in the IER (to re-assert the interrupt signal, if there was one). This will cause the edge in the signal that the ICU needs to initiate another interrupt if need be.

A disadvantage to doing this is that you cannot use the feature about not having to disable transmit interrupts if you read the Interrupt Identification Register (IIR). The advantage, of course, is that your system won't randomly lock up on you (from this cause, anyway). You'll have to enable transmit interrupts when you need them and disable them when you don't. (One note: there's no race condition here if your priorities are set right).

Processing a pending interrupt while servicing another causes no harm (if done right), but it isn't necessary. There is no latency problem, since Rx and Tx interrupts can only happen at, say, 960 times/second each and they DON'T CLOBBER each other. There is no problem with them happening simultaneously if you only process one at a time, since the other will happen immediately after you finish processing the current one and can be handled in the usual way (if you follow my directions about accounting for edge-triggered interrupts posted earlier to this newsgroup).