嵌入式微系统msOS成型记（“实用单片机系统MS”升级版）

只看该作者 · 2014-6-9 12:21

本帖最后由 lldwsw 于 2014-6-17 10:52 编辑

一、何为嵌入式微系统
嵌入式微系统，顾名思义就是嵌入式微型操作系统，然而操作系统一词在嵌入式行业里往往专指uC/OS之类的带任务切换的系统，所以为了有别于这个专用名词，往往用开发平台一词来代替，所以嵌入式微系统更准确的名字为嵌入式微型开发平台。

大家肯定会问，uC/OS这样的嵌入式操作系统跟嵌入式微系统到底有什么区别，那么我们就要从项目需求开始说起。

某个公司需要在嵌入式芯片（MCU51或者STM32）上开发一个控制项目，涉及LCD界面、多种不同接口速度的外设、多种不同速度的业务逻辑控制，下图为常见的一种工业自动化项目需求。

作为项目负责人，首先要分析清晰项目需求，假设这个项目有点复杂，涉及多路采样及多路PWM输出，所以选择STM32之类的高性能处理器，之后再考虑软件设计。

这个项目设计到多路输入传感器及多路输出，有高速的业务逻辑控制，也有低速的菜单界面，为了把低速的菜单界面与高速的业务逻辑分开独立编程，所以引入嵌入式操作系统，比如uC/OS，会方便程序设计。

uC/OS除了任务切换功能等有限的功能外，没有别的，所以其它的东西还是需要我们自己添加,菜单界面就是一个。界面编程里面，简单的界面用状态机还比较容易编程，但若涉及到稍微复杂一点的界面，传统的状态机编程思想就完全不适合了，代码很难维护修改，为了提高可维护性，需要引入一个标准的菜单界面编程库（GUI），虽然现在网上也有不少，但适合自己的却很难找，往往需要自己编写一套菜单界面库，这个工作量很大，难度也很难，最后往往退回到传统状态机菜单编程方式。
其它的硬件相关的设备驱动库，都需要自己来完成，比如按键、串口、步进驱动等等。若这个项目需要多人协同开发、长期维护，则还需要制定架构标准，一些接口规范，命名标准，而这么多的要求，对于大部分的小、微型企业的嵌入式项目负责人来说，要求太高了。所以最后这个项目负责人，往往自己一个人埋头苦干，什么标准什么规范都没有，经过较长的一段时间开发加上后期的修修补补，项目勉强的交差了。然而当这个负责人离职的时候，面临着无人接手的窘境。
我们再看消费类电子产品的开发模式，以MTK6225功能手机为例，RTOS采用Nucleus，菜单界面软件库采用PlutoMMI，此外还需要多媒体、文件系统，电话本、短消息等中间件，之后是各种硬件设备驱动，整个软件架构类似ARM公司提倡的CMSIS架构。

MTK提供了整套硬件参考设计、PCB设计、生产流程、测试流程，软件开发标准。客户通过不长的时间培训即可掌握手机的开发设计，一般10来人的手机设计公司，在具有一定的手机设计经验的基础上，只需要2、3个月就可以设计出一款MTK提供的参考手机，之后公司基于这个参考手机做硬件上的机型改进及软件上的界面调整即可。到了Android时代更是简单了，因为Android软件属于通用软件，所以软件更是不需要培训了。

其他消费类电子，比如以前的VCD、DVD、MP3、MP4等等，都采用类似的方式，只有采用这种方式，源头厂家才可以快速的切入市场，并且可以同时管理、维护很多下游客户，比如MTK的下游山寨手机公司上千家，大的手机厂家也有近百家之多。因为采用了标准的设计模版，应用开发、客户维护人员都不是很多，尤其是维护人员，大大降低，获得高额的利润。而因为采用标准通用的软件架构平台，迅速的培养了大量的通用手机软件人员，而这些软件人员都可以在各个手机公司立即干活，不存在更换一个公司之后还需要培训的问题，这样下游厂家也不需要担心人才流动引起的工作交接问题。

