处理器间业务处理系统的制作方法

本公开涉及通信技术领域，特别涉及一种处理器间业务处理系统。

背景技术：

处理器是现代计算设备的基础，为现代计算设备提供基础计算力。为满足计算设施对计算性能、通用性、通信能力、功耗等特殊使用场景的要求，处理器演变出dsp(digitalsignalprocessor，数字信号处理器)、cpu(centralprocessingunit，中央处理器)、arm(advancedrisc(reducedinstructionsetcomputing，精简指令集计算机)machines，高级risc处理器)、mcu(microcontrollerunit，微控制单元)等各种专用类型架构的处理器。

现代计算设备往往结构和功能复杂，单个、单种处理器已不能满足功能设计指标，需要多个、多种处理器组合搭配，共同完成功能。在多处理器交叉通信时，常见的设计往往使用总线通信技术，可以实现多处理器间大批量数据的快速交互。但是，总线通信技术的软件和硬件设计比较复杂，技术要求高，对于多处理器间的小批量数据交互，假若采用总线通信，则存在总线利用率低，资源浪费等问题。

技术实现要素：

本公开实施例提供了一种处理器间业务处理系统，能够满足小批量数据交互的多处理器应用场景，且实现较为简单。所述技术方案如下：

本公开提供了一种处理器间业务处理系统，其特征在于，所述处理器间业务处理系统包括：交换器和至少两个处理器，所述至少两个处理器包括第一处理器和第二处理器，

所述第一处理器用于，基于针对所述第二处理器的待发送业务请求，生成至少一个业务请求包，基于所述业务请求包，生成第一传输层包，通过第一通信接口将所述第一传输层包发送至所述交换器，所述业务请求包按照应用层传输格式进行封装，所述应用层传输格式包括携带包序号和包数据，传输层包按照传输层格式进行封装，所述传输层格式包括携带传输层头，所述传输层头包括源处理器的编号和目的处理器的编号；

所述交换器用于，接收所述第一传输层包，基于所述第一传输层包携带的目的处理器的编号，将所述第一传输层包发送至所述第二处理器的第二通信接口，所述第一通信接口与所述第二通信接口为不同类型的通信接口；

所述第二处理器用于，通过所述第二通信接口接收所述第一传输层包，基于所述第一传输层包和所述传输层格式，确定所述待发送业务请求对应的所有业务请求包，基于所述应用层格式，从所述待发送业务请求对应的所有业务请求包中恢复出所述待发送业务请求，并处理相应业务，基于业务处理结果，生成至少一个针对所述第一处理器的业务回复包，基于所述业务回复包，生成第二传输层包，通过所述第二通信接口将所述第二传输层包发送至所述交换器，所述业务回复包按照所述应用层传输格式进行封装；

所述交换器还用于，接收所述第二传输层包，基于所述第二传输层包携带的目的处理器的编号，将所述第二传输层包发送至所述第一通信接口；

所述第一处理器还用于，通过所述第一通信接口接收所述第二传输层包，基于所述第二传输层包，确定所有针对所述第一处理器的业务回复包，基于所述所有针对所述第一处理器的业务回复包，恢复出业务处理结果。

可选地，所述第一处理器用于，

对所述待发送业务请求进行分包处理，得到至少一个所述业务请求包，所述包序号按照分包顺序排列。

可选地，所述第一处理器用于，

当所述业务请求包的数量为2个或大于2个时，按照所述业务请求包的序号，依次为所述业务请求包括添加传输层头，生成所述第一传输层包；

按照所述第一传输层包的生成顺序，依次通过第一通信接口将所述第一传输层包发送至所述交换器。

可选地，

所述第二处理器还用于，在接收所述第一传输层包之后，生成针对当前接收的第一传输层包的确认包，通过所述第二通信接口将所述确认层包发送至所述交换器，所述确认包按照所述传输层格式封装；

所述交换器还用于，接收所述确认包，基于所述确认包携带的目的处理器的编号，将所述确认包发送至所述第一通信接口；

