宁波网站建设公司哪家最正规,装饰设计甲级资质,有赞商城商家版,html怎么做成网站针对当前应用的复杂性#xff0c;SOC芯片更好能能满足应用和媒体的需求#xff0c;集成众多接口#xff0c;用ARM做为应用处理器进行多样化的应用开发和用户界面和接口#xff0c;利用DSP进行算法加速#xff0c;特别是媒体的编解码算法加速#xff0c;既能够保持算法的灵…针对当前应用的复杂性SOC芯片更好能能满足应用和媒体的需求集成众多接口用ARM做为应用处理器进行多样化的应用开发和用户界面和接口利用DSP进行算法加速特别是媒体的编解码算法加速既能够保持算法的灵活性又能提供强大的处理能力。德州仪器TI继第一系列Davinci芯片DM644x之后又陆续推出了DM643xDM35x/36xDM6467OMAP35xOMAPLx等一系列ARMDSP或ARM视频协处理器的多媒体处理器平台。众多有很强DSP开发经验的工程师以及应用处理开发经验的工程师都转到使用达芬奇或OMAP平台上开发视频监控、视频会议及便携式多媒体终端等产品。基于ARMDSP的芯片架构如何进行开发实现做期望的嵌入式应用呢 传统的芯片基本是一个处理器内核或者是通用处理器如ARM或者是DSP。对于控制和用户接口一般用通用处理器实现算法处理或者媒体处理则依赖于DSP或者硬件芯片很多系统都是双芯片的架构。开发模式也比较单纯比如ARM芯片有ARM的的仿真工具基于OS之上进行应用开发DSP有DSP的开发工具如TI的CCS以及510、560的仿真器可以进行算法的移植、优化、跟踪、调试等。这时所需要的经验也比较单一。 基于ARMDSP的双核架构很多工程师不知道如何入手进行开发提出了很多的疑问比如对ARM工程师很困惑的是如何使用DSP的资源如何进行数据的交互如何保持双核之间的同步对DSP工程师则问到如何进行ARM调试如何启动DSP如果进行媒体加速如何操作外设获取或发送数据等。基于不同的开发经验和基础ARM工程师和DSP工程师会从完全不同的角度来看SOC的芯片以至于拿到SOC的芯片根本不知道如何入手这里就本人的经验与大家分享一下。 首先ARMDSP的芯片他是一个双核的对应ARM和DSP分别是不同的指令集和编译器可以把SOC的芯片看成是两个单芯片的合成需要两套不同的开发工具CCS3.3可以进行芯片级的调试和仿真但是对应ARM和DSP需要选择不同的平台。一般来说ARM上面跑操作系统比如LinuxWince等在ARM上的开发除了bootloader以外基本都是基于OS的开发比如驱动内核裁减以及上层应用等需要的调试和仿真主要靠log或者OS提供的调试器如KGDBPlatform Builder等。基于DSP核的开发和传统单核DSP一样需要用CCS仿真器来进行开发调试。 其次对于芯片的外设接口ARM核和DSP核都可以访问典型的情况是ARM控制所有的外设通过OS上的驱动去控制和管理这部分和传统的ARM芯片类似DSP主要是进行算法加速只是和memory打交道为了保持芯片的资源管理的一致性尽量避免由DSP去访问外设。当然根据具体的应用需求DSP也是可以控制外设接口进行数据的收发这时需要做好系统的管理避免双核操作的冲突。 对memory的使用非易失的存储空间比如NAND、NOR Flash基本也是由ARM访问DSP的算法代码作为ARM端OS文件系统的一个文件存在通过应用程序进行DSP程序的下载和DSP芯片的控制。外部RAM空间即DDR存储区是ARM和DSP共享存在的但是在系统设计的时候需要把ARM和DSP使用的内存严格物理地址分开以及预留出一部分用来交互的内存空间。一般情况ARM是用低端地址DSP通过CMD文件分配高端地址中间预留部分空间用来做数据交互比如在OMAP3的Linux下的DVSDK中128MB的DDR空间被分成三部分低端地址从0x8000000到0x85800000-1的88MB空间给Linux内核使用从0x85800000到0x86800000-1的16MB给CMEM的驱动用来做ARM和DSP的大块数据交互从0x86800000到0x88000000-1的24MB是DSP的代码和数据空间。 芯片的启动也是需要重点考虑的问题一般情况下是ARM启动和传统的单核ARM一样支持不同的启动方式比如可以支持NANDNORUARTSPIUSBPCI等接口启动。DSP默认处于复位状态只有通过ARM的应用下载代码并且解除复位以后DSP才能跑起来。有些应用场景需要DSP直接从外部上电就自启动有些芯片也是支持这种模式的。 最后关于芯片的通信和同步这个是困扰很多工程师的问题为了便于客户的开发和使用TI提供了DSPLINKCODEC ENGINE的DVSDK开发套件基于DVSDK可以很方便的进行ARMDSP的应用开发下面对DVSDK的软件架构各个软件模块的功能等做简要介绍。 DVSDK是多个软件模块的集成包括纯DSP端的软件模块ARM的软件模块和双核交互的软件模块 DVSDK的软件包都是基于实时软件模块Real-Time-Software-ComponentRTSC的还需要安装RTSC的工具XDCXDC是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/BIOSDSP的可执行代码需要包含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包含cmemSDMA等cmem是用来在OS之外分配连续物理内存空间进行物理地址到虚地址以及虚地址到物理地址空间转化的。为了避免数据的多次复制需要开辟一块ARM和DSP共享的数据空间ARM和DSP都可以直接访问这部分空间需要通过CMEM管理。对ARM来说CMEM是OS上的一个驱动程序需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间通过ARM传给DSP的指针必须是物理地址。 为了适配一些播放器的接口DVSDK还提供了DMAIDigital Media Application InterfaceDMAI提供了更为精简的媒体接口和基于OS的音视频捕捉、回放等接口在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。并且DMAI也提供了最基本的测试应用例子可以很方便的进行修改和测试。 如果只是调用现成的或者第三方的算法库可以只了解ARM端的软件模块Codec Engine或者DMAI已经提供了丰富的应用接口DSP可以认为是个单纯的媒体加速器把ARMDSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能就需要对DSP进行开发了。Codec Engine对DSP的算法只是规范了接口以便于和Codec Engine一起生成DSP的可执行程序。 开发DSP算法的工程师和传统的单核的DSP开发模式类似只需要操作DSP核基于CCS进行算法开发最后封装成xDM的接口就可以了。具体如何进行DSP的打包如何生成DSP的可执行程序在后续的文章继续讨论。 /dvsdk_3_00_01_42/codec_engine_2_24/examples/ti/sdo/ce/examples$ls apps buildutils codecs extensions servers 可以看到三个关键的目录apps,codecs,servers分别存放着应用程序代码算法代码算法服务代码。 codecs是不能单独成为程序的它是以库的形式供给servers,apps servers是dsp端可以运行的程序包括操作系统 apps是arm端linux操作系统下的一个应用程序。 参考网站http://www.61ic.com/Article/DaVinci/TMS320DM646x/201104/34242.html
