如何安装实时 *** 作系统RTOS

要想最大限度地发挥Zynq All Programmable SoC的优势，您需要一款 *** 作系统。本文将介绍如何安装实时 *** 作系统——这里特指μC/OS-III。

要想从最大限度地发挥赛灵思Zynq®-7000 All Programmable SoC处理系统的地优势，采用 *** 作系统肯定比使用简单的物理硬件解决方案更加有效。Zynq SoC设计的开发人员有很多种 *** 作系统可供选择，可以根据最终应用选择实时 *** 作系统。如果您正在多个应用领域需要快速响应和可靠性能来避免损失或实现严格性能目标的极具挑战性的环境中使用Zynq SoC，那么 RTOS无疑是您的最佳选择。

我们将利用最流行的实时 *** 作系统之一，Micrium的μC/OS-III来演示如何以最佳方式将RTOS添加到Zynq SoC系统中。RTOS或其早期版本已被用于包括好奇号火星探测器在内的多种激动人心的系统中。RTOS的最新版本目前正在进行MISRA-C、DO178B A级、SIL3/4和IEC61508标准的认证，这意味着它将吸引广泛Zynq SoC用户的目光。但是在介绍具体实现方法之前，我们先回顾一下实时 *** 作系统的基本知识，这对此很有帮助。

什么是实时 *** 作系统？
实时 *** 作系统与标准 *** 作系统有什么区别？实时 *** 作系统是确定的，意思是指系统需要在明确的截止时间内做出响应。这种确定性很重要，其原因有多种，例如，如果最终应用正在监控工业流程，那么必须在特定时段内对事件做出响应，工业控制系统就属于这类情况。

可根据满足截止时间的能力对RTOS进一步分类为三种不同类型的RTOS，每种类型都以不同方式满足截止时间。在hard RTOS中，错过截止时间被视为系统错误。而对于firm RTOS就不是这样，偶尔错过截止时间是可以接受的。在soft RTOS中，错过一次截止时间会减少结果的有效性，但系统在整体上对此是可以接受的。

实时 *** 作系统以运行任务（有时称为进程）为核心，每项任务执行规定的功能。例如，某个任务可能通过接口读取数据，或对数据执行某种 *** 作。简单的系统可能只运行一项任务，但更多情况下处理器上会同时运行多项任务。这些任务间的转换被称为“上下文切换”，它要求将与每项任务关联的处理器状态存储并添加到任务栈中。

采用分时法，每个任务都会获得处理器上的一个专用时间档，而更高优先级的任务还可分配多个时间档。

下一步运行哪项任务将由内核来控制。该内核是RTOS的核心，用来管理软件的输入与输出请求，并将它们转换为处理器中央处理单元和功能元件能识别的数据处理指令。任务调度可能比较复杂，尤其是当需要避免死锁（指两个或更多任务相互锁定）时更是如此。两种基本调度方法分别是分时法和事件驱动法。采用分时法，每项任务都会获得处理器上的一个专用时间档，而更高优先级的任务还可分配多个时间档。时间分段通过定期中断或定时器进行控制，这种方法通常被称为 “轮询调度”。而采用事件驱动方案，只有当具有更高优先级的任务需要运行时才会进行任务切换。这种方法通常称为“抢先式调度”。

死锁、资源共享和互斥等待
当两个或两个以上进程（例如UART、ADC或DAC）需要使用相同资源时，它们可以同时对该资源提出请求。这种情况下，应对访问进行控制以防出现争用现象。如何对此进行管理非常重要，若不采用正确的管理方法，就会出现“死锁”或“互斥等待”这样的问题，从而导致系统错误。

当某个进程占用一种资源且无法将其释放时，就会出现死锁，因为在这种情况下无法完成该项任务。该进程需要使用当前被另一进程占用的另一种资源。由于系统无限期地处于这种状态，因此可以说应用程序已被锁死。可以想象，死锁对于实时 *** 作系统来说是非常不好的。

当某个进程因为所需要的资源总是被分配给其它进程而无法运行时，就会发生互斥等待。

多年来，已经有很多关于这类主题的文章和资料，也推荐了很多解决方案，对此您可能并不会感到意外，例如Dekker算法，这是一种用于并行程序中互斥问题的经典解决方法。处理这类情况的最常用方法是信号量法，通常分为二进制信号量和计数信号量这两种类型。

