2 of 2 people found this helpful
Is my perception correct?
Yes you are correct.
Why are low-priority interrupts entered within the interrupt-disabled section also pending?
By design, every CPU doesn't know the designer's intention. Therefore when interrupts from multiple sources occur, the interrupt active flags are preserved. The is true even with lower priority interrupts. The CPU design assumes ALL interrupts are important to the application. It's up to the application SW design to "throw away" any unneeded interrupts.
The normal ISR servicing is to process the first incoming interrupt unless there are more than one pending. This can happen if interrupts are temporarily disabled. If this is the case, there is an assigned priority by the user or in the CPU design.
Once the first ISR is processed and RTI, the next ISR is processed and so on.
Does it exist if the generated interrupt is discarded?
Jumping into an ISR is due to a pending interrupt. The interrupt active flag in the register may or may not be automatically cleared when the ISR begins processing. I recommend you consult the CPU tech documents for this information. If the interrupt is not automatically cleared, you will have to perform it in the ISR.
Note: Be careful not disable interrupts too long. As noted, each interrupt source has an interrupt active flag. If interrupts are disabled too long, you might actually get more than one attempt to set the SAME interrupt active flag. However, since there is only one active flag for this interrupt source, you might lose the relevant data that caused the earlier interrupt(s).
An example of this condition is a Real-Time Clock (RTC) interrupt. If four 1 seconds RTC interrupts attempt to be serviced but interrupts were disabled for 4 secs, the ISR will be serviced ONLY once and the latest RTC data will be available.
A slight exception are communication interrupts. A UART has a 4-byte Rx FIFO. Therefore if the ISR is not serviced for 4 UART Rx interrupt attempts, you can use just one ISR call to pull all 4 bytes from the Rx FIFO.
Back when I was a young engineer (many, many years ago). a experienced SW engineer told me the following wisdom about using interrupts.
- Only disable interrupts to properly service time-critical SW atomic operations.
- Only disable interrupts for a the shortest amount of time needed.
- When servicing an ISR, execute the least amount code to get the relevant data and store it for queued use in the main Task or Task scheduler. This is to prevent other pending ISRs from getting delayed. Remember: When executing an ISR, interrupts are normally disabled until the ISR is completed.
- If you need to execute an action in the ISR, make sure it can execute quickly to exit the ISR ASAP. If it can't be executed quickly queue it in the main Task or Task scheduler. An example of what NOT to execute in the ISR is dumping multiple bytes to a serial port. Also avoid Delay() commands.
- Avoid nested interrupts. Use sparingly. Nesting can cause stack overflows if not carefully designed.