Using a Crystal just for Timer1

[Ttelmah]

One thing it may be worth saying. You talk about having a timer with a
resolution of 10mSec (so a count that increases at this interval), and then
have your need for accuracy long term. Is the short term accuracy at all
importante?.
If not, then it is worth understanding that interrupts cost processor
performance. If you are servicing an interrupt every 1mSec, then this
will use tens of thousands of machine cycles per second.
As Jay says there are RTC modules that give really simple holding of a
reasonably accurate 'time', and the nice thing with these is they only
use any processor resources when you actually read them. I have a
system that uses the internal oscillator, and on the PIC I'm using this
gives better than 2% overall accuracy. In fact it is normally well better
than this. The unit has an external RTC, but does all it's internal operations
based on a simple timer running off the internal oscillator. This drifts a
little, but all I do is every time the counter runs over (100Hz clocked, so
every 65 seconds), I just read the external RTC, and set my master internal
'time' based on this. At any moment I want a time, I just read the last
read time value, and add the count from the internal timer. Result is my
long term accuracy is good, but I don't use much processor time to handle
things, and have an instantaneous 'time' when needed.
I had the unit switched off for a couple of weeks, turned it back on, and
the system 'time' was easily within a second of the current time.

Might be worth considering an approach like this.

[asmallri]

[Ttelmah]

You are way off.
It is not quite as bad on the PIC24's etc., but on the simpler PIC's every
operating register is saved, then the code has to test which interrupt is
involved, and call the handler. Typically over 60 instructions of overhead
getting into and out of the handler. Even on the 16bit PiC's, there is a
save of each operating register that is undone on the exit. On the 16bit
PIC's the overhead is about 18 instructions on entry and the same on exit.
Add your ten instructions to the ISR overhead (and add the ISR clear
instruction, then remember the call and return are both twin cycle
instructions, and you have 10+3+60 = 73 * 100 = 7300. It only takes the
ISR to be fractionally more complex, and the time climbs into the tens of
thousands of instructions.
That is also the instruction count, not the machine clock cycle count.
*4 on clock cycles.
Disassemble a standard interrupt handler sometime.

Your case undercounts even the overhead if you use the FAST keyword,
and the internal save instruction.

[asmallri]

I mixed up a couple of posts and thought this thread used the PIC24 family and as a result my previous post IS NOT APPLICABLE to the PIC18F family and I apologise for any confusion I casused.

Having said that, from a PIC24/DSPIC33 perspective, my previous post was not far off the mark.

In my solution, the 1ms interrupt handling does not modify any registers therefore you do not need the compiler to push and pop unnecessary registers from the stack.

This approach would use two interrupt handlers, one simple one as outlined by my previous post dealing with the 1ms interrupt. Then a second interrupt handler (basically any spare interrupt) that would be invoked by the 1ms handler when the 1ms MyCount is decremented to zero. When this occurs the 1ms handler would set the interrupt flag bit corresponding to whatever interrupt handler the 10ms task is allocated to. The CCS compiler would handle this as a standard interrupt handler and there push and later pop all registers.

This approach adds minimal overhead and does not required additional hardware such as a RTC. Any time you add hardware to a product you increase hardware complexity, final product costs and reduce the overall MTBF.

As they say, there is more than one way to skin a cat and this is how I would do it for a PIC24/dsPIC33.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

Yes, the 16 bit PIC's are a lot better, however if you look at the standard
handler, there is still a save of all the W registers. Only a single instruction
line, but it repeats 12 times!.....
Big saving of course is that the interrupt vectors directly to the required
handler.
Interrupts generically have much more overhead than you may expect.