一种基于binder机制的数据传输装置及其实现方法与流程

1.本发明涉及数据传输技术领域，尤其涉及一种基于binder机制的数据传输装置及其实现方法。


背景技术：

2.传统qnx系统通过pps协议通信，可以直接通过系统命令行输入对应pps来测试系统发送数据到目标设备。然而，在linux系统中，各中间件通过ipc进行通信，因此无法如qnx系统中那样直接通过系统命令行输入来测试系统发送数据到目标设备，导致系统调试效率低，增加了开发周期，不利于新产品的快速上市。


技术实现要素：

3.本发明提供一种基于binder机制的数据传输装置及其实现方法，旨在解决现有技术中的缺陷，实现在linux系统中可以直接通过系统命令行输入来测试系统发送数据到目标设备，提高调试效率。
4.为达到上述目的，本发明所采取的技术方案为：
5.本发明一方面提供一种基于binder机制的数据传输装置，包括：
6.若干个安全容器以及与其连接的binder通信模块，还包括依次连接的收发模块、收发进程、通讯接口，所述收发模块还与所述binder通信模块连接；
7.所述安全容器、收发模块、收发进程设置在应用层，所述binder通信模块设置在内核层，所述通讯接口设置在物理层；
8.所述若干个安全容器，用于隔离各交互进程，每个所述安全容器包括一个交互进程和参数转换模块；
9.所述交互进程，用于接收交互界面输入的交互指令转发给所述参数转换模块，或者接收所述参数转换模块转换后的参数发送给交互界面进行显示；
10.所述参数转换模块，用于将接收到的第一预设类型参数转换成第二预设类型参数；
11.所述收发模块，用于将所述第二预设类型参数通过对应的binder端口发送给收发进程；
12.所述收发进程，用于将所述第二预设类型参数转换为通讯模块可识别的电平类型后发送给通讯模块，或者接收通讯模块的数据并转换为第二预设类型参数；
13.所述通讯模块，用于对外提供通讯硬件接口；
14.所述binder通信模块，设置在linux系统内核层，用于打开binder服务，为所述交互进程、收发进程提供ipc通信，并注册死亡通知的回调函数。
15.具体地，所述参数转换模块用于将argv参数转换为int型参数。
16.具体地，所述通讯模块为uart、i2c接口。
17.进一步地，所述binder通信模块还用于注册死亡通知的回调函数。
18.本发明另一方面提供一种基于binder机制的数据传输装置的实现方法，包括：
19.步骤1、创建binder通信模块的复用机制；
20.步骤2、binder通信模块开启binder服务，在交互进程、收发进程之间建立binder端口连接；
21.步骤3、交互进程接收交互界面输入的交互指令，发送给参数转换模块；
22.步骤4、所述参数转换模块获取交互指令中的第一预设类型参数转换为第二预设类型参数；
23.步骤5、所述参数转换模块将所述第二预设类型参数装入到vector类型容器中；
24.步骤6、收发模块将所述vector容器通过binder机制传给收发进程；
25.步骤7、收发进程将所述vector容器中的所述第二预设类型参数转换为通讯模块可识别的电平信号后发送给所述通讯模块；
26.步骤8、通讯模块通过预定的通讯协议将所述电平信号发送给目标设备。
27.具体地，所述步骤1包括：
28.步骤101、创建目标命名空间，所述目标命名空间为各安全容器对应的单独的命名空间；
29.步骤102、将服务管理器service manager在binder驱动中对应的实体节点全局变量、uid全局变量封装为与所述目标命名空间关联的局部变量；
30.步骤103、将进程信息记录结构体binder_proc与所述目标命名空间关联；
31.步骤104、为各安全容器注册服务管理器service mannager；
32.步骤105、服务管理器service manager将注册的交互进程的名称存入对应的所述目标命名空间相关的服务列表中。
33.具体地，所述binder通信模块开启binder服务包括：
34.步骤201、将android上的binder驱动、服务管理器servicemanager和binder库移植到linux系统上；
35.步骤202、打开binder驱动文件，在内核空间创建进程信息记录结构体binder_proc；
36.步骤203、设置binder驱动上下文管理者；
37.步骤204、开启loop循环，实时检测服务请求。
38.具体地，所述步骤4包括：所述参数转换模块通过解析所述交互指令中main函数获取第一预设类型参数。
39.具体地，所述步骤4包括：所述参数转换模块通过ascii码的编码规则将argv参数转换成int型参数。
40.进一步地，在所述步骤2之后还包括：
41.步骤21、binder通信模块注册死亡通知的回调函数；
42.在所述步骤7之后还包括：
43.步骤71、binder通信模块判断所述交互进程、收发进程之间的binder端口的连接是否断开，是则进入下一步，否则返回步骤3；
44.步骤72、binder通信模块回调所述死亡通知进行重新连接。
45.具体地，所述步骤71包括：通过binder.isbinderalive()方法来判断所述交互进
程、收发进程之间的binder端口的连接是否断开。
46.具体地，所述步骤72包括：
47.通过回调onservicedisconnected来实现重新连接。
48.本发明的有益效果在于：本发明通过创建binder通信模块的复用机制，在交互进程、收发进程之间建立binder端口连接，将交互指令中的第一预设类型参数转换为第二预设类型参数并装入到vector类型容器中，然后通过binder机制传给收发进程，再发送给通讯模块，并由通讯模块通过预定的通讯协议发送给目标设备，实现了在linux系统中可以直接通过系统命令行输入来测试系统发送数据到目标设备，提高了调试效率。
附图说明
49.图1是本发明的基于binder机制的数据传输装置的结构示意图；
50.图2是本发明的基于binder机制的数据传输装置的实现方法的流程示意图。
具体实施方式
51.下面结合附图具体阐明本发明的实施方式，附图仅供参考和说明使用，不构成对本发明专利保护范围的限制。
52.在本发明的说明书、权利要求书或附图中描述的流程中，包含各个步骤的序号(如步骤10、20等)，所述序号仅用于区分开各个步骤，所述序号本身不代表任何的执行顺序。需要说明的是，本文中的“第一”、“第二”等描述，仅用于区分描述对象等，不代表先后顺序，也不表示“第一”、“第二”等是不同的类型。
53.实施例1
54.如图1所示，本实施例提供一种基于binder机制的数据传输装置，包括：
55.若干个安全容器以及与其连接的binder通信模块，还包括依次连接的收发模块、收发进程、通讯接口，所述收发模块还与所述binder通信模块连接；
56.所述安全容器、收发模块、收发进程设置在应用层，所述binder通信模块设置在内核层，所述通讯接口设置在物理层；
57.所述若干个安全容器，用于隔离各交互进程，每个所述安全容器包括一个交互进程和参数转换模块；
58.所述交互进程，用于接收交互界面输入的交互指令转发给所述参数转换模块，或者接收所述参数转换模块转换后的参数发送给交互界面进行显示；
59.所述参数转换模块，用于将接收到的第一预设类型参数转换成第二预设类型参数；
60.所述收发模块，用于将所述第二预设类型参数通过对应的binder端口发送给收发进程；
61.所述收发进程，用于将所述第二预设类型参数转换为通讯模块可识别的电平类型后发送给通讯模块，或者接收通讯模块的数据并转换为第二预设类型参数；
62.所述通讯模块，用于对外提供通讯硬件接口；
63.所述binder通信模块，设置在linux系统内核层，用于打开binder服务，为所述交互进程、收发进程提供ipc通信，并注册死亡通知的回调函数。
64.在本实施例中，所述参数转换模块用于将argv参数转换为int型参数。
65.在本实施例中，所述通讯模块包括uart、i2c接口。
66.在本发明的另一个实施例中，所述binder通信模块还用于注册死亡通知的回调函数。
67.实施例2
68.如图2所示，本实施例提供一种基于binder机制的数据传输装置的实现方法，包括：
69.步骤1、创建binder通信模块的复用机制。
70.在本实施例中，所述步骤1包括：
71.步骤101、创建目标命名空间，所述目标命名空间为各安全容器对应的单独的命名空间；
72.在具体实施时，通过create_new_namespaces()函数创建目标命名空间。
73.通过为每个安全容器创建单独的命名空间(namespace)，使得运行在其中的交互进程互不影响，提高了系统的稳定性。
74.步骤102、将服务管理器service manager在binder驱动中对应的实体节点全局变量、uid全局变量封装为与所述目标命名空间关联的局部变量；
75.步骤103、将进程信息记录结构体binder_proc与所述目标命名空间关联；
76.步骤104、为各安全容器注册服务管理器service mannager；
77.步骤105、服务管理器service manager将注册的交互进程的名称存入对应的所述目标命名空间相关的服务列表中。
78.步骤2、binder通信模块开启binder服务，在交互进程、收发进程之间建立binder端口连接。
79.在本实施例中，所述binder通信模块开启binder服务包括：
80.步骤201、将android上的binder驱动、服务管理器servicemanager和binder库移植到linux系统上。
81.binder驱动工作在linux的内核态，负责进程之间binder通信的建立，以使数据可在进程间进行传递。
82.binder库中包括交互过程中涉及到的各项功能对应的binder功能接口，每个binder功能接口实现某一特定功能。
83.步骤202、打开binder驱动文件，在内核空间创建进程信息记录结构体binder_proc。
84.步骤203、设置binder驱动上下文管理者。
85.步骤204、开启loop循环，实时检测服务请求。
86.步骤3、交互进程接收交互界面输入的交互指令，发送给参数转换模块。
87.步骤4、所述参数转换模块获取交互指令中的第一预设类型参数转换为第二预设类型参数。
88.在本实施例中，所述步骤4包括：所述参数转换模块通过解析所述交互指令中main函数获取第一预设类型参数。
89.在本实施例中，所述第一预设类型参数为argv参数，所述第二预设类型参数为int
型参数。
90.在本实施例中，所述步骤4包括：所述参数转换模块通过ascii码的编码规则将argv参数转换成int型参数。
91.在本实施例中，所述int型参数为hex型参数。
92.步骤5、所述参数转换模块将所述第二预设类型参数装入到vector类型容器中。
93.在本实施例中，所述vector类型容器通过c 实现。
94.步骤6、收发模块将所述vector容器通过binder机制传给收发进程。
95.步骤7、收发进程将所述vector容器中的所述第二预设类型参数转换为通讯模块可识别的电平信号后发送给所述通讯模块。
96.步骤8、通讯模块通过预定的通讯协议将所述电平信号发送给目标设备。
97.在具体实施时，所述通讯协议与所述通信模块适配，例如uart、i2c协议等。
98.实施例3
99.与实施例2不同的是，本实施例在所述步骤2之后还包括：
100.步骤21、binder通信模块注册死亡通知的回调函数。
101.在所述步骤7之后还包括：
102.步骤71、binder通信模块判断所述交互进程、收发进程之间的binder端口的连接是否断开，是则进入下一步，否则返回步骤3。
103.在本实施例中，所述步骤71包括：通过binder.isbinderalive()方法来判断所述交互进程、收发进程之间的binder端口的连接是否断开。
104.步骤72、binder通信模块回调所述死亡通知进行重新连接。
105.在本实施例中，所述步骤72包括：
106.通过回调onservicedisconnected来实现重新连接。
107.以上所揭露的仅为本发明的较佳实施例，不能以此来限定本发明的权利保护范围，因此依本发明申请专利范围所作的等同变化，仍属本发明所涵盖的范围。