DSP/BIOS环境下的数据通信
扫描二维码
随时随地手机看文章
关键词：DSP/BIOS 管道 流I/O 主机
引 言
对于数字信号处理应用来说，数据的通信很关键。在TI公司的DSP/BIOS环境下有3种通信方式，即基于管道（PIP，pipe）的通信、基于流（SIO，stream I/O）通道的通信以及基于主机（HST，host）通道的通信。每一种通信方式都是通过调度其相应的内核对象来完成的。DSP/BIOS提供了管理每一种通信方式的模块及相应地API调用，通过这些模块及调用，可以完成DSP环境下的输入/输出 （I/O）。本文在对各种通信方式进行简要介绍的基础上,对各种通信方式进行比较，并给出利用PIP对象进行数据通信的1个例子。
1 通信方式简介
（1）主机通信
主机通信方式下，由HST对象完成主机与目标机之间的通信。HST对象静态配置为输入/输出，每一个HST对象内部是用数据管道对象来实现的。
开发DSP应用时，可以应用HST对象来模仿数据流和测试程序算法对数据的处理。在程序开发的早期，特别是在测试信号处理算法时，程序使用输入通道对象访问来自主机文件中的数据，以及使用输出通道对象把算法处理过的结果反馈回主机一侧，以供查验或比较。在程序开发的后期，当算法开发完毕时，可以把HST对象改回到PIP对象，通过利用PIP对象完成外设真实数据与目标应用程序之间的通信。
（2）管道通信
管道（PIP）对象用于管理块I/O（也称为基于流的I/O或者异步I/O）。每一个PIP对象维护着一个分为固定数量和固定大小的缓冲区（称为帧）。所有的I/O操作在每一刻只处理1帧。尽管每一帧长度是固定的，但是应用程序可以在每一帧中放置可变数量的数据（但不能超过最大值）。管道有两端，一端为写线程，一端为读线程。写线程一端用于向管道中添加数据，读线程一端用于从管道中读取数据。管道能够用于在程序内的任意2个线程之间传递数据。经常地，管道的一端由ISR控制，另一端由软件中断函数控制。数据通知函数（也称为回调函数）用于同步数据的传输，包括通知读函数和通知写函数。当读或写1帧数据时，这些函数被触发，以通知程序有空闲帧或者有数据可以利用。
（3）流通信
流是一个通道，通过它，数据在应用程序与 I/O设备之间传输。流通道可以是只读的（用于输入）或者只写的（用于输出）。它对所有I/O设备提供了一个简单通用接口，允许应用程序完全不用考虑每个设备操作的细节。流I/O的一个重要方面是它的异步特性。当应用程序正在处理当前缓冲区时，一个新的输入缓冲区正在被添充和以前的缓冲区正在被输出。流交换的是指针而不是数据，这就大大减少了开销，使得程序更能满足实时约束的要求。流模块（SIO）通过驱动程序来与不同类型的设备打交道。驱动程序由DEV（Device）模块管理。
设备驱动程序是管理一类设备的软件模块。这些模块遵从通用接口（由DEV提供），因此，流函数能够发出普通请求。图 1 给出了流与设备之间的交互示意图。
（4）各种通信方式比较
DSP/BIOS支持两种不同的数据传输模型，一种是管道模型，由PIP与HST模块使用；另一种是流模型，由SIO与DEV模块使用。2个模型都要求1个管道或者流具有1个读线程和1个写线程。2个模型都通过拷贝指针而不是数据来完成数据的拷贝。一般来说，管道模型支持低级通信，而流模型支持高级的、与设备无关的I/O。具体情况如表1所列。
表1 DSP/BIOS环境下通信方式的比较
| 管道对象（PIP与HST） | 流对象（SIO与DEV） |
| 程序员必须创建自己的驱动程序 | 提供了一种创建设备驱动程序的更加结构化方法 |
| 读/写线程可以是任意线程类型或者主机PC | 一端必须由使用SIO调用的任务（TSK）来处理，另一端必须由使用Dxx调用的HWI处理 |
| PIP函数是非阻塞的，程序在管道写或读之间必须进行检查，以确保缓冲区可利用 | SIO_put、SIO_get和SIO_reclaim是阻塞函数（SIO）_issue是非阻塞函数） |
| 使用更少的内存，一般较快 | 更加灵活，使用简单 |
| 每个管道拥有自己的缓冲区 | 缓冲区能够从一个流传输到另一个流而不用拷贝 |
| 管道必须使用配置工具静态地配置 | 流可以在运行时刻创建或者使用配置工具静态地配置 |
| 对推栈设备（stacking devic）没有内建地支持 | 提供对堆栈设备（stacking devic）的支持 |
| 使用HST（内部PIP实现）使得主机与目标机的通信容易起来 | DSP/BIO提供了大量的设备驱动程序 |
2 基于管道通信的一个例子
在基于以上分析的基础上，给出利用管道进行通信的1个例子。该例是音频处理的一个例子。数据从数据源输入到编码器以后经量化通过串行口输入到目标机，目标机处理完毕后再经串行口发送到编码器，由编码器经扬声器输出。图2给出数据的流程图。
（1）管道设计
该例中，设计了DSS_rxPipe和DSS_txPipe两个管道，其中DSS_rxPipe用于数据的接收，DSS_txPipe用于数据的发送。
（2）线程设计
由于每个管道分别对应1个读写线程，因此，发送管道与接收管道总共需要4个读写线程。本例中为了简化设计，只设计了2个线程。其中，音频处理函数（设计为软件中断SWI）既作为接收管道的读线程又作为发送管道的写线程；串行口接收中断处理服务例程ISR既作为接收管道的写线程又作为发送管道的读线程。
每次中断发生时，串行口中断服务例程（ISR）把数据接收寄存器（DRR）中的数据字（32位）拷贝到数据接收管道的一空闲帧中。当1帧被填满时，ISR把该满帧写到数据接收管道中（通过调用PIP_put），供该管道的读线程（即音频处理函数）读取。音频处理函数执行时，它读取接收管道中的一满帧，处理完毕后再把它写到发送管道的一空闲帧中，供该管道的读线程（即ISR）发送。每次ISR触发时，它从发送管道中读取一满帧（若有的话），并每次32位字地发向串行口发送寄存器（DXR）直到1帧中的所有数据发送完毕。然后，该空闲帧被回收到发送管道，供音频处理函数（即该管道的写线程使用）。需要注意的是，由于例子当中发送速率与接收速率一样，因此，中断处理函数不但负责数据的接收也负责数据的发送，并且每次中断执行时只发送1个32位字。
（3）需注意的问题
PIP_alloc和PIP_put由PIP对象的写线程调用，PIP_get和PIP_free由PIP对象的读线程调用，这种调用顺序是非常重要的。若打乱这种调用顺序，将会产生不可预测的后果。因此，每一次对PIP_alloc的调用都要跟着对PIP_put的调用才能继续调用PIP_alloc；对于PIP_get，情况也是如此。
另外，为了避免PIP调用过程中产生递归，作为通知读/写函数的一部分，应该避免调用PIP API函数。如果为了效率起见必须要这样做，那么对诸如此类的调用应该加以保护，以阻止同一管道对象的重入以及错误的PIP API调用顺序。例如，在发送管道的通知读函数以及接收管道的通知写函数的开始部分，我们添加了如下语句，以避免递归调用：
static Int nested = 0；
…
if (nested){/*防止由于调用PIP_get函数而产生的递归调用*/
return；
}
nested =1；
…
3 总 结
在DSP/BIOS提供的3种通信方式中，由于PIP对象的效率很高，因此使得它在基于DSP应用系统的输入输出中得到了广泛的应用。但是，我们在利用其所提供的便利的同时，一定要妥善处理好通知读/写函数的编写工作，以免发生递归调用，产生灾难性的后果。
下载文档
