PIC Clock

[Dirk Bruere at Neopax]

Looks like I'm probably going to be using a PIC
The clock seems OK with just an xtal and a couple of caps. However, I've had
problems with such setups on other uPs in the past. How reliable is this on a
PIC, or should I use an osc module?

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Spehro Pefhany]

Looks like I'm probably going to be using a PIC
The clock seems OK with just an xtal and a couple of caps. However, I've had
problems with such setups on other uPs in the past. How reliable is this on a
PIC, or should I use an osc module?

Pretty good, at least in the 4MHz range. A resonator is pretty
bulletproof if you can live with a bit more inaccuracy.


Best regards,
Spehro Pefhany

 

[Leon]

Looks like I'm probably going to be using a PIC
The clock seems OK with just an xtal and a couple of caps. However, I've had
problems with such setups on other uPs in the past. How reliable is this on a
PIC, or should I use an osc module?

I've never had any problems. The oscillator does need to be configured
properly; there are *lots* of options on the latest chips, which can be
confusing.

Leon

 

[Dirk Bruere at Neopax]

I've never had any problems. The oscillator does need to be configured
properly; there are *lots* of options on the latest chips, which can be
confusing.

I'm just worried about reliable starting.
We are going to employ at least 6 in each system and they must start within a mS
of each other after power on. One not starting at all would be a serious flaw.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[John Jardine.]

I'm just worried about reliable starting.
We are going to employ at least 6 in each system and they must start within a mS
of each other after power on. One not starting at all would be a serious

flaw.

They always start.
But within a ms of each other, sounds like a fast track to perdition

 

[James Beck]

flaw.

They always start.
But within a ms of each other, sounds like a fast track to perdition

No kidding!
If they all need to know (or in his case assume) that the others are up
and ready to rock, then some type of signalling between the units had
better be employed. Something as simple as a daisy chained enable/I'm
alive would be better than attempting to get the reset circuits and
oscillators to all be with in 1mS.

Jim

 

[Bob Monsen]

[quoted text muted]

I'm just worried about reliable starting. We are going to employ at
least 6 in each system and they must start within a mS of each other
after power on. One not starting at all would be a serious flaw.

If you are worried, simply use an external crystal oscillator, and clock
them all on the same signal. That way, they are all more accurate anyway
(the internal clock is temperature sensitive).

You can also use a separate circuit to synchronize them using their MCLR
reset inputs... perhaps a one-shot?

--
Regards,
Bob Monsen

"we can allow satellites, planets, suns, universe, nay whole systems
of universe[s,] to be governed by laws, but the smallest insect, we
wish to be created at once by special act"
-- Charles Darwin

 

[David L. Jones]

I'm just worried about reliable starting.

Don't be.
Follow the datasheet values and it will start every time. The PICs
would not have made it to the #1 seller if they had clock starting
reliability problems.

We are going to employ at least 6 in each system and they must start within a mS
of each other after power on. One not starting at all would be a serious flaw.

In that case use one as the master clock and then tap off it (one of
the pins allows this) and power the other chips which are set up for
external clock input. Or better yet, simply use an external oscillator
of your choosing and clock them all from it.

Out of curiosity, why must they start within a mS of each other?
Is your code sequentially critical across chips?, if it is that's not a
good position to be in...

Dave

 

[Joseph Legris]

I'm just worried about reliable starting.
We are going to employ at least 6 in each system and they must start within a mS
of each other after power on. One not starting at all would be a serious flaw.

I have found an overall no-start rate of roughly 1 in 1000 over roughly
20,000 pieces (@20mHz, PIC HS osc, 22pF ceramic caps), and it has always
been either the crystal's fault or a defective PCB. We don't measure
start-up time. Every now and then we get a cluster of maybe 1 bad
crystal in 100, but now we test them first and weed out the bad ones.
Lately (past couple of years) they've all been good. A few years ago FOX
had a bad spell, but then bounced back. More recently Raltron did too,
but less severely. Of course it could have nothing to do with the
manufacturing - maybe we are handling them improperly. Whatever the
cause, they are the weakest link by far. One thing: we have never had a
crystal go bad that passed incoming test.

I have never encountered a bad processor except one we ruined by
disconnecting the programmer mid-cycle. We have never heard of a unit
just dying in the field either (automotive app, industrial temp range
part) - there has always been an external cause such as tampering or
accident.

For your case I'd go with a central oscillator, just for the
synchronized start-up alone. Then add the increased assembly costs for
individual crystals and caps. It's also much easier to trouble-shoot.

 

[Dirk Bruere at Neopax]

I have found an overall no-start rate of roughly 1 in 1000 over roughly
20,000 pieces (@20mHz, PIC HS osc, 22pF ceramic caps), and it has always
been either the crystal's fault or a defective PCB. We don't measure
start-up time. Every now and then we get a cluster of maybe 1 bad
crystal in 100, but now we test them first and weed out the bad ones.
Lately (past couple of years) they've all been good. A few years ago FOX
had a bad spell, but then bounced back. More recently Raltron did too,
but less severely. Of course it could have nothing to do with the
manufacturing - maybe we are handling them improperly. Whatever the
cause, they are the weakest link by far. One thing: we have never had a
crystal go bad that passed incoming test.

It's not a hard failure to start that I'm worried about, since that can be
picked up on test. It's intermittent failures in the field that would cost us a
bundle.

I have never encountered a bad processor except one we ruined by
disconnecting the programmer mid-cycle. We have never heard of a unit
just dying in the field either (automotive app, industrial temp range
part) - there has always been an external cause such as tampering or
accident.

For your case I'd go with a central oscillator, just for the
synchronized start-up alone. Then add the increased assembly costs for
individual crystals and caps. It's also much easier to trouble-shoot.

May do so.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org