Yes, if dejittering a single interrupt were the primary goal. However, I believe the issue here was generating interrupts at 1 millisecond intervals with no long-term timing creep. If you just let timer 1 free run then it will, of course, only generate interrupts every 65536 instructions, or every 13.1072 milliseconds. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: Olin Lathrop To: Sent: Thursday, September 28, 2000 2:44 PM Subject: Re: [PIC]: interrupt accuracy > > The problem is that there can be jitter on reaching the interrupt handler > > for the timer. This jitter is caused by 2-cycle instructions, other > > interrupt handlers, and interrupts being disabled at 'task' level. > > > > We can get around the jitter problem by always adding a constant to the > > timer, rather than trying to set it directly. What we are doing is > > effectively advancing time forward the rest of the 65536-5000 instructions > > to get the timer to interrupt again at the right point. > > > > ... > > > > fudge = ...number to account for instructions timer is turned off... > > magic_value = D'65536'-D'5000'+fudge > > > > bcf T1CON,TMR1ON ; turn off timer > > movlw low(magic_value) > > addwf TMR1L,F > > btfsc STATUS,C > > incf TMR1H,F > > movlw high(magic_value) > > addwf TMR1H,F > > bsf T1CON,TMR1ON ; turn it back on > > You could do this an alternate way by leaving timer 1 alone to generate > regular interrupts. You would then do the real interrupt task in the > interrupt service routine after waiting for timer1 to reach some small value > that is at least as large as what the longest latency could be. Let's > assume the longest latency is well less than 256 instructions, which means > you can deal exclusively with TMR1L. You could then use TMR1L to index into > a list of NOPs to de-jitter the interrupt. Timer 1 would always be at a > guaranteed known value (and therefore this would be happening at a regular > time with no jitter) at the end of the NOPs. > > Here's the general concept without some details: > > movwf tmr1l, w ;get timer 1 low byte > addwf pcl ;skip ahead depending on how far along timer 1 is > nop ;NOPs must be in same 256 word block as ADDWF PCL > nop > . > . > nop > nop > ; > ; Timer 1 is guaranteed to be exactly XXXX here. > ; > > > ***************************************************************** > Olin Lathrop, embedded systems consultant in Devens Massachusetts > (978) 772-3129, olin@cognivis.com, http://www.cognivis.com > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu