[参考译文] RTOS/EK-TM4C1294XL：Task_sleep (duration)会破坏正在执行的其他已构建任务。

也许这是内核空闲记录器 、其中睡眠持续时间是任务的一部分、用于缩短其执行间隔 、它是 一个显示抑制器。 CPU 负载模块 设置为500ms、 睡眠持续时间800、 2000源自 并假设 Clock_tick 1000us？

请注意，任务负载增加了0.23到0.34，此时   在 任何睡眠时间内，在高速 USB0中向 PrintAllData_taskFxn()中添加或感知的延迟都很小。 如果应用中没有 TI-RTOS、则当物联网应用连接到云时、USB0打印数据不会减慢速度。

TaskFxn 时间日志记录的理念帮助我们了解函数执行在执行指令时如何影响 CPU 负载。

但等待您不仅在一个 Task_construct()方法中获得了晚餐的全部清理。 如果您现在采取行动，我们将向您发送无缝通用交换 方法 Task.create()，这样您也可以 欺骗您的所有朋友您的内核任务主机比他们的内核更强大。

也许(Task.h)函数 调用 未按预期集成到内核环境中？ 请注意  、任务的构建或创建方法之间的差异产生了两个非常不同的输出、CPU 负载与 调用(main.c)中的 Task_Sleep (800)持续时间相同。

bp101、

[引用 user="BP101]TI-RTOS  内核是多任务处理还是仅多线程处理？ S[/报价]

这取决于您所说的"线程"。 从 Linux 角度而言、您是指"线程"(例如、进程中的多个线程...系统中的多个进程)、还是指"线程"是执行块线程的通用术语。 我们在一般意义上使用术语"线程"。 因此、每个任务、Swi 或 Hwi 都是一个线程。 因此、TI-RTOS 内核既可以执行多任务处理、也可以执行多线程处理。

可以附加用于生成上述执行图的项目。 描述似乎没有意义、我想复制图形、以便我更好地回答您的意见。

Todd

在上述情况下、SRAM 中存在一个任务块、我假设每次加载一个线程句柄时都会执行该任务块。 在抢先式多任务处理中、一个任务绝不会影响其他任务/虚拟内存空间、但整体执行速度可能会受到全局影响。

当另一个任务处于睡眠状态或以其他方式执行时，打印任务中存在较大的执行时间延迟。 预计会有一些延迟、但不会达到发生的程度。 请注意删除 Task_construct()指令并替换为任务模块创建的 Task.create()后的用法已停止。 打印任务仍然有很大的延迟、降低睡眠时间实际上没有什么不同。

您绝对不需要测试我们的应用程序、就可以相信正在发生这种情况。 上面的图形描绘了一个非常清晰的图片，除了显然需要更多工作的其他问题外，RTOS 对 Task_construct()任务的处理存在一些错误。

[引用 user="ToddMullanix"]例如，您提到打印...您是否在 IDE 控制台使用 printf？

否-打印通过 USB0 高速 (480KBPS) 连接至 Windows 主机计算机大容量 设备客户端。

[引用 user="ToddMullanix"]无论任务是通过 Task_create 还是 Task_con构造 创建(假设参数相同)，任务的长期执行都是相同的。

 唯一明显可见的主要区别 是没有使用 Task_constructor 分配优先级、请参阅下面的两种配置方法。

Task_Params_init (&taskParams)；
taskParams.STACKSIZE = 2048；
taskParams.stack =&task1Stack；
Task_con构(&task1Struct,(Task_Functr) PrintAllData_taskFxn、 &taskParams、NULL)；


var task1Params = new Task.Params ()；
task1Params.instance.name ="TaskPrintStats"；
task1Params.priority = 6；
task1Params.vitalTaskFlag = false；
task1Params.arg0 = 1；
program.global.TaskPrintStats = Task.create ("&PrintAllData_taskFxn"、task1Params)； 

由于红色/蓝色线分别是空闲记录器、因此可能不是应对上述延迟负责的内核。 任务方法减少了 CPU 负载使用率的5%。 调试负载的过程甚至更低是最困难的！

[引用 user="ToddMullanix"]您是否知道目标已停止并且 CCS 在 CIO 缓冲区已满或'\n'正在写入时读取其内容

 CCSv7.3在2.8GHz 四核英特尔处理器上运行、并在 USB 打印、 IOT 云写入期间将73个内存线程的负载拉取2%。  我对 CCS7的理解是多线程多内核感知、很难想象它会以图形化的方式影响 RTOS。

与 UARTLogger 一起使用的 RTOS 分析器似乎在高数据速率(例如115200波特)下将数据传输到 CCS 调试中。 更重要的是、当许多(6)个 HWI 停止/启动中断阻塞 RTOS 调试接口时、执行图的 HWI 日志记录会更好。 无论 UART 传输缓冲区空间是多少(64kB)或 Clock_tick Diags 过多或其他内核模块 Diags 日志记录事件在运行时关闭、大量 HWI 事件都将丢失在 Live Session 视图中。

执行行图几乎不显示任何绘图、而 CCS7.3开始调试、很可能是在 Java 代码中的某个位置通过 UART 缓冲区阻塞来响应 GUI 控制。 遗憾的是、我们将 USB0/EMAC0用于应用的其他部分、而 SPI 甚至不是 Logger 传输选择。