Why RETIW is needed to get consistant ISR timing

PJMontey says:

Imagine that the RTCC is your digital alarm clock. If you don't change the alarm time on it, every 24 hours it will go off at the same time. You don't need to do anything special, it just happens. Now suppose that for some reason you need to take some medicine every three hours starting at midnight. What you could do is set your alram clock to go off at midnight. You would then get out of bed, take your medicne, go back to bed, and before falling asleep you'd set the alarm to go off at 3 AM. When the alarm went off, you'd repeat the process, only this time when you got back into bed you'd set the alarm for 6 AM. When the alarm went off at six, you'd do the same thing only this time you'd set it for 9 AM, etc, etc, etc.

Now, the nice thing about this is that no matter how long it took you to get up and take your medicine, when you set the alarm it would be for some absolute time (3 AM, 6 AM, etc) and not a relative time such as "3 hours from now." By doing it this way, you allow yourself flexibility (perhaps you went to the bathroom or ate a snack one of the times you got up to take you rmedicine) in the amount of time your "medicine" task took, but the time between getting up was always a consistent and accurate 3 hours. The key is that the clock kept running and keeping track of time while you got your medicine, and you manually calculated what time to set the alarm for to be three hours from when it woke you up.

This is essentially what the negative number in the RETIW instruction does. When the RTCC interrupt goes off, the CPU jumps to the interrupt code and starts executing it. Depending on what it's doing, sometimes it takes more or less time for the interrupt code to execute depending on things like conditional code paths. The whole time you're executing the interrupt, the RTCC is still going, just like your clock. However, when you get to the end of the interrupt code, there is that nice RETIW with a negative number. That negative number is added to the current value of RTCC (whatever it is) and, just like you setting your alarm to be at the next 3 hour increment, it [b]automatically causes the RTCC value to be jumped ahead so that it goes off at the right time.[/b]

If you specify -26, the RTCC will be jumped ahead so that it generates an interrupt 26 clocks cycles from the time the current one went off. If you specify -100, the time between interrupts will be 100 cycles. As long as your interrupt code takes less time than the number of cycles in your RTCC time interval, you're golden. Your interrupt could take 9 cycles on one interrupt and 62 on the next, but when your interrupt is done and the "RETIW #-100" is executed, the next interrupt will happen 100 clocks from when the current one started. No muss, no fuss. The CPU does all the work needed to make this happen.

Finally, by adding in the prescaler to the RTCC, you can lengthen the amount of time between interrupts. If the RTCC is feed with no prescaler, then every clock cycle causes the RTCC clock to increment (or decrement, I cna't remember if it counts up or down) to the next value. This means your interrupt period can be no longer than 255 clocks long. At 50 MHz, that's a pretty short amount of time. However, if you need more time, set the prescaler to something other than 1:1 and you'll get that amount of time increase. If the prescaler is 4:1, then the RTCC value will get changed every four clocks, meaning that your maximum of 255 is now 255 * 4 = 1020 cycles.

  .