今天在阅读《 Linux用户日记》时,我偶然发现了有关NuttX RTOS 的一些内容。我检查了他们的网站,并对其功能集和将其放入8052的能力印象深刻。我发现有趣的是它支持POSIX,这是我为我的一个客户内部RTOS所做的工作。这个功能似乎比内部RTOS多一些。
是否有其他人听说过NuttX并尝试过?如果是这样,它与FreeRTOS等其他RTOS相比如何?
今天在阅读《 Linux用户日记》时,我偶然发现了有关NuttX RTOS 的一些内容。我检查了他们的网站,并对其功能集和将其放入8052的能力印象深刻。我发现有趣的是它支持POSIX,这是我为我的一个客户内部RTOS所做的工作。这个功能似乎比内部RTOS多一些。
是否有其他人听说过NuttX并尝试过?如果是这样,它与FreeRTOS等其他RTOS相比如何?
Answers:
这里已经讨论了与此问题相关的链接:
摘录:此处引用的Linux Journal文章位于:链接
我认为8052和M68HC12端口是表征NuttX的特别糟糕的选择,因为它们都存在一些问题,并且NuttX现在是具有63个发行版的5.16版本。
我没有填写在“发布”选项卡在这里采访:链接 ; 那里也有评论:link。
大量的NuttX文档可在此处找到:link。
hcs12和8051部件的问题如下:
8051 / 80c52:此体系结构确实对RTOS有害。它在专用存储器位置(地址0)具有很小的硬件堆栈(8051上为128字节,80c52上为256字节)。要切换任务,您必须将要阻止的任务的整个堆栈从其专用地址复制到某个保存位置,然后将要启动的任务的整个堆栈从其保存位置复制到专用堆栈位置。耶!
而且,由于堆栈太小了。溢出堆栈非常非常容易-尤其是在中断处理期间。
NuttX 8051端口是完整且可正常运行的(至少是我上次使用该端口)。但是为了使其有用,您可能还必须在每个中断上复制整个堆栈,以防止其溢出。基本上,我在那一点上失去了兴趣,但是如果有人真的有动力使用8051,那么它是可行的(如果不建议的话)。
8051端口的优点在于,这是将NuttX放入非常小的内存位置的绝佳练习。8051端口在32Kb的RAM中运行-包括RTOS,libc,编译器库,大量的测试程序,.data / .bss和heap。并保留一点记忆!
hcs12:这是我在业余时间不做任何事情的项目。只是还没有完成,还没有准备好黄金时间。
关于与其他RTOS的比较,我真的没有任何好的权威性答案,因为我没有使用其他RTOS。但是,这是我天真的理解:
FreeRTOS的下载量非常大,而且占用的空间很小,约为4Kb。它是非常小的MCU的首选RTOS。芯片供应商将FreeRTOS端口与几乎每个MCU捆绑在一起。因此,这是默认的RTOS选择。
FreeRTOS有几十个竞争对手。ChiBIOS立即浮现在脑海。这些都是各种类型的微型调度程序。
为了进行真正的比较,我们首先需要做的就是定义RTOS的含义:这仅仅是一个调度程序吗?还是它是一组集成的标准OS功能-诸如调度程序,文件系统,设备驱动程序,内存管理,网络等。大多数操作系统(例如Linux)都是完整的开发环境,而不仅仅是调度程序。NuttX是一个完整的操作系统,与Linux具有相同的含义。以下是其他几个:
RTEMS:我已经处理过这个了。它已经存在了很长时间,应该非常稳定。它很大;认为> 100kb。我认为它的目标略高于MCU市场。
uCOS:从来没有使用过,但这是几个流行的引导程序下的RTOS,不是吗?我的印象是它与RTEMS类似,但是我真的不知道我在说什么。
我如何将NuttX与之比较:嗯,它要小得多。起始占用空间约为20Kb。一个全功能的配置大约需要10-20Kb。与这些RTOS的另一个区别是NuttX是非常标准的。您可以将NuttX视为类似于Linux的微型产品。在Linux上编译和运行的大多数代码也将在NuttX上运行(某些系统代码,例如网络代码或守护程序可能需要进行一些调整)。
我认为RTEMS更加专注于微处理器。NuttX更专注于微控制器。
选择开源RTOS时,要记住许可方面的另一个差异。特别是如果您打算在商业项目中使用RTOS。大多数开源RTOS都有修改的GPL许可证。许可证修改通常指定您不必具有与GPL RTOS链接的专有代码(但您仍必须通过修改来释放RTOS文件)。
NuttX(可能还有其他)具有非限制性的修改后的BSD许可证。使用BSD许可证,您基本上可以将代码当作自己的代码来使用和使用,而无需承担任何责任,只需要在文件中保留许可和版权信息即可。