[参考译文] MSP432E401Y：如何计算空闲任务中所用的时间

尊敬的 Charles：

您能不能再详细说明一下。 我参考了工作台循环示例。 无法获取。  

在空闲任务中使用哪个 API。

您好！

 我不是 TI-RTOS 专家。 运行基准循环示例将显示正在收集的以下基准测试。

我曾想你可以 使用 示例中 用于计算 Idle 函数中周期数的 Timestamp_get ()来执行类似操作。 我能想到的另一种方法是创建用户定义的空闲任务。 在空闲任务内部、您将 GPIO 引脚设置为高电平、并且在其中一个任务中、最好是在优先级最高的任务中、您将清除 GPIO 引脚。 在示波器上、您可以看到 GPIO 引脚在一秒内变为高电平的相对时长。  

在.cfg 文件中、您可以按如下所示插入自己的 Idle 函数。  

尊敬的 Charles：

我已使用 GPIO 检查了 cpuload。  

我做了一个像这样的空闲任务

空 idleTask (空)
｛
     while (1)
    ｛
         GPIOPinWrite ->高电平

         Task_sleep (100)；
     }
}

在经过1秒的时间范围内、我获得了50%的 CPU 负载

但当我签入 CCS 时、CPU 负载图会显示为100%

这是意料之外的。 您能帮助我调试 CCS 工具问题吗？此图显示了错误的结果。

您好！

 CCS 上显示的 CPU 负载是否持续一秒？  您是否能够缩小较大的时间范围？ 用户任务是什么？您正在运行多少个任务？  

尊敬的 Charles：

上面的照片不是1秒,但我保持了更长的运行,观察图表15分钟。 它持续显示为100%。

除空闲任务外、总共6个用户任务正在运行。

所有用户任务的简要说明

任务1 -->根据基于中断的按键，它做出一些决定。

任务2-->计算了16个通道的 ADC 值

任务3 -->通过 i2c 执行与 IC 的通信  

任务4-->如果发现基于条件的某些故障、则发出警报。 基于 TI RTOS 的队列实施50                独特组件。

任务5 -->看门狗任务，所有其他任务都需要在其时间范围内向看门狗任务报告。

任务6-->通过 UART 与外设进行通信。

您好！

 在将您的问题发送给我们的 CCS 专家之前、我建议再做一个实验。 您现在如何复位 GPIO？ 只是最高任务吗？ 您能尝试在您的所有任务中清除 GPIO 引脚吗？ 只要进入空闲任务、GPIO 引脚就会生效、但只要它切换到任何其他非空闲任务、就会清除 GPIO 引脚。  

 从 CCS 的角度来看、我不知道哪些任务是空闲任务、哪些是非空闲任务。 如果 CCS 将您的用户定义的空闲任务视为常规任务、则可能会解释为什么 CPU 负载为100%。 如果是这种情况、则通过引脚切换使用用户定义的空闲任务不是正确的方法。 但我将把这个问题推迟到 CCS 专家那里征求意见。  

尊敬的 Charles：

所有用户任务中的 GPIO 复位时、环路会自动启用。 我执行了该操作、并在下面附上结果。

添加一个优先级

空 idleTask (空)
｛
     while (1)
    ｛
         GPIOPinWrite ->高电平

         Task_sleep (100)；
     }
}

我将 Task_sleep 修改为100、200和250、并附加下面的结果。  

idle_task-->修改 task_sleep 为200

idle_task ->将 task_sleep 修改为250

我不知道当我在 ROV 下使用 CCS 工具检查 CPU_LOAD 时,它是如何计算的,有没有地方可以看到设置?

您好！

 不管 ROV 显示的是什么,请记住 task_sleep()是系统节拍的。 默认情况下、节拍为1ms。 当你将 Task_sleep (250)包含在你的用户定义的空闲任务中时 、它将首先设置 GPIO 引脚、然后使任务进入阻止状态250ms。 当用户定义的任务处于阻断状态时、我非常确信您的其他6个正常任务是根据事件(例如信标或其他事件)触发彼此运行的方式运行的。 这就是您显示99% CPU 负载的原因。  或许更准确的方法是删除 task_sleep。 在用户定义的空闲任务之后、它仅设置引脚。 如果没有其他任务要运行、内核应调用其他空闲任务(见下文)、直到您的正常任务恢复运行、此时 GPIO 引脚再次被清除。   

 我会将您的问题转发给我们的 CCS 专家、供您对 ROV 如何计算和显示 CPU 负载进行评论。  

大家好、thanku、他建议这个实验、空闲任务大部分时间都在运行。 这增强了我的信心、CPU 负载不是100%、这会反映在 CCS 上。 您能将我的问题转交给任何 CCS 专家吗？  

您好 Ashwini：

您能否提供所用的 CCS、SYS/BIOS 和 XDCtools 的确切版本？

如果您还可以提供测试用例项目、那将非常有用。

谢谢

小标题

我不确定从空闲函数调用 task_sleep 是否有效。
通常、当一个任务无事可做时(例如、它已经到达一个诸如 sem_wait 或 task_sleep 的阻塞调用)、调度程序会给优先级较低的任务一个运行机会。 当我们到达最低优先级且没有任何任务可执行时、调度程序会浪费在空闲循环中运行的 CPU 时钟周期。 如果您添加了任何用户空闲函数、它们将被调用并且一直停止、直到任务需要做一些事情。
如果在空闲任务中放入 sleep (100)、CPU 将会在哪里运行12、000、000个时钟周期？
我想结果是不确定的。

您好、ki、

CCS 版本= 11

XDCtools 版本= xdctools_3_61_02_27_core

我们使用的是 SDK 版本= SDK_4_20_00_12

您好！

在上面的消息查尔斯纠正了方法,并建议:

或许更准确的方法是删除 task_sleep。 在用户定义的空闲任务之后、它仅设置引脚。 如果没有其他任务要运行、内核应调用其他空闲任务、直到您的正常任务恢复运行、此时 GPIO 引脚再次被清除。   

我按照此方法操作、发现 CPU 负载不是 ROV 下 CCS 中所示的100%。

Unknown 说：

我已经按照此方法操作，发现 CPU 负载并非如 CCS 中 ROV 下所示100%。

我不确定我是否理解。 按照这种方法操作后、ROV 下的 CPU 负载现在不再是100%？

您好！

我利用 GPIO 和测量的 CPU 负载进行了该实验。 如果我看到 ROV 下的 CPU 负载、仍然是100%。

您能否提供重现问题的测试用例项目？

谢谢

小标题