_CLKFREQ vs CLKFREQ vs CLK_FREQ

dbpage

The Propeller Manual is very clear, _CLKFREQ is the original system clock frequency at startup and CLKFREQ is the current system clock frequency. They both may be the same value, but they can be different if the application changes the clock speed.

Of what use is the following CLK_FREQ constant?

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq               ' system freq as a constant

Is it solely to establish other constants, such as:

CON
TIME1 = CLK_FREQ / 2
TIME = CLK_FREQ - SEC_LED_HI_TIME

Are there run-time uses for the constant CLK_FREQ?

Seairth

When defining the clock constants, _xinfreq and _clkfreq are mutually exclusive (you can only define one of them, or the other). Since _xinfreq was defined, an equivalent "_clkfreq" had to be calculated from it if you need the value. Of course, you could always define _clkfreq instead of _xinfreq.

Edit: note also that the above CLK_FREQ is only useful if you intend to change the values of _xinfreq or which PLL multiplier you are using with XTAL1. If you aren't going to do either, then you may as well just set CLK_FREQ = 80_000_000, which would more directly convey your meaning.

JonnyMac

I use the code you posted in the first snippet all the time; it lets me create timing constants that will propagate through the program with a crystal or PLL change.

idbruce

I use the code you posted in the first snippet all the time; it lets me create timing constants that will propagate through the program with a crystal or PLL change.

That is indeed quite a handy snippet. After learning that trick from Jon's coding examples, I also begin all of my programs that way.

Seairth

@cgracey,

In your next iteration of the spin compiler, would you consider changing the behavior of _xinfreq and _clkfreq a bit? In particular, have them be predefined with default values and implicitly in scope. User code can override them as they do now, except that both constants will be "in scope" even though only one was explicitly set. For instance, if code sets _xinfreq, then _clkfreq is implicitly updated. Both _xinfreq and _clkfreq would be accessible to the user code (even though _clkfreq was not explicitly set). After all, this is exactly what the above code is meant to achieve, but adds unnecessary confusion since there is already a predefined constant (_clkfreq) that means the same thing.