OMAPL138双核系统的调试方案设计

摘要：OMAPL138高性能、低功耗双核处理器为手持式移动设备提供强有力的支持。对双核通信模块DSPLink的软件架构和在Linux嵌入式操作系统下的编译加载进行了分析和介绍，以消息队列组件为例分析了ARM和DSP双核通信时通道的建立和连接的方式。通过DSP／BIOS和Linux端DSPLink的MSGQ接口和多线程技术，建立ARM和DSP消息传递通道，提供了在双核开发中对DSP端暗箱调试的解决方法。
关键词：OMAPL138；双核处理器；DSPLink；消息队列；调试

1 双核调试困难
双核芯片的推出为兼顾强大的数据处理能力和良好的用户体验提供了解决方案，将双CPU集成在一个芯片上也简化了硬件电路设计的难度。但是，双核开发增加了软件设计的难度。以往的ARM工程师与DSP算法工程师的明确分工已经不能适用于双核芯片的开发，需要在双核芯片的同步运行上提供一些解决方案。开发工程师在进行双核开发中会遇到调试方面的困难，以往的CCS和仿真器的调试方式已经不适用于双核环境下对DSP程序的调试。DSP端的程序运行，无法直观地提供调试信息给开发者，相当于一个“黑匣子”，以至于开发者无法获取DSP端寄存器和变量的变化情况。本文通过推出基于DSPLink软件模块的消息队列组件，使DSP调试信息通过ARM端应用程序打印。

2 双核通信理论
TI公司推出的OMAP体系结构与其推出的达芬奇结构有相似之处，OMAP体系开发套件与达芬奇套件有很大的相似性，而达芬奇处理器最具革命性的意义在于它的全平台开放。TI提供了全套开发套件，给工程师们在开发上提供了便利性和规范。开发套件中，基于双核通信的底层为DSPLink模块，为核心模块。
2．1 DSPLink双核通信构架
在OMAP体系中，芯片设计时，在片内分配一块RAM内存区域，是ARM和DSP都可以直接使用的共享内存区域。在小数据量的简单的控制信息通信时，可以直接使用片内的共享内存，通信速率也是最快的。同时还有将共享内存分配在片外的DDR，以便进行大数据量的传输。
DSPLink为TI针对双核通信的底层模块，在ARM端和DSP端具有相似的作用，在ARM端Linux嵌入式操作系统中作为Linux的内核模块存在，扮演着设备驱动的角色，通过驱动提供的众多上层API接口直接操作共享内存。在DSP端其连接的是TI推出的主要用于DSP的一款实时操作系统DSP／BIOS，同样作为驱动存在。采用DSPLink软件方法将物理层抽象出来，为硬件提供了十分优秀的拟合，使ARM和DSP在通信上实现无缝的链接。
DSPLink的软件构架如图1所示。

(1)在GPP端
GPP OS：在GPP端多采用操作系统，比较常用的是嵌入式操作系统Linux和WinCE，TI的DVSDK中有相关的支持。
OS抽象层：OS抽象层包含了DSPLink需要的一些通用的OS服务部件，通过此层使DSPLink可以不依赖特定的操作系统，从而可以利用接口特性更多地针对不同的操作系统使用，使开发者方便地移植到不同操作系统中。
Link Driver：GPP端的驱动层，该层提供了共享内存的GPP端的驱动。
Processor Manager：该层维护一个针对所有模块的Book-Keeping信息，通过API给用户提供通过Link Driver的控制操作。
DSP／BIOS Link：通过API可以脱离对底层的了解，直接操作共享内存，以实现通信。
(2)在DSP端
DSP Link Driver：Link Driver是DSP／BIOS中驱动的一部分，该部分驱动只负责基于物理连接之上与GPP之间的交互。
DSP／BIOS：DSP端的实时操作系统。
2．2 MSGQ通信搭建方法
双核通信的基本模式即是一方将所需要传输的数据放到共享内存中，通过中断的方式告知另一方。作为DSPLink中不同的通信模块，存在的不同只是对共享内存的组织方式不同。下面以MSGQ传输方式为例分析建立双核通信构架。
MSGQ表述消息队列方式，主要针对ARM和DSP端可变长度的短消息的交互，是基于DSP／BIOS的MSGQ模块实现的。消息的发送／接收都要以队列的方式进行。消息的发送者将消息发送入队列中，随后接收者从队列中将消息取出。每个消息队列只能有一个接收者，但是可以同时有多个发送者。在一个任务中，可以进行多个消息队列的读写。使用MSGQ进行数据传输还需要用到另外两个组件：
①PROC，在GPP应用中模拟DSP角色，控制DSP程序的载入、运行、停止。
②POOL，用于分配存储器缓冲区，将内存合理分块，使分配所需内存适合传输数据的尺寸。
利用这两个组件，将完成DSP程序的载入启动和内存池的分配。
MSGQ通信流程如图2所示。

