On 5 June 2012 02:16, Neil wrote: > My guess (just a guess) is that because of some other interrupt being > serviced when the TMR1H interrupt occurs, TMR1L may be about to overflow > and update TMR1H when the code is updating it too, resulting in some > type of "conflict". =A0I say "conflict" as if it were just that the > overflow and subsequent TMR1H increment occurs before the code changing > TMR1H, then a bit of time would be lost. > > To test my assumption, I'm thinking I could probably wait in a loop > (ugh! -- I hate that in interrupts) until TMR1L is some low value, and > then re-load TMR1H. =A0I'd also have to check for TMR1H already being > incremented (by a TMR1L overflow), and compensate for that. =A0I vaguely > remember some discussion of this for older 16F chips, but not coming up > with much right now. =A0Will search better when I have a better internet > connection. 18F chips have a dual-priority interrupt system. Try using that before doing loops, etc. Set you're overflow ISR as high priority and everything else as 'standard' priority. (Also, the high priority ISR automatically saves context on interrupt entry and exit IIRC). Low priority ISRs can be interrupted by high priority ISRs but not the other way around. All the best --=20 Brendan Gillatt http://www.brendangillatt.co.uk --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .