接触 RTEMS 是 2008 年下半年的事情。当时在设计一些嵌入式系统的解决方案，寻找一个好的中间件，以满足系统多方面的要求。在查阅 ACE 时发现其支持 RTEMS 系统，不了解 rtems 是什么。于是，就用 google 搜索了 RTEMS 这个关键字，发现了新大陆。

最开始是从 www.rtems.net 上学习，发现资料陈旧且疏漏较多；于是就上官方网站 www.rtems.com 直接学习英文资料。官方的资料与最新的软件也有对不上的情况。但瑕不掩瑜，对一个开源的RTOS系统，能做到如此水平，实在是让人佩服。

当我深入 RTEMS 之后，除了感叹它的精巧设计外，也发现了一些问题。我把这些问题列出来，供大家讨论研究：

  • autoconf 的配置管理方式虽然方便，但进入门槛较高，远不如 ecos 那种图形化配置工具来得方便易用，进入门槛低；
  • 图形界面；RTEMS官方提供的方案是使用NanoX(micro window)；这个方案对于x86或者一些系统级的嵌入式来说，是挺全面的解决方案。RTEMS提供了一套界面的开发工具“RTEMSGraphicsToolkit ”，看起来，越来越接近PC机了。目标可能就是把QT移植过来。 然而对于一个小小的ARM7来说或者一个黑白屏幕来说，这样的方案是不是太大了点？很多时候，嵌入式系统需要的仅仅是一些简单的交互和信息的显示。需要一个高度可配置、伸缩的方案。目标也和RTOS的初衷是相辅相成的：想办法发挥出嵌入式系统的最大性能。个人觉得x11并不适合嵌入式多变的需求；这方面还需要同仁们努力啊。
  • 多处理器的支持；RTEMS毫无疑问是支持多处理器系统的，松散耦合，紧耦合两种。RTEMS 支持的方式采用的是 ASMP 的方式，即每一个处理器上都跑一个RTEMS，相互之间采用总线通讯。这种方式有很多优点，不需要考虑调度的问题，同步的问题也被转化成单机的同步问题。对单处理器的代码可以做最大的保全。然而，处理器之间的任务划分，不再是透明的。应用者必须考虑一个任务放在A CPU 上或是 B CPU上运行。对于芯片多处理器(CMP)，这种方式就有点不爽了，原本一个逻辑整体，因为ASMP的支持方式，却要每个CPU的可访问的内存划分开，中断划分开等等……任务也必须要安排到每一个CPU上。多处理器的支持需要改进改进，特别是x86、ARM、SPARC等CMP的运用，改进后会为开发者带来很大的便利。也比ASMP的方式利用资源的方式合理。
  • 设备驱动不丰富；只有少量的网卡，PCI、PCIe的设备支持，BSP虽然覆盖了主流的处理器类型，还是需要开发者做很多工作。当然，OAR的大牛们有更多的更重要的事情要去做，只希望开源界的朋友们站出来，为这方面多多加油努力。
  • 文件系统不丰富，缺乏一些优秀的文件系统的支持；jaffs、yaffs、ntfs、ext3等文件系统的支持还是比较重要的。嵌入式开发面临的存储设备也是多样化的，FAT格式不利于文件系统的长期稳定运行，nandflash这样的设备还是需要yaffs这样的文件系统。
  • 不支持IPv6；恩，这个是趋势，OAR的大牛们已经注意到这个问题了，相信不久的将来，这个会被支持的。
  • 缺乏一些总线的支持；这个是大问题，如CAN、USB、火线等，小一点的公司没有这样的技术力量去扩展，大一点的公司有力量去做但嫌维护成本高。RTEMS优良的性能会保证最终产品的性能。然而客户自己移植的协议，总线未能顾及到RTEMS系统的特点，甚至损害RTEMS的性能。难啊，这方面还希望官方多做做努力。
  • 使用gdb调试，使用起来多有不便。GDB虽然支持的芯片多，它只是个通用的调试器，用户可能还需要诸如调度次数、中断次数，以及开关中断的次数等信息。栈的用量、堆的用量等等，如果能在GDB的基础上再提供此类调试信息，必将进一步提高普通用户应用RTEMS产品的质量。

简单的聊聊，欢迎朋友们拍砖。