Interrupts: Difference between revisions

There are actually two PICs on most systems, and each handleshas 8 different interrupts. Actuallyinputs, IRQplus 2one andoutput IRQsignal 9that's (handledused byto tell the masterCPU andthat an IRQ occurred. The slave PICs,PIC's respectively)output aresignal is connected, soto wheneverthe IRQmaster PIC's third input (input #2); occurs,so IRQwhen 9the alsoslave occursPIC (thiswants canto betell changedthe CPU an interrupt occurred it actually tells the master PIC, butand mostthe devicesmaster expectPIC IRQtells 2the toCPU. beThis reservedis called "cascade". The master PIC's third input is configured for this purposeand not configured as a normal IRQ, andwhich thereforemeans dothat notIRQ use2 it)can't happen.

A device sends thea PIC chip an interrupt, and the PIC tells the CPU whichan interrupt occurred (either directly or indirectly). When the CPU acknowledges the "interrupt occurred" signal, the PIC chip sends the interrupt number (between 00h and FFh, or 0 and 255 decimal) is to bethe servicedCPU. When the system first starts up, the IRQs 0- to 7 are set to interrupts 08h- to 0Fh., and IRQs 8-F to 15 are set to interrupts 70h- to 77h. Therefore, iffor IRQ 6 is sent to the PIC by a device, the PIC would tell the CPU to service INT 0Eh, which presumably has code for interacting with whatever device sentis connected to the interruptmaster inPIC thechip's first"input place#6". Of course, there can be trouble when two or more devices share an IRQ; if you wonder how this works, check out [[Where Can I Find Info On PNP|Plug and Play]]. Note that interrupts are handled by priority level: 0, 1, 2, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7. So, if IRQ 8 and IRQ 3 come in simultaneously, IRQ 8 is sent to the CPU. When the CPU finishes handling the interrupt, it tells the PIC that it's OK to resume sending interrupts: