嵌入式微系统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等中间件层引入了设备层,至此整个软件架构的框架基本建立完成,如下图: