DSP/BIOS环境下的数据通信

摘要：讨论和比较DSP/BIOS环境下的各种通信方式，给出利用PIP管道对象进行数据通信的一个例子。文章的最后给出利用管道对象进行数据通信所需注意的一些问题和相应的解决方法。 关键词：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应用系统的输入输出中得到了广泛的应用。但是，我们在利用其所提供的便利的同时，一定要妥善处理好通知读/写函数的编写工作，以免发生递归调用，产生灾难性的后果。