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.