TMS570LC4357: RTI Module Timing Analysis

Hi Naveen,

My apologies for the delayed response, i was off for few days.

Naveen R said:

Could you please confirm if my assumptions and function usage from the RTI module are correct, or if I am missing something?

Your assumptions are correct, and you will get time in ms here.

However, i would also suggest you refer below thread once, i handled this thread long back and here i mentioned one boundary condition:

(+) TMS570LC4357: Queiry on delay using the timers(on rollover condition) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi Jagadish, 

Thanks for confirming.

I'll once go through the thread which you had mentioned for understanding boundary condition, will get back if any further clarification is required.

Kind Regards, 
Naveen R

Hi Jagadish,

I have gone through the thread which you had attached to handle boundary condition. But I am facing some issue while handling it.

In my setup, the rollover is configured to occur every 9375 cycles.

For example,
the start tick is 2, and the boundary condition is checked only if it is less than 2. However, in the background, the ticks continue to increment, eventually rolling over and exceeding the start tick.
How can we handle the boundary condition in this scenario?

    rtiInit();

    rtiStartCounter(rtiREG1, rtiCOUNTER_BLOCK0);
    get_start_tick = rtiGetCurrentTick(rtiREG1, rtiCOMPARE0);

    for(i=0; i<10000000; i++) // dummy loop to check the timing
    {
        get_cur_tick = rtiGetCurrentTick(rtiREG1, rtiCOMPARE0);
         if(get_cur_tick < get_start_tick)
        {
            get_cur_tick = get_cur_tick + rtiREG1->CMP[rtiCOMPARE0].UDCPx;
        }
    }

    rtiStopCounter(rtiREG1, rtiCOUNTER_BLOCK1);

    elapsed_time_ms = (float)((get_cur_tick - get_start_tick) * 1000)/rti_clock_freq;

Hi Naveen,

Naveen R said:

the start tick is 2, and the boundary condition is checked only if it is less than 2. However, in the background, the ticks continue to increment, eventually rolling over and exceeding the start tick.
How can we handle the boundary condition in this scenario?

This will happen with your test code, i mean you can't measure the boundary condition with your code. Because you are just measuring the start tick only once after immediately timer start and then you are continuously getting current tick, actually this is not the boundary condition, and this is not the way to trigger the boundary condition.

For example, take these values, these are from the thread i shared earlier,

If you verify the difference between these printed values 18452, 43646, 68840, 94035 .......etc the difference is usually ~26000, right?

So, if you continuously take your initial value and current values then at boundary condition the initial value could be 988425, and current tick value will become 14765 right?

So, this is actually the real boundary condition where the initial value is closure to the max value (1000000) that is 988425 and our current tick value is 14625,

so here to calculate the difference of ticks properly we need to add the UDCPx to the current tick and then subtract it from initial tick, ((1000000+14625) - 988425) = 26340. This implies at boundary condition also we got proper difference only.

In your case you are just fixing initial value to the 2 which is immediately after start of the timer and then you are never changing this and just changing the current tick and calculating difference, this is not ideal way to calculate delays right?

I hope this clarifies your doubts.

--
Thanks & regards,
Jagadish.