Searching \ for 'Dual PICs one Xtal.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=xtal
Search entire site for: 'Dual PICs one Xtal.'.

Truncated match.
PICList Thread
'Dual PICs one Xtal.'
1999\06\24@203315 by wruehl

flavicon
face
PICsters,
  What is the best way to have two 16F84's on the same board share
the same crystal? Can the chips share the crystal in parallel? or is
there
a more elegant approach?

Bill Ruehl

1999\06\24@224944 by May Scott

flavicon
picon face
I can't imagine the two oscillators getting along very well, but I could be
wrong.  The safest be would be to take the oscillator output (wired as per
normal for one PIC), and buffer this through a 74HC14 or vaguely similar,
and feed it's output to the clock in on the other PIC.  I've done this with
the 8051 types, and it works a charm...

Till later,
Scott.
Û¼¡`¡¼Û¿,üü,¿Û¼¡`¡¼Û¿,üü,¿
Scott May.
Hydrographic Support
1345 Ipswich Road
Rocklea.
Ph      +617 3892 5610
Fax     +617 3848 5191
spam_OUTscott.mayTakeThisOuTspamdnr.qld.gov.au <.....scott.mayKILLspamspam@spam@dnr.qld.gov.au>  
scottspamKILLspamsmartdata.com.au <.....scottKILLspamspam.....smartdata.com.au>
Û¼¡`¡¼Û¿,üü,¿Û¼¡`¡¼Û¿,üü,¿


               {Original Message removed}

1999\06\24@235007 by Mark Willis

flavicon
face
William Ruehl wrote:
>
> PICsters,
>    What is the best way to have two 16F84's on the same board share
> the same crystal? Can the chips share the crystal in parallel? or is
> there
> a more elegant approach?
>
> Bill Ruehl

 One question:  Why not just use 2 crystals or 2 ceramic resonators?

 2 easy possibilities;

 a)  Put the F84's fairly close to each other, connect crystal across #
1 F84 with caps as per normal, connect the Osc2/ClkOut pin of that one
to the Osc1/ClkIn pin of #2 (treating it like an external oscillator.)
Want the Osc. trace from Pic #1 to #2 short, here.  And stray
capacitance from that lead may slightly affect the frequency of
oscillation of the Xtal.  So if you buffer this output through a gate,
that improves things (perhaps a spare inverter?)  If careful, you can
skip the gate.  YMMV.

 b)  BETTER: Set up a standard inverter-style oscillator & use that to
drive both PICs, through a second inverter, into Osc1/ClkIn.  See the
data sheets for how to make such an oscillator <G>

 Also could just use a clock oscillator module & drive both F84's off
that.

 A caveat:  You aren't guaranteed that the 2 PICs are running on the
same clock phase, they should stay at a constant skew, though.  So don't
assume this!  (i.e. When Pic #1 is in the Q1 state, Pic # 2 may be in
any of the Q1, Q2, Q3 or Q4 states, for all we know.  So if you want to
pass data back & forth quickly, you cannot do it on a 2-instruction loop
etc. <G>)

 Anyone on list know of any way to Q-state synchronize a pair of F84's,
please let ME know!  Though I suppose you could do it with starting with
a slow clock, watching for a rising edge on one output, and holding the
first PIC to raise that edge in "hold" (i.e. no clock state change)
until the other PIC's output goes high, then speeding up both PIC clock
rates (use a programmable clock divider system, for all this.)  Fancy
hard way to do an un-necessary thing, methinks <G>

 Mark

1999\06\25@023107 by Don McKenzie

flavicon
face
William Ruehl wrote:
>
> PICsters,
>    What is the best way to have two 16F84's on the same board share
> the same crystal? Can the chips share the crystal in parallel? or is
> there
> a more elegant approach?

Can I run two PICs from a single clock?

Quote:"
Yeah... There are two ways:

If you have an external clock (with an oscillator and everything... not
just a crystal or ceramic resonator), you can obviously run its signal
to the CLKIN (OSC1) pin of each PIC.

If you're using the PIC's built-in oscillator with an external crystal
or ceramic resonator, you can simply tie one PIC's CLKOUT (OSC2) pin to
the other's CLKIN, then put the crystal/resonator between the two
remaining OSC pins. Some experimentation with capacitor values may be
necessary.
Un-quote:"

and that come from http://pweb.netcom.com/~fastfwd/answers.html
which is a FAQ page set up by Andrew Warren (Fast Forward Engineering)
quite some time ago.

I can't remember the last time I saw one of his messages.
The old MC BBS crew are thinning out.

Don McKenzie  EraseMEdonspam_OUTspamTakeThisOuTdontronics.com http://www.dontronics.com

