CN103812953A - 一种微控制单元与 arm 处理器的通信接口系统 - Google Patents

Abstract

本发明公开了一种微控制单元与ARM处理器的通信接口系统，该通信接口系统包括：ARM处理器的物理层、链路层、传输层、接口层、逻辑层、应用接口层和应用层，以及微控制单元层，所述接口层，其为微控制单元与ARM处理器的协议解析接口，用于将从传输层获取的数据帧转化为对应业务逻辑的接口函数，通过实现所述接口函数以将所述业务逻辑传递到更高层，以及将业务逻辑转化为数据帧发送至更低层。本发明所涉及的通信接口系统因为采用了业务分层解析，接口化衔接的技术手段，所以降低业务逻辑间耦合度，增强业务逻辑内耦合度的技术问题，进而达到了增加框架高可维护性的技术效果。

Description

一种微控制单元与 ARM 处理器的通信接口系统

技术领域

本发明涉及计算机通信领域，尤其涉及一种微控制单元与ARM处理器的通信接口系统。

背景技术

当前，基于Android的处理器（例如ARM和MCU）的通讯接口系统主要执行包括协议解析、逻辑处理、jni调用、Android服务和应用调用等过程，其结构复杂层次多样。

如图1所示，为现有的MCU/ARM通信接口系统结构，包括MCU层、物理层、链路层、逻辑层和应用层。在现有的通讯系统中，应用调用MCU是通过注册回调函数实现的。这种实现方法的缺点是维护复杂。在等待函数返回值的过程中，需要开线程，而处理返回值时，需要UI线程。处理逻辑复杂，占用线程多，与Android服务的耦合度太高，而且不符合Android系统信息处理的规范。

并且，现有的通讯系统架构存在容错性能低，MCU相关应用资源耗费大，服务层中逻辑处理模块混乱，难以维护，MCU控制逻辑复杂等问题。

因此，亟需一种方案以解决上述问题，提供一种降低层次间耦合度、提高层次内耦合度，且易于重构和拓展的通信接口系统。

发明内容

本发明所要解决的技术问题之一是需要提供一种健壮的、高效的、可维护性高的且分层实现的微控制单元与ARM处理器的通信接口系统。

为了解决上述技术问题，本发明提供了一种微控制单元与ARM处理器的通信接口系统，该通信接口系统包括：ARM处理器的物理层、链路层、传输层、接口层、逻辑层、应用接口层和应用层，以及微控制单元层，其中，所述微控制单元层，用于将设备触发所述微控制单元所产生的操作指令根据协议标准形成数据帧发送，以及用于接收并解析所述ARM处理器发送的指令，以控制相关设备动作；所述物理层及链路层，用于实现微控制单元和ARM处理器之间的信息交互和协议交互；所述传输层，用于对传输的数据帧进行有效性验证确保协议交互的正确性；所述接口层，其为微控制单元与ARM处理器的协议解析接口，用于将从传输层获取的数据帧转化为对应业务逻辑的接口函数，通过实现所述接口函数以将所述业务逻辑传递到更高层，以及将业务逻辑转化为数据帧发送至更低层；所述逻辑层，用于对所述业务逻辑进行处理；所述应用接口层，其为系统服务与应用程序的接口，用于将从所述应用层获取的需要微控制单元处理的信息转换成与业务逻辑对应的接口函数；所述应用层，用于实现用户界面处理。

在一个实施例中，所述通信接口系统是基于Android操作系统的通信接口系统。

在一个实施例中，对于所述物理层及链路层，通过在Linux文件系统中创建一虚拟设备节点，对该虚拟设备节点分配缓存区，进而通过所述虚拟设备节点实现所述微控制单元和所述ARM处理器之间的信息交互和协议交互。

在一个实施例中，所述逻辑层包括Java层和C/C++层，所述Java层，用于实现Android虚拟机的应用调用以及对所述应用调用的支持；所述C/C++层，用于实现应用调用中Java代码到C/C++代码的过渡。

