[参考译文] RTOS/EK-TM4C129EXL：请建议我添加第二个线程。

Yuliy、您好！

我假设您还具有以下全局变量。

Task_Structtask1Struct;
char task1stack[TASKSTACKSIZE]；

如果是这种情况、它应该起作用。 您是否可以在 BIOS_start 中设置断点并运行到它。 然后在 CCS 中查看 Tools->ROV->Task->Detailed。 您应该会看到三个任务(空闲任务和在 main 中创建的两个任务)。 您还应该能够在每个任务函数的开头设置断点、以确认它们正在运行(例如、在 UARTRXFxn 和 echoFxn 上)。

次要 NIT、您不需要第二个 Task_Params 结构。 您可以对 Task_construct_duct 调用重复使用同一个调用。 只需确保根据需要更改所需字段(例如，stack 和 instance->name)。

Todd

>我假设您也具有以下全局变量。  

是的、我有。

然后在 CCS 中查看 Tools->ROV->Task->Detailed

我有 tools->ROV classic，我看到以下图片。 第二个线程仍然没有启动。

>是否可以在 BIOS_start 函数值中设置断点并运行到该断点。 然后在 CCS 中查看 Tools->ROV->Task->Detailed。 Y

现在我先重新排序，然后打开 了 Tools->ROV classic->Task->Detailed，然后运行到 BIOS_start。

我看到以下情况

我有解决方案。
每个任务都必须有 Task_yield ()；call。
否则它将无法工作。

现在、我有一个简单的问题。 为什么它不是用文档编写的？
它不是可选的、是必须的。
此类信息必须在文档中。

哦、不。

如果某个线程被阻止、例如 UART_READ、
这意味着它不会产生。
这意味着所有其他线程都将会窒息...

这是我所说的糟糕设计吗？ 或者我理解有什么问题吗？

更糟

线程中

我阅读了 TI 的答案。

"来回答您的第二个问题。 调用 Task_yield ()时，当前运行的任务将立即使处理器成为下一个相同的优先级就绪任务。”

哈？ 这意味着低优先级线程永远不会有机会运行。

为什么要引入线程的初级机制？

看起来我在该频道中只有一个...

[引用 user="Yuliy Poluyanov"]看起来就像我在这个渠道中独自...

可能是因为这里没有太多人使用 TI 的 RTOS (实际上、我认为这可能是一个相当好的一般性声明)。 您必须查看有关任务分配方案的手册。

Robert

您好、Robert、

> 您必须查看有关任务分配方案的手册。

本手册具有撕裂性。 没有关于 Task_yield ()命令的单个字。。。例如。。。

在具有相同优先级的2个线程的情况下、具有较低优先级的轮距将完全不会占用 CPU。

它已经足够了。。。  

我认为这是一个严重的设计错误。

[引用用户="Yuliy Poluyanov"]

在具有相同优先级的2个线程的情况下、具有较低优先级的轮距将完全不会占用 CPU。

它已经足够了。。。  

我认为这是一个严重的设计错误。

[/报价]

这是一个相当常见的设计决策、我认为唯一更常见的决策是禁止具有相同优先级的多个任务。

某些 RTOS 确实在具有相同优先级的任务之间进行循环时间分片、但即使在这种情况下、也可能会默认为更高效的协作任务分配方案、使用作为某种类型的任务生成。 请注意、在这种情况下、会等待信标等。 通常具有隐式良率、因此您可以在许多情况下写入时不添加显式良率。

手册中应包含与函数调用解释分开的某种操作说明/理论部分。 或者、您可能会看到选择限制性较低的 RTOS 的原因。

Robert

看来您已经足够早了、可以轻松切换到非特定于供应商的 RTOS。

Robert

自由 RTOS 和 uCOS-II 成为可能

Yuliy、

TI-RTOS 是抢先式 RTOS (与大多数 RTOS 调度程序非常相似)。 最高优先级的任务一直运行到它

1、一个更高优先级的线程准备好运行(例如、更高优先级的任务、Swi 或 Hwi)。

2.它达到阻塞条件(例如、具有非零超时的 Task_sleep 或 Semaphore_pend、信标不可用或 UART_read、您需要阻止数据进入等待)。

它调用 Task_yield、并且具有相同优先级的另一个任务已准备好运行(不是常见用例)。

在设计任务时、不应长时间占用资源、因为它可能会占用较低优先级的任务(就像您不应长时间占用 ISR 中的资源一样)。 当然、如果您必须这样做、则可以选择、而不是调度程序。 设计人员应根据其系统/应用的需求设置相应的优先级。

TI-RTOS 实际上在嵌入式领域相当流行。 这里是中的一个图表  

遗憾的是、我们在传达姓名方面做了一个令人困惑的工作、因此我们经常会拆分为两个项目。

您看到的循环技巧并不常用。 有几个客户希望这样做、因此我们展示了一种可行的方法。 更常见的方法是使用常规抢先式调度程序、并根据需要使用不同的优先级。

Todd

谢谢 Todd、

您的信息是合作和有用的。

您说得对、我正处于我的设计的偏执阶段、处于概念验证阶段的某些位置。 更改操作系统的时间不是太晚。

晚上睡觉后、我仍然认为我可以根据您的新输入调整我的设计。 我将保留 TI-RTOS。

我唯一想告诉您的是。 请至少添加一个指向 TI 文档的链接、以便工程师可以用调度程序 Inti RTOS 的优缺点来通知自己。

非常感谢。