Searching \ for '[PIC] calculate Fosc and Baud rates' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'calculate Fosc and Baud rates'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] calculate Fosc and Baud rates'
2012\03\22@190328 by Bill Stoddart

picon face
Hello,
This feels like a simple question but I've had very little luck finding any
answers.

I have an 18F4550 on the PICDEM FSUSB board. It has a 20Mhz crystal. I am
trying to send data out over rs232. I have gotten everything working at
9600 baud but this is just barely able to keep up with my data source
(clocked in from an FPGA).

I have been programming with the hi-tech compiler and MPLAB.

Code for the usart:
OpenUSART(USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE &
USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_LOW, 78);

Header code:
#define _XTAL_FREQ 20000000  // (20 MHz crystal on PICDEM FS USB board)

#pragma config PLLDIV   = 5
#pragma config CPUDIV   = OSC1_PLL2
#pragma config USBDIV   = 2
#pragma config FOSC     = HSPLL_HS

I would appreciate any help calculating out the numbers for a higher speed.
I have been shooting for 115200 with out any luck. I've gone through the
datasheet but i'm lost.
Thanks in advance.
Bil

2012\03\22@191526 by Jan-Erik Soderholm

face picon face
Bill Stoddart wrote 2012-03-23 00:03:
{Quote hidden}

Can you get it working with some simple assembler code?
Should just take 10-15 lines to make a short USART test to
send something out. Then, with the params worked out, one
can/could translate them into whatever high-level language
one is using.

2012\03\22@192101 by Scott

picon face
> I would appreciate any help calculating out the numbers for a higher speed.
> I have been shooting for 115200 with out any luck. I've gone through the
> datasheet but i'm lost.

Have you taken a look at Table 20-3: "BAUD RATES FOR ASYNCHRONOUS MODES"?

This has all the information necessary to produce the desired baud rate.

-Scot

2012\03\22@194411 by IVP

face picon face
> I have been shooting for 115200 with out any luck

Hi Bill,

Section 20.1 of DS39623B outlines how to select a baud rate