所述第一处理器还用于，通过所述第一通信接口接收所述确认包，确定是否存在未发送的第一传输层包，当存在未发送的所述第一传输层包时，按照所述第一传输层包的生成顺序，将未发送的所述第一传输层包中最先生成的第一传输层包通过第一通信接口发送至所述交换器。

可选地，所述第一处理器还用于，

当发送所述第一传输层包后经过预定时长、且未接收到针对上一次发送的第一传输层包的确认包时，重新将上一次发送的第一传输层包通过第一通信接口发送至所述交换器。

可选地，所述第一处理器用于，

当发送所述第一传输层包后经过预定时长、且未接收到针对上一次发送的第一传输层包的确认包时，确定上一次发送的第一传输层包的连续发送次数是否超过预定次数；

当同一所述第一传输层包的连续发送次数未超过预定次数时，重新将上一次发送的第一传输层包通过第一通信接口发送至所述交换器。

可选地，所述传输层格式还包括携带校验码，

所述第一处理器还用于，生成所述第一传输层包的校验码，并将所述第一传输层包的校验码添加到所述第一传输层包中；

所述第二处理器还用于，在接收所述第一传输层包之后，基于所述第一传输层包携带的校验码，对所述第一传输层包进行校验，当校验通过时，生成针对当前接收的第一传输层包的确认包。

可选地，所述第二处理器用于，

去除所述第一传输层包的传输层头和所述校验码，恢复出所述业务请求包。

可选地，所述第二处理器用于，

基于所述业务请求包携带的包序号，对接收到所有所述业务请求包的包数据进行组装，恢复出所述待发送业务请求。

可选地，所述第二处理器用于，

在组装未完成、且接收到新的业务请求包时，重新对包括所述新的业务请求包的包数据在内的所有所述业务请求包的包数据进行组装。

本公开实施例提供的技术方案带来的有益效果是：

通过第一处理器基于针对第二处理器的待发送业务请求，生成至少一个业务请求包，基于业务请求包，生成第一传输层包，通过第一通信接口将第一传输层包发送至交换器；交换器将第一传输层包发送至第二处理器的第二通信接口，第一通信接口与第二通信接口为不同类型的通信接口；第二处理器通过第二通信接口接收第一传输层包，并确定所有业务请求包，基于业务请求包携带的包序号，恢复出待发送业务请求，处理相应业务，基于业务处理结果生成针对第一处理器的业务回复包，基于业务回复包，生成第二传输层包，再通过交换器将第二传输层包发送至第一处理器，以使第一处理器接收到业务处理结果，这样，利用交换器实现了具备不同类型的通信接口的两个处理器(第一处理器与第二处理器)之间的业务处理，这两个处理器可以是两个及以上处理器中的任意两个处理器，每个处理器仅需要提供一个通信接口，如任意一个闲置的通信接口，处理器就可以与其他处理器进行业务交互；并且，由于应用层包(业务请求包和业务回复包)按照应用层传输格式进行封装和传输层包按照传输层格式进行封装，将业务处理流程划分为应用层与传输层共两层，相比于总线技术，每个处理器仅需要提供一个闲置的通信接口，比较容易实现，业务处理流程只有两层处理流程，传输层实现业务数据的传输，应用层实现业务应用层面的交互，流程较为简单，能够缩减数据长度，节省成本和资源；当数据交换的处理器较多时，该方案可以满足小批量数据交互的多处理器应用场景。

附图说明

为了更清楚地说明本公开实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本公开实施例提供的一种处理器间业务处理系统的结构框图；

图2是本公开实施例提供的交换器的结构框图；

图3是本公开实施例提供的传输层格式和应用层格式的示意图；

图4是本公开实施例提供的处理器间业务处理方法的流程图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。

