??? 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 |
Topic | Author | Date |
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 |