Hardware Interupt

[Dinosaur]

Hi all

Long time since I have posted anything, but rest assured I keep an eye on the questions and answers.
My question is perhaps more hardware related, but searching the net with all sorts of variations of the same topic still delivers no answers.

I am trying to borrow an hardware interupt line from devices that I know are not installed on my systems.
For example, Com2:

My problem is that I cannot find anywhere the detail related to the actual hardware interfacing, like timing or diagram showing de-coupling etc.
Plenty of examples for writing Interupt handlers in asm.

I have an 8bit I/o card with an onboard cpld that is going to create an output/interupt every time an event occurs.
My questions are:
How long is this interupt allowed to be ON for ?
can it be On for 1 isa bus clk ?
If during power up the signal goes Tri-State what are the implications. ? (if there are then I may have to buffer the output)

Any help appreciated, including links to the sites with info.

Regards from DownUnder
Dinosaur

[Phil]

I really wish I could help you with your questions. I too did a Google search looking for some timing diagrams I had once seen in a book titled 16-bit Microprocessor Architecture by Andrew Tanenbaum. It's an ancient text comparing the 68K and 386 processors if I recall correctly but it also had a wealth of info about bus interfacing and signal timing. Perhaps you might find a copy at your library or maybe a used copy for sale cheap on Amazon. The text was dense but probably correct. I think it was used in several college courses teaching computer architecture.

Here's what I think, but do not know for certain, about the INTR request. The signal can be asserted by the interrupt controller when a device signals an event. The interrupt controller is also responsible for priority arbitration and also for raising some signals that give the processor a handle into its interrupt vector table. These signals are probably raised by the controller when it sees the INTA signal come back from the processer saying that is acknowledging and preparing to service the interrupt. The device would still be asserting its interrupt request to the interrupt controller until the event is actually cleared by an action performed by the interrupt service routine, like reading the byte that had arrived at the serial port, for instance. For each device, there is some specific action that must happen in order to clear the interrupt request for each specific event.

In my brief wanderings I did encounter a caution about some Pentiums requiring a special interrupt controller that would periodically drop the INTR signal during a specific clock cycle. I don't think the 80386 cared whether it was constantly asserted but I think it is an edge triggered event.

Hope someone else here can help you find a more specific reference to the info you need.


Good luck with your

[MichaelW]

Here are some relevant (I hope) quotes from ISA System Architecture, Tom Shanley and Don Anderson, MindShare Press, 1993, ISBN 1-881609-05-7:

On ISA systems, the Interrupt controllers are programmed to recognize a positive-going pulse as a valid interrupt request on an input. There are two problems inherent in this method.
...
Internally, the 8259 has a pull-up resistor on each of its IRQ inputs. When an ISA expansion car must generate an interrupt request, the line is driven low by the card and is then allowed to go high again.
...
The 8259 specification also demands that the IRQ line must remain high until after the leading-edge of the first interrupt acknowledge bus cycle.

This is followed by several paragraphs that explain a problem with ISA cards that are designed to keep the IRQ line low until the request must be generated. In short, the problem is that the low line can pick up noise spikes that can cause the 8259 to can generate "phantom" requests on IRQ7 or IRQ15. To guard against this, the interrupt handler must check the respective 8259's ISR register to ensure that the request is real.

ISA card designers can avoid this problem my designing the card's IRQ output driver to keep the IRQ line high when not requesting service, allowing the pull-up resistor inside the 8259 to keep it high. The line will not be prone to pick up noise spikes when it is high. When a request must be generated, the card drives the IRQ line low and then lets it go high again. This low-to-high transition registers as a request in the 8259. When the microprocessor generates the first interrupt acknowledge, the line is guaranteed to be high and the request is therefore valid.

And from the Intel Microprocessor and Peripheral Handbook (1987), Volume 1 – Microprocessor, the 8259A/8259A-2/8259A-8 Programmable Interrupt Controller data sheet:

If LTIM = '0' an interrupt request will be recognized by a low to high transition on an IR input. The IR input can remain high without generating another interrupt.

The timing requirements do not specify a minimum width for the low pulse on the IR line.

[Dinosaur]

Many thanks for that.

I will try to hardwire and see what happens.

Regards
Dinosaur

[Dinosaur]

Hi all

For those whom would like a follow-up.
Connecting the output from my cpld directly to the IRQ line on the bus worked perfectly.(current limited to 4 mA)
I took note of the quote which suggested keeping the line Hi between interupts, and there are no false interupts.

My only worry was the activity on the IRQ line during the boot up process.
I thought that Dos may try to service the interupt, but I managed to test all in Codeview
and the IRQ does not get serviced until I have re-directed it to my routine.

Many thanks for your help
Regards
Dinosaur