> Hi, some time ago somebody claimed that the Frequency to PLL
> can only be 4 MHz...
> Could this be the issue?
Well, this is very interesting. A valuable waste of time, if one could
say that ;-)
Using a 3.2768MHz on OSC1/OSC2, no matter what TMR0 is
loaded with, in whichever order, the period is always 757.85us
So I put a 4MHz crystal in and got these results (give or take a
smudge for calls etc). 83.333ns instruction time @ 48MHz
TMR0 free-running, 5432us. Which is, ta da, 65536 * 83.333ns
TMR0 loaded with FB28 (- d1240) => 104us
So the story seems to be, going back to the 3.2768, that the
PIC may execute instructions at less than 48MHz derived from
OSC1/OSC2, but TMR0 won't work properly. Probably
other modules too
As brought up in a previous thread, the correct way would be
to use OSC1/OSC2 just for the USB and the frequency for
the core and peripherals via T1OSC
> > Hi, some time ago somebody claimed that the Frequency to PLL
> > can only be 4 MHz...
> > Could this be the issue?
>
> Well, this is very interesting. A valuable waste of time, if one could
> say that ;-)
>
> Using a 3.2768MHz on OSC1/OSC2, no matter what TMR0 is
> loaded with, in whichever order, the period is always 757.85us
>
> So I put a 4MHz crystal in and got these results (give or take a
> smudge for calls etc). 83.333ns instruction time @ 48MHz
>
> TMR0 free-running, 5432us. Which is, ta da, 65536 * 83.333ns
> TMR0 loaded with FB28 (- d1240) => 104us
>
> So the story seems to be, going back to the 3.2768, that the
> PIC may execute instructions at less than 48MHz derived from
> OSC1/OSC2, but TMR0 won't work properly. Probably
> other modules too
>
> As brought up in a previous thread, the correct way would be
> to use OSC1/OSC2 just for the USB and the frequency for
> the core and peripherals via T1OSC
>
>
That's likely to be the cause, but when I thought of that earlier
I couldn't understand why general instructions execute at the
correct speed, for example the 1ms delay is good, but TMR0
doesn't increment correctly. And always a 757us rollover too.
I daresay there's a silicon component to all this, not simply
the clock. Anyway, hopefully I have found the problem and
can move on (it's been a very long two days)
On the plus side, I know more about the 4550 than I did
yesterday
If you look at the DataSheet carefully (Section 2.2.1 in the Figure 2.1),
there is only one place where they mention that "4 MHz input only" but AFAIK
you can use higher crystal which can be divided to 4 MHz using the PLL
divider like 12MHz/3.
Anyway, in the evening I was thinking why did you use timer if you do not do
anything else in parallel:
tmp equ 0x20
bitdel2
clrf tmp
call wait_10cy ; we need 10 more cycles but then we will have
; proper 104us with your original crystal
loop
nop
decfsz tmp
bra loop
return
>
>
>
> > Are you sure is not a problem of PLL lock ?
>
> That's likely to be the cause, but when I thought of that earlier
> I couldn't understand why general instructions execute at the
> correct speed, for example the 1ms delay is good, but TMR0
> doesn't increment correctly. And always a 757us rollover too.
>
> I daresay there's a silicon component to all this, not simply
> the clock. Anyway, hopefully I have found the problem and
> can move on (it's been a very long two days)
>
> On the plus side, I know more about the 4550 than I did
> yesterday
>
> If you look at the DataSheet carefully (Section 2.2.1 in the
> Figure 2.1), there is only one place where they mention that
> "4 MHz input only" but AFAIK you can use higher crystal
> which can be divided to 4 MHz using the PLL divider like
> 12MHz/3
Someone mentioned that before, you or Dario I think. Uses
6MHz or 8MHz IIRC
> Anyway, in the evening I was thinking why did you use
> timer if you do not do anything else in parallel:
There are several ways I could have made the delay. TMR0
seemed the most convenient, and also this is a small part of a
very large project and it's probable I'll work the timer into the
interrupt handler later. There will be 3 UARTs running and I
need something more interactive than dedicated code. In the
end the timer problem highlighted something that needed to be
worked out
> If you look at the DataSheet carefully (Section 2.2.1 in the Figure
> 2.1), there is only one place where they mention that "4 MHz input
> only"
I'm still working that block out but it looks like you get 96MHz
only with a 4MHz input (ie output of the pre-scaler and MUX ?)
"The PLL is enabled in HSPLL, XTPLL, ECPLL and
ECPIO Oscillator modes. It is designed to produce a
fixed 96 MHz reference clock from a fixed 4 MHz input"
Parameter F13 might be the PLL lock range
F13 ?CLK CLKO Stability (Jitter) -0.25 - +0.25 %
If so then the frequency produced by 3.2768 is well out of spec
clear.net.nz> wrote:
