揭毅

（德赛工业研究院，惠州 516000）

引 言

在MCU系统程序设计中，常常遇到测试工程师反映我们的按键反应不灵敏，或是系统对外部的信号响应慢，实时性差。如果不是程序模块设计问题，那我们就要考虑系统程序设计上的实时性问题了。但是如果仅仅在系统程序设计上片面地考虑实时性问题，而忽略了任务均衡性问题，那么系统又可能出现有的模块程序响应快、有的模块程序反应慢的问题。为了解决这些问题，下面就我在车载娱乐系统程序设计工作中的经验与大家聊聊。

1 什么是实时性

实时性很容易被多数人误认为就是“快”的意思。其实，“快”只是实时性的一个特征，而且是相对的——是相对于任务需求而言的。

无论你的个人电脑是采用了何种“奔X”CPU，也无论该CPU的主频是几个G，只要你安装的是XP操作系统，那么它就是一个非实时系统。相反，一个8位的MCU，哪怕主频只有4MHz，也可以构成一个实时系统。

实时或是非实时，与CPU的速度并无直接关系，而完全取决于操作系统或程序架构。众所周知，操作系统（OS）主要包括三大组成部分：进程调度、内存管理和文件系统。其中，进程调度决定了系统的实时性。

实时系统的本质特征在于：所有任务的响应时间和执行时间都是可以根据各任务的需求进行设计，并且事先就能被预知。在一个实时系统上，我们可以根据需求分析的结果，对各个任务进行合理的、满足要求的“实时性”设计，使得最终完成的程序能够按照预定规则运行，并达到各种实时性指标的要求。基于这种定位，我认为在程序设计时，不频繁使用“计算器”的工程师通常不会有“实时性”的概念，这种工程师设计出的系统也很难讲是实时系统，至少，实时性指标是不能足以保证的。至此，大家应该可以理解我为何经常会问一些同事：你有无购买计算器？微软的工程师编程时无需使用计算器——因为他们设计的是非实时系统，但我们却需要——因为我们设计的是实时系统。区别就在于此！

在单片机系统中，很多情况下是不使用OS的。实际上，在没有OS的多任务系统中，进程调度的工作是由应用软件工程师自身编制程序来实现的。那么，自身编制的进程调度系统是否一定就是实时系统呢？我的回答是：不一定！关键在于你如何设计进程调度程序和如何合理安排各种任务。

如果你设计出的系统是非实时的，而实际各个任务的需求又是实时的，那么，系统就一定会存在问题。特别是在“任务并发”时，程序一定会出问题，甚至出现一些稀奇古怪的现象。

2 什么是任务均衡

我经常听到软件部的兄弟抱怨：MCU的速度不够快；内存冲突；需要提高主频等等。

实际上，大家可以测试一下我们目前系统程序中MCU的平均运行效率。我可以肯定地说，在我们目前的系统中，MCU的平均运行效率绝没有超过60%，很可能为20%～30%，甚至在10%左右。由于MCU的主振荡器一直在工作，它的ALU一刻也不会停止运行，那么，它在干什么呢？实际上，MCU在反复执行着一个没有任何实际任务的“死循环”，等待中断和时隙的到来——在绝大部分时间，MCU被闲置。

工程师所抱怨的速度不够，通常是指在任务并发时，发生消息丢失、内存／堆栈溢出或任务执行被延迟等现象。

通常，单片机系统是一个多任务系统。这里的多任务总是表现为“多功能”，而非“高性能”。否则，我们就不会选择采用MCU，尤其是8位MCU——因为8位MCU的性能总是不会太高的。基于MCU的这种低性能，通常不会将其用于大流量信号的处理，而是只作控制用。控制类信号的处理不同于大流量信号的处理，它仅需占用极少的ALU资源。

对于上面讲到的这种“忙的时候忙不过来，闲的时候闲得要命”的情况，就引出了“任务均衡”的问题。任务均衡性设计，是任何实时嵌入式系统设计的关键工作之一。

在与软件工程师讨论一些程序设计细节时，发现我们的工程师们总是追求“快”。其实，如果每个任务的处理都要“快”，而且是无量纲的“快”，那么任务均衡性问题也就无从谈起了。进行任务均衡性设计的实质是：让真正需要快速处理的任务快起来，让无需快速处理的任务慢下来，最终达到任务均衡的目的，从而提高MCU的使用效率。这里的“慢”就是为了“快”，没有“慢”也就没有“快”。

