CN116737420A - 基于操作系统的1553b总线通信方法 - Google Patents

Abstract

本发明提供了一种基于操作系统的1553B总线通信方法，包括：通过标准I/O接口open打开操作系统已注册的1553B总线设备，完成硬件初始化；通过标准I/O接口ioctl配置1553B总线芯片和软件工作模式；内核抽象层和驱动层通过1553B总线数据帧接收队列和发送队列进行数据缓存交互；通过标准I/O接口write将数据帧写入设备，内核抽象层通过发送队列将其传递给驱动程序处理；驱动层将传输反馈信息填入数据帧，通过接收队列传递给内核抽象层，再通过标准I/O接口read返回。从而实现了在操作系统环境下1553B总线驱动程序的通用化设计，降低了应用程序的开发周期和难度，提升了软件开发效率。

Description

基于操作系统的1553B总线通信方法

技术领域

本发明涉及通信技术领域，具体地，涉及一种基于操作系统的1553B总线通信方法。

背景技术

MIL-STD-1553B是一种数字式时分制串行数据总线，具有高可靠、抗干扰能力强、灵活、速率较高、扩充和维护简便等特点，因而被广泛应用于国内外航空和航天电子系统的通信网络的设计中。1553B总线的传输协议为命令/响应方式，数据传输的最小单位为“消息”，所有的消息传输均由BC(总线控制端)发出命令，RT(远程终端)响应。

随着国内外高性能、高可靠处理器技术的不断发展，传统的单机软件开发模式已不能满足日渐复杂的系统软件的开发要求。操作系统因支持多任务并发、对硬件统一管理和夸平台可移植性好等优势，而被广泛应用在嵌入式计算机控制系统中。

基于操作系统开发的1553B总线通信软件由底层驱动和上层应用程序组成，通过驱动程序实现对底层硬件实现细节的隐藏和封装，应用程序通过操作系统提供的标准I/O接口，实现对硬件设备的操作控制。由于目前不同型号任务1553B总线应用层通信协议不尽相同，消息传输类型繁多，BC和RT等不同的工作模式差异大，RT模式只能被动响应等因素，对基于操作系统平台的1553B总线底层驱动软件通用化和抽象化设计带来很多困难。

因此，设计一种基于操作系统平台的通用1553B总线通信软件，可以满足BC和RT处理各类应用层通信协议通信要求，且适用于各类操作系统设备驱动模型，成为了现今航空、航天嵌入式系统开发亟需解决的问题。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种基于操作系统的1553B总线通信方法。

第一方面，本申请实施例提供一种基于操作系统的1553B总线通信方法，包括：

步骤1：应用程序通过标准I/O接口open打开已注册到设备驱动表中的1553B总线设备，并通过驱动程序对应的设备打开接口函数完成初始化工作，所述初始化工作包括：中断配置和中断服务子程序绑定；

步骤2：应用程序通过标准I/O接口ioctl配置1553B总线芯片和软件工作模式，并通过驱动程序对应的设备控制接口函数根据传入的自定义的ioctl命令进行相应的软硬件状态设置；

步骤3：驱动程序内核抽象层和驱动层通过1553B总线数据帧接收队列和发送队列进行数据缓存交互；其中，在数据帧结构中包含总线消息传输的各类属性；

步骤4：应用程序根据需要构造的数据帧结构作为输入参数，通过标准I/O接口write写入设备；驱动程序对应的内核抽象层设备写入接口函数尝试将传入的数据帧逐帧添加入发送队列，并启动驱动层消息处理流程；若发送队列满，则挂起等待；在驱动层消息处理时，从发送队列中逐帧取出数据帧解析并处理；

步骤5：应用程序通过标准I/O接口read读取总线传输结果，解析返回的数据帧结构并处理；驱动程序对应的内核抽象层设备读取接口函数尝试从接收队列中取出数据帧返回给应用程序；若接收队列为空，则挂起等待；当总线消息传输结束产生中断时，驱动层读取接收数据或反馈信息，写入数据帧结构并添加入接收队列中。

可选地，当1553B总线芯片配置成工作在BC模式时，不论发送还是接收消息，应用程序根据消息控制信息构造数据帧后，通过标准I/O接口write传递给驱动程序处理；再通过标准I/O接口read读取消息传输结束反馈信息。