从以上例子可以看到，通用标准化的开发设计，带来的好处是巨大的：提高了开发效率、缩短了开发周期、便于产品长期维护，容纳更多的下游客户。

只看该作者 · 2014-6-10 14:19

本帖最后由 lldwsw 于 2014-6-10 15:08 编辑

本文为连载性质，每周一篇，总计十二篇。
msOS到今天已经完善，也有大量的实际使用例子，比如PID算法库、步进驱动库及扩展大屏幕串口屏等，非常适合于工业场合，形成了一个控制体系。很多网友基于msOS应用于自己的项目中了。
msOS自创立以来，获得广大嵌入式爱好者的认同，msOS QQ群目前已经基本满员接近1000人，形成了嵌入式的生态链，我公司的嵌入式人员招聘都从msOS群中招聘，目前有三位新同事从群内来，最近的一位是在华为工作了五年的嵌入式人员，对msOS非常认可，加入了我公司，今后负责msOS方面的东西。
应网友要求，开启msOS的出书计划，本身msOS的文档就有接近200页，再增加实际应用例子，可以成书了，目前选择了电子工业出版社。这本书将以全新的视角看待嵌入式设计，尤其是从架构方面看待，特别适合于想在架构方面有所突破的中高级嵌入式人员，而这方面的书，目前几乎没有看到。
本人目前把公司都交给了同事经营，自己专心于做系统架构或者核心技术开发，为公司搭建研发体系和产品体系，目前正在做高频感应加热设备的FPGA设计，有一些进展，并且FPGA这一块的架构需求，得到我的大学同学，清华研究生，某知名芯片设计公司负责架构设计的高手亲自指点，并为我搭建架构，协助我开发msFPGA，争取下一个架构msFPGA也能获得较大的成功，若开发的好，也将采用开源方式推广。
这样子，把msOS、msFPGA整合起来，构建一套适合于工业的完整体系。

只看该作者 · 2014-6-11 14:49

支持更新，一直在学习MS

只看该作者 · 2014-6-11 21:15

你这个OS不会以后也收费吧

只看该作者 · 2014-6-13 16:29

不会收费

只看该作者 · 2014-6-13 21:44

可以学红帽的，服务收费，代码不收费

只看该作者 · 2014-6-16 08:40

嵌入式微系统msOS成型记之二：中低端嵌入式软件平台的困局

嵌入式领域有不少操作系统，大致可以三类：第一类以Wince、Linux、Android为代表的，属于大型操作系统，拥有内核任务调度、菜单界面、多媒体、网络、文件存储、外设驱动等一系列完善的功能，但这类操作系统属于非实时操作系统，往往用于办公、娱乐、人机接口等对时间要求不高的场合。此外因为功能太完善，对硬件的要求很高，最低配置CPU需要ARM9 200MHz，内存需要32MByte，支持MMU内存管理单元，标配彩屏。

第二类以VxWorks为例，属于功能丰富的嵌入式实时操作系统，功能丰富。往往用于高实时、高可靠的军工、航空航天、工业自动化领域，对硬件要求也比较高。

第三类以uC/OS-II，FreeRTOS为例，只有一个抢占式多任务实时操作系统的任务内核，此外还提供一些内核管理的函数接口及必要的扩展功能，其它的功能库如菜单界面、网络等都需要自己扩展，这类操作系统主要应用于中低端小型的项目中，成本要求高，需求多样，但一般不是很复杂，实时性有要求，但不苛刻，往往都是消费类或者一般的工业自动化设备，比如白色家电的控制系统、小型监控、传感器的测试平台、仪器仪表、小型工业自动化领域取代PLC，降低成本等等。

中低端小型项目，一般都是基于MCU51、ARM7或者现在的CortexM3、M0开发。简单的项目，软件最常用的是前后台系统，也叫裸奔，紧急响应用中断，低速处理在main大循环中执行。稍微复杂一点的在前后台系统的基础上引入了系统节拍，执行一些例行的事件，这个也叫时间片编程方式。再进一步是引入消息机制，实现消息机制编程方式。再复杂一些就引入uC/OS-II等RTOS，实现多任务编程，简化编程难度，但同时因为引入了RTOS，需要充分了解RTOS的特性，所以对编程人员的水平要求比较高。

