是否有必要用C语言编写RTOS？为什么不能用java或其他技术编码.. ?? 那是因为java中缺少指针概念吗？
垃圾收集是Java成为实时的重要原因.JIT是另一个,但它可以克服.
通常,C是有效的可移植组件,可提供非常可预测的运行时性能,这对于可靠的实时执行至关重要.
实时系统也可以用其他语言编程.例如,Java有一个Java RTS系统.
与其他答案相反,实时垃圾收集的工作量合理.但是,这些不会捆绑在您的典型发行版中.
令人担忧的是,其他语言通常具有难以实现确定性和可靠性的功能,例如传统的垃圾收集,JIT,运行时优化等.
起初,RTOS不仅仅用C编码.它们也可以用其他语言编码.但是,用于RTOS的语言需要提供确定性行为.这意味着特定操作的延迟必须始终在特定的时间内.这排除了例如垃圾收集,在大多数实现中,垃圾收集将在不确定的时间内停止所有线程的执行.
因为RTOS开发人员很可能不太了解C++.
嵌入式系统中的C++:神话与现实
有些人认为C++有开销和成本使得它不适合嵌入式系统编程,它缺乏C的控制和简洁,或者虽然它可能适合某些小众应用,但它永远不会取代C作为语言嵌入式系统的选择.
这些看法是错误的.在编译器和其他工具足够的地方,C++总是优于C作为嵌入式系统的实现语言.在完成C所做的一切时,它提供了更多表达,封装,重用的机会,甚至可以在C中提供不切实际的尺寸和速度改进.
>那么,为什么这些看法会持续存在？主要原因是当人们形成他们的观点时,他们对C的了解远远超过C++.他们已经阅读了一些书籍,编写了一些代码,并且能够使用C++的功能,但是他们缺乏对幕后发生的事情的了解,这种熟悉性允许人们在输入源代码时可视化反汇编,甚至在制定时也是如此.设计.
在嵌入式设计中使用C++替代C的指南
嵌入式软件应用程序通常用C语言编写.多年来,C++一直被视为自然的继承者,并且已经获得了更大的认可,但其使用量的增长速度远低于预期.
有许多的原因.首先,嵌入式开发人员非常保守,他们更喜欢使用经证实而非新颖的解决方案"如果没有破坏,就不要修复它".
还有经验教训.许多开发人员试图将C++用于嵌入式应用程序并且失败了.这种失败有时可能归因于开发工具的缺点,但大多数情况下,应该责备使用"像台式计算机一样对待嵌入式系统"的语言.
C的局限性虽然C被广泛使用,但它有局限性,因为它不是为嵌入式应用程序或现在常见的规模项目而设计的.主要限制包括:
1)C非常强大和灵活,因此可能是危险的.(它具有低级别的能力 - 这对嵌入式有用"但也代表了许多不警惕的陷阱.)
2)程序员需要非常有条理和有纪律
3)程序员需要了解程序在低级别和高级别的行为(大型项目难以维护)
4)程序员需要熟悉应用程序
但是,C++具有强大的面向对象功能,可以帮助解决C的局限:
1)它将非专家的高专业知识区域封装并隐藏在"对象"中; (测试用例将在本系列的第2部分中展示专业知识的封装).
2)非专家可以直观地使用对象来实现高级概念设计
为RTOS-es通常运行的所有硬件提供高度优化的c编译器.
您可以相对轻松地在c代码中包含非常低级别的优化.
c代码可用于许多有用的低级系统工具,因此可以很容易地合并.
作为一种语言,可以使用Java,并且实际上发生了各种古怪的案例.
但是一些边缘案例和示威活动实际上更多是"证明规则的例外".
通常,Java是一个用于业务逻辑而非OS内核的大型系统.
如果我们还没有C,那么Java可能在不同的方向或多个方向上发展.
但我们确实拥有C,这对于操作系统内核来说几乎是完美的,对业务逻辑来说也是一个挑战.
对于内核而言,Java与C一样好的论点与C对应用程序的Java一样好.经验,减去一些边缘的例子,绝对证明了每种语言的好处.
根据定义,RTOS必须支持确定性调度和执行.通常,低中断延迟和直接硬件访问也是一个理想的因素.Java中使用的技术,如垃圾收集,JIT编译和字节码执行,使这些目标难以实现.
Java可以在实时系统中使用,但通常它在 RTOS 上运行而不是在其实现中使用.
总而言之,建议RTOS始终用C实现同样是不正确的.任何系统级语言都适用,包括汇编程序.在大多数情况下,至少内核的某些部分在任何情况下都是汇编程序.C++将是一种合适的语言(很明显,因为它本质上是一个C超集),许多商业RTOS在任何情况下都有C++包装器; 我习惯性地为RTOS开发C++抽象层以支持可移植性.
通常使用C的另一个原因是因为C(通常是C/C++)编译器通常是第一个且通常是新架构可用的唯一语言(汇编器除外)(现在经常以GNU编译器实现的形式) ).因此,如果您希望能够将RTOS移植到最广泛的平台,那么使用最普遍的语言是有意义的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 