基于DSP/BIOS 的TI DSP 应用程序框架设计

　　3.1 主从通信方式

　　我们在DSP 的存储空间中定义了两个寄存器：DSP 运行控制寄存器（DSP_CNTL）和DSP 运行状态寄存器（DSP_STAT）。在DSP_CNTL 中可以定义一系列控制字段用来表示外部主机对DSP 的各种控制操作，而在DSP_STAT 中可以定义一些与DSP_CNTL 相对应的描述DSP 当前运行状态的字段信息。GPP 通过合理地设置DSP_CNTL 以命令DSP 执行相应的操作，而DSP 在响应了CPU 的命令后会设置好DSP_STAT 以告知CPU 目前DSP 的运行情况。

　　另外，为了便于 DSP 与主机进行数据交换，ERF5 在DSP 的存储空间中开辟了两块专用于在DSP 与GPP 之间进行数据交换的缓冲区，并在DSP 运行状态寄存器DSP_STAT 中定义一个缓冲区标志位PPFLG 以告知主机当前它所能访问的乒乓缓冲区是“乒”或是“乓”，使得主机和DSP 之间的数据交互能够彼此相对独立地进行。

　　3.2 任务实现模型

　　在明确了主机与DSP 的通信方式以后，下面需要解决的就是如何在应用程序框架中给出合理的任务实现模型使它既能支持主机对DSP 的有效控制又能尽可能地减小DSP/BIOS的任务调度开销。这里以我们的实际项目为例来阐述任务的实现模型。在我们的H.264 混合编解码系统中，DM642 需要运行三个相互独立的任务：视频编码任务、视频解码任务和视频直通任务，在任意时刻，这三个任务线程的核心处理过程运行与否完全受GPP 控制。首先，出于对系统性能的考虑，我们都以静态配置的方式在DSP/BIOS 中定义这3 个任务，这样在系统运行时不需要花费由于任务动态创建所带来的不可避免的性能开销。显然这3 个任务应该具有同等优先级，否则，由于DSP/BIOS 实时内核的抢占性特征将使得某些高优先级的任务始终抢占那些低优先级任务的执行权即使GPP 在某些时刻并没有启动那些高优先级的任务。此外，由于DSP/BIOS 周期性地调度系统中所有处于就绪状态下的任务，所以必须使每个任务中判断其主体处理过程是否执行的逻辑和任务切换逻辑尽可能短小，因为这段代码在系统执行时将被频繁地调用。另外需要注意的是应该使用TSK_sleep(…)函数来实现任务切换逻辑以使当前没有被GPP 命令执行的任务被阻塞一段时间（该时间间隔应该至少是系统中各个周期性任务的最大执行周期），否则DSP/BIOS 任务调度器会频繁调度该任务以至于影响到其它任务的正常执行。下面以视频直通任务为例给出其任务执行流程图如图3所示。

　　图3 视频直通任务的执行流程图