The Scenix SX has jitter-free response to internal and external interrupts,
and also takes care of the context saves. Just 3 cycle interrupt response and
3 cycle return from interrupt, both are deterministic.

What serial rate do you need?

Stephen

"Paul B. Webster VK2BZC" <paulb@MIDCOAST.COM.AU> wrote:
> 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.


____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1