在一个实施例中，所述C/C++层对应用该通信接口系统的应用系统中的纯业务逻辑、以及所述微控制单元的纯业务逻辑、协议解析和硬件接口调用进行处理，所述应用系统中的纯业务逻辑包括除所述微控制单元外的其他子模块或子系统的信息处理逻辑。

在一个实施例中，在所述逻辑层发送广播时，将业务逻辑封装成K-V模式的数据结构，所述K-V模式的数据结构包括微控制单元所发送的int型信号值，以及对应该信号值的string型的广播字符串，其中，int型信号值被标识为key，string型的广播字符串被标识为value，二者构成了K-V模式的数据结构。

在一个实施例中，所述应用系统为车机系统。

在一个实施例中，所述车机系统中的纯业务逻辑包括混音子模块、音频处理子模块、视频源处理子模块、EQ处理子模块、FM处理子模块以及面板按键处理子模块的信息处理逻辑。

与现有技术相比，本发明的一个或多个实施例可以具有如下优点：

本发明的微控制单元与ARM处理器的通信接口系统，由于是通过采用业务分层解析，接口化衔接的技术手段来构建的，因而建立后的通信接口系统降低了业务逻辑间的耦合度，增强了业务逻辑内耦合度，进而达到了增加框架高可维护性的技术效果。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例共同用于解释本发明，并不构成对本发明的限制。在附图中：

图1是现有技术中MCU/ARM通信接口系统的结构示意图；

图2是根据本发明实施例的MCU与ARM处理器的通信接口系统的结构示意图；

图3是根据本发明一示例的MCU与ARM处理器的通信接口系统中下层MCU向上层ARM传递信号的说明图；

图4是根据本发明另一示例的MCU与ARM处理器的通信接口系统中上层ARM向下层MCU传递信号的说明图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，以下结合附图对本发明作进一步地详细说明。

需要说明的是，本发明的MCU与ARM处理器的通信接口系统可以通过以下步骤来构建：

首先，将整个系统的逻辑拆分为业务（应用）逻辑函数和系统功能函数，然后，总结业务逻辑，并对其进行归类，实现每个业务逻辑类的服务。最后，通过业务逻辑和技术实现划分通信接口系统的架构层次，实现每个分层间的通讯方式和接口函数。其中涉及到的系统功能函数（也称系统逻辑）主要是为了支持业务逻辑的程序的实现，这些系统功能函数例如可以是各层次间的衔接方式、代码调用技术以及例如用统一接口调用发送Android广播的处理公共函数的方式。系统逻辑体现在实现业务数据在层次间传输的过程中。

图2是根据本发明实施例的MCU与ARM处理器的通信接口系统的结构示意图。下面以应用在车机系统的通信接口系统为例，参考图2来详细说明该接口系统的各个层次结构及功能。

该通信接口系统主要包括MCU层以及隶属于ARM处理器的物理层、链路层、传输层、接口层、逻辑层、应用接口层和应用层。

其中，MCU层主要分为底层、中层和上层这3层。底层用于对车机主体的信号（如方向盘学习）以及下位机板载的一些芯片（例如蓝牙，FM等）信号进行处理。中层为逻辑处理层。上层为协议转化层，用于将MCU逻辑处理层（即中层）方法转化为协议，进而发送至上位机ARM中。

需要说明的是，现有技术中MCU的逻辑处理层需要处理较复杂逻辑，而本实施例淡化了MCU层中逻辑处理层的地位，把像收音机存台、搜台等较复杂逻辑放到上位机ARM中进行处理。

对于ARM处理器的物理层及链路层来说，它们主要是用来提供信息交互的通道，进而实现微控制单元和ARM处理器之间的信息交互和协议交互。具体地，可以通过在Linux文件系统中创建一个虚拟设备节点，并分配一定大小的缓存区，这样上位机和下位机就可以通过访问该虚拟设备节点进行信息交互和协议交互，为整个通讯协议的实现奠定了基础。

