对于关键应用程序，嵌入式系统的最大安全CPU使用时间是多少？我们正在用顶级来衡量绩效。 50-75％安全吗？
答案 0 :(得分：1)
实时嵌入式系统旨在满足实时限制，例如：
由于实时操作系统（RTOS）是“抢占式”（调度程序可以挂起任务以执行更高优先级的任务），因此即使在CPU使用率达到100％的情况下，您也可以满足这些限制：执行高优先级的任务，然后恢复到正在执行的操作。
但这并不意味着无论如何您都会遇到限制，一些提示：
对于前面的示例：
要回答您的问题，只要满足实时限制，CPU使用率在50-75甚至100％都是安全的，但是请记住，如果以后要添加功能，如果CPU使用率达到98％，您将没有足够的空间。
答案 1 :(得分：1)
在rate monotonic scheduling中，数学分析确定了当利用率低于大约70％（并适当分配了优先级）时，可以调度实时任务（即具有特定实时期限的任务）。如果您对所有任务都有准确的统计信息并且具有确定性，则可以高达85％，并且仍可保证可调度性。
但是请注意，使用率仅适用于具有硬实时截止期限的任务。后台任务可以一直利用剩余的CPU时间，而不会错过最后期限。
假设“ CPU利用率”是指在具有基于抢占式优先级的调度程序的系统中，执行代码（而不是空闲循环）所花费的时间，则...取决于。
首先存在测量问题；如果您的利用率采样周期足够短，则通常会在100％和零之间切换，而如果很长，您将获得一个很好的平均值，但不知道利用率是否足够高，足以饿死一个较低的优先级任务可能无法按时完成。这是一个错误的问题，因为任何实际的利用率采样率通常会比最短的期限长得多，因此充其量是定性的而不是定量的措施。在关键情况下，它并不能告诉您很多有用的信息。
其次，您正在测量的问题。尽管RTOS通常有一种衡量CPU利用率的方法，但它正在衡量所有任务的利用率，包括那些没有期限的任务。
例如，如果最低优先级任务的利用率达到100％，则对可调度性没有任何危害-从这个意义上说，低优先级任务与空闲循环没有什么不同。在正常情况下，在空闲循环中进入低功耗模式的系统，这可能会对功耗产生影响。
优先级较高的任务占用100％的CPU使用率，因此错过了优先级较低的任务的最后期限，则您的系统将发生故障（从某种意义上说，将错过最后期限-结果取决于应用程序）。
仅测量CPU利用率是不够的，但是如果您的CPU利用率为100％，并且利用率不是简单地在最低优先级线程中执行某些后台任务，则可能无法调度-会有事情无法完成。结果当然取决于应用程序。
尽管低优先级的后台线程消耗100％的CPU可能不会造成任何危害，但确实使测量CPU利用率的功能完全没有用。如果任务是预先植入的，并且出于某种原因，优先级较高的任务占100％，则您可能无法检测到该问题，因此后台任务（以及任何低于抢占任务的任务）将无法完成。因此，最好确保您有一些空闲时间，以便可以检测到异常的调度行为（如果您没有其他方法可以这样做）。
不屈服的后台任务问题的一种常见解决方案是在空闲循环中执行此类任务。许多RTOS允许您插入空闲循环挂钩来执行此操作。然后，后台任务是可抢占的，但不包括在利用率度量中。在那种情况下，您当然不能再有一个没有优先级的低优先级任务，因为您的空闲循环会塞满东西。
分配优先级时，执行时间最短的任务应具有最高优先级。此外，在优先级较高的任务中，执行时间应更具确定性-也就是说，如果要花费100us运行，则它应该在某个合理的范围内始终花费那么长的时间。如果某些处理可能是可变的，以致于大多数情况下需要花费100us，并且有时必须执行需要100ms的处理；那么应将100毫秒的流程传递给某个优先级较低的任务（或暂时降低该任务的优先级，但是这种模式可能难以管理和预测，并可能导致后续的截止日期或事件丢失）。
因此，如果您对任务期限和截止日期含糊不清，一个很好的经验法则是将其保持在70％以下，但不要在测量中包括非实时后台任务。