第 3 章 多媒体任务管理和 Fatfs 文件系统移植
本系统中要完成多种多媒体任务，单凭 Nios II 软核不能完成多线程的工作方式，为了解决多任务调度和管理的问题，本文利用嵌入到 Nios II IDE 中的μ C/OS II 系统来实现多媒体系统的任务管理和并行协同工作，这样即简化了软件控制的难度，又提高了整个系统的可重用性和工作性能。另外，在系统的主要存储设备 SD 卡的控制方面，利用传统的软件控制较为复杂而且读写速度较慢，本系统在 Nios II 中结合了 Fatfs 文件系统，进行软件上的优化来提高效率。
下面将对这两项在软件控制上的优化设计进行讲解。
3.1 μ C/OS II 系统
3.1.1 μ C/OS II 简介
μ C/OS II 是由 Micrium 公司在 1992 年首次发布的一款非常流行的实时内核系统，它具有很好的灵活性和实时性，可固化可裁剪并且有抢占性和多任务内核。已经应用于数以百计的商业应用，成功的在超过 40 不同架构的处理器上执行过任务。本系统就是将μ C/OS II 应用在 Nios II 处理器上，由于我们用到的Nios II IDE 软件对 μ C/OS II 系统提供了完全的支持，所以可以很方便的将操作系统移植到用户定制的系统中去[35,36].
μ C/OS II 为用户提供了六项基本服务。一、时间管理（Time management）：
主要是一些用来对任务进行延时、让延时结束、得到系统时间的函数。二、内存管理（Memory management）：在操作系统中将一整块内存空间分成多个大小相等的内存分区进行管理。三、任务管理（Task management）：用来进行任务的创建和修改，还有设置任务的优先级以及对任务的挂起和恢复操作。四、信号量（Semmaphores）：可以产生事件发生标志、控制使用共享资源，还可以用来传递信息。五、消息传递（Message passing）：主要用做实现两个不同任务之间的通信，传递的方式有邮箱消息和消息队列两种。六、事件标志（Event flag）：用做同步不同的事件。
这里主要介绍一下系统主要用到的任务管理服务。μ C/OS II 能够管理的任务上限为 64 个，其中有四个最高优先级和四个最低优先级的任务是系统自身保留的，仍然剩下 56 个供用户使用的任务，每个任务都会被分配一个数字作为任务的编号，数字越小对应的任务优先级就越高。μ C/OS II 的任务调度策略是，在等待列表中选择优先级最高的任务优先运行。这就意味着如果优先级高的任务一直在运行，那么低级别优先级的任务就只能一直等待，没有执行的机会。
这就要求开发者对任务的优先级有一个合理分配，才能保证各个任务的正常运行，本系统中任务的分配会在下面进行详细介绍[37].
3.1.2 μ C/OS II 在多媒体平台中的应用
μ C/OS II 内核是运行在基于硬件抽象层板级支持包上的，在 Nios II IDE 软件中直接把μ C/OS II 像 C 标准库一样作为硬件抽象层扩充到 Nios II 处理器上，如图 3-1 所示为它的编程结构，从中我们可以清晰的看出它与 Nios II 处理器、HAL API 在结构上的关系。正是因为这种结构在 Nios II 处理器上利用 μ C/OS II进行开发有很多的优势：它的程序能够灵活的运用到其他的 Nios II 硬件系统上；对于潜在的硬件更改问题有抵御能力；可以访问所有的 HAL 服务，就像 UNIX风格的应用程序接口一样；它的 ISR 函数很容易实现。
在 Nios II IDE 软件中使用μ C/OS II 时，通过 Nios II 工程设置就可以为实时操作系统模块进行控制。我们不需要直接修改源文件的内容来更改内核属性。
在对系统移植时已经把源代码放入 Nios II IDE 的安装路径中，特定处理器代码的路径是<Nios II EDS install path>/componets/altera_nios2/UCOSII,独立处理器代码的路径是<Nios II EDS install path>/componets/micrium_uc_osii. μ C/OS II的软件包的工作机理类似于为硬件组件提供的驱动，当在 Nios II 工程中使用μ C/OS II 系统时，componets/micrium_uc_osii 路径中的 header 文件和 source 文件就被包含在工程路径当中，相应的设置参数就会反映在板级支持包的 system.h文件中，对于系统设备驱动在工程建立好后，包含 inc 和 src 子目录的 UCOSII目录就会被添加到 source 和 include 文件的搜索目录中区，Nios II 的软件建立工具（SBT）会把这些文件复制到工程中 BSP（板级支持包）的 obj 目录，这样μ C/OSII 内核就可以自动编译并链接成为整个工程的一部分。
下面介绍一下基于μ C/OS II 编写应用程序的步骤。
首先，利用#include“includes.h”函数，在工程中包含函数声明、基本的宏定义等等。
第二，利用#define TASK_STACKSIZE 4096,来对任务栈的大小进行设置，这一步骤是保证线程安全的关键。
第三，为了提高系统的实时性和系统的正常运转，要合理分配任务的优先级。
第四，完成单个具体任务的程序编写。
第五，利用 OSInit（）函数初始化所有的数据结构。
第六，创建至少一个用户。方式有两种，可以先创建父任务，接着利用父任务创建子任务；也可以依次的创建任务。
第七，利用 OSStart（）启动操作系统，让各个任务开始运行。
μ C/OS II 在多媒体系统中主要起到的作用就是可以实现多线程的工作模式，并且完成多媒体任务的创建和多任务的调度。在软件设计中，多任务的程序设计方式也是一个难点。在进行任务管理调度时，因为每一个任务需要的资源和重要程度不同，所以对任务的优先级进行合理的配置在很大程度上会影响到整个系统的性能指标。
在上面的介绍中我们已经知道，系统总会运行等待列表中优先级最高的那个任务。所以，本系统将主任务的优先级设为最高，主任务的作用就是来创建子任务，任务结束就自我删除。本文的多媒体平台一共有三个子任务需要调度，有图像显示与采集任务、GPS 信息接收显示任务和音乐播放任务。GPS 信息接收显示任务由于解析的数据量相对较小，显示文本相对简单，任务执行最快，耗时也最短，所以把它的等待时间设为最长，优先级设为最高。在图像显示与采集任务当中，采集图像数据，读取图像数据，解码数据，显示图像的过程为三个任务中最为复杂，处理的数据量最大，耗时最长，执行最慢，所以把它的优先级设为最低，等待时间设置为最短。音乐播放功能中，音频解码部分运用硬件解码所以处理速度会稍快，在耗时和执行速度上都处在中间，所以把它的优先级和等待时间都设为中。按照以上的优先级设计方式，系统就能够在执行高优先级任务的同时也能够执行低优先级的任务，能够充分发挥多任务设计给本多媒体平台带来的强大的性能提升。
对μ C/OS II 系统具体的操作步骤和配置将在第五章的软件整合部分给出。在第四章中会对各个任务子模块的执行程序设计进行讲解。
3.2 FATfs 文件系统移植
3.2.1 FATfs 文件系统移植在多媒体平台中的必要性
本文中的多媒体平台需要对音频和图像文件进行存储并对这些文件进行读写操作。我们选择了 SD 卡作为存储设备，因此文件系统在数据存储设计这一块就起到了至关重要的作用。传统的直接对存储介质进行数据读写的方式太过复杂且通用性差，每次操作前都要对其存储空间结构充分的了解，极大的增加了程序设计的难度。而通过移植文件系统就能够系统地灵活地对数据进行操作。
因为文件系统为开发者提供了明确的 API 函数，这些函数与地层的存储介质不相干，也就避免了每次都从头开始对地址空间进行读写。这样一来，我们在访问底层存储器时就有了标准的接口函数使程序更有层次感，可移植性更强更符合未来的发展趋势[38].
当前市面上经常被用到的文件系统有 ZLG/FS 系统、uC/FS 系统和 FATfs 系统。第一种是针对嵌入式的小型系统，虽然是免费的，但系统不够完善和稳定；第二种由 Micrium 公司开发，功能非常强大，一般用在硬盘、FLASH、CF 卡等上面，但它是一种商业系统，需要付费。所以这里我们选择了 FATfs 文件系统，它是一款专门为小型嵌入式系统设计的 FAT 系统模块，不仅免费开源而且高效。
另外，源代码都是用标准 C 编写具有很好的硬件平台独立性[39,40].
3.2.2 FATfs 文件系统的结构和原理
FATfs 文件系统的结构如图 3-2 所示有三个层次，文件系统应用层负责与用户进行沟通的，提供文件系统操作的 API 函数给用户；FATfs 文件系统层是实现有关文件系统的；disk I/O 硬件层是与具体用到的存储设备直接关联，开发者会提供与存储设备对应的接口函数。
FAT 作为一种分区格式，按照 FAT 表中簇号的位数不同可分为 FAT12、FAT16 和 FAT32 三种，FAT 后面的数字代表的就是其簇号的最高位数，因为本文用到的 SD 卡容量为 1G,所以选择了 FAT16 这种格式[41].
上面提到了簇这个名词，它是文件系统中文件存储的基本单位，每个簇的大小是由开发者设定的，以本系统为例，SD 卡的容量为 1G,那么就应该将簇的容量设置为 16KB,这样才不会浪费磁盘空间。计算一下，因为选择的是 FAT16格式，簇号用 16 位表示，最多的簇数为 216=65536 个，设置的簇容量为 16KB,则磁盘的总空间为 16KB*65536=1024MB 刚好为 1G.
FAT16 主要由六部分组成，如图 3-3 所示。下面就分别说一下这基本分的作用。
首先是 DBR（DOS Boot Record）操作系统引导区，它是可以被直接访问的第一扇区位于0磁道。这一区主要包含引导程序和BPB（Bios Parameter Block），BPB是一个很重要的数据结构，叫做基本参数块，它包含了文件分区的基本描述信息，这些信息都非常重要，主要有，扇区数、每扇区的字节数、FAT 表数、每个 FAT 表占用的扇区数、根目录的个数等信息[42].
根据上面的 BPB 中保留扇区和首扇区的信息我们就可以到达 FAT 区，这一区的主要任务就是为文件之间搭上一根链条，用来索引和定位，这种结构被称为“链式结构”.它有自己的一套查找文件的流程，每个链上的元素代表的是簇号，利用文件的目录项就可以得到文件数据簇号的起始位，接着就能够在数据区得到这个簇的数据。接下来，按照簇号查找到数据相应的 FAT 表，如果其文件内容的结尾是“FF”则文件查找成功，如果不是说明查到的是链条，则将此单元的内容作为下一单元的簇号继续查找，其流程如图 3-4 所示。
这种存储链表对于文件的读取非常重要，所以为了数据的安全，我们从图3-4 看出有 FAT1 和 FAT2 两个区，FAT2 就是作为 FAT1 的备份区存在，两个的数据内容是一致且同步的。根目录区在上面索引文件的流程中提到，它也是十分重要的，存储了文件属性和起始簇号等关键信息，与它结合 FAT 才能准确的定位文件位置。根目录后面就是数据区了，它占了磁盘的主要空间，存储了用户的文件和文件夹。
3.2.3 FATfs 文件系统的移植
文件系统的移植就是要消除其应用在不同平台上的差异性，本系统就是要实现在 Nios II IDE 软件环境中实现 FATfs 对 SD 卡的控制，在移植过程中编译器是一项很重要的工具，文件系统的源代码要经历 C 到汇编再在二进制可执行代码的过程，这个过程中容易出现意想不到的错误，让人欣慰的是，Nios II IDE集成开发环境提供了非常优质的编译器，可以有效的避免这些错误发生，同时FATfs 与各平台极好的兼容性也为移植提供了很好的保证。
移植的准备工作首先将 FATfs 源代码的文件夹放入工程的 software 文件夹中，源代码共有六个文件，integer.h 文件中是对所有用到的数据类型的描述，ffconf.h 文件是对系统有关的配置，用来描述 disk I/O 硬件层的是 diskio.c 和diskio.h 文件，最后是描述文件系统应用层的 FATFS_008.c 和 FATFS_008.h 文件。
接下来就是利用这些源文件进行移植，主要分为以下几个步骤。
首先要解决的是数据类型问题，系统中需要统一的数据类型，这一点的配置在 interger.h 文件中进行设置，之后在执行代码头部 include 它就可以解决数据类型的问题。
第二步，也是非常重要的步骤就是将文件系统层和应用层与 SD 卡联通起来。这里还要用到 SD 卡的驱动文件 sd_driver.c 和 sd_driver.h 文件，同样要放入工程的 software 文件夹下。我们要完成的任务是利用文件系统实现对 SD 卡的读写操作，所以要联通的最基本的就是初始化函数和读写扇区函数。控制硬件层的 diskio.c 和 diskio.h 文件中这三种函数分别是 disk_initialize（）、disk_read（）、disk_write（）。要实现联通，首先在 sd_driver.h 文件中 include 文件 diskio.h,并编写交互接口函数。另外在 diskio.c 文件中要 include 文件 sd_driver.h.这样就能够实现文件系统中对 SD 卡底层驱动的控制。
最后的步骤就是利用 ffconf.h 中的配置文件根据实际情况对文件系统综合配置，这里需要给宏定义分配数值。
到这里文件系统就成功的移植到了 Nios II 上，在对 SD 卡中数据在软件设计中直接引用简单的 API 读写函数就能够实现对 SD 卡中数据的操作无需考虑存储介质。在对 SD 卡操作时要注意的事项是，每次打开 SD 卡即利用 f_mount（）函数挂载，完成文件操作之后必须要在用这个函数关闭 SD 卡，这样才能保证其正常运行。
3.3 本章小结
本章主要承接第二章中系统的总体结构和任务划分部分，对多媒体平台中的任务调度方法进行了详细的描述，并且给出了重要的存储模块中为了控制 SD卡的 FATfs 文件系统的移植。在任务调度上，本文利用了μ C/OS II 系统对软件控制进行了优化，上文中讲解了μ C/OS II 如何应用在 Nios II 软核上并给出了任务分配和管理的方案。在文件系统移植方面，文中讲解了 FATfs 系统的原理和移植过程。有了这两方面的设计和软件上的优化，也为下面的第四章中多媒体平台的各个功能模块的设计打下了坚实的基础。
