> Please refresh me on this by copying in or providing a URL to my old > message. > Bob Ammerman > RAm Systems > (contract development of high performance, high function, low-level > software) First posting: WARNING: Untested code ahead! What we really need is a way to ensure that Timer 1 interrupts every 5000 instructions or 1 millisecond. 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. Here is my suggestion (this code would be in the interrupt handler) 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 Also, sorry this is in ASM, not C, but the same thing should work in C. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) Second posting: The maximum jitter on a PIC is one cycle. This is because some instructions take one cycle and others take two cycles. It is possible to completely dejitter the PIC by examining the value of the timer register in the interrupt handler. For example, I use the following code on an 18C to do exactly that: org 8 ; The next two instructions are used to eliminate jitter on the ; interrupt timing. When the interrupt occurs, it may have to wait ; an extra cycle becuase a two cycle instruction is in progress. ; ; We can tell the difference by looking at the least significant ; bit of TMR2. If the next instruction skips we use 2 cycles, if it ; doesn't skip then we use 3 cycles. The net result is that we add ; a cycle when needed so that we always get to 'dejittered' at the ; exact same time relative to the actual rollover of TMR2! btfsc TMR2,0,A bra dejittered dejittered: Note that this technique should work on all PICs. Also, on an 18C external interrupts are dejittered by the PIC hardware, as noted by this quote from the last paragraph of section 7.0 of the 18C452 datasheet: >For external interrupt events, such as the INT pins or the PORTB input change interrupt, the interrupt latency will be three to four instruction cycles. The exact latency is the same for one or two cycle instructions. I don't believe that external interrupts are dejittered by any prior PIC families. Please correct me if I am wrong. So, my conclusion is that for timer and external interrupts the 18C can process the interrupt with zero jitter. Non 18C chips can do that for timer interrupts but not external interrupts. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) >> ----- Original Message ----- From: "Mike Mansheim" To: Sent: Friday, April 06, 2001 5:50 PM Subject: [PIC]: precise interrupts > Using an F876 with a 10M clock, I'm looking to create a precise 1ms > interrupt using timer 1. I found a thread in the archives that > covered this, and am using Bob Ammerman's suggestion for my first > try (I'll play with the ccp module later). It's working, but it > did raise a couple of questions. > The technique is to add a constant to the timer value in the > interrupt: > - Bob say's to add 65536 - 2500 + fudge, where fudge accounts for the > instructions while the timer is turned off. Since those instructions > are doing a 16 bit add, there is a btfsc statement. Wouldn't this > introduce the possibility of 1 cycle of jitter, depending on whether > or not the branch was taken? > - I have nearly the same code as Bob's example, so there are 6 > instructions between turning the timer off and back on (including the > aforementioned btfsc). I assumed that the fudge would be 6, maybe 7 > to account for the instruction to start the timer back up. When > I check it on a scope, I need a fudge of 10 or 11, depending on the > clock (one running hairs below 10M, the other hairs above). Any idea > why this would be? > > I found another entry (by Bob again), where he talks about completely > eliminating jitter by looking at the lsb of TMR2. Why does this indicate > whether or not a 2 cycle instruction is in progress? Is it the same for > the other timers? > (this was an article of some sort, not part of a thread, as near as I > could tell, so I couldn't pursue it any further in the archive) > Thanks for any help. > << -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.