可选地，所述步骤2包括：

在BC模式下，应用程序通过ioctl将1553B总线工作模式设置为BC模式；

当消息传输结束产生中断时，驱动程序判断当前为BC模式，并根据消息类型进行BC中断服务子程序处理。

可选地，所述步骤4包括：

当BC应用程序需要控制消息传输时，不论是发送还是接收，先构造数据帧结构，再通过标准I/O接口write传递给驱动程序处理；

BC驱动层消息处理时，从发送队列取出一帧数据，根据数据帧中的消息属性构造相应的消息缓存结构和消息描述符，并启动消息传输。

可选地，所述步骤5包括：

BC中断服务子程序处理时，先判断中断类型，若是发送结束中断，则读取消息传输反馈状态；

若是接收结束中断，则继续读取RT返回的数据，一起写入数据帧结构后添加到接收队列中，返回给应用程序；

尝试从发送队列中取出一帧数据继续处理，依次循环，直到发送队列为空为止。

可选地，当1553B总线芯片配置成工作在RT模式时，应用程序需根据1553B总线应用层协议通过ioctl命令配置各子地址控制字和查找表。

可选地，所述步骤2包括：

在RT模式下，应用程序先通过ioctl将1553B总线工作模式设置成RT模式，再通过ioctl按照应用层协议配置各子地址控制字和查找表，驱动程序完成相应的硬件配置，并记录各子地址配置信息；

当消息传输结束产生中断时，驱动程序判断当前为RT模式，并根据子地址配置信息进行RT中断服务子程序处理。

可选地，当1553B总线芯片配置成工作在RT模式并完成各子地址配置后，作为总线响应端，不论是接收还是发送消息，应用程序先通过调用标准I/O接口read获取驱动返回的消息传输结束信息再做处理；

若是数据发送结束，则更新相应的子地址的下一周期的参数；

若是数据接收结束，则从数据帧中读取接收的数据内容并处理。

可选地，所述步骤4包括：

当应用程序更新发送子地址缓存区数据时，构造数据帧格式，调用标准I/O接口write写入设备；

当驱动层从发送队列取出数据帧解析并处理时，仅更新相应的RT子地址发送缓存区数据。

可选地，所述步骤5包括：

RT中断服务子程序处理时，先判断中断类型；

若是发送结束中断，则读取消息命令字；

若是接收结束中断，则继续读取接收的消息数据，一起写入数据帧结构后添加到接收队列中，返回给应用程序。

第二方面，本申请实施例提供一种基于操作系统的1553B总线通信设备，包括：处理器和存储器，所述存储器中存储有可执行的程序指令，所述处理器调用所述存储器中的程序指令时，所述处理器用于：

执行如第一方面中任一项所述的基于操作系统的1553B总线通信方法的步骤。

第三方面，本申请实施例提供一种计算机可读存储介质，用于存储程序，所述程序被执行时实现如第一方面中任一项所述的基于操作系统的1553B总线通信方法的步骤。

与现有技术相比，本发明具有如下的有益效果：

本申请提供的基于操作系统的1553B总线通信方法，解决了因不同型号应用层通信协议的不同和BC与RT工作模式的差异而导致操作系统底层驱动难以通用化设计的难题。通过驱动程序对1553B总线通信处理过程的标准化和通用化的抽象封装，隐藏了底层硬件实现细节，满足BC和RT处理各类1553B总线应用层通信协议要求，适用于各类操作系统设备管理模型，可以方便快捷的实现软件夸平台移植。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种基于操作系统的1553B总线通信方法的流程示意图；

图2为本申请实施例提供的数据帧传输过程示意图；

图3为本申请实施例提供的驱动程序BC中断处理流程示意图；

图4为本申请实施例提供的驱动程序RT中断处理流程示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，当组件被称为“固定于”另一个组件，它可以直接在另一个组件上或者也可以存在居中的组件。当一个组件被认为是“连接”另一个组件，它可以是直接连接到另一个组件或者可能同时存在居中组件。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面以具体地实施例对本发明的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

本申请实施例提供一种基于操作系统的1553B总线通信方法，包括：

步骤1：应用程序通过标准I/O接口open打开已注册到设备驱动表中的1553B总线设备，并通过驱动程序对应的设备打开接口函数完成初始化工作，初始化工作包括：中断配置和中断服务子程序绑定。

