[参考译文] RTOS/TM4C1294KCPDT：RTOS 2.16.1.14更新存在一些问题。

#1通过添加睡眠周期为2000ms 的(while)与(IF)指令来变通解决问题。 正在等待从 GUI 激活布尔开关。 奇数部分是睡眠期间后每次排队的任务、但布尔开关显然没有被锁存。

#2使用的任务名称被显示，以便任何人都知道哪个任务来自 所有(动态)分配的 HWI 任务处理程序。  2000ms 超时周期显示日志记录、但有2个静态任务 具有相同的记录器列印语法。

 RTOS 分析器格式：664000063025、、Cortex_M4_0、"LM_SLEEP：tsk：0x200147a8、func：0x58f9、超时：2000"、Task_LM_SLEEP、Unknown、200147a8、11287、LoggerIdle、ti.sysbios.dl.task、ti.589.bios.d790、0x778000、0x768K、0x678K、0x768K、0x7K、0x7970K、0x7K

静态任务函数记录器：

/*休眠2000ms */
Task_sleep (sleepDurs)；
Log_print2 (Diags_User1、"任务%d 处于唤醒状态、计数=%d"、0、 count)；
count++； 

3号程序不能放入可用的内存中。  ".VTable"大小为0x26c 时运行定位失败、与".vecs"、大小为0x360 (第0页) tm4c1294kcpdt.cmd  /rtsc_BLDC_QS_IoT 行38 C/C++问题重叠。

* RTOS Project (TM4C129x.cmd)文件 分配错误 (.vtable 为十六进制值)、 change (.vtable：> SRAM) make (.intvecs：> FLASH)该问题是将 现有应用程序迁移到 RTOS 的关键时间。

您好 Todd、

剩下的唯一问题是、RTOS 分析器图形在 周四的最新更新 CCS7中未生成任何行、并且它替换 了许多 IDE 文件等。 唯一的图形工作方式是执行、但仅为内核空闲任务生成一行。 CPU 负载图之前生成了几 个不同的动态 HWI 加载的任务 、这一点在一段时间之前似乎已经有所回顾。   

 CCS7.0版本更新：

 IDE -调试服务器集成功能 6.0.1.201705101800、   RTSC/XDCtools (目标运行时支持) 3.32.25、   XDCtools 核心更新功能 3.32.2.25、 Code Composer Studio IDE 主要功能 7.2.0.201705101800、系统分析器(UIA 目标)、 (IDE 客户端) 2.0.5.50、 <<DVT - Graph 4.1.7050.38> Visualization

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/648499/2382951#2382951

问题是、日志记录应在何时以及是否可以生成 CPU 负载详细信息时生成 CPU 负载图。 如果是、更新中可能会更改哪些内容来中断 RTOS 图形功能。 原始 RTOS 内核版本为3.32.01.22

是的、它应该：

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/648499/2382951#2382951

您好 Todd、

经过几个小时的 RTOS 2.16.1.14评估 后、我的结论是静态任务只执行 一次 、即使调试实时事件指示 加载多次、0.00 CPU 负载会被记录得更久。  静态任务仅 在  首次加载时执行(IF)指令 、并且在任务 模块返回 指示 加载、0.00 CPU 加载后无法执行加载的任务函数。  在这种情况下、静态 任务仅 在 任务本身中存在(while 循环)时执行函数、从而 在 任务模块处理程序中使其保持活动状态(持续)。

这 种奇怪的行为 似乎与  任何任务模块在集线器和辐条内核或其他方面的行为相互矛盾。 当 任务函数 从不(返回) 且循环与其他事件不同步时、Point 尝试使用(Task_sleep)来限制任务内核时间片会导致(高速)可视显示数据的异步计时不稳定。 需要 while 循环来保持静态任务活动(辐条)这一简单事实似乎表明  任务模块(集线器)中存在严重错误。  因此、当   使用具有布尔开关限定符 的(If)指令来调用函数时、任务将排队、但绝不会重新执行。  

您好 Todd、

关于静态任务执行 行为； 去年报告 了  一年前的相同奇怪行为(未完全理解)问题。  测试 已将我们的 USB0打印静态任务调用移至 现有 的功能型1秒周期性 GPTM 计时器中。 RTOS 实时事件显示 (IF)指令布尔开关静态任务 持续(加载)、 在任务初始执行后 CPU 负载为0.00。  但是、静态任务会在函    数中作为由(Clock_tick)使用相同的布尔开关(IF)指令(no Task_sleep)指令管理的任务发生错误故障时持续执行。  

