Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
12/09/05 09:52
Read: times


 
#104958 - other method
Responding to: ???'s previous message
Indeed, the method given in tutorial is inherently unprecise (does not take into account the variable interrupt latency) (and yes, the (partial) compensation should be +5).
While Peter gives a nice example how the interrupt latency can be compensated, there are also another methods how to achieve precise timing using the timer interrupts. One of them is to use the autoreload mode (8-bit at timers 0 and 1, 16-bit at timer2 on '52). Other is to let the timer run freely and overflow at FFh (or FFFFh) not attempting the interrupt to occur at 1 second or an integer fraction of 1 second; and for real time purposes recalculate the accumulated counter accordingly (e.g. if in "the vanilla" at 12MHz a 16-bit overflow occurs at a 65536us rate, and a counter is incremented in the ISR, then multiply the value of counter by 0.065536 to get the current time in seconds). An another trick is to reload only the high byte of timer in 16-bit (or 13-bit) mode (making sure the reload occurs within 256 cycles after the overflow). With suitable combination of crystal frequency and reload value an integer fraction of 1 second can be achieved in this way.

Jan Waclawek

List of 7 messages in thread
TopicAuthorDate
real time clock            01/01/70 00:00      
   Yes, it is rubbish            01/01/70 00:00      
      other method            01/01/70 00:00      
         priorities            01/01/70 00:00      
            Latency is always variable            01/01/70 00:00      
   Latency            01/01/70 00:00      
      The Bible            01/01/70 00:00      

Back to Subject List