Sys*_*der 5 embedded rtos scheduler task
我想通过使用 RTOS 更具体地了解硬实时系统背后的概念。根据 RTOS 的定义，它保证实时任务永远不会超过其最后期限。
void RT_task1(void *params)
{
do_inits();
while (true)
{
... // Do the job whatever it is in realtime.
Delay(20); // Wait for 20 ms.
}
}
这是 RTOS 中基于任务的实时系统的简单结构。在这一点上，我想知道这些问题；
1）此代码块中 RTOS 定义中提到的“DEADLINE”是什么。是“Delay”时间20 ms还是“Do Job”部分确定的其他时间？
2) 如果超过期限会怎样？我知道它是由 RTOS 保证的，但在“假设情况”下：我们是否定义了灾难性错误过程？
3）RTOS如何保证工期？我的意思是，我可以运行大量 RT 任务，因此 CPU 资源可能不够，或者编程错误的任务比其他 RT 任务消耗了太多时间？“保证”部分在哪里？
我知道 RTOS 和传统操作系统之间的主要区别在于调度程序。RTOS采用确定性的方式为用户提供调度保证。然而，这些信息并不能完全满足我对整个系统的理解。
谢谢。
@System Coder 写道：
根据 RTOS 的定义，它保证实时任务永远不会超过其最后期限。
那不是真的。根据定义，实时操作系统保证任务的确定性调度。任务是否满足截止日期完全取决于应用程序的设计和实现，尤其是如何划分任务、如何触发任务以及如何分配优先级。
如果硬实时任务超过其截止日期会发生什么？
更合适的问题是，如果任务未能在截止日期前完成，您的应用程序将如何表现？这个问题完全取决于应用程序。RTOS 本质上不会检测失败的最后期限，因为它不了解您的应用程序。RTOS 的目标是以永远不会超过最后期限的方式设计调度和优先级分配。如果超过了最后期限，则说明您的设计存在缺陷，而不是 RTOS 的故障。
你的代码片段太简单了；实时应用程序通常必须响应外部事件（除了时间），如果循环的目标是每 20 个操作系统周期执行一次任务（根据评论是毫秒），那么如果延迟时间超过 1 个刻度之前的代码。此外，初始执行将与 RTOS 时钟周期异步，并且在任何情况下，第一个和第二个循环执行之间的时间都将不太确定（在 19 到 20 个时钟周期之间）。
对于没有硬性截止日期的任务来说，循环中的延迟是可以接受的。例如 PID 回路，这是一个糟糕的设计。相反，在您的示例中，您应该使用 RTOS 计时器（而不是延迟）；这样循环体只需在 20 毫秒内完成，而不是 1 毫秒。如果有更高优先级的任务和中断抢占了这个任务，即使代码本身在 1ms 内完成，如果被其他代码抢占和延迟，它也可能会错过该截止日期；因此，有 20 毫秒的时间来完成任务显然是有益的。
1）此代码块中 RTOS 定义中提到的“DEADLINE”是什么。是“Delay”时间20 ms还是“Do Job”部分确定的其他时间？
截止日期是您的申请成功满足其要求所必需的截止日期；它不是由 RTOS 定义的，而是由您的需求定义的。如上所述，您的示例可能不是实时任务的良好设计，除非它和所有可能的抢占任务可以在不到 1 毫秒的时间内完成。无论如何，它的可扩展性都不是很好，并且最初满足最后期限的设计在维护、新代码或优先级重新分配后可能不再这样做。
2) 如果超过期限会怎样？我知道它是由 RTOS 保证的，但在“假设情况”下：我们是否定义了灾难性错误过程？
就像我说的; RTOS 不保证这一点，失败的后果取决于您的应用程序。如果没有发生什么不好的事情，也许最后期限是错误的并且不必要地紧迫。如果失败，您需要重新考虑系统的可调度性。
3）RTOS如何保证工期？我的意思是，我可以运行大量 RT 任务，因此 CPU 资源可能不够，或者编程错误的任务比其他 RT 任务消耗了太多时间？“保证”部分在哪里？
不可以；能够保证确定性调度；最高优先级的“就绪”任务将立即运行（在上下文切换时间的限制内）——就这么简单，仅此而已。即使在 RTOS 中，由于中断处理程序设计不佳，您仍然可以使调度变得不确定。它们还需要具有确定性——每个都在有限且理想的恒定时间内执行。任务执行的最大延迟是所有较高优先级任务和中断的执行时间之和；作为一般经验法则，通过将最高优先级分配给执行时间最短的任务，可以最大限度地减少延迟。执行时间不确定或变化很大的任务应给予较低的优先级。其他应用程序特定因素也会发挥作用，例如任务如何与其他任务交互、通信或同步。