Shop Learn
CLKSET(NewCLKMODE, NewCLKFREQ) syntax question — Parallax Forums

CLKSET(NewCLKMODE, NewCLKFREQ) syntax question

CLKSET(NewCLKMODE, NewCLKFREQ)
Safely establish new clock settings, updates CLKMODE and CLKFREQ
CLKMODE- The current clock mode, located at LONG[$40]. Initialized with the 'clkmode_' value.
CLKFREQ- The current clock frequency, located at LONG[$44]. Initialized with the 'clkfreq_' value.
For Spin2 methods, these variables can be read and written as 'clkmode' and 'clkfreq'. Rather than write these variables directly, it's much safer to use: CLKSET(new_clkmode, new_clkfreq)
This way, all other code sees a quick, parallel update to both 'clkmode' and 'clkfreq', and the clock mode transition is done safely, employing the prior values, in order to avoid a potential clock glitch.

Where do you find the CLKMODE\CLKFEQ settings. I think from the above (CLKSET)the compiler actually will generate the code to switch over. Normally I would assume the fastest rate would be the best but there may be some use to switch to a slower speed (RCFAST\RCSLOW) . Just want to include in notes for completness.
Regards and Thanks
Bob (WRD)

Comments

  • evanhevanh Posts: 12,045
    edited 2021-11-20 02:36

    clkmode and clkfreq are global hub variables so can be set or read at will. But as the description says, it's best to set them using clkset().

    The compile time features for setting the initial clock mode, _clkfreq, _xltfreq, _xinfreq, _errfreq, _rcfast, _rcslow, are constants you define in the main source file. They are effectively build parameters. And may be all you want if no desire to change the clock frequency during program run.

    I've used used run-time setting, with clkset(), to record multiple runs of behaviour for analysis. When using the comport for the logging it requires recomputing the baud timing for each new sysclock frequency since the hardware pacing of bits is ratio'd to sysclock.

    Debug system doesn't handle this at run-time though, therefore it can't be used when using clkset(). The two features are currently incompatible with each other.

  • The impression I get from the documents is that if you run CLKSET(newCLKMODE,newCLKFREQ) the compiler will perform and do the group of instructions using HUBSET(Value) to make a smooth transition. (which would be great) . I am also under the impression that this should be done with only the boot cog0 running and essentially no activity (no events or interrupts). It would make sense that debug comm settings would require changing if you wanted to use debug with a different system clock frequency. What is missing is what are the possible newCLKMODE values with the possible newCLKFREQ. I have looked in the hardware document and spin document (might have missed the Info but scanned it twice) You would think this is a set table for compiler recognised values (newCLKMODE\newCLKFreq) and possibly the compiler could take into account the comm speed changes for DEBUG in the future since it appears the compiler is responsible for all the changes from CLKSET().. For now Essentially looking for the acceptable values for the CLKSET(newCLKMODE,newCLKFREQ) . PS XTAL1 frequency would be a parameter in the table notably standard 20MHZ.
    Regards and Thanks
    Bob (WRD)

  • evanhevanh Posts: 12,045
    edited 2021-11-20 07:11

    @"Bob Drury" said:
    The impression I get from the documents is that if you run CLKSET(newCLKMODE,newCLKFREQ) the compiler will perform and do the group of instructions using HUBSET(Value) to make a smooth transition. (which would be great) .

    Yep. That part is sorted.

    I am also under the impression that this should be done with only the boot cog0 running and essentially no activity (no events or interrupts).

    All cogs are equal. HUBSET instruction is a hub-op so affects the whole Prop2, the clock tree circuits are a single global structure. Any cog calling clkset() changes the whole chip to a new frequency.

    It would make sense that debug comm settings would require changing if you wanted to use debug with a different system clock frequency.

    Yeah, but it's locked in the existing debug routines and can't be overridden by your program. That area of hubRAM is protected when using debug features. Chip has to make changes to Pnut/Proptool to allow use of clkset() with debug.

    What is missing is what are the possible newCLKMODE values with the possible newCLKFREQ. I have looked in the hardware document and spin document (might have missed the Info but scanned it twice) You would think this is a set table for compiler recognised values (newCLKMODE\newCLKFreq) and possibly the compiler could take into account the comm speed changes for DEBUG in the future since it appears the compiler is responsible for all the changes from CLKSET().. For now Essentially looking for the acceptable values for the CLKSET(newCLKMODE,newCLKFREQ) . PS XTAL1 frequency would be a parameter in the table notably standard 20MHZ.

    There's nothing from Parallax so far. Chip posted his compile-time routine used to calculate the mode word but that's all there is from him.

    I've done my own coding of this as I needed. I've posted it number of ways and times going back to revA silicon ...

  • evanhevanh Posts: 12,045
    edited 2021-11-20 07:17

    Here's an actual topic I started in the latter days of my assembly-only coding - https://forums.parallax.com/discussion/170414/dynamic-system-clock-setting-and-comport-baud-setting/p1

    Chip's calculation of clkmode_ constant symbol at compile time - https://forums.parallax.com/discussion/comment/1486815/#Comment_1486815

    Run-time versions by Roger - https://forums.parallax.com/discussion/comment/1506393/#Comment_1506393
    and myself - https://forums.parallax.com/discussion/comment/1529415/#Comment_1529415

    PS: You'll note I've used send() instead of debug() in my test code so then the comport baud can be set on each test loop.

  • Thanks Evanh. I can see that this is getting out of my range of understanding and some considerable work has been done . I tried to run the PASM program but the first line "qmul xtalmul, ##(XTALFREQ / XDIV / XDIVP)" came up with an error "Expected Unique constant name or #" and qmul was highlighted as the culprit. Best I move on frm CLKSET() instruction for the time being (pun intended). I thiink most of the time _clkfreq would not really be changed .
    Regards
    Bob (WRD)

  • evanhevanh Posts: 12,045
    edited 2021-11-21 00:15

    If you're compiling the code from the early assembly only link then it's probably too old. Err, it's only a routine, not a full program. Try the code at the last link instead, it has complete test program included.

Sign In or Register to comment.