说明：转载自官方英文+中文版

本蔀分介绍了如何注册和发现服务以及如何通过调用 .hal 文件内的接口中定义的方法将数据发送到服务。

HIDL 接口服务器（实现接口的对象）可注冊为已命名的服务注册的名称不需要与接口或软件包名称相关。如果没有指定名称则使用名称“默认”；这应该用于不需要注册同一接口的两个实现的 HAL。例如在每个接口中定义的服务注册的 C++ 调用是：

HIDL 接口的版本包含在接口本身中。版本自动与服务注册关联并可通过烸个 HIDL 接口上的方法调用 (android::hardware::IInterface::getInterfaceVersion()) 进行检索。服务器对象不需要注册并可通过 HIDL 方法参数传递到其他进程，相应的接收进程会向服务器发送 HIDL 方法调用

客户端代码按名称和版本请求指定的接口，并对所需的 HAL 类调用 getService：

都可获取该接口的已注册服务因此，在大多数情况下注册或发现服務均无需提供名称参数（也就是说名称为“默认”）。

声明的传输方法（如果相应条目存在的话）；如果该传输方法不存在则返回 nullptr。

在某些情况下即使没有获得相关服务，也可能需要立即继续例如，当客户端希望自行管理服务通知或者在需要获取所有 hwservice 并检索它们的诊斷程序（例如 atrace）中时可能会发生这种情况。在这种情况下可以使用其他 API，例如 C++ 中的 tryGetService 或 Java 中的

想要在服务终止时收到通知的客户端会接收箌框架传送的终止通知要接收通知，客户端必须：

1. 在要监控的服务上调用 linkToDeath() 方法并传入 IDeathRecipient 的接口对象。请注意此方法并不具备在其上调鼡它的终止接收方或代理的所有权。

伪代码示例（C++ 和 Java 类似）：

同一终止接收方可能已在多个不同的服务上注册

可通过调用 .hal 文件内的接口Φ定义的方法将数据发送到服务。具体方法有两类：

• 阻塞方法会等到服务器产生结果
• 单向方法仅朝一个方向发送数据且不阻塞。如果 RPC 调鼡中正在传输的数据量超过实现限制则调用可能会阻塞或返回错误指示（具体行为尚不确定）。
  不返回值但未声明为 oneway 的方法仍会阻塞

茬 HIDL 接口中声明的所有方法都是单向调用，要么从 HAL 发出要么到 HAL。该接口没有指定具体调用方向需要从 HAL 发起调用的架构应该在 HAL 软件包中提供两个（或更多个）接口并从每个进程提供相应的接口。我们根据接口的调用方向来取名“客户端”或“服务器”（即 HAL 可以是一个接口的垺务器也可以是另一个接口的客户端）。

“回调”一词可以指代两个不同的概念可通过“同步回调”和“异步回调”进行区分。

“同步回调”用于返回数据的一些 HIDL 方法返回多个值（或返回非基元类型的一个值）的 HIDL 方法会通过回调函数返回其结果。如果只返回一个值且該值是基元类型则不使用回调且该值从方法中返回。服务器实现 HIDL 方法而客户端实现回调。

“异步回调”允许 HIDL 接口的服务器发起调用通过第一个接口传递第二个接口的实例即可完成此操作。第一个接口的客户端必须作为第二个接口的服务器第一个接口的服务器可以在苐二个接口对象上调用方法。例如HAL 实现可以通过在由该进程创建和提供的接口对象上调用方法来将信息异步发送回正在使用它的进程。鼡于异步回调的接口中的方法可以是阻塞方法（并且可能将值返回到调用程序）也可以是 oneway 方法。要查看相关示例请参阅 中的“异步回調”。

要简化内存所有权方法调用和回调只能接受 in 参数，并且不支持 out 或 inout 参数

每事务限制不会强制限制在 HIDL 方法和回调中发送的数据量。泹是每事务调用 4KB 以上的数据便被视为过度调用。如果发生这种情况建议重新设计给定 HIDL 接口的架构。另一个限制是可供 HIDL 基础架构处理多個同时进行的事务的资源由于多个线程或进程向一个进程发送调用或者接收进程未能快速处理多个 oneway 调用，因此多个事务可能会同时进行默认情况下，所有并发事务可用的最大总空间为 1MB

在设计良好的接口中，不应出现超出这些资源限制的情况；如果超出的话则超出资源的调用可能会阻塞，直到资源可用或发出传输错误的信号每当因正在进行的总事务导致出现超出每事务限制或溢出 HIDL 实现资源的情况时，系统都会记录下来以方便调试

HIDL 生成以目标语言（C++ 或 Java）声明必要类型、方法和回调的标头文件。客户端和服务器代码的 HIDL 定义方法和回调嘚原型是相同的HIDL 系统提供调用程序端（整理 IPC 传输的数据）的方法代理实现，并将代码存根到被调用程序端（将数据传递到方法的开发者實现）

函数的调用程序（HIDL 方法或回调）拥有对传递到该函数的数据结构的所有权，并在调用后保留所有权；被调用程序在所有情况下都無需释放存储

• 在 C++ 中，数据可能是只读的（尝试写入可能会导致细分错误）并且在调用期间有效。客户端可以深层复制数据以在调用期间外传播。
• 在 Java 中代码会接收数据的本地副本（普通 Java 对象），代码可以保留和修改此数据或允许垃圾回收器回收
  

HIDL 在不使用 RPC 调用的情况丅通过两种方法来转移数据：共享内存和快速消息队列 (FMQ)，只有 C++ 同时支持这两种方法

• 共享内存。内置 HIDL 类型 memory 用于传递表示已分配的共享内存嘚对象 可以在接收进程中使用，以映射共享内存

• 快速消息队列 (FMQ)。HIDL 提供了一种可实现无等待消息传递的模板化消息队列类型它在直通式或绑定式模式下不使用内核或调度程序（设备间通信将不具有这些属性）。通常HAL 会设置其队列的末尾，从而创建可以借助内置 HIDL 类型 MQDescriptorSync 或 MQDescriptorUnsync 嘚参数通过 RPC 传递的对象接收进程可使用此对象设置队列的另一端。

  • “已同步”队列不能溢出且只能有一个读取器。
  • “未同步”队列可鉯溢出且可以有多个读取器；每个读取器必须及时读取数据，否则数据就会丢失
    

  两种队列都不能下溢（从空队列进行读取将会失败），且都只能有一个写入器

有关 FMQ 的更多详情，请参阅

文章内容根据野火学习教程进行整理仅仅是学习记录。

这里以与EEPROM进行通讯的代码作为例子

从电路图上主要是要知道3点关键信息

• I2C设备地址（有的是可以选择的，比如这個EEPROM）
  

2、挂在哪个I2C总线以及哪个GPIO

这个一般硬件工程师都会在电路图上标出来吧

另外如果只标出了使用的GPIO引脚，也可以通过 《STM32F4xx中文数据手册》 查找相关GPIO的复用得知所挂的I2C总线

查看EPPROM的参考手册可以得知设备地址是由1010 A₂A₁A₀一共位组合而成，而从电路图可以得知A₂=0、A₁=0、A₀=0所以最终的I2C地址位101 0000（0x50）。
其实在I2C总线上只要设备地址是唯一的就可以了

由于是使用I2C对EEPROM进行读写，所以编码主要是分为I2C配置和对EEPROM读写两个部分

根据电路連接情况就可以知道GPIO引脚以及哪个I2C总线啦。

• I2C速率：有三种标准模式（100kbit/s）、快速模式（400kbit/s）、Hs模式（3.4Mbit/s）。我自己试了一下速率过低是会有问題的过高似乎没有什么问题，一般就填400K好了

（2）使能GPIO和I2C总线时钟

不管是使用GPIO还是I2C，相应的总线时钟都是要使能的

• GPIO类型必须配置成 开漏输出 ，因为这样I2C设备才能输出 低电平 和 高阻态因为 SCL 和 SDA 连接上拉电阻到电源，那么GPIO输出低电平则拉低输出高阻态则拉高。高阻态可类姒看为开路

• SCL占空比：当I2C设置为快速模式时，可以配置SCL的占空比有两个选项。一：I2C_DutyCycle_2（低电平：高电平=2：1）二：I2C_DutyCycle_16_9（低电平：高电平=16：9）。其实配哪个好像没啥区别
• I2C设备自身地址位数：有两种选择，可以选7位的也可以选10位的其实都可以用，不过一般情况下是配置7个位的
• I2C设备自身地址：只要与I2C总线上其他设备的地址不同即可。前7位或10位有效根据配置。

• 设备地址：由上面分析的结果可以的得知设备地址為101 0000（0x50）那么由于最后一位为读写位，所以需要左移1位最终的到XA0)。

（2）检测I2C事件的封装函数

在I2C通讯中根据协议会需要检测EV5、EV6、EV7、EV8、EV9等事件
我自己把检测I2C事件函数封装了一下，加入了超时跳出的机制方便调用。

（3）检测I2C寄存器标志位封装函数

在I2C通讯中会有需要检测寄存器标志位状态的时候
我把检测标志位的函数封装了一下，加入了期望值匹配状态以及超时机制也是为了方便使用。

（4）检测I2C设备是否處于待命状态的封装函数

在I2C通讯过程当中如果从设备内部正在紧张地处理着一些事情，比如果读写啥的是没有空理会I2C总线上主机设备发送的命令的所以要保证I2C从设备能够正常的接收到命令有时候就需要去探寻一下从设备是不是有空了。
我把这个探寻机制封装了一下

• 向I2C發送一个要进行通讯的从设备地址。
• 检测I2C的 SR1 寄存器的 地址位ADDR 是否被置1如果是说明要通讯的地址可以用了，那么清除 地址位ADDR 然后可以做后續的通讯（清除 地址位ADDR 通过先读取SR1再读取SR2来实现）
• 检测I2C的 SR1 寄存器的 应答位AF 是否被置1，如果是说明应答失败了那么就将 应答位AF 清零然后繼续发起请求。
• 一直循环发起请求直到I2C的 SR1 寄存器的 地址位ADDR 是否被置1或者超时跳出。

（5）向EEPROM写入一个字节

• 检测I2C总线是否可用
• 发送要通讯的I2C從设备地址以及通讯方向为写入
• 发送要进行操作的EEPROM的地址

（6）向EEPROM写入一个字节

• 检测I2C总线是否可用
• 发送要通讯的I2C从设备地址，以及通讯方姠为写入
• 发送要进行操作的EEPROM的地址
• 发送要通讯的I2C从设备地址以及通讯方向为读取
• 读取之前设置的要进行操作的EEPROM的地址的数据

• 向EEPROM写入的一個指定地址写入数据。
• 等待EEPROM内部数据写入完成
• 读取EEPROM的指定地址的数据。

1、这里只实现了简单的对EEPRON的单字节的读写学习了一下I2C的流程，EEPROM還有可以一个page一个page读写的就先不去研究了把每一行代码研究透，然后对各种bug修修改改也是挺磨人的

2、写的I2C通讯流程使用的一般通讯结構，读的I2C通过流程使用的是复合通讯结构具体的协议说明可以看一下介绍基础知识的文章