Don's Download Dungeon:   http://www.dontronics.com/download.html
Australian Electronics Ring http://www.dontronics.com/aering.html
Win $500USD Cash. Micro design contest:  http://www.simmstick.com

1999\06\26@050208 by Roland Andrag

flavicon
face
>  Anyone on list know of any way to Q-state synchronize a pair of F84's,
>please let ME know!  Though I suppose you could do it with starting with
>a slow clock, watching for a rising edge on one output, and holding the
>first PIC to raise that edge in "hold" (i.e. no clock state change)
>until the other PIC's output goes high, then speeding up both PIC clock
>rates (use a programmable clock divider system, for all this.)  Fancy
>hard way to do an un-necessary thing, methinks <G>


Mark, if you have a way of checking whether the chips are on the same Q
cycle, you can just keep resetting one chip until it starts up in the same Q
cycle.  ie. give one micro contol over the other's Mclr pin...

Cheers
Roland

1999\06\26@122703 by Mark Willis

flavicon
face
Roland Andrag wrote:
>
> >  Anyone on list know of any way to Q-state synchronize a pair of F84's,
> >please let ME know!  Though I suppose you could do it with starting with
> >a slow clock, watching for a rising edge on one output, and holding the
> >first PIC to raise that edge in "hold" (i.e. no clock state change)
> >until the other PIC's output goes high, then speeding up both PIC clock
> >rates (use a programmable clock divider system, for all this.)  Fancy
> >hard way to do an un-necessary thing, methinks <G>
>
> Mark, if you have a way of checking whether the chips are on the same Q
> cycle, you can just keep resetting one chip until it starts up in the same Q
> cycle.  ie. give one micro contol over the other's Mclr pin...
>
> Cheers
>  Roland

 I think something where we don't assume startup delays will be
identical, but just synchronize after startup, would be easier.

 I thought about using a shift register to capture that "Q Phase
difference", too messy;

 I think the easiest way to do this is to use a gate to drive #2's
ClkIn and to at one point in software have #2 stop itself at a known
state - use an EDGE trigger - then have #1 release #2's clock, as all IO
pin writes occur on the same Q state, this should work just fine.  I'll
play with it later <G>

 Mark

1999\06\26@145048 by Sean Breheny

face picon face
Mark,

Earlier you had said that the reason for doing this (or at least one
reason) was to be able to exchange data between two PICs in a two-cycle
loop. Could you please explain how this would work?

Even just a loop that does nothing takes at least two cycles,so I don't see
how it is possible to exchange data without adding at least one instruction.

Thanks,

Sean

At 09:24 AM 6/26/99 -0700, you wrote:
{Quote hidden}

| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
shb7spamspam_OUTcornell.edu ICQ #: 3329174
________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

1999\06\26@222437 by Mark Willis

flavicon
face
Well, no, not two cycles for the whole loop, two instructions for the
*innards* of the loop though;  If (and only if) you Q-state synchronize
two PICs, you can write to an output pin in one instruction cycle, then
READ it on the other PIC on the next instruction cycle, (you could
potentially do full duplex bi-directional I/O here, on a 16C66 or the
like.)  That's possibly pushing it, if you have any serious lead
capacitance on the lines between the two PICs, of course.  Just
something I've been thinking about because, knowing one project,
something that seriously silly may be necessary <G>  I'll try to avoid
it, simple always is GOOD, but if I need it for some reason, it's good
to have thought way ahead & have a workable approach.  ("Brain Aerobics"
here, not seriously considering using it tomorrow <G>)  I2C is probably
a better idea for most anything you want to do.

 Mark

Sean Breheny wrote:
{Quote hidden}

1999\06\28@110717 by Dan Larson

flavicon
face
On Sat, 26 Jun 1999 09:24:50 -0700, Mark Willis wrote:

>Roland Andrag wrote:
>>
>> >  Anyone on list know of any way to Q-state synchronize a pair of F84's,
>
>  I think something where we don't assume startup delays will be
>identical, but just synchronize after startup, would be easier.
>

I would like to make an observation here, if I may...

What about the startup timer?  If they are being used wouldn't they
introduce some variation in startup time since they are based on
an internal RC clock?

Dan

1999\06\29@014944 by root

flavicon
face
Hi,
I tied the "master" PIC's CLKOUT to the "slave" PIC's CLKIN directly, and
both ran w/o any problems.
I hope this helps.
Imre


On Fri, 25 Jun 1999, May Scott wrote:

{Quote hidden}

>                 {Original Message removed}

1999\06\29@030016 by Nicholas Uloth

