Time stamping in milliseconds

Chee-Beng,

Some comments below…

> 1. Will mTimeStamp be reset to zero after some time? I observed
> in my project that mTimeStamp does reset to zero after about 15 seconds.
>  Is there anyway to avoid this reset?

The CLK_getltime() value will rollover eventually, as the total number of ticks exceeds a 32-bit count.  But this typically takes many days to occur.  Is it possible that you are using the higher rate CLK_gethtime() value in your computation? 

If this is not the case, can you indicate which DSP you are running on, the clock rate of the CPU, and the selected clock driving the timer peripheral?

> 2. I need to reset mTimeStamp to zero when some particular event
> occurs. I tried to use CLK_start() and seems like there is no effect. Is there
> a way to reset/restart the clock?

CLK_start() will start the timer peripheral ticking, but it doesn’t cause the total number of ticks that have expired (as reported by CLK_getltime()) to be reset to zero.  This tick count will continue to count up from zero, until it rolls over as a 32-bit value.  There is no BIOS API for resetting this.  If you need this behavior in your timestamps, I think you’ll need to manage this on your own, replacing the “CLK_getltime()” value in the equation with something like: “CLK_getltime() – (tick count when I reset my timestamp to zero)”.

> 3. Is the statement above the usual and correct way to compute a real-time
>  clock in millisecond? Or is there other proper methods?

The above should work. 

A couple other methods for computing elapsed time in milliseconds are shown in the API descriptions for CLK_cpuCyclesPerLtime() and CLK_cpuCyclesPerHtime().  For example:

time1 = CLK_getltime();
... processing ...
time2 = CLK_getltime();
CPUcycles = (time2 - time1) * CLK_cpuCyclesPerLtime();

/* calculate absolute time in milliseconds */
TimeAbsolute = CPUCycles / GBL_getFrequency();

Hi Scott,

I really appreciate your comments.

I double-checked with my codes, and I am quite sure I did not use the CLK_gethtime() for my computation. To give you a better idea, I created a PRD task to loop continuously at 1 second interval, and in the task, I just printed the time-stamp:

void taskACSStart(void) // A PRD task loops at 1 second interval

{

LOG_printf(&trace, "%d", (CLK_getltime() * CLK_getprd()) / CLK_countspms());

}

And below were what printed out:

0   1000

1   2000

2   3000

3   4000

4   5000

5   6000

6   7000

7   8000

8   9000

9   10000

10   11000

11   12000

12   13000

13   14000

14   683

15   1683

16   2683

17   3683

18   4683

19   5683

20   6683

21   7683

22   8683

23   9683

24   10683

25   11683

Chee-Beng,

I think what may be happening is that the multiplication of the first two values may be exceeding a 32-bit value, which then gets divided by CLK_countspms().  So, it appears that the tick count from CLK_getltime() was reset/rolled-over, but it was a math rounding issue instead.  To avoid this you may need to multiply the tick count times the ratio of CLK_getprd()/CLK_countspms()?

Can you please re-run the test with additional logging that shows what the return value from CLK_getltime() is, as well as the values reported by CLK_getprd() and CLK_countspms()?

Thanks,
Scott