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
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
--
"it\'s the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
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
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.
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
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.
mS
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...
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.
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.
May do so.
--
Dirk
The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.