Forums

PICmicros instruction counter synchronization

Started by Robert Scott August 25, 2004
Does anyone know if any of the Microchip PICmicros reset their
divide-by-four instruction counter during a hardware reset?  I need to
drive an array of PICs from a single clock, and more than that, I need
all the PICs to be exactly synchronized with respect to their
instruction cycles.  I am hoping that releasing them from reset at the
same time will accomplish this goal.  I am looking primarily at the
low to mid range PICs.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
On Thu, 26 Aug 2004 00:58:25 GMT, the renowned no-one@dont-mail-me.com
(Robert Scott) wrote:

>Does anyone know if any of the Microchip PICmicros reset their >divide-by-four instruction counter during a hardware reset? I need to >drive an array of PICs from a single clock, and more than that, I need >all the PICs to be exactly synchronized with respect to their >instruction cycles. I am hoping that releasing them from reset at the >same time will accomplish this goal. I am looking primarily at the >low to mid range PICs.
Yes it is held in Q1 state during reset (midrange at least). I hope you're going to re-synchronize them from time to time.. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
On Thu, 26 Aug 2004 01:39:23 GMT, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>Yes it is held in Q1 state during reset (midrange at least).
Ah... but upon release of reset (which may have slightly different analog signals arriving internally), will all the parts come out of reset and execute their first Q1 phase on exactly the same, precise external clock tick?
>I hope you're going to re-synchronize them from time to time..
With a circuit to skip any necessary clock pulses needed to re-align their Q1 phases with some primary CPU? Jon
On Thu, 26 Aug 2004 04:57:34 GMT, the renowned Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>On Thu, 26 Aug 2004 01:39:23 GMT, Spehro Pefhany ><speffSNIP@interlogDOTyou.knowwhat> wrote: > >>Yes it is held in Q1 state during reset (midrange at least). > >Ah... but upon release of reset (which may have slightly different analog >signals arriving internally), will all the parts come out of reset and execute >their first Q1 phase on exactly the same, precise external clock tick?
Sure, provided the /RESET edge is properly synchronized with the common external clock, so there are setup and hold times that are not marginal. That's all under his control. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Spehro Pefhany wrote:
> On Thu, 26 Aug 2004 04:57:34 GMT, the renowned Jonathan Kirwan > <jkirwan@easystreet.com> wrote: > > >>On Thu, 26 Aug 2004 01:39:23 GMT, Spehro Pefhany >><speffSNIP@interlogDOTyou.knowwhat> wrote: >> >> >>>Yes it is held in Q1 state during reset (midrange at least). >> >>Ah... but upon release of reset (which may have slightly different analog >>signals arriving internally), will all the parts come out of reset and execute >>their first Q1 phase on exactly the same, precise external clock tick? > > Sure, provided the /RESET edge is properly synchronized with the > common external clock, so there are setup and hold times that are not > marginal. That's all under his control. >>>I hope you're going to re-synchronize them from time to time.. >> >> >> With a circuit to skip any necessary clock pulses needed to re-align their Q1 >> phases with some primary CPU?
Some uC have noise filters on the RESET lines. eg early AVRs were very susceptable to this, and so newer ones have a 2.5us 'spike filter', plus they also have additional coming-out-of-reset delays. ie you will need to test the specific PIC member, and might like to include :- - Lower Freq clock around RESET, to tolerate RC delays - Some means to actually verify LOCK, probably via a Interrupt sync pulse A PLD could manage both tasks.
On Thu, 26 Aug 2004 17:29:06 +1200, the renowned Jim Granville
<no.spam@designtools.co.nz> wrote:

>Spehro Pefhany wrote: >> On Thu, 26 Aug 2004 04:57:34 GMT, the renowned Jonathan Kirwan >> <jkirwan@easystreet.com> wrote: >> >> >>>On Thu, 26 Aug 2004 01:39:23 GMT, Spehro Pefhany >>><speffSNIP@interlogDOTyou.knowwhat> wrote: >>> >>> >>>>Yes it is held in Q1 state during reset (midrange at least). >>> >>>Ah... but upon release of reset (which may have slightly different analog >>>signals arriving internally), will all the parts come out of reset and execute >>>their first Q1 phase on exactly the same, precise external clock tick? >> >> Sure, provided the /RESET edge is properly synchronized with the >> common external clock, so there are setup and hold times that are not >> marginal. That's all under his control. >>>>I hope you're going to re-synchronize them from time to time.. >>> >>> >>> With a circuit to skip any necessary clock pulses needed to re-align their Q1 >>> phases with some primary CPU? > > Some uC have noise filters on the RESET lines. eg early AVRs were very >susceptable to this, and so newer ones have a 2.5us 'spike filter', plus >they also have additional coming-out-of-reset delays.
The PWRT(imer) can be disabled on midrange PICs. THe OST(imer) is automatically disabled when external clock is selected. If there is a spike filter that could cause problems at high clock speeds.
> ie you will need to test the specific PIC member, and might like to >include :- > - Lower Freq clock around RESET, to tolerate RC delays
That's a possibility. The minimum reset width is spec'd at 2usec.
> - Some means to actually verify LOCK, probably via a Interrupt sync pulse > A PLD could manage both tasks.
Sure. Or maybe just a FF is required. I suspect if he had a PLD available he might not be worrying about this particular issue. At higher clock speeds (maybe over 4MHz) those things and more will probably come into play. The delay from the clock rising edge to a port pin changing state is (on one particular chip) as much as 150nsec (typical 50, with no minimum). At 20MHz, each Q state is only 50nsec, so the possible unit-to-unit variation is more than one Q state. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com