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端都會使用到