Searching \ for '[PIC]: Startup time for resonators' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=time
Search entire site for: 'Startup time for resonators'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Startup time for resonators'
2002\07\11@172530 by Brent Brown

picon face
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.brownTakeThisOuTspamclear.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


2002\07\11@173550 by Jinx

face picon face
> 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


2002\07\11@180514 by Jinx

face picon face
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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\07\11@182315 by Brent Brown

picon face
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}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\07\11@210125 by Brent Brown

picon face
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.brownKILLspamspam@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


2002\07\12@024327 by Pic Dude

flavicon
face
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? ]

Cheers,
-Neil.


{Original Message removed}

2002\07\12@042326 by Matt Pobursky

flavicon
face
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}


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


2002\07\12@051440 by Peter L. Peres

picon face
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


2002\07\12@053420 by Peter L. Peres

picon face
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


2002\07\12@071137 by Brent Brown

picon face
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.brownspamKILLspamclear.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


2002\07\12@071149 by Brent Brown

picon face
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.brownKILLspamspam.....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


2002\07\12@071605 by Brent Brown

picon face
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.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  EraseMEbrent.brownspam_OUTspamTakeThisOuTclear.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


2002\07\12@072225 by Brent Brown

picon face
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.brownspamspam_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


2002\07\12@080457 by mike

flavicon
face
On Fri, 12 Jul 2002 23:19:24 +1200, you wrote:

{Quote hidden}

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


2002\07\12@081330 by Olin Lathrop

face picon face
> ... 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.


*****************************************************************
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


2002\07\12@082453 by Jochen Feldhaar

flavicon
face
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


2002\07\12@085215 by Sean H. Breheny

face picon face
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}

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


2002\07\12@085347 by Olin Lathrop

face picon face
> > Because there is a minimum MCLR rise time spec, if I recall correctly.
> <donning flame suit>
> ...wouldn't that be a max. spec???

Yes, oops.

> 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


2002\07\12@091216 by Roman Black

flavicon
face
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


2002\07\12@102645 by Peter L. Peres

picon face
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


2002\07\12@124725 by Nikolai Golovchenko

flavicon
face
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}

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


2002\07\12@213022 by Brent Brown

picon face
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.brownKILLspamspamclear.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


2002\07\12@213038 by Brent Brown

picon face
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.brownKILLspamspamclear.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


2002\07\13@053421 by Roman Black
flavicon
face
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.


2002\07\13@145954 by Nikolai Golovchenko

flavicon
face
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}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\07\13@152606 by Bob Barr

flavicon
face
On Sat, 13 Jul 2002 12:03:01 -0700, Nikolai Golovchenko wrote:

<snip>

{Quote hidden}

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.


2002\07\13@161911 by Nikolai Golovchenko

flavicon
face
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.


2002\07\13@165618 by Bob Barr

flavicon
face
On Sat, 13 Jul 2002 13:21:05 -0700, Nikolai Golovchenko
<TakeThisOuTgolovchenkoEraseMEspamspam_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.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...