Also verified on a bad-ass-looking Citizen watch, which cost me over $10, so it has to be right.
How does one stop the oscillator and maintain accurate timing? The main oscillator is the internal osc at 32 Mhz, and the secondary 32.768 khz osc is NOT synchronized to the main.
Either way, after a bunch more testing, I found some interesting data...
(a) with the PIC sleeping, timing seems to be accurate
(b) when the timing goes off, it's not consistent -- seems to jump ahead a second or two rather quickly
(c) if I remove the TMR1H reload, timing is correct in sleep or wake.
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". I 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. I'd also have to check for TMR1H already being incremented (by a TMR1L overflow), and compensate for that. I vaguely remember some discussion of this for older 16F chips, but not coming up with much right now. Will search better when I have a better internet connection.
Cheers,
-Neil.
On 5/28/2012 11:29 PM, IVP wrote:
{Quote hidden}>> 10 secs in an hour, compared to the stopwatch on my phone
> Can you trust your phone ?
>
> Your ISR doesn't indicate anything that would cause such a large
> error, as far as jitter or latency is concerned anyway. 1/360 error
> is an odd sort of number for hex registers. If it was 14s (ie 1/256)
> then you might suspect a consistent high byte anomaly, for example
> the TMR1H loading. The datasheet recommends stopping the timer
> if it's asynchronous with the main ocillator before writing. Perhaps
> try that, with compensation for jitter, and see if that improves the
> accuracy, then look at the best solution. Possibly there's a timing
> mismatch between the s/w and the h/w, although if the main oscillator
> is running much faster than 32kHz that shouldn't be a problem
>
> Joe