Analysis of the interrupt response process of MCS-51

Conditions for interrupt response:
At this point, we still feel amazing about the computer's response to interrupts. We humans can respond to external events because we have a variety of "sensors" - our eyes and ears can receive different information. How does the computer do it? What about this? In fact, to put it bluntly, it is not surprising at all. When MCS51 is working, it will query each interrupt mark in every machine cycle to see if they are "1". If it is 1, it means that there is an interrupt request, so the so-called interrupt, In fact, it is also a query, but it is checked every cycle. To put it in human terms, it is equivalent to when you are reading a book, you will raise your head every second to check if someone is ringing the doorbell or if there is a phone. . . . Pretty stupid, isn't it? But computers are like this, no one is smart at all.

After understanding the above interrupt process, it is not difficult to understand the conditions for interrupt response. In one of the following three situations, the CPU will block the response to the interrupt:
1. The CPU is processing an interrupt request of the same level or higher.
2. The current machine cycle is not the last cycle of the instruction currently being executed. We know that microcontrollers have single-cycle, double-cycle, and three-cycle instructions. It does not matter whether the currently executed instruction is a single byte. If it is a double-byte or four-byte instruction, you have to wait for the entire instruction to be executed before responding to the interrupt ( Because the interrupt query may be found in every machine cycle).
3. The instruction currently being executed is a return instruction (REti) or an instruction that accesses the IP and IE registers, and the CPU should execute at least one more instruction before interrupting. These are all related to interrupts. If you are accessing IP or IE, you may turn on or off interrupts or change the priority of the interrupt. The interrupt return instruction indicates that the interrupt has not been processed yet, so you have to wait until the processing of this instruction is completed. , execute another instruction to respond to the interrupt.

Interrupt response process
The CPU needs to check each interrupt source sequentially in each machine cycle. When an interrupt request is detected, whether it can respond depends on whether the following conditions exist:
(1) The CPU is processing the same level or higher level Interrupt;
(2) The instruction is being executed and the last machine cycle has not yet reached;
(3) The instruction being executed is a RETI or access IP or IE instruction. After the above instruction is executed, the response will not be until another instruction is executed. New interrupt.
Response process: (assuming that an interrupt request flag has been set to 1)
(1) First set the corresponding priority status flip-flop to 1;
(2) Execute a hardware subroutine call,
1) The hardware clears the corresponding interrupt request flag (TI , except RI)
2) Push the current PC content into the stack - protect the breakpoint;
3) Send the interrupt service subroutine entry address to the PC - transfer.
Return process: (after RETI execution)
(1) Clear the corresponding priority status trigger to 0.
(2) Pop the two bytes at the top of the stack from the stack and send them to the PC - restore the breakpoint.
(3) The CPU continues executing the original program where it was interrupted.
Note:
1) The difference between protecting breakpoint and protecting scene and restoring breakpoint and restoring scene.
2) The external interrupt response time is between 3 ~ 8 machine cycles.
Use external interrupts to implement single-step operations.
When the CPU responds to an interrupt, it first sends the address of the next instruction (that is, the instruction to be executed after the interrupt returns) to the stack, and then sends the corresponding interrupt entry address to the PC according to the interrupt mark. PC is the program pointer, and the CPU The instruction is fetched based on the value in the PC. Whatever value is in the PC, the instruction will be fetched somewhere, so the program will go to the interrupt entry point to continue execution. These tasks are all done by hardware and we don’t have to think about it. There is another question here. Have you noticed that each interrupt vector address is only separated by 8 units, such as 0003-000B. How to complete the interrupt program in such a small space? It's very simple. If you arrange an LJMP instruction at the interrupt point, can't the interrupt program jump to anywhere?

A complete main program should look like this:
ORG 0000H
LJMP START
ORG 0003H
LJMP INT0; transfer to external interrupt 0
ORG 000BH
RETI; no timer 0 interrupt is used, put a RETI here in case it "accidentally" occurs Interruption will not have much consequences.
After the interrupt program is completed, a RETI instruction must be executed. After executing this instruction, the CPU will take out the address saved in the stack and send it back to the PC. Then the program will continue execution from the interruption point of the main program. Note: The protection work done by the CPU is very limited, only one address is protected, and everything else is not protected, so if you use A, PSW, etc. in the main program, you have to use it in the interrupt program They also need to ensure that after returning to the main program, the data there is still the data before the execution interruption, so they have to protect themselves.


`