On Sun, Jul 12, 2009 at 5:21 AM, Heinz Czychun wrote: > 1) What I am seeing is normal behaviour. > > 2) T0IF gets set every time Timer 0 rolls over Yes, that's correct > 3) 2 above is only an issue if another peripheral causes an > interrupt, then T0IF must be explicitly dealt with. Since Timer 0 is > not easily turned off. You do not have to deal with T0IF, simply just ignore it in the ISR. That's one of the disadvantage of the non-vectored interrupt controller of the PIC. When an interrupt occurs you always have to figure out what caused the interrupt. Testing T0IF is just a way polling if Timer0 caused the interrupt, but if T0IE was not set there is no reason to do this testing. > 4) I can only stop Timer 0 by: Don't worry about stopping Timer0. Just let it rolling over and over again and ignore T0IF. In the main code the interrupt enable bits are significant in that > they will prevent a peripheral from generating an interrupt. So the > interrupt flag bits can safely be ignored. That's correct > Once an interrupt (any interrupt) forces execution of the interrupt > service routine the interrupt enable bits become useful flags to tell > which peripheral's service request should be honoured. But now the > interrupt flag bits (all that are set) become significant and cannot > be ignored. Whether the peripheral's interrupt enable bit is set or > not it's interrupt flag bit must be cleared or the processor will be > hung repeatedly reentering the interrupt service routine. Only when the appropriate IE bit is set. For example if T0IE is clear you will get no interrupt at any time because of T0IF is set. Tamas -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist