現(xiàn)在我們的工作中，應(yīng)用程序一般都是和BSP聯(lián)編，然后將vxworks_rom.bin燒到班子里。在BSP啟動(dòng)后，調(diào)用應(yīng)用程序的函數(shù)的。

但是這樣有個(gè)問(wèn)題，就是應(yīng)用程序和BSP結(jié)合的太緊密了。BSP開(kāi)發(fā)者得將BSP代碼給應(yīng)用程序開(kāi)發(fā)者，或者應(yīng)用程序開(kāi)發(fā)者得將應(yīng)用程序編譯后的.a文件給BSP開(kāi)發(fā)者，才能完成程序的升級(jí)!

那么下面的方法是我這兩天弄出來(lái)的，可以將應(yīng)用程序和BSP開(kāi)發(fā)分離的一個(gè)辦法。只要開(kāi)始將接口約定好就可以了!還不是很成熟，我也還沒(méi)有正式在項(xiàng)目中使用，但是我相信這是一個(gè)不錯(cuò)的選擇!

首先，要建立一個(gè)文件系統(tǒng)，TFFS的文件系統(tǒng)就可以。磁盤(pán)大小只要可以放的下應(yīng)用程序編譯后的文件就好了。這步就不贅述了。

然后，在BSP工程的usrApp中添加下載應(yīng)用程序模塊和啟動(dòng)接口程序的代碼。下面主要說(shuō)明這步,代碼如下：

#include loadLib.h

#include stdio.h

#include taskLib.h

#include ioLib.h

extern SYMTAB_ID sysSymTbl;

void usrAppInit (void)

{

#ifdef USER_APPL_INIT

USER_APPL_INIT; /* for backwards compatibility */

#endif

FUNCPTR taskEntry=NULL;

SYM_TYPE *pType;

intfd=open(/tffs0/appProj.out,O_RDONLY,0);

if(fd==NULL)

{

printf(/nopen project fail../n);

return;

}

if(loadModule(fd,LOAD_ALL_SYMBOLS)==ERROR)

{

printf(/nload module fail.../n);

return;

}

if(symFindByName(sysSymTbl,appEntry,(char* *)taskEntry,pType)==ERROR)

{

printf(/nfind symbol fail.../n);

return;

}

taskSpawn(entry,100,0,1024,taskEntry,0,0,0,0,0,0,0,0,0,0);

/* add application specific code here */

}

主要代碼。只要應(yīng)用程序?qū)⑸?jí)后的工程編譯成.out文件，上傳到磁盤(pán)/tffs0中，就可以了!當(dāng)然，應(yīng)用程序的入口函數(shù)appEntry不能變。

最后，這段代碼如果之間運(yùn)行，可能會(huì)遇到一些問(wèn)題：

1.loadMoudle失敗，報(bào)錯(cuò)Relocation value doesnot fit in 24 bits。這是因?yàn)楹瘮?shù)在內(nèi)存中的位置超出了跳轉(zhuǎn)的最大距離(一般跳轉(zhuǎn)指令是24bit,32M).為了解決這個(gè)問(wèn)題，按如下步驟：

在應(yīng)用程序的工程中選擇Builds->default->c/c++complier,在后邊加入-mlongcall(GUN)或者-Xcode-absolute-far(diab)，點(diǎn)擊OK.

把這個(gè)編譯出來(lái)的.out文件上傳到文件系統(tǒng)。

2.symFindByName失敗。這個(gè)原因可能是因?yàn)閼?yīng)用程序的工程是cpp文件，也就是c++文件。c++編譯出來(lái)的文件，符號(hào)表的入口和C 不同，所以找不到。如，同樣的entry(void,int)函數(shù)，C編譯出來(lái)就是entry,而C++可能是entry_Fvi，這個(gè)由于不同的編譯器而不同。解決這個(gè)問(wèn)題，有兩個(gè)辦法：

(1).入口函數(shù)所在的文件，不要用cpp文件，全部改用c文件。

(2).cpp文件中的入口函數(shù)包含在external C {}中。