采用 Linux 与 DSP/BIOS RTOS

在系统性能与编程简易性之间的权衡折中是通用操作系统与实时操作系统之间的主要区分点之一。

GPOS 倾向于提供较高程度的资源抽象，这不仅可通过支持软件模块性与资源隔离来提高应用的便携性、简化开发流程，同时还能增强系统的稳健性。这使 GPOS 成为诸如网络、用户界面以及显示管理等通用系统组件的理想选择。

然而，该抽象需要以系统资源的精细粒度控制作为代价，以满足信号处理代码等高强度算法的计算性能要求。对于实现这种高级别的控制，开发人员通常需要采用实时操作系统 (RTOS)。

从嵌入式信号处理角度上讲，我们通常要考虑两种类型的操作系统，即通用操作系统 Linux 与实时操作系统 DSP/BIOS。Linux 可支持更高水平的抽象技术，而 DSP/BIOS 则可提供更精细的控制。

为了充分发挥这两种操作系统的优势，开发人员可采用系统虚拟机，这就使编程人员可在同一 DSP 处理器上同时运行 Linux 与 DSP/BIOS 系统。

(编者注：与 Java 虚拟机等特定编程语言使用的进程虚拟机环境不同，系统虚拟机对应于实际硬件，可在相同计算环境中与其它类似实例相隔离的情况下执行完整的操作系统。)

然而，我们要提出一个重要的问题：为什么不使用分别运行 Linux 与 DSP/BIOS 系统的 CPU+DSP 组合器件呢?毕竟，CPU 在运行用户接口控制代码等方面具有更高的效率。此外，不同的内核可避免虚拟化带来的开销。不过，在同一颗芯片上集成所有功能还是很有吸引力的，原因如下：

其一，当今高性能 DSP 比前代 DSP 要强大得多，这样可减少控制处理周期数。其二，大多数高性能 DSP 的通用性能均比前代产品更强，从而可实现更高效的控制代码处理工作。

如果所有功能都可集成在 DSP 上，那么其优势将更加出众。更少的芯片数量可实现更低的成本与更小的占用空间。此外，由于不再需要在耗费大量电力的处理器间数据传输，因此还可降低能耗。

进度安排

操作系统最常见也是最有利的一个特性就是能同时执行多个任务或多个线程。操作系统通过时间表来管理内核处理，以连续执行相关任务。

以往，嵌入式编程人员在使用 Linux 时会担心实时性能较低的问题。不过，对 Linux 内核的最新增强显著提高了其对系统事件的响应能力，从而使其可满足各种企业与个人以及嵌入式产品的需求。

Linux 可实现线程的时间切片以及优先次序时间安排。时间切片技术是指在所有线程之间共享处理工作周期，以确保无封锁线程。这种方法通常适用于用户接口功能，以确保在系统超载、响应较慢的情况下也不至于完全丢失用户功能。

与此形成对比的是，优先次序线程时间安排技术则可确保系统中最高优先级线程的执行，直至该线程放弃控制为止，这时下一个最高优先级的线程即开始执行。

Linux 内核在每次从内核到用户模式的转换时都会对可用线程的优先级进行重新评估，这就意味着内核最新评估的任何事件(如驱动程序上数据的可用性)都能立即触发新线程(调度器的时延响应时间内)的转换。由于确定了基于优先级的线程，其通常用于必须满足实时要求的信号处理应用。

在推出 Linux 内核 2.6 版本之前，制约实时性能的主要因素是 Linux 内核会禁用中断，且禁用时间有时会长达数百毫秒。

就此而言，我们可以提高内核实施的效率。因为在禁用中断时，代码的某些部分无需重新进入，而这会增加中断响应的时延。

目前的 2.6 版本提供了构建选项，可在整个内核代码中以更高的频率插入中断再启用指令。Linux 社区通常将该特性称作先占内核 (preempt kernel)，尽管这会让内核性能略有下降，但却能够显著提高实时性能。对于众多系统任务而言，在先占性 Linux 2.6 内核与实时线程结合使用时，将能提供足够的性能来满足实时需求。

例如，德州仪器 (TI) 的 DSP/BIOS 以软件中断和任务的形式仅支持优先级调度。与 Linux 调度器一样，软件中断和任务都属于先占型的。但是，DSP/BIOS 也为应用编程人员提供了直接存取硬件中断的条件，该资源仅适用于 Linux 内核模式。

直接存取硬件中断使应用编程人员可在理论上实现底层硬件所支持的最短时延响应。对控制环路等需要绝对最低时延的应用而言，这种精细粒度的硬件中断控制机制通常是一种非常重要的特性。

受保护的资源访问

Linux 与大多数通用操作系统的一个基本属性就是用户空间程序与所用的底层系统资源相分离。仅在工作处于监控(如内核)模式下时才允许直接访问存储器和设备外设。

如果用户程序希望访问系统资源，那么它必须通过称作驱动器的内核模块从内核发出请求。该应用位于用户存储器空间，并将通过虚拟文件访问驱动程序。然后，虚拟文件将应用的请求转至驱动器执行的内核存储器空间。

Linux 可提供特性极为丰富的驱动器模型，其中包括标准流媒体外设、模块存储设备以及文件系统，甚至还包括网络与基于网络的文件系统。

驱动器与用户空间应用的分离可实现高度的稳健性。此外，通用驱动器接口上的抽象水平使其便于将数据流传输给串行端口、闪存文件系统或网络共享文件夹，且仅需对底层应用代码稍作更改。

然而，实现这种灵活性需要付出代价。应用与物理资源的严格分离会加大开销。如果用户空间程序要访问设备外设，则内核模式必须进行环境交换才能处理该请求。

由于数据是成块访问，而非逐个样本 (sample-by-sample) 访问，因此通常来说这不会造成太大的局限性。这样，内核模式下每次块访问仅需进行一次环境交换即可。

但是，在某些情况下，应用代码需与物理硬件严格匹配。如果使用 DSP 等对数据吞吐量要求较高且不能容忍停顿的高性能处理器时，通常就会出现此类情况。这时，内核空间的物理资源与用户空间的应用相分离的做法就可能会严重影响系统性能。

应用与硬件的匹配

我们不妨使用 TMS320DM643x 处理器架构来研究在执行块视频处理时会遇到的典型情况，该架构采用一个 600 MHz / 4800 MIPS DSP 处理内核以及诸如功能丰富的视频端口子系统等各种多媒体外设。这种硬件通常用于将输入视频流进行 H.264 格式压缩。

为了充分发挥 DSP 内核的处理能力，处理的数据应从周期操作内部存储器读取，而不是从速度较慢的外部存储器读取。尽管在技术上可以让具有足够快的片上存储器的处理器存储一个或多个完整的视频帧，但这种技术对大多数目标市场来说成本太高。因此，采用可提供 80 KB 的单周期操作片上数据存储器的处理器取而代之。