Post by thread:Crystal circuits, and 16F84-4 running at 16mHz

Just for kicks, I hooked up a 16F84-4 (4mHz) to a 16mHz crystal, and it (seems to) run fine. ------------- On an unrelated note, I have to run a PIC within a few ppm of the crystal frequency (8 mHz). I assume I can use a variable capacitor in the crystal circuit. Does this work, and what pF should I use? Also, what's the point of the resistor I occasionaly see betwixt the pic xtal pin and the xtal? Microchip APP note regarding xtal circuits is not too enlightening.

>On an unrelated note, I have to run a PIC within a few ppm of the crystal >frequency (8 mHz). > >I assume I can use a variable capacitor in the crystal circuit. >Does this work, and what pF should I use? You don't strictly need a variable, but you do need to know the real loading of the circuit to find the right values. I'd pad for the variable JIC, but then build the board with fixed caps, and sub the caps to get it right. If the loading C is correct, the xtal will sing the right tune. If you're producing more than a few, you can order the rocks cut to your spec, rather than having to pad to meet an off-the-shelf part, but padding Cs are easier to control than parasitics anyway, so a stock 22pF unit isn't a bad choice. If you have to use a variable, you want to be able to adjust it across the predicted value, I'd use a small one, plus a fixed cap to center the range. >Also, what's the point of the resistor I occasionaly see betwixt the pic >xtal pin and the xtal? Microchip APP note regarding xtal circuits is not too >enlightening. Reduces the drive to the rock. Mchip apparently has some honkin' outputs. I've seen others complaining about blowing watch xtals when the R isn't in the circuit. Most rocks will specify a maximum drive level, as well as the proper loading C.

Why do you need this level of accuracy? If you need accuracy this good, even if you trim it to the required value initially, it is unlikely to STAY this good over time. You may have to "oven" your crystal (shudder) or you can buy an external oscillator with arbitraily good performance (which will include its own oven as performance gets tighter). Unfortunately arbitraily good also translates to 1/arbitraily expensive to some power :-). You can also use analog compensation for thermal drift (thermistor(s) and approriate C's etc. Some months ago someone mentioned someone (HP I think) doing 'digital compensation) where they measure temperature etc and then compensate their algorithms for what the clock will have drifted to. probably only for the brave. > On an unrelated note, I have to run a PIC within a few ppm of the crystal > frequency (8 mHz). >

> >Also, what's the point of the resistor I occasionaly see betwixt the pic >xtal pin and the xtal? Microchip APP note regarding xtal circuits is not too >enlightening. > This resistor is used for some different types of crystal cuts. Not sure which one's. Occasionally the xtal won't oscillate and apparantley the resistor does some thing that helps. More reliable ... I think they are parallel cut xtals Aussieglider

At 09:10 AM 7/11/98 +0200, you wrote: >At 18:41 10/07/1998 -0400, you wrote: >>Also, what's the point of the resistor I occasionaly see betwixt the pic >>xtal pin and the xtal? Microchip APP note regarding xtal circuits is not too >>enlightening. > >Current limiting in the crystal ( hence power ) How does one decide what value to use? Wild guess? :-) Start with a high value and work down?

At 06:53 PM 7/10/98 -0500, you wrote: >>On an unrelated note, I have to run a PIC within a few ppm of the crystal >>frequency (8 mHz). >> >>I assume I can use a variable capacitor in the crystal circuit. >>Does this work, and what pF should I use? > >You don't strictly need a variable, but you do need to know the real loading >of the circuit to find the right values. I'd pad for the variable JIC, but then >build the board with fixed caps, and sub the caps to get it right. If the loading >C is correct, the xtal will sing the right tune. If you're producing more than >a few, you can order the rocks cut to your spec, rather than having to pad >to meet an off-the-shelf part, but padding Cs are easier to control than >parasitics anyway, so a stock 22pF unit isn't a bad choice. I generally get whatever Xtals Hosfelt or Jameco has for low $. The idea of just soldering various caps. in untill running close enough is a good idea I hadn't considered. Will probably end up doing that.

At 12:32 AM 7/12/98 +1200, you wrote: >Why do you need this level of accuracy? Bragging rights! :-) Completely unnecessary for the performance of the product. >If you need accuracy this good, even if you trim it to the required value >initially, it is unlikely to STAY this good over time. Yes, that's true.

That's interesting, I've been toying with writing a video graphics overlay program for a while now. I've always been scuppered by the need to use an external PLL to lock the PIC Osc to the incomming video. All of the techniques that I've thought of to lock-up in software have got the inherent cycle jitter. What is the error on lock-up of the code that you've seen? Dave Ward England ______________________________ Reply Separator ________________________________ _ Subject: RE: CRYSTAL CIRCUITS, AND 16F84-4 RUNNING AT 16MHZ Date: Sun, 12 Jul 1998 23:44:43 -0700 From: Peter <.....popowiczKILLspam@spam@OANET.COM> Subject: Re: Crystal circuits, and 16F84-4 running at 16mHz To: PICLISTKILLspamMITVMA.MIT.EDU Is there an external circuit/signal you need to sync with? I've seen code that pseudo PLL the OSC. -------------------------------- Peter Popowicz Senegal Technology .....popowiczKILLspam.....oanet.com

>I generally get whatever Xtals Hosfelt or Jameco has for low $. >The idea of just soldering various caps. in untill running close enough >is a good idea I hadn't considered. Will probably end up doing that. I know it seems kludgy, but it's somewhat difficult to make accurate measurements that low. You could use a variable, tweak till right, and then measure the variable, but desoldering it will most likely change the value anyway.

Dave Ward <EraseMEGB9C5WZFspam_OUTTakeThisOuTIBMMAIL.COM> wrote: > I've always been scuppered by the need to use an external PLL to lock the PIC > Osc to the incomming video. All of the techniques that I've thought of to > lock-up in software have got the inherent cycle jitter. I've used a 74HC4046 PLL to lock to a multiple of the horizontal sync. It works great, provided you have a clean video input and a good sync separator (the Elantec EL4581 works well). There are data sheets and application notes on the 74HC4046 on the Philips web site. Motorola also has an application note on the 74HC4046 available by fax-back. Eric

Hello Peter, Ive read your reply on the 16MHz PIC question and you wrote > Is there an external circuit/signal you need to sync with? > I've seen code that pseudo PLL the OSC. Now am I very interseted in your last commentline, refering to code. I've created a PIC-project named "OSD-tracking" wich can find a bright spot in a "normal" PAL-television/video signal. Then is projects a croshair on top of this video-signal, resulting in a futuristic (but cheap) object tracking device. The only sensor needed is a camera. Now I know it sounds complex but it is quite simple (realy). The only thing is that my OSD (On Screen Display as visible on monitor or TV) wiggles. This due to the fact of bad syncronysation between the analog video-signal and the digital-OSD data. My question how do i stop/synchronise my oscillator with software (and some small hardware hacks) in a cheap and simple way. I'd like small sollutions. Please reply your answer could be the key to a steadier tracking/OSD.