Bill wrote:Assuming you can't turn Timer 0 off because of your application requirements, so far this is normal...
Actually, T1 and T2 can be turned off, but T0 cannot. It can only be disabled. It’s when it is disabled that the ISR still executes the code designed to service a T0 interrupt, because of the recommended test of T0IF, which only tests for overflow, not for interrupt. I now also test for T0IE, which is what I originally thought was a fudge, and therefore probably wrong.
Bill wrote: If you are enabling and disabling T0IE in the main software loop, then you have to conditionally check the T0IF bit in your ISR depending on the state of T0IE.
Exactly - “depending on the state of T0IE” and everyone says test the IF, but it seems that you also have to test the IE in some cases. I started doing that, and I think you’re saying that I got it right. I had thought that I was getting it wrong and that my IE test was a crowbar solution, since I have never seen any reference to it in this context. My contention is that Microchip providing a direct test of interrupt might have been appropriate.
Bill wrote: Do you, or do you NOT want interrupts with Timer 0? If you do NOT, clear the T0IE register and Timer 0 will not generate interrupts. Since it won't be generating interrupts, your ISR should not be looking at T0IF. You will need some other polling routine to check for overflows (if that matters) or let it run with T0IF set.
T0 will be required sporadically, enabled by an external stimulus (emulated by a momentary push switch on my breadboard) and when T0 times out the ISR will disable it. Thus there will be no further interrupts until the button is pressed again, but T0IF will be high for all of that time, since it is still running and timing out. Therefore unless I also test T0IE, the timeout will be responded to in the polling code, which I cannot allow to happen.
Bill wrote: Perhaps you should explain what you are trying to do and post your source code for analysis. I'll wager that this probably boils down to not fully understanding how the interrupt logic works.
It’s 469 lines of assembly code, and now that it includes testing of IE in the ISR, it works as required. I can readily describe what the software is doing and provide the code, but doesn’t the above describe exactly what I’m getting at?
But I think you have supported my “fudge” of testing of IE as well as IF in cases where the timer is needed but not always enabled. That’s probably pretty blindingly obvious, but as I said, I have never seen it mentioned.
Or is there still something fundamentally wrong somewhere?