DT’s Elapsed Timer Magic Trick

[Art]

Thanks
It wasn’t my idea to use timer1 values as RAM that survives WDT reset,
but I figure as long as you haven’t started timer1, you could just write the count into
one of the timer1 bytes instead of on-chip EEPROM and read the value after the reset.

For my clock board I have swapped the 8MHz crystal with a 20MHz crystal,
and added a dual flip flop to divide two of the clocks, so now have:
8,12,16,20 & 24MHz. One dual more flip flop, and I’ll have 6 & 10MHz as well.
It has been reliable so far with the freqs I can test, bust suspect any 1MHz increment is easy to detect.

[Art]

Ok, after a little experimentation today, finding the frequency without any use of EEPROM at all is really this easy:

'
DEFINE OSC 20				‘needed so the 100ms pause period is known
'
if status.bit4 = 1 then			'was not reset by watchdog
for percount = 0 to 255			'do eeprom writes until wdt reset
pause 100				'
@ MOVF	_percount	,W		;copy counter value to timer low byte 
@ MOVWF   TMR1L				;load timer with count value
next percount				'
makereset:				'failsafe to make reset occur
goto makereset				'
'
else					'hardware was reset by watchdog
@ clrwdt				;
@ MOVF	TMR1L	,W			;copy counter value to timer low byte 
@ MOVWF  _wrtcount			;reload timer with correct value
endif					'
'

Then you have a number in wrtcount that represents the crystal frequency i.e. a couple of values either side of 25 = 20MHz.
This is with the power timer also set, but I doubt that matters as the pic isn’t doing anything in power timer period.

In any case, it’s very handy to know that if you’re not using Timer1,
you have an ordinary word variable that survives WDT for certain.

If your program was going to use Timer1 after this, the values should probably be reset to zero, then the clock started.
DT’s Elapsed Timer code does have a Reset feature which probably does this as well as clearing it's real time variables.