Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Cannot get 57600 b/s on 18f452

Status
Not open for further replies.

BOBKA

New Member
Hi, I am trying to get as much as possible from my serial connection. I am using 10Mhz xtal in HS+PLL mode (total of 40MHz).

at the top of my program I define

#define BAUD d'57600'
#define XTAL d'10'
#define X ((XTAL*d'1000000')/(d'64'*BAUD))-1

and then in the program I clear the BRGH bit (making the speed slow - and what is the limit here?).

Instead of the desired chars, I am getting some garbage. If I reduce the speed to 38400 b/s (or lower), everything works just fine.

I also tried
#define X ((XTAL*d'1000000')/(d'16'*BAUD))-1
and then set BRGH bit high, so I started to get some new garbage. I also tried to change the XTAL to 40, but no success.

Two questions:
1. what is the bitrates for BRGH=1 and BRGH=0?
2. is this a limitation of a pic/max/pc?

PS: I am using COM2 on pc which is set to 115200 in devices, and then set to appropriate BAUD in terra term. Also, fifo buffers are off.


Thank You.
 
BOBKA said:
Hi, I am trying to get as much as possible from my serial connection. I am using 10Mhz xtal in HS+PLL mode (total of 40MHz).

at the top of my program I define

#define BAUD d'57600'
#define XTAL d'10'
#define X ((XTAL*d'1000000')/(d'64'*BAUD))-1

and then in the program I clear the BRGH bit (making the speed slow - and what is the limit here?).

Instead of the desired chars, I am getting some garbage. If I reduce the speed to 38400 b/s (or lower), everything works just fine.

I also tried
#define X ((XTAL*d'1000000')/(d'16'*BAUD))-1
and then set BRGH bit high, so I started to get some new garbage. I also tried to change the XTAL to 40, but no success.

Two questions:
1. what is the bitrates for BRGH=1 and BRGH=0?
2. is this a limitation of a pic/max/pc?

PS: I am using COM2 on pc which is set to 115200 in devices, and then set to appropriate BAUD in terra term. Also, fifo buffers are off.


Thank You.
Try the 10mhz high speed and x=10 or 40mhz, low speed, and x=10... i am surprised no one responded ... one has to wonder...

Dan
 
Assuming integer division, and the parentheses the value of X is 1. I'm no expert but I think the error is kinda large. Using the value 1 the calculated baudrate is 78125. Sure enough this error is just too large. If you use BRGH = 1 to use a 16x baudrate clock then I compute a value of 9. This gives an actual baudrate of 62500. This is better but not quite what you want. If you need 57600 then I suggest that you consider changing crystals so that you get what you want. I think that 9.216 MHz. would work, and there may be other values
 
Last edited:
Papabravo said:
Assuming integer division, and the parentheses the value of X is 1. I'm no expert but I think the error is kinda large. Using the value 1 the calculated baudrate is 78125. Sure enough this error is just too large. If you use BRGH = 1 to use a 16x baudrate clock then I compute a value of 9. This gives an actual baudrate of 62500. This is better but not quite what you want. If you need 57600 then I suggest that you consider changing crystals so that you get what you want. I think that 9.216 MHz. would work, and there may be other values
According to the data sheet:
--------------------------------
Solving for X:
X = ( (FOSC / Desired Baud Rate) / 64 ) – 1
X = ((16000000 / 9600) / 64) – 1
X = [25.042] = 25
--------------------------------
10000000/57600/16-1 (for BGRH=0=high speed, 64 is for low speed) = 10
Going the other way we get 56818 for an error of 1.3%
The moral of the story is: counters do not use integer division.

Dan
 
Nicely worked out cadstarsucks, but you misssed the fact that he's using the 18F in HS+PLL mode, which means it runs at 40Mhz instead of 10MHz. But what you probably didn't know is that the PICList has an online generator for these values at this gives either a +1.4% (43 and BRGH=1, or 10 and BRGH=0) or -0.9% (42 and BRGH=1) error using 40MHz.
 
My SPBRG Calc application shows similar results with better tolerance for 57600 baud using BRGH=1.

