News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

hardware interrupt

Started by xxxx, February 26, 2005, 04:19:33 PM

Previous topic - Next topic

xxxx

1.how many software and hardware interupts can the 8088 implement?
2.are software interupts executed the same way internal interupts are excecuted?








thanks

MichaelW

The early x86 processors support 256 interrupt vectors, numbered 0 to 255.

I'm not sure I understand your second question. If by internal interrupts you mean processor-generated exceptions, both (software and exception interrupts) are "executed" in the same way, but not initiated in the same way. External hardware interrupts are "executed" pretty much in the same way, but at some point before the final interrupt return, an interrupt handler must indicate to the interrupt controller(s) that the interrupt has been handled.
eschew obfuscation

xxxx

1..   "The early x86 processors support 256 interrupt vectors, numbered 0 to 255."
       
    is that the total of software and hardware interupts or separate for each?


2.take the 8088 as an example.i just finished reading about the 8259 programable interupt controller and my understanding is that if i want to use interupt type  16h to service an interupt generated by an edge presented by IR0 i would make ICW2=10110.so would the interupt service in routine in IR) be same if i had written:   INT 16H in a program?plz correct me where i'm wrong

MichaelW

1. 256 would be the total for software and hardware interrupts.

2. The upper 5 bits of the value written to ICW2 are the upper 5 bits of the interrupt ID, and the lower 3 bits of the interrupt ID are the level of the interrupt currently being serviced. So AFAIK the value 10110b would mean that IR0 would have an interrupt ID of 10000b = 10h. There is a one to one correspondence between the value written to ICW2 and the interrupt ID for IR0 only when the lower 3 bits of the ICW2 value are clear. The value normally written to ICW2 for the master is 08h = 1000b, and 70h = 1110000b for the slave. But to answer your question, as programmed, an INT 10h would call the same handler as would be called for an IRQ0.
eschew obfuscation

xxxx

michealw,
 
      just to make i understand,what should ICW2 be for interrupt type 72?




thanks

MichaelW

I hope this is understandable:

ICW2 = 72 = 48h = 01001000b

lower 3 bits from IRx --------+++
upper 5 bits from ICW2 -+++++ |||
                        ||||| |||
                        vvvvv vvv
Interrupt ID for IR0  = 01001 000b = 48h
Interrupt ID for IR1  = 01001 001b = 49h
Interrupt ID for IR2  = 01001 010b = 4Ah
Interrupt ID for IR3  = 01001 011b = 4Bh
Interrupt ID for IR4  = 01001 100b = 4Ch
Interrupt ID for IR5  = 01001 101b = 4Dh
Interrupt ID for IR6  = 01001 110b = 4Eh
Interrupt ID for IR7  = 01001 111b = 4Fh

eschew obfuscation

xxxx

thank you.evrything is clear now.

thanks

xxxx

#7
assume that ir 3  is being serviced.then ir 0 is requesting a service.will the 82C59A make output INT a logic 1 and then servide ir 0?

edit:  i meant  INT==INTR
thanks

MichaelW

I don't know what output INT is, but assuming the interrupt flag is set (this would be so if the IR3 handler had executed an STI), IR0 would then be serviced. But note that the interrupt controller will inhibit any request that is not of a higher priority than the highest priority request currently being serviced. So if the requests were reversed, with IR3 attempting to interrupt IR0, the interrupt controller would remember the request but it would not immediately pass the request to the processor because IR3 has a lower priority than IR0.
eschew obfuscation

xxxx

so if IR3 is being serviced and IR0 is requesting a service and the interupt flag is set,the controller would generate an interupt request to the CPU through the INTR output?

MichaelW

Yes...But I see now that in my last reply I skipped over one significant detail. AFAIK the interrupt controller knows nothing of the interrupt flag, so the controller would set INTR regardless of the state of the flag. If the flag were set, the processor would recognize INTR and carry out the actions necessary to service the interrupt. If the flag were clear, the processor would ignore INTR, so it would not generate the interrupt acknowledgement sequence that the interrupt controller would be waiting for, so the interrupt controller would simply wait (with INTR set).
eschew obfuscation

xxxx

so if the interupt flag is set,then IR0 would not be serviced while IR3 is being serviced eventhough the priority of IR0 is higher than IR3?but if IR0 is being serviced and IR3 is requesting a service it won't be serviced regardless of the state of the interupt flag?

thanks

MichaelW

If the interrupt flag were set, IR0 would be serviced. As the interrupt controller is normally programmed, its handling of a request is determined by the priority of the request and the state of the Interrupt Mask Register. When the interrupt controller receives a request that has a higher priority than any that are currently being serviced, and if the request is not masked, then the controller sets INTR. The processors handling of INTR is determined by the state of the interrupt flag. If the flag is set, the processor recognizes INTR, and if the flag is clear, the processor ignores INTR.
eschew obfuscation

xxxx

thank you for ur explanation.


when IR3 is being serviced,what is set in the in service register?what what happens to it when IR0 is requesting a service and the interupt flag is set?




thanks

MichaelW

When the interrupt controller gets an interrupt request it sets the corresponding bit in the Interrupt Request Register. The interrupt controller logic then decides whether to generate an INTR. I currently don't have any references available that detail how the controller logic works, but you can probably find an Intel document somewhere that does. If the processor recognizes INTR, it generates two Interrupt Acknowledge bus cycles. The first acknowledge clears the highest-priority bit in the Interrupt Request Register and sets the corresponding bit in the In Service Register. The second acknowledge causes the interrupt controller to output an interrupt ID, and the processor uses this ID to service the interrupt. After the interrupt is serviced, the interrupt handler (interrupt service routine) writes a non-specific End-of-Interrupt command to the interrupt controller, and the controller then clears the highest-priority bit in the In Service Register.

eschew obfuscation