步骤2：应用程序通过标准I/O接口ioctl配置1553B总线芯片和软件工作模式，并通过驱动程序对应的设备控制接口函数根据传入的自定义的ioctl命令进行相应的软硬件状态设置。

本实施例中，当1553B总线芯片配置成工作在BC模式时，不论发送还是接收消息，应用程序根据消息控制信息构造数据帧后，通过标准I/O接口write传递给驱动程序处理；再通过标准I/O接口read读取消息传输结束反馈信息。

示例性的，可以选择上海航天电子技术研究所基于北京翼辉科技有限公司SylixOS内核授权的一款大型嵌入式实时操作系统AIC-OS(风云翼辉操作系统)作为本实施例方法中的操作系统，并在搭载具备BC和RT模式的1553B总线接口芯片(如BU61580)的计算机硬件平台首先完成AIC-OS的移植。

示例性的，步骤2中，在BC模式下，应用程序通过ioctl将1553B总线工作模式设置为BC模式；当消息传输结束产生中断时，驱动程序判断当前为BC模式，并根据消息类型进行BC中断服务子程序处理。

本实施例中，当1553B总线芯片配置成工作在RT模式时，应用程序需根据1553B总线应用层协议通过ioctl命令配置各子地址控制字和查找表。

示例性的，在RT模式下，应用程序先通过ioctl将1553B总线工作模式设置成RT模式，再通过ioctl按照应用层协议配置各子地址控制字和查找表，驱动程序完成相应的硬件配置，并记录各子地址配置信息；当消息传输结束产生中断时，驱动程序判断当前为RT模式，并根据子地址配置信息进行RT中断服务子程序处理。

步骤3：驱动程序内核抽象层和驱动层通过1553B总线数据帧接收队列和发送队列进行数据缓存交互；其中，在数据帧结构中包含总线消息传输的各类属性。

步骤4：应用程序根据需要构造的数据帧结构作为输入参数，通过标准I/O接口write写入设备；驱动程序对应的内核抽象层设备写入接口函数尝试将传入的数据帧逐帧添加入发送队列，并启动驱动层消息处理流程；若发送队列满，则挂起等待；在驱动层消息处理时，从发送队列中逐帧取出数据帧解析并处理。

示例性的，当BC应用程序需要控制消息传输时，不论是发送还是接收，先构造数据帧结构，再通过标准I/O接口write传递给驱动程序处理；BC驱动层消息处理时，从发送队列取出一帧数据，根据数据帧中的消息属性构造相应的消息缓存结构和消息描述符，并启动消息传输。

示例性的，当1553B总线芯片配置成工作在RT模式并完成各子地址配置后，作为总线响应端，不论是接收还是发送消息，应用程序先通过调用标准I/O接口read获取驱动返回的消息传输结束信息再做处理；若是数据发送结束，则更新相应的子地址的下一周期的参数；若是接收结束，则从数据帧中读取接收的数据内容并处理。

本实施例中，当应用程序更新发送子地址缓存区数据时，构造数据帧格式，调用标准I/O接口write写入设备；当驱动层从发送队列取出数据帧解析并处理时，仅更新相应的RT子地址发送缓存区数据。

步骤5：应用程序通过标准I/O接口read读取总线传输结果，解析返回的数据帧结构并处理；驱动程序对应的内核抽象层设备读取接口函数尝试从接收队列中取出数据帧返回给应用程序；若接收队列为空，则挂起等待；当总线消息传输结束产生中断时，驱动层读取接收数据或反馈信息，写入数据帧结构并添加入接收队列中。

示例性的，BC中断服务子程序处理时，先判断中断类型，若是发送结束中断，则读取消息传输反馈状态；若是接收结束中断，则继续读取RT返回的数据，一起写入数据帧结构后添加到接收队列中；尝试从发送队列中取出一帧数据继续处理，依次循环，直到发送队列为空为止。

示例性的，RT中断服务子程序处理时，先判断中断类型；若是发送结束中断，则读取消息命令字；若是接收结束中断，则继续读取接收的消息数据，一起写入数据帧结构后添加到接收队列中。

图1为本申请实施例提供的一种基于操作系统的1553B总线通信方法的流程示意图，如图1所示，本实施例中的方法可以包括如下步骤：

步骤S1：应用程序通过标准I/O接口open打开已注册的1553B总线设备；对应的驱动程序注册的“设备打开”接口函数完成中断配置和中断服务子程序绑定等基本初始化工作。

示例性地，应用调用fd＝open(“/dev/bus1553B”,O_RDWR)；驱动程序对应的“设备打开”接口函数完成处理器连接1553B总线芯片中断引脚连接的外部中断的配置，并使能相应的中断向量。

步骤S2：应用程序根据1553B总线应用层协议，通过标准I/O接口ioctl进一步详细配置1553B总线芯片和软件工作模式等；驱动程序根据传入的自定义的ioctl命令进行相应的软硬件状态设置。

示例性地，例如，1553B总线要配置成BC模式，则应用程序调用ioctl(fd,_1553_DEV_SET_MODE,BC_MOD)；驱动程序对应的“设备控制”接口函数解析传入的命令为_1553_DEV_SET_MODE(宏定义)，继续解析传入的参数，将当前总线芯片工作模式配置成BC模式并记录模式状态。

可选地，上述方法还包括：应用程序可以通过自定义的ioctl命令与驱动程序约定任意设备控制操作，可以带输入和返回参数，也可以不带参数，包括(但不限于)寄存器的默认配置、获取硬件RT地址、RT子地址的配置、模式码配置、消息结束字配置和设备复位操作等；应用程序只需传入控制参数，具体的硬件操作由驱动程序实现。

步骤S3：在设备注册初始化时，驱动程序内核层首先完成1553B总线数据帧接收队列和发送队列的初始化操作，队列缓存大小由设备注册时传入的参数指定。所有的数据帧均从队列尾入列、从队列头出列。

步骤S4：当1553B总线配置成BC模式时，BC应用程序需要控制消息传输时，不论是发送还是接收，均首先构造数据帧结构，然后通过标准I/O接口write传递给驱动程序处理；BC驱动程序从发送队列取出一帧数据，根据数据帧中的消息属性构造相应的消息缓存结构和消息描述符，并启动消息传输。

示例性地，如BC应用程序需要通过A总线从RT地址1的子地址3获取32字的参数时，应用程序将这些参数写入数据帧中：

bus1553_frame.msgChannel＝CHANNEL_A；

bus1553_frame.rtAddr1＝1；

bus1553_frame.rtSubaddr1＝3；

bus1553_frame.msgType＝RT_BC；

bus1553_frame.dataLen＝32；

bus1553_frame.msgStatus1＝0；

然后调用标准I/O写数据接口函数size＝write(fd,&bus1553_frame,sizeof(FRAME_1553DATA))；内核层驱动获取写入的数据帧后，将其加入发送队列中，并启动消息处理；驱动层消息处理时，从发送队列中取出该帧数据，解析传入的参数，构造RT->BC类型消息格式，并在消息堆栈中构造消息命令字，最后启动消息传输。

步骤S5：当1553B总线配置成BC模式时，当BC应用程序写入一帧消息控制信息后，就读取一帧反馈信息；当消息传输结束产生中断时，BC中断服务子程序首先判断中断类型，如果是发送结束中断，则读取消息传输反馈状态，如果是接收结束中断，继续读取RT返回的数据，一起写入数据帧结构后添加到接收队列中；最后尝试从发送队列中取出一帧数据继续处理，依次循环，直到发送队列为空为止。

示例性地，继续上述步骤S4中的例子，BC应用程序接着调用标准I/O读数据接口函数size＝read(fd,&bus1553_frame,sizeof(FRAME_1553DATA))；获取总线传输反馈信息。由于此时接收队列为空，内核层驱动读设备数据任务阻塞等待。当该消息传输结束产生中断时，BC中断服务子程序判断是接收数据类型中断，按照RT->BC的消息类型的格式，从对应的消息缓存区中读取返回的32字的数据和反馈状态字，写入数据帧添加到接收队列中，并唤醒等待接收队列不为空的线程，然后继续尝试获取发送队列中的数据。由于此时发送队列为空，则消息处理流程结束。内核层读设备数据任务被唤醒后，从接收队列中获取一帧数据，并返回给应用程序。图2为本申请实施例提供的数据帧传输过程示意图；图3为本申请实施例提供的驱动程序BC中断处理流程示意图；具体过程参见图2、图3。

