Shop OBEX P1 Docs P2 Docs Learn Events
(Better) Crystal Sharing — Parallax Forums

(Better) Crystal Sharing

MacTuxLinMacTuxLin Posts: 821
edited 2012-02-10 11:17 in Propeller 1
Hi All,

Please let me know if this is workable? Thanks.

CrystalInverter.png


Updated: I have added the inverter according to Phil's advice.
CrystalInverter.png
611 x 447 - 32K

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-31 20:49
    No, it won't work. The signal to the crystal gets inverted twice, so it's no longer across an inverter and won't be driven to oscillation. (That's just one reason; there are probably others that come into play, should you add an external inverter..)

    -Phil
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-01-31 21:03
    Connect the crystal between XO and XI on one prop, and connect XO on that prop to XI on the other.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2012-01-31 21:24
    Thanks Phil & Circuitsoft. Got it. I'm trying to minimise onboard components and save resources in using a prop to generate a sync to the next prop's XI.
  • HShankoHShanko Posts: 402
    edited 2012-01-31 23:06
    For one application with 2 Prop 1s, I used one crystal on one Prop, and used a counter to output 5 MHz on one pin. Yes, uses one pin up this way. I wasn't sure if I could reliably connect the 5 MHz square wave to x1 pin on the 2nd; didn't even experiment with that scheme. I had enough spare counters and pins to spare.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2012-01-31 23:53
    I used the xtal out to xtal in of another Prop, once, to save that second xtal but due to the slightly modular way I built it I had left on both individual reset buttons. I then found that all seemed ok unless the "master" Prop (Blade2)was reset without the "slave" (PropCMD) one then the Xtal oscillator would stop whilst the "master" rebooted ON RCFAST. This left the "slave" clockless for a bit and when the (12MHz) xtal started up again it wouldn't come out of the crash.

    As soon as the two Props resets were commoned then all was ok. I did wonder about if the slave's RCFAST was a lot faster than the master's if the same would occure but swapping around the Props didn't seem to change anything
  • MacTuxLinMacTuxLin Posts: 821
    edited 2012-02-01 00:54
    Thanks Harley. I had been doing as you've mentioned but the current project has different requirement which Toby seems to have hit the nail.
    Toby Seckshund wrote: »
    I used the xtal out to xtal in of another Prop, once, to save that second xtal but due to the slightly modular way I built it I had left on both individual reset buttons. I then found that all seemed ok unless the "master" Prop (Blade2)was reset without the "slave" (PropCMD) one then the Xtal oscillator would stop whilst the "master" rebooted ON RCFAST. This left the "slave" clockless for a bit and when the (12MHz) xtal started up again it wouldn't come out of the crash.

    As soon as the two Props resets were commoned then all was ok. I did wonder about if the slave's RCFAST was a lot faster than the master's if the same would occure but swapping around the Props didn't seem to change anything

    Thanks Toby. I planned to test it tomorrow as I was worried what you've mentioned might happen. The first Prop1 would have a possibility to reboot while the second Prop1 is in the mist of an operation. That's why I could not use the usual setup.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2012-02-08 09:09
    After further testing, I'd go with Circuitsoft's suggestion. No extra component needed.

    Thanks.
  • SONIC the HedgehogSONIC the Hedgehog Posts: 321
    edited 2012-02-08 09:36
    That's pretty awesome to use a setup with two propellers! The possibilities are ever increasing, but am application that requires a master-slave relationship sounds intense and very demanding.
  • groggorygroggory Posts: 205
    edited 2012-02-08 11:29
    I'd add one note here.

    I'd tie a line from the prop that has both sides of the crystal connected to the reset line of the prop with the crystal disconnected. Have the beginning of your program on the 'master' prop reset the slave prop. That way if the master gets reset the slave won't go crazy when it loses its clock source.
  • Mike GreenMike Green Posts: 23,101
    edited 2012-02-08 11:32
    The slave won't "go crazy" when its clock source stops. It'll just stop. A Propeller has to have some kind of clock to function. It can use its internal clock, but, if it's using an external clock of any kind and those clock pulses stop coming, everything comes to an immediate stop. It can't switch over to its internal clock if the external clock stops.
  • groggorygroggory Posts: 205
    edited 2012-02-08 13:15
    Mike Green wrote: »
    The slave won't "go crazy" when its clock source stops. It'll just stop. A Propeller has to have some kind of clock to function. It can use its internal clock, but, if it's using an external clock of any kind and those clock pulses stop coming, everything comes to an immediate stop. It can't switch over to its internal clock if the external clock stops.

    What does the DI line on the master look like from the period of reset to up and running?

    The way I see it, having the slave stop, then start will only happen cleanly and with proper timing if the DI input outputs say... 5MHz one moment, then for the next x time it outputs nothing (or low), then starts outputting 5MHz again. At no time is it allowed to output a different frequency during the boot phase.

    :-) This solution may end up being super simple if it's a clean transition.

    Also, could I slave say... 4 propellers to a single propeller's DI line? I imagine each propeller won't pull much from it.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-02-08 13:17
    You'll want to connect the XI on several props to the XO on the master prop. XO is a logic output, but XI is an input that is only driven by the crystal, and loading it down with multiple props could destabilize the oscillator.
  • Mike GreenMike Green Posts: 23,101
    edited 2012-02-08 13:33
    The oscillator is turned off when the Propeller is reset. You have to turn it on explicitly which the bootloader does if the program in EEPROM requires it (_CLKMODE)

    You really don't want to connect XO to several other Props' XI inputs. XO is not designed to drive anything other than a single crystal. The additional capacitance of the PCB traces will load it down and the oscillator may not start up reliably. The extra capacitance may also decrease the oscillation frequency of the crystal. At the very least, you'll need some kind of buffer mounted close to the XO pin along with the crystal and keep the traces as short as possible.
  • LeonLeon Posts: 7,620
    edited 2012-02-08 13:53
    I once ran several AVRs from the same clock, using an oscillator module. They typically have an output buffer with a large drive capability.
  • jmgjmg Posts: 15,183
    edited 2012-02-08 14:07
    Something like a 2GU04 is the best solution, if you do not want a Osc Module.
    (or the more focused, but not quite as cheap/multisourced, 74AUP1Zxx)

    One Gate manages the Xtal, (no pauses on RST) and the other Gate buffers and speeds up the edges a little, for all the driven Prop XI's
  • groggorygroggory Posts: 205
    edited 2012-02-08 14:16
    jmg wrote: »
    Something like a 2GU04 is the best solution, if you do not want a Osc Module.
    (or the more focused, but not quite as cheap/multisourced, 74AUP1Zxx)

    One Gate manages the Xtal, (no pauses on RST) and the other Gate buffers and speeds up the edges a little, for all the driven Prop XI's

    Ok...so I hear two answers on this.

    1) It's ok to drive ONE prop from another prop. It is not ok to drive MORE THAN ONE prop from another prop

    and

    2) It's not ok to drive ANY NUMBER of props from another prop without running it through a buffer such as the 2GU04. Also, the buffer should be physically located near the prop to minimize lead capacitance so as to not destabilize the crystal driving circuitry and possible cause it to not start up.

    ...also, here is a link to the 2GU04 buffer that was referenced by jmp...in case anyone wants to see
    http://www.onsemi.com/pub_link/Collateral/NLX2GU04-D.PDF
  • idbruceidbruce Posts: 6,197
    edited 2012-02-08 15:31
    Mike
    It can't switch over to its internal clock if the external clock stops.

    That is a nice fact to know.

    Bruce
  • groggorygroggory Posts: 205
    edited 2012-02-08 16:10
    idbruce wrote: »
    Mike



    That is a nice fact to know.

    Bruce

    Makes sense... The propeller ticks along based on its clock source. If you stop its clock...you stop the propeller. Switching oscillator inputs means it's doing something...aka...not stopped.

    Makes perfect sense.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-02-08 16:25
    Go with jmg's suggestion. All the other suggestions have technical problems that may or may not work reliably, including the frequency being pulled off by additional capacitance.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2012-02-09 01:43
    I was hoping that the second Prop would have just sulked whilst its incoming clock went AWOL but the PropCMD bit stopped, and stayed stopped until it got a reset. I was, obviously, using PLLx8 on both of the props. I wonder if the slave Prop's PLL was the bit that hated the pulse pause.

    As Leon says I have used AVRs like this but with them the OSC options are set by flags and so kick in from the start.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2012-02-09 06:34
    jmg wrote: »
    One Gate manages the Xtal, (no pauses on RST) and the other Gate buffers and speeds up the edges a little, for all the driven Prop XI's

    Could you please elaborate? I don't have 2GU04 but I have SN74AUP1G04 x 2.

    Thanks.
  • jmgjmg Posts: 15,183
    edited 2012-02-09 14:48
    MacTuxLin wrote: »
    Could you please elaborate? I don't have 2GU04 but I have SN74AUP1G04 x 2.

    Just wire the Gates you have in series. See Fig 14 in

    http://www.nxp.com/documents/data_sheet/74AUP1Z04.pdf

    R1 is often used to adjust drive to the Xtal, and add a little phase shift too.
  • groggorygroggory Posts: 205
    edited 2012-02-09 15:12
    jmg wrote: »
    Just wire the Gates you have in series. See Fig 14 in

    http://www.nxp.com/documents/data_sheet/74AUP1Z04.pdf

    R1 is often used to adjust drive to the Xtal, and add a little phase shift too.

    Ok, to follow that diagram...
    http://www.nxp.com/documents/data_sheet/74AUP1Z04.pdf

    omit c1, and c2 as the propeller's crystal drive circuitry takes care of that.

    r1 is based on the reactance of the propeller's internal motion capactiors, which are likely around .010pF. The reactance of .010pF @ 5MHz is around 3.2 Megaohms. So to round that to a standard 5% resistor that would be 3.3 megaohms.
  • jmgjmg Posts: 15,183
    edited 2012-02-09 15:34
    groggory wrote: »
    Ok, to follow that diagram...
    http://www.nxp.com/documents/data_sheet/74AUP1Z04.pdf

    omit c1, and c2 as the propeller's crystal drive circuitry takes care of that.

    r1 is based on the reactance of the propeller's internal motion capactiors, which are likely around .010pF. The reactance of .010pF @ 5MHz is around 3.2 Megaohms. So to round that to a standard 5% resistor that would be 3.3 megaohms.

    You've lost me here - you use All Prop's in External drive mode, and so you are building a external stand alone oscillator.
    In a 1GU04 you need a bias resistor, 2 caps and a R1 drive resistor, which is usually under 10K at MHz frequencies.
    See also
    http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/74AUP1Z04EVB.pdf
    This gives R1 = 330 ohms at 25MHz so expect ~1.5k at 5MHz
  • groggorygroggory Posts: 205
    edited 2012-02-09 15:41
    jmg wrote: »
    You've lost me here - you use All Prop's in External drive mode, and so you are building a external stand alone oscillator.
    In a 1GU04 you need a bias resistor, 2 caps and a R1 drive resistor, which is usually under 10K at MHz frequencies.

    I never use 2 capacitors external to a propeller when I hook up a crystal. The propeller has those built in.

    I looked at figure 14 and it said that R1 (the drive resistor) should be selected such its value is approximately equal to the reactance of C1 at the crystal drive frequency. This will result in an input to the crystal of 50% of the rail to rail output of X2.

    Also, Rbias is internal to the 74AUP1Z04

    Obviously we (I) am misunderstanding your meaning. Would you mind going into MS paint and drawing up a quick sketch of how you propose hooking up the 74AUP1Z04 such that a single crystal drives two propellers?
  • jmgjmg Posts: 15,183
    edited 2012-02-09 16:23
    groggory wrote: »
    Obviously we (I) am misunderstanding your meaning. Would you mind going into MS paint and drawing up a quick sketch of how you propose hooking up the 74AUP1Z04 such that a single crystal drives two propellers?

    Just copy the sch here :
    http://media.digikey.com/pdf/Data%20...AUP1Z04EVB.pdf
    The 1GU04 which you said you have, does not include the bias resistor.

    See comments above, the consensus is with TWO props, it is best to slave both, so any Prop caps are not used.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2012-02-10 09:46
    Thanks jmg. My prototype worked. Each Prop could reboot without affecting the other Prop. It ran flawlessly for about 10 min now but I'm going to let it run through the night, just to be sure ;)
  • groggorygroggory Posts: 205
    edited 2012-02-10 11:17
    MacTuxLin wrote: »
    Thanks jmg. My prototype worked. Each Prop could reboot without affecting the other Prop. It ran flawlessly for about 10 min now but I'm going to let it run through the night, just to be sure ;)

    Since you have it on the bench...it would help me if you could do this...

    Write a program in both props that toggles a pin at a regular interval, say ~1kHz. Hook up both props to a logic analyzer and look at that pin. Start a data capture. Reboot the master prop. Give it a second to capture more data. Stop the data capture.

    Then post up the resultant waveform. If you have a nice logic analyzer such as the salae logic analyzer post up the capture file. I'd love to see.

    Thanks!
Sign In or Register to comment.