Post by thread:Internal oscillator calibration

Gabriel, Yes, you can and should trust the factory calibration. I have designed more than one 12C5xx based commercial product with RS232 communications code, and they work just fine (they always stay within +/- 3% over voltage, temperature and process variations). Study the F vs. Vdd and Fosc vs. T oscillator calibration charts in the data sheets, and pick an operating voltage and temperature consistent with your requirements. The oscillator frequency is guaranteed to be within the guardband they show in the charts (and is usually and typically much tighter than that). If you apply the full T and Vdd range of your expected operating environment, you must expect to see Fosc anywhere in that range, especially over very large volumes of chips. Always attempt to accommodate your design for 3 sigma variation, and you won't have any problems with these parts. If you attempt or need to dynamically modify the factory calibration value, remember that incremental changes in the OSCCAL value shift the oscillator period in 4ns increments, (initially a 1.6% frequency shift from the median or center frequency of 4 MHz). I've discussed this issue in a prior thread, and without repeating the details, I was privileged to conduct extensive calibration testing in conjunction with Microchip on the 12C5xx parts, and know that with proper design practices you shouldn't have any problems with oscillator frequency. Chuck Mauro <snip> > I am sorry for being ambiguous on my request. > My application is not really that critical, it is for RS232 comms. But > the > real question should have been: How much can I trust the factory > oscilator > calibration for the 12C5xx PICS??? > > Gabriel > <snip>

I can think of a number of ways... Example: if you know you are connected to a [inherently] calibrated system - a PC's serial port for example (the baud xtal is orders of magnitude tighter spec'd than the RC osc of the PIC), you can "autobaud" detect the bit timing of an incoming serial stream. Doing this every so often over time can provide data to derive a dt correction factor. Once a +/- dt becomes large enough to be accommodated by a single OSCCAL increment (4ns), you could adjust your bit timing code in your serial routines to reflect the fact. It's not a perfect scheme, but given the resolution of the system, it would tend to work nicely. If you design your code to trigger events from the timer, then the entire system can be adjusted to accommodate any drift. This should take care of all factors: Vdd, T, and process variations. It does, however, rely on some knowledge of an external indirect reference... - Chuck Mauro > {Original Message removed}

to add to this the RS232 is a fairly forgiving self synchronizing protocol that in a well designed system gets sampled in the center of the bits , if you send startbit+8 databits +stopbit and one end ( the PC) is clocked with a x-tal timebase and at the correct frequency theoretically you are OK if you are less than 1/20 Th. (half of the bit time) off , this is 5%high or 5%low Most hardware will also have enough margin so a half a stopbit is enough to re-synchronize, you could always send a little longer than the number of stopbits without bad effects other than slowing down the stream of data a little. Peter {Original Message removed}