嵌入式微系统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实现了多任务之后，新平台的架构有些浮现，接下来要做的是确定软件架构，而这个必须要从现代成熟的软件架构中寻找。在跟同事交流后，他们都提到了面向对象设计，但这个需要采用C++，而嵌入式中C++却不流行，我也不会，所以不可能选择C++。后来想到用常规的C语言写成类似C++的面向对象风格，但参考了网上的代码之后，觉得把C语言弄的更复杂了，很别扭，变成了四不像。之后又了解了JAVA，但感觉这个风格也不是很适合，直到有一位负责C#的同事侯德平，他建议采用C#，并且给我演示C#的好处的时候，让我眼睛一亮，这就是我想要的东西。

　　1、 优雅的编程风格，简单易用的长命名命名规范很容易被开发者接受，抛弃复杂的匈牙利命名法。

　　2、 System这个命名空间概念，可以很好的封装整个系统层，把应用层独立出来，这样可以提高代码的复用性和稳定性。

　　3、 C#是面向对象，但比C++简单很多，完全可以利用C语言中的结构体模拟命名空间和类，把C语言写成C#风格。

　　4、 微软的编程环境，特别适合工业行业，无论PC机还是WINCE嵌入式设备，C#都可以通用。这样嵌入式端用新平台开发之后，本身就是C#风格的，很容易掌握PC端的C#编程。

　　到了这儿，整个框架基本成型，但是系统层如何进一步细分呢?这时苏鹏建议参考ARM的CMSIS标准，如下图：

　　为了提高可移植性，在硬件驱动层与OS、GUI等中间件层引入了设备层，至此整个软件架构的框架基本建立完成，如下图：