Date: Thu, 2 Jan 1997 22:04:02 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: hmmm@alaska.net Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Ints Message-ID: <199701021134.WAA16141@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.GSO.3.93.970102010408.6300A-100000@calvino.alaska.net> from hmmm at "Jan 2, 97 01:31:43 am"
next in thread | previous in thread | raw e-mail | index | archive | help
hmmm stands accused of saying: > On Thu, 2 Jan 1997, Michael Smith wrote: > > > If you're operating in a polled environment, you're not using an IRQ. > > if you POLL a device for a response received via interrupts, then you ARE > polling ... :) Please don't go inventing your own terminology in order to prove yourself "right". If you are responding to an interrupt, you are not "polling" as such. > > The highest pending interrupt status is presented in the IIR. If you > > perform an action that clears an interrupt status, the IIR may change. > > MAY change - or DOES change ? is it usually a circuit outside of CPU > concerns? do INT status flags change EXACTLY as the condition is removed? "may" change. If you really want the low-down on how much UART implementations vary, search the FreeBSD mailing list archives for mention of a program called COMTEST in a message from Frank Durda. Basically, there is very little that you can actually count on. > isn't the signal removed after the PIC responds to the device ? > ... so that the IRQ line is now "free" again - and may be interrupted > by the same device with its own higher priority interrupt ? No. > > must clear all the enabled internal interrupt states within the UART > > in order to clear the interrupt output and thus allow the PIC to detect > > a new interrupt. > > but the device HAS to ASSERT its IRQ again in order to have another of its > interrupts served - so it must DE-ACTIVATE the IRQ line at some time - and > i'm pretty sure it's right after the PIC acknowledges the devices > request - so that it can interrupt one of its own ISRs by one of its own > higher priority interrupts ... ??? i'm probably wrong! :( You're wrong. There is no automatic interrupt-acknowledge on the ISA bus. The PIC interrupts the processor when an input goes from inactive to active. It is the processor's responsibility to manipulate the peripheral so that the input goes inactive again. If it fails to do so, there will be no more interrupts from it. Finito. > maybe i've been working with the SCC too long ... Perhaps you have been working in non-ISA environments too long. The M68K has a slightly more sane interrupt management scheme, as do some RISC processors. Intel don't appear to have got it right with the APIC either (I can't say for sure having never had to talk to one myself.) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701021134.WAA16141>