Logic Check on Cycles Count

[JonnyMac]

I have a simple PASM subroutine:


' ---------------------
' Pause in microseconds
' ---------------------
'
pauseus mov ustimer, cnt ' sync with system clock
tjz usecs, #pauseus_ret ' bail if zero
sub ustimer, #24 ' account for setup/call/return
add ustimer, ustix ' set timer for 1us
usloop waitcnt ustimer, ustix ' wait and reload
djnz usecs, #usloop ' update delay count
pauseus_ret ret

... and was just looking for a logic check on subtracting 24 from the initial ticks count to take care of call setup and return cycles. Am I on track? Now I'm thinking it should be 28 to account for DJNZ when it doesn't jump.

[MagIO2]

Hmmm ... why do you subtract 24? The call is one instruction and the mov ustimer,cnt is another instruction which counts. But from there on your ustimer is fixed. And even if you have 50 instructions between the mov and the waitcnt these won't add extra time to your waitcnt.

If you want it 100% accurate you might want to use less than 4 for the mov ustimer, cnt because cnt is read in the read source cycle of an instruction ... there are greater gurus here which can tell you the right number ;o)

[Rayman]

It hurts my head to think about it...

I think I'd just store cnt before calling the routing and then capture cnt after the call and print out the difference...
Then, just fiddle with the numbers until it comes out right...

[JonnyMac]

@Ray: Good point, I tend to emperically test things -- must have posted before the coffee had fully kicked in.

@MagIO2: There is the call, the setup in the routine before it drops into the loop, the return. I'm going to heed Ray's advice and let the Propeller measure for me.

[JonnyMac]

And the winner is... 25! This takes into account two instructions: 1) set the delay value, 2) the call to pauseus. Not sure where the odd clock tick comes in but I'm sure a review of the data sheet will reveal it.

Thanks again for the suggestion, Ray. Test code attached for those that may be interested (I used suggested code from the Propeller Q&A site).

[ericball]

The odd tick is probably from where ustimer is read (via waitcnt)versus written (via mov) in the pipeline.