MCU has multiple interrupts in a short period of time. How to solve the problem of interrupt loss?

question

In embedded development, if the execution time of interrupt A's processing function is long, and two interrupts A come quickly within a certain period of time (for example, external pin input signal changes), the second interrupt will be lost.

I have a few questions:

1. Do the chips currently on the market support caching interrupt flags? For example: Interrupt A is triggered three times in a short period of time, but the CPU has no time to respond (the execution function of interrupt A takes a long time, or a higher priority interrupt is being executed) , can the CPU remember these three interrupts? If so, how many interrupt flags can be cached at most?

2. If there is no interrupt flag caching mechanism, it must be ensured that this interrupt is processed before the next interrupt arrives?

3. Can the flag of interrupt A be cleared at the initial stage of interrupt A response (automatically cleared by the chip or cleared in the interrupt processing function). At this time, if interrupt A occurs again, the chip will set the flag of interrupt A. In theory, the interrupt flag can be cached twice?

Summary of netizens’ responses:

Use asynchronous processing

——After an interrupt occurs, only the interrupt record is recorded, and the interrupt service is not processed.

Just like when we write a microcontroller program, there is a variable in the interrupt service program that is constantly increasing, and then there is another main program that is constantly judging and processing while.

Measure the execution time of the interrupt service function to see if it is small enough, such as less than 5us. If the interrupt handler takes too much time, it must be optimized.

In Linux, there are upper and lower halves of interrupts. The upper half handles more timely matters, and the lower half handles more time-consuming operations.

Also when using interrupts, if it is already being processed, the first thing to do when entering the interrupt is to turn off the interrupt to avoid being interrupted by interrupts during the interrupt processing process.

——Is it necessary to add a cache for interrupts?

Caching is a good thing, but caching will definitely lead to interruptions that are not timely enough. For example, the idea of ​​​​interruption is, I want to go to the toilet, and I must go to the toilet now. What I mentioned earlier is "interruption", so how to design an interrupt cache has become an interesting topic. What the interrupt service program needs to do is to continuously throw things into the cache, and a thread is required to continuously retrieve data from the cache. Get things to process until the cache is empty.

——Of course, caching also has caching problems, so I saw someone replying

" ---There is currently no chip that implements caching. The interrupt only has a triggered flag and a cleared flag, and there is no information about how many times it has been triggered ."

Caching is the idea of ​​​​software, and the CPU part does not want to consider such low-level things.

————If there is no interrupt flag bit caching mechanism, it must be ensured that this interrupt is processed before the next interrupt arrives?

One method mentioned above is to turn off the interrupt when entering the interrupt. Another way is to clear the current interrupt flag bit when entering the interrupt, and then do the processing. If another interrupt occurs during the processing, The interrupt flag bit will be set, and then the interrupt will be re-entered after exiting the interrupt.

Through the above method, the purpose of caching 1 interrupt can be achieved, which is equivalent to having a buff that can handle 2 interrupts.

Spring recruitment has begun. If you are not fully prepared, it will be difficult to find a good job in spring recruitment.

I’m sending you a big employment gift package, so you can raid the spring recruitment and find a good job!