The Liquid Crystal Display (LCD) driver performs operations such as powering on the LCD and initializing the internal registers of the driver integrated circuits (ICs).
The display driver model based on the [Hardware Driver Foundation (HDF)](../driver/driver-hdf-overview.md) provides the following functions:
The display driver model based on the [Hardware Driver Foundation (HDF)](driver-overview-foundation.md) provides the following functions:
- Provides a basic framework for LCD driver development to improve development efficiency.
...
...
@@ -46,7 +46,7 @@ The LCD interfaces include the Mobile Industry Processor Interface (MIPI) Displa
TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. TTL devices are manufactured using the bipolar process and feature high speed, low power consumption, and diversified types.
TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. TTL devices are manufactured using the bipolar process and feature high speed, low power consumption, and diversified types.
The TTL interface is used to transmit data in parallel mode under control signals. It transmits data signals, clock signals, and control signals (such as line synchronization signals, frame synchronization signals, and data validity signals). For the LCD with the TTL, additional peripheral interfaces, such as the Serial Peripheral Interface (SPI) and Inter-Integrated Circuit (I2C), are required for the read and write of the internal registers.
...
...
@@ -62,11 +62,13 @@ Before applying your device with OpenHarmony system, you need to perform LCD dri
### Available APIs
To adjust the parameters of the LCD, establish a display channel with the display, and implement the display effect, use **display::host** to register the **PanelInfo** struct and interface information and add device description.
2. Adapt the driver to the chip at the SoC adapter layer.
3. Add the LCD panel driver and register the panel driver functions in the driver entry function **Init**. The functions provide capabilities for:
3. Add the LCD panel driver and register the panel driver data in the driver entry function **Init**. The driver data interface implements the following features:
- Powering on/off the LCD device
Based on the LCD hardware connection, use the GPIO APIs provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier.
4. (Optional) Implement other HDF APIs, such as **Release()**, as required.
4. (Optional) Implement other HDF interfaces as required.
5. (Optional) Create other device nodes for implementing service logic or debugging based on the HDF as required.
...
...
@@ -136,7 +138,7 @@ The following uses the Hi35xx series chips as an example to describe how to perf
}
```
2. Configure the chip platform driver information in the **drivers/hdf_core/framework/model/display/driver/adapter_soc/hi35xx_disp.c file**.
2. Configure the chip platform driver information in **drivers/hdf_core/framework/model/display/driver/adapter_soc/hi35xx_disp.c**.
```c++
/* Configuration of the display driver to adapt to the MIPI and chip platform */
...
...
@@ -179,9 +181,9 @@ The following uses the Hi35xx series chips as an example to describe how to perf
}
```
3. Add a device in **drivers/hdf_core/framework/model/display/driver/panel/mipi_icn9700.c**.
@@ -23,7 +23,7 @@ The figure below illustrates how a motion driver works.
1. MSDP: The MSDP service obtains a Motion HDI service instance from the Motion Proxy and calls the Motion HDI API.
2. IDL: The IService Manager allocates a Motion HDI instance requested by the MSDP service, and the Motion Proxy forwards the instance to the MSDP service. After the MSDP service calls the HDI API provided by the Motion Proxy, Motion Stub is called through Inter-Process Communication (IPC) to invoke the Motion Service API. The code is automatically generated by a tool and does not need to be developed by the component vendor.
2. IDL: The MSDP service obtains a Motion HDI service instance from the Motion Proxy and calls the Motion HDI API. The interface instance is allocated by IService Manager. After the MSDP service calls the HDI API provided by the Motion Proxy, Motion Stub is called through Inter-Process Communication (IPC) to invoke the Motion Service API. The code is automatically generated by a tool and does not need to be developed by the component vendor.
3. HDI Service: The HDI service consists of Motion Interface Driver, Motion Service, and Motion Impl. Motion Interface Driver provides the motion driver code. A **HdfDriverEntry** structure is defined to implement the **Init**, **Bind**, and **Release** functions. The **HDF_INIT** macro is used to load the driver in the functions. Motion Service provides the motion recognition service interface class. The specific implementation is described in Motion Impl. The code of HDI Service must be developed by the component vendor.
## Development Guidelines
...
...
@@ -36,6 +36,8 @@ The motion driver provides capabilities for the MSDP service to enable or disabl
**Table 1** Available APIs
**NOTE**<br>The following table lists the C++ function interfaces generated by the IDL interface description. For details about the interface declaration, see the IDL file [/drivers/interface/motion/v1_0/](https://gitee.com/openharmony/drivers_interface/tree/master/motion).
| int32_t EnableMotion(int32_t motionType) | Enables motion recognition of the specified type. The motion recognition data can be obtained only after the motion recognition is enabled.|
...
...
@@ -48,29 +50,30 @@ The motion driver provides capabilities for the MSDP service to enable or disabl
The development procedure is as follows:
1. Develop the user-mode driver for motion recognition based on the HDF.
2. Implement the **EnableMotion**, **DisableMotion**, **Register**, and **Unregister** APIs.
The motion recognition directory structure is as follows:
```undefined
/drivers/peripheral/motion # Developed by the vendor.
├── hdi_service # Driver capabilities provided by the motion recognition module for the MSDP service layer.
├── test # Test code for the motion recognition module.
│ └── unittest\hdi # HDI unit test code for the motion recognition module.
```
/drivers/peripheral/motion // Developed by the vendor.
├── hdi_service // Driver capability provided by the motion module for upper-layer services.
├── test // Test codes for the motion module.
│ └── unittest\hdi // HDI unit test code of the motion driver module.
```
The following describes how to develop a user-mode motion driver based on the HDF. For details, see [motion_interface_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/motion/hdi_service/motion_interface_driver.cpp).
The following describes how to develop a user-mode motion driver based on the HDF. For details, see [motion_if_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/motion/hdi_service/motion_if_driver.cpp).
You need to implement the **Bind()**, **Init()**, **Release()**, and **Dispatch()** functions. The **Bind()** function binds the service capability with the driver; **Init()** implements the initialization required before the driver is loaded; **Release()** reclaims resources when **Init()** fails; **Dispatch()** implements the service, which is bound in **Bind()**.
```c++
// Custom HdfMotionInterfaceHost object
```c
/* Custom HdfMotionInterfaceHost object. */
structHdfMotionInterfaceHost{
structIDeviceIoServiceioService;
OHOS::sptr<OHOS::IRemoteObject>stub;
};
// Enable the IPC service to call the response API.
/* Enable the IPC service to call the response API. */
// Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release driver resources and exit the driver model.
/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release driver resources and exit the driver model. */
