How to truly implement PT60 interrupt nesting <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Recently, when supporting several PT60 home appliance projects, I encountered a common problem, that is, when the program is running, the display digital tube will flicker irregularly. Several projects are centered around touch TSI. The other party's engineer responded that if the TSI interrupt is turned off, there will be no flickering. The scanning program of the digital tube is completed in the MTIM interrupt. After preliminary analysis and speculation, it should be caused by the interrupt timing disorder. So we thought this could be solved by nesting interrupts. To put it simply, the definition of interrupt nesting is that when the MCU is processing a low-priority interrupt, a high-priority interrupt comes, the system will then drop the low-priority interrupt and execute the high-priority one, and then return to execute the low-priority one. According to this logic, we should be able to set the priority of each interrupt in advance. The project uses a total of four interrupts: TSI, RTC (the combination of these two interrupts completes the TSI key scan, which is based on the algorithm written by Sam before), MTIM (digital tube scanning), and KBI (used for low-power wake-up). Therefore, we set the priority of MTIM to the highest, and the flickering phenomenon should no longer occur, but after the change, the result still fails. After continuous discussion and searching the data manual, it was finally realized, but it must be said that it is still quite troublesome to implement interrupt nesting in PT60. Let's go step by step: 1. First, let's look at the order in which the CPU executes interrupts. The rest of the steps are nothing special, the key lies in step 2. 2. Let's look at the function of the I bit. When an interrupt is entered, the I bit will be automatically set, that is, the system turns off all interrupts. The reason for doing this is to prevent the system from being interrupted by other interrupts when executing a certain interrupt. So this is the root cause of why we break nesting failure! 3. Therefore, if we need to use nested interrupts, we need to add the instruction to clear the I bit of the CCR register, asm cli, in each interrupt program. 4. Because interrupt nesting is enabled, there is a potential risk that some stack data before the interrupt will be incorrect or the interrupt priority will be wrong, so at the end of the interrupt program, we can add one more sentence to restore everything to normal. IPC_SC_PULIPM = 1; After the above steps, interrupt nesting can be realized. But in this process, I encountered several problems, and I would like to share them with you. 1.PT60 interrupts will nest themselves: The manual mentions that high-priority and same-level interrupts can preempt low-priority ones. Let me give you an example to illustrate: Now there are two interrupts, interrupt 1 - low priority level 0, interrupt 2 - high priority level 1. Interrupt 1 is in the process of being executed, and interrupt 2 comes to interrupt it. The system must finish executing interrupt 2 first, and then go back to execute the remaining part of interrupt 1. But unfortunately, a new interrupt 1 comes at this time, which means that the previous interrupt 1 has not finished running, and is preempted by the new one, that is, it nests itself, which will inevitably cause problems in the timing of all interrupts. This is a potential hidden danger. Our solution is: after the interrupt No. 1 of level 0 starts to execute the interrupt program, let it raise its own interrupt level by one level. When the interrupt ends, add the recovery statement mentioned above to change it back to level 0. In this way, my old interrupt No. 1 (level 1) has not been executed yet, and even if the new interrupt No. 1 (level 0) comes, it cannot be preempted and must wait for the old one to finish executing first. The following statements are used to increase the interrupt level. When we experiment, the interrupt is only level 0 and 1. 2. The interrupt flag must be cleared before executing the asm cli instruction: Next, if you open the asm cli without knowing the flag, the system will keep letting the interrupt go in, that is, the interrupt will keep nesting itself, and eventually the stack will explode, and the program will run away. It's simple stuff, but definitely worth noting. Attached is the test program, you can refer to it if you need it. General
記事全体を表示