苛刻的成本、需求的多样性，导致目前没有一套比较完善的操作系统统一这一方面的开发编程，哪怕是uC/OS-II等RTOS内核，也需要根据实际项目需求来配置、裁剪，增减不必要的软件功能。

此外，中低端小型项目，技术难度相对较低，所以嵌入式人员的入门门槛较低，这个本身是好事，然而也就是因为入门门槛太低，又没有一套统一的编程规范，导致编程的随意性很大，一个公司十个编程人员，有十套不同的编程方式，相互之间检查、维护非常困难，而小型企业的人才流动相对较大，软件负责人离开后，继任者因为编程的思维方式不同，往往看不懂前人的程序而废弃再重新设计，这样导致代码质量一直在低质量的重复循环，也极大的提高了公司的软件成本。

项目继承性这种情况在高校、研究所中尤为突出。比如一所研究所的主业是做传感器，但为了测试这款传感器必须要搭建一套嵌入式测试平台，若用WINCE、Linux等开发平台，需要一个嵌入式团队来开发，投入很高，维护很难，副业变成主业了，若是自己搭建一套完善的通用测试系统，既没有这个能力，也没有这个精力，所以一般都是针对性的设计这款传感器的测试系统。因为高校、研究所的学生经常更换，后来者看不懂前人的代码，又不得不重新设计。

中低端小型项目，需求虽然多样，虽然无法用一套操作系统去统一开发，但是我们可以把这些分为几类，比如彩屏的消费类、黑白屏的工控类、数码管显示的微控制类等等。这几年国内有一款比较出名的开源嵌入式操作系统叫RT-Thread，编程风格类似Linux，在OS的基础上集成了GUI、文件系统和网络功能，不少用户把它应用于消费类行业。而最新发展起来的一款开源嵌入式微系统叫msOS，采用微软的C#风格，侧重于平台架构，可以灵活组合，简单易用，目前整合了uC/OS-II，集成了128*64黑白屏的GUI、参数日志存储、PID算法库和步进驱动库，定位于仪器、仪表、小型工业自动化领域，msOS的中文名就叫嵌入式微系统。

只看该作者 · 2014-6-23 16:09

msOS的需求来源-嵌入式微系统连载之三

2001年我大学毕业后去了中科院半导体所工作，第一次真正接触了MCU51下的C语言开发，项目组要求项目中的功能尽可能封装成一个个的功能子函数，便于维护，所以一个项目就是由各个功能子函数组成的。但我因为在所里时间较短，没有真正参与其中，只是接触了这个概念，觉得这个非常好，也在自己心中暗暗的下了一个决心，今后要建立自己的函数库，以方便项目开发。

2002年我来到深圳做手机软件开发，采用英飞凌手机解决方案，有一套标准的软件架构平台，RTOS采用Nucleus，GUI等其它部分都是英飞凌自己完成的，当时国内山寨手机行业还没有开始，所以这套手机解决方案还不是很完整，功能比较少，但就是因为不完整，功能少，很多还需要我们自己开发，所以让我有了更深入的了解整个软件架构的机会。

我负责的是手机驱动部分，所以可以比较清晰的了解整个手机的软件架构，代码是如何组织的，加上原本就是做硬件的，所以相对较快的完成了工作，在手机公司呆了半年之后就有比较多的空余时间，想着把MCU51熟悉一下，把基础打好，便于开发一些小项目，于是采购了一套周立功公司推出的MCU51开发板：DP-51开发板。

按DP-51开发板提供的例子如GPIO、串口、按键等走了一遍，基本上熟悉了MCU51芯片的特性，对MCU51的编程就不再神秘，但是这种一个个例子，一个个功能子函数的方式，已经瞧不上了，毕竟之前是做手机方案的，于是就想着如何借用手机的平台架构思想，把这些功能函数都整合起来，形成一套基于MCU51下的软件开发平台。

