Date: Tue, 31 Dec 1996 12:30:41 -0900 (AKST) From: hmmm <hmmm@alaska.net> To: freebsd-hackers <hackers@freebsd.org> Subject: Re: Ints (fwd) Message-ID: <Pine.GSO.3.93.961231123017.8358B-100000@calvino.alaska.net>
next in thread | raw e-mail | index | archive | help
------------------------------------------------------------------------------ Sleep: a sign a caffeine deprivation ... http://www.alaska.net/~hmmm ------------------------------------------------------------------------------ ---------- Forwarded message ---------- Received: from CHARLESB (aac-proxy2.mpb.jccbi.gov [162.58.29.160]) by calvino.alaska.net (8.8.0/8.7.3) with SMTP id IAA14915; Tue, 31 Dec 1996 08:48:36 -0900 (AKST) Message-ID: <32C94455.5ACB@admin.tc.faa.gov> Date: Tue, 31 Dec 1996 08:50:29 -0800 From: Charles Bader <Charles_Bader_at_AAL450@admin.tc.faa.gov> Organization: Federal Aviation Administration X-Mailer: Mozilla 2.0 (Win16; U) MIME-Version: 1.0 To: hmmm <hmmm@Alaska.NET>, davidn@sdev.usn.blaze.net.au, trolso_n@motsat.sat.mot.com, tpv@Alaska.NET Subject: Re: Ints References: <Pine.GSO.3.93.961230230326.12094A-100000@calvino.alaska.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Length: 2640 hmmm wrote: > > On Tue, 31 Dec 1996, David Nugent wrote: > > > The problem is that the ISA bus is only a binary (two-state) > > bus. Each IRQ has its own physical "line" which is either high > > or low. If two devices drive the IRQ in opposite directions at > > the same time, there's every chance that the PIC won't see it. > > Interrupts are simply lost, so the cpu never sees it to call > > the associated ISR. > > OK - so it comes down to this - Multiple devices CAN share the same IRQ as > long as one device isn't "activating" an IRQ that another is > "de-activating" at the same time - right? > > and the reason a COM1 RxINT & TxINT is different from a COM1 RxINT & COM2 > RxINT is because the COM1 device in the first instance will generate pull > on the same IRQ line in SEQUENCE - ie - not simultaneously as in the > second case ... - right? :) Wait a second guys.... The interrupt lines on the ISA bus are open-collector, which means that it is possible to OR-TIE them together- remember Digital Electronics Fundamentals? Open-collector is very similar to tri-state, and is used when there is only 1 active state. If an application should require multiple devices to share a bus, and 2 active states are required, then tri-state drivers are required on all outputs. The only state which we are concerned with is ACTIVE (low). The processor doesn't care if an interrupt isn't happening, only when one IS. So a peripheral device does not DRIVE the interrupt line "the other way", it simply de-activates it's open-collector output. If another peripheral device happens to have interrupt asserted, the state of the IRQ line will not change. A problem occurs at the tail end of an ISR, when the IF flag is cleared during the IRET instruction. If another interrupt happens to occur since the time you last checked the peripheral's flag register and prior to issuing an IRET, then the PIC will indeed lose the interrupt. The PIC will clear the first interrupt, and in so doing, will also clear the second, since they share the same line. The best solution is to never use the same interrupt line which will be used by any two devices which will be used at the same time. Barring this, it is important to check the status registers of the 2 peripherals prior to exiting the ISR as well as entering it. Problems of this sort involving communications are very difficult to track down, since the triggering event revolves around 2 separate, unsynchronized events. The probability of the second interrupt occurring during this short time frame is very small, but nevertheless will happen sooner or later.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.93.961231123017.8358B-100000>