传输层，其主要用于对协议帧进行有效性验证。在该层中优选通过CRC校验，同时配合出错重传机制进而确保协议交互的正确性。

而接口层，其是该接口通信系统的核心，作为MCU与ARM的协议解析接口，主要是为了保障软件的健壮性和可复用性。

在下位机向上位机通信时，接口层将传输层传输的数据帧转换为业务逻辑的接口函数，通过该接口函数将业务逻辑传递到更高层。对于车机系统来说，其逻辑被分为应用逻辑和系统逻辑，其中，应用逻辑是指应用软件需要调用的逻辑，系统逻辑是指非应用软件调用的逻辑，应用逻辑例如可以是音频源、视频源处理和面板键调用等操作。本实施例中的通信系统框架精确抽象出了处理这两种逻辑的相关方法。

所谓上位机到下位机的通讯为应用或者Android服务调用MCU的功能，通过调用相关模块的接口方法，传输层会将其转变为信息帧发送到下位机中。一旦协议转换逻辑稳定，程序无需知道方法转变成协议的过程，只需要按照接口的API调用其功能即可。

逻辑层，其为整个系统级别的业务逻辑处理单元。在车机系统中，按模块方式，该逻辑层包括混音子模块、音频处理子模块、视频源处理子模块、均衡器（Equalizer，简称EQ）处理子模块、FM处理子模块、面板按键处理子模块等，当然，不限于上述子模块，例如还可以包括应用信息转发子模块。

根据Android操作系统，该逻辑层被分为两个部分，一个是Java层，一个是C/C++层。其中，Java层主要用于实现Android虚拟机的功能调用以及对应用调用的支持。C/C++层主要用于实现应用调用中Java代码到C/C++代码的过渡，通过jni调用C/C++的代码。考虑到如发广播、开启应用等操作需要通过java实现，而C代码执行效率较高，比较稳定，所以把系统中主要的纯业务逻辑以及MCU的主要逻辑放到逻辑层中的C中完成，再通过jni调用完成C到Java、Java到C的调用。

需要说明的是，将车机系统中，需要将涉及到例如发广播、开启应用的业务需求等封装成K-V模式的数据结构，把发广播、开启应用等操作封装成几个接口，供C/C++逻辑层调用。

在MCU调用Android界面时，其是通过发广播的形式进行的。MCU所发送的是int型的信号值，其对应一个String型的广播字符串，其中int信号值被标识为key，String型的广播字符串被标识为value，二者构成了K-V模式的数据结构。通过使用这种K-V结构，能够解决C/C++与Java传输string类型数据时内存处理复杂的问题。这是因为，在本实施例的整个通信框架中，C/C++与Java传输的是int型的数据，int型不存在释放内存的问题，在Java代码中，int型对应着string字符串，而这个字符串对应着业务逻辑的操作，而且字符串的处理严格在一个类、一个函数中转换，这样控制了K-V结构处理的唯一性。

因此，本实施例的逻辑层中的C/C++层主要用来对系统中的纯业务逻辑、以及MCU的部分纯业务逻辑、协议解析和硬件接口调用进行处理，其中，系统中的纯业务逻辑包括除MCU以外的其他子模块或子系统的信息处理逻辑。在本实施例中，车机系统中的纯业务逻辑包括混音子模块、音频处理子模块、视频源处理子模块、EQ处理子模块、FM处理子模块以及面板按键处理子模块的信息处理逻辑，但不限于上述子模块，还可以包括应用信息转发子模块。这样，可以使数据帧的处理速度加快。另外，使用K-V结构存储并解释MCU到ARM的通讯，简化了调用Android的接口，增加了框架的可维护性。而且，这样保证了逻辑层的逻辑处理效率，明确了Java层和C/C++层的责任，在两层次中规范接口，防止方法滥用，确保了业务逻辑的可维护性和逻辑层代码的健壮性。

