1、嵌入式中间件远程调试,DVEVM远程调试,使用特殊软件或硬件在宿主机上使用调试器对目标代码进行监控和排错 嵌入式系统特殊性：调试器和被调试代码不能同时运行在资源有限的目标平台 远程调试：指调试器运行的环境（宿主机） 与被调试的系统（目标机）在物理上是分离的，通过串口、USB口或以太网口进行连接调试。,嵌入式系统只能通过远程方式进行调试器与目标程序的交互。 硬件仿真器在同一时刻只能调试其中一个处理器的目标代码 采用远程调试技术是实现调试交互功能的有效解决方法。,GNU开源：GDB和DDD，远程调试功能。 单步执行目标平台程序代码 设置断点 查看内存 交互信息,DDD远程调试框架,远程调试中间件：
2、本地调试代理（GDB）和目标机调试存根（GDB Stub）组成 通过串口、USB或以太网口连接，使用GDB标准远程串行协议协同工作，实现对目标机上的系统和上层应用的监控和调试功能。 GDB Stub是运行在目标系统中的一段二进制代码，作为宿主机GDB和目标机调试程序间的一个媒介（中间件）存在,DDD远程调试框架图,DDD远程调试框架由两部分组成，分别运行在宿主机和目标机硬件平台 此处调试程序DDD与C/S框架的用户应用程序相对应，负责装入被调试的应用程序源码，并被调试提供图形界面 中间件GDB和Stub用来平滑宿主机和目标机的差别，依据协议在二者之间发出和接受控制和消息,中间件GDB把DDD的
3、控制和消息通过中间件Stub发送到调试组件使组件获得属性，然后把控制权交给调试组件 调试组件依据对象特征实施处理，并将处理结果通过中间件Stub不断反馈到调试程序DDD。 通过调试代理中间件GDB，调试程序DDD向调试组件对象发布属性并获取响应 这样调试程序DDD不必关心目标机的具体特征，就像调试本地目标代码一样访问目标机资源,GDB RSP协议,GDB RSP协议是一种基于消息的ASCII 码协议，制定了GDB宿主机与被调试目标机进行通信时数据包的格式 它定义读写数据的消息，控制被调试程序，并报告运行程序的状态 协议格式与相关内容见教材P154 消息正确返回响应数据或OK，否则是定义好的错误
4、码。,实现远程调试,目前嵌入式Linux系统有三种主要远程调试方法，分别适合不同场合的调试工作： ROM Monitor KGDB GDB-Stub/Server,最常采用的是GDB-Stub/Server方式调试应用程序 多数情况下，对于复杂的程序需要反复调试 进行远程调试，目标系统必须绑定GDB Stub（网络条件下是GDB Server）中间件，宿主机也必须配置GDB环境,设置宿主机GDB和DDD,一般Linux发行版都有一个可以运行的GDB 若要远程调试，需要简单配置和重新编译 GDB源码可以从http:/ftp.gnu.org/gnu/gdb下载,实现目标机调试中间件Stub,目标机
5、上Stub的基本功能是与主机GDB通信，实现读写内存，寄存器，stop，continue等调试命令。 目标机与主机通过硬件连接，被调试的二进制代码部分与Stub绑定，GDB与被调试部分通过RSP通信，根据Stub所处地位实现内核或应用等不同层次的调试。,内核层调试模型,初始化模块控制模块与主机GDB通信的具体流程如下所示。,应用层调试模型,在嵌入式Linux开发领域中调试应用程序常用的调试代理工具GDB-Server，调试模型如下图,嵌入式中间件示例：Codec框架,充分理解Codec框架可以使工程师只专注于个性化的Codec算法组件或者在嵌入式操作系统之上开发应用例程，特别对于后者更有帮助，
6、示意图如下：,从结构上看，它与前面的示例没有本质上的不同，唯一的区别是用了共享DDR内存作为两个处理器之间的通信信道，用DSP/BIOS Link实现会话层协议。,Codec框架由Codec引擎（CE）和Codec Server（CS）两部分组成。 提供了丰富的API、中间件和DSP算法组件供用户装配生成独立的个性化的CE和CS Codec框架包括一个不断扩充的算法组件组合，包括H.264,MPEG,JPEG以及其他视频、图像、语音编解码组件,Codec框架也支持用户自定义的算法组件，符合XDM规范或符合XDAIS规范的非XDM算法都可以容纳到Codec框架中 通过Codec引擎把达芬奇的DS
7、P端封装成一个黑匣子，为应用系统的开发者提供一个定制的流媒体开发平台 Codec引擎借助于一系列在嵌入式操作系统支持下的API，是开发者不必考虑有复杂的视频、图像、语音处理算法。,什么是Codec引擎,在Codec框架下应用程序像汽车驾驶员，通过引擎驾驶汽车完成各种不同的行驶任务 此时，Codec引擎是一个应用程序接口API的集合，用来演示和运行XDAIS算法。 它提供了一个VISA接口，使得应用系统开发者方便的调用那些符合XDM约定的XDAIS算法组件,设计Codec引擎的API应该能支持算法组件在本地或远端（DSP）运行 XDM是数字媒体的eXpress DSP算法接口标准，有时也称为XD
8、AIS-DM. XDM接口把Codec算法分成VISA等4类：视频，图像，语音，音频,为什么使用Codec框架,设计Codec框架是用来解决一些开发SoC应用常见的问题 不同类型的处理机环境，众多的调试器和复杂的单步跟踪方法 不同实现有不同的API，改成更有效的算法需要大量重新编码 两个处理器之间的复用性，用户可能想把算法导入一个新的DSP或新的GPP板上 DSP的复杂存储器管理和DSP实时问题,专注于理论研究的算法开发人员，希望新的算法改动可以更容易的纳入到系统，他们不愿为算法之外的代码修改付出任何努力 一个重要的问题是，所有这些开发任务是互相重叠的，有大量的工作可以重复利用,通过仔细规划上面这些复杂的开发任务，把其中对于特定处理器是稳定不变的，可以重复利用的任务固定下来分别组织成为应用程序接口API，系统程序接口SPI和中间件存根，骨架形成了Codec框架 在Codec框架下针对具体应用可以封装不同的Codec引擎，结合不同的DSP算法组件可以绑定成Codec Server,Codec引擎可以为执行算法组件提供标准的软件体系结构和接口 Codec引擎便于使用，应用程序开发者只要详细说明执行什么算法，而不需要说明怎样执行和哪里执行。 Codec可以扩展和配置，使用标准工具和技术可以为Codec框架添加新的算法 Codec引擎的基本结构如下图,GPP+DSP结构中Codec引擎,
