分类： 嵌入式
2010-07-08 13:08:10
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://gs5689.blogbus.com/logs/35618716.html
编解码引擎CE和服务器CS之间的关系可以比作客户机和应用服务器之间的关系，本质上是远过程调用思想在双核上的实现。
1. 远过程调用(RPC)的工作原理
远过程调用最初是用在C/S架构上进行互操作的一种机制，是OS中进程间通讯在网络环境中的延伸。其目的是使得应用程序在调用另一个远程应用程序(在另外一个节点上，或本节点上的另一个进程中)时，采用与本地调用相同的调用方式，就像本地进行的调用过程一样,其过程如下：
1. 客户按本地调用的方式，直接调用本地的客户指代(stub),客户指代具有与服务器相同的过程接口;
2. 客户指代不进行任何逻辑处理，只是一个中介，因此它仅将客户的调用请求进行加工、打包，向低层通讯机制发出请求信息;
3. 客户端通过低层通讯机制将消息传送给服务器端的通讯机制;
4. 由于一个服务器节点上可能运行多个服务器程序，因此服务器端需要部分的解析消息，找出客户希望调用的服务器程序;
5. 服务器骨架(skeleton)对消息进行解析，从中获得调用者的参数，然后调用服务器程序;
6. 服务器程序执行相应的过程;（上面没有标出这一操作，其余步骤以此类推）
7. 服务器程序将结果返回给服务器骨架;
8. 服务器骨架将结果打包，向低层通信机制发出应答消息;
9. 服务器端通讯机制将消息传送给客户端通信机制;
10. 由于一个客户端节点上也可能有多个调用点，因此通信机制需要部分的解析返回的消息，找出消息应该返回给哪个应用程序，并将消息发送给对应的客户指代;
11. 客户指代从消息中解析出结果，返回给客户程序。
从上过程分析可见，RPC过程中客户指代的主要工作包括：
1. 建立客户与服务器之间的连接;
2. 将客户的高层调用用语句打包为一条低层的请求消息(RPC的编排)，然后向服务器发出请求信息;
3. 等到服务器返回应答消息;
4. 接收来自服务器的应答消息，并将来自低层的应答消息解析为可以返回的数据(RPC的还原);
5. 将返回值传送给客户指代。
对应服务器骨架也包含上述类似的功能。
2. 引擎与服务器的通讯框架
在ARM端，对视频类程序来说，应用程序首先把采集到的原始图像信号，通过VISA接口调用相关的Codec存根函数，由存根函数调用相关的Engine API函数，也就是SPI(service provider interface)接口，但由于实际的Codec算法在远端(DSP端)，所以必须由引擎把信号进行封装，通过OS抽象层与DSP Link通讯把打包后的数据发送出去。
当数据进入DSP端后，服务器上的算法实例(codec)接收到相关的数据信息，但这时的信息是被封装过的，必须由服务器骨架对数据进行解析，从中获得调用者的VISA接口参数，然后调用相关的xDM Codec实例，数据的返回方法与之相逆。在这个过程中，ARM端看做客户机，DSP端看做服务器，把server看做服务区骨架，codec看做服务区上的应用程序。
3. 引擎与服务器的通讯细节实例
这里分析一个实际的调用代码的过程。 在视频类程序中，一般是通过像VIDDEC_process(a,b,c)这样的VISA接口函数来调用远端算法的。对内部的工作细节是: 首先在应用程序(ARM端app.c)中调用VIDDEC_process(a,b,c)[ceapp_decodeBuf()调用VIDDEC_process(),这个调用只是客户端发送个接口信号]，这里首先是调用引擎上的Engine API,也就是服务提供者接口(SPI)VIDDEC_p_process(a,b,c)，从这可以看出在app.c中要有一次CERuntime_init()的调用。然后通过引擎CE的操作系统抽象层OSAL把参数a,b,c和调用信息VIDDEC_p_process()打包发送给DSPLink；然后通过DSPLink中转打好包的信息给DSP端的服务器骨架；最后服务器CS解析收到的信息包，由解析后的数据得知我们要调用VIDDEC_process()这一VISA API函数，并解析出所用参数为a,b,c[video_copy.c中调用VIDEC_TI_process(),这里的调用才是真正的远端服务器上执行算法]。从这可以看出在server在编译时，main.c需要调用一次CERuntime_init()。这一服务器骨架就知道如何调用本地(DSP端)的xDM算法以及其他方法了。这整个过程对用户来说是透明的，也就是说应用程序只需要调用Linux端的VISA API接口函数即可。接下来的内部工作由引擎CE和服务器CS来解决。数据从DSP端返回ARM端的过程与之相逆。
