Post by thread:[PIC]: Startup time for resonators

Does anyone have any figures for oscillator startup time using a 4MHz ceramic resonator? Comparison to times for RC or crystal would be great. I will be using a PIC16F877 sitting in sleep mode most of the time until woken up by interrupt. To keep power dissipation lowest we want it to wake up as soon as possible do it's thing and go back to sleep. My client has previously used RC mode for this reason, but now needs better timing accuracy. I have a feeling that a resonator will start quicker than a crystal but I need to verify that. Lots of my other projects use a 4MHz resonator with internal caps but haven't used sleep mode. Maybe I'll write a test program later today nad try it myself. Thanks. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: spam_OUTbrent.brownTakeThisOuTclear.net.nz -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Thanks Jinx, I have read the section in the midrange manual (now) and it makes things a bit clearer. Still, if anyone has any actual figures for startup time that would be interesting. I realise PIC oscillator design is a bit of a black art. For this application I could even try something weird like a combination of startup on RC oscillator then power up a 11.0592MHz crystal (used for IRDA chip) divide by six to give 1.8432MHz when I need it, use some fancy logic switching to get this to the micro, then go to sleep again. That way I get instant startup from sleep and a good clock for baud rates when I need it. Main problem I can see is that RC mode does not easily allow for external clock in. {Quote hidden}> > Does anyone have any figures for oscillator startup time using > > a 4MHz ceramic resonator? Comparison to times for RC or > > crystal would be great. > > Hi Brent, Section 2 of the Mid-range Manual has some info on this > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On 12 Jul 2002 at 10:01, Jinx wrote: > Brent, me again, Sections 3.2.3 and 3.2.4 of the MRM are about > the Oscillator Start-up Timer, OST, and have specifics, knew I'd > seen it somewhere > > I think you should still read Section 2 for all the background info Cheers Jinx, Read it all now & have it figured (hope). Still comes down to the unknown factor of how long does it take for a particular brand/value of resonator (or crystal) to start oscillating with a given PIC. After assimilating all the info in the manuals I now know that this is dependant on a whole bunch of suff like temp, Vdd, noise, capacitance, res/crystal specs, which way you hold your tongue etc. In reality this means you have to try it to see what works and then making sure that it works reliably. There seems no simple sure fire way of making a resonator/crystal start up instantly, and so the RC option seems the way to go where this is most important. Actually I already knew all this stuff... micro's of any sort (but particularly PIC's?) can be fussy about starting to oscillate. How many PIClist postings have there been about projects with oscillator problems? This little bit of research kind of reinforces my view that the oscillator section of any design should be tested to guarantee startup at any temp/voltage. Thanks, Brent. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: .....brent.brownKILLspam@spam@clear.net.nz -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

part 1 1488 bytes content-type:text/plain; charset=iso-8859-1 (decoded 7bit) Brent, Here's a screenshot of a Kyocera PBRC-4.00 4MHz SMD ceramic resonator w/internal caps on startup. I tried it several times and it was very consistent. It looks like it takes about 600 uS from power-on. It tracks the 5V supply rail quite nicely. Since you want to are planning to use Sleep mode, the oscillator should start up very quickly based on what I see -- probably around 300 uS based on the 'scope shot. My CONFIG fuse is set to HS, since I found that in production units the oscillator starts more reliably than with XT using this particular resonator. Hope that helps. Matt Pobursky Maximum Performance Systems On Fri, 12 Jul 2002 09:22:39 +1200, Brent Brown wrote: {Quote hidden}>Does anyone have any figures for oscillator startup time using a 4MHz >ceramic resonator? Comparison to times for RC or crystal would be >great. > >I will be using a PIC16F877 sitting in sleep mode most of the time >until woken up by interrupt. To keep power dissipation lowest we want >it to wake up as soon as possible do it's thing and go back to sleep. >My client has previously used RC mode for this reason, but now needs >better timing accuracy. I have a feeling that a resonator will start >quicker than a crystal but I need to verify that. Lots of my other >projects use a 4MHz resonator with internal caps but haven't used >sleep mode. Maybe I'll write a test program later today nad try it >myself. > >Thanks. part 2 8865 bytes content-type:image/gif; name=Ceramic.gif (decode) part 3 144 bytes -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On Fri, 12 Jul 2002, Brent Brown wrote: >Thanks Jinx, > >I have read the section in the midrange manual (now) and it makes things a >bit clearer. Still, if anyone has any actual figures for startup time that would >be interesting. I realise PIC oscillator design is a bit of a black art. > >For this application I could even try something weird like a combination of >startup on RC oscillator then power up a 11.0592MHz crystal (used for IRDA >chip) divide by six to give 1.8432MHz when I need it, use some fancy logic >switching to get this to the micro, then go to sleep again. That way I get >instant startup from sleep and a good clock for baud rates when I need it. >Main problem I can see is that RC mode does not easily allow for external >clock in. Can't you use one of the PICs that have provisions for a second oscillator ? Run continuously on 32768Hz and run on RC when waking up ? Or something like that ? Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

