Post by thread:Dual PICs one Xtal.

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

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_OUTTakeThisOuTdontronics.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

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

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}> > 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 > | | 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 shb7spam_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

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}> > 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: > > > > 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 > > > | > | 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 > @spam@shb7KILLspamcornell.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

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}> 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 > KILLspamscott.mayKILLspamdnr.qld.gov.au <RemoveMEscott.mayTakeThisOuTdnr.qld.gov.au> > spamBeGonescottspamBeGonesmartdata.com.au <TakeThisOuTscottEraseMEspam_OUTsmartdata.com.au> > Û¼¡`¡¼Û¿,üü,¿Û¼¡`¡¼Û¿,üü,¿ > > > {Original Message removed}

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

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

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}> > 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. 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

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

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}> >[ 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 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}> >> > (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 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