Osctune

[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.

[Heckler]

Hey folks, I finally had a chance to grab a NEW PIC and read it to try and view this factory calibration value. But I can't seem to find it.

So as I stated earlier I have only 12F683, 16F688 & 16F690 chips. If I put a NEW pic in my programmer (pickit2 w/low pin count demo board) and then "read" the chip, all I see in the "Program Memory" window is "3FFF" in all memory locations. In the "EEPROM" window is "FF" in all locations.

Where do I look to find this "osccal" factory calibration value?
Are these chips just too "low end" to have this calibration value?

Why do I see "3FFF" in the program code area? This translates to 14 binary bits of "1". Why 14 bits? (the .pdf documentation says the 16F688 is an 8bit mcu)

Is it possible to view all the other "special function registers"? As I look at the .pdf it shows various values for the registers on power-up, and they are NOT all 1's.

HELP!!

Dwight