论文部分内容阅读
摘 要：由于在原有的具有双核结构的数字信号处理芯片ADSP-BF561上运行的嵌入式Linux 2.6系统的运行效率不高，无法满足网络多媒体电话的实时需求。针对这个问题，本文在系统引导模式、程序的执行模式、线程支持以及双核通讯这几个方面对Linux系统进行了改进，从而提高了运行效率以及满足了实时应用的需求。
关键词：嵌入式；Linux；数字信号处理器
中图分类号：TP316.81
数字信号处理器（DSP）是指将信号以数字形式表示且处理的技术与理论，是对数字信号进行处理的一种芯片。数字信号处理器是跟随数字信号处理技术共同发展的。数字信号处理器除了应用于音视频领域，还广泛应用于通信、信息、控制、军事、雷达、医疗、家用电器以及航空航天等多个领域。下面介绍的数字信号处理器的系统采用的是嵌入式Linux 2.6系统，它在消费类的数字多媒体产品中得到广泛应用。
1 嵌入式Linux的概述
嵌入式系统是一种以计算机技术为根本，以运用为核心，软硬件可被任意裁剪，适用于各类应用系统，对成本、功耗、功能、体积以及可靠性要求严格的特定计算机系统。它的计算机硬件系统是将功能软件与操作系统集于一身，简而言之就是将系统的硬件与应用软件一体化，具有自动化高、软件代码小以及速度迅速等优点。Linux是日趋盛行的一种操作系统平台，能被广泛的用于各类产品与工程中。由于Linux系统的资源都是免费开放的，因此为了满足和适应市场以及Linux应用软件的各种需求，它的配置与所支持的软件组件都在不断发展。目前Linux系统主要有实时增强和嵌入式这两个版本。虽然Linux系统最初被用于PC体系组织结构的操作系统，但如今也被应用于各种管理单元、控制器。嵌入式Linux最大的特点便是选择性广。
2 总体设计结构
此系统主要采用的是ADSP-BF561芯片，它具备双核CPU，主要由Core A与Core B这两个可独立进行计算的Blackfin核构成。每个Blackfin都包括四种片上存储器，其中一个称为L2是双核共享的，其他三个空间里每个Blackfin核各占一份。此网络多媒体电话的主要有音/视频解码、音/视频编码（G.711、H.263）、网络通讯（H.323、PPPOE）等功能。用Linux系统来承担网络通讯功能，能很大程度地减轻软件开发整体的工作量。对系统进行总体设计时，不仅平均地分配了BF561双核芯片的计算任务，而且定义Core A为供Linux 系统运行的主导核，用来担任系统的网络通讯和解码计算，同时定义Core B 来进行运算量大的编码计算。
3 嵌入式Linux在DSP中的具体应用
在对系统进行详细设计时，有几个问题我们要事先考虑好：第一，只要是通过VDSP工具所开发出来的编/解码算法都不可在使用GCC工具编译的Linux系统中直接运行，再加上GCC工具的代码优化能力不强，因而要往Linux系统中移植编/解码算法所需的工作量太大。第二，Linux系统中没有把不是GCC工具编译出来的代码加载到BF561芯片中的片内存储空间的方法。第三，由于现有的Linux系统中不支持线程，而且系统栈存在于片外的SDRAM中，因此导致访问速度变慢。第四，BF561芯片所具备的原子操作功能在用在双核互斥的访问临界资源的时候会引起死锁。下面介绍一下具体的解决方案：
3.1 再阶段引导方式
在处理音/视频数据时，网络多媒体电话不仅要进行较多的运算，而且在计算方面要求速度较快。相比外部的SDRAM，BF561芯片的内部L1存储器对代码的执行速度要快很多，因此，要想提高速度，就该把全部的算法都加载到内部的L1中。再加上与VDSP工具相比，开源社区所支持的GCC工具所具有的优化能力较弱，因此算法最好采用VDSP工具来翻译链接。要想将这些问题解决，必须用到再阶段引导方式：在第一阶段先对链接选项进行更改，把音/视频的解压缩算法通过BF561的boot ROM加载到内部L1准确的位置上去；在第二阶段把Linux系统的压缩核心再加载到外部SDRAM的准确位置上同时开始运行。
一开始，建立一个VDSP的引导工程，往该工程里增添音/视频的解压缩的全部算法，再通过对链接选项的设置进行正确的引导。所有的代码、数据以及栈等的地址在链接文件中都进行了明确的规定，再根据链接文件VDSP工具能生成与执行程序映像，而且把地址信息都存储在于映像文件的头部。在系统引导的过程中，通过映像文件头所显示的信息，BF561的boot ROM可把数据和代码加载到之前链接文件所指定的位置上去。然后再往外部SDRAM里复制上Flash上Linux的核心压缩映像且启动核心运行。但值得注意的是，在核心运行被启动前，要先将Core B运行启动，当Core B 启动后它的编译算法便会进入一个死循环，从而重复执行和接收Core A的命令。因为Core B是一个单独的计算机单元，而且用于编译算法的数据、栈以及代码都存储与Core B的内部L1里，因此它的运行不会对Core A造成干扰。
3.2 混合执行多种代码
通过研究发现，非采用GCC编译的程序能在Linux系统中正常运行，只需将三个方面的问题解决好：
一方面，因为BF561采用的是实地址空间，不需要对代码进行地址的重定向，只需要在用到VDSP或GCC的链接代码时对编/解码程序和Linux核心的存放位置进行正确的设置，譬如data段、代码段等，确保各个部分拥有各自独立的空间而且互不冲突。由于Linux系统所管理的存储空间为外部SDRAM和内部L2，但编/解码程序所管理的存储空间大都聚集在L1里，因此能保证互不干扰。另一方面，要根据CPU的状态来设置栈指针。由于BF561具有USER和SUP两种不同的模式，它们有各自的栈指针。根据具体情况，我们设置解码程序运行于USER模式下，因为利用USER提供的栈，能够避免解码进程占用CPU的时间过长。但是在USER模式下运行的解码程序，解码程序会参与到调度中，势必会被其他进程抢占或中断，因此一定要准确地设置栈指针，不然的话会导致系统发生混乱。然而，要在Linux核心中运行程序就得用到exccv系统调用，但是exccv要是更改起来比较困难。基于这个问题，我们还是采用上面链接文件设置的方案，把解码程序看做是一个函数，来使用用户进程里的栈指针。并且在解码程序运行过程中栈的位置不发生改变，而只是运行出栈和压栈操作。 3.3 线程实现方案
由于Linux2.6系统不支持线程，要想增加此功能，就得更改核心系统和系统库调用。一般Linux的进程控制块要向SDRAM进行申请，因而导致访问速度非常慢。此外进程的系统栈位于进程控制块的8KB地址空间的顶端，因此系统栈也位于SDRAM中，因而进一步减慢进程的运行速度。而把主要进程模块以及init_task存储于内部L2中，能很大程度地加快进程的执行速度。在启动核心时需要用到init_task的系统栈，但是把init_task安置于L2中，就需要对编译选项进行更改设置。
3.4 DSP的双核通讯方案
网络多媒体电话系统进行编码的是Core B，而接收编码数据的是Core A，然后利用Linux系统将编码数据向网络传输，因此把编码后得到的数据传输给Linux系统是双核通讯最主要的任务。即使编码得到的数据量不是很大，但数据包的数目太多，在加上Linux系统自身的实时能力较差，要想进行处理非常困难，因此双核通讯需要用到环形缓冲方案。
缓冲区的读写是由Linux的设备文件来控制的。首要任务是让缓冲区能进行互斥访问。虽然BF561已使用testset来进行临界资源的互斥访问，但是由于testset指令仅仅只能用在单个核上程序之间的互斥访问，假如双核同一时间调用testset指令来访问相同的临界资源时，就会导致系统死锁。所以，缓冲区设备要通过读点（read_point）、写点（write_point）以及缓冲区的包数（n）三个变量来进行互斥访问。应用程序要读取缓冲区内的数据包，就得通过缓冲区设备read函数阻塞。假如缓冲区内有数据，那么read函数就会将读点的值返回，之后应用程序就能直接从读点读取数据以及更改读点，一直到读点遇到写点，然后应用程序将再次调用read函数阻塞从而等待数据。但是值得注意的是，读点的指的更改是由Core A来完成的，而Core B只进行读取，而写点却正好相反，双核不需要通过读点和写点之间的互斥访问，都能对n的数据进行读取和更改，因此只要可以通过n来对缓冲区的数据是否为空进行判断就行了。在某些情况下，n的指可能是负值或者出现错误，但因为BF561具有对称的多处理结构，而且单个核不会占用总线很长时间，不会让这种错误不会累积到缓冲区内允许的最大包数的值，因此不会对缓冲区数据是否为空的判断造成影响。
4 对系统性能进行评价
通过以上的改进方法，不仅实现了网络多媒体电话的功能目标，而且减少了软件系统开发所花费的时间。第一，大大减轻了Linux系统运行对编/解码算法性能的影响，编码算法在计算30帧/秒时，Core B的占用率不超过40%，跟单独运行的编译算的性能差不多。如果在Linux系统下，编译算法全负荷地运行，那么平均编码帧率在150帧/秒左右，相比单独运行的平均性能，只有5帧/秒左右的差别。第二，编/解码算法跟网络传输间互不影响。因为BF561双核是串行访问总线的，所以加入系统性能较差会导加重网络丢包现象。再加上双核通讯与进程这些模块能节省很多没用的系统开销，因此系统通过改进后，只有网络传输率超过800KB/s时才会导致UDP出现丢包，能满足系统的需求。第三，网络多媒体电话不仅具有较好的整体性能，而且有较大的扩充空间。在进行网络传输和30帧/秒的编/解码时，Linux系统下Core A的scbedule函数仅占用不到5%的CPU内存，解码算法占用20%的CPU内存，Core B的编译算法仅占40%的CPU内存。总的看来，CPU的占用率不高。
参考文献：
[1]关晓宁.基于嵌入式系统的数字信号处理平台的分析[J].科技致富向导，2012（30）.
[2]郑静菡，唱江华，刘树东，戴学丰.嵌入式下Linux系统设备驱动程序的开发[J].齐齐哈尔大学学报，2009（01）.
[3]袁俊杰，曹作良.基于Linux嵌入式系统开发平台的建立[J].天津理工大学学报，2006（03）.
作者简介：丽娜（1980.7-），女，辽宁阜新人，达斡尔族，讲师，研究生，研究方向：电子信息。
关键词：嵌入式；Linux；数字信号处理器
中图分类号：TP316.81
数字信号处理器（DSP）是指将信号以数字形式表示且处理的技术与理论，是对数字信号进行处理的一种芯片。数字信号处理器是跟随数字信号处理技术共同发展的。数字信号处理器除了应用于音视频领域，还广泛应用于通信、信息、控制、军事、雷达、医疗、家用电器以及航空航天等多个领域。下面介绍的数字信号处理器的系统采用的是嵌入式Linux 2.6系统，它在消费类的数字多媒体产品中得到广泛应用。
1 嵌入式Linux的概述
嵌入式系统是一种以计算机技术为根本，以运用为核心，软硬件可被任意裁剪，适用于各类应用系统，对成本、功耗、功能、体积以及可靠性要求严格的特定计算机系统。它的计算机硬件系统是将功能软件与操作系统集于一身，简而言之就是将系统的硬件与应用软件一体化，具有自动化高、软件代码小以及速度迅速等优点。Linux是日趋盛行的一种操作系统平台，能被广泛的用于各类产品与工程中。由于Linux系统的资源都是免费开放的，因此为了满足和适应市场以及Linux应用软件的各种需求，它的配置与所支持的软件组件都在不断发展。目前Linux系统主要有实时增强和嵌入式这两个版本。虽然Linux系统最初被用于PC体系组织结构的操作系统，但如今也被应用于各种管理单元、控制器。嵌入式Linux最大的特点便是选择性广。
2 总体设计结构
此系统主要采用的是ADSP-BF561芯片，它具备双核CPU，主要由Core A与Core B这两个可独立进行计算的Blackfin核构成。每个Blackfin都包括四种片上存储器，其中一个称为L2是双核共享的，其他三个空间里每个Blackfin核各占一份。此网络多媒体电话的主要有音/视频解码、音/视频编码（G.711、H.263）、网络通讯（H.323、PPPOE）等功能。用Linux系统来承担网络通讯功能，能很大程度地减轻软件开发整体的工作量。对系统进行总体设计时，不仅平均地分配了BF561双核芯片的计算任务，而且定义Core A为供Linux 系统运行的主导核，用来担任系统的网络通讯和解码计算，同时定义Core B 来进行运算量大的编码计算。
3 嵌入式Linux在DSP中的具体应用
在对系统进行详细设计时，有几个问题我们要事先考虑好：第一，只要是通过VDSP工具所开发出来的编/解码算法都不可在使用GCC工具编译的Linux系统中直接运行，再加上GCC工具的代码优化能力不强，因而要往Linux系统中移植编/解码算法所需的工作量太大。第二，Linux系统中没有把不是GCC工具编译出来的代码加载到BF561芯片中的片内存储空间的方法。第三，由于现有的Linux系统中不支持线程，而且系统栈存在于片外的SDRAM中，因此导致访问速度变慢。第四，BF561芯片所具备的原子操作功能在用在双核互斥的访问临界资源的时候会引起死锁。下面介绍一下具体的解决方案：
3.1 再阶段引导方式
在处理音/视频数据时，网络多媒体电话不仅要进行较多的运算，而且在计算方面要求速度较快。相比外部的SDRAM，BF561芯片的内部L1存储器对代码的执行速度要快很多，因此，要想提高速度，就该把全部的算法都加载到内部的L1中。再加上与VDSP工具相比，开源社区所支持的GCC工具所具有的优化能力较弱，因此算法最好采用VDSP工具来翻译链接。要想将这些问题解决，必须用到再阶段引导方式：在第一阶段先对链接选项进行更改，把音/视频的解压缩算法通过BF561的boot ROM加载到内部L1准确的位置上去；在第二阶段把Linux系统的压缩核心再加载到外部SDRAM的准确位置上同时开始运行。
一开始，建立一个VDSP的引导工程，往该工程里增添音/视频的解压缩的全部算法，再通过对链接选项的设置进行正确的引导。所有的代码、数据以及栈等的地址在链接文件中都进行了明确的规定，再根据链接文件VDSP工具能生成与执行程序映像，而且把地址信息都存储在于映像文件的头部。在系统引导的过程中，通过映像文件头所显示的信息，BF561的boot ROM可把数据和代码加载到之前链接文件所指定的位置上去。然后再往外部SDRAM里复制上Flash上Linux的核心压缩映像且启动核心运行。但值得注意的是，在核心运行被启动前，要先将Core B运行启动，当Core B 启动后它的编译算法便会进入一个死循环，从而重复执行和接收Core A的命令。因为Core B是一个单独的计算机单元，而且用于编译算法的数据、栈以及代码都存储与Core B的内部L1里，因此它的运行不会对Core A造成干扰。
3.2 混合执行多种代码
通过研究发现，非采用GCC编译的程序能在Linux系统中正常运行，只需将三个方面的问题解决好：
一方面，因为BF561采用的是实地址空间，不需要对代码进行地址的重定向，只需要在用到VDSP或GCC的链接代码时对编/解码程序和Linux核心的存放位置进行正确的设置，譬如data段、代码段等，确保各个部分拥有各自独立的空间而且互不冲突。由于Linux系统所管理的存储空间为外部SDRAM和内部L2，但编/解码程序所管理的存储空间大都聚集在L1里，因此能保证互不干扰。另一方面，要根据CPU的状态来设置栈指针。由于BF561具有USER和SUP两种不同的模式，它们有各自的栈指针。根据具体情况，我们设置解码程序运行于USER模式下，因为利用USER提供的栈，能够避免解码进程占用CPU的时间过长。但是在USER模式下运行的解码程序，解码程序会参与到调度中，势必会被其他进程抢占或中断，因此一定要准确地设置栈指针，不然的话会导致系统发生混乱。然而，要在Linux核心中运行程序就得用到exccv系统调用，但是exccv要是更改起来比较困难。基于这个问题，我们还是采用上面链接文件设置的方案，把解码程序看做是一个函数，来使用用户进程里的栈指针。并且在解码程序运行过程中栈的位置不发生改变，而只是运行出栈和压栈操作。 3.3 线程实现方案
由于Linux2.6系统不支持线程，要想增加此功能，就得更改核心系统和系统库调用。一般Linux的进程控制块要向SDRAM进行申请，因而导致访问速度非常慢。此外进程的系统栈位于进程控制块的8KB地址空间的顶端，因此系统栈也位于SDRAM中，因而进一步减慢进程的运行速度。而把主要进程模块以及init_task存储于内部L2中，能很大程度地加快进程的执行速度。在启动核心时需要用到init_task的系统栈，但是把init_task安置于L2中，就需要对编译选项进行更改设置。
3.4 DSP的双核通讯方案
网络多媒体电话系统进行编码的是Core B，而接收编码数据的是Core A，然后利用Linux系统将编码数据向网络传输，因此把编码后得到的数据传输给Linux系统是双核通讯最主要的任务。即使编码得到的数据量不是很大，但数据包的数目太多，在加上Linux系统自身的实时能力较差，要想进行处理非常困难，因此双核通讯需要用到环形缓冲方案。
缓冲区的读写是由Linux的设备文件来控制的。首要任务是让缓冲区能进行互斥访问。虽然BF561已使用testset来进行临界资源的互斥访问，但是由于testset指令仅仅只能用在单个核上程序之间的互斥访问，假如双核同一时间调用testset指令来访问相同的临界资源时，就会导致系统死锁。所以，缓冲区设备要通过读点（read_point）、写点（write_point）以及缓冲区的包数（n）三个变量来进行互斥访问。应用程序要读取缓冲区内的数据包，就得通过缓冲区设备read函数阻塞。假如缓冲区内有数据，那么read函数就会将读点的值返回，之后应用程序就能直接从读点读取数据以及更改读点，一直到读点遇到写点，然后应用程序将再次调用read函数阻塞从而等待数据。但是值得注意的是，读点的指的更改是由Core A来完成的，而Core B只进行读取，而写点却正好相反，双核不需要通过读点和写点之间的互斥访问，都能对n的数据进行读取和更改，因此只要可以通过n来对缓冲区的数据是否为空进行判断就行了。在某些情况下，n的指可能是负值或者出现错误，但因为BF561具有对称的多处理结构，而且单个核不会占用总线很长时间，不会让这种错误不会累积到缓冲区内允许的最大包数的值，因此不会对缓冲区数据是否为空的判断造成影响。
4 对系统性能进行评价
通过以上的改进方法，不仅实现了网络多媒体电话的功能目标，而且减少了软件系统开发所花费的时间。第一，大大减轻了Linux系统运行对编/解码算法性能的影响，编码算法在计算30帧/秒时，Core B的占用率不超过40%，跟单独运行的编译算的性能差不多。如果在Linux系统下，编译算法全负荷地运行，那么平均编码帧率在150帧/秒左右，相比单独运行的平均性能，只有5帧/秒左右的差别。第二，编/解码算法跟网络传输间互不影响。因为BF561双核是串行访问总线的，所以加入系统性能较差会导加重网络丢包现象。再加上双核通讯与进程这些模块能节省很多没用的系统开销，因此系统通过改进后，只有网络传输率超过800KB/s时才会导致UDP出现丢包，能满足系统的需求。第三，网络多媒体电话不仅具有较好的整体性能，而且有较大的扩充空间。在进行网络传输和30帧/秒的编/解码时，Linux系统下Core A的scbedule函数仅占用不到5%的CPU内存，解码算法占用20%的CPU内存，Core B的编译算法仅占40%的CPU内存。总的看来，CPU的占用率不高。
参考文献：
[1]关晓宁.基于嵌入式系统的数字信号处理平台的分析[J].科技致富向导，2012（30）.
[2]郑静菡，唱江华，刘树东，戴学丰.嵌入式下Linux系统设备驱动程序的开发[J].齐齐哈尔大学学报，2009（01）.
[3]袁俊杰，曹作良.基于Linux嵌入式系统开发平台的建立[J].天津理工大学学报，2006（03）.
作者简介：丽娜（1980.7-），女，辽宁阜新人，达斡尔族，讲师，研究生，研究方向：电子信息。