在本公开中，处理器包括dsp(digitalsignalprocessor，数字信号处理器)、cpu(centralprocessingunit，中央处理器)、arm(advancedrisc(reducedinstructionsetcomputing，精简指令集计算机)machines，高级risc处理器)、mcu(microcontrollerunit，微控制单元)等各种专用类型架构的处理器。这些处理器虽然架构不同，但均有各自的专用通信接口，例如uart(universalasynchronousreceiver/transmitter，通用异步收发传输器)、i2c(inter－integratedcircuit，内置集成电路)、spi(serialperipheralinterface，串行外设接口)等通用通信接口。但是单个处理器的通信接口数量是有限的，一个通信接口仅支持与一个处理器通信，这样，若将单个处理器依次与各个处理器相连，则将受限于通信接口的数量，在实际执行时存在难度。

考虑到处理器通常都具备uart、i2c、spi等通用通信接口，其中除硬件设计本身要使用其中部分接口外，往往有闲置不用的接口。本公开可在不影响原有硬件设计的原则上，选择闲置不用的uart、i2c、spi等通用通信接口资源，实现多cpu间的交叉通信。本方法对每个cpu只需要提供一个通信接口，且通信接口种类对其它cpu透明。

图1是本公开实施例提供的一种处理器间业务处理系统的结构框图。参见图1，该处理器间业务处理系统包括：交换器1和至少两个处理器p，该至少两个处理器p包括第一处理器2和第二处理器3。

第一处理器2用于，基于针对第二处理器3的待发送业务请求，生成至少一个业务请求包，基于业务请求包，生成第一传输层包，通过第一通信接口将第一传输层包发送至交换器1，业务请求层包按照应用层传输格式进行封装，应用层传输格式包括携带包序号和包数据，传输层包按照传输层格式进行封装，传输层格式包括携带传输层头，传输层头包括源处理器的编号和目的处理器的编号。

交换器1用于，接收第一传输层包，基于第一传输层包携带的目的处理器的编号，将第一传输层包发送至第二处理器3的第二通信接口，第一通信接口与第二通信接口为不同类型的通信接口。

第二处理器3用于，通过第二通信接口接收第一传输层包，基于第一传输层包和传输层格式，确定待发送业务请求对应的所有业务请求包，基于应用层格式，从待发送业务请求对应的所有业务请求包中恢复出待发送业务请求，并处理相应业务，基于业务处理结果，生成至少一个针对第一处理器2的业务回复包，基于业务回复包，生成第二传输层包，通过第二通信接口将第二传输层包发送至交换器1，业务回复包按照应用层传输格式进行封装。

交换器1还用于，接收第二传输层包，基于第二传输层包携带的目的处理器的编号，将第二传输层包发送至第一通信接口。

第一处理器2还用于，通过第一通信接口接收第二传输层包，基于第二传输层包，确定所有针对第一处理器2的业务回复包，基于所有针对第一处理器2的业务回复包，恢复出业务处理结果。

本公开中，通过第一处理器基于针对第二处理器的待发送业务请求，生成至少一个业务请求包，基于业务请求包，生成第一传输层包，通过第一通信接口将第一传输层包发送至交换器；交换器将第一传输层包发送至第二处理器的第二通信接口，第一通信接口与第二通信接口为不同类型的通信接口；第二处理器通过第二通信接口接收第一传输层包，并确定所有业务请求包，基于业务请求包携带的包序号，恢复出待发送业务请求，处理相应业务，基于业务处理结果生成针对第一处理器的业务回复包，基于业务回复包，生成第二传输层包，再通过交换器将第二传输层包发送至第一处理器，以使第一处理器接收到业务处理结果，这样，利用交换器实现了具备不同类型的通信接口的两个处理器(第一处理器与第二处理器)之间的业务处理，这两个处理器可以是两个及以上处理器中的任意两个处理器，每个处理器仅需要提供一个通信接口，如任意一个闲置的通信接口，处理器就可以与其他处理器进行业务交互；并且，由于应用层包按照应用层传输格式进行封装和传输层包按照传输层格式进行封装，将业务处理流程划分为应用层与传输层共两层，相比于总线技术，每个处理器仅需要提供一个闲置的通信接口，比较容易实现，业务处理流程只有两层处理流程，传输层实现业务数据的传输，应用层实现业务应用层面的交互，流程较为简单，能够缩减数据长度，节省成本和资源；当数据交换的处理器较多时，该方案可以满足小批量数据交互的多处理器应用场景。

