Implementing a Real-time Clock in a PIC Project.

Alan Robert Clark

Feb 7, 2001

Microchip publish marvellous stuff about ClockFreq/4 = InstrucCycle; and ClockFreq/4/Prescalar = RTCC(Tmr0)Rollover. A number of misconceptions arise. We all use the prescalar, in order to generate fewer RAM bytes necessary to implement a RTC. The Prescalar allows accurate polling ability of the RTCC. (Many instruction cycles per RTCC cycle.)

All hogwash when you actually **Measure** using accurate stopwatches etc. One reason is the (admittedly documented) feature that when re-loading the RTCC, the bloody Prescalar **IS CLEARED**. With no way of reading, or writing to the Prescalar, it is impossible to detect how many clock cycles have been missed.

Using my old watch with wires soldered to the stopwatch button, an open collector transistor and a suitably programmed PIC, it is possible to calibrate the system. But even then, the system is not entirely accurate, and the concept of calibration is to get the Processing cycle as accurate as possible, and for the macro timers, add the occassional leap count :-)

I have tried varying PICS and crystals, but find the results are repeatably exact, down to a hundredth of a second!!! Scary.

The primary adjustment is made after exiting the wait loop, usually inserting nops. These are calculated from the time difference, dividing through all timer levels, till the difference in Processing cycle time is calculated. This number divided by the Instruction Cycle time for that crystal gives the number of nops required. Since this is NOT usually an integer, later leap counts are required for the macro (long running) accuracy. But the primary adjustment works very well in most cases.

So herewith a table of my RTOS values that work.

These values are quite repeatable, and hence can be used to correct the larger counters (eg for the 4MHz crystal, add 1 to the 5 mSec counter every 225 seconds!)