Searching \ for '[PIC]: precise interrupts' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'precise interrupts'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: precise interrupts'
2001\04\06@175709 by Mike Mansheim

flavicon
face
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: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\04\06@185717 by Bob Ammerman

picon face
Mike,

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)

{Original Message removed}

2001\04\09@120455 by Mike Mansheim

flavicon
face
> 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 removed}

2001\04\09@122802 by Roman Black

flavicon
face
Mike Mansheim wrote:
>
> > Please refresh me on this by copying in or providing  a URL to my old
> > message.
>
> > Bob Ammerman

> 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.
<snip>


Is the interrupt latency reliable? According to
page 28 of the 16c84 datasheet this is 3.25x
the instruction cycle time. Up to 3.25 instructions?

It looks in that diagram like T0IF flag changes,
than takes 1 clock to sense it, then about 5 clocks
to set GIE bit (which causes interrupt) then
when GIE is sensed it flushes address and loads
the 0x0004 address. It says 3.25 instructions
but it is really only two instructions after
timer0 reads 00. Bit confusing really, especially
since they don't mention if this whole sequence
can cause jitter... Is it always 3.25 insts or up
to 3.25 insts??
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\09@130748 by Bob Ammerman

picon face
Ok Mike now I understand your concern:

In the code:

{Quote hidden}

you are concerned that the BTFSC can introduce jitter. This isn't the case
because:

If the skip is taken the BTFSC will take 2 clocks.

If the skip isn't taken the BTFSC will take 1 clock and the INCF TMR1H,F
will take 1 clock.

Your other question dealt with dejittering timer 2 interrupts on the 18C.
This works because there are only two possible values of timer 2 when we get
into the handler, depending on whether a 1 or 2 cycle instruction was
interrupted. You can tell those two values apart by just looking at the
least significant bit of timer 2.

The same technique should work for the other timers.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Quote hidden}

indicate
> > whether or not a 2 cycle instruction is in progress?  Is it the same for
> > the other timers?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\09@155341 by Mike Mansheim

flavicon
face
Bob - thanks for the answer.
Any thoughts on the value of 'fudge'?
Is it empirical or should I be able to explicitly calculate it?

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\09@160152 by Bob Ammerman

picon face
----- Original Message -----
From: "Mike Mansheim" <.....Michael_J_MansheimKILLspamspam@spam@GRACO.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Monday, April 09, 2001 3:46 PM
Subject: Re: [PIC]: precise interrupts


{Quote hidden}

Mike, it should be just the number of instructions from the BCF to the BSF,
in this case 7 (counting just one of the endpoints).

This may not be precisely right if the chip doesn't really start and stop
the timer in one cycle (I seem to remember a two cycle delay on start?).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...