Also verified on a bad-ass-looking Citizen watch, which cost me over=20
$10, so it has to be right.

How does one stop the oscillator and maintain accurate timing?  The main=20
oscillator is the internal osc at 32 Mhz, and the secondary 32.768 khz=20
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=20
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=20
serviced when the TMR1H interrupt occurs, TMR1L may be about to overflow=20
and update TMR1H when the code is updating it too, resulting in some=20
type of "conflict".  I say "conflict" as if it were just that the=20
overflow and subsequent TMR1H increment occurs before the code changing=20
TMR1H, then a bit of time would be lost.

To test my assumption, I'm thinking I could probably wait in a loop=20
(ugh! -- I hate that in interrupts) until TMR1L is some low value, and=20
then re-load TMR1H.  I'd also have to check for TMR1H already being=20
incremented (by a TMR1L overflow), and compensate for that.  I vaguely=20
remember some discussion of this for older 16F chips, but not coming up=20
with much right now.  Will search better when I have a better internet=20
connection.

Cheers,
-Neil.


On 5/28/2012 11:29 PM, IVP wrote:
>> 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

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.