(Better) Crystal Sharing

Comments

• Phil Pilgrim (PhiPi) Posts: 23,514

  2012-01-31 20:49 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
• Circuitsoft Posts: 1,166

  2012-01-31 21:03 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.
• MacTuxLin Posts: 821

  2012-01-31 21:24 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.
• HShanko Posts: 402

  2012-01-31 23:06 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 Seckshund Posts: 2,027

  2012-01-31 23:53 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
• MacTuxLin Posts: 821

  2012-02-01 00:54 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.
• MacTuxLin Posts: 821

  2012-02-08 09:09 edited 2012-02-08 09:09

  After further testing, I'd go with Circuitsoft's suggestion. No extra component needed.
  
  Thanks.
• SONIC the Hedgehog Posts: 321

  2012-02-08 09:36 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.
• groggory Posts: 205

  2012-02-08 11:29 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 Green Posts: 23,101

  2012-02-08 11:32 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.
• groggory Posts: 205

  2012-02-08 13:15 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.
• Circuitsoft Posts: 1,166

  2012-02-08 13:17 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 Green Posts: 23,101

  2012-02-08 13:33 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.
• Leon Posts: 7,620

  2012-02-08 13:53 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.
• jmg Posts: 15,193

  2012-02-08 14:07 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
• groggory Posts: 205

  2012-02-08 14:16 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
• idbruce Posts: 6,197

  2012-02-08 15:31 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
• groggory Posts: 205

  2012-02-08 16:10 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.
• Cluso99 Posts: 18,071

  2012-02-08 16:25 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 Seckshund Posts: 2,027

  2012-02-09 01:43 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.
• MacTuxLin Posts: 821

  2012-02-09 06:34 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.
• jmg Posts: 15,193

  2012-02-09 14:48 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.
• groggory Posts: 205

  2012-02-09 15:12 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.
• jmg Posts: 15,193

  2012-02-09 15:34 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
• groggory Posts: 205

  2012-02-09 15:41 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?
• jmg Posts: 15,193

  2012-02-09 16:23 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.
• MacTuxLin Posts: 821

  2012-02-10 09:46 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
• groggory Posts: 205

  2012-02-10 11:17 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!