应用接口层是指Android系统服务与应用的接口，类似于接口层，用于把每个业务细粒度抽象成方法，向下调用。这是因为Android应用调用MCU时需要通过Android服务，而每个子模块的调用接口是通过aidl（Android系统服务SSI的接口函数）指定的。

在应用层中，为了防止逻辑层出现关联性问题，所以把逻辑代码的实体放在Android系统服务中。该应用层中不涉及任何系统级别的逻辑，主要是用户界面UI处理。即接收用户信息，发送给MCU或Android服务，以及接收MCU或Android服务信息，反馈给用户。

通过上述这种方式来细分通讯系统的各个层次，可以细粒度地增加层次内的耦合性、层次间的离散性，对后期引入新需求和维护系统运行状态提供了一定基础，而且也增强了系统的健壮性。

为了进一步理解本发明，下面具体说明一示例。下面参考图3来说明如何利用该通信接口系统实现MCU向ARM进行通信。

首先，数据由MCU层的MCU产生，MCU层以数据帧的形式发送到ARM处理器的物理层，随后经过物理层以电信号的形式发送至链路层，链路层将接收到的电信号以数据帧的形式发送到接口层。ARM的接口层把数据帧转化为业务逻辑的接口函数，逻辑层中对应的函数调用广播发送数据到应用层中，最后，应用层接到广播数据后进行相应的处理。

更具体地，在MCU层中，设备（车机主体）触发MCU产生原始操作指令，MCU层根据协议标准形成数据帧发送到ARM中。

在ARM的物理层和链路层中，物理层将MCU发送的数据帧以电信号的形式通过串口发送给ARM的链路层中，即ARM中Android kernel虚拟的设备节点中，存在内存里，在这里ARM与MCU进行通讯交互，分别访问对方的协议队列。

ARM的接口层把数据帧转化为业务逻辑的接口，每个业务逻辑都对应着一组函数，通过对这些函数接口的实现，把这些信息传递到逻辑层进行调用。

在逻辑层进行业务逻辑处理，并封装成与上层应用对应的通讯用广播（这是根据Android进程间通讯机制来实现的）。

应用层在接收到逻辑层（android framework)传来的广播后，根据UI需求，改变应用界面指定控件的显示，比如收音机搜索的时候，接收到搜台过程指令，改变搜台控制盘的转动和数字显示。

以上示例是下层向上层传递数据，即MCU向ARM传递数据，下面以一个示例来详细说明如何利用这个通信接口系统从上层向下层进行通信。

如图4所示，其为上层向下层通信的流程，以打开收音机为例，首先应用层调用Android系统服务SSI的aidl接口函数。由binder机制，把信息发送给函数实体，这里，binder是android独有的进程间通讯机制，在这里逻辑层是一个进程为android的系统服务，每一个应用是其他个进程，binder是服务和应用的通讯渠道。应用接口层通过jni调用逻辑层函数，经过逻辑层处理过的业务信息转化为逻辑函数发送到接口层，接口层把业务逻辑转化为数据帧，通过链路层和物理层把数据帧发送到MCU层，MCU根据得到的数据帧信息进行相应的处理，即打开收音机。

更具体地，用户通过操作车机屏幕进而产生需要MCU处理的信息。应用层首先需要调用系统服务的接口函数，把信息传递到应用接口层。

而应用接口层是指根据业务逻辑定义的以业务模块为划分的接口函数，这些函数覆盖了所有的业务逻辑，比如收音机的搜台，播放频率，搜索下一个频率等。

在逻辑层中，为了保证数据处理速度，优选地，选择C/C++来处理业务逻辑，所以应用接口层需要jni调用C/C++代码。在逻辑层中会处理业务逻辑，例如，收音机搜台时，需要调整频率的小数为整数，进行乘1000操作。

接口层把业务逻辑转化为数据帧。通过链路层和物理层把数据帧发送到MCU进行处理，通过虚拟设备节把电信号发送到MCU层中。

