《国产嵌入式微系统msOS成型记》之四 嵌入式微系统msOS的诞生

为了解决多人协作，多种需求产品的开发，并且还要长期维护，必须要把这些产品的共性提取出来。

1、 不需要低功耗设计。

2、 传感器类和驱动器类属于单一功能的设备，传统前后台架构的MS3即可。

3、 电源类及控制类设备都属于功能复杂的，实时性要求高，带有屏幕显示，外扩多路传感器或者驱动器的设备，这两类可以统一为一类，是设计的重点，需要建立全新的平台。

那么这个新平台应该做成什么样子，脑子里还是没有概念的，只是知道在高频机设计中，传统的状态机或者函数指针方式的菜单界面编程方式是要改进了。我虽然在手机公司做过近两年的手机驱动开发，但此后一直做硬件方面的工作，后来创业经营公司，所以嵌入式软件水平一直停留在MS3这个层次没有提高，对于这个新平台的设计，首先需要向软件专家请教，尤其是过去这么多年，软件开发也有极大的变化。

幸好我公司的底子是做手机的，主流是MTK手机方案，此外基于Wince做了一款工业手持机，所以有各类专业软件人员，对C、JAVA、C#都非常熟悉。在众多软件人员中，特别要感谢的是苏鹏，他擅长Linux，之后是负责MTK手机开发平台的维护，也需要开发JAVA应用，关键那个时候他也恰好参与了基于MS3的红外温度传感器的开发，所以对嵌入式有一定的概念，对大型软件编程又很擅长，所以当我提出我的需求的时候，他很清楚我想要干什么。

苏鹏认为MS3是一个很好的东西，简单、易用，不能轻易抛弃，所以第一步在MS3上重构，引入当前主流的面向对象菜单界面编程思想，这个重构花了将近一个月，因为MS3是前后台的，只有一个大循环，基于消息机制，很多事件都是在大循环中处理，菜单界面放在大循环中解析的时候，因为菜单界面显示属于是低速事件，会严重影响高速的事件，让MS3中的消息机制失效，所以无法完美的实现面向对象菜单界面编程，只是形式上的实现了一些功能，没有实际使用这个代码，但这也为后来的真正实现面向对象菜单界面编程打下了基础，并且也认识到MS3这种只有一个大循环的架构无法实现真正的面向对象菜单界面编程，必须要引入抢占式多任务操作系统，把菜单界面放在最低优先级的任务中，其他的消息事件处理(消息事件处理，也叫业务逻辑处理，后续用业务逻辑表述)放在一个高的优先级中，这样最少需要两个任务，所以接下来的事情就是选择RTOS，并且深入理解它。

首先考虑的是uC/OS-II，因为它的资料最多，用户群体广泛，并且之前也接触过一点，虽然没有深入，但感情上首选它。此外有同事推荐了FreeRTOS和国内的RT-Thread，FreeRTOS跟uC/OS-II类似，但知名度太低，资料及客户群体都很少，虽然它是免费的，还是放弃了。RT-Thread编程风格是Linux的，我不喜欢Linux风格，感觉不好看，不够优雅，其次知名度也远不如uC/OS-II，并且可靠性、稳定性如何也值得怀疑，它带的GUI适合彩屏，相对复杂，也不适合黑白屏的工业场合使用，所以也放弃了。

选定uC/OS-II后，必须要深入理解它的每一个细节，首先碰到的就是uC/OS-II有太多的宏定义，因为要可裁剪、可配置，但实际上有大量的功能是用不到的，所以我就从精简入手，把在新平台中可能用到的函数保留下来，其它的一律去掉，这样就没有了烦人的宏定义，有很多网友也抱怨这些宏定义，严重的干扰了uC/OS-II的代码阅读。

通过精简uC/OS-II，深刻掌握了它的原理，并且这个时候新平台的需求也越来越清晰，绝大部分的需求只要两个任务即可，一个为菜单界面任务，一个为业务逻辑任务，根本不需要64个任务，所以对uC/OS-II大做修改重构，去掉了空闲任务和统计任务，把菜单界面解析安排在最低优先级上，业务逻辑放在高优先级上，这样只需要两个任务即可。

为了考虑今后任务的扩展性，还是保留了任务表，只是精简为支持8个任务。为了降低OS的内存占用，进一步精简OS内核，把原来基于链表结构的任务块改成数组结构。这样一个非常简单的uC/OS-II就出炉了，仅仅两个文件即可。

精简、重构后的内核只是保留了uC/OS-II的任务切换功能而已，而所有的RTOS都有这个功能，并且都是类似的，所以已经脱离了uC/OS-II，只是这个内核开始源自uC/OS-II，风格一样，所以还保留其名，但本质上已经不属于uC/OS-II了，所以也不存在版权问题，若想进一步避开，也可以参考其它的RTOS精简或者直接用其它的RTOS。若只需要用两个任务，新平台还提供了一种软中断的方式实现双任务，完全不需要RTOS。

引入RTOS实现了多任务之后，新平台的架构有些浮现，接下来要做的是确定软件架构，而这个必须要从现代成熟的软件架构中寻找。在跟