This came up a week or so ago & got me thinking.

1.      You should be able to feed 2 (or more) PICs from an external osc. or
even feeding the input side  of the second from the xtal drive (output) side
of the other. Possibly at the highest frequencies it may be dubious but in
the middle range I don't see why not.

2.      Q Cycle synchronising. With the PICs that have PWM output the Q
cycle is available (e.g. the '73s will produce a 10 bit resolution with the
LSB corresponding to a single oscillator cycle). Therefore, it should be
possible to use a PLL to synchronise the two clocks & processors down to
this level. You may need additional synchronisation to achieve an
approximate setting first but after that the Q cycle PLL could take over. As
you say, rise and fall times may need looking at carefully for actual
communication (along with port read/write timing) but it could be worth
looking at, particularly if in the case of parallel processing.

Anyone else any ideas on this?

Richard P


> -----Original Message-----
> From: Thomas Brandon [mailto:tom@PSY.UNSW.EDU.AU]
> Sent: Thursday, October 14, 1999 2:26 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Multiple PIC's, one OSC.
>
>
> Is it possible to run multiple PIC's of one oscillator
> source. I don't want
> them synced or anything (I know the Q cycles will be out),
> it's a board
> space and (possibly) a calibration issue. Have a project that
> will prob.
> require multiple PIC's. Be much nicer to have 1 oscillator. Ideally it
> wouldn't matter how many PIC's were hooked up (but this may
> not be possible
> with reasonable accuracy due to load). The other advantage of
> this is a
> single clock calibration routine. If calibration was an issue
> then all chips
> should be able to be calibrated simultaneously (assuming the
> design kept the
> clock equal at all PICs), thus if the calibration were off slightly it
> should be off for all PICs and there shouldn't be drift between PICs
> (although I don't need to count on this and wouldn't unless absolutely
> neccesary).
>
> I must say, a Q cycle synchronisation capability would be a fantastic
> addition for multi PIC projects. Something like the
> synchronisation scheme
> used in multimaster I2C (from memory) to obtain clock sync.
> The basic idea
> of this would be a Clock hold pin on your PIC's. If this pin
> were held low
> the PIC would not be able to rollover from Q4 to Q1, hence
> you would tie
> this pin of your PIC's together, hold it low for a few cycles
> (after OSC
> startup) to get all the PIC's at the Q4->Q1 transition, then
> let it go high,
> this would cause all PIC's to start at Q1 at the same time.
> Of course this
> relies on all PIC's having identical clocks (have to be
> careful of rise\fall
> times due to capacitances etc), and prob. wouldn't be exactly
> rock solid.
> But If you could hold them steady for a few million cycles
> between resync's
> it would allow extremely fast (theoretically at the clock rate) data
> transfers with no physical synchronisation. Ideally you could
> set up the
> hardware to, do automatic synching (e.g. every X million
> cycles, do a 4
> cycle sync). Don;t know if it'd work in practice but I like
> it in theory.
>
> Tom.
>