通常，为每种资源会分配一个二进制信号量。请求进程会在任务执行之前等待资源变为可用资源。一旦任务完成，请求进程就会释放该资源。这些信号量通常被称为等待(WAIT)和发信号(SIGNAL) *** 作。进程首先等待信号量。如果资源闲置，进程将被赋予该资源的控制权，并运行直到完成，此时进程会发出完成信号。但是，如果进程在等待信号量时资源已被占用，那么进程将会被暂停直到该资源被释放为止。当前正在执行的进程一旦完成，暂停状态就会立刻终止，但如果具备更高优先级的进程抢先占用该资源，那么就需要等待更长的时间。通常使用名为互斥锁(mutexes)的特殊二进制信号量来防止优先级反转的发生（mutexes一词源于“mutual exclusion”）。

计数信号量的工作方式与二进制信号量相同，但是只有当特定资源类型有一个以上的实例时才会使用计数信号量（例如数据存储）。由于每个资源都被分配到一个进程中，因此计数数值会减少以显示剩余的可用资源数量。当数值减至为零时可用资源就没有了，同时提出请求的进程就会被暂停，直到有一种资源被释放为止。

不同进程之间经常进行通信是很有必要的。有以下几种方法可供使用，其中最简单的方法是按如上所诉的方式使用数据存储和信号量。更为复杂的技术包括消息队列。采用消息队列，当一个进程需要向另一个进程发送信息时，它会向队列POST一条消息。当一个进程需要从队列中接收消息时，它会PEND队列。因此，消息队列的工作原理就像FIFO（先入先出）存储器一样。

μC/OS-III *** 作系统
Micrium的μC/OS-III是一种优先式RTOS，意思是指它总是运行已做好执行准备并具有最高优先级的任务。要想将该 *** 作系统添加到您的Zynq SoC系统设计中，第一步需要从Micrium网站下载μC/OS-III RTOS。下载后，安装工作非常简单。您只需要将一些ZIP文件解压到电脑上赛灵思安装程序中的正确文件夹（路径）。

应确保将名为Zynq-7000-ucosiii-bsp.zip的ZIP文件解压到\ \ISE_DS\EDK\ sw\ lib\bsp\文件夹。您会在此文件夹下看到一些其它 *** 作系统，包括独立系统和xilkernel。随后，如图1所示，将名为Zynq-7000-ucosiii-demo.zip的ZIP 文件解压到\\ISE_DS\EDK\sw\lib\sw_apps\文件夹。您会在此文件夹内看到一些其它应用的演示。

安装完这两组文件后，我们就可以在软件开发套件(SDK)中创建项目。我们将会使用之前创建的相同基础硬件，但由于想添加该 *** 作系统，因此还需要一个新的应用程序和板支持包(BSP)。

在SDK中，应关闭基础硬件设计外所有已打开的项目。下一步选择File > New > ApplicaTIon Project选项，命名新项目并选择 *** 作系统μC/OS-III（见图2）。然后选择用于μC/OS-III的演示程序（见图3）。

完成后，点击Finish按钮。在SDK中将会创建应用和板支持包（如选择该项）。如果您选择了Auto Build选项，会发现若干错误报告。这是因为并不是所有项目参考都是正确的。要设定这些项目参考，您需要导入在Project > Src > SetTIngs选项中找到的演示设置。右击XML文件并查看属性。这样便可选择并复制文件位置，如图4所示。

位置复制后，右击项目并选择属性。在项目C++/C++ General下，选择Paths和Symbol选项。然后选择Import SetTIngs，并粘贴到设置文件的位置。

另外必须确保资源库能正确指向您之前所添加的库。您可以通过设置Xilinx Tools > Repositories对其进行检查；该选项应显示之前μC/OS-III BSP的安装位置。

由于我们希望用UART输出演示的状态（显示完成的初始化值和正在运行的任务），因此您可能需要在BSP设置下将stdin和stdout设置到UART。

执行完这些工作后，您会发现目前就可以创建项目了。但是仍存在一些警告，如果您尝试在硬件上运行该项目，项目并不能如演示那样执行。这是因为存在一个未声明的函数警告。在bsp.c文件中加入如下声明可纠正这个问题。
#include "xil_cache.l

一旦添加“include”头文件后，项目就可按照预期构建并在ZedBoard上运行，(登陆 ?v=uRB4La5ijrA 观看YouTube视频)。

启动并运行
启动并运行实例项目后，您大可放心您的系统上肯定正确实现了RTOS。现在，您可继续在Zynq SoC上正确实现软件设计。一旦您创建了软件应用，并且工程设计团队也已做好了在硬件上进行测试的准备后，您就可以创建一个编程文件——创建方法与物理硬件系统完全相同（见赛灵思中国通讯杂志第48期中的“如何配置Zynq SoC 物理硬件解决方案”，从而让采用RTOS的应用从配置存储器中启动并执行。