diff --git a/en/contribute/OpenHarmony-hdf-coding-guide.md b/en/contribute/OpenHarmony-hdf-coding-guide.md index b28b7591c6467b04927d06d53d276e1f69f3b00f..e63cca63bec7351de9f2166fa2f362cfa38439ce 100644 --- a/en/contribute/OpenHarmony-hdf-coding-guide.md +++ b/en/contribute/OpenHarmony-hdf-coding-guide.md @@ -526,7 +526,7 @@ int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) ret = InitDiver(); // A custom method uses an error code provided by the HDF. if (ret != HDF_SUCCESS) { - HDF_LOGE("init drvier is failed"); + HDF_LOGE("init driver is failed"); return ret; } return HDF_SUCCESS; diff --git a/en/device-dev/driver/driver-peripherals-external-des.md b/en/device-dev/driver/driver-peripherals-external-des.md index fc358c852ff3678a5b863a80b0f533fd514b4458..f375802a58e1b7ab774bcd4b40c50447b55a7f6a 100644 --- a/en/device-dev/driver/driver-peripherals-external-des.md +++ b/en/device-dev/driver/driver-peripherals-external-des.md @@ -2,7 +2,7 @@ ## Overview -The WLAN module is developed based on the Hardware Driver Foundation \(HDF\). It 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 are capable of creating, disabling, scanning, and connecting to WLAN hotspots. The WLAN driver provides the Hardware Driver Interface \(HDI\) layer with the capabilities of setting and obtaining the device MAC address and setting the transmit power. The following figure shows the framework of the WLAN module: +The WLAN module is developed based on the Hardware Driver Foundation \(HDF\). It 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 are capable of creating, disabling, scanning, and connecting to WLAN hotspots. The WLAN driver provides the Hardware Device Interface \(HDI\) layer with the capabilities of setting and obtaining the device MAC address and setting the transmit power. The following figure shows the framework of the WLAN module: **Figure 1** WLAN framework ![](figures/wlan-framework.png "wlan-framework") diff --git a/en/device-dev/driver/driver-peripherals-lcd-des.md b/en/device-dev/driver/driver-peripherals-lcd-des.md index 1def774aeb36f20b380ba4296c22685e84d2a776..a23e99fe034f8e0ac4f8bb14eb339efe754ff82a 100644 --- a/en/device-dev/driver/driver-peripherals-lcd-des.md +++ b/en/device-dev/driver/driver-peripherals-lcd-des.md @@ -9,7 +9,7 @@ The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes inte **Display Driver Model** -The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. The display driver model is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated between different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Driver Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI. +The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. The display driver model is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated between different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Device Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI. - HDF display driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process various upper-layer calls in a centralized manner. - SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes the calls at the platform driver layer to the LCD driver layer. diff --git a/en/device-dev/driver/driver-peripherals-sensor-des.md b/en/device-dev/driver/driver-peripherals-sensor-des.md index 63a01ac73bacbd3ae69bf8afbe131e1926472170..d06029a210c8b1a0f09ccced093ad9af20a418d4 100644 --- a/en/device-dev/driver/driver-peripherals-sensor-des.md +++ b/en/device-dev/driver/driver-peripherals-sensor-des.md @@ -32,7 +32,7 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen 1. The sensor host reads the sensor management configuration from the Sensor Host node of the device_info HCS (sensor device information HCS). 2. The sensor host parses the sensor management configuration from the HCB database and associates the corresponding sensor driver. 3. The sensor host loads and initializes the sensor manager driver. -4. The sensor manager driver publishes the sensor hardware driver interfaces (HDIs). +4. The sensor manager driver publishes the sensor hardware device interfaces (HDIs). 5. The sensor host reads the acceleration sensor driver configuration from the Sensor Host node of the device_info HCS. 6. The sensor host loads the acceleration sensor abstract driver and calls the initialization interface to allocate the sensor driver resources and create the data processing queue. 7. The sensor host reads the chipset driver configuration and private configuration of the acceleration sensor from the accel_xxx_config HCS (sensor private configuration HCS). diff --git a/en/device-dev/driver/driver-peripherals-touch-des.md b/en/device-dev/driver/driver-peripherals-touch-des.md index 15c1892db7902caa09c05182bae61ac9cdc35c16..c2a8db8241249eb761b7d1b45be0e70b2d961aa4 100644 --- a/en/device-dev/driver/driver-peripherals-touch-des.md +++ b/en/device-dev/driver/driver-peripherals-touch-des.md @@ -11,7 +11,7 @@ This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver. - The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen. + The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Device Interfaces \(HDIs\) for upper-layer input services to control the touchscreen. **Figure 1** Architecture of the input driver model diff --git a/en/device-dev/kernel/kernel-small-overview.md b/en/device-dev/kernel/kernel-small-overview.md index bb4c1f642537d2cd08a3494baa7b6bf74dc00020..f4d419fef1b10ae3de2fba8d51da60c3e6e4bce4 100644 --- a/en/device-dev/kernel/kernel-small-overview.md +++ b/en/device-dev/kernel/kernel-small-overview.md @@ -84,7 +84,7 @@ The LiteOS-A integrates the HDF framework. The HDF framework provides a more pre - Configurable component-based driver model - Message-based driver interface model - Object-based driver and device management -- Unified hardware driver interface \(HDI\) +- Unified hardware device interface \(HDI\) - Power management and plug and play \(PnP\) **Extended Components** diff --git a/en/release-notes/OpenHarmony-1-1-0-LTS.md b/en/release-notes/OpenHarmony-1-1-0-LTS.md index 548508060618b8a2567b1c418df04007e3353332..998465a35dd195ad265e2f5ddbf104925d84d95c 100644 --- a/en/release-notes/OpenHarmony-1-1-0-LTS.md +++ b/en/release-notes/OpenHarmony-1-1-0-LTS.md @@ -167,7 +167,7 @@ This version inherits all features of OpenHarmony 1.0, and adds and optimizes fe

