Shop OBEX P1 Docs P2 Docs Learn Events
Overhead of a foo := CNT instruction? — Parallax Forums

Overhead of a foo := CNT instruction?

andrewsiandrewsi Posts: 59
edited 2011-10-22 14:56 in Propeller 1
Hey folks: Quick question somebody probably knows off the top of their head, or could determine by inspecting the interpreter PASM source.

I have some spin code that does:
WAITPEQ ([I]some state)[/I]
time := CNT

What I'm trying to do is to capture the CNT at the actual PEQ event time, but of course there is SPIN interpreter overhead here, so it should actually be time := CNT - (some constant). I found the online article written a few years back that allows you to time arbitrary code blocks like this:
t0 := cnt
' Insert code to measure here
t1 := cnt
elapsed := ||(t1-t0)
With no code to run between the two checkpoints, the article says the interpreter will add 368 clocks of overhead between the two measured CNT statements.

For my purpose, though, this won't quite work because the overhead I'm interested in is not the complete assignment statement, because retrieving CNT itself will take place only partway through the assignment routine, so the measured overhead will be overestimated if I include the actual copying of the CNT value to the variable. What I need is the overhead of the assignment statement up to the point where it actually retrieves the CNT, but not after - I just want to be as close as possible to the CNT when the actual PEQ wake-up event took place. I don't know what proportion of 368 clocks is the retrieval of CNT, and what remainder is the copying of the value. :smile:

Anybody know the answer to this one?

Comments

  • MagIO2MagIO2 Posts: 2,243
    edited 2011-10-22 12:32
    I would simply setup 2 COGs. One COG programmed in PASM and one in SPIN both with the same WAITXXX instruction. Both simply store the CNT value directly after the wait-instruction.

    Then you trigger the event once that makes the wait continue.

    The PASM part then stores the result back in a SPIN-variable. Then you simply subtract the SPIN-result from the PASM-result. If you need it absolutely accurate you can also subtract the clock-cycle-time that PASM needs.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-10-22 12:35
    I assume you're doing this twice to measure the elapsed time between input events, right? In that case, just make sure to follow each waitxxx instruction directly with a tx := cnt, and the two overheads will cancel, plus or minus some small uncertainty for hub timing.

    -Phil
  • andrewsiandrewsi Posts: 59
    edited 2011-10-22 14:56
    Yes, I just had a duh moment. As long as pulses are always measured the same way, the extra overhead will always be the same for each measurement and thus cancel itself out (disregarding hub uncertainty, which is too small to be worth worrying about for this application.) Thanks, Phil.
Sign In or Register to comment.