internal or external PIC oscillator?

Status
Not open for further replies.

Mark_R

Member
Trying to settle on an oscillator for my project. This will be on a 18F4620. The program will not be too complicated, a bunch of slow digital I/O for monitoring alarm points, communication with a cellular modem at 9600 baud over the hardware USART, connection to an LCD display and communication to a RTC via I2C. This is being designed for a temperature range of -30 to +60C.

I was hoping to use the internal oscillator (8MHz), with or without the 4x PPL enabled (32MHz). My concern is if the temperature swing will cause enough variation to cause problems with the USART comms.

I was initially thinking that 9600 was so slow that it would not be a big deal, but then I was thinking that the slower the baud rate, the more important it would be as a given percentage would equate to a bigger time displacement? Not sure which way to look at it. I assume the I2C is not a concern as it is synchronous.

Any opinions?


Thanks.
 
Last edited:
Depends on the data you're sending, if you're sending brief packets of data the baud rate deviation tolerance is higher. It's easy enough to test using 'canned air' liquid as a refrigerant, and a transistor as a heater. A crystal would be a good choice if you can afford the space/cost of it. With oscilators you really can't go wrong with a crystal.
 
Also I know some AVR's have internal temperature sensors, not sure if your PIC does but it could allow you to change the oscillator calibration byte depending on temperature. Not as good as a crystal, but it'll likley get you within range.
 
The PIC has some osc tuning, they mention comparing to a known freq like ac line for drift reference, or tuning based upon frame or data errors happening in the USART. If I was going to go through that, I might as well throw in an ext. crystal.

On a typical project without high speed demands, what's the typical logic for choosing a clock speed?
 
Last edited:
The same as for high speed. Chose a frequency that is evenly divisible by the desired baud rate, 0% error every time. As temperature shift is ppm per degree C a lower frequency clock will track better than a higher frequency over a wide temperature range, but that's only important for really high speed data rates. You should have absolutly no trouble finding baud rate divisible crystals, they're very common for just this reason.
 
Sceadwian said:
The same as for high speed. Chose a frequency that is evenly divisible by the desired baud rate, 0% error every time.
Click to expand...

So, one would go with say, 14.7456Mhz, which is divisible into all the standard baud rates up to 115.2K?

I'm looking at the helpful chart here==> **broken link removed**
 
Yep, as long as that crystal frequency is high enough for the mathematical processing you need to do with the data or otherwise.
 
Not quite absorbing the big picture yet...

So I see all sorts of code example of the use of a nice round number crystal, like 10 or 20Mhz. I assume this is fine if there are no external comms to sync with, but if there is, a crystal which is an even divisor of the baud rates like 14.7456 Mhz or 22.1184Mhz make more sense?

If I understand, you could still use another freq but you have to live with a bit of an error on the baud rate? As set in the SPBRGH / SPBRG registers? Does setting these registers null out the error?

Am I even in the ballpark here?
 
You can never null out the error on a mismatched baud rate, it's there, period. Depending on the baud rate and the clock mismatch you'll get more or less baud rate error at a given transmitting rate. It depends on the frequency and tollerance of the sender/recievers baud rate match as well so it's really a big grey area. If you use a baud rate divisible crystal frequency you never even have to think about it. If you don't you'll have to do testing to determine if the error rate is low enough for your application. Some never see it, some can't work with even a little errror.
 
The internal oscillator can drift by ±10% over that temperature range.

However, if you still wanted to use the internal oscillator it may be possible. If the UART is only used infrequently, then you could use the auto baud detect to eliminate clock errors.

Mike.
 

It's used frequently.
 
Hi there,


Maybe you can run one up and output a pulse of known frequency and measure
that with a good frequency counter while raising the temperature of the ic
chip. That would give you at least some idea what happens when the temperature
rises and falls. You should probably measure several chips and see if they
all behave somewhat the same way though.
Would probably be interesting.
Post results so we all can take a look
 
If you have the spare communication time you could renegotiate the baud rate every 10 seconds and that would solve your problem. It would only involve sending a dozen or so bytes.

Mike.
 
Mark_R said:
So, one would go with say, 14.7456Mhz, which is divisible into all the standard baud rates up to 115.2K?

I'm looking at the helpful chart here==> **broken link removed**
Click to expand...

Doh! Just noticed that this is an NXP document. Does the logic/math even apply to a PIC?
 
Pommie if you have a clock rate mismatch you can't correct for it, it's always there, it has to be divisible. RS232 baud rates are rather specific, and very different from typical crystal values.
 
Sceadwian, if you use the internal clock at 32MHz and use the auto baud rate detect feature of the pic, your RS232 bit rate error will be less than 0.25% even though your clock might be 5% out. This is because the auto baud rate detect uses the other machines data rate to set its own baud rate generator.

With a crystal the baud rate is normally well within the required tolerance.

Note that this only applies to newer pics with the 16 bit baud rate generator.

Mike.
 
Status
Not open for further replies.

Similar threads

1
  • Question
Internal corrosion on a circuit?
Replies
10
Views
2K
1-3-2-4
1
  • Question
Relaxation Oscillator Help
Replies
13
Views
4K
Athosworld
U
  • Question
Oscillator - SIT8008AI-82-33E-28.636360
Replies
4
Views
2K
rjenkinsgb
  • Question
Single or Dual output on generator ?
Replies
3
Views
2K
KatharynBrowne
K
D
RTC 32.768khz oscillator stuck
Replies
8
Views
2K
ZipZapOuch
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…