无论是处理“快”的任务，还是处理“慢”的任务，都需要满足系统性能的要求，否则所实现的系统就是一个不合格的系统，或是一个不健康的系统。因此，在需求分析和程序架构设计阶段，对各个任务的时间指标作出恰当的分析和合理的定义就显得非常重要。下面我举几个例子来说明。

（1）键扫描

根据人的反应速度和操作特点，对于仪表类设备，按键的捕获时间在30～50ms左右已经足够。如果一味地追求“快”，不仅浪费系统资源，而且还会对键抖性能要求过高。一般，我们会设计一个20ms的键扫描周期，用两次键扫值进行按键消抖，那么键捕获时间不会超过40 ms——你会发现此时的按键操作已经很灵敏了。在任务比较繁重的系统中，我们还可以将键捕获和键响应的处理节拍区分开来。通常，键响应时间只要能保持在100～200ms以内，已经不会使人感受到慢，有时这种延迟反而会给人更舒适的感受。

但是，对于旋转编码器这类器件，虽然我们可以将其归并为“键输入”范畴，但是它的脉冲宽度是比较窄的（可能会到几百个μs），建议采用中断的方式加以捕捉。但是，必须充分注意的是，检测速度快，并不意味着接收脉冲的速度也需要快；否则，在测试者高速旋转编码器时，会产生频繁中断，很可能会影响到其他任务的实时性。实际上，我们接收的旋转脉冲是用于数值增减和显示Level的，每100ms跳动一格已经是“目不暇接”了。因此，每中断一次时，最好能将该中断关闭，然后再在100ms时隙中将该中断打开。

（2）通信接收

我们都清楚，通信接收的响应速度都是要求很高的，通常都是用中断来进行接收处理。但是，一个完整报文（帧）的解析就不需要处理得很快了，完全可以安排在一个相对空闲的时隙中进行处理，而无需在中断服务程序中加以处理。中断服务程序执行时间的加长，将带来整个系统性能的下降。

3 常用汽车控制线

ACC——对“下升沿”的响应，要尽量地快（500μs以内），最好使用优先级最高的中断。因为，它需要应用于快速Mute，否则易产生点火POP－NOISE。但是，对“上降沿”的响应，就无需那么快，500ms就已满足要求。

Parking——只要求检测高低电平，而无需检测边沿，100ms的扫描周期已经足够。

Illuminance——只要求检测高低电平，而无需检测边沿。由于部分车辆采用了PWM调光，PWM的频率也没有统一标准，建议硬件上采用检波电路，以减小对MCU资源的占用。在采用硬件检波电路以后，软件的检测扫描周期为100ms就已足够。

Tele－Mute——只要求检测高低电平，而无需检测边沿。100ms的扫描检测周期已经足够。

Reverse——同Tele－Mute。

4 实时性和任务均衡性设计方法

下面介绍一种在无OS环境下，实现实时性和任务均衡性的设计方法。

首先介绍一下“时隙”的概念，时隙的英文叫法是“Time slot”，也就是“时间间隙”的意思。我们通常会选择一个基本时隙去扫描并执行任务，有些任务每个基本时隙都去扫描，有些任务则无需每个基本时隙都去扫描，而是若干个基本时隙再去扫描一次。用时隙去同步任务的执行，用时隙的长短来区分任务的轻重缓急。

基本时隙用定时器中断来产生，其他时隙用基本时隙的整数倍来产生，并尽量在中断服务程序中实现。时隙定时器是最重要的系统定时器，不仅要保持它的准确性，还需尽量简洁，使其保持最高效运行。

基本时隙的设计最为重要，它与其他各时隙的设计都须根据实际系统的要求来进行。基本时隙的长度决定了任务的最快扫描周期，从实时性要求来讲，很显然是越短越好。但是，基本时隙的过短将会对整个软件系统的架构和性能产生重大不利影响，限制系统整体性能的发挥。

基本时隙的选择原则是，在满足实时性要求的前提下，尽量长一些。对于个别需要更快响应速度的激励，采用中断的方式来响应。

这里已经引发了程序架构设计中的一个矛盾，即：基本时隙尽量长，尽量少开中断，中断服务程序尽量短。其实，这完全符合技术的特点，需要全方位地综合考虑。选择不是唯一性的，但是，对一个具体的系统，最佳方案可能只有一个。

结 语

以上是笔者对实时性和任务均衡性程序设计上的一些看法。基于以上方法来编写MCU程序可以大大提高程序的运行效率和系统实时性，改善任务的均衡性，并减少程序异常运行等问题的发生。