 |
 |
| View previous topic :: View next topic |
| Author |
Message |
javick82
Joined: 12 Jul 2007
Posts: 43
|
| Delay - Crystal vs. Clock Explanation |
 Posted: Fri Feb 25, 2011 12:08 pm |
 |
|
I would like to understand what is going on with my code on the USB demo board featuring the PIC18F4550. I can get my code to work reliably (at least so far) but I want to know why it works one way and not the other.
My project will require the use of both RS232 (for machine comms) and USB (via serial port emulator for PC communication and system control).
| Code: |
#include <18F4550.h>
#use delay(clock=48000000)
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#include <usb_cdc.h>
void main()
{
usb_init();
printf("\n\rInitialized\n\r");
while(1)
{
if(usb_enumerated())
{
printf("\n\rEnumerated!\n\r");
break;
}
}
//do something
while(1);
}
}
|
In the above code, if I change the clock to 20,000,000 the RS232 baud rate is thrown off. However, the hardware indicates that there is, indeed, a 20 MHz crystal present. Changing "clock" to "crystal" gives the same result. Even setting clock=40,000,000 works, but again not sure why.
Removing PLL5 and CPUDIV1 from the fuses corrects the issue with the RS232 data transfer, but completely disables the USB.
What is the correct way to set up the firmware and more importantly, why? How are the fuses and processor speed working together to give the above results?
Thanks for the input!
-Jason |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 25, 2011 1:11 pm |
|
|
Look at the oscillator block diagram in the 18F4550 data sheet:
| Quote: |
FIGURE 2-1: PIC18F2455/2550/4455/4550 CLOCK DIAGRAM
|
http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf
The key point is that the PLL requires a 4 MHz input, only.
If the crystal is not 4 MHz, it must be divided down to give 4 MHz. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Fri Feb 25, 2011 1:44 pm |
|
|
Explaining a bit further (the diagram is the key).
On the USB PIc's, the PLL _always runs_, and feeds the USB.
The HSPLL fuse, says 'feed the CPU from the USB PLL'.
To feed the CPU from the crystal, select the HS fuse instead.
Now the PLL5 fuse, says 'divide the incoming clock by 5 to feed the USB PLL'. The USB PLL _requires_ 4MHz. 20/5=4.
This frequency is then multiplied by 24, to give 96MHz. This is then divided by 2 to feed the USB.
Selecting CPUDIV1, with HSPLL, says 'take the USBPLL clock/2 to feed the CPU. Since the USBPLL generates 96MHz, this gives 48MHz as the CPU clock.
So if you changed the HSPLL fuse to HS, and your clock statement to 20MHz, things would again work, with the CPU now running from the crystal, rather than he PLL (but you need to keep the PLL5 fuse, if you are using the USB, since this still needs the 96MHz PLL).
Now the CPUDIV numbers do get a bit confusing, since the divsions given, differ when this is running from the USBPLL, from those it gives when running from the crystal. The CCS fise 'names' correspond to the divisions when running off the crystal, and you need to look at the data sheet/diagram to work out what division each of these gives....
Best Wishes |
|
|
javick82
Joined: 12 Jul 2007
Posts: 43
|
|
| Posted: Fri Feb 25, 2011 2:07 pm |
|
|
Alright, the diagram and the explanation really helped explain what is going on.
Still a little hazy, but I get the gist of what the "working code" is doing vs. the "broken code".
Thanks! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
