No indeed, the 16C54 family doesn't do interrupts. Sorry. Bob Ammerman RAm Systems ----- Original Message ----- From: "Dan Lanciani" To: Sent: Saturday, February 09, 2002 12:16 PM Subject: Re: [PIC]: minimum uncertainty input->output > Bob Ammerman 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" > |To: > |Sent: Friday, February 08, 2002 10:30 PM > |Subject: Re: [PIC]: minimum uncertainty input->output > | > | > |> "Clint O'Connor" 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" 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