(it's been a little while since I did this, apologies for any errors)

BRGH = 0

((Fosc/baud rate)/64)-1

((20000000/9600)/64)-1

BRG = 31.55

((20000000/115200)/64)-1

BRG = 1.71

With BRGH = 1

((20000000/115200)/16)-1

BRG = 9.85 (call it 10)

The actual baud rate is

20000000/(16(10+1))

= 113636

with an error of (113636 -115200)/115200 = 1.36% slow. This would
probably not be a problem if each frame is synched. For long streams
with no reference the receiver will drift away from the incoming data

A 'hexadecimal' crystal is more suitable for common baud rates, but
whether you can or do use one depends on the functional priorities. For
example if a microsecond timer is more important than comms, then a
20MHz would be preferable (for the 200ns cycles). You might have to
compromise somewhere

An 18.432MHz crystal in the calculations

((18432000/115200)/16)-1

= 9.000000, no error

Jo

2012\03\22@201244 by Isaac Marino Bavaresco
flavicon
face
Em 22/3/2012 20:44, IVP escreveu:
{Quote hidden}

The problem is that the USB peripheral needs a 48MHz clock to operate.
The main clock is constrained to values that after being multiplied by
the PLL and divided by the pre/postscalers can result in an USB clock of
48MHz.


Isaac

2012\03\22@203725 by Isaac Marino Bavaresco

flavicon
face
Em 22/3/2012 20:44, IVP escreveu:
{Quote hidden}

Values of Fosc multiple of 6MHz work better. Select the source for the
CPU clock from the PLL output (96MHz) divided by 2 or 4.

Common rates up to 19200 result in exact dividers, higher common rates
result in very small rate errors.


With BRG16 = 1 and BRGH = 1, assuming a 48MHz Fosc (12MIPS):

SPBRGH:SPBRG = Fosc/(4*Rate) - 1

SPBRGH:SPBRG = 48e6/(4*115200) - 1 = 103,1666... => 103 => Actual baud
rate = 115384 (+0.16%)


Isaac

2012\03\22@204440 by IVP

face picon face
> The problem is that the USB peripheral needs a 48MHz clock to operate

Yes, I did say

"whether you can or do use one [a hexadecimal crystal] depends on
the functional priorities"

As this is on an FSUSB board there's not much Bill can do wrt accuracy
of the actual baud rate without upsetting the USB

Jo

2012\03\22@222512 by Isaac Marino Bavaresco

flavicon
face
Em 22/3/2012 21:44, IVP escreveu:
>> The problem is that the USB peripheral needs a 48MHz clock to operate
> Yes, I did say
>
> "whether you can or do use one [a hexadecimal crystal] depends on
> the functional priorities"
>
> As this is on an FSUSB board there's not much Bill can do wrt accuracy
> of the actual baud rate without upsetting the USB
>
> Joe


Yes, there is, he can use BRG16 = 1 and BRGH = 1.


Isaac

2012\03\23@072607 by alan.b.pearce

face picon face

> A 'hexadecimal' crystal is more suitable for common baud rates, but
> whether you can or do use one depends on the functional priorities. For
> example if a microsecond timer is more important than comms, then a
> 20MHz would be preferable (for the 200ns cycles). You might have to
> compromise somewhere
>
> An 18.432MHz crystal in the calculations
>
> ((18432000/115200)/16)-1
>
> = 9.000000, no error
>
There is also a 19.something that gives exact baud rates (19.66088? or something like that). The other option would be to 'overclock' slightly at twice 12.288 which is also an exact baud rate frequency (hence it tended to be used as the standard frequency for 8080 CPUs).


-- Scanned by iCritical.

2012\03\23@083012 by Bill Stoddart

picon face
Thanks to everyone who chimed in, it got me thinking through the problem
better.

I think I am doing the calculations correctly but some of the baud rates
I'd chosen must have had too much of an error.

I am able to run at 9600 with 8 bit, BRGH=0, BRG=78 and at 115200 with 8bit
BRGH=1, BRG=25.

I tried to run 9600 with 8bit BRGH=1, BRG=311 with no luck.

This is all still using 48MHz.

Thanks again
Bill

On Fri, Mar 23, 2012 at 7:26 AM, <spam_OUTalan.b.pearceTakeThisOuTspamstfc.ac.uk> wrote:

{Quote hidden}

>

2012\03\23@094501 by Jan-Erik Soderholm

face picon face


Bill Stoddart wrote 2012-03-23 13:30:
> Thanks to everyone who chimed in, it got me thinking through the problem
> better.
>
> I think I am doing the calculations correctly but some of the baud rates
> I'd chosen must have had too much of an error.
>
> I am able to run at 9600 with 8 bit, BRGH=0, BRG=78 and at 115200 with 8bit
> BRGH=1, BRG=25.
>
> I tried to run 9600 with 8bit BRGH=1, BRG=311 with no luck.
>

I think you must be a bit more carefull with what you write.

There is no "BRG" register at all in the 18F4550!

There is a SPBRG register (in 8 bit baudrate mode) and a
SPBRGH/SPBRG register pair (in 16 bit baudrate mode).

Then there is control bit BRG16 that selects between 8 (default
at POR) and 16 bit mode.

I'm not sure what the "with 8bit" stands for.
8 bit characters or 8 bit baudrate register.

Of course one can't set BRG=311 if in 8 bit baudrate register mode.

Jan-Erik.


{Quote hidden}

>> -

2012\03\23@095340 by Bill Stoddart

picon face
Jan-Erik,
You've cleared up one bit of confusion I had... I didn't understand how the
register size was the size of that register. It seems obvious now :\

I did mean 8 bit registers.

Thanks
Bill

On Fri, Mar 23, 2012 at 9:45 AM, Jan-Erik Soderholm <
jan-erik.soderholmspamKILLspamtelia.com> wrote:

{Quote hidden}

2012\03\23@101731 by Isaac Marino Bavaresco

flavicon
face
Bill,


Using BRG16 = 1 and BRGH= 1 changes the formula to Fosc / ( 4 * rate ) -
1, resulting in many more options of dividers.
With FOsc = 48MHz and the above setting you can obtain all the normal
baud rates from 300bps and up with an error of at most 0.2%.


Isaac



Em 23/3/2012 09:30, Bill Stoddart escreveu:
{Quote hidden}

>> -

2012\03\23@175552 by IVP

face picon face
> With Fosc = 48MHz

The OP said the PICDEM FSUSB has a 20MHz crystal. I'm not
familiar with that board. Can it be changed to 48MHz

2012\03\23@180945 by IVP

face picon face
> There is also a 19.something that gives exact baud rates (19.66088?
> or something like that)

Yes, it's 19.6608. I use them often on -20 parts, and the 9.8304 on
-10 parts or 4 * PLL with -40 parts. Sometimes for comms, and they
are good for clocks because of their divide-by-256-iveness

19.6608 doesn't get you an error-free 115200 comms unfortunately,
whether BRGH = 0 or 1

19660800/115200 = 170.666666 => BRG = 1.6666 or 9.6666

It's OK for other baud rates though

19660800/9600 = 2048.0000

2012\03\23@182434 by Isaac Marino Bavaresco

flavicon
face
Em 23/3/2012 18:55, IVP escreveu:
>> With Fosc = 48MHz
> The OP said the PICDEM FSUSB has a 20MHz crystal. I'm not
> familiar with that board. Can it be changed to 48MHz ?

The PIC18F4550 and siblings have a PLL with a prescaler. The input to
the PLL must always be 4MHz and its output is always 96MHz.
Certainly he is dividing the 20MHz by 5 to get the correct input of 4MHz
to the PLL.

The PLL output is routed to a divider by 2 to clock the USB peripheral
and can also be routed to another divider by 2, 3, 4 or 6 to clock the CPU.


Isaa

2012\03\23@183705 by peter green

flavicon
face
IVP wrote:
>> With Fosc = 48MHz
>>    
>
> The OP said the PICDEM FSUSB has a 20MHz crystal. I'm not
> familiar with that board. Can it be changed to 48MHz ?
>   The picdem FS USB has a PIC18F4550. Due to the USB the
PIC18f4550 has a rather unusual clock block. Normally*
the incoming clock is divided down to 4MHz, then multiplied
up to 96MHz then divided down again for the USB and
primary clock.

So with this chip it's perfectly normal to have a 20 MHz
crystal and yet have a "primary clock" of 48 MHz.

* You can also bypass the 96 MHz pll and drive core and/or
USB directly off the oscilator but I don't think i've ever seen it done

2012\03\23@185223 by IVP

face picon face

> The PIC18F4550 and siblings have a PLL with a prescaler. The
> input to the PLL must always be 4MHz

I've used the 4550 a few times and know its oscillator block. My
query was whether the board crystal can be swapped for another
if serial comms (not USB) was Bill's priority and error rates with
the 20MHz were unacceptable. As you've shown though he can
get close enoug

More... (looser matching)
- Last day of these posts
- In 2012 , 2013 only
- Today
- New search...