flavicon
face
At 07:54 29/06/99 +0200, you wrote:
>Hi,
>I tied the "master" PIC's CLKOUT to the "slave" PIC's CLKIN directly, and
>both ran w/o any problems.
>I hope this helps.
>Imre

Did the extra loading make any difference to the frequency though ?
Even a small error might be a problem when one is implmenting a real time
clock.

Nic

1999\06\29@123926 by Mark Willis

flavicon
face
Dan Larson wrote:
>
> On Sat, 26 Jun 1999 09:24:50 -0700, Mark Willis wrote:
>
> >Roland Andrag wrote:
> >>
> >> >  Anyone on list know of any way to Q-state synchronize a pair of F84's,
> >
> >  I think something where we don't assume startup delays will be
> >identical, but just synchronize after startup, would be easier.
> >
>
> I would like to make an observation here, if I may...
>
> What about the startup timer?  If they are being used wouldn't they
> introduce some variation in startup time since they are based on
> an internal RC clock?
>
> Dan

 Dan, startup delays are caused BY the startup timer...  I just said
that, in my perhaps unique way.

 (How can a program run - as NO code runs while the startup timer is
counting, anyways?  <EG>)

 So I just suggested, sync up AFTER both pics have gone through the
startup delay, through software sending an edge trigger to sync things
up.

 (Does someone else's software run while the startup timer's running?
Evil Minds want to know <G>  How do they DO that?)

 Mark, being weird this AM

1999\06\29@132820 by Dan Larson

flavicon
face
On Tue, 29 Jun 1999 09:37:38 -0700, Mark Willis wrote:

>
>  Dan, startup delays are caused BY the startup timer...  I just said
>that, in my perhaps unique way.
>
>  (How can a program run - as NO code runs while the startup timer is
>counting, anyways?  <EG>)
>

Depends on how low Vss is <BG>

>  So I just suggested, sync up AFTER both pics have gone through the
>startup delay, through software sending an edge trigger to sync things
>up.

I just can't see how the clock Q's will align. I guess I'd have to ping
an output on each and scope them for phase jitter, sync'ing on MCLR of
the first PIC being reset repeatedly with a 555 timer or something.

But if I was sure that the leading edge of MCLR going high resets the Q
cycle counter of the clock, perhaps I can see the first PIC holding down
the reset of the second PIC to sync. But, even if they can be made to sync
consistently it still may not be on the same Q cycle.  I wish there were
some more timing diagrams that showed Q cycle in relation to MCLR.

>
>  (Does someone else's software run while the startup timer's running?
>Evil Minds want to know <G>  How do they DO that?)
>

If it is on someone else's PIC, it does!

>  Mark, being weird this AM
>

Dan

1999\06\29@135106 by Mark Willis

flavicon
face
Dan Larson wrote:
>
> On Tue, 29 Jun 1999 09:37:38 -0700, Mark Willis wrote:
>
> >
> >  Dan, startup delays are caused BY the startup timer...  I just said
> >that, in my perhaps unique way.
> >
> >  (How can a program run - as NO code runs while the startup timer is
> >counting, anyways?  <EG>)
> >
>
> Depends on how low Vss is <BG>

 Don't think so, !TO bit wouldn't make sense otherwise!  Quoth the F84
docs,

