This repository stores the core source code information of the OpenHarmony driver subsystem, including the driver framework, configuration management, configuration parsing, universal framework model, and unified hardware driver interfaces. It is designed to provide a more precise and efficient development environment, where you can perform one-time development for multi-system deployment.
Figure 1 Architecture of the HDF
/drivers/hdf_core/framework
├── core # Core code for implementing the HDF
│ ├── adapter # Kernel adaptation layer
│ ├── common # Common basic code
│ ├── host # Driver host environment module
│ ├── manager # Management module
│ └── shared # Code shared by the host and manager modules
├── include # Header files for the HDF to provide capabilities externally
│ ├── audio # Header files related to audio operations
│ ├── bluetooth # Header files related to bluetooth operations
│ ├── core # Header files exposed externally
│ ├── ethernnet # Header files related to ethernnet operations
│ ├── net # Header files related to network operations
│ ├── osal # Header files of the OS adaptation layer
│ ├── platform # Header files declaring platform APIs
│ ├── utils # Header files declaring common capabilities
│ └── wifi # Header files for the WLAN module to provide capabilities externally
├── model # Universal framework module for drivers
│ ├── audio # Audio framework module
│ ├── display # Display framework module
│ ├── input # Input framework module
│ ├── misc # Misc framework module, including dsoftbus, light, vibrator
│ ├── network # WLAN framework module
│ └── sensor # Sensor driver module
│ └── storage # Storage driver module
│ └── usb # Usb driver module
├── sample # Sample code
├── support # Basic capabilities
│ └── platform # Platform driver framework and APIs, including GPIO, I2C, and SPI
│ └── posix # Posix APIs, including Mem, Mutex, Sem, Spinlock, Thread and Time
├── test # Testcase
├── tools # Source code related to the tools of the HDF
│ └── hc-gen # Source code of the configuration management tool
│ └── hcs-view #
│ └── hdf-dbg #
│ └── hdf-dev_eco_tool #
│ └── hdf-gen #
│ └── idl-gen #
│ └── leagecy #
└── utils # Basic data structures and algorithms
To develop a driver based on the HDF, you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content.
Driver development based on the HDF consists of the following three parts:
Driver: Develop the functions.
Information configuration: Present the loading information of the driver.
Resource configuration: Configure the hardware information of the driver.
You need to complete the logic code for the functions of a driver by the following APIs.
The first part that catches your eyes is the driver entry, which is described through DriverEntry.
Three APIs are available, namely Bind, Init, and Release.
struct HdfDriverEntry g_deviceSample = {
.moduleVersion = 1,
.moduleName = "sample_driver",
.Bind = SampleDriverBind,
.Init = SampleDriverInit,
.Release = SampleDriverRelease,
};
Bind: This API is used to bind driver devices and its functions.
int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
{
return HDF_SUCCESS;
}
Init: When devices are successfully bound, the HDF calls Init to initialize the driver. After initialization is complete, the HDF will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
{
return HDF_SUCCESS;
}
Release: When you need to uninstall a driver, the HDF calls this function to release the driver resources. Then, other internal resources will be released.
void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
{
// Release all resources.
return;
}
For details, see HDF Overview.
The sensor driver module is developed based on the HDF and supports functions such as cross-OS migration and differentiated device configuration.
For details, see Sensor Driver Overview.
The display driver model that is developed based on the HDF shields the differences among chip platforms, achieving cross-platform migration of the OS. It also abstracts the common service logic of peripherals and configures differentiated adaptation APIs so that a driver model can be compatible with different peripheral. In this way, third-party vendors can efficiently access the OpenHarmony driver ecosystem.
For details, see LCD Overview.
The input driver model is developed based on the HDF, provides unified driver APIs for upper-layer input services, and is decoupled from the chip platform. In addition, it abstracts several types of common platform drivers based on different input devices and is compatible with those input devices through configuration and differentiated peripheral APIs.
For details, see Touchscreen Overview.
The WLAN module is developed based on the HDF and supports cross-OS migration, component adaptation, and modular assembly and compilation. Based on the unified APIs provided by the WLAN module, driver developers of WLAN vendors can adapt their driver code and developers of the Hardware Driver Interfaces (HDIs) are capable of creating, disabling, scanning, and connecting to WLAN hotspots.
For details, see WLAN Overview.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
Activity
Community
Health
Trend
Influence
:Code submit frequency
:React/respond to issue & PR etc.
:Well-balanced team members and collaboration
:Recent popularity of project
:Star counts, download counts etc.