Searching \ for 'TMR0 Latency' 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/index.htm?key=tmr0+latency
Search entire site for: 'TMR0 Latency'.

Truncated match.
PICList Thread
'TMR0 Latency'
1999\10\17@221306 by Thomas Brandon

flavicon
picon face
I am looking at a project requiring a very tight timing loop. Ideally I
would have it accurate to a single instruction but maybe 1 instruction error
could be tolerated. What delays are present in a TMR0 interrupt on overflow
driven loop. The basic idea would be (assuming TMR0 overflow is the only
enabled interrupt):
delay EQU ...
int_latency EQU ...

ORG 0x004
   MOVF delay
   SUBLW int_latency
   MOVWF TMR0

where delay is the number of cycles (if prescaler = 1:1) and int_latency is
the total latency of the interrupt occuring and of setting TMR0. In this
case int_latency would be 3 inst (MOVF-MOVWF) + the delay for the interupt
to fire + the delay for the setting of TMR0. From reading the MChip docs I
think that there is a 4 inst delay for the interrupt to fire and actually
execute 0x004 for real, and a 2 inst delay for the update of TMR0 to kick
in. Hence I would set int_latency to 4 + 2 + 3 = 9inst. Is this correct? Is
there any jitter in the internal interrupt handling?

1999\10\18@091923 by paulb

flavicon
face
Thomas Brandon wrote:

> I am looking at a project requiring a very tight timing loop.

 If so, I'd avoid interrupts like the plague!

> Ideally I would have it accurate to a single instruction but maybe 1
> instruction error could be tolerated.

 The plot thickens!

> What delays are present in a TMR0 interrupt on overflow driven loop.
> The basic idea would be (assuming TMR0 overflow is the only enabled
> interrupt):

 The delays are:
1} an extra cycle if the presently executed instruction modifies PC.
2} Interrupt latency - an interrupt modifies PC too!
3} context saving.

> ORG 0x004
>     MOVF delay
>     SUBLW int_latency
>     MOVWF TMR0

 No context saving!  Not workable.  Need to save STATUS, W, maybe other
things.  May need to clear bank select to access TMR0.

> where delay is the number of cycles (if prescaler = 1:1) and
> int_latency is the total latency of the interrupt occuring and of
> setting TMR0.  In this case int_latency would be 3 inst (MOVF-MOVWF) +
> the delay for the interupt to fire + the delay for the setting of
> TMR0. From reading the MChip docs I think that there is a 4 inst delay
> for the interrupt to fire and actually execute 0x004 for real, and a 2
> inst delay for the update of TMR0 to kick in. Hence I would set
> int_latency to 4 + 2 + 3 = 9inst. Is this correct?

 Sounds plausible.  Honestly, I would take that as an indication to
forget using an interrupt for this purpose.

> Is there any jitter in the internal interrupt handling?

 Yes, depends on whether it happens to hit a branch instruction.

 It sounds like you plan to enter a tight loop and use interrupts to
do your timing.  That sounds crazy to me.  Unless you context save, it
will be very difficult to avoid crashing the loop badly.  The only
conditional you could use within the loop is BTFSx.  The loop couldn't
do any useful processing anyway.

 As such, you'd be far better off to do the timing in the loop,
wouldn't you?  Latency would be guaranteed constant and about six
instructions at most.

 Like all such mind-bending problems, I would suggest you disclose your
real objective for suggestions.  There are techniques posted for coding
single-cycle resolution counting loops IIRC.
--
 Cheers,
       Paul B.

1999\10\18@192731 by Thomas Brandon

flavicon
picon face
---- Original Message -----
From: Paul B. Webster VK2BZC <spam_OUTpaulbTakeThisOuTspamMIDCOAST.COM.AU>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Monday, October 18, 1999 11:17 PM
Subject: Re: TMR0 Latency


{Quote hidden}

That's purposeful, there's too much to do in the given time to waste 6inst.
saving context, everything would happen in the TMR0 interrupt to prevent
context saves, sorry for not making clear.

{Quote hidden}

Not so much interrupts, just PIC interrupts. Scenix interrupts with
"determnistic jitter free 60ns int., 100ns ext" interrupts with hardware
context saves would be much more acceptable.

> > Is there any jitter in the internal interrupt handling?
>
>   Yes, depends on whether it happens to hit a branch instruction.
That could be a problem. I don't need to do anything in the main code, but
to infinitely loop I need lots of jumps (well, just one, but it's executed a
lot), so there would be a lot of 2 cycle inst.'s.

{Quote hidden}

The application is multi channel serial comms. As such, the task must be run
with accurate timing but there is a lot to do in the given loop time and the
amount of processing varies dramatically (a lot of the time the loop will do
nothing as no serial lines are active). Hence, the time taken to calculate a
variable delay and implement it is a big problem.

Anyway, as suggested above, the scenix's interupts and speed are much more
suited to this task so I believe I will switch.

Thanks,
Tom.

1999\10\18@195305 by Dennis Plunkett

flavicon
face
At 09:31 19/10/99 +1000, you wrote:
{Quote hidden}

This may sound crazy for a PIC but is common code practice in a DSP type
aplication, e.g. G728 to G711 conversion where processing is performed in
blocks, but data is input and output on an 8kHz cycle




{Quote hidden}

Yeh go there.
You say that timing is critical, well maybe, but it is realy only is on
receive, which is asynchronus and all transmit may be sychronus to each
other. The main problem is the speed of the incomming data. Sampling at 3
times the expected incomming data rate will remove the need to trigger an
interrupt and line up the receiver, however the second method uses less
processing power as you can then start sampling in the expected middle of
the data stream etc.

Whatever, enjoy

Dennis

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