usart baudrate problems :"Baud rate out of range"

Guest · Posted: Wed Jan 18, 2006 1:55 am

I get the above Compiler Error when I use the following for a PIC18F6620:

janneb · Joined: 18 Jan 2006 Posts: 3

This is just to show, that I am the "guest" that just made the above post...

Wink

Jan

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

The baud rate calculator that I have, says the error is 3.549%.
If your only goal is to get it to compile, there are a couple ways to do it.

1. You can put in the actual rate that you will get, which is 111111 baud.
Then the compiler will calculate 0% error, and it will compile. Example:

set_uart_speed(111111);

2. You can alter the #use delay() clock value temporarily, so that
the error rate calculated by the compiler is just under 3%.
Then it will compile.

#use delay(clock=16100000)
set_uart_speed(115200);
#use delay(clock=16000000) // Restore correct value.

This answers the narrow question of how to make it compile.

janneb · Joined: 18 Jan 2006 Posts: 3

Thanks for your interest, BUT, you misunderstood my question...
I understand that making code changes, can make it compile OK,
BUT how is it possible to get a downloadable .HEX file WITHOUT changes?

How was it possible for the original code writer to compile this code OK???

Is it possible to tell the MPLAB Environment/CCS Compiler to "ignore" the Error and continue compilation?

Confused

Jan

Ttelmah · Guest

Historically, the margin allowed for baud rate errors, was greater on older versions of CCS. There were then complaints, that the serial often didn't work, so the margin was tightened. This probably explains the successful compilation in the past.
Given that you only want to change the UART speed, simply go DIY, without the checking.
It is not exactly complex, to do a define, that divides the clock rate, by the desired baud rate*4, subtracts one, and loads this into SPBRG. This then won't complain, but will leave you with the risk of unreliable comms.

Best Wishes

janneb · Joined: 18 Jan 2006 Posts: 3

Thanks again for yet another workaround...

I know that this code has been compiled recently (last 6 months), but I do NOT know how old the compiler used, was... Maybe it allowed > 3%?

If I use 114600 to be just below 3%, the connection is very unstable (at least when I'm using a portable Toshiba).

I also have gotten a USB->RS232 converter, that allows up to 128000.
Using this setup, gives me a completely "stable" connection...!

Thanks all!

Wink

KEEP SMILIN' (;>) Jan