calibfreq freaks

Hi All,

I'm working on a project to capture events with a resolution or 5mS or better. The core of the code is based on Womai's post http://www.picaxeforum.co.uk/showthread.php?t=8541

I've got the basics running fine, with an output toggling every interrupt, which should give a 500Hz signal.

My measured value is actually 498.8 Hz. The error might be my uncalibrated freq meter, or the 20X2 resonator is a bit off, or the preload value is too coarse. In any case I tried a calibfreq tweak to get it closer to 500 Hz.

It went bananas !.

I tried calibfreq 1, and the frequency dropped to 125 Hz. Tried other values, but always get about the same. Even calibfreq 0 drops my frequency to 124.6 Hz

Can anyone tell me what is happening ?

Thanks,

Buzby


( PICAXE 20X2 C.0 Firmware version 0 )

Seems likely that you are poking the wrong location for the chip - but I don't know the right location for the 20x2 so I can't really say - perhaps look at the chip's data sheet...

I'm not poking, I'm using calibfreq - page 36 in the manual.

( The calibfreq command is commented out in the attached file. )

Hi All,

I may have just fixed it, but I don't know why.

If I use :

setfreq m64
calibfreq 3

I get 125 Hz

But if I use :

calibfreq 3
setfreq m64

I get 500 Hz

Can anybody explain why the commands have to be in this order ?.

I have found what I think is the answer.

The osctune register in the PIC18F1XK22 also controls the PLL which multiplies the clock by 4.

The PICAXE calibfreq command writes to the register, but it seems that it does not maintain the existing state of the PLL control bit.

( This may have some relation to other posts I've seen where frequencies were not changing when the PLL was supposedly enabled. )

The manual needs to state that the order of commands is significant, or calibfreq needs fixing.

Buzby

Thanks for your observations. I cannot say what the issue is but we will look into it.

Thanks hippy, I'll try some more tests tonight.

From my testing it appears that CALIBFREQ inadvertently clears the PLLEN bit in OSCTUNE as Buzby suspected ( or tested ), so speed also drops to a quarter of what it should be ...

#Picaxe 20X2
#Terminal 9600
#No_Table
SetFreq M32
CalibFreq 0
SerTxd( "Oops - 9600 baud, not the expected 38400 baud",CR,LF)

The pragamatic solution for now is to issue any CALIBFREQ commands before SETFREQ and where CALIBFREQ is used to vary speeds programmatically follow those with an appropriate SETFREQ, though in most cases I expect there's just one SETFREQ and CALIBFREQ in any program.

We'll look at correcting the behaviour and it looks like it may be possible to fix within the compiler so all 20X2 will behave identically regardless of firmware version.

Thanks hippy,

I just tried :

setfreq m16
calibfreq %01000000

Now it's running at 64 MHz !.

Hi,

Is there any reason, why one couldn't also enable the pll on internal oscillator mode in picaxe 28x2(when running at 4 or 8 mhz, as not to exceed rated frequency), by poking the bit6 in osctune?

Janne said:

Hi,

Is there any reason, why one couldn't also enable the pll on internal oscillator mode in picaxe 28x2(when running at 4 or 8 mhz, as not to exceed rated frequency), by poking the bit6 in osctune?

Click to expand...

Yes there is a reason, it won't work! The PLL is configured for external use only on the 28X2. This is due to the technicalities of the resonator options during initial fuse programming - the PLL can only be configured to be used internally (as on 20X2) or externally (28X2/40X2), but not both.

Thanks for that. After reading the datasheet a bit more, i notice those settings are in the configuration registers - access denied from the running picaxe program