The SPBRG Calc spreadsheet (post #1) and single file application (post #5) can be found on this Forum.Microchip thread; **broken link removed**

spbrg-calc-screen-shot-png.11681


The Spreadsheet can provide SPBRG solutions for non-standard baud rates (by editing the BAUD rate cells in the left most column).

**broken link removed**
 

Attachments

  • SPBRG Calc Screen Shot.PNG
    SPBRG Calc Screen Shot.PNG
    28.2 KB · Views: 526
Last edited:
Nigel Goodwin said:
Nicely worked out cadstarsucks, but you misssed the fact that he's using the 18F in HS+PLL mode, which means it runs at 40Mhz instead of 10MHz. But what you probably didn't know is that the PICList has an online generator for these values at this gives either a +1.4% (43 and BRGH=1, or 10 and BRGH=0) or -0.9% (42 and BRGH=1) error using 40MHz.
Actually he said he had tried both. The switch to 40MHz only entails using the low speed option instead of the high speed one. I did look it up. You see, I do this sort of thing all the time at work as the software guys tend to miss the minutia.

The spreadsheets can often have errors if they are included at all. My boss has learned that it is better to trust my position than most any other in the school of hard knocks.

For me to find and answer that question was all of 10 minutes because it is what I do every day for a living. That and find the most effective solutions for a whole myriad of design problems.

Dan
 
Last edited:
Thank you guys for you response. I have played with it a little bit more. It appears that the XTAL should be the actual clock at the clock pin and not the one after the PLL. I figured out that the clock division was the limiting factor, so I will be stack with it for a while.

I finally figured out how the BRGH works, to summarized:

There are two models for calculating SPBRG, one is based on low speed transmission (BRGH=0) and the other is based on high speed transmission (BRGH=1). Those high/low speed transmission settings can be derived from looking at the results of those two models.
Low speed transmission: SPBRG = (XTAL*d'1000000')/(d'64'*BAUD_RATE) - 1
High speed transmission: SPBRG = (XTAL*d'1000000')/(d'16'*BAUD_RATE) - 1
* the SPBRG should be rounded to the nearest integer
*BAUD_RATE is the desired baud rate (19200, 57600, etc)

Since the above SPBRG equations round the results, we want to calculate the actual transmission rate, and the percentage error due to this rounding.
low speed: ACTUAL_BAUD = XTAL*d'1000000' / (d'64'*(SPBRG+1))
high speed: ACTUAL_BAUD = XTAL*d'1000000' / (d'16'*(SPBRG+1))

The percentage error is calculated as (same eqn for both models):
% error = ((ACTUAL_BAUD-BAUD_RATE)/BAUD_RATE)*100%



Example: we want to get transmission rate of 19200 bits/s w/ crystal of 10M
=> XTAL=10, BAUD_RATE=19200

low speed: SPBRG = (10*1000000) / (64*19200) - 1 = 8.138 - 1 => 7
ACTUAL_BAUD = 10*1000000 / (64*(7+1)) = 19531.25
% error = ((19531.25-19200)/19200) * 100% = 1.73%

hish speed: SPBRG = (10*1000000) / (16*19200) -1 = 32.55 - 1 => 31
ACTUAL_BAUD = 10*1000000 / (16*(31+1)) = 19531.25
%error = 1.73% as for low speed, but if we were to round the SPBRG, we would get SPBRG= 32.55-1 = 32,
then ACTUAL_BAUD = 10*1000000 / (16*(32+1)) = 18939.4
and %error = ((18939.4-19200)/19200) * 100% = -1.14%

Results: using high speed model is always better cause it provides smaller % error. The only situation where it cannot be used, is when SPBRG for it is greater than 255. This will typically occur at high clock frequencies and very slow transmission rates. In this cases low speed transmission model should be used.

Hope this will help someone :)
 
BOBKA said:
It appears that the XTAL should be the actual clock at the clock pin and not the one after the PLL.

Are you 100% sure about this?

The baudrate table shown in Microchip datasheet has an entry for 40MHz, which could be the result of using 10MHz crystal + 4x PLL. It also has an entry for 10MHz too. The SPBRG values are different.

How do the above program knows whether PLL is used or not?
 
Last edited:
eblc1388 said:
Are you 100% sure about this?

Sounds wrong to me.

The baudrate table shown in Microchip datasheet has an entry for 40MHz, which could be the result of using 10MHz crystal + 4x PLL. It also has an entry for 10MHz too. The SPBRG values are different.

How do the above program knows whether PLL is used or not?

I suspect he's possibly not got the clock multiplier switched on?, so is only running at 10MHz.
 
Actually the way I tested it is by changing the configuration bits in MPLAB (7.50). I got desired output when using HS mode and using HS+PLL mode (the same SPBRG value). From this I concluded that it is the incoming clock and not the one after PLL. I will double check this when I'll arrive home.
 
Guys, I did change it in the MPLAB (and as a result the checksum changes), and it happens that it doesn't depend on the PLL.
 
I believed you have really done so. Unfortunately I don't know why the PIC does not switch into PLL mode.

I can confirm that the PLL does indeed increases the MCU internal clocking to 4x crystal frequency, and that affects also the baudrate generator.

Therefore you will need to use a different SPBRG value if you enable the PLL.

See also the last post here:
HSPLL baud setting (SPBRG)

And the second post here:
Problem with baud rate generation 18f452
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top