GPP端按如下顺序开通消息队列：
①PROC_setup()。采用ARM端应用程序载入DSP程序到DSP中运行的方法启动DSP，由于PROC组件被用于模拟DSP，首先要针对PROC进行创建和初始化。
②PROC_attach(processorId，NULL)。在DSP端运行之前，需要建立与GPP端通信的DSP的关联，其中指定的processorId为与之通信的DSP的编号，防止ARM与多DSP通信时造成连接混乱。
③POOL_open(POOL_makePoolId(processorId，POOL_ID)，＆SamplePoolAttrs)。打开共享内存池，内存缓冲区同样需要一个ID来进行不同的分工。SamplePoolAttrs用来指定缓冲区大小、buffer个数等属性。
④MSGQ_open(SampleGppMsgqName，＆SampleGppMsgq，NULL)。在进行MSGQ通信之前的一个前提是处理器双方都需要各自打开一个消息队列，每个消息队列拥有各自的name，只有当连接方提出的name与消息队列的name相吻合的时候，消息队列才得到建立。利用该API打开消息队列，SampleGppMsgqName指代的是GPP端消息队列的name。
⑤PROC_load(processorId，(Char8*)＆imageInfo，numArgs，args)。将编译好的DSP程序载入DSP中，相关参数为DSP的编号、DSP可运行程序名字、参数的个数和运行参数。
⑥PROC_start(processorId)。开始运行编号为processorId的DSP。
⑦MSGQ_locate(dspMsgqName，＆SampleDspMsgq，＆syncLocateAttrs)。等待需要建立的消息队列打开。由于通信时需要将一条消息队列的两个端口都关联到指定的处理器，只有name为dspMsgqName的消息队列一边已经打开后，才能连接指定要连接的消息队列，该消息队列才真正建立起来，并进行通信。该接口函数与MSGQ_open相呼应。syncLocateAttrs为指定等待的相关属性，例如指定该属性为syncLocateAttr s．timeout=WAIT_FOREVER时，程序一旦运行到此函数处，如果另一方处理器还没有MSGQ_open的name为dspMsgqName的消息队列，便会阻塞在此处，直到打开为止。至此GPP端的消息队列已经完成设置，等待DSP端消息队列的建立。
DSP端按如下顺序开通队列：
①建立TASK任务。由于DSPLink是基于处理器两端操作系统进行的连接，因此，在DSP端同样必须采用操作系统作为通信的媒介，采用DSP／BIOS操作系统，以任务的形式运行程序。
②创建和初始化MSGQ传输属性。在进行MSGQ的创建打开之前，要先指定MSGQ的相关属性。
③MSGQ_open((String)dspMsgQName，＆info->localMsgq，＆msgqAttrs)创建DSP端消息队列，原理如同GPP端。
④MSGQ_locate(GPP_MSGQNAME，＆info->locatedMsgq，＆syncLocateAttrs)等待连接GPP端打开的消息队列，原理如同GPP端。
⑤当GPP和DSP端消息队列都建立完毕，并且关联，通信即建立，可以采用MSGQ_put和MSGQ_get发送和接收数据。

3 基于MSGQ双核调试方案
MSGQ组件在实际的应用中因其数据长度的可变性，对DSP端应用程序的调试提供了强大的解决方案。通过MSGQ的分析可以发现，采用ARM和DSP端联合，通过log打印的方式可以方便地对DSP端的运行情况进行一定的了解。
在GPP端和DSP端应用程序中建立独立线程和任务。由于只需要将DSP信息传输到GPP端而不需要GPP端的反馈信息，因此只需要设计单向传输，创建一条消息队列即可。当DSP端运行到需要打印的信息时，将消息暂存于指定的内存空间，当任务切换到调试任务时，将暂存的消息发送到GPP端，GPP端接收到消息后在终端打印。调试建立流程如图3所示。