需要说明的是，当系统中处理器较多时，处理器间与交换器连接的通信接口的类型可以相同。例如有3个处理器，第一个处理器可以通过i2c与交换器连接，第二个处理器可以通过uart与交换器连接，第三个处理器可以通过i2c与交换器连接。

其中，系统中所有的处理器均分配一个设备地址(编号)，比如从1～n，该设备地址对所有处理器透明，便于添加传输层头，同时便于链路层的交换区(交换器1)按照对应的方向交换数据。

对于交换器1，其作为链路层实现数据交换，可以采用fpga(fieldprogrammablegatearray，现场可编程逻辑门阵列)。图2是本公开实施例提供的处理器间业务处理系统的结构框图。参见图2，该交换器1包括：交换控制器11、存储器12和多个接口控制器13。其中，接口控制器13的数量与处理器的数量相同，第i个接口控制器13与第i个处理器的通信接口相匹配。i为正整数。

其中，交换控制器11通过控制接口与各个处理器的控制接口电连接。控制接口可以是i/o引脚。具体地，交换控制器11设有与系统中处理器的数量一致的i/o引脚，一个i/o引脚连一个处理器的i/o引脚，不同处理器对应的交换控制器11的i/o引脚不同。

第一处理器2还用于，当存在处理器间业务(比如针对第二处理器的业务需求)或者已生成第一传输层包时，通过控制接口向交换控制器11申请通信权限。

交换控制器11用于，基于各处理器的通信权限申请，确定第k次通信的发送方处理器，向第k次通信的发送方处理器发送允许通知，允许通知用于指示第k次通信的发送方处理器将接收方处理器的第k次数据发送至相应接口控制器13，接收方处理器为除发送方处理器之外的任何一个处理器。k为正整数。

相应地，第一处理器2用于，当第k次通信的发送方处理器为本处理器时，通过控制接口接收允许通知，基于针对第二处理器的待发送业务请求，生成至少一个业务请求包；或者，通过第一通信接口将所述第一传输层包发送至所述交换器。

存储器12用于，存储从相应接口控制器13接收到的第k次数据，第k次数据为第一传输层包。

交换控制器11还用于，当第k次通信的接收方处理器为第二处理器3时，将存储器12中存储的第k次数据通过第二处理器3对应的接口控制器13发送至第二处理器3(具体可以是，交换控制器11通过控制接口向第二处理器3发送数据接收通知，第二处理器3通过控制接口收到数据接收通知后，开始通过第二通信接口读取数据)。

示例性地，由于第一通信接口与第二通信接口可以为不同类型的通信接口，比如第一通信接口为i2c，第二通信接口为spi，那么，交换控制器11还用于，基于第二通信接口，对存储器12中存储的第k次数据进行相应物理协议的转换，将转换后的第k次数据通过第二处理器3对应的接口控制器13发送至第二处理器3的第二通信接口。

示例性地，第一处理器2用于，对待发送业务请求进行分包处理，得到至少一个业务请求包(分包)，上述包序号按照分包顺序排列。

图3是本公开实施例提供的传输层格式和应用层格式的示意图。参见图3，示例性地，应用层格式还包括携带业务类型标识。可以预先统计所有的处理器间的业务类型，然后为业务类型编号，不同编号表示不同的业务，将该编号作为业务类型标识。

示例性地，参见图3，应用层格式还包括携带交互序号，交互序号用于指示应用层包的类型，应用层包的类型包括业务请求包和业务回复包。这样，处理器收到应用层包后，可以根据交互序号识别应用层包为业务请求包还是为业务回复包。

示例性地，参见图3，应用层格式还包括携带总包数和包数据长度，总包数用于指示应用层包(业务请求包和业务回复包)的分包总量。

示例性地，第一处理器2用于，当业务请求包的数量为2个或大于2个时，按照业务请求包的序号，依次为业务请求包括添加传输层头，生成第一传输层包，传输层头包括源处理器的编号和目的处理器的编号；按照第一传输层包的生成顺序，依次通过第一通信接口将第一传输层包发送至交换器1。

示例性地，第二处理器3还用于，在接收第一传输层包之后，生成针对当前接收的第一传输层包的确认包，通过第二通信接口将确认包发送至交换器1。确认包按照所述传输层格式封装。

相应地，交换器1还用于，接收确认包，基于确认包携带的目的处理器的编号，将确认包发送至第一通信接口。

相应地，第一处理器2还用于，通过第一通信接口接收确认包，确定是否存在未发送的第一传输层包，当存在未发送的第一传输层包时，按照第一传输层包的生成顺序，将未发送的第一传输层包中最先生成的第一传输层包通过第一通信接口发送至交换器1。

在应用中，第一处理器2通过第一通信接口接收到针对上一次发送的第一传输层包的确认包时，可以确定是否存在未发送的业务请求包，当存在未发送的业务请求包时，按照传输层格式对业务请求包进行封装，生成得到第一传输层包，然后将生成的第一传输层包通过第一通信接口发送至交换器1。或者，第一处理器2可以先生成所有业务请求包对应的第一传输层包，在接收到针对上一次发送的第一传输层包的确认包后，接着发送下一个第一传输层包。

示例性地，第一处理器2还用于，当发送第一传输层包后经过预定时长、且未接收到针对上一次发送的第一传输层包的确认包时，重新将上一次发送的第一传输层包通过第一通信接口发送至交换器1。

示例性地，第一处理器2还用于，当发送所述第一传输层包后经过预定时长、且未接收到针对上一次发送的第一传输层包的确认包时，确定上一次发送的第一传输层包的连续发送次数是否超过预定次数；当同一所述第一传输层包的连续发送次数未超过预定次数时，重新将上一次发送的第一传输层包通过第一通信接口发送至所述交换器；当同一第一传输层包的连续发送次数超过预定次数时，确定本次业务处理失败。

其中，参见图3，传输层格式还包括携带校验码，即所有传输层包均带有校验字段，方便接收方判断数据是否接收正常。示例性地，第一处理器2还用于，生成第一传输层包的校验码，并将第一传输层包的校验码添加到第一传输层包中。

相应地，第二处理器3还用于，在接收第一传输层包之后，基于第一传输层包携带的校验码，对第一传输层包进行校验，当校验通过时，生成针对当前接收的第一传输层包的确认包。

参见图3，示例性地，传输层格式还包括传输层头的长度。

示例性地，第二处理器3用于，去除第一传输层包的传输层头和校验码，恢复出业务请求包，再基于所有业务请求包，恢复出待发送业务请求。

示例性地，第二处理器3用于，基于业务请求包携带的包序号，对接收到所有业务请求包的包数据进行组装，恢复出待发送业务请求。

示例性地，第二处理器3用于，在组装未完成、且接收到新的业务请求包时，重新对包括新的业务请求包的包数据在内的所有业务请求包的包数据进行组装。

其中，可以将处理器(第一处理器或第二处理器)的业务处理功能划分为发送模块、接收模块、处理模块和业务接口。其中业务接口用于提供对外接口，供处理器中需要的程序(应用程序)调用与其它处理器进行交互，主要用途是生成业务请求包；发送模块用于控制传输层包的生成及发送，即给应用层包添加传输层头和校验字段(校验码)后再进行发送；接收模块用于控制传输层包的接收，去掉传输层格式，恢复应用层包，并根据应用层包的业务类型标识，将应用层包发给对应的模块(如果业务类型标识为业务请求包，则将应用层包发送给处理模块；如果业务类型标识为业务回复包，则将应用层包发送给业务接口)，并向对端发送模块回复确认包；处理模块用于根据应用的业务请求进行相应的处理，并回复处理结果，在回复处理结果时，将处理结果分包处理，得到至少一个业务回复包(分包)。业务可以是一条命令的执行，比如cpua将一条命令发给cpub执行，cpub执行之后返回相应的结果。

