器件型号： TDA4VE-Q1
这是针对最高 11.2 的所有 TI PSDK 版本中存在的问题的错误报告
PDK OSAL 提供 TaskP_WaitMsec() 函数。
MCU_PLUS_SDK 提供 ClockP_usleep () 函数。
app_utils 图层为这些应用程序提供包装器 appRthosTaskSleepInMsecs()。
可以预期、这些函数将在给定的延迟时间内延迟当前任务的执行。 可能会发生这种情况、任务稍后唤醒（如果此时有一个更高优先级的任务正在运行）。 但是、一个合理的预期是任务 不会提前唤醒。
但是、 由于这些功能是如何实现的、情况并非如此。 在内部、它们映射到 FreeRTOS vTaskDelay ()/ SAFERTOS xTaskDelay () 调用、以延迟给定数量的 tick 的当前任务 — 但这会计算当前的 tick！ 因此、如果在节拍间隔的中间调用 appRtosTaskSleepInMsecs(1)、它将在半毫秒内返回。 如果在周期间隔接近结束时调用相同的方法、它几乎可以立即返回。
如果在调用 appRthosTaskSleepInMsec() 之前和之后调用 appLogGetTimeInUse()、则可以轻松地观察到这种行为。 在空载系统上、两个时间戳之间的差异 始终小于 请求的睡眠时间。
这将中断在硬件通信代码中使用 appRtosTaskSleepInMsecs()、其中延迟很重要、如果未等待所需的延迟、则会中断硬件功能故障。 特别敏感的情况是,当需要数百微秒的延迟时,尝试使用 appRtosTaskSleepInSecs(1)-它确实会中断。
虽然这可以在应用程序代码中通过始终调用 appRtosTaskSleepInMsecs() 来实现每个应用程序逻辑所需的更大延迟、但这种解决方案看起来并不好。 PSDK 中的修复会更好。
