[参考译文] TMS570LC4357：RTI 模块时序分析

尊敬的 Naveen：

我对延迟的反应表示歉意,我已经休息了几天。

您的假设是正确的、您将在这里得到以 ms 为单位的时间。

但是、我也建议您参考下面的线程一次、我很久以前处理过这个线程、这里我提到了一个边界条件：

(+) TMS570LC4357：使用计时器时的多工延迟(在翻转情况下)-基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：  

感谢您的确认。

我将先介绍您为理解边界条件而提到的线程、如果需要进一步的说明、我将返回该线程。

此致、  
Naveen R

尊敬的 Jagadish：

我已经完成了您为处理边界条件而附加的线程。 但我在处理时遇到了一些问题。

在我的设置中、翻转配置为每9375个周期发生一次。

例如、
开始节拍为2、仅当边界条件小于2时才检查边界条件。 然而、在后台、节拍会继续增加、最终回滚并超过 START (开始)节拍。
在这种情况下、我们如何处理边界条件？

    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;

尊敬的 Naveen：

开始计时为2、仅当边界条件小于2时才检查边界条件。 然而、在后台、节拍会继续增加、最终回滚并超过 START (开始)节拍。
在这种情况下、我们如何处理边界条件？

这会在您的测试代码中发生、我的意思是您无法使用您的代码测量边界条件。 由于您只是在立即计时器启动后测量一次开始节拍、然后不断获得当前节拍、因此实际上这不是边界条件、也不是触发边界条件的方式。

例如、获取这些值、它们来自我之前共享的线程、

如果您验证这些打印值之间的差异18,452,43643646,68868840,94035 ... 等等、差异通常是~26000、对吧？

因此、如果连续取初始值和电流值、那么在边界条件下、初始值可能是988425、电流节拍值将变为14765对吧？

因此、这实际上是真实边界条件、其中初始值接近最大值(1000000)、即988425、而我们的当前周期值为14625。

因此、为了正确计算节拍差、我们需要将 UDCPx 添加到当前节拍中、然后从初始节拍中减去它、((1000000+14625)- 988425)= 26340。 这意味着在边界条件下、我们也仅获得适当的差值。

在本例中、您只是将初始值固定为2、即在计时器启动后立即确定、然后您永远不会更改此值、而只是更改电流周期和计算差值、这不是计算延迟的理想方式？

我希望这能澄清你的疑虑。

——
谢谢、此致、
Jagadish。