图4是本公开实施例提供的一种处理器间业务处理方法的流程图。为便于说明，图4中省略交换器的处理步骤。该处理器间业务处理方法流程包括如下步骤。

(1)当cpua(第一处理器)需要与cpub(第二处理器)交互时，cpua调用业务接口向发送模块发出业务请求包，业务接口将业务请求按照应用层格式进行封装分包处理后得到多个业务请求包，并转给发送模块。

(2)发送模块按照业务请求包的包序号，给业务请求包添加传输层头并添加校验字段，得到第一传输层包，然后使用对应的物理接口(通信接口)发送此第一传输层包，传输层头附加有源cpua地址及目的cpub地址。

(3)链路层数据交换区根据传输层头的源cpua地址及目的cpub地址将数据包转发往cpub的通信接口。

(4)cpub的接收模块从通信接口接收到第一传输层包后，根据校验码对第一传输层包进行校验，若校验失败，则丢弃该包，继续接收新数据；若校验成功，则去掉传输层头恢复业务请求包后将业务请求包发往处理模块，并发送确认包到cpua的发送模块以通知cpua该包已正确接收。

(5)cpub的发送模块给确认包添加传输层头并添加校验字段，然后使用对应的物理接口发送此数据包，传输层头附加有源cpub地址及目的cpua地址。

(6)cpua的接收模块接收到确认包后，对确认包进行校验，若校验失败，则丢弃该包，继续接收新数据；若校验成功，则去掉传输层头后将确认包发往业务接口。业务接口收到确认包后，发送下一业务请求包(如存在)，否则开始接收业务回复包。所有应用层包的发送均需接收到目的cpu的确认包后再发送下一包，若一定时间内没有接收到确认包，则重复发送该应用层分包，重复3次后仍没有接收到确认包则业务失败。

(7)cpub的处理模块对收到的业务请求包进行缓冲组包处理(组合包数据)，组装完毕后进行对应的处理，根据处理结果生成业务回复总包，然后将业务回复总包分包，生成业务回复包后发给发送模块；若组装尚未完成即有新的业务请求包到来，则丢掉前面缓冲的包，重新开始缓冲组包新的业务包。

(8)cpub的发送模块给业务回复包添加传输层头并添加校验字段得到第二传输层包，该头附加有源cpub地址及目的cpua地址，然后发送该第二传输层包。

(9)链路层数据交换区根据传输层头的源cpub地址及目的cpua地址将第二传输层包转发往cpua。

(10)cpua的接收模块接收到第二传输层包后，对第二传输层包进行校验，若校验失败，则丢弃该包，继续接收新数据；若校验成功，则去掉传输层头恢复业务回复包，将业务回复包发往业务接口，并发送确认包到发送模块以通知cpub该包已正确接收。

(11)cpua的发送模块给确认包添加传输层头并添加校验字段，然后使用对应的物理接口发送此数据包，传输层头附加有源cpua地址及目的cpub地址。

(12)cpub的接收模块接收到确认包后，对确认包进行校验，若校验失败，则丢弃该包，继续接收新数据；若校验成功，则去掉传输层头后将确认包发往处理模块。处理模块收到确认包后，发送下一业务回复包(如存在)。

(13)cpua的业务接口对收到的业务回复包进行缓冲组包处理，组装完毕后向应用返回业务处理结果，业务交互流程结束。

整个交互过程中，单个cpu能够按照需求与其它cpu发起交互。交互分为两个阶段，第一阶段为发生请求阶段，第二阶段为接收业务结果阶段，各阶段数据传输通过传输层实现完整性校验和应答重传机制，保证交互过程的可靠性，通过应用层实现应用层业务交互控制。以上，两层交互流程可以实现在受限接口条件下多cpu间的可靠交互。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本公开的可选实施例，并不用以限制本公开，凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。