The electro-mechanical resonator osc start-up time is inversely proportional to amplifier gain and proportional to oscillator Q, and inversely proportional to amplifier noise. Something like: Tstart ~= Q / ( Nf * G ) Therefore low Q high gain and high Nf are desirable. G is determined by the supply voltage and the osc setting (HS has more gain than XT and that than LP), Nf is probably constant, and ceramic resonators have a lower Q than crystals. Therefore HS with ceramic resonator and high supply voltage should give fastest startup time. There are schemes to 'kick' the oscillator with a unit pulse to hasten the startup but these do not normally apply to PICs and MCUs because they can cause a glitch. The unit pulse enters the equation above as a very high initial Nf. It can be generated by logic (gate ring monostable) or by a monostable, or even by applying a fast edge to one of the caps in the oscillator PI network. Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On 12 Jul 2002 at 11:59, Peter L. Peres wrote: > Can't you use one of the PICs that have provisions for a second > oscillator ? Run continuously on 32768Hz and run on RC when waking up > ? Or something like that ? Yes, wIll be using 32.768kHz clock as well, but for main clock would like fast startup from sleep (as with RC) but also desire accurate clock for generating baud rates. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: brent.brownKILLspamclear.net.nz -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On 12 Jul 2002 at 3:23, Matt Pobursky wrote: > Here's a screenshot of a Kyocera PBRC-4.00 4MHz SMD ceramic resonator > w/internal caps on startup. I tried it several times and it was very > consistent. It looks like it takes about 600 uS from power-on. It > tracks the 5V supply rail quite nicely. Since you want to are planning > to use Sleep mode, the oscillator should start up very quickly based > on what I see -- probably around 300 uS based on the 'scope shot. My > CONFIG fuse is set to HS, since I found that in production units the > oscillator starts more reliably than with XT using this particular > resonator. Hi Matt, Thanks for taking the time to post a scope image. Interesting that you found HS mode more reliable. In HS mode the oscillator circuit has more gain (and uses more power). The mid range manual section 2.3.3.1.1 explains why oscillator start up from sleep mode is actually more difficult than from power up. From this I gather that although your resonator starts reliably on power up in about 600us it could take any length of time or even be unreliable in a power up from sleep scenario. Initially I thought resonators might start up generally faster/easier than crystals but I haven't found any evidence to support that. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: .....brent.brownKILLspam.....clear.net.nz -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On 12 Jul 2002 at 1:27, Pic Dude wrote: > Got in late on this thread so hopefully I'm not repeating > something or missing some key info, but if you're worried > about startup time, why not put a large enough cap on MCLR > so that comes up to threshold AFTER the resonator kicks on > (allowing room for tolerance, etc)? You can measure that > time and adjust the code accordingly. [ I assume you have > something timed critically? ] That's OK. The key objective is to get as fast as possible startup when waking up from sleep. This is because the micro is battery powered and only wakes occasionally to do stuff then goes back to sleep, therefore the briefest possible awake period keeps power consumption to the minimum. You have got me thinking though: if I wake from sleep by an interrupt and then it takes a while for the oscillator to start up...what is the power consumption actually like in this in-between state waiting for the oscillator to start? Technically the oscillator is not running so power could still be quite low. Still would likethe micro be awake ASAP though to process whatever caused it to wake. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: brent.brownspam_OUTclear.net.nz -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On Fri, 12 Jul 2002 23:19:24 +1200, you wrote: {Quote hidden}>On 12 Jul 2002 at 1:27, Pic Dude wrote: > >> Got in late on this thread so hopefully I'm not repeating >> something or missing some key info, but if you're worried >> about startup time, why not put a large enough cap on MCLR >> so that comes up to threshold AFTER the resonator kicks on >> (allowing room for tolerance, etc)? You can measure that >> time and adjust the code accordingly. [ I assume you have >> something timed critically? ] > >That's OK. The key objective is to get as fast as possible startup >when waking up from sleep. This is because the micro is battery >powered and only wakes occasionally to do stuff then goes back to >sleep, therefore the briefest possible awake period keeps power >consumption to the minimum. > >You have got me thinking though: if I wake from sleep by an interrupt >and then it takes a while for the oscillator to start up...what is >the power consumption actually like in this in-between state waiting >for the oscillator to start? Technically the oscillator is not >running so power could still be quite low. Still would likethe micro >be awake ASAP though to process whatever caused it to wake. ..remember it will only be in this waking-up state for a few mS, so the power draw in this state is not a major problem if it isn't waking up very often. Unless you're talking small coin cells it probably isn't too significant. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Olin Lathrop schrieb: > > > ... why not put a large enough cap on MCLR > > so that comes up to threshold AFTER the resonator kicks on > > Because there is a minimum MCLR rise time spec, if I recall correctly. <donning flame suit> ...wouldn't that be a max. spec??? Jochen <exiting flame suit> > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Matt, I wonder why your 5v line takes so long to come up to voltage? Are you switching the input to a regulator whose output then feeds the pic? I think a more fair test of oscillator startup would be to directly switch the 5V supply to the pic, since it may well be that the osc can start a lot faster if the supply rise time is faster. The reason I say this is that the fact that it follows the supply so closely makes me suspicious that what you are calling startup is actually simply the 5v line adjusting the operating point of the oscillator as it rises. It seems to me from your screenshot that the startup really happened in a very short period of time right near the rightmost cursor. If you could make the V supply rise faster, it is possible that the oscillator might start much more quickly. Sean At 03:23 AM 7/12/2002 -0500, you wrote: {Quote hidden}>Brent, > >Here's a screenshot of a Kyocera PBRC-4.00 4MHz SMD ceramic resonator >w/internal caps on startup. I tried it several times and it was very >consistent. It looks like it takes about 600 uS from power-on. It >tracks the 5V supply rail quite nicely. Since you want to are planning >to use Sleep mode, the oscillator should start up very quickly based on >what I see -- probably around 300 uS based on the 'scope shot. My >CONFIG fuse is set to HS, since I found that in production units the >oscillator starts more reliably than with XT using this particular >resonator. > >Hope that helps. > >Matt Pobursky >Maximum Performance Systems > >On Fri, 12 Jul 2002 09:22:39 +1200, Brent Brown wrote: > >Does anyone have any figures for oscillator startup time using a 4MHz > >ceramic resonator? Comparison to times for RC or crystal would be > >great. > > > >I will be using a PIC16F877 sitting in sleep mode most of the time > >until woken up by interrupt. To keep power dissipation lowest we want > >it to wake up as soon as possible do it's thing and go back to sleep. > >My client has previously used RC mode for this reason, but now needs > >better timing accuracy. I have a feeling that a resonator will start > >quicker than a crystal but I need to verify that. Lots of my other > >projects use a 4MHz resonator with internal caps but haven't used > >sleep mode. Maybe I'll write a test program later today nad try it > >myself. > > > >Thanks. ------------------------------------------- Introducing NetZero Long Distance Unlimited Long Distance only $29.95/ month! Sign Up Today! http://www.netzerolongdistance.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Brent Brown wrote: > > Does anyone have any figures for oscillator startup time using a 4MHz > ceramic resonator? Comparison to times for RC or crystal would be > great. > > I will be using a PIC16F877 sitting in sleep mode most of the time > until woken up by interrupt. To keep power dissipation lowest we want > it to wake up as soon as possible do it's thing and go back to sleep. Hi Brent, i've seen a few responses to your question but the main thing to consider is the length of start up time itself, but the actual power used during startup. PIC chips use very little power when running at a lower clock speed, the current they draw is (roughly) proportional to the number of clocks/sec it does. That is why you use 32kHz clock for low power etc. I *ran* a standard 5v 16f84 at 60uA with a low freq clock here as an experiment once. :o) So, technically the pic doesn't really use any significant power during startup, as the power drain only occurs relative to how many instructions it performs. Based on graphs of oscillator startup, the moment it really starts oscillating it is almost at frequency. Before that there is minimal power draw as the PIC is not clocking. I suppose the big question is what the PIC has to do after waking up, and does it matter if the first 100 or so instructions are fractionally off-speed?? :o) -Roman -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On Fri, 12 Jul 2002, Brent Brown wrote: >Peter, > >Thanks for your description on oscillator start up. As usual though >there is always a catch: want fast startup but low power is important >too, so XT or HS modes are out. Look into the kick option. If the event that requires wakeup is external then you can use it to kick the oscillator. One form is: <digital input>---CMOS Schmitt gate----*----->wakeup interrupt on CPU | +--|C1|---*--> Xtal input on MCU | +---|Xtal|---> more stuff You need to make sure that the node (Xtal *output*) on the MCU has the same polarity as the output of the Schmitt Gate before the event. Then the polarity will change when the event comes and the osc. will be kicked through C1. C1 is the Xtal load cap. Electrically the scheme is sound, as long as the ground and vcc connections of the Schmitt gate are tightly coupled to the CPU's. However, it's a hack. I would not use such a thing in a production circuit, however if I were a MCU manufacturer I'd look into it seriously for integration into future products ... You can simulate this in SPICE using a NMOS/PMOS transistor amp, crystal (== parallel LC group + coupling cap) in Pierce osc config, and one of the PI caps connected to a stepwise programmed voltage source, set to give a single step of size Vcc. Delay the step as needed (T~=5 periods is about right). You may have to add a pair of ideal diodes as input clamping network on the amplifier. Intuitively this is equivalent to giving a pendulum a hefty kick. Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Hi Brent, You might want to still use the RC oscillator as it provides the fastest start-up. To achieve accurate baud rates you simply need to calibrate the RC-oscillator using a good reference, like 32768 Hz crystal. Some PICs can run from RC-oscillator and clock a timer from the crystal at the same time. So, you would have to simply wake up occasionaly (on timer overflow for example, which would be every 2 seconds), calibrate the RC-oscillator, and go back to sleep. Or do the calibration even less often, but it depends on how fast the frequency can change. If the device is indoors, where temperature doesn't change quickly, it's probably pretty stable. Nikolai Thursday, July 11, 2002, 3:05:18 PM, Brent Brown wrote: {Quote hidden}> Thanks Jinx, > I have read the section in the midrange manual (now) and it makes things a > bit clearer. Still, if anyone has any actual figures for startup time that would > be interesting. I realise PIC oscillator design is a bit of a black art. > For this application I could even try something weird like a combination of > startup on RC oscillator then power up a 11.0592MHz crystal (used for IRDA > chip) divide by six to give 1.8432MHz when I need it, use some fancy logic > switching to get this to the micro, then go to sleep again. That way I get > instant startup from sleep and a good clock for baud rates when I need it. > Main problem I can see is that RC mode does not easily allow for external > clock in. >> > Does anyone have any figures for oscillator startup time using >> > a 4MHz ceramic resonator? Comparison to times for RC or >> > crystal would be great. >> >> Hi Brent, Section 2 of the Mid-range Manual has some info on this >> >> -- >> http://www.piclist.com hint: PICList Posts must start with ONE topic: >> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads >> >> >> > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

