根据前几篇文章,一个
DM6446
的系统已经架构完成。但是有很多人都喜欢
TI
的机制,毕竟双核软件开发对很多工程师来说是非常麻烦的事情,既然
TI
提供开发套件和开发包,那么直接做
OEM
就可以了,底层的东西不需要关心很多,所以我们在这里开始讨论双核通信机制(包含
DSP SERVER
)。特别是
TI
提供
H.264
、
JPEG
、
MPEG4
、
G711
等算法调用例子,让很多系统集成工程师看到项目的希望。网上有很多朋友都介绍
DVSDK1.0
的
Codec
和
DSP SERVER
,他们都写得不错,本篇部分内容介绍也借鉴他们的,在此基础上重点介绍
dvsdk_2_00_00_22
,毕竟
TI
的
dvsdk
原理几乎都一样。
TI
有几个文档:
sprued5.pdf
、
sprued6.pdf
、
sprue67.pdf
和
spruec8b.pdf
,都是学习
Codec Engine
的不错资料。
一、dvsdk_2_00_00_22
介绍
在我们讨论
TI
Codec Engine
原理
之前,先检查大家安装的
dvsdk_2_00_00_22
,看看还有什么没有安装的,见下图。先让大家有个感性的认识,否则先讲
Codec Engine
原理的话,估计有不少人还没看完就兴致消失了。
dvsdk_2_00_00_22
是基于
TI EVM
的硬件平台的,有些朋友自己设计独创的
DM6446
板子,要利用
TI
Codec Engine
,就需要做很多移植工作,这是经验之谈。
本人在《
TI Davinci DM6446开发攻略――开发环境搭建
》里,也介绍一些基本软件包的安装,本人这里多装了一个低版本的
c6x code generation tools
,其实用
dvsdk_2_00_00_22
自带的
cg6x_6_0_23
就可以了。
dsplink-1_61_03-prebuilt_bk
是因为本人要编译
dsplink-1_61_03-prebuilt
,所以备份一下,防止出问题,其他
dvsdk_2_00_00_22
的软件包(
codec_engine_2_23_01
、
dvsdk_demos_2_00_00_07
,等等)都有原始备份,毕竟本人不是牛人,这些东西开始时不是非常熟悉,所以改动前都要备份一下,以便以后出问题进行比较和还原。根据
TI dvsdk_2_00_00_22
的
Codec Engine
要求,
local_power_manager_1_23_01
是要安装的,有些例子就需要这里边的
lpm_dm6446.ko
和
ocvc_dm6446.ko
。这些都可以通过
TI
的网站上下载(一个网友说得好:内事不决问老婆,项目不决问
google
!
)。
dvsdk_2_00_00_22
里每个软件包和工具包内都有文档介绍说明,见
dm6446_2_00_00_22_release_notes.html
的介绍(懒得连文档都不愿看的人或急功近利直接拿来的人,进步是不大的,除非是天才。中国有很多有天才资质的人,但在中国是不会出现天才的,所以,好好看文档吧,呵呵。),而
Rules.make
是一个很重要的文件,见《开发环境搭建》里有介绍。其中:
bios_5_33_06
:
是TI的DSP实时操作系统,本人下载比较新的版本。和C6x Code Generation Tools一样,这里的DSP/BIOS也是Linux环境下的版本。DSP系统工程师需要了解这个操作系统。
cg6x_6_0_23
:这个是
dsp
的交叉编译链,即在
linux
下生成可以在
c64
系列
dsp
上运行的程序;
codec_engine_2_23_01
:是
TI
机制的重点所在,
实现ARM和DSP或协处理器的协同工作
,以它为基础进行算法等开发。开发
codec_engine_2_23_01
前,如果你不是公认的牛人,请生成自己的
Codec Engine
例子的目录――
<CE_EXAMPLES_INSTALL_DIR>
,
e.g.
/usr/work/examples
,就是把
codec_engine_2_23_01/ examples
给
COPY
到你的工作目录,备份一下。
dm6446_dvsdk_combos_2_05
:
Codecs for both encoding and decoding H.264 and decoding MPEG2
。
玩H264的朋友就应该知道这个文件包的价值。
dmai_1_20_00_06
:里边有
Capture
,
Disaplay
,
V4L2
等内核驱动接口,
encode
,
ecode
,
encodedecode
这些例子调用这些驱动接口。
dvsdk_demos_2_00_00_07
:里边有
encode
,
ecode
,
encodedecode
的应用例子;
dvtb_4_00_08
:这是一个在
ARM
端运行,基于脚本语言的测试
codec
的应用程序。用户不需要写任何
C
代码就可以处理
Linux I/O, codec API
以及一些与线程有关的问题
;
dsplink-1_61_03-prebuilt
:
是实现ARM和DSP之间通信的底层软件,Codec Engine就是建立在这个底层软件之上。编译出来的
dsplinkko.ko
是
Codec Engine
E
基本元素之一。
edma3_lld_1_05_00
:里边包括
EDMA3
的低层驱动;
framework_components_2_23_01
:
是TI提供的一个软件模块,负责DSP侧的memory 和DMA资源管理。因此,DSP算法工程师需要了解这个软件模块。
linuxutils_2_23_01
:里边有
cmem.ko
,这个也是
Codec Engine
基本元素之一。
local_power_manager_1_23_01
:里边有
lpm_dm6446.ko
和
ocvc_dm6446.ko
,这个
ko
有些
DM6446
的例子是没有用到。但在
OMAP
的芯片中,
DVSDK3.0
基本上用到这个元素。
PSP_02_00_00_140
:里边包括TI提供的FLASH TOOL,UBL的BIN文件,UBOOT-1.2.0等源代码,audio,ccdc,gpio,V4L2的例子源代码。
xdais_6_23
:
是一个标准,它定义了TI DSP算法接口的标准。这样大大提高了DSP算法软件的通用性。DSP算法工程师要写出能被ARM通过Codec Engine调用的算法,必须保证自己的算法接口符合这个标准。因此,DSP算法工程师也必须了解这个软件模块。
xdctools_3_10_03
:XDC Tools和gmake类似,是用来编译和打包的工具,能够创建实时软件组件包RTSC(Real Time Software Component).与其他编译工具一样,它能根据源文件和库文件编译生成可执行文件。不同的是它能够自动的进行性能优化和版本控制。XDC还能够根据所提供的配置脚本语言产生代码,这一特性在编译如编解码器、服务器和引擎等可执行程序时尤为重要。XDC根据用户定义的一套build指令,通过调用用户指定的ARM 工具链(Tool Chain)和DSP编译器(C6x Code Generation Tools )build出ARM侧和DSP侧的可执行文件。可以先不必细究这个工具,只需通过编Codec Engine的例子,就知道如何设置build指令就可以了。有关XDC的用法,下面这段是参考一个网友的,本人放到这里,让大家更好去理解XDC。
XDC
的调用语法格式: XDC <target files> <XDCPATH> <XDCBUILDCFG>
target files: 指编译产生的目标文件。可以通过命令脚本来指定要产生哪些目标文件;
XDCPTH: 编译时所要查找的目录;
XDCBUILDCFG: 由"config.bld"文件指定,包含了与平台有关的编译指令。后面细说。
以上命令模式可能在参数过多是很复杂,通常把它写成shell脚本来运行。
与XDC相关的三个配置文件:package.xdc: 主要包含与包package有关的信息:依赖信息、模块信息、版本信息。由自己提供。package.bld: 主要作用是定义一个包应该如何被编译。文件内容用Javascript来描述。其中包含目标平台集的定义[MVArm9,Linux86]、编译版本的定义[release]、确定源文件集、生成的可执行文件信息等等。这两个文件都是在server目录下,可见每个codec都有自己的package信息描述文件,然后XDC根据再依之生成一个package包。config.bld: 这个文件处在codec_engine_##目录下,为各个codec所共有,它主要定义了与平台有关的特性,包含如下几部分:DSP Target、Arm Target、Linux Host Target、Build Targets、Pkg.attrs.Profile、Pkg.lib等具体信息。通常都是基于TI提供的模板对这三个配置文件做修改。
其实说这么多的
xdais
和XDC,我们先不用一下子就理解很透彻,TI提供的软件包example和工具包都帮我们设置好的,我们要做的就是修改makefile,
Rules.make,
xdcpaths.mak
,user.bld的工作。上面介绍的软件包工具包是开发Codec Engine必不可少的元素,如果要深入学习,得好好看
sprued5.pdf
、
sprued6.pdf
、
sprue67.pdf
和
spruec8b.pdf
。
二、TI DAVINCI
软件架构原理介绍
软件架构分为应用层、信号处理层和
I/O
层三部分,
TI
提供的达芬奇参考软件框架就是基于这样的结构,如下图。
Davinci
的应用工程师
可以在系统的用户空间在系统功能性上添加和发挥自己的特色。信号处理层通常都运行在
DSP
一侧负责信号处理,包括音视频编解码算法、
Codec Engine
、
DSP
的实时操作系统
DSP/BIOS
及和
ARM
通信的模块。
I/O
层就是我们通常所说的驱动,是针对
Davinci
外设模块的驱动程序。在
DAVINCI
系统中,
Davinci
的ARM是HOST,负责操作系统应用,
DSP
是协处理器,
负责运行音频视频
codec
算法处理,ARM通过TI的
Codec Engine
机制调用DSP侧的
codec
。
其中应用层通过
Codec Engine
的
VISA(Video, Image, Speech, Audio)API
来调用
DSP
侧的算法,通过
EPSI(Easy Peripheral Software Interface)API
来访问和操作
Davinci
的外设。这三个部分通常对应三个
Davinci
软件开发小组。当然还需要一个系统集成工程师把这三个部分集成起来,不过
VISA API
和
EPSI API
的存在已经大大简化了集成工作的复杂程度。
Codec Engine
是连接ARM和DSP或协处理器的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块。ARM应用程序调用
Codec Engine
的
VISA
(
Video, Image, Speech, Audio
)
API
,如下图中
VIDENC_process(a, b, c )
。
Codec Engine
的
stub
(ARM侧)会把参数
a, b, c
以及要调用
DSP
侧
process
这个信息打包,通过消息队列(
message queue
)传递到
DSP
。
Codec Engine
的
skeleton
(
DSP
侧)会解开这个参数包,把参数a, b, c转换成DSP侧对应的参数x, y, z(比如ARM侧传递的是虚拟地址,而DSP只能认物理地址),DSP侧的
server
(优先级较低,负责和ARM通信的任务)会根据
process
这一信息创建一个DSP侧的
process(x, y, x)
任务最终实现
VIDENC_process(a, b, c)
的操作。
要真正了解DM6446
软件架构,先从自己所处的角色说起,本人认为,开发
DM6446
软件一般分为:
双核系统集成工程师、ARM应用程序工程师、DSP算法工程师和DSP系统工程师。牛的人一般都兼职四个角色!
ARM
应用程序工程师:应用层开发设计
DSP
算法工程师:DSP算法设计
DSP
系统工程师:集成算法LIB和
DSP/BIOS
的
DSP Server
设计;
双核系统集成工程师:UBL、UBOOT、LINUX内核、根文件系统、设备驱动程序设计、总体系统集成。
每个角色的具体分工,可以看看
sprue67.pdf
。以下是一个网友提供的资料,
如图下图所示,
DaVinci
的软件开发通常需要四个步骤
(
本文以
codec
运行在
DSP
为例
)
:
软件系统分为应用层、信号处理层和
I/O
层三部分,达芬奇软件开发通常需要以上四个步骤。
第一步,
DSP
算法
工程师需要基于
DSP
利用
CCS
开发自己的音视频编解码算法,编译生成一个编解码算法的库文件
*.lib(
等同于
Linux
环境下的
*.a64P
,直接在
Linux
环境下修改文件后缀名即可
)
。如果要通过
Codec Engine
调用这个库文件中的算法函数,那么这些算法实现需要符合
xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)
标准;
Codec Engine
机制下不符合
xDM
标准的算法实现需要创建算法自己的
Stub
和
Skeleton(
具体请参考
spraae7.pdf)
。
第二步,生成一个在
DSP
上运行的可执行程序
*.x64P(
即
.out
文件
)
,也就是
DSP Server
。
第三步,根据
DSP Server
的名字及其中包含的具体的音视频编解码算法创建
Codec Engine
的配置文件
*.cfg
。这个文件定义
Engine
的不同配置,包括
Engine
的名字、每个
Engine
里包括的
codecs
及每个
codec
运行在
ARM
还是
DSP
侧等等
(
具体说明,请参考
sprue67.pdf
的第
5
章
Integrating an Engine)
。
最后,应用工程师收到不同的
codec
包、
DSP Server
和
Engine
配置文件
*.cfg
,把自己的应用程序通过编译、链接,最终生成
ARM
侧可执行文件。
三、利用
Codec Engine
进行自己的项目
如何利用Codec engine进行自己的项目呢?例子――TI提供的例子,会让你省掉很多复杂的过程,例子先给你个感性的认识,以后用多了,慢慢你就会了解xDAIS、xDM标准和XDC TOOL,xDM只是xDAIS的扩展。你要做的是修改
相应工具包、软件包里的
makefile,
Rules.make,
xdcpaths.mak
,user.bld,config.bld等等。我们就拿dvsdk_2_00_00_22\dvsdk_demos_2_00_00_07\dm6446\encodedecode
说事,因为这个例子调用
H.264
的
codec
。
首先确保以下关键元素可以编译通过:
dvsdk_2_00_00_22\codec_engine_2_23_01\examples
dvsdk_2_00_00_22\dm6446_dvsdk_combos_2_05
dvsdk_2_00_00_22\dmai_1_20_00_06
dvsdk_2_00_00_22\dsplink-1_61_03-prebuilt
dvsdk_2_00_00_22\dvsdk_demos_2_00_00_07\dm6446
dvsdk_2_00_00_22\linuxutils_2_23_01\packages\ti\sdo\linuxutils\cmem
编译通不过的原因就是相关的makefile,
Rules.make,
xdcpaths.mak
,user.bld没有修改好。请参考各个软件包的文档,比如
dvsdk_2_00_00_22/codec_engine_2_23_01/examples/build_instructions.html
等,怎么编译,是使用
make
,
gmake
还是
xdc
设置,文档都有介绍,如果要在这里都列出来,那太耗时间了。我们重点讲一下上面软件包的之间的关系,让大家进一步了解
Codec Engine
。
dvsdk_2_00_00_22\dsplink-1_61_03-prebuilt
里可以生产
dsplinkko.ko
,
dvsdk_2_00_00_22\linuxutils_2_23_01\packages\ti\sdo\linuxutils\cmem
里产生cmem.ko。
dsplinkko.ko,cmem.ko
这些在开发包里有,由于这些驱动编译时使用的内核和你的内核不一致,所以在目标板子上运行
encodedecode
的例子时,
insmod
会出错,你要以你的内核为准,重新编译这些驱动。
encodedecode
的例子会用到dm6446_dvsdk_combos_2_05里DSP Server的loopbackCombo.x64P,而这些codec 和 server就是建立在codec_engine_2_23_01的基础上的。encodedecode的例子调用linux内核驱动,是通过dmai_1_20_00_06。这样分析,大家应该对dvsdk_2_00_00_22有个比较全面的认识了,很多工作可以进行了。
经过一段时间看文档和实际摸索,终于调通
TI CODEC ENGINE
,这样就轻易调用
h.264
,
g711
音频的算法,在我们帮客户设计的硬件平台上,我们成功的帮组客户实现
TI
机制开发要求,这样客户基本上不用花太多时间就可以设计出自己的产品,加快产品上市时间。有关
Codec Engine
包括
DSP Server
,本文先介绍
DAVINCI
的双核通信机制,有关
DSP Server
的搭建,本人打算参考一个网友的文章,因为他写得很不错,他在
dvsdk_1.0
上介绍的,本人针对
dvsdk_2.0
对
DSP Server
的原理再添加点内容。
本人写文章,目的主要是给大家介绍开发方法,动手的还得大家自己去做,这样你个人能力才会有质的飞跃,一上来就加本人博客公告里的QQ,要这要那,本人觉得是一种很肤浅的行为。本人一再声明,QQ是谈生意和项目合作、技术支持的,是为客户服务的。写技术文章,就是培养一种技术氛围。技术氛围是一个很广泛的东西,没有这种良好氛围,科技就会发展很慢,浮躁急功近利的氛围,只有被动挨打,任人宰割。任何科技发明,科技创新,都需要良好的技术氛围。学习别人先进的东西,总会没错的,否则浮躁急功近利,只会变成实实在在的机器工人,而不是有思维、有创造力的人。