RTOS的最佳定义是什么?

时间:2016-01-16 17:32:49

标签: rtos

我还没有找到特定于具有意义的RTOS定义。我能找到的最好的是wiki:

https://en.wikipedia.org/wiki/Real-time_operating_system

但是我有一些批评意见/问题:

  1. &#34;实时&#34;似乎在我发现的所有RTOS定义中都没有定义。没有什么比实际的实时更快(无限小!)。因此,我相信&#34;实时&#34;只有在观察者的背景下才有意义。使用iPhone用户的人的实时时间可能<20ms,因为人眼视线无法更快地检测到变化。对于气囊展开,它可能<1ms。互联网上的所有定义似乎都掩盖了&#34;实时&#34;的定义!
  2. 如果RTOS是由在特定时间范围内执行某些事情的要求定义的(&#34;截止日期&#34;),为什么抖动会进入定义?如果iPhone响应在12-14ms之间抖动,它是否不再实时响应?它符合20ms的要求,对吗?如果响应一次达到100毫秒,则用户可能会注意到,此时系统不是RTOS
  3. 怎么可能有&#34;软&#34; RTOS? RTOS的定义符合特定的截止时间要求。如果它不符合它,那么它不是RTOS! RTOS的定义禁止使用&#34; soft&#34; RTOS
  4. 对我而言,似乎没有正式和精确的RTOS定义。它是一个通用术语,用于解释操作系统的特性,其主要优先事项是实时&#34;实时&#34; (根据要求编号)特定类型的观察员。看起来这个名称似乎已经采用了实现的含义,例如如何处理事物,多任务处理,消息传递,信号量等等......如果系统无法响应,那么所有这些都可能根本不属于RTOS的一部分。 &#34;截止&#34;要求,对吧?

    对于这样一个无处不在的问题感到抱歉,但我无法在脑中清晰地看到这个问题。我发现的所有定义都不够精确,或者使用实现细节来定义定义。

2 个答案:

答案 0 :(得分:1)

你是对的,没有定义来定义确切的时间范围。这不是定义的目标。但实时并不依赖于观察者,而是应用程序。由于应用程序不同,时间范围不同,因此定义不能将该范围赋予数字。

只要满足应用程序的时间限制,抖动就无关紧要了。你对这个例子绝对正确。如果截止时间是20毫秒,则花费100毫秒是失败的。如果操作系统要归咎于延迟,那么它不是RTOS。

&#34;软实时&#34;有一个非常具体的含义,这可能是你唯一真正错的。这里的概念是,当任务超过截止日期时你会怎么做? (注意:这可能是任务本身或RTOS的错误。)在硬实时系统中,任务根本没有任何价值。迟到的结果和没有结果一样好,你取消了任务。没有必要担心其他任务。

软RTOS实际上更复杂。完成任务仍然有价值,虽然减少了。因此,RTOS不会难以杀死任务,但操作系统仍然必须确保其他任务满足其最后期限。这需要额外的照顾,如果你只是为了完成这项任务,这是不必要的。

答案 1 :(得分:0)

有一个Embedded Systems Dictionary。以下是一些摘录:

  

实时 adj。具有及时性要求,通常以不能错过的截止日期的形式提供。

     

实时操作系统 n。专门设计用于实时系统的操作系统。简称RTOS。

     

实时系统 n。任何具有及时性要求的嵌入式或其他计算机系统。可以使用以下问题   将实时系统与其他系统区分开来:“这是一个迟到的答案   坏的,甚至更糟,而不是错误的答案?“换句话说,会发生什么   如果计算没有及时完成?如果没有不好的事情,   它不是一个实时系统。如果有人死亡或任务失败,   它通常被认为是“硬”的实时,这意味着暗示   系统有最后期限。介于两者之间的一切都是“软”   实时性。