Delays in PASM Independent of Clock Settings

JohnBF

I'm working through the PE Kit labs trying to translate as much as possible into PASM. Great learning experience.

What's the best way to run a PASM routine that's independent of system clock settings (as discussed in the lab manual starting on page 49)? You can calculate a delay in spin and pass it to the routine as a parameter. But then if the clock settings change while the routine is running it won't know about it. You can continually update the delay in the routine, but that slows things down.

Attached is a program with·one PASM routine that updates, and one that does not update the delay. I'd appreciate any thoughts on the best way to approach this.

/John

Mike Green

There is no time reference in the Propeller that's independent of the system clock settings (clock mode), so it's impossible without an external clock fed into an I/O pin to have a Spin or PASM routine really independent of the system clock settings. Even if the program continually checks for system clock changes by monitoring the locations in lower hub memory that hold copies of the system clock mode and clock frequency, these locations are not updated automatically at the same time the hardware clock mode is changed. I don't know whether the Spin interpreter updates the locations before or after it updates the actual clock mode using the CLKSET call and there's no built-in equivalent in PASM.

Truthfully, you want to avoid changing the system clock all the time. If your concern is power consumption, this can be reduced markedly by having as many running cogs as possible waiting for something to happen either with a WAITPNE/WAITPEQ or a WAITCNT. These all put the cog into a low power mode until the expected change occurs. If you need to drop into a very low power state, say by changing to the slow internal clock or turning off the PLL, the various cogs can coordinate the change when they're in some kind of stable, planned state.

JohnBF

I'm just asking about a way to duplicate in PASM a spin statement like clkfreq/1000 to mark a mSec in a routine that cannot predict the clock setting of the program calling it. Sounds like the answer is no. /John

Mike Green

The value used in CLKFREQ is stored at locations 0-3 in hub memory. You can fetch it from there with a "RDLONG temp,#0". You'd have to do the division by 1000 yourself, but that's easy enough.

JohnBF

Got it. Thanks.