weixin_41028621的博客

该目标包含了两个源文件main.c和gpio_dayu800.c，并指定了包含目录//commonlibrary/c_utils/base/include。这个函数的作用是将"hardware"组与"gpio:gpio_dayu800"依赖项相关联。以上函数实现了是用指令对Dayu800开发板的GPIO引脚的操作，根据输入参数的数量和值，函数执行不同的操作，并在终端打印出相应的信息。2.6.新增sample/hardware/gpio目录下文件gpio_dayu800.c和gpio_dayu800.h。

d后的dir为目标输出目录，以输出文件夹名为IIdlTestServiceTs为例，在idl可执行文件所在目录下执行./idl-gen -gen-ts -d IIdlTestServiceTs -c IIdlTestServiceTs/IFoo.id，将会在执行环境的IIdlTestServiceTs目录中生成接口文件、Stub文件、Proxy文件。根据OpenHarmony IDL中的定义生成的信息或代码可以简化跨进程或跨设备调用接口的实现。1.openharmony IDL工具。

OpenHarmony默认提供了电量等级，根据当前的电量来定义系统统一的电量等级，如满电量、高电量、低电量、极低电量等。但是电量等级对应的电量值在不同的产品上规格是不同的，产品希望根据产品的设计规格来定制此特性。采用NAPI （Native API）获取电池信息，NAPI 组件是一套对外接口基于Node.js N-API规范开发的原生模块扩展开发框架。Battery Manager 提供了电池信息查询的接口，同时开发者也可以通过公共事件监听电池状态和充放电状态的变化。1.2.电池和充电属性接口。

电源管理子系统1.简介  电源管理子系统是 OpenHarmony 的基本能力子系统，有电池服务组件、显示控制组件和电源管理服务组件，主要提供如下功能：重启服务：系统重启和下电。系统电源管理服务：系统电源状态管理和休眠运行锁管理。显示相关的能耗调节：包括根据环境光调节背光亮度，和根据接近光亮灭屏。省电模式 ：在不损害主要功能和性能的前提下，提供一种低功耗操作模式 。电池服务：支持充放电、电池和充电状态的监测，包括状态的更新和上报，还包括关机充电。温控 ：在设备温度到一定程度之后对应用、

IPC和RPC通常采用客户端-服务端（Client-Server）模型，在使用时，请求Client端进程可获取Server端所在进程的代理（Proxy），并通过此代理读写数据来实现进程间的数据通信，更具体的讲，首先客户端会建立一个服务端的代理对象，这个代理对象具备和服务端一样的功能，若想访问服务端中的某一个方法，只需访问代理对象中对应的方法即可，代理对象会将请求发送给服务端；在整个通信过程中，如果使用的是IPC通信，则依赖的是Binder驱动，使用的是RPC通信，则依赖的是软总线驱动。

点击新建之后，会跳转到官方原始仓的Pull Request页面下，按照下图填写好相关的Pull Request信息即可。fork完成之后，就会自动跳转到自己的gitee仓库页面，里面会创建一个与你刚fork的仓库同名的仓库。5.向官方原始仓提交Pull Request。1.fork OpenHarmony中仓库。2.克隆fork出来的仓库到自己的主机上。3.配置本地仓与官方原始仓的关联。4.新建开发分支进行开发。

使用IDL语法描述HDI接口并保存为.idl文件，.idl文件在编译过程中转换为C/C++语言的函数接口声明、客户端与服务端IPC相关过程代码，开发时只需要基于生成的头文件中函数接口实现具体服务功能即可。HDI（Hardware Device Interface，硬件设备接口）是HDF驱动框架为开发者提供的硬件规范化描述性接口，位于基础系统服务层和设备驱动层之间，是连通驱动程序和系统服务进行数据流通的桥梁，是提供给硬件系统服务开发者使用的、统一的硬件设备功能抽象接口，其目的是为系统服务屏蔽南向设备差异。

Input驱动模型基于HDF驱动框架、Platform接口、OSAL接口进行开发，向上对接规范化的驱动接口HDI（Hardware Device Interface）层，通过Input-HDI层对外提供硬件能力，即上层Input Service可以通过HDI接口层获取相应的驱动能力，进而操控Touchscreen等输入设备。常见的输入设备有键盘、鼠标、游戏杆、触摸屏等。器件设备向平台驱动注册：将实例化的器件设备注册到平台驱动，实现设备和驱动的绑定，并完成中断注册、上下电等器件初始化工作。

最后，调用 DevMgrService的接口 StartService，即 DevmgrServiceStartService() 启动设备管理服务主体，其实就是为一个个host设备创建 DevHostServiceClnt ，并启动对应的 Host 设备在Host域内的DevHostService。DevmgrServiceAttachDeviceHost()遍历host节点的所有设备信息，使用DriverLoader构建设备节点，装载驱动，发布服务，然后将设备链接到Host的devices列表。

适配层提供具体平台硬件设备的驱动，按照核心层定义的模型创建设备对象，并完成对象的初始化(包括必要的成员变量初始化以及钩子方法挂接，以及相关的硬件初始化操作)，最后使用核心层提供的注册方法将设备对象注册到核心层纳入统一管理。在内核态，这个指针可以直接指向实际设备对象，但是对于某些类型的平台设备，需要在用户态提供同样的DevHandle类型及配套API，而实际设备对象在内核空间，导致无法直接获取和使用内核空间的地址。提供统一适配接口：定义了标准的设备对象模型，驱动程序仅需关注标准对象模型的适配。

GPIO又俗称为I/O口，I指的是输入(in），O指的是输出（out）。通常，GPIO控制器通过分组的方式管理所有GPIO管脚，每组GPIO有一个或多个寄存器与之关联，通过读写寄存器完成对GPIO管脚的操作。在HDF框架中，同类型设备对象较多时（可能同时存在十几个同类型配置器），若采用独立服务模式，则需要配置更多的设备节点，且相关服务会占据更多的内存资源。核心层主要提供GPIO管脚资源匹配，GPIO管脚控制器的添加、移除以及管理的能力，通过钩子函数与适配层交互，供芯片厂家快速接入HDF框架。

OpenHarmony驱动子系统采用C面向对象编程模型构建，通过平台解耦、内核解耦，兼容不同内核，提供了归一化的驱动平台底座，旨在为开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。支持组件化的驱动模型，为开发者提供更精细化的驱动管理，开发者可以对驱动进行组件化拆分，使得驱动开发者可以更多关注驱动与硬件交互部分。驱动框架完成大部分驱动加载的动作，用户只需注册自己所需的接口和配置，然后驱动框架就会解析配置的内容，完成驱动加载和初始化动作。提供驱动框架能力，主要完成驱动加载和启动功能。

这里将init进程的代码分成了通用的和特有的两部分，共同的代码均在 /base/startup/init/services/init/文件夹下，其中有lite/和standard/分别用来构建小型系统和标准系统的init进程。这里主要分析标准进程的启动流程。由于OH标准系统是基于kernel内核开发的，所以启动init进程，那么OH的init进程的入口为/base/startup/init/services/init/main.c中。由于从kernel进程启动的init进程。1.kernel的启动。