为什么选择RTEMS
刘浩思
很久没写过关于RTEMS的文章了。很多朋友最近问我，为什么选择RTEMS，不选择VxWorks，你自己学习就算了，为什么也要拉着别人搞RTEMS。
这些问题略微的有一些复杂，我就专门写篇文章来作答。以前，我做商业项目都是使用FreeRTOS和uC/OS-II的， FreeRTOS和uC/OS-II都差不多，核心代码不过几千行。突出的特点是，好掌握，易上手，在较短的时间内就能上手开发。但是同时带来一个问题，由于驱动的缺乏，不仅仅是缺乏驱动，更缺的是，驱动的统一框架。所以设计驱动的时候，不仅仅是让相关的设备能工作，更多的是要设计一个驱动结构。对于商业项目来讲，交付完成后都是需要维护的。自己设计的驱动结构，风险和成本都比较高。需要很长的时间才能稳定下来。尤其是在需要实时性的场合。
uC/OS-II的API不丰富也是个棘手的大问题，我们的项目中，uC/OS-II，我们用C++封装了大量的系统函数，便于系统的使用。因为项目的软件架构是UML用面向对象的思想写得。利用 C语言可以实现面向对象的思想架构设计，但是要运用大量的技巧，需要用函数指针实现多态和继承。这个对编程人员来说，无端端需要了更高的技术水平。为了降低对开发人员的技术要求，使用C++做开发，与C相比，除运行效率略有些损失外，带来更多的好处。C++有严格的语法保证继承和多态，这个是C里面没有的。架构设计可直接转化为C++的框架代码，可节省不少的人力物力。然而，uC/OS-II是C函数编写的，做C++扩展，封装设计也需要不少的工作。这些都是uC/OS-II不具备的。
我们的系统颇为复杂，需要使用到TCP/IP，uC/OS-II有系统自带的uTCP/IP；选用了这个协议栈噩梦才刚刚开始。本以为这个协议栈很稳定，在使用期间，才发现协议栈有很多非常深层次的问题。1.首先有些层次支持IP分包，又有些层次不支持分包；2.TCP连接在使用一段时间后，随机出现没有FIN信号和SYN信号，导致和PC系统断链接；3.多台计算机(超过十台)同时ping协议栈，协议栈会挂掉，无法恢复；4.使用大包ping协议栈，也会出现奇奇怪怪的问题。5.也许是我们定制水平不够，系统连续跑到7天以上后，会造成硬件的MAC层会随机挂掉，我们用同样的linux代码测试，是没有这样的问题。驱动也是极力模仿linux，但是问题解决不掉，还是会出现这样的情况。
最后头疼的问题，是uC/OS-II的授权问题，人家是开源的，商业用是要收费的。说实话，用起来没有问题，付钱我倒没啥意见，关键是问题一堆，也没啥付钱的动力和想法。失望之余，我开始寻找新的替代操作系统，一句话，就是要成熟稳定可靠。VxWorks倒是不错的选择，但是授权费用太贵了，会把我们的利润榨干；没办法干这种事情，企业要生存的。于是找到了RTEMS，这个操作系统本身的性能超过了VxWorks，不过是2005年以前测得，现在还没有大牛比较过。
我第一接触到RTEMS之后，感觉到的是“强大”! 紧接着就是“麻烦”!说强大，发展时间长，代码质量高，系统相当之稳定。我们移植到uC/OS-II相同的硬件平台上，RTEMS自带的BSD协议栈表现的相当出色，随便Ping，随便telnet，运行了十几天，相当之稳定。丝毫没有颓势；API函数相当的丰富，也有一套成熟的驱动结构。(和Linux比起来还是有些简陋，但是足够用了)完善的C++封装。同时 RTEMS是开源免费，使用的发布协议是使用了RTEMS，你高兴公开你的代码你就公开，不高兴公开就不公开(严格的来说不是这样，但最终的效果是一样的)。
欣喜之余，问题来了，麻烦！由于使用GNU的工具链，对于使用windows下集成开发环境的团队来说，那是相当的麻烦。不仅仅因为需要装虚拟机在linux下开发，rtems的调试跟踪，代码撰写等等，都需要用单独的工具完成，对人员的素质要求很高。细节也非常的多，一不小心，埋下伏笔，呵呵，那就是给自己找麻烦了。再者，就是RTEMS的学习资料少得可怜，中国实际上潜在的研究人员非常多，但他们不愿意也没时间把自己的研究公布出来；国外的话只有官方的文档有些介绍。且介绍中的疏漏相当的多，需要潜心的研究。 毕竟全世界专职维护RTEMS的人就那么几个，需要用google summer code推动一些周边项目，并不像VxWorks那样面面俱到的商业项目，什么都是完美的。也正因为这些瑕疵，更显得RTEMS的可贵。
对于我来说，选择RTEMS，只是想应用于我的项目，我的产品。然而，从学习的角度来说，比那些集成化的工具来说，能学习到更多的东西，从深层次了解嵌入式系统的开发。IAR EWARM、RVDS这样的工具用熟了，不代表就可以把GNU玩转了，但把GNU玩转了，集成环境一定是没有问题的。所以，对广大的学生朋友来说，RTEMS是一个不错的，提升自己全方面能力的东西。不过，学习难度稍微有些大了，介绍资料又少，的确是有问题。
前阵子，看到一个笑话是，上世纪80年代只有资本主义才能救中国，上世纪90年代只有中国才能就亚洲，现在只有中国才能救世界。中国由中国制造变为中国创造，需要更多的软实力；中国如火如荼的物联网技术，通讯模块、操作系统、芯片都是国外的，中国搞的是物联网协议规范，试问，你都没有自己的东西，凭什么人家要尊重你的游戏规则？所谓的物联网，只不过是中国人的一厢情愿。说不好听的，掩耳盗铃而已。
国家的富强需要方方面面的成功，需要方方面面的积累。我们现在不看别人如何成功，把一款操作系统学好，应用好。应用到我们自己的系统中去，提升我们方方面面的品质。为国家的建设添砖加瓦，为自己的人生也添砖加瓦。
这些问题略微的有一些复杂，我就专门写篇文章来作答。以前，我做商业项目都是使用FreeRTOS和uC/OS-II的， FreeRTOS和uC/OS-II都差不多，核心代码不过几千行。突出的特点是，好掌握，易上手，在较短的时间内就能上手开发。但是同时带来一个问题，由于驱动的缺乏，不仅仅是缺乏驱动，更缺的是，驱动的统一框架。所以设计驱动的时候，不仅仅是让相关的设备能工作，更多的是要设计一个驱动结构。对于商业项目来讲，交付完成后都是需要维护的。自己设计的驱动结构，风险和成本都比较高。需要很长的时间才能稳定下来。尤其是在需要实时性的场合。
uC/OS-II的API不丰富也是个棘手的大问题，我们的项目中，uC/OS-II，我们用C++封装了大量的系统函数，便于系统的使用。因为项目的软件架构是UML用面向对象的思想写得。利用 C语言可以实现面向对象的思想架构设计，但是要运用大量的技巧，需要用函数指针实现多态和继承。这个对编程人员来说，无端端需要了更高的技术水平。为了降低对开发人员的技术要求，使用C++做开发，与C相比，除运行效率略有些损失外，带来更多的好处。C++有严格的语法保证继承和多态，这个是C里面没有的。架构设计可直接转化为C++的框架代码，可节省不少的人力物力。然而，uC/OS-II是C函数编写的，做C++扩展，封装设计也需要不少的工作。这些都是uC/OS-II不具备的。
我们的系统颇为复杂，需要使用到TCP/IP，uC/OS-II有系统自带的uTCP/IP；选用了这个协议栈噩梦才刚刚开始。本以为这个协议栈很稳定，在使用期间，才发现协议栈有很多非常深层次的问题。1.首先有些层次支持IP分包，又有些层次不支持分包；2.TCP连接在使用一段时间后，随机出现没有FIN信号和SYN信号，导致和PC系统断链接；3.多台计算机(超过十台)同时ping协议栈，协议栈会挂掉，无法恢复；4.使用大包ping协议栈，也会出现奇奇怪怪的问题。5.也许是我们定制水平不够，系统连续跑到7天以上后，会造成硬件的MAC层会随机挂掉，我们用同样的linux代码测试，是没有这样的问题。驱动也是极力模仿linux，但是问题解决不掉，还是会出现这样的情况。
最后头疼的问题，是uC/OS-II的授权问题，人家是开源的，商业用是要收费的。说实话，用起来没有问题，付钱我倒没啥意见，关键是问题一堆，也没啥付钱的动力和想法。失望之余，我开始寻找新的替代操作系统，一句话，就是要成熟稳定可靠。VxWorks倒是不错的选择，但是授权费用太贵了，会把我们的利润榨干；没办法干这种事情，企业要生存的。于是找到了RTEMS，这个操作系统本身的性能超过了VxWorks，不过是2005年以前测得，现在还没有大牛比较过。
我第一接触到RTEMS之后，感觉到的是“强大”! 紧接着就是“麻烦”!说强大，发展时间长，代码质量高，系统相当之稳定。我们移植到uC/OS-II相同的硬件平台上，RTEMS自带的BSD协议栈表现的相当出色，随便Ping，随便telnet，运行了十几天，相当之稳定。丝毫没有颓势；API函数相当的丰富，也有一套成熟的驱动结构。(和Linux比起来还是有些简陋，但是足够用了)完善的C++封装。同时 RTEMS是开源免费，使用的发布协议是使用了RTEMS，你高兴公开你的代码你就公开，不高兴公开就不公开(严格的来说不是这样，但最终的效果是一样的)。
欣喜之余，问题来了，麻烦！由于使用GNU的工具链，对于使用windows下集成开发环境的团队来说，那是相当的麻烦。不仅仅因为需要装虚拟机在linux下开发，rtems的调试跟踪，代码撰写等等，都需要用单独的工具完成，对人员的素质要求很高。细节也非常的多，一不小心，埋下伏笔，呵呵，那就是给自己找麻烦了。再者，就是RTEMS的学习资料少得可怜，中国实际上潜在的研究人员非常多，但他们不愿意也没时间把自己的研究公布出来；国外的话只有官方的文档有些介绍。且介绍中的疏漏相当的多，需要潜心的研究。 毕竟全世界专职维护RTEMS的人就那么几个，需要用google summer code推动一些周边项目，并不像VxWorks那样面面俱到的商业项目，什么都是完美的。也正因为这些瑕疵，更显得RTEMS的可贵。
对于我来说，选择RTEMS，只是想应用于我的项目，我的产品。然而，从学习的角度来说，比那些集成化的工具来说，能学习到更多的东西，从深层次了解嵌入式系统的开发。IAR EWARM、RVDS这样的工具用熟了，不代表就可以把GNU玩转了，但把GNU玩转了，集成环境一定是没有问题的。所以，对广大的学生朋友来说，RTEMS是一个不错的，提升自己全方面能力的东西。不过，学习难度稍微有些大了，介绍资料又少，的确是有问题。
前阵子，看到一个笑话是，上世纪80年代只有资本主义才能救中国，上世纪90年代只有中国才能就亚洲，现在只有中国才能救世界。中国由中国制造变为中国创造，需要更多的软实力；中国如火如荼的物联网技术，通讯模块、操作系统、芯片都是国外的，中国搞的是物联网协议规范，试问，你都没有自己的东西，凭什么人家要尊重你的游戏规则？所谓的物联网，只不过是中国人的一厢情愿。说不好听的，掩耳盗铃而已。
国家的富强需要方方面面的成功，需要方方面面的积累。我们现在不看别人如何成功，把一款操作系统学好，应用好。应用到我们自己的系统中去，提升我们方方面面的品质。为国家的建设添砖加瓦，为自己的人生也添砖加瓦。
类似资料：