>> Hello Eric! >> This is a good question. >> I agree that for a vast majority of the use cases, using the Timer counters and their handlers independently is the most common way to use it. >> However, have you considered a case, where you would 'not' want to use it? >> for example, consider a point of time in the application, where the app does not care which counter it came, it knows to ignore it, or exit quickly or..? the problem is the INTC handler can't IGNORE it, rather regardless the INTC handler has to figure out which interrupt popped so it can clear it. That is what makes INTC not useful. >> In such a case, instead of replicating the code in each handler, I could use the combined interrupt, which is basically an OR of the 2 separate ones and expect the >> same functionality no matter which counter fires. see above. The issue with the scenerio you are proposing above is you still have to know which Timer generated the interrupt because you have to clear the interrupt manually. Which means you have to know which one interrupted. So you first have to check which timer is generating the interrupt so you can clear the correct interrupt. Once you have to look to see which timer is interrupting, you lose any advantage of the combined interrupt. It is simpler to use the base interrupt because you can immediately clear the interrupt and then call a common routine. >> I could also see assigning a higher priority and using the INTC to do some further priority sorting in software. Okay. Can you be more specific about what you are thinking. I don't see how I can get INTC to do something useful by playing with priorities. The key issue is one needs to clear the appropriate interrupt. Someone clearly thought there was something useful to be gained by adding INTC, I'm trying to understand what that might be. So far I don't see how to use INTC for anything useful that wouldn't be simpler using the base interrupts. >> These are just a few ideas... >> Regards, >> Priya
↧