需要说明的是，以上示例仅是BC工作模式中的一种消息处理流程，其余消息类型处理流程与此类似，不再重复赘述。本发明同时还支持将1553B总线配置成工作在RT模式，对上述存步骤中两种工作模式存在差异的环节进一步通过示例说明。

可选地，当上述步骤S2将1553B总线芯片配置成RT模式时，应用程序接着通过ioctl接口按照应用层通信协议配置各RT子地址信息；驱动程序解析输入的命令参数并完成子地址控制参数配置，并且记录所有子地址配置信息。

示例性地，RT应用软件初始化时，通过ioctl接口将RT发送子地址2配置成32字单消息结束中断，查找表指向0x400起始的缓冲区；将RT接收子地址4配置成128字循环缓冲结束中断，查找表指向0x480起始的缓冲区。

可选地，步骤S4包括：当RT应用程序需要更新发送子地址缓冲区数据时，首先构造数据帧结构，然后通过标准I/O接口write传递给驱动程序处理。驱动层消息处理时，从发送队列取出一帧数据，确定是发送子地址类型时，查找初始化时记录的该子地址查找表和控制字信息，然后将数据帧中的数据写入对应的子地址总线缓存区中。

示例性地，继续上述步骤所述RT模式示例，在RT应用软件初始化时，将发送子地址2信息及待发送数据写入数据帧结构中：

bus1553_frame.rtSubaddr1＝2；

bus1553_frame.msgType＝RT_BC；

bus1553_frame.dataLen＝32；

bus1553_frame.msgData＝txBuf；

然后调用标准I/O写数据接口函数size＝write(fd,&bus1553_frame,sizeof(FRAME_1553DATA))；内核层驱动获取写入的数据帧后，将其加入发送队列中，并启动消息处理；驱动层消息处理时，从发送队列中取出该帧数据，解析传入的参数为RT->BC发送类型，读取数据帧格式中32字的数据，写入RT发送子地址2配置的0x400起始的缓冲区中。

可选地，步骤S5包括：RT应用程序不停的读取消息传输结束信息，然后根据读取的子地址传输结束信息做后续处理；RT中断服务子程序处理时，首先读取消息命令字判断中断类型，如果是发送结束中断，则将消息命令字写入数据帧结构中，如果是接收结束中断，则继续读取接收的消息数据，一起写入数据帧结构后添加到接收队列中。RT中断服务子程序处理流程如图4所示。

示例性地，继续上述步骤所述RT模式示例，RT应用程序在完成初始化流程后，一直调用size＝read(fd,&bus1553_frame,sizeof(FRAME_1553DATA))；获取消息结束中断信息。当RT应用程序读到的帧信息是发送子地址2时，接着跟新下一帧数据，并再次通过标准I/O写数据接口函数write写入设备；当RT应用程序读到的帧信息是接收子地址4时，继续读取返回的32字数据内容，并继续读接下来的3帧数据，构成一个完整的128字的数据包。当RT子地址2数据传输结束产生中断时，RT中断服务子程序将该子地址命令字写入数据帧中并添加到接收队列中；当RT接收子地址4收到128字数据并产生循环缓冲中断时，RT中断服务子程序读取消息命令字判断是接收子地址2，根据子地址配置信息，首先重置循环缓冲指针，接着从0x480起始的地址分4次每次读取32字构造4个数据帧，并依次添加到接收队列中。

本实施例配置的1553B总线驱动软件可以适用于BC和RT等不同的工作模式，通过驱动程序的抽象和标准化处理，实现了底层硬件操作的统一。在本发明提供的驱动程序的基础上开发应用软件与单机软件平台的1553B总线通信软件设计思路和处理流程高度一致，可以方便快捷的实现软件夸平台移植。

需要说明的是，所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“平台”。

此外，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当用户设备的至少一个处理器执行该计算机执行指令时，用户设备执行上述各种可能的方法。其中，计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于用户设备中。当然，处理器和存储介质也可以作为分立组件存在于通信设备中。

本申请还提供一种程序产品，程序产品包括计算机程序，计算机程序存储在可读存储介质中，服务器的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得服务器实施上述本发明实施例任一的方法。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (8)

1.一种基于操作系统的1553B总线通信方法，其特征在于，包括：

