Timing input...

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

Timing input...

Post by RedDave »

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.


User avatar
CousinItt
Respected Member
Posts: 265
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Hi RedDave,

looks like we're trying to do the same thing: https://www.xcore.com/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.
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Post by RedDave »

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?
User avatar
CousinItt
Respected Member
Posts: 265
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

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.
erlingrj
Member
Posts: 8
Joined: Tue Aug 10, 2021 1:21 pm

Post by erlingrj »

I am bringing up this thread as it discusses exactly my issue. I want to use the xCore to timestamp events on its pins with very high accuracy, preferrably in a single CC. Does anyone know the details of how the input timestamping works? Is it done in HW (like the Input Capture functionality of Timer peripherals found in normal microcontrollers?) or is it just the value of the port counter at the time the read operation is done. In the latter case you would introduce jitter that would depend on the amount of work the thread is doing.

I currently have no dev kit to test it on, using XSIM and port loopback I get consistently accurate values for both hw_ts and sw_ts. I have tried generating multiple events simultanously which should at least make sw_ts jitter, but this is not the case. XSIM is said to be a "near cycle accurate simulator" so I sadly dont trust my results. My hopes are that the input timestamping happens in HW and thus in parallell and will have 1CC accuracy as long as its read before the next event.

Code: Select all

        select
        {
            case p_ic when pinsneq(v_ic) :> v_ic @ hw_ts:
            	if (v_ic == 1) {
              		tmr :> sw_ts;
              		// Do something with timestamps
              	}
                break;
        }
[\code]