For a project I'm working on, the 4x increase in speed with the PLL enabled will be beneficial. I had it enabled with a 20MHz crystal, overclocking the PIC to 80MHz and everything seemed to work fine.
Everything until the USART. Even dropping back to a 12MHz crystal (I don't have any 16MHz on hand), I can't find any combination of settings to make the USART routines work properly. Without the PLL enabled, it works great. I'm communicating with a CH340G USB chip.
So, a few questions:
1. When using the PLL, should the crystal frequency be multiplied by 4 for the CLOCK statement, or is it necessary to manually account for the speed differences in delay statements and etc.?
2. What tweeks do I need to make to get the UART to work with the PLL enabled? With br=9600, and the clock frequency set to the actual crystal value, I'd expect the actual baud rate to be 38,400 but this results in giberish being received by the CH340G.
Thanks for any help,
Jon
USART Module with 18F26k22 and PLL Enabled
Moderators: David Barker, Jerry Messina
-
- Registered User
- Posts: 185
- Joined: Mon Mar 10, 2008 8:20 am
- Location: Seattle, WA USA
- Contact:
-
- Swordfish Developer
- Posts: 1486
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: USART Module with 18F26k22 and PLL Enabled
Always use the real clock freq you'll be running at for 'clock = ' ie 40, 64, 80, etcshould the crystal frequency be multiplied by 4 for the CLOCK statement
The standard usart module defaults to BRGH=true, BRG16=false and the calcs peter out as you go higher in clock freq and lower in baudrate without warning. Try using
Code: Select all
#option USART_BRGH = true // module default = true
#option USART_BRG16 = true // module default = false
include "usart.bas"
Code: Select all
Public Sub SetBaudrate(pSPBRG As SPBRGRegister = br19200)
It's better to change it to something like
Code: Select all
// change parameter to a word... was passed in SPBRGRegister, assuming SPBRG
// and SPBRGH are in contiguous locations but they're not in all chips
public sub SetBaudrate(pSPBRG as word = br19200)
SPBRG = pSPBRG.byte0
#if USART_BRG16
SPBRGH = pSPBRG.byte1
#endif
I think I posted a replacement module at one point...
-
- Registered User
- Posts: 185
- Joined: Mon Mar 10, 2008 8:20 am
- Location: Seattle, WA USA
- Contact:
Re: USART Module with 18F26k22 and PLL Enabled
In this case, setting BRGH and BRG16 did the trick. I'll work on a more universal solution and have a look for your updated USART module. Thanks Jerry!
Any feelings on overclocking 18F26K22s to 80MHz? It seems to work but it doesn't seem like best practice, especially for something that may operate under temperature extremes. 16MHz crystals are on the way.
Any feelings on overclocking 18F26K22s to 80MHz? It seems to work but it doesn't seem like best practice, especially for something that may operate under temperature extremes. 16MHz crystals are on the way.
-
- Swordfish Developer
- Posts: 1486
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: USART Module with 18F26k22 and PLL Enabled
64->80MHz is a pretty big jump. I'd be leery of that in a commercial product.
The internal osc+PLL works pretty good for 64MHz operation.
I don't know if you need the xtal precision or what temp ranges you need to work over,
but there's a graph on pg 506 of the datasheet (figure 28-100) of what you can typ expect.
The internal osc+PLL works pretty good for 64MHz operation.
I don't know if you need the xtal precision or what temp ranges you need to work over,
but there's a graph on pg 506 of the datasheet (figure 28-100) of what you can typ expect.