前后台系统VS嵌入式OS，何时该上OS？

嵌入式系统软件设计包括两个方面的设计，一个是业务逻辑的设计，另一个是调度器设计。因为不同的应用有不同的业务逻辑，所以业务逻辑的设计模式因应用不同而有所不同，没有一个面面俱到的设计模式；如果业务逻辑设计比做电影剧本设计，那麽要让剧本播放出来，还需要播放器来播放，这里的调度器就是播放剧本的播放器。通常这个部分可以有统一的设计模式，  这个统一的设计模式就是大家众所周知的OS，然要用好操作系统这个调度器，首先你需要掌握OS任务的调度方法，这个门槛相对比较高。其次OS这个调度器往往设计比较庞大，势必会占用系统资源，这对于有些嵌入式系统CPU资源有限的情况下，采用 os作为调度很显然是不合适的。虽然当下一些流行的嵌入式rtos系统（uCos,rtmes等）都设计为可裁剪，但即便将它们裁剪后，能满足系统要求，然这种裁剪的学习负担对大多数人来说也是不小的，还有就是os的使用负担，因为使用os系统调度业务逻辑与使用前后台调度器（在未有os系统之前，我们称呼其为监控程序）调度业务的设计方法完前不同。

采用嵌入式OS设计需要掌握的东西

1.你需要学习os任务的使用方法

（1）任务的创建、删除、调度

（2）任务的状态的运转（休眠，阻塞，就绪，运行，中断）

（3）任务之间的同步及通信

2.有了第一步的知识，接下来需要进行任务设计，将剧本放到任务里调度

（1）需要考虑你的剧本需要放到多少个任务里去调度

（2）任务之间的优先级分配，那个任务优先调度

（3）因为你的剧本放映需要有一定的先后顺序，所以你还要设计这些任务之间的同步关系及通信机制

3.任务设计完了，剧本也可以放映了，效果如何，你需要分析，是不是剧本放映效果达到了系统的预期，你需要做任务可调度性分析，是不是真的满足系统性能要求

对于实时操作系统，常采用的分析方法为速率单调分析方法（RMA），如果达不到系统预期，你需要对第二步进一步优化。

较之于前后台系统，采用os作为调度系统学习门槛高，占用系统资源多，对于那些系统资源有限的，业务逻辑不是过度复杂的情况下，采用os系统作为调度器，可以说并非上上策。

采用前后台系统的设计方法

下面我们来看看前后台系统：

如上图，所谓前后台系统由2部分组成：无限循环+中断，我们把无限循环称之为后台程序，中断程序称之为前台程序。那麽对于这样的系统来说，调度器应该怎么设计呢，应按放到那里呢。调度器往往既放到前台也放到后台。

1.调度器的设计

（1）中断事件（如定时器中断，通信中断等），通过硬件触发的调度器，直接将对应的调度程序（剧本）放入其中

（2）基于条件的触发（软件触发）：触发条件不多，调度器可以设计为分支结构；触发条件比较多的话，比如按键触发条件，可以把按键处理程序的调度器设计成为基于表格的驱动方法；

（3）周期性的调度器的设计，采用前台（定时器中断）与后台(判断定时时间是否到，到了就调用周期性剧本)结合的方法

（4）系统对偶尔高并发条件一时忙不过来，为了不影响系统的关键任务，调度器应怎么设计呢？调度器可以设计成为基于队列的调度方式，对于那些不是很紧迫的任务（比如显示任务）可以采用排队的方式调度。

当通过以上方式设计的调度方法还不能满足系统要求时，就要改进系统的设计，包括剧本设计和调度器设计，如果还是不能达到要求，就要考虑提高系统的资源了（如更换CPU）。

2.调度器的放置位置

以上的调度器的设计是比较常用的设计方法，我们一般把调度器放到前台和后台。那麽有没有仅把调度器放到前台情况呢？有没有把调度器仅放到后台的情况呢？对于前者答案是肯定的，后台只做一件事情让单片机进入休眠，对于便携式设备，可以极好的控制系统功耗。将调度器仅放到前台，不必考虑前台与后台竞争资然的情况，一般来说原来在后台的调度处理程序都会放到定时器中断来处理，其调度器的设计方法与1中的调度器设计方法雷同。对于把调度器都放到前台处理必须注意一点，若定时中断处理程序一直占用CPU,导致其他中断得不到调用，那麽我们就不能把调度器都放到前台了。对于后者，除非我们的系统不需要用到中断，而这往往在实际应用中很少有过。

3.业务逻辑（剧本）的设计对调度器设计的影响

比如，对于通信处理程序来说往往放到前台执行，若通信处理部分比较耗时，可以将通信处理部分放到后台处理，前台仅作为数据接收和发送处理，若通信数据包发送过于集中，后台暂时来不及处理时，可以采用队列的方式保存通信数据包。这样一来通信处理的前台调度器负责存放通信数据，而对通信处理的部分，由后台调度器来处理。

什么时候该使用OS？

前面我们介绍了嵌入式基于OS的软件设计和基于前后台系统的软件设计，那麽在什么情况下需要使用OS呢？我发现有好多开发人员把OS用于项目的开发，都有一种心态，似乎他们的系统只有使用过OS才是高明的系统，才是有技术含量的系统，完全没有考虑过应用实际。我要说的是一个系统的设计的高明与否，不是看你有没有使用OS，而是你的设计是否简单，简单能让你开发时间更短，简单能让你的系统更好维护。简单来源于良好的数据结构设计，来源于良好的编码风格（自注释代码），来源于好的框架设计，比如上面说的os调度框架，你的前后台系统也完全可以设计出一个更加适合你的应用的调度框架。以数据为驱动的设计，往往能使你的系统更简单，易于扩展和维护。哎，罗嗦了一大堆，似乎跑题了，那么在什么情况下应上OS呢？

1.当有多个任务都很耗时，而这些任务可以并发调用，这时候为了提高任务之间的调度并发性，应该考虑使用OS，这一点是使用OS的很重要的原因，有的人说os能提高程序的实时性，在这个方面os的确可以提高这些任务的实时性，对于那些关键性任务，一次调用都不能遗漏的任务，对于这种实时，还是要靠中断来完成，而非os系统来完成，这个可能是大家的一个误区，所以说，前后台系统通过中断系统来保证关键任务的实时性丝毫不逊于使用os的系统。相反，os系统在任务调度的时候，会使用定时器中断，这个也会影响系统的实时性，虽然任务切换很短。而使用前后台系统，往往只能通过排队的方式实现。

2.当业务逻辑（剧本）过于复杂，而通过自设计的调度器来调度这些剧本的时候，使得设计不能简单，相较于os往往趋于复杂，不易维护，为了使系统设计更加简单可靠，可以考虑使用os

3.当系统资源充足，你的团队熟悉OS的设计方法，而你不想写自己的调度方法，觉得这样更加节省开发时间

4.对于便携式设备，使用前后台系统比使用os方法更易控制系统的功耗，因为 os系统方式，为了使任务调度及时，往往定时器中断调度更频繁，cpu的唤醒频率更频繁，从这一点来看，前后台系统功耗处理上要优于os方式。