Hi,

I am doing the first configuration for the PIC18F4550, can someone please tell me if it is correct? Should FOSC be set to HS or to HSPLL_HS ?

Thanks in advance.

#pragma config FOSC   = HS        
#pragma config PLLDIV = 5         
#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2           
#pragma config FCMEN  = OFF       
#pragma config IESO   = OFF       
#pragma config PWRT   = OFF     
#pragma config BOR    = ON       
#pragma config VREGEN = ON     
#pragma config WDT    = OFF      
#pragma config MCLRE  = ON        
#pragma config LVP    = OFF       
#pragma config ICPRT  = OFF    
#pragma config CP0    = OFF

 

HS refers to the basic crystal / resonator oscillator circuit. HS for fast crystals and all but the slowest resonators. The 'HS' in HS_PLL has to do with the crystal type as well. Its kind of confusing nomenclature. HS means a higher oscillator drive level than XT. The PLL attached to both has nothing to do with the actual oscillator drive level so treat them separately.

The 'PLL' part comes in generating the internal USB clock. It has to be 6MHz or 48MHz and its a function of the crystal frequency and PLLDIV. Whether you use HS or HSPLL is dictated by how fast the basic oscillator is. If you use a slow basic oscillator (say 4MHz) you would use the USB PLL to get the USB speed up to spec. If your crystal freq. is 48MHz, you don't use the PLL.

Once you get the oscillator running and the USB at its correct frequency, you have a choice for the SYSTEM clock (that drives the CPU and other peripherals). If you use the basic oscillator freq with the prescaler (CPUDIV) clock (as you would with a fast basic oscillator) you don't specify 'PLL' in HS_PLL. If you have a slow basic clock that has been PLL'ed up to drive the USB and want to rip, specify HS_PLL to use the faster USB clock. (with CPUDIV the prescaler to that).


So three steps:
1) Get the basic oscillator hardware running (XT, HS, EC etc).
2) Use the PLL/PLLDIV section if necessary to get the USB up to speed. USBDIV selects PLL or straight oscillator for the USB.
3) Pick the appropriate signal from the resulting clocks i.e.either the oscillator directly OR the scaled-up oscillator that drives the USB, HS or HS_PLL, XT or XT_PLL etc, to drive the CPU, using CPUDIV as req'd to get the desired CPU speed.

What's your crystal frequency and USB freq?

 

Hi,

Thanks for the reply. Actually I am not going to use the USB but the UART. So in this case can I eliminate all the PLL settings? The crystal that I'm using is 20MHz.

Is the config below OK if the USB is not used:

#pragma config FOSC   = HS                  
#pragma config FCMEN  = OFF        
#pragma config IESO   = OFF        
#pragma config PWRT   = ON    
#pragma config BOR    = ON        
#pragma config VREGEN = OFF     
#pragma config WDT    = OFF       
#pragma config MCLRE  = ON         
#pragma config LVP    = OFF        
#pragma config ICPRT  = OFF     
#pragma config CP0    = OFF

 

Also, is it recommended to turn on PWRT and the Watchdog timer?

Thanks in advance.

 

Your config should work OK. I recommend specifying all the configs, even those you are using defaults for... Just because. For example, the BrownOutReset is enabled but you haven't specified anything about the voltage.. Such things can bite you. Plus, across various compilers and even versions, defaults have been known to change...

PWRT - I usually use it. Same with the OST (oscillator startup timer).
BOR - Definitely use it, especially if you contemplate using the EEPROM. Pick a voltage that ensures the PIC will run at 20MHz. That way, no loss of control when the power is going down. Ask me how I know these things...
WDT - I always use that as well but that depends on how you write your code. The ideal setup is when your code comes back to a single point (top of a task loop etc.) to clear the WDT. If you have lots of dumb delays it becomes problematic to feed the dog while counting clocks. The compiler may insert clrwdt into delay loops to prevent this from happening - you'd have to look at the generated code (or it may be documented). At any rate, this part has a huge prescaler for very long WDT delays (2 minutes +) so you could easily cover lots of dumb delays while still feeding the dog. It was way harder when the WDT prescaler was shared with TMR0. If the timer used the prescaler, the WDT time was about 10ms. Pretty zippy.

BTW, never clear the WDT in an timer-service interrupt. The timers can keep running fine while your code is stalled. Also, its helpful to check RCON after a reset to what caused it.

Presumably you have checked the baud-rate tables to make sure you can get your desired speed with 20MHz. You can get many of the standard ones OK but its good to check.

Looks good to me.