PIC16F88 Internal clock and Baud Rate problem

[ShellTox]

Hello

I'm using a PIC16F88 with 8MHz internal clock. I'm trying to send data through USART at 57600 Baud. The compiler gives me an error that this value is not supported. After reading the datasheet of this PIC, this value seems to be supported.

I've also tried to use 56000 Baud, but the data I'm sending sometimes gets corrupted, in a cyclic way.

I've managed to put it to work with 38400 Baud, but I need to speed up the communication. Does anyone knows why this is happening?

[sirius]

Obviously you've made a mistake when configuring project properties.Firstly,look at "General" tab,when creating the project you have to select "Internal RC Osc,no CLKOUT" or "Internal RC Osc" .Type in "Oscilator Frequency" - 8000000 /actually you've done this/. At "Communications" tab choose RS-232 properties,I think here everything is clear.And lastly, at "Intr Oscillator Config" tab, check off "Enable Internal Oscillator" checkbox, "System Clock Select" - "Internal Oscillator, "Mode" - 8Mhz. If you manage to configure these properties - your problem will be solved!

P.S.
I compiled it,no problem,regardless of the baud error.The compiler gives no errors!

[PCM programmer]

[ShellTox]

Hello

Thank you for the quick answers


@sirius: I'm using MPLAB as IDE with CCS compiler. I think you are using CCS IDE.

@PCM programmer: Thank you for the baud rate tool, it's very usefull.
And yes, the +-2% deviation margin is violated with 57600 baud @ 8MHz
internal clock. I still have a question! Using 56000 baud @ 8MHZ internal
clock, the deviation is way below 2% as shown in the picture below.



With this configuration I'm still receiving some cyclic errors in SIOW. It should work... right?

This is what I get in SIOW:

X= 410;Ù= 547;Z= 384;
Ø= 410;Y= 547;Z= 384;
X= 410;Y= 547;Ú= 384;
X= 410;Y= 547;Ú= 384;
X= 410;Ù= 548;Z= 384;
X= 410;Y= 548;Z= 384;
X= 410;Ù= 547;Z= 384;
Ø= 411;Y==547;Z= 384;
X= 410;Y= 547;Ú= 384;
X= 410;Ù= 548;Z= 384;
Ø= 410;Y= 548;Z= 384;
X= 410;Y= 548;Z= 384;
X= 410;Y= 547;Ú= 384;
X= 410;Ù= 548;Z= 334;
Ø= 410;Y= 548;Z= 384;

This should be the correct frame:

X= 410;Y= 548;Z= 334;

I've also tried to use 55555 baud to match exactly the calculation, but the results were the same.

[PCM programmer]

Do we know if the UART in your PC can do 56000 baud accurately ?

It would be better to choose a different baud rate, or change the PIC's
crystal frequency, so that a standard baud rate can be used.

[ShellTox]

You're right about that. The only thing I know about the baud rate accuracy in my PC is in SIOW. There I choose a custom baud rate and enter 56000, but that doesn't guarantees accuracy.

[Ttelmah]

Assuming your PC has a standard UART, and clock generator, it'll give:

115200 = 115384
57600 = 57692
56000 = 55556

So just over 1% error on the 56000 selection.

It is also worth checking in your BIOS, if you have an option for 'spread spectrum'. This is a feature on some PC's, designed to improve the ability of the units to pass certain RF tests, by slightly modulating the master clock. On some chipsets, this (incorrectly) modulates the clock used to generate the serial if selected, causing problems....
If you have this, disable it. This would cause a cyclic error.

Then, what length are your cables, and how is your drive hardware done?. RS232, is only specified for 3m cables max, at 56Kbps. It often 'gets away' with more, but you may simply be having a problem here. Mobile phone renegotiating at a regular interval for example....

Best Wishes

[asmboy]

Am I the only one who has noticed that he checked the BRGH16 box
on the PIC baud checker ?

That is an 18F capability that I am sure the 16f88 DOES NOT HAVE.

The true error is just as PCM warned , -3.55% - and a bit nasty.

I use 38400 all the time at 8mhz INT_OSC with various host UARTS ,
most happily - but that is my std baud upper limit.

[FvM]

[asmboy]

with 1.8432 mhz ref osc chip the 16550 and 16450 family used in PCs and elsewhere can make the fractional 1/2 divisor freqs of 28.8 and 57.6 kb
no problem - BTW the divisor for the part is 32 @ 56.6

http://pdf1.alldatasheet.com/datasheet-pdf/view/9301/NSC/PC16550D.html


the 8250 -> 16450 - 16550 16c55x family are the most widely used / china chip copied uarts out there - in PC / linux architecture.
c for yourself - very simple
divide 1.8432mhz by YOUR desired baud rate and see if you get an integer divsor- ( 1.8432mhz is the commonest xtal freq in PC and linux mfgr reference BIOS D-kits too )

take it to the bank - i've been dealing with this sort of issue for over 10 yrs now.
been there - done that - got the dirty t shirt 2 prove it

[Ttelmah]

[Charlie U]

I don't know if I missed it above, but the tolerance of the internal osc. frequency is +/-1% typical, +/-2% max @ 25degC. This is the "sweet" spot. The possible error increases as the temperature varies. You could easily have a device that is 1% or more off center to start with. Any other errors would be compounded by this. Personally, I never rely on the internal oscillators if I need to use async serial comms.

[ShellTox]

Hello

@Ttelmah:

In my BIOS, I don't have a 'spread spectrum' option. My cable is about 1.5 meters long (USB to RS232 converter) and I'm using the MAX232 in the PICDEM 2 plus

[Ttelmah]

USB to RS232....

These don't use the internal clock for RS232 at all. They develop the baud rates internally. They are sometimes less than perfect (some use ceramic resonators, and give the wrong baud rates if used outside an office environment - others fail completely, usng the same resonator for USB, which fails if the clock drifts by more than 1:10000.....).

What baud rates are 'really' available, will depend on the unit. I'd stick a digital scope on the signal, and see what it is really sending.

Also, many of these only use 5v RS232, and can be annoyingly bad.

What is the make of the unit?. What chipset (device manager)?.

Best Wishes

[ShellTox]

The converter manufacturer is Prolific. I couldn't find the chipset. Details follow: