greyham@hades.OZ (Greyham Stoney) (06/15/89)
Hiyall comparchies...... I have a nasty little problem with an 80186 system I'm working on at the moment; basically the problem is to do with missing interrupts. The 80186's built-in interrupt controller is being use to handle interrupts from a variety of sources. Two of them in particular are something of a worry because they are very short, cannot afford to be missed, and may occur at almost exactly the same time. The problem seems to be that the 80186 doesn't latch the interrupts when they occur; so with my two interrupts, if one of them is being serviced when the second comes in, the second gets lost. Some solutions spring to mind: * make the second a higher priority than the first, and re-enable interrupts in the first's service routine. This doesn't work though if they come in in the reverse order (which they might). * make them the same priority and issue an EOI at the start of both interrupt routines. This screws up though if two of the same interrupt come in very close together; which they may well do. * make the hardware latch the things. Ha!. Only kidding!!!! Or is there something I've missed?. Yes, I have as a matter of fact RTFM'd and if you've done so too, you'll know how much help that was. Any help greatly appreciated; EMAIL me direct and I'll summarize to the net. thankyou, Greyham Great.... now I can get back to slandering some Intel RISC based DMA cray 68000 optimisation VAX mainframe front-ends..... -- /* Greyham Stoney: +61 2 428 6476 * greyham@hades.oz - Ausonics, Lane Cove, Oz. <- first preference * greyham@utscsd.oz - Uni of Technology, Sydney. <- if hades bounces */ Zero Knowledge: Now THERE'S a concept I can identify with!!!
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (06/28/89)
Electronic mail fail so posting: In article <258@hades.OZ> you write: > > I have a nasty little problem with an 80186 system I'm working on at >the moment; basically the problem is to do with missing interrupts. The Conceptually, either somebody knocks on your door (interrupt) or you knock on theirs (polling). I don't see any other option (but will be happy to be proven wrong). If you can go out and read some sort of register, memory location whatever which is set by the interrupting device you're off the hook. The flag which is set means "Hey, I generated an interrupt and want to be serviced". What you then do is in the interrupt routine (you really only need one) poll each of the flags. Atomic test and clear the flag (if you can) and carry out any required actions. This method is robust against (occasional) lost interrupts and double interrupts for the same service request or interrupts coming in at different levels. > > Or is there something I've missed?. Not really except perhaps an occasional interrupt :-) On the other hand if you can't do the above then you can forget about getting... > > back to slandering some Intel RISC > based DMA cray 68000 optimisation VAX mainframe front-ends..... Cause then you've got real problems :-) -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof