PIC oscillator tutorial

[Jean FOUGERON]

Hi friends
I definitely am lost with all these different oscillator modes
Do you know where to find a clear and precise tutorial on it

For example, when I use a 20 MHz resonnator and #fuse HS what frequency my clock is ?
and HSPLL : 2 times ?

Which value have I to specify in #use delay : 20000000 oor 40000000

And in these cases, how the PIC knows to produce a USB 48MHz and not a 24MHz ?

You can derstand that I am lost, and because I am afraid not to be alone in this situation, please somebody give us a CLEAR and understable TUTORIAL

Good WE

[asmboy]

#use delay should always be the ULTIMATE frequency , including any PLL multiplication.


so 10mhz xtal with PLLx4 would be 40mhz
and so on

[Jean FOUGERON]

Do #FUSES HS,PLL5 have sense ? or //#FUSES HSPLL,PLL5 is correct ?

And in this case the freq. is 20MHz or more (with a 20M resonator).

[asmboy]

#fuses mirror the datasheet features of the actual PIC

different oscillator PLL settings depend on individual pic models

let the DATASheet for your model pic be your guide
( you never specified what PIC you are working with )


PLL X4 is the MOST common


if in doubt - set a timing loop with timer0, at a precise divisor and then
toggle a pin at a given rate , then measure the pin toggle frequency.

simple experiment you can do to know what result you are really getting

[Jean FOUGERON]

I use a PIC18F2550 with a resonator 20MHz

With #FUSES HS and #use delay(clock=20000000) -> Time3 div_by_1 == 5,48ms

With #FUSES HS,PLL2 and #use delay(clock=20000000) -> Time3 div_by_1 == 5,48ms

With #FUSES HSPLL,PLL2 and #use delay(clock=20000000) -> it doesn't work

With #FUSES HSPLL,PLL2 and #use delay(clock=40000000) -> it doesn't work

And what configuration have I to use if I want a reliable USB ?

Thanks for all

[asmboy]

[Douglas Kennedy]

Well, the issue with usb is that usb has its own dictate of a 24Mhz clock.
(usb 2.0 D+ D- wires) The pic internal usb clock or the pic code clock can be different. Now since the pic clock and the usb clock are derived from the same external frequency the external frequency is constrained to some multiple of a common divisor.
EX 18F2455 16mhz xtal common divisors are 2 ,4 , 8 ,16
We must choose 4 since only with PLL4 in the fuses can we get 16mhz down to 4 mhz ready for multiplication to the pic internal usb clock ( a fixed multiple of 24mhz) the 18F2455 data sheet says the internal usb has a fixed 24 x PLL and needs 96 mhz for the internal usb part. So 16 mhz is prescaled to 4hz by PLL4 and in the pic usb circuit rescaled once more to 96Mhz via an internal clock multiplied of 24x
Now suppose we want our pic code to run at 32 mhz but we now know the internal is at 96Mhz
#use delay(clock=32000000) then we need CPUDIV2 which is a bit confusing since it is really divide by three to get 32Mhz.
A recap the external 16Mhz clock was manipulated to 96Mhz for the pic internal usb needs and then the 96mhz was then reduced to 32Mhz for our pic code needs.
Perhaps this is not a good explanation and maybe others have a better way of explaining it. The constraint is the usb part of the pic has a chip data sheet dictated osc freq. The user frequency is then constrained by this and the avialable divisors specified in the fuses statement.

An aside
Je crois qu'une explanation en francais va etre aussi complique. Par hazard Jean votre anglais est formidable.

[Ttelmah]

[Jean FOUGERON]

[Jean FOUGERON]

[Ttelmah]

The translation between CCS fuses and 'what they actually are', is in the document 'fuses.txt' that comes with the compiler. This is an 'often missed resource'.
Then the reference from this, is the data sheet.
Some are really annoying like the CPUDIV ones. Problem here is that (for instance) the pattern 01, means /2, when used with the crystal as an input yet /3 from the PLL. CCS in their 'wisdom' elected to call this fuse CPUDIV2, and give the description '/2 postscaler', but this is simply wrong from the PLL....
Personally I wish they had been a little less 'spoon-feeding' in their thinking, and on fuses like this, used the binary patterns, so you'd have CPUDIV00 CPUVIV01 CPUDIV10 & CPUDIV11, with the numbers corresponding to the binary values put into the CPUDIV bits, then a simple look in the data sheet would give the actual dividers without any confusion....

Best Wishes