[发明专利]BF561的双核协调工作方法

说明书

技术领域

本发明属于特定芯片上的双核软件协调工作方法。

背景技术

以单颗ADSP BF561@500MHz实现H.264 D1网络摄像(IPCAMERA)产品系统所需的嵌入式LINUX的主控系统、H.264 BP D1的视频实时编码和基于标准RTP的流媒体传输协议软件。根本原因缘自ADSP BF561的对称双核构架：正是由于ADSP BF561的这种对称双核构架，阻碍了它单芯片实现H.264 D1 IPCAMERA产品。双核我们称之为CORE A跟CORE B，CORE A只能用来跑嵌入式操作系统，我们采用的是嵌入式LINUX操作系统，而CORE B则是用来跑视频压缩编码算法(H.264)，用ADI提供的集成开发环境Visual DSP++来进行编译和运行测试。目前业界存在的问题是，CORE A运行的LINUX软件跟CORE B运行的VDSP编译出来的软件是不同的，彼此完全不兼容，跑嵌入式LINUX操作系统的CORE A是无法运行VDSP编译的软件的；而以CORE B单核提供的计算能力(MIPS)是远不能满足H.264 BP@D1实时编码的计算量的，除非另外一个核CORE A也能分担一部分编码的计算，但编码的算法软件是独立的VDSP编译出来的程序，CORE A的嵌入式LINUX操作系统是无法执行的。CORE A无法为CORE B分担视频压缩编码算法所需的大量的计算，造成双核负载的不均衡，使得系统实现失败，这便是问题的根本症结所在。问题的关键在于CORER A跟CORE B运行的软件完全不同，一个是基于LINUX操作系统下的应用软件，而另一个则是完全没有操作系统下的算法软件，彼此不兼容，所以不能互相分担任务。那么可以的尝试就不外乎解决这个兼容性问题，这个则又可归结到一个编译器的问题上，如果两边采用同样的编译器，则就可解决兼容性的问题。但无论嵌入式LINUX操作系统还是H.264视频编码算法都不是一套简单的软件系统，都非常复杂，更换编译器带来的编译问题、解决编译后的稳定性问题、性能损失问题等，都很多。下面的尝试均不可避免的遭遇这些难题。

CORE A采用嵌入式LINUX操作系统，编译器为GNU CC，简称gcc；CORE B的软件用VDSP编译，编译器为ADI提供的编译器。VDSP携带的编译器生成的代码效率要远远高于gcc生成的代码，所以，对于性能优化要求极高的视频压缩编码算法而言，采用VDSP编译环境才能获得最佳的性能。

尝试1：CORE A采用嵌入式LINUX操作系统，将H.264编码算法移植到嵌入式LINUX下面，整合到例如FFMPEG等软件里面去，采用gcc统一进行编译，则可统一由嵌入式LINUX操作系统进行控制以及视频压缩编码的计算。

这样做有两个最大的问题：

(1)嵌入式LINUX对B核的管理，因为这种方式由嵌入式LINUX统一管理双核，那其实就是一个对称多处理(SMP)系统，而SMP的实现需要对目前稳定的嵌入式LINUX操作系统做大量的改动，这个的实现难度太大，而且日后的稳定性不可保证；

(2)Gcc编译出来的H.264视频压缩算法的效率低下，比VDSP下生成的代码需要更多的MIPS来完成同样的工作，不可取。

鉴于此，目前此方法无一成功。

尝试2：CORE A采用嵌入式LINUX操作系统，但将其移植到VDSP环境下，用VDSP的编译器取代gcc来进行编译。这样，双核的软件统一在VDSP环境下统一编译，可实现相互调用。

这种方式存在的问题：

目前我司已可完成嵌入式LINUX内核在VDSP下的编译，并可下载到CORE A运行起来；但尚未解决对LINUX下应用程序(ELF-FLAT可执行文件格式)加载的难关，目前只能通过直接修改ELF-FLAT可执行文件的二进制文件的方式来加载最基本的init/shell等进程，而对于IPCAMERA产品所需的更多复杂的应用软件和协议软件则尚无法加载。

尝试3：CORE A采用更为精简的RTOS：uCOS-II，它已经由micrium公司完成对blackfin的移植支持，采用VDSP开发环境进行编译，已开放在其官方网站供下载，那么这种方式也是将双核的软件统一在VDSP下编译开发，则可顺利的实现软件的互通调用，并完成双核的负载均衡。

这种方式存在的问题：