S698-T处理器的VxWorksARINC 429总线模块应用

摘要：ARINC429总线是航空专用总线，应用非常广泛。本文以S698-T处理器为平台，从底层驱动程序入手，详细讲述了针对S698-T处理器的VxWorks ARINC429总线驱动模块的应用与开发过程。给出了通过VxWorks VIP工程调用ARINC429驱动，完成数据收发的过程，可为后续的应用、开发工作提供帮助。

引言

VxWorks操作系统作为一种嵌入式实疾僮飨低(RTOS)，拥有高性能的内核以及友好的用户开发环境，发展为当今较流行的嵌入式系统。其应用遍布通信、国防、工业控制、医疗设备等多个嵌入式领域。

S698-T是珠海欧比特控制工程股份有限公司面向嵌入式控制领域而研制的一款高性能、高可靠的SoC芯片，以130 nm CMOS半导体工艺制造。S698-T芯片以高性能的SPARC V8(IEEE-1754)架构，标准的32位RISC整数单元IU为主控内核，配以IEEE-754标准的64位双精度浮点处理单元FPU。此外，S698-T内部还集成了1553B总线控制器、ARINC429总线控制器、CAN总线控制器、多功能I/O接口、UAR丁接口、在线硬件调试支持单元DSU、DAC模块、ADC模块等多种功能模块。

ARINC429总线协议是美国航空电子工程委员会(Airlines Engineering Committee)于1977年7月提出的，并于同年同月发表并获得批准使用。数字式信息传输系统DITS，规定了航空电子没备及有关系统间的数字信息传输要求。ARINC429广泛应用在先进的民航客机中，如B-737、B757、B-767等。ARINC429总线结构简单、性能稳定、抗干扰性强。最大的优势在于可靠性高，这是由于它非集中控制、传输可靠、错误隔离性好。

1 S698-T ARINC429驱动程序设计

ARINC429驱动基于VxBus模式进行开发，VxBus是在VxWorks中用于支持设备驱动的特有架构。VxBus在总线控制器驱动程序服务的支持下，能在总线上发现设备，并执行一些初始化工作，使驱动与硬件设备之间正常通信。它包括以下功能：

①允许设备驱动匹配对应设备;

②提供驱动程序访问硬件的机制;

③允许软件其他部分访问设备功能;

④在VxWorks系统中，实现设备驱动的模块化。

在VxWorks6.2版本发布前，设备驱动并不能被集成到VxWorks工程配置当中，为了添加或移出设备驱动，需要有丰富的BSP和驱动开发相关的知识。并且在驱动被添加或移出时要去做一些管理VxWorks工程的额外工作。作为VxWorks系统组件的一部分，VxBus消除了上面遇到的一些难题，各种驱动和支持组件的添加与删除完全可以在Workbench工程中进行，而不需要BSP和驱动相关的知识，也不会在添加、删除驱动时增加管理VxWorks工程的额外工作。因此大大方便了BSP的开发。

ARINC429驱动采用第三方驱动程序的组织方式，VxWorks允许驱动程序开发厂商和开发者创建第三方驱动程序，不需要担心不同厂商的文件之间的命名空间冲突。每一个想提供VxWorks驱动程序的厂商必须在3rdparty目录创建自己的子目录。

尽管一个驱动程序可以包括很多文件，比如多个源文件和多个头文件，但是一个标准的VxWorks驱动程序有一个最小的文件集，对于大多数VxWorks驱动程序最少要求6个文件，如表1所列。

一般情况下，CDF文件、dc文件、dr文件都被认为是驱动程序的配置文件，下面详细介绍这些文件。

1.1 驱动程序源文件

驱动程序源文件包含了驱动程序功能的实现逻辑，它们被放在目录installDir/vxworks-6.x/target/src/hwif，第三方驱动的源文件放在目录installDir/vxworks-6.x/target/3rdparty。很多VxWorks设备驱动程序只包含一个源文件，一个驱动程序可以包含一个或者几个可选的头文件;驱动程序可以包含多个源文件，此时必须在Makefile里面提供各个模块的依赖规则。下面以文件leon2obt429.c为例来说明VxWorks驱动程序的结构。

设备驱动程序的第一部分是一个描述VxBus初始化阶段要调用的例程的结构：

LOCAL struct drvBusFuncs leon2OBT429DrvFuncs={

leon2OBT429InstInit，

leon2OBT429InstInit2，

leon2OBT429InstConnect

};

接着就是描述驱动程序所支持的驱动方法的数据结构(每一种类别的驱动程序都必须实现该类的驱动方法)：

LOCAL device_method_t leon2OBT429Drv_methods[]={

{0，NULL}

};

然后描述该驱动程序需要的注册信息的结构：

LOCAL struCt vxbDevRegInfo lcon2OBT429DrvRegistration={

NULL， /*后续设备指针*/

VXB_DEVID_DEVICE， /*设备ID号*/

VXB_BUSID_PLB， /*总线ID号*/

VXB_VER_4_0_0， /*VxBus版本号*/

“leon2OBT429Dev”， /*驱动名称*/

leon2OBT429DrvFuncs， /*驱动入口函数指针*/

leon2OBT429Drv_methods[0]，/*设备方法组*/

NULL， /*设备探测*/

NULL /*默认参数*/

};

在注册信息后面，驱动程序必须提供一个例程来向VxBus注册，表明该驱动程序的存在：

void leon2OBT429DrvRegister(void){

/*驱动注册，此时不需要真正的硬件*/

vxbDevRegister((struct vxbDevRegInfo *)

leon2OBT429DrvRegistration);

}

由于驱动程序注册方法被当作是驱动程序的第一个入口点，VxWorks必须被配置成：当该驱动程序向VxBus注册时，VxWorks知道调用该入口点。为了做到这点，VxWorks使用的之前提到的那几个驱动配置文件：CDF文件、dc文件、dr文件。

1.2 CDF文件

CDF文件的全称是Component Description File，组件描述文件。根据VxBus标准开发的VxWorks设备驱动程序都被编译成一个单独的模块，可以使用VxWorks配置工具非常轻松地将驱动程序配置进BSP中。但是，必须为你的设备驱动程序创建一个VxWorks组件。

一个组件是一个基本的功能单元，它可以单独配置进入VxWorks内核镜像中。为了能够单独添加和删除设备驱动程序到VxWorks中，驱动程序必须能够被VxWorks配置工具识别成individual组件。为了让驱动程序能够在Workbench或者vxprj中是可以配置的，必须创建CDF文件，CDF文件提供VxWorks配置工具所需要的信息。针对风河公司发布的设备驱动程序，其对应的CDF文件位于以下目录：