README.md
1# HDF<a name="EN-US_TOPIC_0000001078041442"></a>
2
3- [Introduction](#section11660541593)
4- [Directory Structure](#section161941989596)
5- [Usage](#section1312121216216)
6 - [HDF](#section129654513264)
7 - [Sensor](#section188637474417)
8 - [Display](#section161502341317)
9 - [Input](#section12629164020115)
10 - [WLAN](#section11408103183114)
11
12- [Repositories Involved](#section1371113476307)
13
14## Introduction<a name="section11660541593"></a>
15
16This 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.
17
18**Figure 1** Architecture of the HDF<a name="fig19330181162816"></a>
19
20
21## Directory Structure<a name="section161941989596"></a>
22
23```
24/drivers/hdf_core/framework
25├── core # Core code for implementing the HDF
26│ ├── adapter # Kernel adaptation layer
27│ ├── common # Common basic code
28│ ├── host # Driver host environment module
29│ ├── manager # Management module
30│ └── shared # Code shared by the host and manager modules
31├── include # Header files for the HDF to provide capabilities externally
32│ ├── audio # Header files related to audio operations
33│ ├── bluetooth # Header files related to bluetooth operations
34│ ├── core # Header files exposed externally
35│ ├── ethernnet # Header files related to ethernnet operations
36│ ├── net # Header files related to network operations
37│ ├── osal # Header files of the OS adaptation layer
38│ ├── platform # Header files declaring platform APIs
39│ ├── utils # Header files declaring common capabilities
40│ └── wifi # Header files for the WLAN module to provide capabilities externally
41├── model # Universal framework module for drivers
42│ ├── audio # Audio framework module
43│ ├── display # Display framework module
44│ ├── input # Input framework module
45│ ├── misc # Misc framework module, including dsoftbus, light, vibrator
46│ ├── network # WLAN framework module
47│ └── sensor # Sensor driver module
48│ └── storage # Storage driver module
49│ └── usb # Usb driver module
50├── sample # Sample code
51├── support # Basic capabilities
52│ └── platform # Platform driver framework and APIs, including GPIO, I2C, and SPI
53│ └── posix # Posix APIs, including Mem, Mutex, Sem, Spinlock, Thread and Time
54├── test # Testcase
55├── tools # Source code related to the tools of the HDF
56│ └── hc-gen # Source code of the configuration management tool
57│ └── hcs-view #
58│ └── hdf-dbg #
59│ └── hdf-dev_eco_tool #
60│ └── hdf-gen #
61│ └── idl-gen #
62│ └── leagecy #
63└── utils # Basic data structures and algorithms
64```
65
66## Usage<a name="section1312121216216"></a>
67
68### HDF<a name="section129654513264"></a>
69
70To 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.
71
72Driver development based on the HDF consists of the following three parts:
73
74- Driver: Develop the functions.
75
76- Information configuration: Present the loading information of the driver.
77
78- Resource configuration: Configure the hardware information of the driver.
79
80You need to complete the logic code for the functions of a driver by the following APIs.
81
82The first part that catches your eyes is the driver entry, which is described through **DriverEntry**.
83
84Three APIs are available, namely **Bind**, **Init**, and **Release**.
85
86```
87struct HdfDriverEntry g_deviceSample = {
88 .moduleVersion = 1,
89 .moduleName = "sample_driver",
90 .Bind = SampleDriverBind,
91 .Init = SampleDriverInit,
92 .Release = SampleDriverRelease,
93};
94```
95
96**Bind**: This API is used to bind driver devices and its functions.
97
98```
99int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
100{
101 return HDF_SUCCESS;
102}
103```
104
105**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.
106
107```
108int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
109{
110 return HDF_SUCCESS;
111}
112```
113
114**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.
115
116```
117void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
118{
119 // Release all resources.
120 return;
121}
122```
123
124For details, see [HDF Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf.md).
125
126### Sensor<a name="section188637474417"></a>
127
128The sensor driver module is developed based on the HDF and supports functions such as cross-OS migration and differentiated device configuration.
129
130- APIs for implementing sensor driver module capabilities: Implement the capabilities of registering, loading, and deregistering sensor drivers as well as detecting sensor device depending on the HDF, normalize APIs for sensor devices of the same type, and offer APIs for parsing register configurations, abstract APIs for bus access, and abstract platform APIs.
131- APIs to be implemented by developers: Based on the HDF Configuration Source \(HCS\), implement differentiated configuration for sensors of the same type and serialized configuration of sensor device parameters, and offer APIs for some sensor device operations to simplify the sensor driver development.
132
133For details, see [Sensor Driver Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-sensor-des.md).
134
135### Display<a name="section161502341317"></a>
136
137The 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.
138
139- APIs for implementing display driver module capabilities: Implement the Hardware Driver Interfaces \(HDIs\) and their adaptation with the chip platform. In addition, the kernel-mode driver abstracts the common services of the panel driver and provides capabilities of initializing the panel, obtaining the panel configuration, powering on/off the panel, and implementing the backlight control.
140- APIs to be implemented by developers: Complete the board-level HCS configuration and private data configuration of the panel, or offer differentiated APIs for some components to ensure efficient development of the display driver.
141
142For details, see [LCD Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-lcd-des.md).
143
144### Input<a name="section12629164020115"></a>
145
146The 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.
147
148- APIs for implementing input driver module capabilities: Implement the HDIs and provide capabilities of managing devices, controlling services, and reporting data. Besides, the input driver model provides a unified driver for different input devices and the capabilities of registering/unregistering an input device, reporting event data, parsing configuration, and loading a common driver.
149- APIs to be implemented by developers: Based on the provided platform driver, add the device descriptions as well as private configuration of the input device and implement differentiated APIs to greatly shorten the time required for developing input drivers.
150
151For details, see [Touchscreen Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-touch-des.md).
152
153### WLAN<a name="section11408103183114"></a>
154
155The 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.
156
157- APIs for implementing WLAN driver module capabilities: Implement the APIs of the WLAN HDI layer and provide capabilities of setting/obtaining the MAC address, obtaining the feature type, and setting the transmit power for upper-layer input services, as well as the capabilities of creating/releasing a **WifiModule**, connecting to/disconnecting from a WLAN hotspot, and applying for/releasing a **NetBuf** for developers.
158- APIs to be implemented by developers: Based on the provided platform driver, complete the board-level HCS configuration as well as the differentiated WLAN configuration, and offer APIs for initializing, deregistering, enabling, and disabling a network device.
159
160For details, see [WLAN Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-external-des.md).
161
162## Repositories Involved<a name="section1371113476307"></a>
163
164[Driver subsystem](https://gitee.com/openharmony/docs/blob/master/en/readme/driver-subsystem.md)
165
166[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md)
167
168[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md)
169
170[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md)
171
172[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md)
173
174