General reply: Thanks for all the responses while I was asleep (it's a time zone thing, not just lazyness!). Thanks Peter for the ideas about kick starting the resonator. Unfortunately the event that wakes the micro will mostly be an internal interrupt event. I am going to look further at making an external low power RC oscillator with CMOS gates and driving this into the OSC1 input with the PIC in LP, XT or HS mode. This is for timing not critical mode but low consumption and fast wake from sleep. With external gates I have the ability to use a port pin to switch to my 11.0592MHz from IRDA chip divided by 6 to give 1.8432MHz clock for baud rates when I need it. I have power control of the IRDA chip & oscillator. It would be nice to use the PIC in RC mode and have it automatically start/stop my external oscillator circuit when exiting/entering sleep mode. That would get power consumption down to where it could be. Could be tricky though. Manual says dont feed a signal in when in RC mode as it will "fight" the input, but maybe with a series resistor the "fighting" current will be no more than normal RC operation. OSC2 output is low in sleep mode and OSC1 will be high but should pulse low when trying to restart the oscillator, so may be able to invent some logic to do this. Regards, Brent. -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: @spam@brent.brownKILLspamclear.net.nz -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On 12 Jul 2002 at 9:48, Nikolai Golovchenko wrote: > Hi Brent, > > You might want to still use the RC oscillator as it provides the > fastest start-up. To achieve accurate baud rates you simply need to > calibrate the RC-oscillator using a good reference, like 32768 Hz > crystal. Some PICs can run from RC-oscillator and clock a timer from > the crystal at the same time. So, you would have to simply wake up > occasionaly (on timer overflow for example, which would be every 2 > seconds), calibrate the RC-oscillator, and go back to sleep. Or do the > calibration even less often, but it depends on how fast the frequency > can change. If the device is indoors, where temperature doesn't change > quickly, it's probably pretty stable. Nikolai, Yes this is a good idea and we do have a 32.768kHz crystal on the second oscillator for implementing a RTC. We thought of the scheme you describe but the problem is that the customer wants to do IRDA with 115200 baud. This scheme does not give enough resolution to aceive this baud rate with the UART. It is probably OK for 9600 baud where each step in SPBRG equals about 400 baud. In a software UART the resolution could be better but we are already doing that to generate a second async port and would like to the use hardware UART as well! -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: KILLspambrent.brownKILLspamclear.net.nz -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Brent Brown wrote: > It would be nice to use the PIC in RC mode and have it automatically > start/stop my external oscillator circuit when exiting/entering sleep > mode. That would get power consumption down to where it could be. > Could be tricky though. Manual says dont feed a signal in when in RC > mode as it will "fight" the input, but maybe with a series resistor > the "fighting" current will be no more than normal RC operation. OSC2 > output is low in sleep mode and OSC1 will be high but should pulse > low when trying to restart the oscillator, so may be able to invent > some logic to do this. Hi Brent, the PIC RC mode is very simple, like a 555 timer it uses the R to charge the C, then the OSC1 pin is simply an open drain input that discharges the C when the volts on it rise above the standard threshold. I tried some funky stuff with the RC osc mode here: http://www.ezy.net.au/~fastvid/pic2clk.htm The basic operation of the RC osc is very straightforward with one >v threshold, and a "drainer" for the cap. I'm sure you can interface a crystal clock to it. Note, at one point I had the thing oscillating between 4MHz and 10kHz, with a few pulses of each, looked pretty funny on the CRO! Of course the PIC ran perfectly even with the oscillator doing this, just at an average of the 2 speeds. In short, go for it! :o) -Roman -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Brent, Okay, I didn't realize you needed a 115.2 kbaud UART. Even with a stable crystal frequency, software or hardware implementation could have a large error if the clock frequency is not right, just because the baud rate is so close to the clock rate. For example, at a 4 MHz clock, the bit length is 8.68 instruction cycles. But it's possible to have only integer number of cycles, so it would be either 8 or 9. The error is then roughly -8% or +4%. This might be okay though if you compensate the error each following transmitted bit, e.g. doing delays in this sequence: 8, 9, 9, 9, 8, 9, 9, 8, 9, 9, etc. But a better clock frequency would be 3.69 MHz, which divides evenly by 115.2 kbaud. Here is another idea. It would be nice to be able to change RC-oscillator frequency with external resistors. You could still calibrate the oscillator to achieve 3.69 MHz and take advantage of the hardware UART. Usually RC-oscillator is completely inside the chip, but a few PICs (like 16F628) have external resistor mode (ER) for the oscillator. The resistor is hooked between CLKIN and VSS. So, if you connect more resistors in parallel controlled by pins, the frequency could be adjusted in some range. It might be difficult to control since pins themselves add another variable, so the frequency could depend on overall power consumption of the PIC, for example... Alternatively, the resistors could be switched by an external device like analog MUX or resistor DAC. That would remove that variability. Nikolai {Quote hidden}> Subject: Re: [PIC]: Startup time for resonators > From: Brent Brown (RemoveMEbrent.brownTakeThisOuTCLEAR.NET.NZ) > Date: Fri Jul 12 2002 - 18:26:50 PDT > On 12 Jul 2002 at 9:48, Nikolai Golovchenko wrote: >> Hi Brent, >> >> You might want to still use the RC oscillator as it provides the >> fastest start-up. To achieve accurate baud rates you simply need to >> calibrate the RC-oscillator using a good reference, like 32768 Hz >> crystal. Some PICs can run from RC-oscillator and clock a timer from >> the crystal at the same time. So, you would have to simply wake up >> occasionaly (on timer overflow for example, which would be every 2 >> seconds), calibrate the RC-oscillator, and go back to sleep. Or do the >> calibration even less often, but it depends on how fast the frequency >> can change. If the device is indoors, where temperature doesn't change >> quickly, it's probably pretty stable. > Nikolai, > Yes this is a good idea and we do have a 32.768kHz crystal on the > second oscillator for implementing a RTC. > We thought of the scheme you describe but the problem is that the > customer wants to do IRDA with 115200 baud. This scheme does not give > enough resolution to aceive this baud rate with the UART. It is > probably OK for 9600 baud where each step in SPBRG equals about 400 > baud. In a software UART the resolution could be better but we are > already doing that to generate a second async port and would like to > the use hardware UART as well! > -- > Brent Brown, Electronic Design Solutions > 16 English Street, Hamilton, New Zealand > Ph/fax: +64 7 849 0069 > Mobile/txt: 025 334 069 > eMail: spamBeGonebrent.brownspamBeGoneclear.net.nz -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Sat, 13 Jul 2002 12:03:01 -0700, Nikolai Golovchenko wrote: <snip> {Quote hidden}>Usually RC-oscillator is completely inside the chip, >but a few PICs (like 16F628) have external resistor mode (ER) for the >oscillator. The resistor is hooked between CLKIN and VSS. So, if you >connect more resistors in parallel controlled by pins, the frequency >could be adjusted in some range. It might be difficult to control >since pins themselves add another variable, so the frequency could >depend on overall power consumption of the PIC, for example... >Alternatively, the resistors could be switched by an external device >like analog MUX or resistor DAC. That would remove that variability. > Could a digital pot perhaps be used rather than external resistors and switching hardware? I'm not sure about the power implications but using one would allow calibration to be done with just the one resistive element. Regards, Bob -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Bob Barr wrote: > Could a digital pot perhaps be used rather than external resistors and > switching hardware? > I'm not sure about the power implications but using one would allow > calibration to be done with just the one resistive element. Sure, that's what I meant by a resistive DAC :) Probably two extra resistors would still be required: ----------o---o CLKIN | | / / \ R1 \ R2 / / | | | | | / | \ R3 (digital pot) | / | | ----------o | === GND R1 sets the nominal frequency and R2/R3 compensate for frequency variation. The parallel connection would ensure that at least R1 is always connected and CPU is running. The digital pot might have some states where it disconnects the resistor completely, which would stall the CPU. Except saving some power, that's not very useful :) Nikolai -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Sat, 13 Jul 2002 13:21:05 -0700, Nikolai Golovchenko <TakeThisOuTgolovchenkoEraseMEspam_OUTMAIL.RU> wrote: >Bob Barr wrote: >> Could a digital pot perhaps be used rather than external resistors and >> switching hardware? > >> I'm not sure about the power implications but using one would allow >> calibration to be done with just the one resistive element. > >Sure, that's what I meant by a resistive DAC :) Probably two extra >resistors would still be required: > Well, DUH on my part. :=) I hadn't thought of a digital pot as a resistive DAC but it certainly is one. Regards, Bob -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.