Bob Ammerman <rammerman@ADELPHIA.NET> wrote:

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

I was looking at interrupts as well, in the data sheet of a 16F628 that I was
using for something else.  But when I went to look at the 16C54 (and family)
I didn't see any mention of interrupts at all.  Does it support them?

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