Hi Adam,

I haven't tried any tests unfortunately, but when this subject came up a
couple of years ago, I suggested the following (I guess I should try it
sometime ;-):

Let's say you want to synchronize PIC A and PIC B. For an example, lets'
say you have a third PIC (PIC C) to accomplish this. Here's how:

Hook PIC A's clock in to a multiplexer, and PIC B's clock in to another
MUX. Connect the clock signal to one of the MUX inputs on both MUXes. Hook
one port pin of PIC C to one of the other MUX inputs, and another port pin
to the other. The select lines for the MUXes go to port pins on PIC C, too.
You also have a port pin going from each of A and B to pins on C.

First, you reset PIC C. After PIC C's program begins to run, then you reset
A and B. A and B's programs start with a clock sync routine which consists
of code to set a port pin to low and to an output, and then sets it high
after a few NOPs. This code is followed by the normal program.

PIC C's code does  the following: First, it sets both MUXes to the state
where the connect A and B's clock in pins to C's port pins. Then, it pulses
the pin connected to A until it sees A's output pin go high. C then stops
pulsing A and does the same procedure to B. Now, A and B are in the same Q
cycle (because a change in pin state always occurs in the same Q cycle). C
now simultaneously sets both MUXes to pass the clock through. You might
need to do something to ensure that the
first clock pulse isn't too short, but probably not.

You could actually do this with only two PICs, but the procedure is more
complicated (you would set one up to be the master. It would perform a
function similar to C, and as long as the prop. delay of the MUX (and PIC
output pin) was short enough, the master and slave would end up in the same
Q cycle because the command to change the port pin hooked to the MUX would
actually make the pin become high in the same Q cycle as the state that the
second PIC was waiting in.)

All of this should work for SXs, too. Things are even easier for an SX
running in full pipelined mode because one instruction gets executed per clock.

Sean



At 03:45 PM 9/22/00 -0400, you wrote:
>Ok, I understand this subject has been hashed before, but I've not seen any
>follow ups...  (see the 6/24/99 Thread "Dual pics, one xtal?")
>
>Can one reset two PICs such that they come up in the same state?  I'm
>interested
>in real-world tests.
>
>These things are good down to DC.  Has anyone taken two chips with the same
>program and run them on a hand operated clock?  Here is what I'm proposing:
>
>Put two chips on the same clock, which is operated by a clean debounced push
>button with a flip flop (one push --> high, next push __> low, etc).  Have
>another clean pushbutton operate both resets.  Program the chips with the same
>program (perhaps a blinking LED).  Now, reset them, and press the clock button
>until an LED lights on one chip.  Do both LEDs come on at the same time in the
>same clock cycle and transition?
>
>Perhaps use another PIC to clock the two PICs and check the output, slowly
>ramping up the speed of the clock.
>
>I suspect the power on reset would mess things up with a fast clock (but
>shouldn't matter if done by hand).  the watchdog would have to be handled
>eternally (or at the least an external reset chip would be needed so either
>processor could reset both).
>
>Since these are static CMOS chips, I don't see any potential problems, but all
>of the threads on them previously have ended with "It probably wouldn't work".
>
>The previous thread also suggested a tirtiary processor which controlled the
>clocks to both pics, waiting for the first one to come to a predefined state,
>then holding back until the second caught up.
>
>Has anyone actually performed any of these tests?
>
>-Adam
>
>The other side of this email contains the lotto numbers for the next ten
>years.
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu