Huge delays when using time stamped outputs Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Huge delays when using time stamped outputs

Post by DemoniacMilk »

I was able to identify what causes a problem described in another thread but cannot see why.

I planned on using timestamped outputs on two 1-bit-ports to achieve an offset of one clock cycle between the two signals. The ports are clocked @ 8.3 MHz by the same clock block. Code as follows:

Code: Select all

    // output the first data set
    portOutfsync <: 0 @ uiTimestamp;                      // do a dummy byte output, get timestamp
    portOutfsync @ uiTimestamp + 8 <: uiFSync;      // .. and then output fsync and
    portOutData  @ uiTimestamp + 9 <: uiaZipped[0]; // .. data, data one clock cycle delayed

    benchmarkTimer :> uiDurProc;

    uiFSync ^= 0x1;
    portOutfsync <: uiFSync;           // this will block until the previous fsync has been transmitted
    portOutData <: uiaZipped[1];    // this will block until the previous data  has been transmitted

    benchmarkTimer :> uiDurSent;
    printf("send:%u us\n", (uiDurSent-uiDurProc)/100);
This outputs
..
send:7864 us
send:7864 us
..
If i remove the first timestamp on the outputs:

Code: Select all

    portOutfsync <: 0 @ uiTimestamp;                      // do a dummy byte output, get timestamp
    portOutfsync <: uiFSync;      // .. removed timestamp
    portOutData @ uiTimestamp + 9 <: uiaZipped[0]; // .. kept timestamp
then the output is
..
send:0 us
send:0 us
..
Why does the timestamp add such a huge delay?


View Solution
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Hm a possible solution:
  • the port runs at 8.33 MHz
  • port counter is 16 bit (?)
counting for 2^16 cycles takes 2^16/8,333,333 Hz = 7,86 ms what is exactly the delay measured.

So my guess is:
Output dummy byte -> port blocks until byte is sent.
when ready to output first FSYNC: port counter has already incremented by 8 -> no output for now -> wait until the counter reaches desired value after overflow -> output is delayed by 2^16 port clock cycles

On realizing this, I changed the first timestamped output from

Code: Select all

portOutfsync @ uiTimestamp + 8 <: uiFSync; 
to

Code: Select all

portOutfsync @ uiTimestamp + 9 <: uiFSync; 
and it works fine.

EDIT:
Sorry for spamming the forum with questions and then answering them myself. Hope it might be helpful for someone else in future. If you dont think so feel free to remove the two topics related to this problem.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Sorry for spamming the forum with questions and then answering them myself. Hope it might be helpful for someone else in future. If you dont think so feel free to remove the two topics related to this problem.
No need to be sorry - You are effectively populating a useful Q&A for others to benefit from..

Yes, good spot on the port timer. Unlike general timers and the use of timerafter for software delays which will fire at any point after the compare value:

Code: Select all

t when timerafter(time) :> void;
port timer usage:

Code: Select all

portOutfsync @ uiTimestamp + 8 <: uiFSync;      // .. and then output fsync and
is a pure comparison, meaning you'll have to go round again if you miss it.