在MCU层中，MCU接收到电信号，并解析协议，调用相关的设备。比如，收音机搜台指令，调用收音机芯片，进行搜台。

本发明的MCU与ARM的通信接口系统中每一层次的耦合度都较低，层次间都严格通过接口来通讯。而且，该通信接口系统淡化了协议处理过程，凸显业务接口。按照实际情况把业务进行归类并细粒度抽象为各个接口，降低各个业务类之间的耦合度，便于单个业务的维护和整个系统的健壮性。

而且，通过广播传输数据，降低了应用程序对系统资源的消耗。使通讯方式更加灵活，信息处理更加稳定。更重要的是，在逻辑处理方面，主要复杂逻辑通过用jni调用C/C++来完成，提高处理效率和稳定性，减少Android虚拟机的负荷。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人员在本发明所揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (8)

1.一种微控制单元与ARM处理器的通信接口系统，其特征在于，该通信接口系统包括：ARM处理器的物理层、链路层、传输层、接口层、逻辑层、应用接口层和应用层，以及微控制单元层，其中，

所述微控制单元层，用于将设备触发所述微控制单元所产生的操作指令根据协议标准形成数据帧发送，以及用于接收并解析所述ARM处理器发送的指令，以控制相关设备动作；

所述物理层及链路层，用于实现微控制单元和ARM处理器之间的信息交互和协议交互；

所述传输层，用于对传输的数据帧进行有效性验证确保协议交互的正确性；

所述接口层，其为微控制单元与ARM处理器的协议解析接口，用于将从传输层获取的数据帧转化为对应业务逻辑的接口函数，通过实现所述接口函数以将所述业务逻辑传递到更高层，以及将业务逻辑转化为数据帧发送至更低层；

所述逻辑层，用于对所述业务逻辑进行处理；

所述应用接口层，其为系统服务与应用程序的接口，用于将从所述应用层获取的需要微控制单元处理的信息转换成与业务逻辑对应的接口函数；

所述应用层，用于实现用户界面处理。

2.根据权利要求1所述的通信接口系统，其特征在于，所述通信接口系统是基于Android操作系统的通信接口系统。

3.根据权利要求2所述的通信接口系统，其特征在于，对于所述物理层及链路层，通过在Linux文件系统中创建一虚拟设备节点，对该虚拟设备节点分配缓存区，进而通过所述虚拟设备节点实现所述微控制单元和所述ARM处理器之间的信息交互和协议交互。

4.根据权利要求3所述的通信接口系统，其特征在于，所述逻辑层包括Java层和C/C++层，

所述Java层，用于实现Android虚拟机的应用调用以及对所述应用调用的支持；

所述C/C++层，用于实现应用调用中Java代码到C/C++代码的过渡。

5.根据权利要求4所述的通信接口系统，其特征在于，

所述C/C++层对应用该通信接口系统的应用系统中的纯业务逻辑、以及所述微控制单元的纯业务逻辑、协议解析和硬件接口调用进行处理，所述应用系统中的纯业务逻辑包括除所述微控制单元外的其他子模块或子系统的信息处理逻辑。

6.根据权利要求4所述的通信接口系统，其特征在于，

在所述逻辑层发送广播时，将业务逻辑封装成K-V模式的数据结构，所述K-V模式的数据结构包括微控制单元所发送的int型信号值，以及对应该信号值的string型的广播字符串，其中，int型信号值被标识为key，string型的广播字符串被标识为value，二者构成了K-V模式的数据结构。

7.根据权利要求5所述的通信接口系统，其特征在于，所述应用系统为车机系统。

8.根据权利要求7所述的通信接口系统，其特征在于，

所述车机系统中的纯业务逻辑包括混音子模块、音频处理子模块、视频源处理子模块、EQ处理子模块、FM处理子模块以及面板按键处理子模块的信息处理逻辑。

Images