SHARC阵列板的VMEBus通信分析与应用
1/2 12下一页尾页
2.3 Apex通信机制在单板机控制中的应用 一般来说，进行高强度运算的信号处理机都应该具有严格的工作时序，在每个工作时序进入相应的工作状态，这有利于其它分系统的相关处理以及信号处理机运算流程的合理安排。因此，对于信号处理机可以采取被动触发控制，即信号处理机完成当前工作时序之后向通信控制器提交下一工作时序请求，通信控制器可根据外部指令(通过网络)决定何时执行，这期间信号处理机应当处理阻塞状态等待回答。那么通信控制器可以利用Apex提供的第二类交互方式，作为服务端实时响应 SHARC的服务申请，并根据整体系统工作时序决定信号处理机的阻塞时间;同时，该方式提供每次4KB的传输量，可以用来下发工作参数和其它命令。这样既可避免繁琐的中断同步设置，又有利于软件的范也维护;而进行大指数据传输应当第一类方式。考虑到采取该方式缺乏握手机制，故应当在交互方式以及 VxWorks的多任务协调与约束下进行避免数据传输发生冲突与覆盖。 3 被动触发控制实现 3.1 阻塞式时序控制 要实现对信号处理机的被动触发控制，必须在通信控制器上建立面向SHARC阵列板的服务模块。Apex提供一个SHARC_system对象，所有的服务都基于该对象建立，包括Melbourne引导。该类中的成员函数SHARC_system::transaction的作用是初始化一个双向通信管道，客户端/服务端的交互通道都通过该通道进行。完成管道初始化之后，调用相应的成员函数SHARC_system::service_loop建立服务循环，如下面的程序所示： /*服务循环线程*/ int service_thread(SHARC_system *sys){ int status; printf(“service thread running...”); sys->service_loop(Timeout(ENVER));/*启动服务循环*/ sys->exit_status(%26;amp;status); /*退出服务循环*/ exit(status); return status; } 利用VxWorks的任务产生函数taskSpawn()，将service_thread服务循环派生成一个独立的线程来处理SHARC的申请。当 SHARC的程序退出后，通信控制器的循环也将自动终止。 由于服务端必须根据客户端提供的服务标签调用相应的服务，这就要求为SHARC_system类加载个人的服务程序。首先，定义系统标准类 Service_group的继承类Custom_group。然后，在这个类当中添加自己的成员函数，即通信控制器SHARC的服务程序;同时，再定义一个向量表table[]，将不同成员函数名称顺次列在其中编制成服务标签，如下所示： Custom_call Custom_group::table[]={ /*在向量表里添加服务标签，第一个对应的标签序号为0 (table[0]),第二个为1(table[1]),以后的以此类推*/ executCommand1, executCommand2， …… }; void Custom_group::executCommand1(Server_packet *pkt){ /*在这里用户写入自己的服务代码*/ } 当服务端接收到了申请后，会立刻自动调用Custom_group::call_service()。该函数的作用是读取服务标签号码，并从 table[]当中取出相应的客户服务程序执行它，如下所示： void Custom_http://www.ruishen.net.cn/电感器group::call_service(Server_packet *pkt){ int tag=MINOR_TAG(pkt->tag); /*读取申请包里的标签序号*/ if(tag>=0 %26;amp;%26;amp; tag<=MAX) /*判断服务标签是否在原先设定的范围内*/ { (this->*(table[tag]))(pkt); /*根据标签调用相应的服务*/ } …… } 此时可将需要下达的指令装载在回复包，当客户服务程序执行完毕之后，该回复包立刻被自动发送出去，因此，可在允许信号处理机进入下一工作时序的时候将客户服务程序返回。在Custom_group类当中可以添加各项控制服务项目，例如Melbourne开机/关机、工作参数下发等等。