同样 、要求(while)指令保持活动 状态的静态任务似乎 指示(Clock_Tick)或其他任务 对任务模块没有影响(执行)任何静态任务、但只影响1次。

[引用 user="BP101"]需要(while)指令使其保持活动 状态的静态任务似乎 表示(Clock_Tick)或其他内容 对任务模块没有影响(执行)任何静态任务、但只能是一次

已验证静态任务退出、然后 进入阻止 、但 保持 加载(持续) 实时事件、 但实际上从未重新加载任务 优先级15。  然而、从 M3 HWI 注册的周期性 GPTM 处理程序调用相同的静态任务  会持续执行(XDC_void)任务。 非常困惑为什么内核任务模型不会对 曾经被阻止 的任务重新排队。  

很困惑——我也是……

[引用 user="ToddMullanix"]为什么要从计时器调用任务函数？

由于任务在由内核控制下的任务模块计时器处理时经过(IF)指令后从未执行、 因此假设使用 Clock_tick。  然而   、由任务模块审核的静态任务 (Clock_tick)在 看似进入阻塞状态后持续指示加载、从不会再次执行 、但似乎会重新排队 进入加载状态。 相当肯定它从未退出、但只有在定时器控制下才能实际退出。 在任务内部添加 while 循环可使任务在任务处理程序中保持活动状态。

 没有指示静态任务 从 内核任务模块中退出(内部功能)。 理想情况下、除非任务处理程序内部或内核仲裁明确指示任务退出任务模块控制。 例如、在函数中发出(Task_exit)命令。  静态任务实例  在加载后应动态地受任务模块的控制。 这是 直到应用  程序通过 (Task_exit)或内核取代 任务执行顺序来声明应用程序或内核异常。  

是否内核 Clock_tick 用于  控制任务模块 以在执行中和执行中执行外滚动任务？  因此  、任务处理程序中的 Task_sleep 指令 可以 传递 计数值 (void ARGU0)以限制 任务模块 加载 任务以执行。    如果应用程序的 CPU 执行优先于任务模块、内核不在优先级控制中、会发出 Task_constructive 指令 。  此 类指令 应 从内核控制的任务模块执行、而不是从主应用程序执行。

[引用 user="ToddMullanix"]您必须调用 Task_create (或 Task_construct)才能使其返回。

任务已 由任务模块实例构建、为什么需要继续重新创建任务模块已动态 调制的相同实例？ 任务模块处于最高优先 级内核控制之下、 第二优先级设置 为 应用程序控制任务。 任务模块似乎允许静态创建的实例 (任务)函数在不应该时自动退出。 任务处理是内核任务模块的任务、而不是应用程序的任务。 否则、除了在调试中查看正在打印的实时事件外、为什么甚至需要首先使用任务模块。

让我们回到基础知识、因为我认为我们谈论的是不同的事情。

这是一个典型的任务永远运行(尽管在完成工作后将睡眠5个周期)、并且永远不会退出。

空 foo (UARg arg0、UARg arg1)

｛

  while (1)｛

   //执行不会离开 while 循环的有趣操作(例如、无"中断"、"转至"等)

   Task_sleep (5)；

  ｝

  //永远不应该出现在这里

｝

这是一个可以退出的任务。

空栏(UARg arg0、UARg arg1)

｛

  INT 标志= 1；

  while (flag)｛

   //做一些有趣的事情

   Task_sleep (5)；

   if (某些条件)｛

     标志= 0；

   ｝

  ｝

  //可以到达此处，任务将退出。

｝

任务退出时、我们是否使用相同的语言？

Todd

 Tivaware 的布尔开关指令；例如 #include

bool g_bPrintingData = true； 

Task_Params_init (&taskParams)；taskParams.STACKSIZE = TASKSTACKSIZE；taskParams.stack =&task1Stack；

Task_construct（&task1Struct,(Task_FuncPtr) PrintAllData_taskFxn、&taskParams、NULL)；