步骤1：应用程序通过标准I/O接口open打开已注册到设备驱动表中的1553B总线设备，并通过驱动程序对应的设备打开接口函数完成初始化工作，所述初始化工作包括：中断配置和中断服务子程序绑定；

步骤2：应用程序通过标准I/O接口ioctl配置1553B总线芯片和软件工作模式，并通过驱动程序对应的设备控制接口函数根据传入的自定义的ioctl命令进行相应的软硬件状态设置；

步骤3：驱动程序内核抽象层和驱动层通过1553B总线数据帧接收队列和发送队列进行数据缓存交互；其中，在数据帧结构中包含总线消息传输的各类属性；

步骤4：应用程序根据需要构造的数据帧结构作为输入参数，通过标准I/O接口write写入设备；驱动程序对应的内核抽象层设备写入接口函数尝试将传入的数据帧逐帧添加入发送队列，并启动驱动层消息处理流程；若发送队列满，则挂起等待；在驱动层消息处理时，从发送队列中逐帧取出数据帧解析并处理；

步骤5：应用程序通过标准I/O接口read读取总线传输结果，解析返回的数据帧结构并处理；驱动程序对应的内核抽象层设备读取接口函数尝试从接收队列中取出数据帧返回给应用程序；若接收队列为空，则挂起等待；当总线消息传输结束产生中断时，驱动层读取接收数据或反馈信息，写入数据帧结构并添加入接收队列中，返回给应用程序。

2.根据权利要求1所述的基于操作系统的1553B总线通信方法，其特征在于，当1553B总线芯片配置成工作在BC模式时，不论发送还是接收消息，应用程序根据消息控制信息构造数据帧后，通过标准I/O接口write传递给驱动程序处理；再通过标准I/O接口read读取消息传输结束反馈信息。

3.根据权利要求2所述的基于操作系统的1553B总线通信方法，其特征在于，所述步骤4包括：

当BC应用程序需要控制消息传输时，不论是发送还是接收，先构造数据帧结构，再通过标准I/O接口write传递给驱动程序处理；

BC驱动层消息处理时，从发送队列取出一帧数据，根据数据帧中的消息属性构造相应的消息缓存结构和消息描述符，并启动消息传输。

4.根据权利要求2所述的基于操作系统的1553B总线通信方法，其特征在于，所述步骤5包括：

BC中断服务子程序处理时，先判断中断类型，若是发送结束中断，则读取消息传输反馈状态；

若是接收结束中断，则继续读取RT返回的数据，一起写入数据帧结构后添加到接收队列中，返回给应用程序；

尝试从发送队列中取出一帧数据继续处理，依次循环，直到发送队列为空为止。

5.根据权利要求1所述的基于操作系统的1553B总线通信方法，其特征在于，所述步骤2包括：

在RT模式下，应用程序先通过ioctl将1553B总线工作模式设置成RT模式，再通过ioctl按照应用层协议配置各子地址控制字和查找表，驱动程序完成相应的硬件配置，并记录各子地址配置信息；

当消息传输结束产生中断时，驱动程序判断当前为RT模式，并根据子地址配置信息进行RT中断服务子程序处理。

6.根据权利要求1所述的基于操作系统的1553B总线通信方法，其特征在于，当1553B总线芯片配置成工作在RT模式并完成各子地址配置后，作为总线响应端，不论是接收还是发送消息，应用程序先通过调用标准I/O接口read获取驱动返回的消息传输结束信息再做处理；

若是数据发送结束，则更新相应的子地址的下一周期的参数；

若是数据接收结束，则从数据帧中读取接收的数据内容并处理。

7.根据权利要求6所述的基于操作系统的1553B总线通信方法，其特征在于，所述步骤4包括：

当应用程序更新发送子地址缓存区数据时，构造数据帧格式，调用标准I/O接口write写入设备；

当驱动层从发送队列取出数据帧解析并处理时，仅更新相应的RT子地址发送缓存区数据。

8.根据权利要求6所述的基于操作系统的1553B总线通信方法，其特征在于，所述步骤5包括：

RT中断服务子程序处理时，先判断中断类型；

若是发送结束中断，则读取消息命令字；

若是接收结束中断，则继续读取接收的消息数据，一起写入数据帧结构后添加到接收队列中，返回给应用程序。