USART Module with 18F26k22 and PLL Enabled

General discussion relating to the library modules supplied with the compiler

Moderators: David Barker, Jerry Messina

Post Reply
Jon Chandler
Registered User
Registered User
Posts: 185
Joined: Mon Mar 10, 2008 8:20 am
Location: Seattle, WA USA
Contact:

USART Module with 18F26k22 and PLL Enabled

Post by Jon Chandler » Mon Dec 19, 2016 5:42 am

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
Jon

Check out the TAP-28 PIC Application board at http://www.clever4hire.com/throwawaypic/

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: USART Module with 18F26k22 and PLL Enabled

Post by Jerry Messina » Mon Dec 19, 2016 11:25 am

should the crystal frequency be multiplied by 4 for the CLOCK statement
Always use the real clock freq you'll be running at for 'clock = ' ie 40, 64, 80, etc


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"
Also, the original library declares the sub as

Code: Select all

Public Sub SetBaudrate(pSPBRG As SPBRGRegister = br19200)
This passes the br value directly in the SPBRG register. It assumes that the SPBRG/SPBRGH register pair are contiguous in the memory map, and for some devices this isn't true.

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
but you should add defines to the actual reg names to account for the '#elseif _usart = 1' defines.

I think I posted a replacement module at one point...

Jon Chandler
Registered User
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

Post by Jon Chandler » Mon Dec 19, 2016 8:21 pm

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.
Jon

Check out the TAP-28 PIC Application board at http://www.clever4hire.com/throwawaypic/

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: USART Module with 18F26k22 and PLL Enabled

Post by Jerry Messina » Mon Dec 19, 2016 8:35 pm

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.

Post Reply