void
PrintAllData_taskFxn (UArg0、UArgarg1)
｛
/*打印 tStats 中的设备统计信息*/
if (g_BPrintingData)(如果(g_BPrintingData))
｛
USBprintf ("\n>打印所有数据 tSats \n")；
/*打印出 MAC 地址以供参考*/
PrintMac()；
/*每周期打印存储 CIK 的 SRAM 阵列缓冲区。 *
USBprintf (">CIK：%s\n"、ExositeCIK)；

//打印一些标题文本。
USBprintf ("\n <<收集的统计信息">\n")；
USBprintf ("-------------------- \n");
PrintStats (g_psDeviceStatistics)；
USBprintf ("\n")；
｝

log_print2 (Diags_all_logging、"任务%d 唤醒、计数=%d"、ID、计数)；
count++；
｝ 

[引用 user="ToddMullanix"]如果任务退出(例如调用 Task_exit 或退出任务函数)、则任务将消失。 如果您想重新调用 Task_create (或 Task_construct)，则必须调用它。

编写的任务 不应落在上面发布的它自己的代码下。 奇怪的 ROV 显示 任务已模糊 终止(黄色框)。   与实时事件不同的状态保持 过帐(LS_taskLoad) 加载(如下)。 对于在同一发布代码中进行布尔开关(IF)测试的 Task_sleep (duration)在内核出现故障的原因、仍然没有回答。 但是  、物联网 任务中存在 Task_sleep（n)、 while 循环 不会对内核进行故障排除。

、"LS_taskLoad：0x2001582c、0、-764920560、0x7c81"、Load、TSK、PrintAllData_taskFxn ()@2001582c、0.00、1449、LoggerIdle、ti.sysbios.utils.Load、ti.sysbios.utils.Load、、、、、700702740、0x360C、0x822082C、0x20822041、0x2760C

您能否附上证明您的问题的已导出示例项目？  

Todd

您好 Todd、

项目具有 机密部分、但相关任务会发布在上述主题中。  无论  任务在结束或添加到 main 之前是否添加到该任务的底部、在终止后添加(Task_con构)语法都不会使(IF)任务重新加载。 将 下面的(Task_construction)语法添加到一个1秒计时器函数 或另一个运行中的任务中、while 循环会使 MCU 发生故障。

令人困惑的部分是(while)替换上面线程中已过帐(PrintAllData)任务中的(IF) 、所有任务似乎在一段时间内都运行正常。 奇怪 的是(Task_sleep)似乎会显著降低 UART2日志记录间隔的速度、这要远远超过 while 循环、它们是 每个   任务的 After (Task_construction)语法(下面)中的一部分。  在 处理 任务中的任何 while 循环时、到目前为止添加的两个应用程序任务似乎将 CPU 从内核中夺走、但 允许(Task_sleep)保持在内核控制之下。

void
main
｛

/*构造 BIOS 对象*/
Task_Params taskParams；


Task_Params_init (&taskParams)；
taskParams.STACKSIZE = TASKSTACKSIZE；
taskParams.stack =_task0Stack；
Task_con构(&task0Struct,(Task_FuncPtr) IOTAppLoop TaskFxn、&taskParams、NULL)；

Task_Params_init (&taskParams)；
taskParams.STACKSIZE = TASKSTACKSIZE；
taskParams.stack =_task1Stack；
Task_construct（&task1Struct,(Task_Functr) PrintAllData_TaskFxn、&taskParams、NULL)；

//一些应用程序初始化代码

/* SysMin 仅在您调用 flush 或 exit 时才会打印到控制台*/
system_flush()；

/*打开用于日志数据的 UART */
UARTUtils_loggerIdleInit (Board_UART0)；

/*启用 IOT SW 中断*/
G_bPrintingData = true；

/*启动 TI-RTOS BIOS */
BIOS_start()；

/* SYS-BIOS 不应该到达这里，只是在...的情况下。。 *
while (1)
{
} 

似乎(Clock_tick)未 按 预期对每个任务的睡眠周期进行仲裁。  UART2记录器以某种方式执行与 (Task_sleep (n)间隔相反的任务周期打印。 尽管 RTOS GUI 指示 TimerID=5 并验证 了 ROV、 但内核在   将(Clock.timerId = 5；)明确添加 到 配置脚本之前似乎未将(Clock_tick)置为有效。  至少这似乎与 两个记录器同时减缓 RTOS 分析器实时事件的输出重合、几乎永远不会发生、就像它以前相对于 task_sleep（n)命令那样。

更改后，UART2 记录 器打印 到 RTOS 分析器 (Live 选项卡)不 会相对于 Task_sleep()持续时间发生，Task_sleep(n)命令对  传递的持续时间值响应不是很灵敏。  ROV 过帐 硬总线故障精确 存储器地址 (0xbebebc)时、应用程序更频繁地崩溃。 遗憾   的是、应用程序在没有任何 RTOS 内核任务的情况下要稳定得多、更不用说它有时在数千小时的在线运行后不会崩溃。