Osctune

[Charles Linquis]

The oscillators are close when they come from the factory, but I need 100% reliable communication at 19.2K baud, over the temperature range of -45 to 100C when running from a 4Mhz internal oscillator, and the supply voltage varying between 4.7 and 5.1V.

Now you see why I'm interested in frequency stability and calibration!

Amazingly, the 18F2221's (without calibration) are *usually* good enough to get this done.

[rmteo]

The oscillators are close when they come from the factory, but I need 100% reliable communication at 19.2K baud, over the temperature range of -45 to 100C when running from a 4Mhz internal oscillator, and the supply voltage varying between 4.7 and 5.1V.

Why not use the AUTO-BAUD RATE DETECT feature - no calibration needed and automatic compensation for temperature/voltage variations? Also works with other oscillator modes (XT, HS, EC) besides IntOSC and high baud rates - I use it with speeds up to 230,400 baud.

[Charles Linquis]

I see what you mean. I have never used that feature before. Time to try it!

[rmteo]

I see what you mean. I have never used that feature before. Time to try it!

Another neat thing about this feature is that you do not have to set a fixed baud rate in your firmware. I have used it (with IntOSC) to communicate at any standard speed from 2,400 to 230,400 baud. Auto-Baud detect is only available on devices that have an EUSART - most PIC18s (and some PIC16s) do.

[Charles Linquis]

I'm assuming it will pick "odd" baud rates (like 18200 buad, which can result from off-frequency oscillator). I would need that.

And I always use the "better" chips. I figure that trying to save $2.00 by using a 16F rather than an 18F chip, and then spending a week overcoming its weaknesses is false economy.

[rmteo]

The nice thing is that it doesn't matter if your PIC18 is off frequency or the sending device is off frequency - it just syncs both units to each other.

[Charles Linquis]

In my case, I'll have to read the resultant SPBRG and use that to calculate the value for my DEBUGOUT command as well.

I have a large network of connected devices. The Master (18F8723) polls the SLAVES (a bunch of 18F2221's). It sends out an 'Attention' byte, followed by the Slave's address, followed by a command and finally, a checksum.

The Slave uses the Receive part of it's EUSART so I can easily use interrupts
to grab the data. But when answering, the slave must 'speak' open-collector to avoid bus contention. I don't have room for an O.C. gate on the slave, so I can't use the Transmit part of the '2221's EUSART.

So, I use a different pin (not PORTC.6) to do the send. I use DEBUGOUT in order to get 19.2Kbaud with a 4MHz oscillator. And before you ask....
I modified PBPPIC18LIB to add a switch to DEBUGOUT that allows it to run in an open-collector mode.

It all works like a charm.

[languer]

So what you were looking for was not really to calibrate it, but to reduce the inherent error that occurs when using a close-enough (but not exact source) for the BAUD generator. This makes more sense (since the Oscillators are trimmed at the factory for 8MHz, before they leave the factory).

Note that 4MHz gives you 0.16% error on the 19,200 BAUD generator. On the other hand, 3.9936MHz is right on. So maybe this was the answer you were looking for through experimentation.