手机驱动开发中，经常用到RTOS提供的系统节拍，5ms一次，用来处理一些例行程序，觉得很好，于是把这个功能引入到软件平台中，把MCU51的定时器2作为系统时钟来处理。手机软件中还有一个非常好的东西就是软件定时器，因为硬件定时器只有非常有限的几个，比如MCU51一般只有三个硬件定时器，一个用于系统时钟，一个用于串口通讯，只有一个了，若需要处理超时、动画、闹钟等，根本不够用，所以需要用软件扩展出很多个软件定时器，一般基于系统节拍来扩展，所以把这个软件定时器功能引入平台。虽然手机中有Nucleus这个RTOS，但是被封装了看不到，所以那个时候对RTOS的特性并不了解，实际手机开发中也感受不到它的存在。而RTOS中常见的消息机制也不是从手机平台中认识的，而是源自大学时期的VB编程，觉得事件触发这种方式非常好，点一个按键，点一下鼠标，产生一个事件，于是把VB中的事件处理方式，也就是消息机制引入平台中。

消息机制、系统节拍、软件定时器，再加标准的前后台，构成了一个基于MCU51下的软件开发平台：实用单片机系统(McuSystem,缩写为MS)。第一版2003年放到网上共享。从今天角度来看，这个简陋的不能再简陋的，命名规范一塌糊涂的软件平台，竟然被不少MCU51初学者所喜欢，经常发邮件询问一些问题。这个事情让我明白，自己的水平虽然不怎么样，但接触的东西相对高端，还有太多的不如我水平的人，他们很需要指点入门。于是在经历几个项目进一步完善软件功能之后，对MS1做了精简、优化，去掉了指针等相对难一些的东西，专门针对初学者，让他们非常容易看懂，这就是MS2。在MS2的基础上丰富了功能，引入了指针，针对中级用户的，变成MS3，应该说MS3的客户群体最多，深受网友喜欢。
2011年，我设计了一款6KW高频感应加热设备（简称高频机），高频机是一款典型的中低端嵌入式项目需求，实时性要求高，工作要求稳定可靠，128*64黑白LCD屏显示界面，高速中断响应，高低速例行节拍处理，业务需求处理，如下图：

硬件上考虑到MCU51速度已经不够用了，所以升级为Cortex M3。软件上因为存在高低速处理需求，一开始想着引入uC/OS-II实现多任务处理，但那个时候对于RTOS了解不多，又没有用过，细节点太多，一个处理不好，可能会引起高频机炸机，所以心里没有把握，最后在同事的建议下放弃而选择了自己擅长的MS3，只是把MS3移植Cortex-M3中，增加了一些菜单界面编程的功能及多级速度系统节拍功能。

项目开发过程中开始感觉到MS3架构的设计已经无法满足这类功能相对较多，菜单界面相对复杂的需求，尤其是用传统的状态机或者是函数指针来实现的菜单界面编程已经超出了这个框架的能力范围，修改或者扩展功能相当复杂，有时候连自己都会搞晕，编程相当痛苦。虽然如此，这个项目还是一步步的完成，产品也稳定批量生产了。

项目转变为产品之后，需要找一个人来接手，解放自己去开发新的东西，这个时候却发现接手人虽然反复看了多遍，自己也跟他讲解了多遍，但当客户有需求需要微调整菜单界面的时候，他往往无从下手或者经常犯错误，传承性非常差。

在高频机市场化获得成功之后，客户对我们的研发信心非常之高，要求围绕客户的机械自动化设备开发周边的电子设备以降低成本，主要有电源类设备如高频机、火花机，传感器类设备如红外温度传感器、激光测距仪、接近开关，驱动类设备如步进电机、伺服电机等，控制类设备如PLC。面对这么多种类的不同需求，需要很多人协同开发，若还是按MS3架构设计，则已经无法满足客户需求，那么新的软件架构平台，该如何设计？

只看该作者 · 2014-6-23 19:06

顶老大的帖子。

只看该作者 · 2014-7-1 11:42

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