Timing input...

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
RedDave
Experienced Member
Posts: 67
Joined: Fri Oct 05, 2018 4:26 pm

Timing input...

Postby RedDave » Tue Mar 12, 2019 12:41 pm

I need to record the time at which a transition occurs at an input (as accurately as possible).

My assumed code for this was

Code: Select all

timer tmr;
unsigned int t;
unsigned int v;

select
{
   case p_in when pinsneq(v) :
      tmr :> t;
      break;
}
If the core is responsible for multiple things then the time recorded would, in general, be some time after the transition. Suppose, for instance, that another case in that select performed an operation that took longer than the required accuracy of the timing.

I have come across code like this on the forum.

Code: Select all

case p_in when pinsneq(v) :> v@ t:
   break;
Is this code exactly equivalent to my original code?
Or does this time the actual transition?


I have tried running it, and I have found that, the value of t returned by this process is always less than 65536, as if it is using a 1 bit timer. The timer appears to be synced by offset from the system timer.

Code: Select all

        select
        {
            case p_button when pinsneq(button) :> button @ t0:
                tmr :> t1;
                printf("%x : %8x : %8x : %8x : %8x\n", button, t0, t1, t1-t0, (t1-t0)%65536);
                break;
        }
This code returns a roughly constant difference between t1 and t0 at the 16 bit level. (it varies by one on different presses).

Final question.
Where do I find documentation on this?
Because I have only seen the notation rather than read the description, I do not know what search terms to use to get help.
CousinItt
XCore Addict
Posts: 138
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Thu Mar 14, 2019 11:24 am

Hi RedDave,

looks like we're trying to do the same thing: viewtopic.php?f=7&t=7090

Your second example isn't the same as the first. Here you're using an input timestamp. The 16-bit port counter is copied into the named variable. I thought the capture was done in hardware, but this may not be the case.

There isn't much info on input timestamps. In the XS1 port specification it says:
All input and output operations can be timestamped by adding “@ variable” to the right of an input or output statement.
Programming XC on XMOS Devices has more, including:
The timestamp recorded by an input statement may come after the time when the data was sampled. This is because the XS1 provides separate instructions for inputting data and inputting the timestamp, so the timestamp can be input after then next data is sampled. This issue also affects output statements, but does not affect inputs performed in the guards of a select statement. A compiler should input the timestamp immediately after executing an input or output instruction, so in practice this behaviour is rarely seen.
I don't know whether that still applies for xCORE-200. Probably we need to check assembly listings.
RedDave
Experienced Member
Posts: 67
Joined: Fri Oct 05, 2018 4:26 pm

Postby RedDave » Thu Mar 14, 2019 11:52 am

Difference is that my issue is not that the time between the trigger and the timer grab is inconsistent (I think this is reasonably deterministic). [My time critical aspects is in the ps region and I do this on another chip.]

My issue is that I need to use the core for other things. I cannot dedicate a whole core just to timing this edge. Therefore, the core may be busy at the time of the edge change.
I have still failed to find documentation on this. What is the time the timestamping returns? Is it transition time or time of the trigger?
CousinItt
XCore Addict
Posts: 138
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Thu Mar 14, 2019 3:28 pm

The timestamp is returning the value of the port counter when it is read. Ideally this would be the value when the transition event occurs.

Who is online

Users browsing this forum: No registered users and 4 guests