Real time clocks, out of the question?

[Dave K.]

The way Kevin's code sets up the interrupt is the best. The other example code posted/referenced all appear to reload the Timer register each time the interrupt is serviced, and the interrupt service latency then becomes an additive value to the timer's period. To some extent, only reloading the upper byte will help avoid the problem, but its easy to avoid the problem all together by just configuring the timer differently. An added bonus is that a few instruction cycles are removed from the ISR by not having to reload the register each time.


Another thing to remember here is that this microcontroller does not have a divide instruction, so including divide operations in an interrupt routine is forcing the microcontroller to execute a lot of instructions on a frequent basis.


Some of the examples provided utilize variables wider than 8 bits, but I didn't notice any cautionary notes for routines that access these variables outside of the interrupt service routine. Because this micrcontroller operates on 8 bits at a time, if a routine were testing a 16 or 32 bit variable and an interrupt occurred in the middle of such a test, the ISR will end up invalidating the foreground operation that it interrupted. No amount of 'volatile' declarations will fix that problem. If the timer value absolutely MUST be greater than 8 bits, then the foreground operations that access this variable must temporarily disable the relevant timer interrupt prior to accessing or manipulating the variable, then re-enable the interrupt after the operation is complete.


I tend to use timers that count down to zero because most microcontrollers are able to test for a zero condition in a single instruction, whereas testing for a specific value tends to use two or more instructions... and this is something which is true for the PIC18.

In other words:

  if (a) {
     do_something();
  }

Will generate fewer instructions than:

  if (a>59) {
    do_something();
  }

As such I tend to write timer ISR's this way:

   // 1ms timer tick ISR

   if (Timer1ms) {
      --Timer1ms;
   }


   if (!(--Timer10)) {
      Timer10 = 10;

      if (Timer10ms) {
         --Timer10ms;
     }

     if (!(Timer100)) {
        Timer100 = 10;

        if (Timer100ms) {
           --Timer100ms;
        }

        if (!(Timer1000)) {
           Timer1000 = 10;

           if (Timer1s) {
             --Timer1s;
          }
       }// !Timer1000
     } // !Timer100
    } // !Timer10
}

In order to use these timers in the foreground code, it is as simple as:

    Timer10ms = 100;    // Start Timer, 100 * 10ms = 1 second


// elsewhere

    if (!(Timer10ms)) {   // if timer expired
       do_something();
    }

Likewise, if you want the expiration of a timer to set an event flag, the ISR could be modified like this:

    if  (Timer) {              // if timer is running
       if (!(--Timer)) {      // decrement, and if it hits zero
          Event_Flag = 1;   // set event flag
      }
    }

So the foreground code could do something like this:

    Event_Flag = 0;  // make sure event flag is cleared
    Timer = 100;      // start timer

// elsewhere

    if (Event_Flag) {
       do_something();
    }

Clearly individual timers can be declared as needed, at whatever the most appropriate resolution for a given function may be. In general, I have found that most timers can be designed to work within an 8 bit value... in other words, if I need a timer that normally needs to run for a 1 second period, that a 10ms resolution timer, loaded with 100 provides more than enough precision.