返回 登录
0

使用RTOS还是bare-metal的5个决定性因素

在开发时,是在RTOS下运行固件还是开发bare-metal解决方案,决定了一个嵌入式系统的成败。不过决定向走哪条路并不容易。以下是开发者在作出决定时应该考虑的五个因素:

因素一:优先权

选择RTOS还是bare-metal调度程序的关键因素是,系统是否需要优先权。如果有有优先级的需要,那么应该选择RTOS。能挂起一个任务,并让优先执行另一个任务,是RTOS的主要优势之一。如果能合理安排任务的优先级关系,可以最大化地发挥系统的实时性能。开发者可能说,在bare-metal上可以通过中断的手法来控制优先行为。某些维度上,这是可行的,但这种中断操作应该是短平快的。如果试图中断一个正字啊优先运行的功能,很有可能会直接影响系统的性能。

因素二:存储

目前很多开发者本能上会在使用RTOS的同时选择小容量的RAM和flash。但是他们可能并不了解终端软件的内存需要。其结果就是屏幕跳出的“will not fit in region”问题。一些RTOS在默认情况下,会设置每个任务或线程堆栈为0x200,不过这意味的是堆栈深度而非大小。在一个32bit的机器上,每个任务默认情况下的大小可能相当于2kB RAM。当然,这样的容量也可以运行起来,不过仍然需要了解使用RTOS时最低的RAM要求。
RTOS的Flash要求也是值得留意的问题。典型的RTOS可以在最低6-8kB的Flash配置下使用。当考虑使用RTOS的时候,最小的配置要求是32kB flash和4kB RAM,而我个人更倾向于使用不小于8kB的RAM。

因素三:中间件

中间件是选择RTOS与否的一个重要决定性因素。一些RTOS具有像文件系统、USB或TCP/IP等易于与RTOS整合的中间件堆栈。如果想为bare-metal系统加入这类堆栈,不仅耗时,还会遇到很多问题。开发者应该考虑哪些中间件堆栈对于应用是必须的,以及使用哪种方案才是最优。

因素四:可移植性与复用

RTOS并不会保证具有可移植性或代码的复用,当然,bare-metal也一样。RTOS具备清晰地定义任务的能力,并支持复用。bare-metal也可以被编写为可移植和可复用,但是相对来说,需要更多精力,而且也并不常见。

因素五:经验

选择RTOS还是bare-metal方案可能也需要基于开发者的经验。缺乏RTOS的开发经验可能会导致一个痛苦且不断修复bug的恶性循环。RTOS易于搭建,但debug则相对耗时一些。我处理过的一些最糟心的bug通常都是在RTOS下遇见的。缺乏RTOS开发经验的团队,最好采用bare-metal方案,或通过一些小的项目积累RTOS开发经验。

你认为还有那些需要考虑到的因素呢?

作者:Jacob Beningo
原文:http://www.edn.com/electronics-blogs/embedded-basics/4441028/RTOS-or-bare-metal—five-decisive-factors

评论