QNX操作系统

 
　 　QNX是由加拿大QSSL公司（QNX Software System Ltd.）开发的分布式实时操作系统。该操作系统既能运行于以Intel X86、Pentium等CPU为核心硬件环境下，也能运行于以PowerPC、MIPS等CPU为核心的硬件环境。QNX操作系统符合POSIX基本标准和实时标准，使其应用可以方便的进行移植。

 

 

 

OMAP家族

OMAP L-1x

The OMAP L-1x parts are marketed only through catalog channels, and have a different technological heritage than the other OMAP parts. Rather than deriving directly from cell phone product lines, they grew from the video-oriented DaVinci product line by removing the video-specific features while using upgraded DaVinci peripherals. A notable feature is use of afloating point DSP, instead of the more customary fixed point one.

OMAP L-1x系列只通过产品目录渠道销售。与OMAP其他产品相比，OMAPL1-x系列采用了与众不同的技术。此类产品不是直接有手机生产线生产，而是由以面向视频需求的达芬奇生产线生产。它们在采用升级过达芬奇外设的同时，移除了特定视频功能。OMAPL1-x系列的一个显著特点是采用了浮点DSP运算器，而不是惯常的定点运算器。

DVSDK的软件架构
DVSDK是多个软件模块的集成，包括纯DSP端的软件模块，ARM的软件模块和双核交互的软件模块。 
DVSDK的软件包都是基于实时软件模块（Real-Time-Software-Component：RTSC）的，还需要安装RTSC的工具XDC，XDC是TI开源的一个工具，可以支持跨平台的开发，能够最大程度的代码重用；如果需要进行纯ARM的开发，还需要ARM的编译工具以及Linux内核或者Wince的BSP； 如果需要进行DSP的算法开发或者DSP端开执行代码生成，还需要安装DSP的编译器cgtools和DSP/BIOS； 为了便于配置生成DSP端的可执行代码，通过向导生成Codec的RTSC包和可执行代码，还可以选装ceutils和cg_xml。 
DVSDK的核心是Codec Engine，所有的其他软件模块基本都是围绕Codec Engine的。 
Codec Engine是连接ARM和DSP的桥梁，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块， 在编译DSP端可执行代码和ARM端应用程序时，都需要Codec Engine的支持。 
Codec Engine主要有两部分： 
 ARM端应用适配层，提供了精简的API和对应的库给应用层使用。 
 DSP的算法调用层，提供了DSP算法的接口封装规范，是的所有的算法通过简单的配置就可以编译到DSP的可执行程序中。 
最终的应用程序需要通过Codec Engine的API接口来下载DSP代码，调用DSP端的封装好的算法，以及进行ARM和DSP的通信。 
关于Codec Engine的介绍，可以参考《帮您快速入门Codec Engine》。 
Codec Engine底层ARM和DSP的通信是建立在DSP/BIOS Link之上的，DSP/BIOS Link真正实现ARM和DSP交互的软件模块。由于DSP/BIOS Link是跨平台的，也是有ARM部分和DSP部分组成，其中在ARM端，包括基于OS的驱动和供应用调用的库文件，DSP端，必须要用DSP/BIOS，DSP的可执行代码需要包含DSP/BIOS Link的库文件。DSP/BIOS Link常用的主要有如下几部分的软件模块： 
PROC相关的，主要是用来做DSP芯片的控制，比如启动，停止等，下载DSP的可执行代码，以及直接读写DSP端的memory空间等 

MSGQ相关，ARM和DSP的通信是基于MSGQ的，MSGQ有轮询等待的方式或者中断的方式， MSG是基于共享内存池的方式。Codec Engine通过MSGQ交互一些关键数据， 比如控制，和一些大块数据的地址指针等。大量的数据交互需要通过cmem实现。 
在ARM端，配合Codec Engine使用的软件模块有LinuxUtils或者WinceUtils，包含cmem，SDMA等， cmem是用来在OS之外分配连续物理内存空间，进行物理地址到虚地址，以及虚地址到物理地址空间转化的。为了避免数据的多次复制，需要开辟一块ARM和DSP共享的数据空间，ARM和DSP都可以直接访问， 这部分空间需要通过CMEM管理。对ARM来说，CMEM是OS上的一个驱动程序，需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间，通过ARM传给DSP的指针必须是物理地址。 
为了适配一些播放器的接口，DVSDK还提供了DMAI（Digital Media Application Interface），DMAI提供了更为精简的媒体接口基于OS的音视频捕捉、回放等接口， 在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。 并且DMAI也提供了最基本的测试应用例子，可以很方便的进行修改和测试。 
如果只是调用现成的或者第三方的算法库，可以只了解ARM端的软件模块，Codec Engine或者DMAI已经提供了丰富的应用接口， DSP可以认为是个单纯的媒体加速器，把ARM+DSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能，就需要对DSP进行开发了。Codec Engine对DSP的算法只是规范了接口，以便于和Codec Engine一起生成DSP的可执行程序。 开发DSP算法的工程师，和传统的单核的DSP开发模式类似，只需要操作DSP核，基于CCS进行算法开发，最后封装成xDM的接口就可以了。