OMAPL138基于SYSLINK的双核通信LED实例（图文）

1  实例编译

光盘中demo/syslink/ex10_led实例实现了利用MCSDK的SYSLINK组件在ARM端控制DSP端来操作开发板外设LED执行跑马灯程序。本实例是基于ex03_notify增加DSP控制LED功能。 先按照广州创龙OMAPL138开发板的用户手册《基于OMAPL138的多核软件开发组件–MCSDK开发教程.pdf》安装MCSDK，配置、编译和安装SYSLINK。然后将ex10_led文件夹拷贝到虚拟机/home/tl/ti/syslink_2_21_01_05/examples目录下（该路径不可随意放置，否者无法包含到SYSLINK里面的头文件），然后进入ex10_led目录，如下图所示： 图1 执行“sudo make clean”清除编译生成文件，执行“sudo make”命令重新编译该例程，如下图所示： 图2 图3 在该目录的dsp/bin/debug/目录下生成.xe674格式文件server_dsp.xe674，如下图所示： 图4 在该目录的host/bin/debug/目录下生成Linux端可执行程序app_host，如下图所示： 图5

2  实例演示

执行此实例双核通信需要4个文件，syslink.ko、slaveloader、server_dsp.xe674和app_host。按照《基于OMAPL138的多核软件开发组件–MCSDK开发教程.pdf》教程完成SYSLINK编译和安装后，syslink.ko和slaveloader将位于开发板文件系统如下位置： syslink.ko：/lib/modules/3.3.0/kernel/drivers/dsp/syslink.ko slaveloader：开发板任意example的debug目录中，如/ex03_notify/debug/slaveloader。 以下为各个文件的作用： syslink.ko：双核通信驱动。 slaveloader：用于ARM端启动DSP并加载.xe674格式的SYS/BIOS文件，例如server_dsp.xe674。 server_dsp.xe674：DSP端应用程序。在此实例中，增加的DSP端控制LED流水灯功能的代码镜像就是server_dsp.xe674。 app_host：ARM端应用程序。 将以上编译出来的slaveloader、server_dsp.xe674、app_host和ex10_led中的run.sh拷贝到开发板同一个目录下，例如开发板的根目录： 图6 进入开发板的Linux文件系统后，执行如下命令安装双核通信驱动： Targert#      insmod/lib/modules/3.3.0/kernel/drivers/dsp/syslink.koTRACE=1TRACEFAILURE=1   图7 然后执行“./run.sh”命令，观察发现LED会先闪烁两次，再依次点亮所有LED，接着依次熄灭所有LED。 Target#        ./run.sh 图8 使用“cat run.sh”命令可以查看到run.sh脚本中的内容是： 图9 以下为脚本内容的解释： ./slaveloader startup DSP server_dsp.xe674：加载SYS/BIOS应用程序和启动DSP核。 ./app_host DSP：启动ARM端Linux应用程序。 ./slaveloader shutdown DSP：关闭DSP核。

3 实例解析

3.1   实例程序结构解析

在ex10_led目录中运行“tree -L 3”命令,可以看到实例程序目录的结构如下图所示： 图10 dsp：SYS/BIOS源代码。 host：ARM端Linux应用程序。 shared：ARM和DSP内存共享相关。 products.mak：makefile调用的配置文件，用于识别编译的头文件和库文件路径。

3.2   实例SYS/BIOS应用程序解析

dsp/main_dsp.c中创建了smain任务，smain任务会先执行Server_init()，如下图所示： 图11 Server_init()在dsp/Server.c中定义，Server.c是最常修改的SYS/BIOS文件。此实例在Server.c中增加了LED控制函数led_init()，如下图所示： 图12 dsp/Server.c中的led_init()函数实现了LED对应的GPIO的基本配置。在初始化配置时让4个LED连续闪烁2次，如下图所示： 图13 LED对应的GPIO相关寄存器定义如下图所示： 图14 SYS/BIOS的smain任务完成后会执行dsp/Server.c中的Server_create()函数。如下图所示： 图15 Server_create()函数在dsp/Server.c中定义，代码如下图所示： 图16 Server_create()函数会注册notify事件。当ARM端notify事件注册时，DSP会触发Server_notifyCB函数，接着执行dsp/Server.c中的Server_exec()函数。如下图所示： 图17 Server_exec()函数在dsp/Server.c中定义，该函数轮询等待ARM端发来的命令，其中Server_waitForEvent()是一种信号量等待方式，当ARM端有命令传送过来时会解除等待，然后解析ARM端传入的命令，解析命令代码如下图所示： 图18 从上图可以看出，ARM传到DSP并解析出来的是num和event两个变量。APP_CMD_ON_PAYLOAD将在下一章节解释。

3.3   实例Linux应用程序解析

host/main_host.c功能和dsp/main_dsp.c类似，它初始化SYSLINK，然后执行host/App.c中的App_create()函数注册notify事件，等待DSP端创建notify事件后,接着执行host/App.c中App_exec()函数。ARM端在App_exec()函数中向DSP发送控制LED的命令，代码如下： 图19 可以看出ARM端发送给DSP的命令有8个，分别是依次点亮4个LED，再依次熄灭4个LED。APP_CMD_ON_PAYLOAD和APP_CMD_OFF_PAYLOAD分别表示控制LED亮和灭，x分别为4个LED编号。控制状态和编号需要DSP端解析。所以APP_CMD_ON_PAYLOAD和APP_CMD_OFF_PAYLOAD是共享数据，其宏定义存放在shared/AppCommon.h中，如下图所示： 图20 APP_CMD_ON_PAYLOAD和APP_CMD_OFF_PAYLOAD宏是用户根据实际情况在shared/AppCommon.h中修改或者添加的，ARM端和DSP端都会使用到