Driver

- +

Driver loading has been optimized. It can now be accomplished in segmented parts.

diff --git a/en/release-notes/OpenHarmony-v3.1-release.md b/en/release-notes/OpenHarmony-v3.1-release.md index 859015d75bbee0012c2e3d9933daaa2f365dc50b..b72f91a0a6eb3006fc32ec43efaebc7d1dd084bc 100644 --- a/en/release-notes/OpenHarmony-v3.1-release.md +++ b/en/release-notes/OpenHarmony-v3.1-release.md @@ -173,7 +173,7 @@ This version has the following updates to OpenHarmony 3.1 Beta. | Pan-sensor| - Data reporting by common sensors, such as acceleration, gyroscope, and Hall effect sensors, is supported.
- The basic functions of vibrators are supported.
- The general algorithms and geomagnetic field algorithms are supported.
The following requirements are involved:
I4WWTG [miscdevice] Peripheral dependency support by miscdevice
I4WWTF [Sensor] Peripheral dependency support by sensor
I4WWTD [Sensor] Common algorithm interfaces
I4MBRQ [sensor] Horizontal intensity and total intensity of the magnetic field
I4MBRP (sensor component) Magnetic declination and dip| NA | | Distributed data management| - Memory JS objects can now be treated as distributed data objects; Distributed relational data management is provided to support data synchronization based on relational tables.
- Condition-based data synchronization and subscription capabilities are supported, making data synchronization more accurate.
- File upload is supported.
- Data encryption and security tiering are supported, and security control is optimized for data transfer. Multi-user synchronization and isolation are supported.
The following requirements are involved:
I4IBPH [distributed_kv_store] Supplemented the functions of the distributed data service
I4MBRS [distributed_kv_store] Cross-device synchronization and subscription of database records based on predicates
I4MBRU [RDB] Database encryption
I4NZVP [distributed_kv_store] Distributed database JS APIs
I4HAMI [data_share_ability] Subscription of cross-application database changes
I4NZP6 [RDB] Multi-table query
I4FZ6B [RDB] Transaction
I4HAMI [data_share_ability] Subscription of cross-application database changes
I4PNX7 [Distributed RDB] Data storage
I4HAMD [data_share_ability] Data access modes
I4H4FH [distributed_kv_store] Data classification and tiering for the distributed database
I4H3M8 [New feature] Complex type of distributed data objects
I4HAMD [data_share_ability] Data access modes
I4PO00 [Distributed RDB] Data synchronization
I4OTW6 [distributed_kv_store] InKeys predicate for the distributed database
I4RGFY [DataShare] Reconstruction based on the Extension ability and cross-application data sharing on a single device
I4H4FR [distributed_kv_store] Multi-user data isolation and sharing
I4RGFY [DataShare] Reconstruction based on the Extension ability and cross-application data sharing on a single device
I4XXGF [request] File upload| For the mini and small systems:
Distributed data objects are now available to small-system devices.
The following requirements are involved:
I4H3JJ: Distributed objects for small-system devices| | DFX| Watchdog detection for the system and application is provided. Log collection for native crashes and JS crashes is supported.
Abnormal behavior detection is provided for JS applications.
System and process status information can be exported. JS applications can obtain the bottom-layer memory, CPU, and VM information.
Distributed tracing and debugging are supported.
Log, system event, and application event capabilities are enhanced.
The following requirements are involved:
I4PJE3 [New feature] Hidumper framework and tool for the standard system
I4MBRE [hiperf] Performance statistics
I4U0KP [profiler] CPU profiler
I4PJE5 [New feature] JS application debugging and optimization based on native memory information
I4Q6AQ [New feature] Watchdog
I4U0JZ [New feature] hisysevent management
I4Q6B6 [Enhanced feature] HiTrace JS APIs
I4Q6AY [New feature] Detection mode framework and basic detection basic functions| NA | -| Driver| -& Enhanced Hardware Driver Foundation (HDF) capabilities are provided, including HDF Configuration Source (HCS) configuration parsing and power management.
- The shared memory queue and on-demand hardware driver interface (HDI) service startup are added to the HDI management framework.
- The user-mode platform interfaces are provided for user-mode driver development.
- More than 200 HDI interfaces are defined for peripheral modules such as display, audio, camera, sensor, power supply, and USB. The number of device interfaces exceeds 600, providing more hardware access capabilities.
The following requirements are involved:
I4HPR7 [Enhanced feature] HCS macro parsing interface
I4LZZF [Enhanced feature] Synchronous/Asynchronous power management invocation
I4QEKH [New feature] Shared memory HDIs
I4QEKI [New feature] Driver development tool for standard-system driver development
I4QEKZ [New feature] User-mode platform driver interfaces
I4QEKL [New feature] Unified platform driver object model built on the HDF
I4QELC [New feature] On-demand UHDF process startup
I4QEKJ [New feature] HDI adaptation for the Linux-input driver
I4QEKM [New feature] Power HDIs
I4QEKK [New feature] HDF-based hardware timer driver
I4QEKP [New feature] HDF-based light driver
I4MBTP [Enhanced feature] Enhanced sensor driver model
I4MBTQ [Enhanced feature] Enhanced sensor driver
I4MBTR [Enhanced feature] Display HDI reference implementation for the standard system
I4MBTS [New feature] More HDF input device capabilities
I4QEKP [New feature] HDF based light driver
I4QEKQ [New feature] Service-oriented display HDI implementation
I4QEL2 [Enhanced feature] Enhanced vibrator driver model
I4XXGZ [New feature] HDF based pedometer sensor driver| For the mini and small systems:
HCS macro parsing interfaces are provided to reduce the memory usage during compilation.
The following requirements are involved:
I4TFTB [New feature] HCS macro parsing interfaces for the mini system| +| Driver| -& Enhanced Hardware Driver Foundation (HDF) capabilities are provided, including HDF Configuration Source (HCS) configuration parsing and power management.
- The shared memory queue and on-demand hardware device interface (HDI) service startup are added to the HDI management framework.
- The user-mode platform interfaces are provided for user-mode driver development.
- More than 200 HDI interfaces are defined for peripheral modules such as display, audio, camera, sensor, power supply, and USB. The number of device interfaces exceeds 600, providing more hardware access capabilities.
The following requirements are involved:
I4HPR7 [Enhanced feature] HCS macro parsing interface
I4LZZF [Enhanced feature] Synchronous/Asynchronous power management invocation
I4QEKH [New feature] Shared memory HDIs
I4QEKI [New feature] Driver development tool for standard-system driver development
I4QEKZ [New feature] User-mode platform driver interfaces
I4QEKL [New feature] Unified platform driver object model built on the HDF
I4QELC [New feature] On-demand UHDF process startup
I4QEKJ [New feature] HDI adaptation for the Linux-input driver
I4QEKM [New feature] Power HDIs
I4QEKK [New feature] HDF-based hardware timer driver
I4QEKP [New feature] HDF-based light driver
I4MBTP [Enhanced feature] Enhanced sensor driver model
I4MBTQ [Enhanced feature] Enhanced sensor driver
I4MBTR [Enhanced feature] Display HDI reference implementation for the standard system
I4MBTS [New feature] More HDF input device capabilities
I4QEKP [New feature] HDF based light driver
I4QEKQ [New feature] Service-oriented display HDI implementation
I4QEL2 [Enhanced feature] Enhanced vibrator driver model
I4XXGZ [New feature] HDF based pedometer sensor driver| For the mini and small systems:
HCS macro parsing interfaces are provided to reduce the memory usage during compilation.
The following requirements are involved:
I4TFTB [New feature] HCS macro parsing interfaces for the mini system| | USB| - A complete USB service management framework is built, including the host and device modules.
- Port switching is supported for switching between different function modes.
- USB JS APIs are provided for application development.
- USB HDIs are defined and implemented, and standard interfaces for USB driver access are provided.
The following requirements are involved:
I4MBRK [New feature] JS API implementation for the USB service
I4QEKV [New feature] HDI implementation for the USB service
I4QEKN [New feature] USB device implementation
I4QEKO [New feature] USB host implementation
I4QEL6 [New feature] USB port implementation| NA | | Compilation and building| - Normalized component definition and compilation are added.
- A unified compilation framework is provided, including the unified gn template, component configuration, product configuration, build commands, and build process.
- Native SDK compilation and release are supported.
- The Kconfig framework is supported.
- The hb capabilities are enhanced, including using the hb compilation entry in a unified manner, displaying build logs by level, and supporting hb command installation, integration, and extension.
- gn coding specifications and best practice are provided.| The feature changes for the mini and small systems are the same as those for the standard system.| | Test| - The automated test framework is added to support the compilation and running of basic unit/UI test scripts.
- The wukong tool is provided to support pressure testing of random event injection at the level of the entire system or a single application.
-& The SmartPerf tool is added to collect and display basic performance data such as FPS, CPU, and memory data.
- The test scheduling framework is enhanced to support automatic case execution configuration and execution configuration management.
- The DCTS compatibility test suite is provided to support the DSoftBus and distributed data compatibility test.
-& The ACTS and HATS compatibility test suites are enhanced, covering external public JS APIs and HDF APIs in OpenHarmony 3.1 Release.
The following requirements are involved:
I4XXCR [Test framework] UI automation test
I4XXCV [Test framework] TS developer test framework
I4XXCW [Test framework] JS application developer test framework
I4XXD0 [Test framework] Executor device management
I4XXCX [Test framework] Test pipeline test suite execution report
I4XXCZ [Test framework] Test case configuration management
I4XXD0 [Test framework] Executor device management
I4XGLQ [New feature] UI random pressure test tool
I4XXD7 [Authentication test] DCTS 3.1 distributed compatibility test suite| NA | diff --git a/zh-cn/contribute/OpenHarmony-hdf-coding-guide.md b/zh-cn/contribute/OpenHarmony-hdf-coding-guide.md index 1521c5dab674669f3497d607275ac24a723aff52..c21029e4cd794d80c10d2477920eb27a442d8ad0 100755 --- a/zh-cn/contribute/OpenHarmony-hdf-coding-guide.md +++ b/zh-cn/contribute/OpenHarmony-hdf-coding-guide.md @@ -526,7 +526,7 @@ int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) ret = InitDiver(); // 自定义方法使用HDF的错误码 if (ret != HDF_SUCCESS) { - HDF_LOGE("init drvier is failed"); + HDF_LOGE("init driver is failed"); return ret; } return HDF_SUCCESS; diff --git a/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md b/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md index 72170c08d1ae053469dc9f3cc47184c6a6d8719d..02c936b35172b5b7eea5ea3818a0efa20158571b 100644 --- a/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md +++ b/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md @@ -10,7 +10,7 @@ LCD（Liquid Crystal Display）液晶显示驱动，对LCD进行上电，并通 ![image](figures/基于HDF驱动框架的Display驱动模型.png "基于HDF驱动框架的Display驱动模型") -Display驱动模型主要由平台驱动层、芯片平台适配层、LCD器件驱动层三部分组成。驱动模型基于HDF驱动框架开发，通过Platform层和OSAL层提供的接口，屏蔽内核形态的差异，使得器件驱动可以便利的迁移到不同OS及芯片平台。模型向上对接Display公共HAL层，支撑HDI（Hardware Display Interface）接口的实现，通过Display-HDI对图形服务提供各类驱动能力接口。 +Display驱动模型主要由平台驱动层、芯片平台适配层、LCD器件驱动层三部分组成。驱动模型基于HDF驱动框架开发，通过Platform层和OSAL层提供的接口，屏蔽内核形态的差异，使得器件驱动可以便利的迁移到不同OS及芯片平台。模型向上对接Display公共HAL层，支撑HDI（Hardware Device Interface）接口的实现，通过Display-HDI对图形服务提供各类驱动能力接口。 - Display平台驱动层：通过HDF提供的IOService数据通道，与公共HAL层对接，集中接收并处理各类上层调用指令。 diff --git a/zh-cn/device-dev/driver/driver-peripherals-sensor-des.md b/zh-cn/device-dev/driver/driver-peripherals-sensor-des.md index cb31f754b21ef69114c6d596889e74141e769208..98b8370080b5729a1d8ab25c31eb9a20bc9d1715 100755 --- a/zh-cn/device-dev/driver/driver-peripherals-sensor-des.md +++ b/zh-cn/device-dev/driver/driver-peripherals-sensor-des.md @@ -54,7 +54,7 @@ Sensor驱动模型以标准系统Hi3516DV300产品中的加速度传感器驱动 Sensor驱动模型对外开放的API接口能力如下： -- 提供Sensor HDI（Hardware Driver Interface）能力接口，简化服务开发。 +- 提供Sensor HDI（Hardware Device Interface）能力接口，简化服务开发。 - 提供Sensor驱动模型能力接口： - 依赖HDF驱动框架实现Sensor器件驱动的注册，加载，去注册，器件探测等能力。 - 提供同一类型Sensor器件驱动归一接口, 寄存器配置解析操作接口，总线访问抽象接口，平台抽象接口。 diff --git a/zh-cn/device-dev/driver/driver-peripherals-touch-des.md b/zh-cn/device-dev/driver/driver-peripherals-touch-des.md index e81e479bd340dec1f2e5f4442f49f8196f97e699..4cf0a8cecf096eb0ae0d3fe7c44e3ab32aad8045 100644 --- a/zh-cn/device-dev/driver/driver-peripherals-touch-des.md +++ b/zh-cn/device-dev/driver/driver-peripherals-touch-des.md @@ -11,7 +11,7 @@ 本节主要介绍基于Input驱动模型开发Touchscreen器件驱动，Input模型整体的框架如下图所示。 - Input驱动模型基于HDF驱动框架、Platform接口、OSAL接口进行开发，向上对接规范化的驱动接口HDI（Hardware Driver Interface）层，通过Input-HDI层对外提供硬件能力，即上层Input Service可以通过HDI接口层获取相应的驱动能力，进而操控Touchscreen等输入设备。 + Input驱动模型基于HDF驱动框架、Platform接口、OSAL接口进行开发，向上对接规范化的驱动接口HDI（Hardware Device Interface）层，通过Input-HDI层对外提供硬件能力，即上层Input Service可以通过HDI接口层获取相应的驱动能力，进而操控Touchscreen等输入设备。 **图1** 基于HDF驱动框架的Input驱动模型 diff --git a/zh-cn/device-dev/kernel/kernel-small-overview.md b/zh-cn/device-dev/kernel/kernel-small-overview.md index ad6dafc5098134d4b2bd902b6b33d3629a786aef..105a8238858657450276790d38232eee8ba9285c 100644 --- a/zh-cn/device-dev/kernel/kernel-small-overview.md +++ b/zh-cn/device-dev/kernel/kernel-small-overview.md @@ -100,7 +100,7 @@ OpenHarmony 轻量级内核是基于IoT领域轻量级物联网操作系统Huawe - 基于对象的驱动、设备管理 -- HDI（Hardware Driver Interface）统一硬件接口 +- HDI（Hardware Device Interface）统一硬件接口 - 支持电源管理、PnP