SETFREQ vs. DEFAULT: FREQ IS DIFFERENT

[Dave E]

Hello all,
An earlier post about toggle speeds with a 20X2 got me to thinking about testing toggle speeds with a 28X2.
I noticed something that got me to scratching my head.
Running this code:


#PICAXE 28X2
#NO_DATA
#NO_TABLE
SETFREQ M8

DO
TOGGLE C.6
LOOP

gives me a toggle frequency of 1.010 kHz

Running the same code with the setfreq command removed gives me 984.1 to 984.5 Hz.

Does anyone have any ideas why there is a difference? I was under the impression that the X2s defaulted to 8MHz internal but this shows a slight difference between default and setfreq M8.

Other info:
no external resonator attached
28X2 firmware B.0
have not tried this with other Picaxe chips

Dave E

 

[MartinM57]

No idea - but I can confirm the results:

With SETFREQ M8, 1008Hz
Without SETFREQ M8, 982.6Hz

External 8Mhz resonator fitted (but shouldn't be used anyway)
28x firmware B.0
Standard download circuit, AXE027 lead (no change in ferequency if connected or not)

 

[womai]

ANY change to the code can slightly affect the execution speed of seemingly unrelated code. This has been discussed many times in the past: The reason is that the code is stored in a very compressed format, so commands may go across byte boundaries some times, but not in other cases, resulting in somewhat different times to interpret the same command (reading and processing one code byte vs. two bytes, respectively). For that reason, if you need super-exact timing, the Picaxe is not a very good choice unless you can handle it e.g. with some timer interrupt or use the PWM or sound command. Otherwise, assembler or (with a bit trial-and-error) a compiled language is the way to go, there you have cycle-accurate control over your code timing. Also an external crystal is more accurate (and stable against temperature changes) than a ceramic resonator, which again is more stable than the internal oscillator.

Wolfgang

 

[MartinM57]

Agreed - but informal testing by putting random code (maybe 10 tests in all - PAUSEs, repeated SETFREQs, other time consuming and variably complex DO...LOOPs etc) before the DO..LOOP command in an attempt to move it around on byte boundaries shows no effect

The only way to affect the DO...LOOP frequency is to have/have not the SETFREQ M8 command in place

 

[Andrew Cowan]

I haven't tried it, but I would imagine that changing the freqency would not affect the hardware PWM frequency, only bit-banged outputs.

A

 

[hippy]

There should be no difference in functionality, but the code alignment will be different which can alter execution speeds. Try ...

Gosub SetFrequency
Do
Toggle C.6
Loop
SetFrequency:
SetFreq M8
Return

This will keep the loop code with the same alignment regardless of whether the SETFREQ command is present or not.

 

[Dave E]

I tried Hippy's code.
Running it as is and with the SETFREQ M8 command remarked out.

Running time is the same = 1010Hz

So, position in the code can make a difference in timing. Any published info or rules of thumb on this? Any way to predict any of this? Not sure what questions to ask.

Dave E

 

[hippy]

The cause of variable timing is as womai described in post #3; changes to code can alter the alignment of following code, which affects that code's timing, sometimes improving speed, sometimes decreasing it. That's just the nature of how things are with a PICAXE.

The questions you are probably looking for; is there any way to control this, or any way to ensure particular timing ?

Not really. The best which can be done is to write programs where you want to have consistent timing such that no changes are made before or in that part of the code, as with the example I gave in post #6. Otherwise, as soon as you add code the timing will change.

It is possible to adjust and optimise timing by putting commands before the timing critical code as MartimM57 suggests. Inserting dummy END commands works but I'm not sure what's best used for X1 and X2. The intent is to use a command which has an odd number of bits length so each inclusion of the command shifts the alignment of the subsequent code. Using multiple commands will test each possible alignment.

Of course, improving the alignment of one command may make the alignment of the following command worse, so it's a case of having finalised code and trial and error ...

Goto MainLoop
End
MainLoop:
Do
Toggle C.6
Loop