Hi Jinx, On 12-Jul-09, at 12:50 AM, Jinx wrote: >> 5) So I'm left with dealing with the T0IF bit, when in the interrupt >> service routine. >> >> T0IE ..shouldn't this be a set (clear, in this instance) and >> forget item > > Yes > > You need to distinguish between what causes an interrupt and what > is set when the ISR is entered. For example, RB0 has the associated > INT0IF and INT0IE flags. If INT0IE isn't set, then INT0IF can't > cause an interrupt, even though it may be set. If an interrupt is > caused > by a timer Ok, then I'm assuming your in the interrupt service routine, right? > then you may find all kinds of other IFs, like INT0IF, set > if you look for them. But they are of no consequence if you are not > interested in them as interrupt sources. I disagree here they, the IFs, are very significant because you won't get out of the isr without clearing them. I see it as a dyke or dam. All is ok as long as all the water is kept out, no interrupts are allowed to happen. But once that first crack happens, an interrupt occurs, all the set IFs are suddenly seen by the cpu and need to be cleared before it can get back to the main code again. And your code has to tell it to do this. That's how interprete all the warnings in the manual about TMR0 settings its TOIF regardless of the TOIE, and that this must be cleared in 'your' software. I think that's why uChip has added an on bit to most (all?) peripherals, so they never can set their IFs when off, so don't need to be dealt with in the isr. Timer0 being a legacy sort of peripheral (the first one?) doesn't have such a nicety. > > And, for example, it is often > the case that you'd poll an IF, like a timer, in a non-critical > instance > when you don't want to use an interrupt but simply need to know > that an event occurred Yes that works because you never entered into an isr. Heinz -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist