嵌入式应用软件任务划分的原则

嵌入式应用软件任务划分的原则

本文主要参考文章“嵌入式应用软件任务划分的原则”，其他见“参考文章部分”。

---

在基于实时操作系统(RTOS，RealTime Operating System)的单片机应用软件设计中，“任务”是一个很重要的概念。对于任务的划分，并没有一个人人都要遵守的规则，不同的人来设计一个同样规格要求的系统，会有不同的方案。本文将在研究划分任务的基础上，从实用的角度给出编写基于RTX51 Tiny实时操作系统的应用软件的指导方针。

任务的概念和应用软件开发过程

• 在嵌入式实时多任务系统开发中，用C语言代码表示的任务是一个无限的循环程序。任务不能有返回，不能有退出出口，但是任务可以被杀死，包括被别的任务杀死或自杀。任务的概念与操作系统中的进程概念相同，一个任务是独立的执行进程，可以与其他的并发任务竞争CPU时间。

• 基于RTOS的单片机应用软件开发过程：首先是根据系统设计方案明确应用软件的功能，然后结合RTOS的并发特性(或准并发特性)，对应用软件要实现的功能进行大小适当的划分，也就是把应用软件的功能按照一定的原则划分为若干个任务模块，并对各个任务间的通信和时延进行仔细的确认。

任务划分的原则

原则1：是将同一个外设的访问放在一个任务中。

对每个独立的硬件(例如串行通信端口)进行操作的驱动程序段放在一个任务中。也就是说，要想对某个设备资源进行操作，只有依靠执行相应的任务来实现。这样无论何时切换任务，都不会对任何独立的“外设”造成影响。

这样做能够避免嵌入式操作系统的特殊问题——资源冲突和重入问题，而且利于系统维护与升级。各个任务之间要实现通信，可以调用os_send_signal函数及全局变量来实现。

所谓“资源冲突”，就是任务A在访问某个资源时，恰好发生了任务切换——由任务A切换到任务B，任务B也访问这个资源且改变了它的状态，这样当再次执行任务A时，就可能发生冲突或带来不确定性。而所谓“重入”，是指假设任务A在运行某个函数，发生任务切换后，任务B也运行这个函数，这样就会破坏任务A执行这个函数时的现场，从而可能导致任务A执行函数时结果不正确。这种问题尤其容易出现在串行接口器件的操作中，例如串口，串行的A/D、D/A器件等。

原则2：是要通过任务分割提高系统的实时性。

在嵌入式多任务实时系统中，任务是指一个程序分段。这个程序分段被操作系统当作一个基本单元来调度。典型地，每个任务都是一个无限的循环。

RTOS本质上就是嵌入的实时内核，它负责管理各个任务，或者说是为每个任务分配CPU时间，并且负责任务之间的通信。实时内核可分为可剥夺型和不可剥夺型两类。因此，按照所使用内核的不同，嵌入式实时系统也可分为两类：使用不可剥夺型内核的嵌入式实时系统和使用可剥夺型内核的嵌入式实时系统。

2.1 长任务的定义

在RTOS中，长任务就是指整个任务的执行时间较长，超出了RTOS中其他某一个或某几个任务的实时要求容限，而对整个RTOS的实时性构成威胁的那些任务。需要注意的是，长任务与复杂任务不能混淆，复杂任务的执行时间不一定长，简单任务也可能会构成长任务。

2.2 长任务对RTOS的影响

当使用可剥夺型实时内核时，长任务由于执行的时间较长，因而更容易被高优先级的任务打断；一旦高优先级的任务进入了就绪状态，当前任务的CPU使用权就被剥夺了，或者说任务被挂起了，那个高优先级的任务立刻得到了CPU的控制权。这样会出现两个问题：一是长任务可能在一次执行的过程中被频繁打断，长时间得不到一次完整的执行；二是长任务被打断时，可能要保存大量的现场信息，其目的是为了保证在高优先级任务执行完返回后，长任务能得以继续执行。然而，这样做要占用一定的系统资源，同时保存现场本身也是要占用CPU时间的，因此，实时性也会下降。

当使用不可剥夺型实时内核时，长任务对RTOS的影响更为明显，因为在这种内核中，任务的响应时间取决于最长的任务执行时间。也就是说，由于长任务的存在，任务的响应时间要变长。其结果是CPU长时间停留在长任务中，其他任务得不到实时的响应，甚至根本得不到执行，系统的实时性势必要下降。

总之，无论是使用可剥夺型内核，还是使用不可剥夺型内核，长任务都会对RTOS构成严重的威胁。

2.3 长任务问题的解决方法

解决长任务问题最有效的途径是进行任务分割。所谓“任务分割”是指将影响系统实时性的长任务分割成若干个小任务。这样单个任务的执行时间变短，系统的任务响应时间变短，实时性得以提高。

（1） 对任务的分析与计算

当然，长任务的分割必须结合系统中所使用的内核，以及各任务对实时性的要求等情况，进行必要的分析与计算，才能保证分割的合理性和有效性，具体的步骤如下。

• ① 分析系统共有多少个任务，这些任务对实时性的要求有多高，求出各个任务所要求的最低执行频率(f1，f2，…，fn)。
• ② 计算目前各任务的实际执行时间(t1，t2，…，tn)。
• ③ 确定系统中的长任务。如果max(t1，t2，…，tn) ≤ min(1/f1，1/f2，…，1/fn)，则此系统中不存在长任务。如果max(t1，t2，…，tn)＞min(1/f1，1/f2，…，1/fn)，则存在长任务，而且执行时间为max(t1，t2，…，tn)的那个任务就是要找的长任务。
• ④ 分析此长任务是否需要分割，分析一下是什么原因导致执行的时间过长，这个时间是否能够通过程序的优化来缩短？如果能，则不需要进行任务分割；否则，要对这个长任务进行分割。

（2） 实施长任务分割

常用的任务分割的方法有以下两种：

• ① 将长任务按功能分为若干个小模块，每一个模块构成一个小任务，每个小任务实现一种相对独立的功能，且要保证执行时间t

• ② 有的长任务比较特殊，例如键盘任务和动态LED数码管显示任务，很难按照上面的方法把它分成若干个功能相对独立的小模块。这时，一般是按照方便保存现场信息的原则，将其强制分割成若干个小任务，每个小任务在min(1/f1，1/f2，…，1/fn) 时间内主动保存现场信息、放弃CPU的控制权，等到再次被内核调度时继续执行。这种分割方法相对而言较复杂，各任务之间界限不是很明显，看似未经分割，但实际上它却是由多次任务中断来完成的。

原则3：是要将软件工程中的“解耦原则”用于任务划分。

可以采用软件工程中的解耦原则对应用程序进行任务的划分。任务之间的耦合是影响软件复杂程度的一个重要因素，应该采取下述设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。具体方法可参见软件工程方面的书籍，例如文献[3]。

基于RTX51 Tiny的应用软件设计指导

RTX51是一个德国Keil Software公司开发的用于8051系列单片机的多任务实时操作系统。RTX51有2个不同的版本。

• （1） 完全版RTX51 Full
  完全版RTX51 Full允许4个优先级的任务时间片轮转调度和抢先式的任务切换，可以并行地利用中断功能。信号和信息可以通过邮箱系统在任务之间互相传递，可以从一个存储池中分配和释放内存，可以强迫一个任务等待中断、超时以及从另一个任务或中断发出的信号或信息。
• （2） 小型版RTX51 Tiny
  小型版RTX51 Tiny是RTX51的一个子集，它可以很容易地在没有任何外部存储器的单片8051系统上运行。RTX51 Tiny仅支持时间片轮转任务切换和使用信号进行任务切换，不支持抢先式的任务切换，可以并行地利用中断功能，可以强迫一个任务等待中断、超时以及从另一个任务或中断发出的信号，不能进行信息处理，也不支持存储器分配或释放。RTX51 Tiny是一种不可剥夺型实时操作系统内核。

基于RTX51 Tiny实时操作系统的单片机应用软件设计，首先应该根据RTX51 Tiny操作系统的准并发特性，对应用软件要实现的功能进行大小适当的划分——按照上述3个原则划分为若干个任务模块，并对各个任务间的通信和时延进行仔细的确认。

编写基于RTX51 Tiny的应用软件的指导方针如下：

• ① 包含头文件rtx51tny.h在应用程序中。
• ② 不要写C语言主函数main()。RTX51 Tiny操作系统内核中已经有它自己的主函数main()。
• ③ 应用程序应该至少包括1个任务函数(task function)。
• ④ RTX51 Tiny应用程序必须中断使能(EA=1)，因为RTX51 Tiny操作系统使用了定时器T0中断。
• ⑤ 应用程序至少调用1个RTX51 Tiny系统函数(如os_wait)；否则，链接器将不会把RTX51 Tiny的系统库包含到应用程序中。
• ⑥ 任务task0是应用程序中第一个执行的函数。在任务task 0中，必须调用os_create_task函数来运行其他任务。
• ⑦ 任务task函数不必退出或返回。任务task必须使用一个while(1)结构或其他类似的结构。任务task函数不带参数，也没有返回值。使用系统函数os_delete_task挂起(halt)一个运行的任务。
• ⑧ 中断服务程序的编写方式，与不使用RTX51 Tiny操作系统下的编写方式相同。
• ⑨ 编译和链接应用程序有2种途径，一种是使用集成开发环境μVision 2 IDE，另一种是使用命令行工具CommandLine Tools。一般采用德国Keil Software公司提供的集成开发环境 μVision 2 IDE。

其他的一些多任务划分方法与原则

任务划分要根据任务的特点和性质

任务的划分好坏直接关系到系统的设计的成败，往往好的任务划分，能够使设计更简单，任务多了，资源开销多，增加了任务之间的同步及频繁切换的开销，任务少了，可以减少共享资源的数量，降低了任务之间切换及同步的开销，不利于业务逻辑的并发调用。

• 1、设备依赖性原则：无论是通信、采集或是控制类任务都对设备具有不同程度的依赖性，同时因为外部设备的特点不同将导致任务的属性也发生变化，比如通信任务一般情况下外部设备的运行速率比主控芯片较低，所以在任务的执行周期，和任务的运行时间需要调整。“输入输出设备的速度差别是任务“并发运行的基础”“。所以通常将不同输入输出设备划分为不同的任务独立运行，也就是以CPU为中心，将和IO口相关的功能划分成若干个独立的任务。
• 2、关键任务：关键性（必须得到运行机会，即使遗漏执行一次也不行），一个系统中必有其关键功能，可以是一个也可以是多个，对于关键性任务划分的原则是使其功能独立，优先级较高，通过信号量或则消息与其他人物进行通信，简化关键任务的体积，尽可能的与其他任务剥离。一般将关键任务交给一个独立的高优先级任务或者ISR来执行，剩余的部分交给另外一个任务去实现，两者之间通过通讯机制来实现。
• 3、紧迫任务：紧迫性：是指一些具有较高的实时性要求的任务，必须在规定的时间内得到运行权，具有严格地执行周期。大多数紧迫任务都由异步事件触发，这些异步事件一般能够引发某种中断，所以将任务安排在ISR中较为合适。一般将紧迫功能分离出来，交给一个独立的任务或者ISR来执行，剩余的部分交给另外一个任务去实现，两者之间通过通讯机制来实现沟通。对于既“关键”又“紧迫”的任务，按紧迫任务去执行。
• 4、数据处理任务：通常一个系统必定会有大量的数据计算，这种数据计算通常会耗费大量的CPU时间，所以处理不当将会严重影响其他任务的实时性，比如如果一个任务具有较高的优先级，而且任务重含有大量的数据计算模块，将会长时间的占有CPU，严重影响其他任务的运行。通常将消耗较大的数据处理部分分离出来交给一个较低的优先级任务实现。
• 5、功能聚合任务：功能密切的任务封装为一个任务，达到功能聚合的效果，这样也会减少任务之间的同步过程，节省通信时间，功能密切一般分为数据关系密切和时序关系密切。
• 6、同等触发任务：触发条件相同的任务划分为一个任务，从而免除事件分发机制带来的额外系统开销。
• 7、将周期相同的功能组合在一起封装成一个任务，就可以避免一个时间事件触发几个任务，省去“事件分发”的操作与他们之间通信。
• 8、将若干按固定顺序执行的功能组合成为一个任务，从而免除同步接力通讯的麻烦。一般这些功能按固定顺序进行流水作业，相互之间完全没有并发性，则应该将这些功能组合为一个任务。这样一来也可以减少任务之间的同步过程。

任务优先级按照任务类型进行安排

1、中断关联性：与中断服务程序（ISR）相关的任务应该安排尽可能高的优先级，这样有利于处理异步时间提高系统的实时性，如果优先级设置的较低，则可能发生由于cpu一直被高优先级的任务霸占，导致在第二次发生中断时还没来的及处理上一次中断发生的事件！导致信号的丢失！
2、紧迫性：紧迫任务要求在规定的时间内完成，有很强的时间关联性，对时间要求较严，在安排紧迫任务的优先级的时候要按照紧迫程度将任务进行划分，越紧迫的任务优先级越高，一般来说，紧迫任务与ISR关联。
3、关键性：任务越关键，优先级越高，道理很简单，如果关键任务安排较低的优先级将不能获得更多的执行机会，导致关键人物得不到执行！关键性就荡然无存！
4、频繁性：越频繁的任务（周期越短）优先级应该设置的越高，以便及时得到执行。
5、快捷性：前面的条件相同相近时，越是快捷的任务优先级越高，这样避免后面的就绪任务延时短。
6、传递性：信息传递的上游任务优先级高于下游任务的优先级。如：信息采集任务的优先级要高于信息处理的优先级

举例说明优先级安排的：
在一个实际项目价值中，模拟信号采集任务，串口接收任务，串口发送任务，键盘监听任务，显示任务。下面分析一下：

模拟信号采集任务、串口发送任务、串口接收任务与ISR有关.
其中串口接收任务是关键任务也是紧迫任务，对实时性要求最高.
模拟信号采集任务是紧迫任务而不是关键任务，因为丢失一次信号的采集还不至于造成严重的后果。
串口任务cpu是主动方，优先级安排低点也可以，只要将数据发送出去就可以。
键盘监听任务和显示任务对实时性要求较低。
数据处理任务视计算量而定，如果计算量较小可以安排在键盘监听之前，因为它比较便捷。反之安排其后。

这样我们可以这样设定：

任务	优先级
串口接收任务	4
模拟信号采集任务	6
串口发送任务	8
数据处理任务	10
按键监听任务	12
显示任务	14

这样可以 #define OS_LOWEST_PRIO 18，优先级安排比较宽松的好处就是方便后续升级，添加任务不需要修改其他部分。

丢中断考量方法

假设所有指令都是单指令周期的，这样1个指令周期就对应一条指令，假设每条指令都是 2 个字节大小（16 位指令）。1ms 时间内 1MHz 的系统可以运行大约 2KB 的代码，一个 12MHz 的系统可以运行 24KB 的代码。在 1MHz 的系统中对于一个1KHz的毫秒中断，中断处理程序越接近 2KB，就说明系统越可能“丢中断“。

我们来看一个实例：评估一个 10KHz 的外中断，中断处理程序允许的理论最大安全尺寸是多少？
1、首先，我们要搞清楚系统的指令大小和指令集的周期数情况。以 ARM Cortex M3 为例，其指令大部分为单周期指令，支持 16 位指令和 32 位指令。为了评估中断处理程序的尺寸上线，可以分别以16 位指令和 32 位指令为基础计算出两个结果作为参考范围。
2、其次，我们要搞清楚系统频率。假设系统频率为 72MHz，已知 10KHz 等效于 100us，则中断处理
程序的理论最大尺寸范围是（72 * 100 * 2）字节到（72 * 100 * 4）字节，即 14.4KB 到 28.8K 之间。取最小值 14.4KB。
结论，中断处理程序及其调用的子函数，其尺寸总和至少要小于 14.4KB 才能确保 10KHz 的中断得到及时的响应。由于未考虑循环、分支以及其它任务的存在，以上结果仅用于粗略的快速评估，实际代码通常应该远小于这一上线值。当实际尺寸接近或者超过 14.4KB 时基本可以判定系统无法及时稳定的响应中断。

参考文章：

1、基于嵌入式操作系统的实时性多任务划分方法
2、基于嵌入式OS的任务设计-----任务划分
3、嵌入式系统任务优先级安排原则
4、玩转嵌入式多任务程序设计笔记三
5、嵌入式应用软件任务划分的原则