Dan,

I tried to figure out a way to better this and all I could come up with is
to use an interrupt input. In that case uncertainty to the first instruction
of the interrupt routine is 1 instruction time, even if the processor was
executing a 2-cycle instruction. Obviously, this must be the only interrupt
enabled for this technique to work.

Bob Ammmerman
RAm Systems



----- Original Message -----
From: "Dan Lanciani" <ddl@DANLAN.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Friday, February 08, 2002 10:30 PM
Subject: Re: [PIC]: minimum uncertainty input->output


> "Clint O'Connor" <clint@no~.argonauta.~spam.com> wrote:
>
> |Well, *technically* it's only 3 instructions but the real uncertainty is
the
> |total time it takes to make the whole decision loop and get back to the
> |input.
>
> I'm actually trying to establish that something can't be done.  So if I
can
> find the best case uncertainty and it's still too much I will have
succeeded.
>
> There is a box the puts out a 120kHz carrier near the zero-crossing of the
> 60Hz AC power line.  The box contains a simple zero-crossing detector
feeding an
> input of a 4 MHz PIC.  An output of the PIC starts a 120kHz analog
oscillator.
> (Sound familiar? :) It has been asserted that two such boxes will
synchronize
> their 120kHz oscillators well enough that there will be no destructive
> interference.  The uncertainty in the zero-crossing detector already makes
> this impossible, but to demonstrate that requires some basic electronics
and
> math.  The uncertainty in the startup of the analog oscillator almost
certainly
> makes synchronization impossible, but that analysis is even more
complicated.  A
> 3 cycle uncertainty in the PIC by itself represents a significant phase
shift.
> If I can determine that it would not be possible for the PIC to be doing
better
> than this then it should be clear that synchronization is impossible even
if
> there were magic/perfect oscillators and zero-crossing detectors.
>
> |I don't know of a way to do it in less than three
> |unless you copy the input to an output port, e.g. movf PORTA,w | movwf
> |PORTB.
>
> I though about that, but it would work only if you filled code memory with
the
> sequence (and even then it only gets the uncertainty down to 2 cycles).
If you
> put it in a goto loop it would be up to 4 and with some way out of the
loop even
> more.
>
> |"Dan Lanciani" <ddl@DANLAN.NoThiS.COM> wrote in message
> |news:200202080911.EAA11638@ss10.danlan.com...
> |> Given a 16C54 class device, what is the minimum uncertainty/jitter with
> |> which a change in a general input can be propagated to a general
output?
> |> My first thought is that a bit test & skip/goto loop gives a three
> | instruction
> |> cycle uncertainty, but I'm probably missing a trick.  I don't care
(within
> |> reason) about minimizing the latency, just the absolute uncertainty in
the
> |> latency.
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body