timestamped reading doesn't work proper
Posted: Tue Sep 29, 2020 11:10 am
Well, I have figured out a very curious behaviour of some part of my code. I have written an own lib for i2s, because I need some more/different features. In my test project, the lib works perfect at 192kHz, even with 8 cores on a tile. In my real usb project the lib doesn't work proper. The code of the lib is like this:
At 44.1kHz it works fine. At 48kHz, I need 2 sync iterations. The higher the input frequency is, the more sync iterations I need. To analyse this problem, I have added output, to inspect the variable states and I have got i.e.: "value = 0, wclk_pattern = 2147483648; pt1 = 53362, pt = 53394". The surprising is that "value" doesn't match the "wclk_pattern". More suprising is that "pt1" is *lower* than "pt" (time dilation?). "pt1" is the timestamp, when it is read, and "pt" when it should be read. The difference is always 32. The timestamp difference does not match to the pattern difference. The pattern difference is odd.
The document "XS1 Ports: use and specification" (https://www.xmos.ai/download/XS1-Ports- ... (1.02).pdf) describes on page 4:
Code: Select all
// sync to the word clock
while (1) {
select {
case p_wclk @ pt :> value @ pt1 :
// read data and do some other stuff
if (value != wclk_pattern) {
printf("value = %u, wclk_pattern = %u; pt1 = %u, pt = %u\n", value, wclk_pattern, pt1, pt);
return;
}
break;
}
}
// do more stuff
The document "XS1 Ports: use and specification" (https://www.xmos.ai/download/XS1-Ports- ... (1.02).pdf) describes on page 4:
My question is: If it is guaranteed, why do I measure such a difference? What could cause such a difference? The code is not marked as distributed or combinable, but runs as a discrete thread.Port counters are 16-bit counters clocked by either an external
clock, or by a divided internal reference clock. Port counters are guaranteed
to perform I/O operations at precisely defined moments related to an externally
visible clock signal.