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)
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
> 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.
> Bill
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.
> 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.
> 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
>> 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.
>> 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):
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
> 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).
>
> > 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.
>
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.
> 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.
>>
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 :\
>
>
> 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.
>
>
> > 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.
> >>
> >> --
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.
>>
> 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
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.
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
> 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