[ Power-up Timer (PWRT), which provides a
[ fixed delay of 72 ms (nominal) on power-up only. This
[ design keeps the device in reset while the power supply
[ stabilizes.

 Note the "Keeps the device IN RESET" there.  Sure, once that 72 ms is
over, the code'll start running, but not UNTIL then!  <G>

{Quote hidden}

 Manual example - Think of two pics run at 1 Hz.  Stop the clock to the
first one that raises RB7 high, until the other PIC also raises RB7,
then let both continue - they're synchronized.  Proper gating should let
them do this at far faster clock speeds than 1 Hz, of course.  I'll do
that later though, have an appointment today <G>

> >  (Does someone else's software run while the startup timer's running?
> >Evil Minds want to know <G>  How do they DO that?)
> >
>
> If it is on someone else's PIC, it does!

 How does anyone's software run while the PIC's held in reset?  Hmmm...

> >  Mark, being weird this AM
> >
>
> Dan

 Mark

1999\06\29@150553 by Dan Larson

flavicon
face
On Tue, 29 Jun 1999 10:49:40 -0700, Mark Willis wrote:

>Dan Larson wrote:
>>
>> On Tue, 29 Jun 1999 09:37:38 -0700, Mark Willis wrote:
>>
>> Depends on how low Vss is <BG>
>
>  Don't think so, !TO bit wouldn't make sense otherwise!  Quoth the F84
>docs,
>

Oh, I was hoping to get a chuckle at the expense of the poor
PIC that has gone crazy because the supply voltage is too low.
IIRC, The 18F84's don't have BOR yet..

>[ Power-up Timer (PWRT), which provides a
>[ fixed delay of 72 ms (nominal) on power-up only. This
>[ design keeps the device in reset while the power supply
>[ stabilizes.
>
>  Note the "Keeps the device IN RESET" there.  Sure, once that 72 ms is
>over, the code'll start running, but not UNTIL then!  <G>

But, what is the timing of the trailing edge of reset in relation to
the Q cycle?   Will execution begin on the first Q1 after reset goes high
while transient Q2,Q3, and Q4's might pass before the next Q1, depending on
the timing of MCLR, OR, will reset actually make the internal clock reset the
Q cycle to Q1? IOW, is the Q cycle synchronous with a free-running Q counter,
or synchronous with the MCLR trailing edge?



I never *thought* code could run while in reset.  A failed attempt at
some subtle humor backfired on me here twice with this!  If it were
true it would be the answer to all computing speed problems since
any number of instructions executed while in reset greater than
zero would result in an instruction per clock cycle ratio of infinity!

>
>  Manual example - Think of two pics run at 1 Hz.  Stop the clock to the
>first one that raises RB7 high, until the other PIC also raises RB7,
>then let both continue - they're synchronized.  Proper gating should let
>them do this at far faster clock speeds than 1 Hz, of course.  I'll do
>that later though, have an appointment today <G>
>

I'd really like to see the results of something like this.  I've thought
of doing it before with chains of processors in robot appendages.

>> >  (Does someone else's software run while the startup timer's running?
>> >Evil Minds want to know <G>  How do they DO that?)
>> >
>>
>> If it is on someone else's PIC, it does!
>
>  How does anyone's software run while the PIC's held in reset?  Hmmm...
>

If the PIC in reset is not the PIC on which the software is running <G>.

I'll stop trying to be funny now.  I have made a disaster out of this.

But seriously, I'd really like to know for sure if Q cycle sync can
really be done.  The parallel processing potential is interesting.

Dan

1999\06\29@192124 by Mark Willis

flavicon
face
Dan Larson wrote:
>
> On Tue, 29 Jun 1999 10:49:40 -0700, Mark Willis wrote:
>
> >Dan Larson wrote:
> >>
> >> On Tue, 29 Jun 1999 09:37:38 -0700, Mark Willis wrote:
> >>
> >> Depends on how low Vss is <BG>
> >
> >  Don't think so, !TO bit wouldn't make sense otherwise!  Quoth the F84
> >docs,
> >
>
> Oh, I was hoping to get a chuckle at the expense of the poor
> PIC that has gone crazy because the supply voltage is too low.
> IIRC, The 18F84's don't have BOR yet..

 True <G>

{Quote hidden}

 I think the answer here is, "Ask your friendly local Scott Fink or
friendly local FAE."  My guess is that you start with Q4 having taken
place while the device was in reset (instruction fetch already's
happened), then start on Q1, but I'd be the first to admit that this is
a "hallucination", AKA Wild-ass GUESS!  <G>

> I never *thought* code could run while in reset.  A failed attempt at
> some subtle humor backfired on me here twice with this!  If it were
> true it would be the answer to all computing speed problems since
> any number of instructions executed while in reset greater than
> zero would result in an instruction per clock cycle ratio of infinity!

 i.e. You pulled a Mark <G>

> >  Manual example - Think of two pics run at 1 Hz.  Stop the clock to the
> >first one that raises RB7 high, until the other PIC also raises RB7,
> >then let both continue - they're synchronized.  Proper gating should let
> >them do this at far faster clock speeds than 1 Hz, of course.  I'll do
> >that later though, have an appointment today <G>
> >
>
> I'd really like to see the results of something like this.  I've thought
> of doing it before with chains of processors in robot appendages.

 Data routing between Robot PICs, yep <G>  Smart serial processing with
one character latency in the F84 types of things, spring to mind...

{Quote hidden}

 Hey, it's about time someone ELSE's humor got misunderstood!  <G>

 I really think it can with identical PICs, but no time to test it
right now.  Moving soon, probably, so I need to get set to do that in
between job hunting calls.  I figure that identical instructions (output
a '1' to RB7 etc.) always will happen on the same clock state, just a
quick run with a very slow clock & a dual trace O-Scope should tell us
whether the output pin changes state near a rising or a falling edge,
then you just hold that clock "in place" until the other PIC's RB7
rises, then lock 'em.  Cannot see anything wrong with that method.  I'll
test it later, though.

 Mark

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...