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

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 hitech 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
JanErik Soderholm
Bill Stoddart wrote 20120323 00:03:
{Quote hidden}> 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 hitech 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.
> Bill
Can you get it working with some simple assembler code?
Should just take 1015 lines to make a short USART test to
send something out. Then, with the params worked out, one
can/could translate them into whatever highlevel language
one is using.
2012\03\22@192101
by
Scott
> 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 203: "BAUD RATES FOR ASYNCHRONOUS MODES"?
This has all the information necessary to produce the desired baud rate.
Scot
2012\03\22@194411
by
IVP
> 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

Em 22/3/2012 20:44, IVP escreveu:
{Quote hidden}>> 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
>
> Joe
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

Em 22/3/2012 20:44, IVP escreveu:
{Quote hidden}>> 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
>
> Joe
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
> 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
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
> 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

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.pearceTakeThisOuTstfc.ac.uk> wrote:
{Quote hidden}>
> > 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@094501
by
JanErik Soderholm
Bill Stoddart wrote 20120323 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.
JanErik.
{Quote hidden}> This is all still using 48MHz.
>
> Thanks again
> Bill
>
> On Fri, Mar 23, 2012 at 7:26 AM,<
.....alan.b.pearceKILLspam@spam@stfc.ac.uk> wrote:
>
>>
>>> 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@095340
by
Bill Stoddart

JanErik,
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, JanErik Soderholm <
janerik.soderholmKILLspamtelia.com> wrote:
{Quote hidden}>
>
> Bill Stoddart wrote 20120323 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.
>
> JanErik.
>
>
> > This is all still using 48MHz.
> >
> > Thanks again
> > Bill
> >
> > On Fri, Mar 23, 2012 at 7:26 AM,<
.....alan.b.pearceKILLspam.....stfc.ac.uk> wrote:
> >
> >>
> >>> 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@101731
by
Isaac Marino Bavaresco

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}> 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, <
EraseMEalan.b.pearcespam_OUTTakeThisOuTstfc.ac.uk> wrote:
>
>>> 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@175552
by
IVP
> 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
> 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 divideby256iveness
19.6608 doesn't get you an errorfree 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
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
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
> 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...