我的程序中也有这个问题。我用 Atollic TrueSTUDIO 在我的 Stm32 NucleoF446RE 中添加了 vApplicationIdleHook,只是为了测试它,没有特别需要。我记得调用了 vApplicationIdleHook 并且可以打印一些东西,但是继续使用我的应用程序,现在 vApplicationIdleHook 不再被调用并且表现不佳。我不会在这里写太多代码,因为事情会太长,但对于像我这样的业余爱好者来说,提示也很容易理解。
目前工作安排:
1)在 FreeRTOSConfig.h 我添加两行
#define configIDLE_SHOULD_YIELD 0
#define configUSE_IDLE_HOOK 1
2) 在 main.c 中,我只添加了我的 void vApplicationIdleHook(void) 定义:无需向前声明。我在这个函数里面放了一个测试点:根本不是 osDelay 或更糟的是一个无限循环。
3)在 main.c 我创建了一个任务。它的优先级无关紧要。
部分代码:
int uuu = 0;
int main(void)
{
//create StartTaskDef with osPriorityLow
//boilerplate code...
}
void vApplicationIdleHook(void)
{
uuu++; // CCC
}
void StartTaskDef(void *argument)
{
const TickType_t xDelayms = pdMS_TO_TICKS(2); // cimsis_os2.h version
while (1) // AAA
{
osDelay(xDelayms); // BBB cimsis_os2.h version
}
}
测试 1。
在上面的代码中:注释掉 AAA 行;在 BBB 和 CCC 行设置断点;编译和调试。按顺序调试将停止在:BBB(无论如何优先级更高);CCC;CCC;CCC;... BBB 只会被击中一次,因为它的任务执行一次然后退出。对于每个 CCC 命中,uuu 递增 1。
测试 2。
保留上面的代码,保持 AAA 行处于活动状态;在 BBB 和 CCC 行设置断点;编译和调试。按顺序调试将停止在:BBB(无论如何优先级更高);CCC;CCC;CCC;...对于每个 CCC 命中,uuu 递增 1。这似乎很奇怪,因为现在行 AAA 是一个无限循环,并且调试不再命中 BBB。所以删除行 CCC 处的断点并恢复调试。现在调试将停止在:BBB;BBB; BBB; ... 在每次调试停止时对 uuu 的检查表明,现在 uuu 不是增加了一个单位,而是增加了数千个。这意味着当行 BBB 正在执行时(StartTaskDef 正在休眠),vApplicationIdleHook 可能会执行数千次。
注意事项。
调试 vApplicationIdleHook 比这个操作系统的其他对象更难,但可以解释,应该被信任,也许可以改进。cimsis_os2.h 对 osDelay 的在线描述与
FreeRTOS 给出的描述之间存在一些混淆:osDelay vs HAL_delay
其中说 osDelay 的参数是毫秒。
这里我使用了第一个版本(cimsis_os2.h 版本),但我更喜欢解决另一个类似问题的第二个版本。