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.
The obvious solution to both latency and uncertainty is an external AND
gate. When you want the signal propagated you just turn on the AND
gate, and turn it off when you want to stop. Latency is the delay of
the gate and uncertainty is nil.
If you must do it in software look at what clock phases the bit test and
set operations work on.
|The obvious solution to both latency and uncertainty is an external AND
|gate. When you want the signal propagated you just turn on the AND
|gate, and turn it off when you want to stop. Latency is the delay of
|the gate and uncertainty is nil.
I'm not trying to design a circuit. I'm trying to determine the best that
the firmware in an existing design could be doing. There is no external gate.
|If you must do it in software look at what clock phases the bit test and
|set operations work on.
Could you expand on this? It isn't clear to me how that timing would affect
the uncertainty.
Ah! you are right. The position within the loop of the reads and writes
only affects latentcy, not uncertainty. Sorry about that.
I am a C programmer (CCS PCB). To get better than the obvious few
assembly instructions will require someone more familliar with the
quirks of PIC assembly code than me. I am actually comptemplating my
first project that will require some assembly embedded in the C. I will
have to write the code, count the cycles, THEN choose the crystal
frequency. I have to generate exactly four cycles of exactly 300kHz
with complementry outputs.
|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.
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 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?
At 03:16 PM 2/9/02 -0500, Dan Lanciani wrote:
>Bob Ammerman <@spam@rammermanKILLspamADELPHIA.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?
Celebrating 18 years of Engineering Innovation (1984 - 2002)
.-. .-. .-. .-. .-. .-. .-. .-. .-. .-
`-' `-' `-' `-' `-' `-' `-' `-' `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.
> Bob Ammerman <RemoveMErammermanTakeThisOuTADELPHIA.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) {Quote hidden}
> I didn't see any mention of interrupts at all. Does it support them?
>
> |----- Original Message -----
> |From: "Dan Lanciani" <ddlEraseME.....DANLAN.COM>
> |To: <EraseMEPICLISTMITVMA.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" <RemoveMEddlEraseMEEraseMEDANLAN.NoThiS.COM> wrote in message
> |> |news:RemoveME200202080911.EAA11638spam_OUTKILLspamss10.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 RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body
>
>
I think that it is 3T cycles for the loop you describe. I also think that
if you use a signal source that is synchronous with the PIC clock it will
be better than this.
danlan.com
