Path: utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: Shared Interrupts (was Parallel Port question) Keywords: interrupts Message-ID: <14444@cbmvax.commodore.com> Date: 14 Sep 90 14:06:40 GMT References: <28208@swrinde.nde.swri.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 103 In article <28208@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes: >In article <1990Sep13.000531.15782@msuinfo.cl.msu.edu> wille@frith.msu.edu >1) Should I reset the interrupt line first thing in the isr, or hold it >low until I'm finished? My isr is pretty busy & takes about 600 us to >complete its dirty work. (at least for now, since it is written in >'C'). In case you were wondering, this is what Jeffrey's input buffer >question has to do with this whole discussion... In general, it can't hurt to clear an interrupt as soon as the software watching that interrupt is called up. Most of the chips, like the Amiga CIAs, which pull interrupts on their own will negate their interrupt output as soon as the service routine reads their interrupt registers. Simple things can be done in the actual interrupt service routine, but if you have an very lengthy bit of work to accomplish, it's much better for your interrupt service routine to simply clear the interrupt register in the device and signal a server task that an interrupt has come in. This doesn't make sense for a simple device that's interrupting you for a single byte coming in, but it's necessary for things like hard disk drives that send over large packets. >2) What about shared interrupts hitting at or near the same time: > a. Do the other PORTB isr's hold the line low until finished (2091 SCSI, > Keyboard * timer) ? Other devices will hold the line low at least until the software that manages them has been notified of the interrupt. There's no need to go beyond that. > b. How are multiple interrupts hits (at the 'same time') recognized > by the system? The interrupts are level-sensitive (except for level 7, NMI, which isn't supported in the A2000). This means that, as long as interrupts are enabled (both in the Amiga interrupt controller and 680x0 sense), the 680x0 CPU will sample the interrupt code every so often and dispatch the appropriate interrupt service vector as long as an interrupt is held low. I think what happens now is that the OS interrupt dispatcher will walk down the list of interrupt servers until one indicates that it manages the device that actually pulled the interrupt. The OS then will RTI, at which point the 680x0 will take that interrupt again if it's still low. Or something along those lines. > c. Guru's Guide indicates how one should exit a shared isr when you > determine it was your hardware which pulled the interrupt. - If > multiple hits at the same time aren't registered, how do I know that > I'm not stealing an interrupt when my hardware says it did it? As a > matter of fact, I can do just that - not hook up my interrupt line & still > process what are actually someone else's interrupts as if they were > mine. If your hardware thinks it pulled the interrupt, your server needs to respond. The only thing that would cause a problem for other devices would be if your server responded positively every time the interrupt were served, whether it pulled it or not. Now, of course, your device isn't going to do what it's supposed to if its interrupt line isn't connected, but other than slowing the system down more, you can't hurt any other device by responding to an interrupt you think you pulled. > d. Can I just say 'Not mine' to all of them? Does the system get confused > when no one claims a shared interrupt? I realize that might slow things > down a bit, but if it is safer then I can do it. You only worry about interrupts you pull. And you can't answer for another device, even if you want to. You would confuse the system pretty heavily if you presented it with an interrupt that couldn't be serviced. First of all, the system would be caught constantly servicing that interrupt. There's no way to force all interrupt generating devices to stop. Of course, if you just pull an interrupt and don't service it, you're doing something illegal anyway; a device should never pull an interrupt until its server is installed. The other effect of permanently pulling an interrupt is that no lower priority interrupts would ever get through. They work a little like tasks -- as long as a higher level interrupt is pulled, no lower level interrupts can be seen. >3) Do most shared interrupts incorporate a timeout - say - maybe 100 ms or >so? I plan on doing this as it is pretty easy, but am mainly curious. The >main reason is that when my program exits ungracefully, the interrupt doesn't >get serviced & poor Amy is left out in the cold, waiting for someone to >rescue her from the evil clutches of Dr. Loe :^) If you don't eventually get serviced, something is very wrong. But I don't have any good number on the longest you'll have to wait to get serviced. We have a working limit of 8ms on the A3000 for any I/O device to respond (though this actually is set to 1/4 sec, with a bus error following). That's just one cycle. While it's extremely evil to grab the bus that long, there are definitely some of these programmed I/O hard disk controllers out there which grab the bus and shut off all interrupts for multiple block transfers from disk. So you could be waiting awhile. You definitely want to reset any interrupt lines on system reset, and don't enable interrupts until your server is installed, but I wouldn't recommend a timeout. >Problem is, every now and then, I seem to be trashing the machine - >trackdisk.device appears to be the culprit, but I know better, so apparently >I am trashing trackdisk.device. Hmm... I dunno about that one. You can't actually harm floppy transfers even by hogging interrupts; the transfer itself happens via the floppy's preallocated chip bus DMA slots. Interrupts only signal the system when the transfer is finished. >Kent Polk: Southwest Research Institute (512) 522-2882 -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!