Contributing components
diff --git a/en/device-dev/driver/Readme-EN.md b/en/device-dev/driver/Readme-EN.md
index f5533c8d3458f16d5d5b427f54820bd37a9a60ba..eb21fdeec4025c5c4dd2dc67030249d72e7d3103 100644
--- a/en/device-dev/driver/Readme-EN.md
+++ b/en/device-dev/driver/Readme-EN.md
@@ -4,10 +4,22 @@
- [HDF Overview](driver-hdf-overview.md)
- [Driver Development](driver-hdf-development.md)
- [Driver Service Management](driver-hdf-servicemanage.md)
- - [Driver Message Mechanism Management](driver-hdf-news.md)
+ - [Driver Message Mechanism Management](driver-hdf-message-management.md)
- [Driver Configuration Management](driver-hdf-manage.md)
- [HDF Development Example](driver-hdf-sample.md)
-- [Platform Drivers](driver-platform.md)
+- [Platform Driver Development](driver-develop.md)
+ - [ADC](driver-platform-adc-develop.md)
+ - [GPIO](driver-platform-gpio-develop.md)
+ - [I2C](driver-platform-i2c-develop.md)
+ - [MIPI-DSI](driver-platform-mipidsi-develop.md)
+ - [MMC](driver-platform-mmc-develop.md)
+ - [PWM](driver-platform-pwm-develop.md)
+ - [RTC](driver-platform-rtc-develop.md)
+ - [SDIO](driver-platform-sdio-develop.md)
+ - [SPI](driver-platform-spi-develop.md)
+ - [UART](driver-platform-uart-develop.md)
+ - [Watchdog](driver-platform-watchdog-develop.md)
+- [Platform Driver Usage](driver-platform.md)
- [GPIO](driver-platform-gpio-des.md)
- [I2C](driver-platform-i2c-des.md)
- [RTC](driver-platform-rtc-des.md)
@@ -16,7 +28,8 @@
- [UART](driver-platform-uart-des.md)
- [Watchdog](driver-platform-watchdog-des.md)
- [MIPI DSI](driver-platform-mipidsi-des.md)
-- [Peripherals](driver-peripherals.md)
+ - [PWM](driver-platform-pwm-des.md)
+- [Peripheral Driver Usage](driver-peripherals.md)
- [LCD](driver-peripherals-lcd-des.md)
- [TOUCHSCREEN](driver-peripherals-touch-des.md)
- [Sensor](driver-peripherals-sensor-des.md)
diff --git a/en/device-dev/driver/driver-develop.md b/en/device-dev/driver/driver-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..7967bb405068886414ca2f3195b8465973ce69b3
--- /dev/null
+++ b/en/device-dev/driver/driver-develop.md
@@ -0,0 +1,25 @@
+# Platform Driver Development
+
+- **[ADC](driver-platform-adc-develop.md)**
+
+- **[GPIO](driver-platform-gpio-develop.md)**
+
+- **[I2C](driver-platform-i2c-develop.md)**
+
+- **[MIPI-DSI](driver-platform-mipidsi-develop.md)**
+
+- **[MMC](driver-platform-mmc-develop.md)**
+
+- **[PWM](driver-platform-pwm-develop.md)**
+
+- **[RTC](driver-platform-rtc-develop.md)**
+
+- **[SDIO](driver-platform-sdio-develop.md)**
+
+- **[SPI](driver-platform-spi-develop.md)**
+
+- **[UART](driver-platform-uart-develop.md)**
+
+- **[Watchdog](driver-platform-watchdog-develop.md)**
+
+
diff --git a/en/device-dev/driver/driver-hdf-development.md b/en/device-dev/driver/driver-hdf-development.md
index 4f5d237341dbd143abfcaf257d995ba024c50861..bac84cd8058471e746d640a3c04cc14c7d4a7bea 100644
--- a/en/device-dev/driver/driver-hdf-development.md
+++ b/en/device-dev/driver/driver-hdf-development.md
@@ -5,12 +5,10 @@
## Introduction
-The HDF is designed based on the component-based driver model. It provides more refined driver management to make driver development and deployment more standard. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. [Figure 1](#fig5487113011526) shows the HDF driver model.
+The HDF is designed based on the component-based driver model. It provides more refined driver management to make driver development and deployment more standard. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. [Figure 1](#fig3580184214210) shows the HDF driver model.
-**Figure 1** HDF driver model
-
-
-
+**Figure 1** HDF driver model
+
## How to Develop
@@ -167,7 +165,7 @@ Driver development based on the HDF consists of two parts: driver implementation
> DEVICE_PRELOAD_INVALID
> } DevicePreload;
> ```
-> When the **preload** field in the configuration file is set to **0** \(**DEVICE\_PRELOAD\_ENABLE**\), the driver is loaded by default during system startup. When this field is set to **1** \(**DEVICE\_PRELOAD\_ENABLE\_STEP2**\), the driver is loaded after system startup if quick start is enabled; it is loaded during system startup otherwise. When this field is set to **2** \(**DEVICE\_PRELOAD\_DISABLE**\), the driver is not loaded by default during system startup and can be dynamically loaded later. If the driver service does not exist when a user-level application obtains the driver service \(for details about how to obtain the driver service, see [Driver Message Mechanism Management](driver-hdf-news.md)\), the HDF attempts to dynamically load the driver.
+> When the **preload** field in the configuration file is set to **0** \(**DEVICE\_PRELOAD\_ENABLE**\), the driver is loaded by default during system startup. When this field is set to **1** \(**DEVICE\_PRELOAD\_ENABLE\_STEP2**\), the driver is loaded after system startup if quick start is enabled; it is loaded during system startup otherwise. When this field is set to **2** \(**DEVICE\_PRELOAD\_DISABLE**\), the driver is not loaded by default during system startup and can be dynamically loaded later. If the driver service does not exist when a user-level application obtains the driver service \(for details about how to obtain the driver service, see [Driver Message Mechanism Management](driver-hdf-message-management.md)\), the HDF attempts to dynamically load the driver.
>- Sequential loading \(drivers must be loaded by default\)
> In the configuration file, the **priority** field \(the value is an integer ranging from 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority.
diff --git a/en/device-dev/driver/driver-hdf-manage.md b/en/device-dev/driver/driver-hdf-manage.md
index 08a88cae19f8c85942cfbe4fe6a6bf73585fda77..db1adbb6d5d0a9149fa245b34efd5319bf1696dd 100644
--- a/en/device-dev/driver/driver-hdf-manage.md
+++ b/en/device-dev/driver/driver-hdf-manage.md
@@ -2,18 +2,20 @@
- [HDF Configuration Overview](#section59914284576)
- [Configuration Syntax](#section533713333580)
-- [Keywords](#section1316625413586)
-- [Basic Syntax](#section173481622115918)
-- [Data Types](#section96521601302)
-- [Pre-processing](#section8164295515)
-- [Commenting](#section0338205819610)
-- [Modifying a Reference](#section179799204716)
-- [Replicating Node Configuration](#section382424014712)
-- [Deleting a Node or Attribute](#section165211112586)
-- [Referencing an Attribute](#section192841514490)
-- [Keyword Template](#section520134294)
+ - [Keywords](#section4522107333)
+ - [Basic Structures](#section853042911312)
+ - [Data Types](#section177001259134)
+ - [Pre-Processing](#section14867121641)
+ - [Comments](#section1323412417)
+ - [Reference Modifications](#section193708571145)
+ - [Node Replication](#section1487792020513)
+ - [Delete](#section1096515391155)
+ - [Attribute References](#section20271317611)
+ - [Template](#section958819191063)
+
- [Configuration Generation](#section106152531919)
-- [Introduction to HC-GEN](#section8260625101012)
+ - [Introduction to hc-gen](#section359734416616)
+
## HDF Configuration Overview
@@ -26,10 +28,8 @@ HDF Configuration Generator \(HC-GEN\) is a tool for converting a configuration
The following figure shows the typical application scenario of the HCB mode.
-**Figure 1** Process of using HCS
-
-
-
+**Figure 1** Configuration process
+
The HCS is compiled using the HC-GEN tool to generate an HCB file. The HCS Parser module in the HDF recreates a configuration tree using the HCB file. Then, the HDF driver modules obtain the configurations using the API provided by the HCS Paser.
@@ -37,7 +37,7 @@ The HCS is compiled using the HC-GEN tool to generate an HCB file. The HCS Parse
The HCS syntax is described as follows:
-## Keywords
+### Keywords
The keywords listed in the following table below are reserved for HCS configuration files.
@@ -90,7 +90,7 @@ The keywords listed in the following table below are reserved for HCS configurat
-## Basic Syntax
+### Basic Structures
The HCS configuration file consists of configurations of attributes and nodes.
@@ -106,7 +106,7 @@ An attribute, as the minimum configuration unit, is an independent configuration
- Available formats of **value** are as follows:
- - A binary, octal, decimal, or hexadecimal integer. For details, see [Data Types](#section96521601302).
+ - A binary, octal, decimal, or hexadecimal integer. For details, see [Data Types](#section177001259134).
- A character string. The content should be enclosed in double quotation marks \(" "\).
@@ -137,9 +137,9 @@ A node is a set of attributes. Its syntax is as follows:
- The **match\_attr** attribute can be added to a node. Its value is a globally unique character string. During configuration parsing, the query interface can be invoked to query the nodes with the attribute based on the attribute value.
-## Data Types
+### Data Types
-Attributes automatically use built-in data types, including integers, strings, arrays, and booleans. You do not need to explicitly specify the data type for the attribute values.
+Attributes automatically use built-in data types, including integer, string, array, and boolean. You do not need to explicitly specify the data type for the attribute values.
**Integer**
@@ -170,7 +170,7 @@ attr_bar = ["hello", "world"];
A Boolean data type has two possible values: **true** and **false**.
-## Pre-processing
+### Pre-Processing
**include**
@@ -184,7 +184,7 @@ The **include** keyword is used to import other HCS files. The syntax is as fo
- The file names must be enclosed by double quotation marks \(" "\). Files in different directories can be referenced using relative paths. The file included must be a valid HCS file.
- In the scenario that multiple HCS files are imported using **include**, if the same nodes exist, the latter node will override the former one, and other nodes are listed in sequence.
-## Commenting
+### Comments
Comments can be formatted as follows:
@@ -206,7 +206,7 @@ Comments can be formatted as follows:
>Multi-line comments cannot be nested.
-## Modifying a Reference
+### Reference Modifications
You can use the following syntax to modify the content of any other node:
@@ -258,7 +258,7 @@ In the preceding example, the **foo.foo\_** node changes the value of the refe
- A node of the same level can be referenced simply using the node name. A node of a different level must be referenced by the absolute path, and node names are separated using a period \(.\). **root** indicates the root node. The path format is the node path sequence starting with root. For example, **root.foo.bar** is a valid absolute path.
- If multiple modifications are made to the same attribute, only one uncertain modification can take effect, and a warning will be displayed.
-## Replicating Node Configuration
+### Node Replication
The content of a node can be replicated to another node to define the node with similar content. The syntax is as follows:
@@ -297,9 +297,9 @@ root {
In the preceding example, the **bar** node configuration includes both the **attr\_0** and **attr\_1** values. The modification to **attr\_0** in the **bar** node does not affect the **foo** node.
-The path of the **foo** node is not required if the **foo** node and the **bar** node are of the same level. Otherwise, the absolute path must be used. For details, see [Modifying a Reference](#section179799204716).
+The path of the **foo** node is not required if the **foo** node and the **bar** node are of the same level. Otherwise, the absolute path must be used. For details, see [Reference Modifications](#section193708571145).
-## Deleting a Node or Attribute
+### Delete
You can use the keyword **delete** to delete unnecessary nodes or attributes in the base configuration tree imported by the **include** keyword. In the following example, **sample1.hcs** imports the configuration of **sample2.hcs** using **include**, and deletes the **attribute2** attribute and the **foo\_2** node using the **delete** keyword.
@@ -333,7 +333,7 @@ root {
> **NOTE:**
>The **delete** keyword cannot be used in the same HCS file. It is recommended that you delete unnecessary attributes directly from the configuration source code.
-## Referencing an Attribute
+### Attribute References
To quickly locate the associated node during configuration parsing, you can use the node as the value of the attribute and read the attribute to find the corresponding node. The syntax is as follows:
@@ -353,7 +353,7 @@ node2 {
}
```
-## Keyword Template
+### Template
The **template** keyword is used to generate nodes with strictly consistent syntax, thereby facilitating the traverse and management of nodes of the same type.
@@ -398,7 +398,7 @@ In the preceding example, the **bar** and **bar\_1** nodes inherit the **fo
The HC-GEN tool is used to generate configurations. It checks the HCS configuration syntax and converts HCS source files into HCB files.
-## Introduction to HC-GEN
+### Introduction to hc-gen
Parameter description:
diff --git a/en/device-dev/driver/driver-hdf-news.md b/en/device-dev/driver/driver-hdf-message-management.md
similarity index 100%
rename from en/device-dev/driver/driver-hdf-news.md
rename to en/device-dev/driver/driver-hdf-message-management.md
diff --git a/en/device-dev/driver/driver-hdf-servicemanage.md b/en/device-dev/driver/driver-hdf-servicemanage.md
index 961fceb1181222a71d1423c5f0eebe22e07da3c6..c979929089d87bfac749151989c5c90cbf790826 100644
--- a/en/device-dev/driver/driver-hdf-servicemanage.md
+++ b/en/device-dev/driver/driver-hdf-servicemanage.md
@@ -128,7 +128,7 @@ The development of driver service management includes compiling, binding, obtain
- Using the subscription mechanism
- If the kernel sapce unaware of the time for loading drivers \(on the same host\), use the subscription mechanism provided by the HDF to subscribe to the drivers. After the drivers are loaded, the HDF releases the driver services to you. The implementation is as follows:
+ If the kernel mode is unaware of the time for loading drivers \(on the same host\), use the subscription mechanism provided by the HDF to subscribe to the drivers. After the drivers are loaded, the HDF releases the driver services to you. The implementation is as follows:
```
// Subscription callback function. After the subscribed drivers are loaded, the HDF releases the driver services to you using this function.
diff --git a/en/device-dev/driver/driver-hdf.md b/en/device-dev/driver/driver-hdf.md
index dd3d27b7a8da1298e142f822e2ad51738e19f691..b406f2aa2a6be96024b32f200b4f56c441e1882b 100644
--- a/en/device-dev/driver/driver-hdf.md
+++ b/en/device-dev/driver/driver-hdf.md
@@ -6,7 +6,7 @@
- **[Driver Service Management](driver-hdf-servicemanage.md)**
-- **[Driver Message Mechanism Management](driver-hdf-news.md)**
+- **[Driver Message Mechanism Management](driver-hdf-message-management.md)**
- **[Driver Configuration Management](driver-hdf-manage.md)**
diff --git a/en/device-dev/driver/driver-peripherals-external-des.md b/en/device-dev/driver/driver-peripherals-external-des.md
index 8cb36a1068e3bef6baba7e9c1a8060b4fd9ae588..6520f590885d35a5201dbab3d01c4173cbf85527 100644
--- a/en/device-dev/driver/driver-peripherals-external-des.md
+++ b/en/device-dev/driver/driver-peripherals-external-des.md
@@ -2,21 +2,17 @@
- [Overview](#section729758162218)
- [WLAN Driver API Architecture](#section178022416377)
- - [Available APIs](#section149681312202415)
-
-- [Development Guidelines](#section15957746172412)
- - [How to Develop](#section11776186132513)
+- [Available APIs](#section7331102018815)
+- [How to Develop](#section15957746172412)
- [Development Example](#section1395253612512)
## 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](#fig967034316227):
-
-**Figure 1** WLAN framework
-
+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:
-
+**Figure 1** WLAN framework
+
### WLAN Driver API Architecture
@@ -28,12 +24,10 @@ The WLAN module provides the following three types of APIs:
3. Capability APIs for vendors
-**Figure 2** Available APIs of the WLAN module
+**Figure 2** Available APIs of the WLAN module
+
-
-
-
-### Available APIs
+## Available APIs
The WLAN driver module provides APIs that can be directly called by driver developers, such as creating/releasing a **WifiModule**, connecting to/disconnecting from a WLAN hotspot, applying for/releasing a **NetBuf**, and converting between the **pbuf** structure of Lightweight IP \(lwIP\) and a **NetBuf**. [Table 1](#table1521573319472) describes some APIs.
@@ -232,12 +226,10 @@ The WLAN driver provides the HDI layer with the APIs for creating and destroying
-## Development Guidelines
+## How to Develop
The WLAN driver is developed based on the HDF and PLATFORM. It provides a unified driver model for WLAN modules of different vendors regardless of the operating system \(OS\) and system on a chip \(SoC\).
-### How to Develop
-
1. Set hardware parameters such as **module** \(different features\) and **chip** in the **wifi\_config.hcs** file.
2. Parse the **wifi\_config.hcs** file and generate a structure with the configured parameters.
3. Initialize and create a module.
diff --git a/en/device-dev/driver/driver-peripherals-lcd-des.md b/en/device-dev/driver/driver-peripherals-lcd-des.md
index fb7eaec0acd0744f5e3ff2df836af5e43ea7b6af..e0c84c253904be7be5730355269de34eafb93ea0 100644
--- a/en/device-dev/driver/driver-peripherals-lcd-des.md
+++ b/en/device-dev/driver/driver-peripherals-lcd-des.md
@@ -1,11 +1,8 @@
# LCD
- [Overview](#section141575391542)
- - [API Description](#section14711163785519)
-
-- [Development Guidelines](#section12394223125615)
- - [How to Develop](#section515923045814)
-
+- [API Description](#section53793327396)
+- [How to Develop](#section12394223125615)
- [Development Example](#section7441155155813)
## Overview
@@ -13,48 +10,43 @@
The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers through APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](driver-hdf-overview.md)\). It provides power-on, power-off, and sending of the initialization sequence for LCD hardware across OSs and platforms. The display driver model is shown in [Figure 1](#fig69138814229).
**Figure 1** Architecture of the display driver model
-
-
-- **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.
+**Display driver model**
- - Display common driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process upper-layer calls in a centralized manner.
+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.
- - SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes calls from the platform driver layer to the LCD driver layer.
+- 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.
+- LCD panel driver layer: provides LCD-related APIs for sending the initialization sequence, powering on/off, and setting the backlight.
- - Third-party chip driver layer: provides LCD-related APIs for sending the LCD initialization sequence, powering on or off the LCD device, and setting the backlight.
+The display driver model, capabilities, and APIs help you simplify the display driver development and improve the efficiency.
- The display driver model, capabilities, and APIs help you simplify the display driver development and improve the efficiency.
-
-
-### API Description
+## API Description
The LCD interfaces are classified into the Mobile Industry Processor Interface \(MIPI\) Display Serial Interface \(DSI\), Transistor-Transistor Logic \(TTL\) interfaces, and Low Voltage Differential Signaling \(LVDS\) interfaces. The MIPI DSI and TTL interfaces are commonly used. Here is a brief introduction to them.
- MIPI DSI
**Figure 2** MIPI DSI
- 
+ 
The MIPI DSI is defined by MIPI Alliance. It is mainly used for mobile terminal display. The MIPI DSI is used to transmit image data, in compliance with the MIPI protocol. Generally, control information of the MIPI DSI is sent to the peer IC in the form of MIPI packets through the MIPI DSI. No additional interface is required.
- TTL interface
**Figure 3** TTL interface
- 
+ 
TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. They are manufactured using the bipolar process and feature high speed, low power consumption, and multiple types.
The TTL interface is used to transmit data in parallel mode under the control of control signals. It transmits data signals, clock signals, and control signals \(such as line synchronization signals, frame synchronization signals, and data validity signals\). Generally, the LCD of the TTL interface and the read/write of internal registers require additional peripheral interfaces, such as the Serial Peripheral Interface \(SPI\) and Inter-Integrated Circuit \(I2C\).
-## Development Guidelines
+## How to Develop
The display driver model is developed based on the HDF, platform APIs, and APIs at the OS abstraction layer \(OSAL\), and provides a unified driver model for the LCD regardless of the OS \(LiteOS or Linux OS\) and chip platforms \(such as Hi35xx, Hi38xx, and V3S\).
-### How to Develop
-
1. Add the LCD driver-related hardware descriptions.
2. Add a driver that adapts 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:
diff --git a/en/device-dev/driver/driver-peripherals-sensor-des.md b/en/device-dev/driver/driver-peripherals-sensor-des.md
index 5ad5682a94344b9bf86b6d679af80d31318900a6..f8720e9754ef2b0a1135f4b51a2c6d20be683884 100644
--- a/en/device-dev/driver/driver-peripherals-sensor-des.md
+++ b/en/device-dev/driver/driver-peripherals-sensor-des.md
@@ -1,11 +1,8 @@
# Sensor
- [Overview](#section3634112111)
- - [Available APIs](#section188213414114)
-
-- [Development Guidelines](#section1140943382)
- - [How to Develop](#section7893102915819)
-
+- [Available APIs](#section20930112117478)
+- [How to Develop](#section1140943382)
- [Development Example](#section257750691)
- [Test Guidelines](#section106021256121219)
@@ -14,7 +11,7 @@
The sensor driver module provides APIs for upper-layer sensor services to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data, and setting sensor options. The sensor driver model is developed based on the Hardware Driver Foundation \(HDF\) and supports functions such as cross-OS migration and differentiated device configuration. The following figure shows the architecture of the sensor driver model.
**Figure 1** Architecture of the sensor driver model
-
+
The sensor driver model offers the following APIs:
@@ -22,7 +19,7 @@ The sensor driver model offers the following APIs:
- APIs for implementing sensor driver model capabilities: These APIs implement the capabilities of registering, loading, and unregistering sensor drivers as well as detecting sensor devices depending on the HDF. The APIs include normalized APIs for sensor devices of the same type, APIs for parsing register configurations, abstract APIs for bus access, and abstract platform APIs.
- APIs to be implemented by developers: Based on the HDF Configuration Source \(HCS\), developers can implement differentiated configuration for sensors of the same type and serialized configuration of sensor device parameters. Some sensor device operations can be abstracted as APIs to simplify sensor driver development.
-### Available APIs
+## Available APIs
The following table lists the APIs provided by the sensor driver model.
@@ -248,12 +245,10 @@ The following table lists the APIs that need to be implemented by driver develop
For details about the API implementation, see [Development Example](#section257750691).
-## Development Guidelines
+## How to Develop
Regardless of the OS and system on a chip \(SoC\), the sensor driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for sensor devices. This section uses the acceleration sensor as an example to describe how to develop a sensor driver.
-### How to Develop
-
1. Register the acceleration sensor driver. The HDF provides a unified driver management model. The HDF identifies and loads the target module driver based on the configuration of the acceleration sensor module.
2. Initialize and deinitialize the acceleration sensor driver. Using the **init** function, the HDF starts loading the sensor device driver and allocating configuration resources for sensor device data, respectively. Using the **release** function, the HDF releases the resources and configurations loaded by the driver.
3. Parse the configurations of the acceleration sensor register group. For different types of sensors, you must configure their respective HCS configuration files in the HCS, check whether the sensor device is in position during the device driver startup, and then load the corresponding configuration file to generate the configuration structure object.
diff --git a/en/device-dev/driver/driver-peripherals-touch-des.md b/en/device-dev/driver/driver-peripherals-touch-des.md
index 4298d466b0c44a026d117ec14d4aa0dc639b5de5..55d22178fe22d5472685898095ed86df4701bbf5 100644
--- a/en/device-dev/driver/driver-peripherals-touch-des.md
+++ b/en/device-dev/driver/driver-peripherals-touch-des.md
@@ -1,11 +1,8 @@
# TOUCHSCREEN
- [Overview](#section175431838101617)
- - [Available APIs](#section17667171301711)
-
-- [Development Guidelines](#section65745222184)
- - [How to Develop](#section865734181916)
-
+- [Available APIs](#section105459441659)
+- [How to Develop](#section65745222184)
- [Development Example](#section263714411191)
- [Add the touchscreen driver-related descriptions.](#section18249155619195)
- [Board-level Hardware Configuration and Private Data Configuration](#section3571192072014)
@@ -27,7 +24,7 @@
**Figure 1** Architecture of the input driver model
-
+
- **Input driver model**
@@ -49,7 +46,7 @@
The touchscreen driver is developed based on the [HDF](driver-hdf-development.md) and is implemented via calls to the OSAL and platform APIs, including bus APIs and OS native APIs \(such as memory, lock, thread, and timer\). The OSAL and platform APIs hide the differences of underlying hardware, so that the touchscreen driver can be migrated across platforms and OSs. In this regard, you can develop the touchscreen driver only once but deploy it on multiple devices.
-### Available APIs
+## Available APIs
Based on the attributes of the pins, interfaces on the touchscreens can be classified into the following types:
@@ -58,7 +55,7 @@ Based on the attributes of the pins, interfaces on the touchscreens can be class
- Communications interfaces
**Figure 2** Common pins of the touchscreen
-
+
The interfaces shown in the figure are described as follows:
@@ -73,30 +70,29 @@ The interfaces shown in the figure are described as follows:
- INT: interrupt pin, which needs to be set to the input direction and pull-up status during driver initialization. After detecting an external touch signal, the driver triggers the interrupt by operating the interrupt pin. The driver reads the touch reporting data in the ISR function.
3. **Communications interfaces**
- - I2C: Since only a small amount of touch data is reported by the touchscreen, I2C is used to transmit the reported data. For details about the I2C protocol and interfaces, see [I2C](driver-platform-i2c-des.md#section1695201514281).
- - SPI: In addition to touch reporting data coordinates, some vendors need to obtain basic capacitance data. Therefore, Serial Peripheral Interface \(SPI\) is used to transmit such huge amount of data. For details about the SPI protocol and interfaces, see [SPI](driver-platform-spi-des.md#section71363452477).
+ - I2C: Since only a small amount of touch data is reported by the touchscreen, I2C is used to transmit the reported data. For details about the I2C protocol and interfaces, see [I2C](driver-platform-i2c-des.md#section5361140416).
+ - SPI: In addition to touch reporting data coordinates, some vendors need to obtain basic capacitance data. Therefore, Serial Peripheral Interface \(SPI\) is used to transmit such huge amount of data. For details about the SPI protocol and interfaces, see [SPI](driver-platform-spi-des.md#section193356154511).
-## Development Guidelines
+## How to Develop
Regardless of the OS and system on a chip \(SoC\), the input driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for touchscreen devices.
-- The following uses the touchscreen driver as an example to describe the loading process of the input driver model:
-
- \(1\) Complete the device description configuration, such as the loading priority, board-level hardware information, and private data, by referring to the existing template.
+The following uses the touchscreen driver as an example to describe the loading process of the input driver model:
- \(2\) Load the input device management driver. The input management driver is loaded automatically by the HDF to create and initialize the device manager.
+\(1\) Complete the device description configuration, such as the loading priority, board-level hardware information, and private data, by referring to the existing template.
- \(3\) Load the platform driver. The platform driver is loaded automatically by the HDF to parse the board-level configuration, initialize the hardware, and provide the API for registering the touchscreen.
+\(2\) Load the input device management driver. The input management driver is loaded automatically by the HDF to create and initialize the device manager.
- \(4\) Load the touchscreen driver. The touchscreen driver is loaded automatically by the HDF to instantiate the touchscreen device, parse the private data, and implement differentiated APIs provided by the platform.
+\(3\) Load the platform driver. The platform driver is loaded automatically by the HDF to parse the board-level configuration, initialize the hardware, and provide the API for registering the touchscreen.
- \(5\) Register the instantiated touchscreen device with the platform driver. Then bind this device to the platform driver, and complete touchscreen initialization such as interrupt registration and power-on and power-off.
+\(4\) Load the touchscreen driver. The touchscreen driver is loaded automatically by the HDF to instantiate the touchscreen device, parse the private data, and implement differentiated APIs provided by the platform.
- \(6\) Instantiate the input device and register it with the input manager after the touchscreen is initialized.
+\(5\) Register the instantiated touchscreen device with the platform driver. Then bind this device to the platform driver, and complete touchscreen initialization such as interrupt registration and power-on and power-off.
+\(6\) Instantiate the input device and register it with the input manager after the touchscreen is initialized.
-### How to Develop
+Perform the following steps:
1. Add the touchscreen driver-related descriptions.
@@ -108,7 +104,7 @@ Regardless of the OS and system on a chip \(SoC\), the input driver is developed
3. Implement differentiated adaptation APIs of the touchscreen.
- Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#section259614242196).
+ Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#section1635911016188).
## Development Example
diff --git a/en/device-dev/driver/driver-peripherals.md b/en/device-dev/driver/driver-peripherals.md
index 2269b5f9dde2fbe881a7047b0f08d09ad7304be0..aee10257e65791a1c04ddea0bfd4e998544fc387 100644
--- a/en/device-dev/driver/driver-peripherals.md
+++ b/en/device-dev/driver/driver-peripherals.md
@@ -1,4 +1,4 @@
-# Peripheral Driver Development
+# Peripheral Driver Usage
- **[LCD](driver-peripherals-lcd-des.md)**
diff --git a/en/device-dev/driver/driver-platform-adc-develop.md b/en/device-dev/driver/driver-platform-adc-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..4f5753bbed8f51339d7e2b9e6c082dc934ec2616
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-adc-develop.md
@@ -0,0 +1,423 @@
+# ADC
+
+- [Overview](#section268031773165048)
+- [How to Develop](#section100579767165048)
+ - [AdcMethod](#section1618135285210)
+
+- [Development Example](#section1745221471165048)
+
+## Overview
+
+The analog-to-digital converter \(ADC\) is a device that converts analog signals into digital signals. In the Hardware Driver Foundation \(HDF\) framework, the ADC module uses the unified service mode for API adaptation. In this mode, a device service is used as the ADC manager to handle external access requests in a unified manner, which is reflected in the configuration file. The unified service mode applies to the scenario where there are many device objects of the same type, for example, when the ADC has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services.
+
+**Figure 1** Unified service mode
+
+
+## How to Develop
+
+The ADC module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **adc\_config.hcs** file.
+
+3. Instantiate the ADC controller object.
+ - Initialize **AdcDevice**.
+ - Instantiate **AdcMethod** in the **AdcDevice** object.
+
+ > **NOTE:**
+ >For details, see [AdcMethod](#section1618135285210) and [Table 1](#table1943202316536).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the signal collection is successful.
+
+
+### AdcMethod
+
+```
+struct AdcMethod {
+ int32_t (*read)(struct AdcDevice *device, uint32_t channel, uint32_t *val);
+ int32_t (*start)(struct AdcDevice *device);
+ int32_t (*stop)(struct AdcDevice *device);
+};
+```
+
+**Table 1** Callbacks for the members in the AdcMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+read
+ |
+device: structure pointer to the ADC controller at the core layer.
+channel: channel ID of the uint32_t type.
+ |
+val: pointer to the signal data to be transmitted. It is of the uint32_t type.
+ |
+HDF_STATUS
+ |
+Reads the signal data sampled by the ADC.
+ |
+
+stop
+ |
+device: structure pointer to the ADC controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Stops the ADC device.
+ |
+
+start
+ |
+device: structure pointer to the ADC controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Starts the ADC device.
+ |
+
+
+
+
+## Development Example
+
+The following uses **adc\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+
+ - ADC driver entry reference
+
+ Many devices may connect to the ADC. In the HDF framework, a manager object needs to be created for the ADC. When a device needs to be started, the manager object locates the device based on the specified parameters.
+
+ The driver of the ADC manager is implemented by the core layer. Vendors do not need to pay attention to the implementation of this part. However, when they implement the **Init** function, the **AdcDeviceAdd** function of the core layer must be called to implement the corresponding features.
+
+ ```
+ static struct HdfDriverEntry g_hi35xxAdcDriverEntry = {
+ .moduleVersion = 1,
+ .Init = Hi35xxAdcInit,
+ .Release = Hi35xxAdcRelease,
+ .moduleName = "hi35xx_adc_driver",// (Mandatory) This parameter must be the same as that in the .hcs file.
+ };
+ HDF_INIT(g_hi35xxAdcDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
+
+ // Driver entry of the adc_core.c manager service at the core layer
+ struct HdfDriverEntry g_adcManagerEntry = {
+ .moduleVersion = 1,
+ .Init = AdcManagerInit,
+ .Release = AdcManagerRelease,
+ .moduleName = "HDF_PLATFORM_ADC_MANAGER",// This parameter corresponds to device0 in the device_info file.
+ };
+ HDF_INIT(g_adcManagerEntry);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **adc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or value ranges of the **AdcDevice** members at the core layer.
+
+ In the unified service mode, the first device node in the **device\_info** file must be the ADC manager, and the parameters must be set as follows:
+
+
+ Member
+ |
+ Value
+ |
+
|---|
+
+ moduleName
+ |
+ It has a fixed value of HDF_PLATFORM_ADC_MANAGER.
+ |
+
+ serviceName
+ |
+ –
+ |
+
+ policy
+ |
+ The value is 0, which indicates that no service is published.
+ |
+
+ deviceMatchAttr
+ |
+ This parameter is not used.
+ |
+
+
+
+
+ Configure ADC controller information from the second node. This node specifies a type of ADC controllers rather than an ADC controller. In this example, there is only one ADC device. If there are multiple ADC devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **adc\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ platform :: host {
+ device_adc :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 50;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_ADC_MANAGER";
+ serviceName = "HDF_PLATFORM_ADC_MANAGER";
+ }
+ device1 :: deviceNode {
+ policy = 0; // The value 0 indicates that no service needs to be published.
+ priority = 55; // Driver startup priority
+ permission = 0644; // Permission to create device nodes for the driver
+ moduleName = "hi35xx_adc_driver"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HI35XX_ADC_DRIVER"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_adc";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller in adc_config.hcs.
+ } // The specific controller information is in adc_config.hcs.
+ }
+ }
+ }
+ }
+ ```
+
+ - adc\_config.hcs configuration reference
+
+ ```
+ root {
+ platform {
+ adc_config_hi35xx {
+ match_attr = "hisilicon_hi35xx_adc";
+ template adc_device {
+ regBasePhy = 0x120e0000;// Physical base address of the register
+ regSize = 0x34; // Bit width of the register
+ deviceNum = 0; // Device number
+ validChannel = 0x1; // Valid channel
+ dataWidth = 10; // Data bit width of received signals
+ scanMode = 1; // Scan mode
+ delta = 0; // Delta parameter
+ deglitch = 0;
+ glitchSample = 5000;
+ rate = 20000;
+ }
+ device_0 :: adc_device {
+ deviceNum = 0;
+ validChannel = 0x2;
+ }
+ }
+ }
+ }
+ ```
+
+3. Initialize the **AdcDevice** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **AdcMethod** \(used to call underlying functions of the driver\) in **AdcDevice**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **adc\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the **AdcDevice** object at the core layer.
+
+ ```
+ struct Hi35xxAdcDevice {
+ struct AdcDevice device;// (Mandatory) Control object of the core layer. For details, see the description of AdcDevice.
+ volatile unsigned char *regBase;// (Mandatory) Base address of the register
+ volatile unsigned char *pinCtrlBase;
+ uint32_t regBasePhy; // (Mandatory) Physical base address of the register
+ uint32_t regSize; // (mandatory) Bit width of the register
+ uint32_t deviceNum; // (Mandatory) Device number
+ uint32_t dataWidth; // (Mandatory) Data bit width of received signals
+ uint32_t validChannel; // (Mandatory) Valid channel
+ uint32_t scanMode; // (Mandatory) Scan mode
+ uint32_t delta;
+ uint32_t deglitch;
+ uint32_t glitchSample;
+ uint32_t rate; // (Mandatory) Sampling rate
+ };
+
+ // AdcDevice is the core layer controller structure. Its members are assigned with values by using the Init function.
+ struct AdcDevice {
+ const struct AdcMethod *ops;
+ OsalSpinlock spin;
+ uint32_t devNum;
+ uint32_t chanNum;
+ const struct AdcLockMethod *lockOps;
+ void *priv;
+ };
+ ```
+
+ - Instantiate the callback function structure **AdcMethod** in **AdcDevice**. The **AdcLockMethod** callback function structure is not implemented in this example. To instantiate the structure, refer to the I2C driver development. Other members are initialized in the **Init** function.
+
+ ```
+ static const struct AdcMethod g_method = {
+ .read = Hi35xxAdcRead,
+ .stop = Hi35xxAdcStop,
+ .start = Hi35xxAdcStart,
+ };
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Transmission successful
+ |
+
+ HDF_FAILURE
+ |
+ Transmission failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **AdcDevice**, and calls the **AdcDeviceAdd** function at the core layer.
+
+ ```
+ static int32_t Hi35xxAdcInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct DeviceResourceNode *childNode = NULL;
+ ...
+ // Traverse and parse all nodes in adc_config.hcs and call the Hi35xxAdcParseInit function to initialize the devices separately.
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ ret = Hi35xxAdcParseInit(device, childNode);// For details about the function definition, see the following description.
+ ...
+ }
+ return ret;
+ }
+
+ static int32_t Hi35xxAdcParseInit(struct HdfDeviceObject *device, struct DeviceResourceNode *node)
+ {
+ int32_t ret;
+ struct Hi35xxAdcDevice *hi35xx = NULL; // (Mandatory) Custom structure object
+ (void)device;
+
+ hi35xx = (struct Hi35xxAdcDevice *)OsalMemCalloc(sizeof(*hi35xx)); // (Mandatory) Memory allocation
+ ...
+ ret = Hi35xxAdcReadDrs(hi35xx, node); // (Mandatory) Fill the default values in the adc_config file to the structure.
+ ...
+ hi35xx->regBase = OsalIoRemap(hi35xx->regBasePhy, hi35xx->regSize);// (Mandatory) Address mapping
+ ...
+ hi35xx->pinCtrlBase = OsalIoRemap(HI35XX_ADC_IO_CONFIG_BASE, HI35XX_ADC_IO_CONFIG_SIZE);
+ ...
+ Hi35xxAdcDeviceInit(hi35xx); // (Mandatory) Initialize the ADC.
+ hi35xx->device.priv = (void *)node; // (Mandatory) Store device attributes.
+ hi35xx->device.devNum = hi35xx->deviceNum;// (Mandatory) Initialize the AdcDevice members.
+ hi35xx->device.ops = &g_method; // (Mandatory) Mount the AdcMethod instance object.
+ ret = AdcDeviceAdd(&hi35xx->device); // (Mandatory and important) Call this function to set the structure of the core layer. The driver accesses the platform core layer only after a success signal is returned.
+ ...
+ return HDF_SUCCESS;
+
+ __ERR__:
+ if (hi35xx != NULL) { // If the operation fails, you need to execute the initialization function reversely.
+ if (hi35xx->regBase != NULL) {
+ OsalIoUnmap((void *)hi35xx->regBase);
+ hi35xx->regBase = NULL;
+ }
+ AdcDeviceRemove(&hi35xx->device);
+ OsalMemFree(hi35xx);
+ }
+ return ret;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void Hi35xxAdcRelease(struct HdfDeviceObject *device)
+ {
+ const struct DeviceResourceNode *childNode = NULL;
+ ...
+ // Traverse and parse all nodes in adc_config.hcs and perform the release operation on each node.
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ Hi35xxAdcRemoveByNode(childNode);// The function definition is as follows:
+ }
+ }
+
+ static void Hi35xxAdcRemoveByNode(const struct DeviceResourceNode *node)
+ {
+ int32_t ret;
+ int32_t deviceNum;
+ struct AdcDevice *device = NULL;
+ struct Hi35xxAdcDevice *hi35xx = NULL;
+ struct DeviceResourceIface *drsOps = NULL;
+
+ drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
+ ...
+ ret = drsOps->GetUint32(node, "deviceNum", (uint32_t *)&deviceNum, 0);
+ ...
+ // You can call the AdcDeviceGet function to obtain the AdcDevice object based on deviceNum and call the AdcDeviceRemove function to release the AdcDevice object.
+ device = AdcDeviceGet(deviceNum);
+ if (device != NULL && device->priv == node) {
+ AdcDevicePut(device);
+ AdcDeviceRemove(device); // (Mandatory) Remove the AdcDevice object from the driver manager.
+ hi35xx = (struct Hi35xxAdcDevice *)device;// (Mandatory) Obtain the custom object through forced conversion and release the object.
+ OsalIoUnmap((void *)hi35xx->regBase);
+ OsalMemFree(hi35xx);
+ }
+ return
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-gpio-des.md b/en/device-dev/driver/driver-platform-gpio-des.md
index b18c31bf7b49ba9001b7013596f6f2e5fbfbd4c1..1635338698156e5f8d22c4c3643f3fd795b0b2d7 100644
--- a/en/device-dev/driver/driver-platform-gpio-des.md
+++ b/en/device-dev/driver/driver-platform-gpio-des.md
@@ -1,8 +1,7 @@
-# GPIO
+# GPIO
- [Overview](#section1635911016188)
- - [Available APIs](#section17715915181611)
-
+- [Available APIs](#section589913442203)
- [Usage Guidelines](#section259614242196)
- [How to Use](#section103477714216)
- [Determining a GPIO Pin Number](#section370083272117)
@@ -22,63 +21,63 @@ The GPIO APIs define a set of standard functions for performing operations on GP
- Setting an interrupt service routine \(ISR\) function and interrupt trigger mode for a pin
- Enabling or disabling a pin interrupt
-### Available APIs
+## Available APIs
**Table 1** APIs available for the GPIO driver
-
-Capability
+
+Capability
|
-Function
+ | Function
|
-Description
+ | Description
|
|---|
-GPIO read/write
+ | GPIO read/write
|
-GpioRead
+ | GpioRead
|
-Reads the level value of a GPIO pin.
+ | Reads the level value of a GPIO pin.
|
-GpioWrite
+ | GpioWrite
|
-Writes the level value of a GPIO pin.
+ | Writes the level value of a GPIO pin.
|
-GPIO settings
+ | GPIO settings
|
-GpioSetDir
+ | GpioSetDir
|
-Sets the direction for a GPIO pin.
+ | Sets the direction for a GPIO pin.
|
-GpioGetDir
+ | GpioGetDir
|
-Obtains the direction for a GPIO pin.
+ | Obtains the direction for a GPIO pin.
|
-GPIO interrupt settings
+ | GPIO interrupt settings
|
-GpioSetIrq
+ | GpioSetIrq
|
-Sets the ISR function for a GPIO pin.
+ | Sets the ISR function for a GPIO pin.
|
-GpioUnSetIrq
+ | GpioUnSetIrq
|
-Cancels the setting of the ISR function for a GPIO pin.
+ | Cancels the setting of the ISR function for a GPIO pin.
|
-GpioEnableIrq
+ | GpioEnableIrq
|
-Enables a GPIO interrupt.
+ | Enables a GPIO interrupt.
|
-GpioDisableIrq
+ | GpioDisableIrq
|
-Disables a GPIO interrupt.
+ | Disables a GPIO interrupt.
|
@@ -91,12 +90,10 @@ The GPIO APIs define a set of standard functions for performing operations on GP
### How to Use
-The GPIO APIs use the GPIO pin number to specify a pin. [Figure 1](#fig1399416053717) shows the general process of using a GPIO.
-
-**Figure 1** Process of using a GPIO
-
+The GPIO APIs use the GPIO pin number to specify a pin. [Figure 1](#fig16151101653713) shows the general process of using a GPIO.
-
+**Figure 1** Process of using a GPIO
+
### Determining a GPIO Pin Number
diff --git a/en/device-dev/driver/driver-platform-gpio-develop.md b/en/device-dev/driver/driver-platform-gpio-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..b2efad86b0e769de2ce4acad6b116c3a8563407b
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-gpio-develop.md
@@ -0,0 +1,432 @@
+# GPIO
+
+- [Overview](#section1826197354103451)
+- [How to Develop](#section731175315103451)
+ - [GpioMethod](#section20369125172319)
+
+- [Development Example](#section800425816103451)
+ - [\#section83834353114](#section83834353114)
+
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the general-purpose input/output \(GPIO\) module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
+
+**Figure 1** Service-free mode
+
+
+## How to Develop
+
+The GPIO controller manages all pins by group. The related parameters are described in the attribute file. Instantiating the driver entry and API functions is the core for the vendor driver to access the HDF.
+
+The GPIO module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **gpio\_config.hcs** file.
+
+3. Instantiate the GPIO controller object.
+ - Initialize **GpioCntlr**.
+ - Instantiate **GpioMethod** in the **GpioCntlr** object.
+
+ > **NOTE:**
+ >For details, see [GpioMethod](#section20369125172319) and [Table 1](#table151341544111).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the GPIO control status and response to interrupts.
+
+
+### GpioMethod
+
+```
+struct GpioMethod {
+ int32_t (*request)(struct GpioCntlr *cntlr, uint16_t local);// (Optional)
+ int32_t (*release)(struct GpioCntlr *cntlr, uint16_t local);// (Optional)
+ int32_t (*write)(struct GpioCntlr *cntlr, uint16_t local, uint16_t val);
+ int32_t (*read)(struct GpioCntlr *cntlr, uint16_t local, uint16_t *val);
+ int32_t (*setDir)(struct GpioCntlr *cntlr, uint16_t local, uint16_t dir);
+ int32_t (*getDir)(struct GpioCntlr *cntlr, uint16_t local, uint16_t *dir);
+ int32_t (*toIrq)(struct GpioCntlr *cntlr, uint16_t local, uint16_t *irq);// (Optional)
+ int32_t (*setIrq)(struct GpioCntlr *cntlr, uint16_t local, uint16_t mode, GpioIrqFunc func, void *arg);
+ int32_t (*unsetIrq)(struct GpioCntlr *cntlr, uint16_t local);
+ int32_t (*enableIrq)(struct GpioCntlr *cntlr, uint16_t local);
+ int32_t (*disableIrq)(struct GpioCntlr *cntlr, uint16_t local);
+}
+```
+
+**Table 1** Callbacks for the members in the GpioMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+write
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+val: input level value, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Writes the level of a GPIO pin.
+ |
+
+read
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+ |
+val: pointer to the output level value, which is of the uint16_t type.
+ |
+HDF_STATUS
+ |
+Reads the level of a GPIO pin.
+ |
+
+setDir
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+dir: input pin direction, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the input or output direction for a GPIO pin.
+ |
+
+getDir
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+ |
+dir: pointer to the output pin direction, which is of the uint16_t type.
+ |
+HDF_STATUS
+ |
+Obtains the input or output direction of a GPIO pin.
+ |
+
+setIrq
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+mode: triggering mode, which can be edge or level. The value is of the uint16_t type.
+func: function pointer to the interrupt service handler.
+arg: void pointer to the input parameters of the interrupt service handler.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets an interrupt request (IRQ) for a GPIO pin.
+ |
+
+unsetIrq
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Cancels the GPIO interrupt settings.
+ |
+
+enableIrq
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Enables an interrupt for a GPIO pin.
+ |
+
+disableIrq
+ |
+cntlr: structure pointer to the GPIO controller at the core layer.
+local: GPIO port number, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Disables an interrupt for a GPIO pin.
+ |
+
+
+
+
+## Development Example
+
+The following uses **gpio\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+
+ - GPIO driver entry reference
+
+ ```
+ struct HdfDriverEntry g_gpioDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = Pl061GpioBind, // Bind does not need to be implemented for GPIO. In this example, the implementation is empty. Vendors can add related operations as required.
+ .Init = Pl061GpioInit, // See the Init function.
+ .Release = Pl061GpioRelease, // See the Release function.
+ .moduleName = "hisi_pl061_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_gpioDriverEntry);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **gpio\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **GpioCntlr** members at the core layer.
+
+ In this example, there is only one GPIO controller. If there are multiple GPIO controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **gpio\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_gpio :: device {
+ device0 :: deviceNode {
+ policy = 0; // The value 0 indicates that no service needs to be published.
+ priority = 10; // Driver startup priority
+ permission = 0644; // Permission to create device nodes for the driver
+ moduleName = "hisi_pl061_driver"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ deviceMatchAttr = "hisilicon_hi35xx_pl061";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller information in gpio_config.hcs.
+ // The controller information must be consistent. Other controller information is also contained in the file.
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - **gpio\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ gpio_config {
+ controller_0x120d0000 {
+ match_attr = "hisilicon_hi35xx_pl061"; // (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ groupNum = 12; // (Mandatory) GPIO group index
+ bitNum = 8; // (Mandatory) Number of GPIO pins in each group
+ regBase = 0x120d0000;// (Mandatory) Physical base address
+ regStep = 0x1000; // (Mandatory) Register offset step
+ irqStart = 48; // (Mandatory) Start an IRQ.
+ irqShare = 0; // (Mandatory) Share the IRQ.
+ }
+ }
+ }
+ }
+ ```
+
+3. Initialize the **GpioCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **GpioMethod** \(used to call underlying functions of the driver\) in **GpioCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **gpio\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the index and the number of pins, are also passed to the **GpioCntlr** object at the core layer.
+
+ ```
+ struct Pl061GpioCntlr {
+ struct GpioCntlr cntlr;// (Mandatory) Control object of the core layer. For details about the member definitions, see the following description.
+ volatile unsigned char *regBase; // (Mandatory) Base address of the register
+ uint32_t phyBase; // (Mandatory) Physical base address
+ uint32_t regStep; // (Mandatory) Register offset step
+ uint32_t irqStart; // (Mandatory) Start an IRQ.
+ uint16_t groupNum; // (Mandatory) GPIO port number
+ uint16_t bitNum; // (Mandatory) GPIO port number
+ uint8_t irqShare; // (Mandatory) Share the IRQ.
+ struct Pl061GpioGroup *groups; // (Optional) Set based on the vendor's requirements.
+ };
+ struct Pl061GpioGroup {// Register address, interrupt number, interrupt function, and lock
+ volatile unsigned char *regBase;
+ unsigned int index;
+ unsigned int irq;
+ OsalIRQHandle irqFunc;
+ OsalSpinlock lock;
+ };
+
+ // GpioCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct GpioCntlr {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ struct GpioMethod *ops;
+ struct DListHead list;
+ OsalSpinlock spin;
+ uint16_t start;
+ uint16_t count;
+ struct GpioInfo *ginfos;
+ void *priv;
+ };
+ ```
+
+ - Instantiate the callback function structure **GpioMethod** in **GpioCntlr**. Other members are initialized by using the **Init** function.
+
+ ```
+ // The members of the GpioMethod structure are all callbacks. Vendors need to implement the corresponding functions according to [Table 1](#table151341544111).
+ static struct GpioMethod g_method = {
+ .request = NULL,
+ .release = NULL,
+ .write = Pl061GpioWrite, // Write pin settings.
+ .read = Pl061GpioRead, // Read pin settings.
+ .setDir = Pl061GpioSetDir, // Set the pin direction.
+ .getDir = Pl061GpioGetDir, // Obtain the pin direction.
+ .toIrq = NULL,
+ .setIrq = Pl061GpioSetIrq, // Set an interrupt for the pin. If this capability is not available, skip it.
+ .unsetIrq = Pl061GpioUnsetIrq, // Cancel the interrupt settings for the pin. If this capability is not available, skip it.
+ .enableIrq = Pl061GpioEnableIrq, // Enable an interrupt for the pin. If this capability is not available, skip it.
+ .disableIrq = Pl061GpioDisableIrq,// Disable the interrupt for the pin. If this capability is not available, skip it.
+ };
+ ```
+
+
+
+- Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Init function description
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **GpioCntlr**, calls the **GpioCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
+
+ ```
+ static int32_t Pl061GpioInit(struct HdfDeviceObject *device)
+ {
+ ...
+ struct Pl061GpioCntlr *pl061 = &g_pl061;// Use static global variables to complete initialization.
+ //static struct Pl061GpioCntlr g_pl061 = {
+ // .groups = NULL,
+ // .groupNum = PL061_GROUP_MAX,
+ // .bitNum = PL061_BIT_MAX,
+ //};
+ ret = Pl061GpioReadDrs(pl061, device->property);// Use the attribute values read from the gpio_config.HCS file to initialize the members of the custom structure object.
+ ...
+ pl061->regBase = OsalIoRemap(pl061->phyBase, pl061->groupNum * pl061->regStep);// Address mapping
+ ...
+ ret = Pl061GpioInitCntlrMem(pl061); // Apply for memory.
+ ...
+ pl061->cntlr.count = pl061->groupNum x pl061->bitNum;// (Mandatory) Calculate the number of pins.
+ pl061->cntlr.priv = (void *)device->property; // (Mandatory) Store device attributes.
+ pl061->cntlr.ops = &g_method; // (Mandatory) Connect to the GpioMethod instance.
+ pl061->cntlr.device = device; // (Mandatory) Enable conversion between HdfDeviceObject and GpioCntlr.
+ ret = GpioCntlrAdd(&pl061->cntlr); // (Mandatory) Call this function to set the structure of the core layer. The driver accesses the platform core layer only after a success signal is returned.
+ ...
+ Pl061GpioDebugCntlr(pl061);
+ #ifdef PL061_GPIO_USER_SUPPORT // (Optional) Access the user-level virtual file system if supported.
+ if (GpioAddVfs(pl061->bitNum) != HDF_SUCCESS) {
+ HDF_LOGE("%s: add vfs fail!", __func__);
+ }
+ #endif
+ ...
+ }
+ ```
+
+- Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void Pl061GpioRelease(struct HdfDeviceObject *device)
+ {
+ struct GpioCntlr *cntlr = NULL;
+ struct Pl061GpioCntlr *pl061 = NULL;
+ ...
+ cntlr = GpioCntlrFromDevice(device);// (Mandatory) Obtain the control object of the core layer through forced conversion.
+ //return (device == NULL) ? NULL : (struct GpioCntlr *)device->service;
+ ...
+ #ifdef PL061_GPIO_USER_SUPPORT
+ GpioRemoveVfs();// Perform operations reverse to GpioAddVfs in Init.
+ #endif
+ GpioCntlrRemove(cntlr); // (Mandatory) Remove the device information and services from the core layer.
+ pl061 = ToPl061GpioCntlr(cntlr); //return (struct Pl061GpioCntlr *)cntlr;
+ Pl061GpioRleaseCntlrMem(pl061); // (Mandatory) Release the lock and memory.
+ OsalIoUnmap((void *)pl061->regBase);// (Mandatory) Remove the address mapping.
+ pl061->regBase = NULL;
+ }
+ ```
+
+
diff --git a/en/device-dev/driver/driver-platform-i2c-des.md b/en/device-dev/driver/driver-platform-i2c-des.md
index 7b70a9fbd022795d0bdbfd142626fdeecf61346d..f0fc3530d5fef97b40bbe31aa912c9a6522bb2ff 100644
--- a/en/device-dev/driver/driver-platform-i2c-des.md
+++ b/en/device-dev/driver/driver-platform-i2c-des.md
@@ -1,8 +1,7 @@
-# I2C
+# I2C
- [Overview](#section5361140416)
- - [Available APIs](#section459052019177)
-
+- [Available APIs](#section545869122317)
- [Usage Guidelines](#section1695201514281)
- [How to Use](#section1338373417288)
- [Opening an I2C Controller](#section13751110132914)
@@ -25,10 +24,10 @@
- I2C message transfer: custom transfer by using a message array
**Figure 1** Physical connection diagram for I2C
- 
+ 
-### Available APIs
+## Available APIs
**Table 1** APIs available for the I2C driver
@@ -70,12 +69,10 @@
### How to Use
-[Figure 2](#fig166181128151112) illustrates the process of an I2C device.
-
-**Figure 2** Process of using an I2C device
-
+[Figure 2](#fig183017194234) illustrates the process of an I2C device.
-
+**Figure 2** Process of using an I2C device
+
### Opening an I2C Controller
@@ -405,7 +402,7 @@ static int32_t TestCaseI2c(void)
}
OsalMSleep(10);
- /* Continuously read 7-byte data from register 0xDO of TP-IC. */
+ /* Continuously read 7-byte data from register 0xD5 of TP-IC. */
ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7);
if (ret != HDF_SUCCESS) {
HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret);
diff --git a/en/device-dev/driver/driver-platform-i2c-develop.md b/en/device-dev/driver/driver-platform-i2c-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..695b0ec78f6a46200b45db639d66a746c2c502e2
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-i2c-develop.md
@@ -0,0 +1,399 @@
+# I2C
+
+- [Overview](#section2040078630114257)
+- [How to Develop](#section1085786591114257)
+ - [I2cMethod and I2cLockMethod](#section1683458184518)
+
+- [Development Example](#section1773332551114257)
+
+## Overview
+
+The Inter-Integrated Circuit \(I2C\) bus is a simple and bidirectional two-wire synchronous serial bus developed by Philips. In the HDF framework, the I2C module uses the unified service mode for API adaptation. In this mode, a device service is used as the I2C manager to handle external access requests in a unified manner, which is reflected in the configuration file. The unified service mode applies to the scenario where there are many device objects of the same type, for example, when the I2C module has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services.
+
+**Figure 1** Unified service mode
+
+
+## How to Develop
+
+The I2C module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **i2c\_config.hcs** file.
+
+3. Instantiate the I2C controller object.
+ - Initialize **I2cCntlr**.
+ - Instantiate **I2cMethod** and **I2cLockMethod** in **I2cCntlr**.
+
+ > **NOTE:**
+ >For details, see [I2cMethod and I2cLockMethod](#section1683458184518) and [Table 1](#table10549174014611).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
+
+
+### I2cMethod and I2cLockMethod
+
+```
+struct I2cMethod {
+int32_t (*transfer)(struct I2cCntlr *cntlr, struct I2cMsg *msgs, int16_t count);
+};
+struct I2cLockMethod {// Lock mechanism operation structure
+ int32_t (*lock)(struct I2cCntlr *cntlr); // Add a lock.
+ void (*unlock)(struct I2cCntlr *cntlr); // Release the lock.
+};
+```
+
+**Table 1** Callbacks for the members in the I2cMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+transfer
+ |
+cntlr: structure pointer to the I2C controller at the core layer. msgs: structure pointer to the user message. count: number of messages, which is of the uint16_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Transfers user messages.
+ |
+
+
+
+
+## Development Example
+
+The following uses **i2c\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - I2C driver entry reference
+
+ Many devices may be connected to the I2C module. Therefore, in the HDF framework, a manager object is created for the I2C, and a manager service is launched to handle external access requests in a unified manner. When a user wants to open a device, the user obtains the manager service first. Then, the manager service locates the target device based on the parameters specified by the user.
+
+ The driver of the I2C manager is implemented by the core layer. Vendors do not need to pay attention to the implementation of this part. However, when they implement the **Init** function, the **I2cCntlrAdd** function of the core layer must be called to implement the corresponding features.
+
+ ```
+ struct HdfDriverEntry g_i2cDriverEntry = {
+ .moduleVersion = 1,
+ .Init = Hi35xxI2cInit,
+ .Release = Hi35xxI2cRelease,
+ .moduleName = "hi35xx_i2c_driver",// (Mandatory) The value must be the same as that in the config.hcs file.
+ };
+ HDF_INIT(g_i2cDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
+
+ // Driver entry of the i2c_core.c manager service at the core layer
+ struct HdfDriverEntry g_i2cManagerEntry = {
+ .moduleVersion = 1,
+ .Bind = I2cManagerBind,
+ .Init = I2cManagerInit,
+ .Release = I2cManagerRelease,
+ .moduleName = "HDF_PLATFORM_I2C_MANAGER",// This parameter corresponds to device0 in the device_info file.
+ };
+ HDF_INIT(g_i2cManagerEntry);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **i2c\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or value ranges of the **I2cCntlr** members at the core layer.
+
+ In the unified service mode, the first device node in the **device\_info** file must be the I2C manager. [Table 2](#table96651915911) lists settings of its parameters.
+
+ **Table 2** Settings of the I2C manager
+
+
+ Member
+ |
+ Value
+ |
+
|---|
+
+ moduleName
+ |
+ It has a fixed value of HDF_PLATFORM_I2C_MANAGER.
+ |
+
+ serviceName
+ |
+ It has a fixed value of HDF_PLATFORM_I2C_MANAGER.
+ |
+
+ policy
+ |
+ The value can be 1 or 2, depending on whether it is visible to the user mode.
+ |
+
+ deviceMatchAttr
+ |
+ This parameter is not used.
+ |
+
+
+
+
+ Configure I2C controller information from the second node. This node specifies a type of I2C controllers rather than an I2C controller. The **busID** and **reg\_pbase** parameters distinguish controllers, which can be seen in the **i2c\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ device_i2c :: device {
+ device0 :: deviceNode {
+ policy = 2;
+ priority = 50;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_I2C_MANAGER";
+ serviceName = "HDF_PLATFORM_I2C_MANAGER";
+ deviceMatchAttr = "hdf_platform_i2c_manager";
+ }
+ device1 :: deviceNode {
+ policy = 0; // The value 0 indicates that no service needs to be published.
+ priority = 55; // Driver startup priority
+ permission = 0644; // Permission for the driver to create a device node
+ moduleName = "hi35xx_i2c_driver"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HI35XX_I2C_DRIVER"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_i2c";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller in i2c_config.hcs.
+ } // The specific controller information is in i2c_config.hcs.
+ }
+ }
+ }
+ }
+ ```
+
+ - **i2c\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ i2c_config {
+ match_attr = "hisilicon_hi35xx_i2c";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ template i2c_controller { // Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ bus = 0; // (Mandatory) I2C ID
+ reg_pbase = 0x120b0000; // (Mandatory) Physical base address
+ reg_size = 0xd1; // (Mandatory) Register bit width
+ irq = 0; // (Optional) Configured based on the vendor's requirements.
+ freq = 400000; // (Optional) Configured based on the vendor's requirements.
+ clk = 50000000; // (Optional) Configured based on the vendor's requirements.
+ }
+ controller_0x120b0000 :: i2c_controller {
+ bus = 0;
+ }
+ controller_0x120b1000 :: i2c_controller {
+ bus = 1;
+ reg_pbase = 0x120b1000;
+ }
+ ...
+ }
+ }
+ }
+ ```
+
+3. Initialize the **I2cCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **I2cMethod** \(used to call underlying functions of the driver\) in **I2cCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **i2c\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the **I2cCntlr** object at the core layer.
+
+ ```
+ // Vendor custom function structure
+ struct Hi35xxI2cCntlr {
+ struct I2cCntlr cntlr; // (Mandatory) Control object of the core layer. For details, see the following description.
+ OsalSpinlock spin; // (Mandatory) The vendor needs to implement lock and unlock for I2C operation functions based on this variable.
+ volatile unsigned char *regBase; // (Mandatory) Base address of the register
+ uint16_t regSize; // (mandatory) Bit width of the register
+ int16_t bus; // (Mandatory) The value can be read from the i2c_config.hcs file.
+ uint32_t clk; // (Optional) Customized by the vendor.
+ uint32_t freq; // (Optional) Customized by the vendor.
+ uint32_t irq; // (Optional) Customized by the vendor.
+ uint32_t regBasePhy; // (Mandatory) Physical base address of the register
+ };
+
+ // I2cCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct I2cCntlr {
+ struct OsalMutex lock;
+ void *owner;
+ int16_t busId;
+ void *priv;
+ const struct I2cMethod *ops;
+ const struct I2cLockMethod *lockOps;
+ };
+ ```
+
+ - Instantiate the member callback function structure **I2cMethod** in **I2cCntlr** and the lock callback function structure **I2cLockMethod**. Other members are initialized by using the **Init** function.
+
+ ```
+ // Example in i2c_hi35xx.c
+ static const struct I2cMethod g_method = {
+ .transfer = Hi35xxI2cTransfer,
+ };
+
+ static const struct I2cLockMethod g_lockOps = {
+ .lock = Hi35xxI2cLock, // Lock function
+ .unlock = Hi35xxI2cUnlock,// Unlock function
+ };
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 3** Input parameters and return values of the Init function
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Transmission successful
+ |
+
+ HDF_FAILURE
+ |
+ Transmission failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **I2cCntlr**, calls the **I2cCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
+
+ ```
+ static int32_t Hi35xxI2cInit(struct HdfDeviceObject *device)
+ {
+ ...
+ // Traverse and parse all nodes in i2c_config.hcs and call Hi35xxI2cParseAndInit to initialize the devices separately.
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ ret = Hi35xxI2cParseAndInit(device, childNode);// For details about the function definition, see the following description.
+ ...
+ }
+ ...
+ }
+
+ static int32_t Hi35xxI2cParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node)
+ {
+ struct Hi35xxI2cCntlr *hi35xx = NULL;
+ ...
+ hi35xx = (struct Hi35xxI2cCntlr *)OsalMemCalloc(sizeof(*hi35xx)); // Apply for memory.
+ ...
+ hi35xx->regBase = OsalIoRemap(hi35xx->regBasePhy, hi35xx->regSize); // Address mapping
+ ...
+ Hi35xxI2cCntlrInit(hi35xx); // (Mandatory) Initialize the I2C device.
+
+ hi35xx->cntlr.priv = (void *)node; // (Mandatory) Store device attributes.
+ hi35xx->cntlr.busId = hi35xx->bus; // (Mandatory) Initialize busId in I2cCntlr.
+ hi35xx->cntlr.ops = &g_method; // (Mandatory) Connect to the I2cMethod instance.
+ hi35xx->cntlr.lockOps = &g_lockOps; // (Mandatory) Connect to the I2cLockMethod instance.
+ (void)OsalSpinInit(&hi35xx->spin); // (Mandatory) Initialize the lock.
+ ret = I2cCntlrAdd(&hi35xx->cntlr); // (Mandatory) Call this function to set the structure of the core layer. The driver accesses the platform core layer only after a success signal is returned.
+ ...
+ #ifdef USER_VFS_SUPPORT
+ (void)I2cAddVfsById(hi35xx->cntlr.busId);// (Optional) Connect the driver to the user-level virtual file system supported.
+ #endif
+ return HDF_SUCCESS;
+ __ERR__: // If the operation fails, execute the initialization function reversely.
+ if (hi35xx != NULL) {
+ if (hi35xx->regBase != NULL) {
+ OsalIoUnmap((void *)hi35xx->regBase);
+ hi35xx->regBase = NULL;
+ }
+ OsalMemFree(hi35xx);
+ hi35xx = NULL;
+ }
+ return ret;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
+
+ ```
+ static void Hi35xxI2cRelease(struct HdfDeviceObject *device)
+ {
+ ...
+ // Release each node separately, like Hi35xxI2cInit.
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ Hi35xxI2cRemoveByNode(childNode);// The function definition is as follows:
+ }
+ }
+
+ static void Hi35xxI2cRemoveByNode(const struct DeviceResourceNode *node)
+ {
+ ...
+ // (Mandatory) Call the I2cCntlrGet function obtain the I2cCntlr object based on busid of the device, and call the I2cCntlrRemove function to release the I2cCntlr object.
+ cntlr = I2cCntlrGet(bus);
+ if (cntlr != NULL && cntlr->priv == node) {
+ ...
+ I2cCntlrRemove(cntlr);
+ // (Mandatory) Remove the address mapping and release the lock and memory.
+ hi35xx = (struct Hi35xxI2cCntlr *)cntlr;
+ OsalIoUnmap((void *)hi35xx->regBase);
+ (void)OsalSpinDestroy(&hi35xx->spin);
+ OsalMemFree(hi35xx);
+ }
+ return;
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-mipidsi-des.md b/en/device-dev/driver/driver-platform-mipidsi-des.md
index 250a419f0ee64f2364f03478a247bb11c0ff6d90..faba7009a138b2d34bed9f52e4fbabc625c020a8 100644
--- a/en/device-dev/driver/driver-platform-mipidsi-des.md
+++ b/en/device-dev/driver/driver-platform-mipidsi-des.md
@@ -1,8 +1,7 @@
-# MIPI DSI
+# MIPI DSI
- [Overview](#section16806142183217)
- - [Available APIs](#section129611916132011)
-
+- [Available APIs](#section12720125432316)
- [Usage Guidelines](#section037231715335)
- [How to Use](#section49299119344)
- [Obtains a MIPI DSI device handle.](#section5126155683811)
@@ -20,10 +19,10 @@
- [Figure 1](#fig1122611461203) shows a simplified DSI interface. Conceptually, a DSI-compliant interface has the same features as interfaces complying with DBI-2 and DPI-2 standards. It sends pixels or commands to a peripheral and can read status or pixel information from the peripheral. The main difference is that the DSI serializes all pixel data, commands, and events that, in traditional interfaces, are conveyed to and from the peripheral on a parallel data bus with additional control signals.
**Figure 1** DSI transmitting and receiving interface
- 
+ 
-### Available APIs
+## Available APIs
**Table 1** APIs for MIPI DSI
@@ -94,12 +93,10 @@
### How to Use
-[Figure 2](#fig99821771782) shows the process of using a MIPI DSI device.
-
-**Figure 2** Process of using a MIPI DSI device
-
+[Figure 2](#fig129103491241) shows the process of using a MIPI DSI device.
-
+**Figure 2** Process of using a MIPI DSI device
+
### Obtains a MIPI DSI device handle.
diff --git a/en/device-dev/driver/driver-platform-mipidsi-develop.md b/en/device-dev/driver/driver-platform-mipidsi-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..f6cb0c843b35315d6de4f3a84b32bd9ff293713f
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-mipidsi-develop.md
@@ -0,0 +1,338 @@
+# MIPI-DSI
+
+- [Overview](#section1266787503161538)
+- [How to Develop](#section545182932161538)
+ - [MipiDsiCntlrMethod](#section10711202141617)
+
+- [Development Example](#section1167576616161538)
+
+## Overview
+
+The Display Serial Interface \(DSI\) is a specification developed by the Mobile Industry Processor Interface \(MIPI\) Alliance to reduce the cost of display controllers in mobile devices. In the HDF framework, the MIPI-DSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
+
+**Figure 1** Service-free mode
+
+
+## How to Develop
+
+The MIPI-DSI module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **mipidsi\_config.hcs** file.
+
+3. Instantiate the MIPI-DSI controller object.
+ - Initialize **MipiDsiCntlr**.
+ - Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
+
+ > **NOTE:**
+ >For details, see [MipiDsiCntlrMethod](#section10711202141617) and [Table 1](#table218771071713).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
+
+
+### MipiDsiCntlrMethod
+
+```
+struct MipiDsiCntlrMethod {// Member functions of the core layer structure
+ int32_t (*setCntlrCfg)(struct MipiDsiCntlr *cntlr);
+ int32_t (*setCmd)(struct MipiDsiCntlr *cntlr, struct DsiCmdDesc *cmd);
+ int32_t (*getCmd)(struct MipiDsiCntlr *cntlr, struct DsiCmdDesc *cmd, uint32_t readLen, uint8_t *out);
+ void (*toHs)(struct MipiDsiCntlr *cntlr);
+ void (*toLp)(struct MipiDsiCntlr *cntlr);
+ void (*enterUlps)(struct MipiDsiCntlr *cntlr);//(Optional) Enter the ultra-low power consumption mode.
+ void (*exitUlps)(struct MipiDsiCntlr *cntlr); // (Optional) Exit the ultra-low power consumption mode.
+ int32_t (*powerControl)(struct MipiDsiCntlr *cntlr, uint8_t enable);// (Optional) Enable or disable power control.
+ int32_t (*attach)(struct MipiDsiCntlr *cntlr);// (Optional) Connect a DSI device to the host.
+};
+```
+
+**Table 1** Callbacks for the members in the MipiDsiCntlrMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+setCntlrCfg
+ |
+cntlr: structure pointer to the MIPI-DSI controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets controller parameters.
+ |
+
+setCmd
+ |
+cntlr: structure pointer to the MIPI-DSI controller.
+cmd: structure pointer to the input instruction.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sends instructions to a display device.
+ |
+
+getCmd
+ |
+cntlr: structure pointer to the MIPI-DSI controller.
+ |
+cmd: structure pointer to the instruction to output.
+ |
+HDF_STATUS
+ |
+Reads instructions from the display device.
+ |
+
+toHs
+ |
+cntlr: structure pointer to the MIPI-DSI controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the high-speed mode.
+ |
+
+toLp
+ |
+cntlr: structure pointer to the MIPI-DSI controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the low-power mode.
+ |
+
+
+
+
+## Development Example
+
+The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Generally, you need to configure the device attributes in **xx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiDsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
+
+ In this example, no additional attribute needs to be configured for the MIPI-DSI controller. If required, you need to add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the **mipidsi\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_mipi_dsi:: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 150;
+ permission = 0644;
+ moduleName = "HDF_MIPI_TX"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HDF_MIPI_TX";// (Mandatory) Unique name of the service published by the driver
+ }
+ }
+ }
+ }
+ }
+ ```
+
+2. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+
+ - MIPI-DSI driver entry reference
+
+ ```
+ struct HdfDriverEntry g_mipiTxDriverEntry = {
+ .moduleVersion = 1,
+ .Init = Hi35xxMipiTxInit, // See the Init function.
+ .Release = Hi35xxMipiTxRelease, //See the Release function.
+ .moduleName = "HDF_MIPI_TX", // (Mandatory) The value must be the same as that in the device_info.hcs file.
+ };
+ HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
+ ```
+
+3. Initialize the **MipiDsiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MipiDsiCntlrMethod** \(used to call underlying functions of the driver\) in **MipiDsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI-DSI has no device attribute file. Therefore, the basic member structure is similar to that of **MipiDsiCntlr**.
+
+ ```
+ typedef struct {
+ unsigned int devno; // Device number
+ short laneId[LANE_MAX_NUM]; // Lane ID
+ OutPutModeTag outputMode; // Output mode, which can be csi mode, dsi video mode, or dsi command mode.
+ VideoModeTag videoMode; // Synchronization mode of the display device
+ OutputFormatTag outputFormat; // Format of the output DSI image, which can be RGB or YUV.
+ SyncInfoTag syncInfo; // Settings related to timing
+ unsigned int phyDataRate; // mbps
+ unsigned int pixelClk; // KHz
+ } ComboDevCfgTag;
+
+ // MipiDsiCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct MipiDsiCntlr {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ unsigned int devNo; // Device number
+ struct MipiCfg cfg;
+ struct MipiDsiCntlrMethod *ops;
+ struct OsalMutex lock;
+ void *priv;
+ };
+ ```
+
+ - Instantiate the callback function structure **MipiDsiCntlrMethod** in **MipiDsiCntlr**. Other members are initialized by using the **Init** function.
+
+ ```
+ static struct MipiDsiCntlrMethod g_method = {
+ .setCntlrCfg = Hi35xxSetCntlrCfg,
+ .setCmd = Hi35xxSetCmd,
+ .getCmd = Hi35xxGetCmd,
+ .toHs = Hi35xxToHs,
+ .toLp = Hi35xxToLp,
+ };
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Operation successful
+ |
+
+ HDF_FAILURE
+ |
+ Operation failed
+ |
+
+
+
+
+ Function description:
+
+ Connects to the **MipiDsiCntlrMethod** instance, calls **MipiDsiRegisterCntlr**, and performs other vendor-defined initialization operations.
+
+ ```
+ static int32_t Hi35xxMipiTxInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ g_mipiTx.priv = NULL; // g_mipiTx is a global variable defined.
+ //static struct MipiDsiCntlr g_mipiTx {
+ // .devNo=0
+ //};
+ g_mipiTx.ops = &g_method;// Connect to the MipiDsiCntlrMethod instance.
+ ret = MipiDsiRegisterCntlr(&g_mipiTx, device);// (Mandatory) Call the function at the core layer and g_mipiTx to initialize global variables at the core layer.
+ ...
+ return MipiTxDrvInit(0); // (Mandatory) Device initialization customized by the vendor.
+ }
+
+ //mipi_dsi_core.c, core layer file.
+ int32_t MipiDsiRegisterCntlr(struct MipiDsiCntlr *cntlr, struct HdfDeviceObject *device)
+ {
+ ...
+ // Define the global variable static struct MipiDsiHandle g_mipiDsihandle[MAX_CNTLR_CNT].
+ if (g_mipiDsihandle[cntlr->devNo].cntlr == NULL) {
+ (void)OsalMutexInit(&g_mipiDsihandle[cntlr->devNo].lock);
+ (void)OsalMutexInit(&(cntlr->lock));
+
+ g_mipiDsihandle[cntlr->devNo].cntlr = cntlr;// Initialize MipiDsiHandle.
+ g_mipiDsihandle[cntlr->devNo].priv = NULL;
+ cntlr->device = device; // Enable conversion between HdfDeviceObject and MipiDsiHandle.
+ device->service = &(cntlr->service); // Enable conversion between HdfDeviceObject and MipiDsiHandle.
+ cntlr->priv = NULL;
+ ...
+ return HDF_SUCCESS;
+ }
+ ...
+ return HDF_FAILURE;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void Hi35xxMipiTxRelease(struct HdfDeviceObject *device)
+ {
+ struct MipiDsiCntlr *cntlr = NULL;
+ ...
+ cntlr = MipiDsiCntlrFromDevice(device);// A forced conversion from HdfDeviceObject to MipiDsiCntlr is involved.
+ //return (device == NULL) ? NULL : (struct MipiDsiCntlr *)device->service;
+ ...
+ MipiTxDrvExit(); // (Mandatory) Release the resources occupied by the vendor's devices.
+ MipiDsiUnregisterCntlr(&g_mipiTx); // Empty function
+ g_mipiTx.priv = NULL;
+ HDF_LOGI("%s: unload mipi_tx driver 1212!", __func__);
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-mmc-develop.md b/en/device-dev/driver/driver-platform-mmc-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..98e853395b30766ac9bec61b981da6d85a9ea620
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-mmc-develop.md
@@ -0,0 +1,559 @@
+# MMC
+
+- [Overview](#section1846388309162704)
+- [How to Develop](#section1617495117162704)
+ - [MmcCntlrOps](#section6203107192915)
+
+- [Development Example](#section1220893490162704)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the MultiMedia Card \(MMC\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The MMC module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **mmc\_config.hcs** file.
+
+3. Instantiate the MMC controller object.
+ - Initialize **MmcCntlr**.
+ - Instantiate **MmcCntlrOps** in the **MmcCntlr** object.
+
+ > **NOTE:**
+ >For details, see [MmcCntlrOps](#section6203107192915) and [Table 1](#table99129433019).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the mount operation and whether the device starts successfully.
+
+
+### MmcCntlrOps
+
+```
+struct MmcCntlrOps {
+ int32_t (*request)(struct MmcCntlr *cntlr, struct MmcCmd *cmd);
+ int32_t (*setClock)(struct MmcCntlr *cntlr, uint32_t clock);
+ int32_t (*setPowerMode)(struct MmcCntlr *cntlr, enum MmcPowerMode mode);
+ int32_t (*setBusWidth)(struct MmcCntlr *cntlr, enum MmcBusWidth width);
+ int32_t (*setBusTiming)(struct MmcCntlr *cntlr, enum MmcBusTiming timing);
+ int32_t (*setSdioIrq)(struct MmcCntlr *cntlr, bool enable);
+ int32_t (*hardwareReset)(struct MmcCntlr *cntlr);
+ int32_t (*systemInit)(struct MmcCntlr *cntlr);
+ int32_t (*setEnhanceSrobe)(struct MmcCntlr *cntlr, bool enable);
+ int32_t (*switchVoltage)(struct MmcCntlr *cntlr, enum MmcVolt volt);
+ bool (*devReadOnly)(struct MmcCntlr *cntlr);
+ bool (*devPluged)(struct MmcCntlr *cntlr);
+ bool (*devBusy)(struct MmcCntlr *cntlr);
+ int32_t (*tune)(struct MmcCntlr *cntlr, uint32_t cmdCode);
+ int32_t (*rescanSdioDev)(struct MmcCntlr *cntlr);
+};
+```
+
+**Table 1** Callbacks for the members in the MmcCntlrOps structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+doRequest
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+cmd: structure pointer to the input command.
+ |
+HDF_STATUS
+ |
+Processes the request.
+ |
+
+setClock
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+clock: input clock value.
+ |
+HDF_STATUS
+ |
+Sets the clock frequency.
+ |
+
+setPowerMode
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+mode: power consumption mode. It is an enumerated value (see MmcPowerMode).
+ |
+HDF_STATUS
+ |
+Sets the power consumption mode.
+ |
+
+setBusWidth
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+width: bus width. It is an enumerated value (see MmcBusWidth).
+ |
+HDF_STATUS
+ |
+Sets the bus width.
+ |
+
+setBusTiming
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+timing: bus timing. It is an enumerated value (see MmcBusTiming).
+ |
+HDF_STATUS
+ |
+Sets the bus timing.
+ |
+
+setSdioIrq
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+enable: specifies whether to enable interrupt.
+ |
+HDF_STATUS
+ |
+Enables or disables Secure Digital Input Output (SDIO) interrupt.
+ |
+
+hardwareReset
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+HDF_STATUS
+ |
+Resets hardware.
+ |
+
+systemInit
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+HDF_STATUS
+ |
+Performs system initialization.
+ |
+
+setEnhanceSrobe
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+enable: specifies whether to enable the enhanced strobe feature.
+ |
+HDF_STATUS
+ |
+Sets the enhanced strobe feature.
+ |
+
+switchVoltage
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+volt: voltage, which can be 3.3 V, 1.8 V, or 1.2 V. It is an enumerated value.
+ |
+HDF_STATUS
+ |
+Set the voltage.
+ |
+
+devReadOnly
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+Boolean
+ |
+Checks whether the device is read-only.
+ |
+
+cardPluged
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+Boolean
+ |
+Checks whether the device is removed.
+ |
+
+devBusy
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+Boolean
+ |
+Checks whether the device is engaged.
+ |
+
+tune
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+cmdCode: command code of the uint32_t type.
+ |
+HDF_STATUS
+ |
+Tunes
+ |
+
+rescanSdioDev
+ |
+cntlr: structure pointer to the MMC controller at the core layer.
+ |
+HDF_STATUS
+ |
+Scans and adds an SDIO device.
+ |
+
+
+
+
+## Development Example
+
+The following uses **himci.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - MMC driver entry reference
+
+ ```
+ struct HdfDriverEntry g_mmcDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = HimciMmcBind, // See the Bind function.
+ .Init = HimciMmcInit, // See the Init function.
+ .Release = HimciMmcRelease, //See the Release function.
+ .moduleName = "hi3516_mmc_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ };
+ HDF_INIT(g_mmcDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **mmc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **MmcCntlr** members at the core layer.
+
+ If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **mmc\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_mmc:: device {
+ device0 :: deviceNode {
+ policy = 2;
+ priority = 10;
+ permission = 0644;
+ moduleName = "hi3516_mmc_driver"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HDF_PLATFORM_MMC_0"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hi3516_mmc_emmc";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller in mmc_config.hcs.
+ }
+ device1 :: deviceNode {
+ policy = 1;
+ priority = 20;
+ permission = 0644;
+ moduleName = "hi3516_mmc_driver";
+ serviceName = "HDF_PLATFORM_MMC_1";
+ deviceMatchAttr = "hi3516_mmc_sd"; // Indicates an SD.
+ }
+ device2 :: deviceNode {
+ policy = 1;
+ priority = 30;
+ permission = 0644;
+ moduleName = "hi3516_mmc_driver";
+ serviceName = "HDF_PLATFORM_MMC_2";
+ deviceMatchAttr = "hi3516_mmc_sdio";// Indicates an SDIO.
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - **mmc\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ mmc_config {
+ template mmc_controller {// Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ match_attr = "";
+ voltDef = 0; // 3.3V
+ freqMin = 50000; // (Mandatory) Minimum frequency
+ freqMax = 100000000; // (Mandatory) Maximum frequency
+ freqDef = 400000; // (Mandatory) Default frequency
+ maxBlkNum = 2048; // (Mandatory) Maximum block number
+ maxBlkSize = 512; // (Mandatory) Maximum number of blocks
+ ocrDef = 0x300000; // (Mandatory) Set the working voltage.
+ caps2 = 0; // (Mandatory) Set the attribute register. For details, see MmcCaps2 in mmc_caps.h.
+ regSize = 0x118; // (Mandatory) Register bit width
+ hostId = 0; // (Mandatory) Host ID
+ regBasePhy = 0x10020000;// (Mandatory) Physical base address of the register
+ irqNum = 63; // (Mandatory) Interrupt number
+ devType = 2; // (Mandatory) Device mode, which can be eMMC, SD, SDIO, or COMBO
+ caps = 0x0001e045; // (Mandatory) Set the attribute register. For details, see MmcCaps in mmc_caps.h.
+ }
+ controller_0x10100000 :: mmc_controller {
+ match_attr = "hi3516_mmc_emmc";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ hostId = 0;
+ regBasePhy = 0x10100000;
+ irqNum = 96;
+ devType = 0; // The value 0 indicates an embedded MultiMedia card (eMMC).
+ caps = 0xd001e045;
+ caps2 = 0x60;
+ }
+ controller_0x100f0000 :: mmc_controller {
+ match_attr = "hi3516_mmc_sd";
+ hostId = 1;
+ regBasePhy = 0x100f0000;
+ irqNum = 62;
+ devType = 1; // The value 1 indicates a Secure Digital (SD) card.
+ caps = 0xd001e005;
+ }
+ controller_0x10020000 :: mmc_controller {
+ match_attr = "hi3516_mmc_sdio";
+ hostId = 2;
+ regBasePhy = 0x10020000;
+ irqNum = 63;
+ devType = 2; // The value 2 indicates a Secure Digital Input Output (SDIO) device.
+ caps = 0x0001e04d;
+ }
+ }
+ }
+ }
+ ```
+
+3. Initialize the **MmcCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MmcCntlrOps** \(used to call underlying functions of the driver\) in **MmcCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **mmc\_config.hcs** file are read by the HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values are also transferred to the objects at the core layer.
+
+ ```
+ struct HimciHost {
+ struct MmcCntlr *mmc;// (Mandatory) Core layer structure
+ struct MmcCmd *cmd; // (Mandatory) Core layer structure used to transfer commands. For details about related commands, see MmcCmdCode.
+ //(Optional) Set parameters based on the vendor's requirements.
+ void *base;
+ enum HimciPowerStatus powerStatus;
+ uint8_t *alignedBuff;
+ uint32_t buffLen;
+ struct scatterlist dmaSg;
+ struct scatterlist *sg;
+ uint32_t dmaSgNum;
+ DMA_ADDR_T dmaPaddr;
+ uint32_t *dmaVaddr;
+ uint32_t irqNum;
+ bool isTuning;
+ uint32_t id;
+ struct OsalMutex mutex;
+ bool waitForEvent;
+ HIMCI_EVENT himciEvent;
+ };
+ // MmcCntlr is the core layer controller structure. Its members are assigned with values by using the bind function.
+ struct MmcCntlr {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *hdfDevObj;
+ struct PlatformDevice device;
+ struct OsalMutex mutex;
+ struct OsalSem released;
+ uint32_t devType;
+ struct MmcDevice *curDev;
+ struct MmcCntlrOps *ops;
+ struct PlatformQueue *msgQueue;
+ uint16_t index;
+ uint16_t voltDef;
+ uint32_t vddBit;
+ uint32_t freqMin;
+ uint32_t freqMax;
+ uint32_t freqDef;
+ union MmcOcr ocrDef;
+ union MmcCaps caps;
+ union MmcCaps2 caps2;
+ uint32_t maxBlkNum;
+ uint32_t maxBlkSize;
+ uint32_t maxReqSize;
+ bool devPluged;
+ bool detecting;
+ void *priv;
+ };
+ ```
+
+ - Instantiate the callback function structure **MmcCntlrOps** in **MmcCntlr**. Other members are initialized by using the **Bind** function.
+
+ ```
+ static struct MmcCntlrOps g_himciHostOps = {
+ .request = HimciDoRequest,
+ .setClock = HimciSetClock,
+ .setPowerMode = HimciSetPowerMode,
+ .setBusWidth = HimciSetBusWidth,
+ .setBusTiming = HimciSetBusTiming,
+ .setSdioIrq = HimciSetSdioIrq,
+ .hardwareReset = HimciHardwareReset,
+ .systemInit = HimciSystemInit,
+ .setEnhanceSrobe= HimciSetEnhanceSrobe,
+ .switchVoltage = HimciSwitchVoltage,
+ .devReadOnly = HimciDevReadOnly,
+ .devPluged = HimciCardPluged,
+ .devBusy = HimciDevBusy,
+ .tune = HimciTune,
+ .rescanSdioDev = HimciRescanSdioDev,
+ };
+ ```
+
+ - Bind function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure **HimciHost** object and **MmcCntlr**, and calls the **MmcCntlrAdd** function at the core layer. **MmcCntlr**, **HimciHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully.
+
+ ```
+ static int32_t HimciMmcBind(struct HdfDeviceObject *obj)
+ {
+ struct MmcCntlr *cntlr = NULL;
+ struct HimciHost *host = NULL;
+ int32_t ret;
+ cntlr = (struct MmcCntlr *)OsalMemCalloc(sizeof(struct MmcCntlr));
+ host = (struct HimciHost *)OsalMemCalloc(sizeof(struct HimciHost));
+
+ host->mmc = cntlr; // (Mandatory) Enable conversion between HimciHost and MmcCntlr.
+ cntlr->priv = (void *)host; // (Mandatory) Enable conversion between HimciHost and MmcCntlr.
+ cntlr->ops = &g_himciHostOps; // (Mandatory) Connect to the MmcCntlrOps instance.
+ cntlr->hdfDevObj = obj; // (Mandatory) Enable conversion between HdfDeviceObject and MmcCntlr.
+ obj->service = &cntlr->service; // (Mandatory) Enable conversion between HdfDeviceObject and MmcCntlr.
+ ret = MmcCntlrParse(cntlr, obj); // (Mandatory) Initialize cntlr. If the initialization fails, execute goto _ERR.
+ ...
+ ret = HimciHostParse(host, obj); // (Mandatory) Initialize the attributes of the host. If the initialization fails, execute goto _ERR.
+ ...
+ ret = HimciHostInit(host, cntlr);// Initialization defined by the vendor. If the initialization fails, execute goto _ERR.
+ ...
+ ret = MmcCntlrAdd(cntlr); // Call the function at the core layer. If the function fails to be called, execute goto _ERR.
+ ...
+ (void)MmcCntlrAddDetectMsgToQueue(cntlr);// Add the card detection message to the queue.
+ HDF_LOGD("HimciMmcBind: success.");
+ return HDF_SUCCESS;
+ _ERR:
+ HimciDeleteHost(host);
+ HDF_LOGD("HimciMmcBind: fail, err = %d.", ret);
+ return ret;
+ }
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS
+
+ Function description:
+
+ Implements ProcMciInit.
+
+ ```
+ static int32_t HimciMmcInit(struct HdfDeviceObject *obj)
+ {
+ static bool procInit = false;
+ (void)obj;
+ if (procInit == false) {
+ if (ProcMciInit() == HDF_SUCCESS) {
+ procInit = true;
+ HDF_LOGD("HimciMmcInit: proc init success.");
+ }
+ }
+ HDF_LOGD("HimciMmcInit: success.");
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void HimciMmcRelease(struct HdfDeviceObject *obj)
+ {
+ struct MmcCntlr *cntlr = NULL;
+ ...
+ cntlr = (struct MmcCntlr *)obj->service;// Forcibly convert HdfDeviceObject to MmcCntlr by using service. For details about the value assignment, see the Bind function.
+ ...
+ HimciDeleteHost((struct HimciHost *)cntlr->priv);// Memory release function customized by the vendor. A forced conversion from MmcCntlr to HimciHost is involved in the process.
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-pwm-des.md b/en/device-dev/driver/driver-platform-pwm-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..01e83c4c2ca5adf68aa0c719ba5bde666df88048
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-pwm-des.md
@@ -0,0 +1,579 @@
+# PWM
+
+- [Overview](#section1043395117296)
+- [Available APIs](#section3939192652418)
+- [Usage Guidelines](#section435718267334)
+ - [How to Use](#section113655616347)
+ - [Obtaining a PWM Device Handle](#section17816586359)
+ - [Setting the PWM Period](#section920214812397)
+ - [Setting the PWM Duty Cycle](#section519712820405)
+ - [Setting the PWM Polarity](#section12383334115)
+ - [Enabling the PWM Device](#section382684811414)
+ - [Disabling the PWM Device](#section16545114404218)
+ - [Obtaining PWM Device Configuration Parameters](#section117101243144311)
+ - [Setting PWM Device Configuration Parameters](#section13834163604414)
+ - [Releasing the PWM Device Handle](#section12987111511450)
+
+- [Usage Example](#section138636719469)
+
+## Overview
+
+- Pulse width modulation \(PWM\) is a method used to digitally encode analog signal levels and convert them into pulses. It can be used for motor control and backlight brightness adjustment.
+
+- The PWM APIs define a set of common functions for operating a PWM device, including those for:
+ - Obtaining and releasing a PWM device handle
+ - Setting the PWM period, duty cycle, and polarity
+ - Enabling and disabling a PWM device
+ - Obtaining and setting configuration parameters
+
+
+## Available APIs
+
+**Table 1** APIs available for the PWM driver
+
+
+Capability
+ |
+Function
+ |
+Description
+ |
+
|---|
+
+Obtaining/Releasing device handles
+ |
+PwmOpen
+ |
+Obtains a PWM device handle.
+ |
+
+PwmClose
+ |
+Releases a PWM device handle.
+ |
+
+Setting the PWM period, duty cycle, and polarity
+ |
+PwmSetPeriod
+ |
+Sets the PWM period.
+ |
+
+PwmSetDuty
+ |
+Sets the PWM duty cycle.
+ |
+
+PwmSetPolarity
+ |
+Sets the PWM polarity.
+ |
+
+Enabling/Disabling devices
+ |
+PwmEnable
+ |
+Enables a PWM device.
+ |
+
+PwmDisable
+ |
+Disables a PWM device.
+ |
+
+Obtaining/Setting configuration parameters
+
+ |
+PwmSetConfig
+ |
+Sets PWM device configuration parameters.
+ |
+
+PwmGetConfig
+ |
+Obtains PWM device configuration parameters.
+ |
+
+
+
+
+> **NOTE:**
+>All functions described in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 1](#fig23885455594) shows the process of using a PWM device.
+
+**Figure 1** Process of using a PWM device
+
+
+
+
+### Obtaining a PWM Device Handle
+
+Before performing operations on a PWM device, obtain a PWM device handle by calling **PwmOpen**. This function returns a PWM device handle with the specified device number.
+
+DevHandle PwmOpen\(uint32\_t num\);
+
+**Table 2** Description of PwmOpen
+
+
+Parameter
+ |
+Description
+ |
+
+num
+ |
+PWM device number.
+ |
+
+Return Value
+ |
+Description
+ |
+
+NULL
+ |
+Failed to obtain the PWM device handle.
+ |
+
+Device handle
+ |
+PWM device handle.
+ |
+
+
+
+
+The following example shows how to obtain a PWM device handle with the device number **0**:
+
+```
+uint32_t num = 0; /* PWM device number */
+DevHandle pwm = NULL; /* PWM device handle */
+
+/* Obtain the PWM device handle. */
+pwm = PwmOpen(num);
+if (pwm == NULL) {
+ HDF_LOGE("PwmOpen: pwm%d failed", num);
+ return;
+}
+```
+
+### Setting the PWM Period
+
+int32\_t PwmSetPeriod\(DevHandle handle, uint32\_t period\);
+
+**Table 3** Description of PwmSetPeriod
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+period
+ |
+Period, in nanoseconds.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in setting the PWM period.
+ |
+
+Negative value
+ |
+Failed to set the period.
+ |
+
+
+
+
+```
+int32_t ret;
+uint32_t period = 1000; /* Period: 1000 ns */
+ret = PwmSetPeriod(pwm, period); /* Set the PWM period. */
+if (ret != 0) {
+ HDF_LOGE("PwmSetPeriod: failed, ret %d", ret);
+}
+```
+
+### Setting the PWM Duty Cycle
+
+int32\_t PwmSetDuty\(DevHandle handle, uint32\_t duty\);
+
+**Table 4** Description of PwmSetDuty
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+duty
+ |
+Duty cycle, in nanoseconds.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in setting the duty cycle.
+ |
+
+Negative value
+ |
+Failed to set the duty cycle.
+ |
+
+
+
+
+```
+int32_t ret;
+uint32_t duty = 500; /* Duty cycle: 500 ns */
+ret = PwmSetDuty(pwm, duty); /* Set the PWM duty cycle. */
+if (ret != 0) {
+ HDF_LOGE("PwmSetDuty: failed, ret %d", ret);
+}
+```
+
+### Setting the PWM Polarity
+
+int32\_t PwmSetPolarity\(DevHandle handle, uint8\_t polarity\);
+
+**Table 5** Description of PwmSetPolarity
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+polarity
+ |
+Polarity, which can be PWM_NORMAL_POLARITY or PWM_INVERTED_POLARITY.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeed in setting the polarity.
+ |
+
+Negative value
+ |
+Failed to set the polarity.
+ |
+
+
+
+
+```
+int32_t ret;
+uint8_t polarity = PWM_INVERTED_POLARITY; /* Inverted polarity */
+ret = PwmSetPolarity(pwm, polarity); /* Set PWM polarity to inverted polarity. */
+if (ret != 0) {
+ HDF_LOGE("PwmSetPolarity: failed, ret %d", ret);
+}
+```
+
+### Enabling the PWM Device
+
+int32\_t PwmEnable\(DevHandle handle\);
+
+**Table 6** Description of PwmEnable
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in enabling the PWM device.
+ |
+
+Negative value
+ |
+Failed to enable the PWM device.
+ |
+
+
+
+
+```
+int32_t ret;
+ret = PwmEnable(pwm); /* Enable the PWM device. */
+if (ret != 0) {
+ HDF_LOGE("PwmEnable: failed, ret %d", ret);
+}
+```
+
+### Disabling the PWM Device
+
+int32\_t PwmDisable\(DevHandle handle\);
+
+**Table 7** Description of PwmDisable
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in disabling the PWM device.
+ |
+
+Negative value
+ |
+Failed to disable the PWM device.
+ |
+
+
+
+
+```
+int32_t ret;
+ret = PwmDisable(pwm); /* Disable the PWM device. */
+if (ret != 0) {
+ HDF_LOGE("PwmDisable: failed, ret %d", ret);
+}
+```
+
+### Obtaining PWM Device Configuration Parameters
+
+int32\_t PwmGetConfig\(DevHandle handle, struct PwmConfig \*config\);
+
+**Table 8** Description of PwmGetConfig
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+config
+ |
+Pointer to the PwmConfig structure containing PWM device configuration parameters.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in obtaining PWM device configuration parameters.
+ |
+
+Negative value
+ |
+Failed to obtain PWM device configuration parameters.
+ |
+
+
+
+
+```
+int32_t ret;
+struct PwmConfig config= {0}; /* PWM configuration parameters */
+ret = PwmGetConfig(pwm, &config); /* Obtain PWM device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("PwmGetConfig: failed, ret %d", ret);
+}
+```
+
+### Setting PWM Device Configuration Parameters
+
+int32\_t PwmSetConfig\(DevHandle handle, struct PwmConfig \*config\);
+
+**Table 9** Description of PwmSetConfig
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+config
+ |
+Pointer to the PwmConfig structure containing PWM device configuration parameters.
+ |
+
+Return Value
+ |
+Description
+ |
+
+0
+ |
+Succeeded in setting PWM configuration parameters.
+ |
+
+Negative value
+ |
+Failed to set PWM configuration parameters.
+ |
+
+
+
+
+```
+int32_t ret;
+struct PwmConfig config= {0}; /* PWM configuration parameters */
+config.duty = 500; /* Duty cycle: 500 ns */
+config.period = 1000; /* Period: 1000 ns */
+config.number = 0; /* Continuous output of square waves */
+config.polarity = PWM_NORMAL_POLARITY; /* Normal polarity */
+ret = PwmSetConfig(pwm, &config); /* Set PWM device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("PwmSetConfig: failed, ret %d\n", ret);
+}
+```
+
+### Releasing the PWM Device Handle
+
+void PwmClose\(DevHandle handle\);
+
+This function will release the resources obtained by calling **PwmClose**.
+
+**Table 10** Description of PwmClose
+
+
+Parameter
+ |
+Description
+ |
+
+handle
+ |
+PWM device handle.
+ |
+
+
+
+
+```
+PwmClose(pwm); /* Release the PWM device handle */
+```
+
+## Usage Example
+
+The following example shows how to obtain a PWM device handle, set the PWM configuration parameters, enable the PWM device, and finally release the PWM device handle.
+
+```
+#include "hdf_log.h"
+#include "osal_time.h"
+#include "pwm_if.h"
+
+void PwmTestSample(void)
+{
+ int32_t ret;
+ struct PwmConfig config; /* PWM configuration parameters */
+ DevHandle pwm = NULL; /* PWM device handle */
+
+ pwm = PwmOpen(0); /* Obtain the PWM device handle. */
+ if (pwm == NULL) {
+ HDF_LOGE("PwmOpen: pwm0 failed");
+ return;
+ }
+ /* Obtain the PWM device configuration parameters. */
+ ret = PwmGetConfig(pwm, &config);
+ if (ret != 0) {
+ HDF_LOGE("PwmGetConfig: failed, ret %d\n", ret);
+ goto err;
+ }
+ config.duty = 500; /* Duty cycle: 500 ns */
+ config.period = 1000; /* Period: 1000 ns */
+ /* Set the PWM device configuration parameters. */
+ ret = PwmSetConfig(pwm, &config);
+ if (ret != 0) {
+ HDF_LOGE("PwmSetConfig: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Enable the PWM device. */
+ ret = PwmEnable(pwm);
+ if (ret != 0) {
+ HDF_LOGE("PwmEnable: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Sleep for 10 seconds */
+ OsalSleep(10);
+ /* Disable the PWM device. */
+ ret = PwmDisable(pwm);
+ if (ret != 0) {
+ HDF_LOGE("PwmDisable: failed, ret %d\n", ret);
+ goto err;
+ }
+err:
+ /* Release the PWM device handle. */
+ PwmClose(pwm);
+}
+```
+
diff --git a/en/device-dev/driver/driver-platform-pwm-develop.md b/en/device-dev/driver/driver-platform-pwm-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..2420131c13ca485f253de5e2e0eb5d5f101f7711
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-pwm-develop.md
@@ -0,0 +1,349 @@
+# PWM
+
+- [Overview](#section1591602238164144)
+- [How to Develop](#section967396342164144)
+ - [PwmMethod](#section14560119104318)
+
+- [Development Example](#section1883877829164144)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the Pulse Width Modulator \(PWM\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The PWM module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **pwm\_config.hcs** file.
+
+3. Instantiate the PWM controller object.
+ - Initialize **PwmDev**.
+ - Instantiate **PwmMethod** in the **PwmDev** object.
+
+ > **NOTE:**
+ >For details, see [PwmMethod](#section14560119104318) and [Table 1](#table11173154124311).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
+
+
+### PwmMethod
+
+```
+struct PwmMethod {
+ int32_t (*setConfig)(struct PwmDev *pwm, struct PwmConfig *config);
+ int32_t (*open)(struct PwmDev *pwm);
+ int32_t (*close)(struct PwmDev *pwm);
+};
+```
+
+**Table 1** Callbacks for the members in the PwmMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+setConfig
+ |
+pwm: structure pointer to the PWM controller at the core layer.
+config: structure pointer to the input attribute value.
+ |
+HDF_STATUS
+ |
+Configures attributes.
+ |
+
+open
+ |
+pwm: structure pointer to the PWM controller at the core layer.
+ |
+HDF_STATUS
+ |
+Starts the device.
+ |
+
+close
+ |
+pwm: structure pointer to the PWM controller at the core layer.
+ |
+HDF_STATUS
+ |
+Stops the device.
+ |
+
+
+
+
+## Development Example
+
+The following uses **pwm\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+
+ - PWM driver entry reference
+
+ ```
+ struct HdfDriverEntry g_hdfPwm = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_PLATFORM_PWM",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ .Bind = HdfPwmBind,
+ .Init = HdfPwmInit,
+ .Release = HdfPwmRelease,
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_hdfPwm);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **pwm\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **PwmDev** members at the core layer. If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **pwm\_config** file.
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_pwm :: device {// Configure an HDF device node for each PWM controller. Set this parameter only when there are multiple PWM controllers.
+ device0 :: deviceNode {
+ policy = 1; // Publish kernel-mode services.
+ priority = 80; // Driver startup priority
+ permission = 0644; // Permission to create device nodes for the driver
+ moduleName = "HDF_PLATFORM_PWM"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HDF_PLATFORM_PWM_0";// (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_pwm_0";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller information in pwm_config.hcs.
+ // For details about the controller information, see pwm_config.hcs.
+ }
+ device1 :: deviceNode {
+ policy = 1;
+ priority = 80;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_PWM";
+ serviceName = "HDF_PLATFORM_PWM_1";
+ deviceMatchAttr = "hisilicon_hi35xx_pwm_1";
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - **pwm\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ pwm_config {
+ template pwm_device {// (Mandatory) Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ serviceName = "";
+ match_attr = "";
+ num = 0; // (Mandatory) Device number
+ base = 0x12070000; // (Mandatory) Used for address mapping
+ }
+ device_0x12070000 :: pwm_device {
+ match_attr = "hisilicon_hi35xx_pwm_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ }
+ device_0x12070020::pwm_device {// Set this parameter only when there are multiple devices.
+ match_attr = "hisilicon_hi35xx_pwm_1";
+ num = 1;
+ base = 0x12070020; // (Mandatory) Used for address mapping
+ }
+ }
+ }
+ }
+ ```
+
+3. Initialize the **PwmDev** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **PwmMethod** \(used to call underlying functions of the driver\) in **PwmDev**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **pwm\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
+
+ ```
+ struct HiPwm {
+ struct PwmDev dev; // (Mandatory) Core layer structure
+ volatile unsigned char *base;
+ struct HiPwmRegs *reg; // Device attribute structure, which can be customized.
+ bool supportPolarity;
+ };
+
+ // PwmDev is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct PwmDev {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ struct PwmConfig cfg; // Attribute structure. For details, see the description of PwmConfig.
+ struct PwmMethod *method; // Hook function template
+ bool busy;
+ uint32_t num; // Device number
+ OsalSpinlock lock;
+ void *priv; // Private data. Generally, the start address of the custom structure is stored to facilitate invoking of the structure.
+ };
+ struct PwmConfig {
+ uint32_t duty; // Time (in ns) when a signal is in the on state.
+ uint32_t period; // Regular interval (in ns) of PWM
+ uint32_t number; // Number of consecutive PWMs
+ uint8_t polarity; // Polarity
+ // ------------------- | --------------
+ // PWM_NORMAL_POLARITY | Normal polarity
+ // PWM_INVERTED_POLARITY | Inverted polarity
+ //
+ uint8_t status; // Running status
+ // ------------------ | -----------------
+ // PWM_DISABLE_STATUS | Disabled
+ // PWM_ENABLE_STATUS | Enabled
+ };
+ ```
+
+ - Instantiate the callback function structure **PwmMethod** in **PwmDev**. Other members are initialized by using the **Init** function.
+
+ ```
+ // Example in pwm_hi35xx.c: fill the hook function
+ struct PwmMethod g_pwmOps = {
+ .setConfig = HiPwmSetConfig,// Configure attributes.
+ };
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **PwmDev**, and calls the **PwmDeviceAdd** function at the core layer.
+
+ ```
+ // The bind function is empty. It can be combined with the init function or implement related operations based on the vendor's requirements.
+ static int32_t HdfPwmBind(struct HdfDeviceObject *obj)
+ {
+ (void)obj;
+ return HDF_SUCCESS;
+ }
+
+ static int32_t HdfPwmInit(struct HdfDeviceObject *obj)
+ {
+ int ret;
+ struct HiPwm *hp = NULL;
+ ...
+ hp = (struct HiPwm *)OsalMemCalloc(sizeof(*hp));
+ ...
+ ret = HiPwmProbe(hp, obj); // (Mandatory) The implementation is as follows:
+ ...
+ return ret;
+ }
+
+ static int32_t HiPwmProbe(struct HiPwm *hp, struct HdfDeviceObject *obj)
+ {
+ uint32_t tmp;
+ struct DeviceResourceIface *iface = NULL;
+
+ iface = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);// Initialize the custom structure HiPwm.
+ ...
+
+ hp->reg = (struct HiPwmRegs *)hp->base; // Initialize the custom structure HiPwm.
+ hp->supportPolarity = false; // Initialize the custom structure HiPwm.
+ hp->dev.method = &g_pwmOps; // Connect to the instantiated object of PwmMethod.
+ hp->dev.cfg.duty = PWM_DEFAULT_DUTY_CYCLE; // Initialize PwmDev.
+ hp->dev.cfg.period = PWM_DEFAULT_PERIOD; // Initialize PwmDev.
+ hp->dev.cfg.polarity = PWM_DEFAULT_POLARITY; // Initialize PwmDev.
+ hp->dev.cfg.status = PWM_DISABLE_STATUS; // Initialize PwmDev.
+ hp->dev.cfg.number = 0; // Initialize PwmDev.
+ hp->dev.busy = false; // Initialize PwmDev.
+ if (PwmDeviceAdd(obj, &(hp->dev)) ) != HDF_SUCCESS) {// (Important) Call the core layer function to initialize the hp->dev devices and services.
+ OsalIoUnmap((void *)hp->base);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
+
+ ```
+ static void HdfPwmRelease(struct HdfDeviceObject *obj)
+ {
+ struct HiPwm *hp = NULL;
+ ...
+ hp = (struct HiPwm *)obj->service;// A forced conversion from HdfDeviceObject to HiPwm is involved.
+ ...
+ PwmDeviceRemove(obj, &(hp->dev));// (Mandatory) Call the core layer functions to release PwmDev devices and services. A forced conversion from HiPwm to PwmDev is involved in the process.
+ HiPwmRemove(hp); //Release HiPwm.
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-rtc-des.md b/en/device-dev/driver/driver-platform-rtc-des.md
index 66e8a08cf14f76bd8e32165491c4387567db8f66..161603462933e996a22bfd39039f93a0c7fb89c9 100644
--- a/en/device-dev/driver/driver-platform-rtc-des.md
+++ b/en/device-dev/driver/driver-platform-rtc-des.md
@@ -1,8 +1,7 @@
-# RTC
+# RTC
- [Overview](#section104842041574)
- - [Available APIs](#section3373340142215)
-
+- [Available APIs](#section20331159102519)
- [Usage Guidelines](#section20636145604113)
- [How to Use](#section16919828134215)
- [Creating an RTC Device Handle](#section1131212144310)
@@ -16,7 +15,7 @@
The real-time clock \(RTC\) driver provides precise real time for the operating system \(OS\). If the OS is powered off, the RTC driver continues to keep track of the system time using an external battery.
-### Available APIs
+## Available APIs
**Table 1** APIs provided by the RTC driver
@@ -116,12 +115,10 @@ The real-time clock \(RTC\) driver provides precise real time for the operating
During the OS startup, the HDF loads the RTC driver based on the configuration file. The RTC driver detects the RTC component and initializes the driver.
-[Figure 1](#fig166181128151112) illustrates the process of using an RTC device.
-
-**Figure 1** Process of using an RTC device
-
+[Figure 1](#fig1610020107333) illustrates the process of using an RTC device.
-
+**Figure 1** Process of using an RTC device
+
### Creating an RTC Device Handle
diff --git a/en/device-dev/driver/driver-platform-rtc-develop.md b/en/device-dev/driver/driver-platform-rtc-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..4041f5453d852dfdc28f63928414e0e47f5a878d
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-rtc-develop.md
@@ -0,0 +1,471 @@
+# RTC
+
+- [Overview](#section509989381142407)
+- [How to Develop](#section1784450860142407)
+ - [RtcMethod](#section13652132473017)
+
+- [Development Example](#section1594883301142407)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the real-time clock \(RTC\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The RTC module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **rtc\_config.hcs** file.
+
+3. Instantiate the RTC controller object.
+ - Initialize **RtcHost**.
+ - Instantiate **RtcMethod** in the **RtcHost** object.
+
+ > **NOTE:**
+ >For details, see [RtcMethod](#section13652132473017) and [Table 1](#table12929217311).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the RTC control status and response to interrupts.
+
+
+### RtcMethod
+
+```
+struct RtcMethod {
+ int32_t (*ReadTime)(struct RtcHost *host, struct RtcTime *time);
+ int32_t (*WriteTime)(struct RtcHost *host, const struct RtcTime *time);
+ int32_t (*ReadAlarm)(struct RtcHost *host, enum RtcAlarmIndex alarmIndex, struct RtcTime *time);
+ int32_t (*WriteAlarm)(struct RtcHost *host, enum RtcAlarmIndex alarmIndex, const struct RtcTime *time);
+ int32_t (*RegisterAlarmCallback)(struct RtcHost *host, enum RtcAlarmIndex alarmIndex, RtcAlarmCallback cb);
+ int32_t (*AlarmInterruptEnable)(struct RtcHost *host, enum RtcAlarmIndex alarmIndex, uint8_t enable);
+ int32_t (*GetFreq)(struct RtcHost *host, uint32_t *freq);
+ int32_t (*SetFreq)(struct RtcHost *host, uint32_t freq);
+ int32_t (*Reset)(struct RtcHost *host);
+ int32_t (*ReadReg)(struct RtcHost *host, uint8_t usrDefIndex, uint8_t *value);
+ int32_t (*WriteReg)(struct RtcHost *host, uint8_t usrDefIndex, uint8_t value);
+};
+```
+
+**Table 1** Callbacks for the members in the RtcMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+ReadTime
+ |
+host: structure pointer to the RTC controller at the core layer.
+ |
+time: structure pointer to the output time value.
+ |
+HDF_STATUS
+ |
+Reads the RTC time information.
+ |
+
+WriteTime
+ |
+host: structure pointer to the RTC controller at the core layer.
+time: structure pointer to the input time.
+ |
+–
+ |
+HDF_STATUS
+ |
+Writes the RTC time information (from milliseconds to years).
+ |
+
+ReadAlarm
+ |
+host: structure pointer to the RTC controller at the core layer.
+alarmIndex: clock alarm index, which is an enumerated value.
+ |
+time: structure pointer to the output time.
+ |
+HDF_STATUS
+ |
+Reads the RTC alarm time.
+ |
+
+WriteAlarm
+ |
+host: structure pointer to the RTC controller at the core layer.
+alarmIndex: clock alarm index, which is an enumerated value.
+time: structure pointer to the input time.
+ |
+–
+ |
+HDF_STATUS
+ |
+Writes the RTC alarm time.
+ |
+
+RegisterAlarmCallback
+ |
+host: structure pointer to the RTC controller at the core layer.
+alarmIndex: clock alarm index, which is an enumerated value.
+cb: pointer to the callback.
+ |
+–
+ |
+HDF_STATUS
+ |
+Registers RtcAlarmCallback that will be invoked when an alarm is generated at the specified time.
+ |
+
+AlarmInterruptEnable
+ |
+host: structure pointer to the RTC controller at the core layer.
+alarmIndex: clock alarm index, which is an enumerated value.
+enable: specifies whether to enable the RTC alarm interrupt.
+ |
+–
+ |
+HDF_STATUS
+ |
+Enables or disables the RTC alarm interrupt.
+ |
+
+GetFreq
+ |
+host: structure pointer to the RTC controller at the core layer.
+ |
+freq: pointer to the output frequency, which is of the uint32_t type.
+ |
+HDF_STATUS
+ |
+Reads the frequency of the external crystal oscillator connected to the RTC driver.
+ |
+
+SetFreq
+ |
+host: structure pointer to the RTC controller at the core layer.
+freq: input frequency, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the frequency of the external crystal oscillator connected to the RTC driver.
+ |
+
+Reset
+ |
+host: structure pointer to the RTC controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Resets the RTC.
+ |
+
+ReadReg
+ |
+host: structure pointer to the RTC controller at the core layer.
+usrDefIndex: structure defining the index of a custom register.
+ |
+value: pointer to the output register value, which is of the uint8_t type.
+ |
+HDF_STATUS
+ |
+Reads the configuration of a custom RTC register based on the register index. One index corresponds to one byte of the configuration value.
+ |
+
+WriteReg
+ |
+host: structure pointer to the RTC controller at the core layer.
+usrDefIndex: structure defining the index of a custom register.
+value: input register value, which is of the uint8_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Configure the RTC register based on the register index. One index corresponds to one byte of the configuration value.
+ |
+
+
+
+
+## Development Example
+
+The following uses **rtc\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - RTC driver entry reference
+
+ ```
+ struct HdfDriverEntry g_rtcDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = HiRtcBind, // See the Bind function.
+ .Init = HiRtcInit, // See the Init function.
+ .Release = HiRtcRelease, //See the Release function.
+ .moduleName = "HDF_PLATFORM_RTC", // (Mandatory) This parameter must be the same as that in the .hcs file.
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_rtcDriverEntry);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **rtc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **RtcHost** members at the core layer.
+
+ In this example, there is only one RTC controller. If there are multiple RTC controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **rtc\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ platform :: host {
+ device_rtc :: device {
+ device0 :: deviceNode {
+ policy = 1; // 2: The driver publishes user-mode services. 1: The driver publishes kernel-mode services. 0: No service needs to be published.
+ priority = 30; // A smaller value indicates a higher priority.
+ permission = 0644; // Permission for the driver to create a device node
+ moduleName = "HDF_PLATFORM_RTC"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HDF_PLATFORM_RTC"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_rtc";// The value must be the same as that of match_attr in the .hcs file.
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - **rtc\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ rtc_config {
+ controller_0x12080000 {
+ match_attr = "hisilicon_hi35xx_rtc";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ rtcSpiBaseAddr = 0x12080000; // Used for address mapping
+ regAddrLength = 0x100; // Used for address mapping
+ irq = 37; // Interruption number
+ supportAnaCtrl = false;
+ supportLock = false;
+ anaCtrlAddr = 0xff;
+ lock0Addr = 0xff;
+ lock1Addr = 0xff;
+ lock2Addr = 0xff;
+ lock3Addr = 0xff;
+ }
+ }
+ }
+ }
+ ```
+
+3. Initialize the **RtcHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **RtcMethod** \(used to call underlying functions of the driver\) in **RtcHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **rtc\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**.
+
+ ```
+ struct RtcConfigInfo {
+ uint32_t spiBaseAddr; // Used for address mapping
+ volatile void *remapBaseAddr; // Used for address mapping
+ uint16_t regAddrLength; // Used for address mapping
+ uint8_t supportAnaCtrl; // Indicates whether anaCtrl is supported.
+ uint8_t supportLock; // Indicates whether lock is supported.
+ uint8_t irq; // Interrupt number
+ uint8_t alarmIndex; // Clock alarm index
+ uint8_t anaCtrlAddr; // anaCtrl address
+ struct RtcLockAddr lockAddr; // Lock address
+ RtcAlarmCallback cb; // Callback
+ struct OsalMutex mutex; // Mutex
+ };
+
+ // RtcHost is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct RtcHost {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ struct RtcMethod *method;
+ void *data;
+ };
+ ```
+
+ - Instantiate the callback function structure **RtcMethod** in **RtcHost**. Other members are initialized by using the **Init** function.
+
+ ```
+ // Example in rtc_hi35xx.c: instantiate the hook.
+ static struct RtcMethod g_method = {
+ .ReadTime = HiRtcReadTime,
+ .WriteTime = HiRtcWriteTime,
+ .ReadAlarm = HiReadAlarm,
+ .WriteAlarm = HiWriteAlarm,
+ .RegisterAlarmCallback = HiRegisterAlarmCallback,
+ .AlarmInterruptEnable = HiAlarmInterruptEnable,
+ .GetFreq = HiGetFreq,
+ .SetFreq = HiSetFreq,
+ .Reset = HiReset,
+ .ReadReg = HiReadReg,
+ .WriteReg = HiWriteReg,
+ };
+ ```
+
+ - Bind function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Input parameters and return values of the Bind function
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Associates the **HdfDeviceObject** object and **RtcHost**.
+
+ ```
+ static int32_t HiRtcBind(struct HdfDeviceObject *device)
+ {
+ struct RtcHost *host = NULL;
+ host = RtcHostCreate(device); // Apply for memory and connect to the device: host->device = device;
+ // Enable conversion between HdfDeviceObject and RtcHost.
+ ...
+ device->service = &host->service; // Enable conversion between HdfDeviceObject and RtcHost.
+ // This setting enables the host to be globally used by calling RtcHostFromDevice.
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS
+
+ Function description:
+
+ Initializes the custom structure object and **RtcHost**.
+
+ ```
+ static int32_t HiRtcInit(struct HdfDeviceObject *device)
+ {
+ struct RtcHost *host = NULL;
+ struct RtcConfigInfo *rtcInfo = NULL;
+ ...
+ host = RtcHostFromDevice(device);// A forced conversion from HdfDeviceObject to RtcHost is involved.
+ rtcInfo = OsalMemCalloc(sizeof(*rtcInfo));
+ ...
+ // HiRtcConfigData reads attributes from the device configuration tree and fills in supportAnaCtrl, supportLock, spiBaseAddr, regAddrLength, and irq in rtcInfo.
+ // Provide parameters for HiRtcSwInit and HiRtcSwInit, and perform operations such as releasing memory when the function internal processing fails.
+ if (HiRtcConfigData(rtcInfo, device->property) != 0) {
+ ...
+ }
+ if (HiRtcSwInit(rtcInfo)! = 0) {// Related to address mapping and interrupt registration
+ ...
+ }
+ if (HiRtcHwInit(rtcInfo)! = 0) {// Initialize anaCtrl and lockAddr.
+ ...
+ }
+
+ host->method = &g_method; // Connect to the UARTHostMethod instance.
+ host->data = rtcInfo; // Enable conversion between RtcConfigInfo and RtcHost.
+ HDF_LOGI("Hdf dev service:%s init success!", HdfDeviceGetServiceName(device));
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ **Function description**:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** or **Bind** function has the corresponding value assignment operations.
+
+ ```
+ static void HiRtcRelease(struct HdfDeviceObject *device)
+ {
+ struct RtcHost *host = NULL;
+ struct RtcConfigInfo *rtcInfo = NULL;
+ ...
+ host = RtcHostFromDevice(device); // A forced conversion from HdfDeviceObject to RtcHost is involved.
+ rtcInfo = (struct RtcConfigInfo *)host->data;// A forced conversion from RtcHost to RtcConfigInfo is involved.
+ if (rtcInfo != NULL) {
+ HiRtcSwExit(rtcInfo);
+ OsalMemFree(rtcInfo); // Release RtcConfigInfo.
+ host->data = NULL;
+ }
+ RtcHostDestroy(host); // Release RtcHost.
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-sdio-des.md b/en/device-dev/driver/driver-platform-sdio-des.md
index 4b5a27d35334ab5e75cbf0ea3cddffd9fd9341d3..e781662256ccee630e3ca9ecf185135c53148ae3 100644
--- a/en/device-dev/driver/driver-platform-sdio-des.md
+++ b/en/device-dev/driver/driver-platform-sdio-des.md
@@ -1,8 +1,7 @@
-# SDIO
+# SDIO
- [Overview](#section1155271783811)
- - [Available APIs](#section08064247248)
-
+- [Available APIs](#section12601496259)
- [Usage Guidelines](#section1878939192515)
- [How to Use](#section1490685512255)
- [Opening an SDIO Controller](#section10782428132616)
@@ -32,11 +31,11 @@
**Figure 1** Connections between the host and devices in SDIO
- 
+ 
- The SDIO interface defines a set of common methods for operating an SDIO device, including opening and closing an SDIO controller, exclusively claiming and releasing the host, enabling and disabling devices, claiming and releasing an SDIO IRQ, reading and writing data based on SDIO, and obtaining and setting common information.
-### Available APIs
+## Available APIs
**Table 1** APIs available for the SDIO driver
@@ -170,7 +169,7 @@
**Figure 2** Process of using an SDIO
-
+
### Opening an SDIO Controller
diff --git a/en/device-dev/driver/driver-platform-sdio-develop.md b/en/device-dev/driver/driver-platform-sdio-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..1f0fcd50d39d2f8c3649e00cdaea1c7525e4fafc
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-sdio-develop.md
@@ -0,0 +1,561 @@
+# SDIO
+
+- [Overview](#section1347805272150053)
+- [How to Develop](#section581179475150053)
+ - [SdioDeviceOps](#section482911395315)
+
+- [Development Example](#section2112250242150053)
+
+## Overview
+
+A Secure Digital Input Output \(SDIO\) card is an extension of the SD specification to cover I/O functions. SD and SDIO are called multimedia card \(MMCs\). In the Hardware Driver Foundation \(HDF\) framework, the SDIO module uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The SDIO module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **sdio\_config.hcs** file.
+
+3. Instantiate the SDIO controller object.
+ - Initialize **SdioDevice**.
+ - Instantiate **SdioDeviceOps** in the **SdioDevice** object.
+
+ > **NOTE:**
+ >For details, see [SdioDeviceOps](#section482911395315) and [Table 1](#table878215448417).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the SDIO control status and response to interrupts.
+
+
+### SdioDeviceOps
+
+```
+// Function template
+struct SdioDeviceOps {
+ int32_t (*incrAddrReadBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size);
+ int32_t (*incrAddrWriteBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size);
+ int32_t (*fixedAddrReadBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size, uint32_t scatterLen);
+ int32_t (*fixedAddrWriteBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size, uint32_t scatterLen);
+ int32_t (*func0ReadBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size);
+ int32_t (*func0WriteBytes)(struct SdioDevice *dev, uint8_t *data, uint32_t addr, uint32_t size);
+ int32_t (*setBlockSize)(struct SdioDevice *dev, uint32_t blockSize);
+ int32_t (*getCommonInfo)(struct SdioDevice *dev, SdioCommonInfo *info, uint32_t infoType);
+ int32_t (*setCommonInfo)(struct SdioDevice *dev, SdioCommonInfo *info, uint32_t infoType);
+ int32_t (*flushData)(struct SdioDevice *dev);
+ int32_t (*enableFunc)(struct SdioDevice *dev);
+ int32_t (*disableFunc)(struct SdioDevice *dev);
+ int32_t (*claimIrq)(struct SdioDevice *dev, SdioIrqHandler *irqHandler);
+ int32_t (*releaseIrq)(struct SdioDevice *dev);
+ int32_t (*findFunc)(struct SdioDevice *dev, struct SdioFunctionConfig *configData);
+ int32_t (*claimHost)(struct SdioDevice *dev);
+ int32_t (*releaseHost)(struct SdioDevice *dev);
+};
+```
+
+**Table 1** Callbacks for the members in the SdioDeviceOps structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+incrAddrReadBytes
+ |
+dev: structure pointer to the SDIO device controller.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to read, which is of the uint32_t type.
+ |
+data: pointer to the output value, which is of the uint8_t type.
+ |
+HDF_STATUS
+ |
+Incrementally reads data of a given length from the specified SDIO address.
+ |
+
+incrAddrWriteBytes
+ |
+dev: structure pointer to the SDIO device controller.
+data: pointer to the input value, which is of the uint8_t type.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to write, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Incrementally writes data of a given length to the specified SDIO address.
+ |
+
+fixedAddrReadBytes
+ |
+dev: structure pointer to the SDIO device controller.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to read, which is of the uint32_t type.
+scatterLen: data length, which is of the uint32_t type.
+ |
+data: pointer to the output value, which is of the uint8_t type.
+ |
+HDF_STATUS
+ |
+Reads data of a given length from a fixed SDIO address.
+ |
+
+fixedAddrWriteBytes
+ |
+dev: structure pointer to the SDIO device controller.
+data: pointer to the input value, which is of the uint8_t type.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to write, which is of the uint32_t type.
+scatterLen: data length, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Writes data of a given length to the fixed SDIO address.
+ |
+
+func0ReadBytes
+ |
+dev: structure pointer to the SDIO device controller.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to read, which is of the uint32_t type.
+ |
+data: pointer to the output value, which is of the uint8_t type.
+ |
+HDF_STATUS
+ |
+Reads data of a given length from the address space of SDIO function 0.
+ |
+
+func0WriteBytes
+ |
+dev: structure pointer to the SDIO device controller.
+data: pointer to the input value, which is of the uint8_t type.
+addr: SDIO address, which is of the uint32_t type.
+size: size of the data to write, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Writes data of a given length to the address space of SDIO function 0.
+ |
+
+setBlockSize
+ |
+dev: structure pointer to the SDIO device controller.
+blockSize: block size, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the block size.
+ |
+
+getCommonInfo
+ |
+dev: structure pointer to the SDIO device controller.
+infoType: info type, which is of the uint32_t type.
+ |
+info: structure pointer to the output SdioFuncInfo.
+ |
+HDF_STATUS
+ |
+Obtains CommonInfo. For details, see the NOTE below this table.
+ |
+
+setCommonInfo
+ |
+dev: structure pointer to the SDIO device controller.
+info: union pointer to the input SdioFuncInfo.
+infoType: info type, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets CommonInfo. For details, see the NOTE below this table.
+ |
+
+flushData
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Calls the function when the SDIO device needs to be re-initialized or an error occurs.
+ |
+
+enableFunc
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Enables the SDIO device.
+ |
+
+disableFunc
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Disables the SDIO device.
+ |
+
+claimIrq
+ |
+dev: structure pointer to the SDIO device controller.
+irqHandler: void function pointer to the IRQ handler.
+ |
+–
+ |
+HDF_STATUS
+ |
+Claims an SDIO IRQ.
+ |
+
+releaseIrq
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Releases an SDIO IRQ.
+ |
+
+findFunc
+ |
+dev: structure pointer to the SDIO device controller.
+configData: structure pointer to the key SDIO function information.
+ |
+–
+ |
+HDF_STATUS
+ |
+Obtains the matching funcNum.
+ |
+
+claimHost
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Claims a host exclusively.
+ |
+
+releaseHost
+ |
+dev: structure pointer to the SDIO device controller.
+ |
+–
+ |
+HDF_STATUS
+ |
+Releases the exclusively claimed host.
+ |
+
+
+
+
+> **NOTE:**
+>CommonInfo includes the following information:
+>- **maxBlockNum**: specifies the maximum number of blocks in a request.
+>- **maxBlockSize**: specifies the maximum number of bytes in a block.
+>- **maxRequestSize**: specifies the maximum number of bytes in a request.
+>- **enTimeout**: specifies the maximum timeout period in milliseconds.
+>- **funcNum**: specifies the function number, which ranges from **1** to **7**.
+>- **irqCap**: specifies the interrupt request \(IRQ\) capabilities.
+>- **\(void \*\)data**
+
+## Development Example
+
+The following uses **sdio\_adapter.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - SDIO driver entry reference
+
+ ```
+ struct HdfDriverEntry g_sdioDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = Hi35xxLinuxSdioBind, // See the Bind function.
+ .Init = Hi35xxLinuxSdioInit, // See the Init function.
+ .Release = Hi35xxLinuxSdioRelease// See the Release function.
+ .moduleName = "HDF_PLATFORM_SDIO",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_sdioDriverEntry);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **sdio\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **SdioDevice** members at the core layer.
+
+ In this example, there is only one SDIO controller. If there are multiple SDIO controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **sdio\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_sdio :: device {
+ device0 :: deviceNode {
+ policy = 1;
+ priority = 70;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_SDIO"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
+ serviceName = "HDF_PLATFORM_MMC_2"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_sdio_0";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller in sdio_config.hcs.
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - **sdio\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ sdio_config {
+ template sdio_controller {
+ match_attr = "";
+ hostId = 2; // (Mandatory) It is set to 2. For details, see mmc_config.hcs.
+ devType = 2; // (Mandatory) It is set to 2. For details, see mmc_config.hcs.
+ }
+ controller_0x2dd1 :: sdio_controller {
+ match_attr = "hisilicon_hi35xx_sdio_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ }
+ }
+ }
+ ```
+
+3. Initialize the **SdioDevice** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **SdioDeviceOps** \(used to call underlying functions of the driver\) in **SdioDevice**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **sdio\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values are also passed to the objects at the core layer.
+
+ ```
+ typedef struct {
+ uint32_t maxBlockNum; // Maximum number of blocks in a request.
+ uint32_t maxBlockSize; // Maximum number of bytes in a block. The value range is 1 to 2048.
+ uint32_t maxRequestSize; // Maximum number of bytes in a request. The value range is 1 to 2048.
+ uint32_t enTimeout; // Maximum timeout period in milliseconds. The value cannot exceed one second.
+ uint32_t funcNum; // Function number, which ranges from 1 to 7.
+ uint32_t irqCap; // IRQ capabilities.
+ void *data; // Private data.
+ } SdioFuncInfo;
+
+ // SdioDevice is the core layer controller structure. Its members are assigned with values by using the Bind function.
+ struct SdioDevice {
+ struct SdDevice sd;
+ struct SdioDeviceOps *sdioOps;
+ struct SdioRegister sdioReg;
+ uint32_t functions;
+ struct SdioFunction *sdioFunc[SDIO_MAX_FUNCTION_NUMBER];
+ struct SdioFunction *curFunction;
+ struct OsalThread thread; /* irq thread */
+ struct OsalSem sem;
+ bool irqPending;
+ bool threadRunning;
+ };
+ ```
+
+ - Instantiate the callback function structure **SdioDeviceOps** in **SdioDevice**. Other members are initialized by using the **Init** function.
+
+ ```
+ static struct SdioDeviceOps g_sdioDeviceOps = {
+ .incrAddrReadBytes = Hi35xxLinuxSdioIncrAddrReadBytes,
+ .incrAddrWriteBytes = Hi35xxLinuxSdioIncrAddrWriteBytes,
+ .fixedAddrReadBytes = Hi35xxLinuxSdioFixedAddrReadBytes,
+ .fixedAddrWriteBytes = Hi35xxLinuxSdioFixedAddrWriteBytes,
+ .func0ReadBytes = Hi35xxLinuxSdioFunc0ReadBytes,
+ .func0WriteBytes = Hi35xxLinuxSdioFunc0WriteBytes,
+ .setBlockSize = Hi35xxLinuxSdioSetBlockSize,
+ .getCommonInfo = Hi35xxLinuxSdioGetCommonInfo,
+ .setCommonInfo = Hi35xxLinuxSdioSetCommonInfo,
+ .flushData = Hi35xxLinuxSdioFlushData,
+ .enableFunc = Hi35xxLinuxSdioEnableFunc,
+ .disableFunc = Hi35xxLinuxSdioDisableFunc,
+ .claimIrq = Hi35xxLinuxSdioClaimIrq,
+ .releaseIrq = Hi35xxLinuxSdioReleaseIrq,
+ .findFunc = Hi35xxLinuxSdioFindFunc,
+ .claimHost = Hi35xxLinuxSdioClaimHost,
+ .releaseHost = Hi35xxLinuxSdioReleaseHost,
+ };
+ ```
+
+ - Bind function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Input parameters and return values of the Bind function
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **SdioCntlr**, calls the **SdioCntlrAdd** function at the core layer, and performs other initialization operations customized by the vendor.
+
+ ```
+ static int32_t Hi35xxLinuxSdioBind(struct HdfDeviceObject *obj)
+ {
+ struct MmcCntlr *cntlr = NULL;
+ int32_t ret;
+ ...
+ cntlr = (struct MmcCntlr *)OsalMemCalloc(sizeof(struct MmcCntlr));// Apply for memory.
+ ...
+ cntlr->ops = &g_sdioCntlrOps; // (Mandatory) struct MmcCntlrOps g_sdioCntlrOps={
+ // .rescanSdioDev = Hi35xxLinuxSdioRescan,};
+ cntlr->hdfDevObj = obj; // (Mandatory) Enable conversion between HdfDeviceObject and MmcCntlr.
+ obj->service = &cntlr->service; // (Mandatory) Enable conversion between HdfDeviceObject and MmcCntlr.
+ ret = Hi35xxLinuxSdioCntlrParse(cntlr, obj);// (Mandatory) Initialize the index and devType of cntlr. If the initialization fails, execute goto _ERR.
+ ...
+ ret = MmcCntlrAdd(cntlr); // (Mandatory) Call the mmc_core.c function at the core layer. If the function fails to be called, execute goto _ERR.
+ ...
+ ret = MmcCntlrAllocDev(cntlr, (enum MmcDevType)cntlr->devType);// (Mandatory) Call the mmc_core.c function at the core layer. If the function fails to be called, execute goto _ERR.
+ ...
+
+ MmcDeviceAddOps(cntlr->curDev, &g_sdioDeviceOps);// (Mandatory) Call the function of mmc_core.c at the core layer to instantiate the hook.
+ HDF_LOGD("Hi35xxLinuxSdioBind: Success!");
+ return HDF_SUCCESS;
+
+ _ERR:
+ Hi35xxLinuxSdioDeleteCntlr(cntlr);
+ HDF_LOGE("Hi35xxLinuxSdioBind: Fail!");
+ return HDF_FAILURE;
+ }
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS
+
+ Function description:
+
+ No operation. The vendor can add operations as required.
+
+ ```
+ static int32_t Hi35xxLinuxSdioInit(struct HdfDeviceObject *obj)
+ {
+ (void)obj;// No operation. The vendor can add operations as required.
+ HDF_LOGD("Hi35xxLinuxSdioInit: Success!");
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Bind** function has the corresponding value assignment operations.
+
+
+ ```
+ static void Hi35xxLinuxSdioRelease(struct HdfDeviceObject *obj)
+ {
+ if (obj == NULL) {
+ return;
+ }
+ Hi35xxLinuxSdioDeleteCntlr((struct MmcCntlr *)obj->service);// (Mandatory) Custom function for releasing memory. A forced conversion from HdfDeviceObject to MmcCntlr is involved.
+ }
+ ```
+
+
diff --git a/en/device-dev/driver/driver-platform-spi-des.md b/en/device-dev/driver/driver-platform-spi-des.md
index 28da985d3b9a955254e98ebc9f883802d915f2f5..a11b55062427658966c10c6ae206d26f3ef4da69 100644
--- a/en/device-dev/driver/driver-platform-spi-des.md
+++ b/en/device-dev/driver/driver-platform-spi-des.md
@@ -1,8 +1,7 @@
-# SPI
+# SPI
- [Overview](#section193356154511)
- - [Available APIs](#section232141411476)
-
+- [Available APIs](#section1325964832615)
- [Usage Guidelines](#section71363452477)
- [How to Use](#section32846814820)
- [Obtaining an SPI Device Handle](#section1927265711481)
@@ -24,12 +23,10 @@
- CS: signals enabled by an SPI device and controlled by the SPI controller
-- [Figure 1](#fig15227181812587) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
-
-**Figure 1** SPI controller/device connection
-
+- [Figure 1](#fig89085710359) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
-
+**Figure 1** SPI controller/device connection
+
- SPI communication is usually initiated by the SPI controller and is operated as follows:
@@ -54,7 +51,7 @@
> **NOTE:**
>Currently, these functions are only applicable in the communication initiated by the SPI controller.
-### Available APIs
+## Available APIs
**Table 1** APIs for the SPI driver
@@ -119,12 +116,10 @@
### How to Use
-[Figure 2](#fig23885455594) shows the process of using an SPI device.
-
-**Figure 2** Process of using an SPI device
-
+[Figure 2](#fig1586912310348) shows the process of using an SPI device.
-
+**Figure 2** Process of using an SPI device
+
### Obtaining an SPI Device Handle
diff --git a/en/device-dev/driver/driver-platform-spi-develop.md b/en/device-dev/driver/driver-platform-spi-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..b970a9598d78a0be8f3f78b1dab32266a5e777ae
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-spi-develop.md
@@ -0,0 +1,451 @@
+# SPI
+
+- [Overview](#section84922229152909)
+- [How to Develop](#section799667984152909)
+ - [SpiCntlrMethod](#section715682993110)
+
+- [Development Example](#section956157227152909)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the Serial Peripheral Interface \(SPI\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The SPI module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **spi\_config.hcs** file.
+
+3. Instantiate the SPI controller object.
+ - Initialize **SpiCntlr**.
+ - Instantiate **SpiCntlrMethod** in the **SpiCntlr** object.
+
+ > **NOTE:**
+ >For details, see [SpiCntlrMethod](#section715682993110) and [Table 1](#table7167123615321).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the SPI control status and response to interrupts.
+
+
+### SpiCntlrMethod
+
+```
+struct SpiCntlrMethod {
+ int32_t (*GetCfg)(struct SpiCntlr *cntlr, struct SpiCfg *cfg);
+ int32_t (*SetCfg)(struct SpiCntlr *cntlr, struct SpiCfg *cfg);
+ int32_t (*Transfer)(struct SpiCntlr *cntlr, struct SpiMsg *msg, uint32_t count);
+ int32_t (*Open)(struct SpiCntlr *cntlr);
+ int32_t (*Close)(struct SpiCntlr *cntlr);
+};
+```
+
+**Table 1** Callbacks for the members in the SpiCntlrMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+Transfer
+ |
+cntlr: structure pointer to the SPI controller at the core layer.
+msg: structure pointer to the SPI message.
+count: number of messages. The value is of the uint32_t type.
+ |
+HDF_STATUS
+ |
+Transfers messages.
+ |
+
+SetCfg
+ |
+cntlr: structure pointer to the SPI controller at the core layer.
+cfg: structure pointer to the SPI attributes.
+ |
+HDF_STATUS
+ |
+Sets SPI controller attributes.
+ |
+
+GetCfg
+ |
+cntlr: structure pointer to the SPI controller at the core layer.
+cfg: structure pointer to the SPI attributes.
+ |
+HDF_STATUS
+ |
+Obtains SPI controller attributes.
+ |
+
+Open
+ |
+cntlr: structure pointer to the SPI controller at the core layer.
+ |
+HDF_STATUS
+ |
+Enables the SPI.
+ |
+
+Close
+ |
+cntlr: structure pointer to the SPI controller at the core layer.
+ |
+HDF_STATUS
+ |
+Disables the SPI.
+ |
+
+
+
+
+## Development Example
+
+The following uses **spi\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - SPI driver entry reference
+
+ ```
+ struct HdfDriverEntry g_hdfSpiDevice = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_PLATFORM_SPI",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ .Bind = HdfSpiDeviceBind, // See the Bind function.
+ .Init = HdfSpiDeviceInit, // See the Init function.
+ .Release = HdfSpiDeviceRelease, //See the Release function.
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_hdfSpiDevice);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **spi\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **SpiCntlr** members at the core layer.
+
+ In this example, there is only one SPI controller. If there are multiple SPI controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **spi\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_spi :: device {// Configure an HDF device node for each SPI controller.
+ device0 :: deviceNode {
+ policy = 1;
+ priority = 60;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_SPI";
+ serviceName = "HDF_PLATFORM_SPI_0";
+ deviceMatchAttr = "hisilicon_hi35xx_spi_0";
+ }
+ device1 :: deviceNode {
+ policy = 1;
+ priority = 60;
+ permission = 0644;
+ moduleName = "HDF_PLATFORM_SPI"; // (Mandatory) Driver name, which must be the same as that of moduleName in the driver entry structure.
+ serviceName = "HDF_PLATFORM_SPI_1"; // (Mandatory) Unique name of the service published by the driver
+ deviceMatchAttr = "hisilicon_hi35xx_spi_1";// The value must be the same as that of match_attr in the .hcs file.
+ }
+ ...
+ }
+ }
+ }
+ }
+ ```
+
+ - **spi\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ spi_config {// Configure private data for each SPI controller.
+ template spi_controller {// Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ serviceName = "";
+ match_attr = "";
+ transferMode = 0; // Data transfer mode, which can be interrupt transfer (0), flow control transfer (1), or DMA transfer (2).
+ busNum = 0; // Bus number
+ clkRate = 100000000;
+ bitsPerWord = 8; // Bit width of the data transferred
+ mode = 19; // SPI data input/output mode
+ maxSpeedHz = 0; // Maximum clock frequency
+ minSpeedHz = 0; // Minimum clock frequency
+ speed = 2000000; // Current message transfer speed
+ fifoSize = 256; // FIFO size
+ numCs = 1; // Chip select (CS) number
+ regBase = 0x120c0000; // Used for address mapping.
+ irqNum = 100; // Interruption number
+ REG_CRG_SPI = 0x120100e4; // CRG_REG_BASE(0x12010000) + 0x0e4
+ CRG_SPI_CKEN = 0;
+ CRG_SPI_RST = 0;
+ REG_MISC_CTRL_SPI = 0x12030024; // MISC_REG_BASE(0x12030000) + 0x24
+ MISC_CTRL_SPI_CS = 0;
+ MISC_CTRL_SPI_CS_SHIFT = 0;
+ }
+ controller_0x120c0000 :: spi_controller {
+ busNum = 0; // (Mandatory) Bus number
+ CRG_SPI_CKEN = 0x10000; // (0x1 << 16) 0:close clk, 1:open clk
+ CRG_SPI_RST = 0x1; // (0x1 << 0) 0:cancel reset, 1:reset
+ match_attr = "hisilicon_hi35xx_spi_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ }
+ controller_0x120c1000 :: spi_controller {
+ busNum = 1;
+ CRG_SPI_CKEN = 0x20000; // (0x1 << 17) 0:close clk, 1:open clk
+ CRG_SPI_RST = 0x2; // (0x1 << 1) 0:cancel reset, 1:reset
+ match_attr = "hisilicon_hi35xx_spi_1";
+ regBase = 0x120c1000; // (Mandatory) Used for address mapping.
+ irqNum = 101; // (Mandatory) Interrupt number
+ }
+ ...
+ //(Optional) Add nodes to the device_info.hcs file as required.
+ }
+ }
+ }
+ ```
+
+3. Initialize the **SpiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **SpiCntlrMethod** \(used to call underlying functions of the driver\) in **SpiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **spi\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the object at the core layer.
+
+ ```
+ struct Pl022 {// Corresponds to parameters in .hcs.
+ struct SpiCntlr *cntlr;
+ struct DListHead deviceList;
+ struct OsalSem sem;
+ volatile unsigned char *phyBase;
+ volatile unsigned char *regBase;
+ uint32_t irqNum;
+ uint32_t busNum;
+ uint32_t numCs;
+ uint32_t curCs;
+ uint32_t speed;
+ uint32_t fifoSize;
+ uint32_t clkRate;
+ uint32_t maxSpeedHz;
+ uint32_t minSpeedHz;
+ uint32_t regCrg;
+ uint32_t clkEnBit;
+ uint32_t clkRstBit;
+ uint32_t regMiscCtrl;
+ uint32_t miscCtrlCsShift;
+ uint32_t miscCtrlCs;
+ uint16_t mode;
+ uint8_t bitsPerWord;
+ uint8_t transferMode;
+ };
+
+ // SpiCntlr is the core layer controller structure. Its members are assigned with values by using the Init function.
+ struct SpiCntlr {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ uint32_t busNum;
+ uint32_t numCs;
+ uint32_t curCs;
+ struct OsalMutex lock;
+ struct SpiCntlrMethod *method;
+ struct DListHead list;
+ void *priv;
+ };
+ ```
+
+ - Instantiate the callback function structure **SpiCntlrMethod** in **SpiCntlr**. Other members are initialized by using the **Init** function.
+
+ ```
+ // Example in spi_hi35xx.c: instantiate the hook.
+ struct SpiCntlrMethod g_method = {
+ .Transfer = Pl022Transfer,
+ .SetCfg = Pl022SetCfg,
+ .GetCfg = Pl022GetCfg,
+ .Open = Pl022Open,
+ .Close = Pl022Close,
+ };
+ ```
+
+ - Bind function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS
+
+ Function description:
+
+ Associates the **SpiCntlr** object with **HdfDeviceObject**.
+
+ ```
+ static int32_t HdfSpiDeviceBind(struct HdfDeviceObject *device)
+ {
+ ...
+ return (SpiCntlrCreate(device) == NULL) ? HDF_FAILURE : HDF_SUCCESS;
+ }
+
+ struct SpiCntlr *SpiCntlrCreate(struct HdfDeviceObject *device)
+ {
+ struct SpiCntlr *cntlr = NULL; // Create the SpiCntlr object of the core layer.
+ ...
+ cntlr = (struct SpiCntlr *)OsalMemCalloc(sizeof(*cntlr));// Allocate memory.
+ ...
+ cntlr->device = device; // Enable conversion between HdfDeviceObject and SpiCntlr.
+ device->service = &(cntlr->service); // Enable conversion between HdfDeviceObject and SpiCntlr.
+ (void)OsalMutexInit(&cntlr->lock); // Initialize the lock.
+ DListHeadInit(&cntlr->list); // Add the corresponding node.
+ cntlr->priv = NULL;
+ return cntlr;
+ }
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Input parameters and return values of the init function
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **SpiCntlr**.
+
+ ```
+ static int32_t HdfSpiDeviceInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct SpiCntlr *cntlr = NULL;
+ ...
+ cntlr = SpiCntlrFromDevice(device);// Forcibly convert HdfDeviceObject to SpiCntlr by using service. For details about the value assignment, see the Bind function.
+ //return (device == NULL) ? NULL : (struct SpiCntlr *)device->service;
+ ...
+ ret = Pl022Init(cntlr, device);// (Mandatory) Instantiate the operation object customized by the vendor. The following is an example:
+ ...
+ ret = Pl022Probe(cntlr->priv);
+ ...
+ return ret;
+ }
+
+ static int32_t Pl022Init(struct SpiCntlr *cntlr, const struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct Pl022 *pl022 = NULL;
+ ...
+ pl022 = (struct Pl022 *)OsalMemCalloc(sizeof(*pl022));// Apply for memory.
+ ...
+ ret = SpiGetBaseCfgFromHcs(pl022, device->property); // Initialize busNum, numCs, speed, fifoSize, clkRate, mode, bitsPerWord, and transferMode.
+ ...
+ ret = SpiGetRegCfgFromHcs(pl022, device->property); // Initialize regBase, phyBase, irqNum, regCrg, clkEnBit ,clkRstBit, regMiscCtrl, miscCtrlCs, and miscCtrlCsShift.
+ ...
+ // Calculate the frequencies corresponding to the maximum and minimum speeds.
+ pl022->maxSpeedHz = (pl022->clkRate) / ((SCR_MIN + 1) * CPSDVSR_MIN);
+ pl022->minSpeedHz = (pl022->clkRate) / ((SCR_MAX + 1) * CPSDVSR_MAX);
+ DListHeadInit(&pl022->deviceList);// Initialize the DList linked list.
+ pl022->cntlr = cntlr; // Enable conversion between Pl022 and SpiCntlr.
+ cntlr->priv = pl022; // Enable conversion between Pl022 and SpiCntlr.
+ cntlr->busNum = pl022->busNum; // Assign a value to busNum in SpiCntlr.
+ cntlr->method = &g_method; // Connect to the SpiCntlrMethod instance.
+ ...
+ ret = Pl022CreatAndInitDevice(pl022);
+ if (ret != 0) {
+ Pl022Release(pl022); // Release the Pl022 object if the initialization fails.
+ return ret;
+ }
+ return 0;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void HdfSpiDeviceRelease(struct HdfDeviceObject *device)
+ {
+ struct SpiCntlr *cntlr = NULL;
+ ...
+ cntlr = SpiCntlrFromDevice(device);// Forcibly convert HdfDeviceObject to SpiCntlr by using service. For details about the value assignment, see the Bind function.
+ // return (device==NULL) ?NULL:(struct SpiCntlr *)device->service;
+ ...
+ if (cntlr->priv != NULL) {
+ Pl022Remove((struct Pl022 *)cntlr->priv);// A forced conversion from SpiCntlr to Pl022 is involved.
+ }
+ SpiCntlrDestroy(cntlr); // Release the Pl022 object.
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-uart-des.md b/en/device-dev/driver/driver-platform-uart-des.md
index a789594525e5d6ebb9270dadd540a35e3d76f887..f6d43fd109b0b41de72fa00e09de73b4298fc972 100644
--- a/en/device-dev/driver/driver-platform-uart-des.md
+++ b/en/device-dev/driver/driver-platform-uart-des.md
@@ -1,8 +1,7 @@
-# UART
+# UART
- [Overview](#section833012453535)
- - [Available APIs](#section1680292311549)
-
+- [Available APIs](#section1928742202715)
- [Usage Guidelines](#section12779050105412)
- [How to Use](#section1858116395510)
- [Obtaining a UART Device Handle](#section124512065617)
@@ -21,27 +20,23 @@
- The Universal Asynchronous Receiver/Transmitter \(UART\) is a universal serial data bus used for asynchronous communication. It enables bi-directional communication between devices in full-duplex mode.
- UART is widely used to print information for debugging or to connect to various external modules such as GPS and Bluetooth.
-- A UART is connected to other modules through two wires \(as shown in [Figure 1](#fig209936401896)\) or four wires \(as shown in [Figure 2](#fig1435614171015)\).
+- A UART is connected to other modules through two wires \(as shown in [Figure 1](#fig68294715408)\) or four wires \(as shown in [Figure 2](#fig179241542163112)\).
- TX: TX pin of the transmitting UART. It is connected to the RX pin of the peer UART.
- RX: RX pin of the receiving UART. It is connected to the TX pin of the peer UART.
- RTS: Request to Send signal pin. It is connected to the CTS pin of the peer UART and is used to indicate whether the local UART is ready to receive data.
- CTS: Clear to Send signal pin. It is connected to the RTS pin of the peer UART and is used to indicate whether the local UART is allowed to send data to the peer end.
- **Figure 1** 2-wire UART communication
-
-
- 
-
- **Figure 2** 4-wire UART communication
-
+ **Figure 1** 2-wire UART communication
+ 
- 
+ **Figure 2** 4-wire UART communication
+ 
- The transmitting and receiving UARTs must ensure that they have the same settings on particular attributes such as the baud rate and data format \(start bit, data bit, parity bit, and stop bit\) before they start to communicate. During data transmission, a UART sends data to the peer end over the TX pin and receives data from the peer end over the RX pin. When the size of the buffer used by a UART for storing received data reaches the preset threshold, the RTS signal of the UART changes to **1** \(data cannot be received\), and the peer UART stops sending data to it because its CTS signal does not allow it to send data.
- The UART interface defines a set of common functions for operating a UART port, including obtaining and releasing device handles, reading and writing data of a specified length, and obtaining and setting the baud rate, as well as the device attributes.
-### Available APIs
+## Available APIs
**Table 1** APIs for the UART driver
@@ -122,12 +117,10 @@
### How to Use
-[Figure 3](#fig1852173020185) shows the process of using a UART device.
-
-**Figure 3** Process of using a UART device
-
+[Figure 3](#fig99673244388) shows the process of using a UART device.
-
+**Figure 3** Process of using a UART device
+
### Obtaining a UART Device Handle
diff --git a/en/device-dev/driver/driver-platform-uart-develop.md b/en/device-dev/driver/driver-platform-uart-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..af8d6a6bb423e35fd6a8ff5df492a6d21ef4c85d
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-uart-develop.md
@@ -0,0 +1,553 @@
+# UART
+
+- [Overview](#section1761881586154520)
+- [How to Develop](#section944397404154520)
+ - [UartHostMethod](#section192316441461)
+
+- [Development Example](#section774610224154520)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the Universal Asynchronous Receiver/Transmitter \(UART\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The UART module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **uart\_config.hcs** file.
+
+3. Instantiate the UART controller object.
+ - Initialize **UartHost**.
+ - Instantiate **UartHostMethod** in the **UartHost** object.
+
+ > **NOTE:**
+ >For details, see [UartHostMethod](#section192316441461) and [Table 1](#table22862114719).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify the basic functions, such as the UART control status and response to interrupts.
+
+
+### UartHostMethod
+
+```
+struct UartHostMethod {
+ int32_t (*Init)(struct UartHost *host);
+ int32_t (*Deinit)(struct UartHost *host);
+ int32_t (*Read)(struct UartHost *host, uint8_t *data, uint32_t size);
+ int32_t (*Write)(struct UartHost *host, uint8_t *data, uint32_t size);
+ int32_t (*GetBaud)(struct UartHost *host, uint32_t *baudRate);
+ int32_t (*SetBaud)(struct UartHost *host, uint32_t baudRate);
+ int32_t (*GetAttribute)(struct UartHost *host, struct UartAttribute *attribute);
+ int32_t (*SetAttribute)(struct UartHost *host, struct UartAttribute *attribute);
+ int32_t (*SetTransMode)(struct UartHost *host, enum UartTransMode mode);
+ int32_t (*pollEvent)(struct UartHost *host, void *filep, void *table);
+};
+```
+
+**Table 1** Callbacks for the members in the UartHostMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+Init
+ |
+host: structure pointer to the UART controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Initializes the UART device.
+ |
+
+Deinit
+ |
+host: structure pointer to the UART controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Deinitializes the UART device.
+ |
+
+Read
+ |
+host: structure pointer to the UART controller at the core layer.
+size: data size, which is of the uint32_t type.
+ |
+data: uint8_t pointer to the output data.
+ |
+HDF_STATUS
+ |
+Receives data.
+ |
+
+Write
+ |
+host: structure pointer to the UART controller at the core layer.
+data: pointer to the input data, which is of the uint8_t type.
+size: data size, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sends data.
+ |
+
+SetBaud
+ |
+host: structure pointer to the UART controller at the core layer.
+baudRate: pointer to the input baud rate, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the baud rate.
+ |
+
+GetBaud
+ |
+host: structure pointer to the UART controller at the core layer.
+ |
+baudRate: uint32_t pointer to the output baud rate.
+ |
+HDF_STATUS
+ |
+Obtains the current baud rate.
+ |
+
+GetAttribute
+ |
+host: structure pointer to the UART controller at the core layer.
+ |
+attribute: structure pointer to the output attributes. For details, see UartAttribute in uart_if.h.
+ |
+HDF_STATUS
+ |
+Obtains UART attributes.
+ |
+
+SetAttribute
+ |
+host: structure pointer to the UART controller at the core layer.
+attribute: structure pointer to the input attributes.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets UART attributes.
+ |
+
+SetTransMode
+ |
+host: structure pointer to the UART controller at the core layer.
+mode: transmission mode, which is an enumerated value. For details, see UartTransMode in uart_if.h).
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the UART transmission mode.
+ |
+
+PollEvent
+ |
+host: structure pointer to the UART controller at the core layer.
+filep: void pointer to a file.
+table: void pointer to a poll_table.
+ |
+–
+ |
+HDF_STATUS
+ |
+Polls for pending events.
+ |
+
+
+
+
+## Development Example
+
+The following uses **uart\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - UART driver entry reference
+
+ ```
+ struct HdfDriverEntry g_hdfUartDevice = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_PLATFORM_UART", // (Mandatory) This parameter must be the same as that in the .hcs file.
+ .Bind = HdfUartDeviceBind, // See the Bind function.
+ .Init = HdfUartDeviceInit, // See the Init function.
+ .Release = HdfUartDeviceRelease, //See the Release function.
+ };
+ // Call HDF_INIT to register the driver entry with the HDF framework.
+ HDF_INIT(g_hdfUartDevice);
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **uart\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **UartHost** members at the core layer.
+
+ In this example, there is only one UART controller. If there are multiple UART controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **uart\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_uart :: device {
+ device0 :: deviceNode {
+ policy = 1; // The value 1 indicates that the driver publishes kernel-mode services. The value 2 indicates that the driver publishes user-mode services.
+ priority = 40; // Driver startup priority
+ permission = 0644; // Permission for the driver to create a device node
+ moduleName = "HDF_PLATFORM_UART"; // Driver name, which must be the same as that of moduleName in the driver entry structure.
+ serviceName = "HDF_PLATFORM_UART_0";// Unique name of the service published by the driver. The name is in the HDF_PLATFORM_UART_X format. X indicates the UART controller number.
+ deviceMatchAttr = "hisilicon_hi35xx_uart_0"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
+ }
+ device1 :: deviceNode {
+ policy = 2;
+ permission = 0644;
+ priority = 40;
+ moduleName = "HDF_PLATFORM_UART";
+ serviceName = "HDF_PLATFORM_UART_1";
+ deviceMatchAttr = "hisilicon_hi35xx_uart_1";
+ }
+ ...
+ }
+ }
+ }
+ }
+ ```
+
+ - **uart\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ template uart_controller {// Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ match_attr = "";
+ num = 0; // (Mandatory) Device number
+ baudrate = 115200; // (Mandatory) Baud rate. Set the value based on service requirements.
+ fifoRxEn = 1; // (Mandatory) Enable the receive of FIFOs.
+ fifoTxEn = 1; // (Mandatory) Enable the transmit of FIFOs.
+ flags = 4; // (Mandatory) Flag signal
+ regPbase = 0x120a0000; // (Mandatory) Used for address mapping.
+ interrupt = 38; // (Mandatory) Interrupt number
+ iomemCount = 0x48; // (Mandatory) Used for address mapping.
+ }
+ controller_0x120a0000 :: uart_controller {
+ match_attr = "hisilicon_hi35xx_uart_0";// (Mandatory) The value must be the same as that of deviceMatchAttr of the corresponding device in device_info.hcs.
+ }
+ controller_0x120a1000 :: uart_controller {
+ num = 1;
+ baudrate = 9600;
+ regPbase = 0x120a1000;
+ interrupt = 39;
+ match_attr = "hisilicon_hi35xx_uart_1";
+ }
+ ...
+ //(Optional) Add nodes to the device_info.hcs file as required.
+ }
+ }
+ ```
+
+3. Initialize the **UartHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **UartHostMethod** \(used to call underlying functions of the driver\) in **UartHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **uart\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
+
+ ```
+ struct UartPl011Port {// Structure related to the API
+ int32_t enable;
+ unsigned long physBase; // Physical address
+ uint32_t irqNum; // Interrupt number
+ uint32_t defaultBaudrate;// Default baud rate
+ uint32_t flags; // Flag signal, which is related to the following three macros.
+ #define PL011_FLG_IRQ_REQUESTED (1 << 0)
+ #define PL011_FLG_DMA_RX_REQUESTED (1 << 1)
+ #define PL011_FLG_DMA_TX_REQUESTED (1 << 2)
+ struct UartDmaTransfer *rxUdt; // DMA transmission
+ struct UartDriverData *udd; // See the following description.
+ };
+ struct UartDriverData {// Structure related to data transmission
+ uint32_t num;
+ uint32_t baudrate; // Baud rate (configurable)
+ struct UartAttribute attr; // Transmission attributes, such as the data bit and stop bit
+ struct UartTransfer *rxTransfer; // FIFO structure related to the buffer
+ wait_queue_head_t wait; // Queuing signal related to conditional variables
+ int32_t count; // Data count
+ int32_t state; // UART controller status
+ #define UART_STATE_NOT_OPENED 0
+ #define UART_STATE_OPENING 1
+ #define UART_STATE_USEABLE 2
+ #define UART_STATE_SUSPENED 3
+ uint32_t flags; // Status flag
+ #define UART_FLG_DMA_RX (1 << 0)
+ #define UART_FLG_DMA_TX (1 << 1)
+ #define UART_FLG_RD_BLOCK (1 << 2)
+ RecvNotify recv; // Pointer to the function that receives serial port data
+ struct UartOps *ops; // Custom function pointer structure. For details, see device/hisilicon/drivers/uart/uart_pl011.c.
+ void *private; // It stores the start address of UartPl011Port for easy invocation.
+ };
+
+ // UartHost is the controller structure at the core layer. Its members are assigned with values by using the Init function.
+ struct UartHost {
+ struct IDeviceIoService service;
+ struct HdfDeviceObject *device;
+ uint32_t num;
+ OsalAtomic atom;
+ void *priv; // It stores the start address of the vendor's custom structure for invoking the structure.
+ struct UartHostMethod *method; // Hook at the core layer. The vendor needs to implement and instantiate its member functions.
+ };
+ ```
+
+ - Instantiate the callback function structure **UartHostMethod** in **UartHost**. Other members are initialized by using the **Bind** function.
+
+ ```
+ // Example in pwm_hi35xx.c: instantiate the hook.
+ struct UartHostMethod g_uartHostMethod = {
+ .Init = Hi35xxInit,
+ .Deinit = Hi35xxDeinit,
+ .Read = Hi35xxRead,
+ .Write = Hi35xxWrite,
+ .SetBaud = Hi35xxSetBaud,
+ .GetBaud = Hi35xxGetBaud,
+ .SetAttribute = Hi35xxSetAttribute,
+ .GetAttribute = Hi35xxGetAttribute,
+ .SetTransMode = Hi35xxSetTransMode,
+ .pollEvent = Hi35xxPollEvent,
+ };
+ ```
+
+ - Bind function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Input parameters and return values of the Bind function
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Invalid controller object
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_INVALID_PARAM
+ |
+ Invalid parameter
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **UartHost**.
+
+ ```
+ //uart_hi35xx.c
+ static int32_t HdfUartDeviceBind(struct HdfDeviceObject *device)
+ {
+ ...
+ return (UartHostCreate(device) == NULL)? HDF_FAILURE: HDF_SUCCESS;// (Mandatory) Call UartHostCreate.
+ }
+ // Description of the UartHostCreate function at the core layer in uart_core.c
+ struct UartHost *UartHostCreate(struct HdfDeviceObject *device)
+ {
+ struct UartHost *host = NULL; // Create a UartHost.
+ ...
+ host = (struct UartHost *)OsalMemCalloc(sizeof(*host));// Apply for memory.
+ ...
+ host->device = device; // (Mandatory) Enable conversion between HdfDeviceObject and UartHost.
+ device->service = &(host->service); // (Mandatory) Enable conversion between HdfDeviceObject and UartHost.
+ host->device->service->Dispatch = UartIoDispatch;// Assign a value to the Dispatch method of service.
+ OsalAtomicSet(&host->atom, 0); // Initialize or set atomic data.
+ host->priv = NULL;
+ host->method = NULL;
+ return host;
+ }
+ ```
+
+ - Init function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ HDF\_STATUS
+
+ Function description:
+
+ Initializes the custom structure object and **UartHost**, calls the **artAddDev** function at the core layer, and connects to VFS.
+
+ ```
+ int32_t HdfUartDeviceInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct UartHost *host = NULL;
+ HDF_LOGI("%s: entry", __func__);
+ ...
+ host = UartHostFromDevice(device);// Forcibly convert to UartHost by using service. The value is assigned in the Bind function.
+ ...
+ ret = Hi35xxAttach(host, device); // Initialize the UartHost object.
+ ...
+ host->method = &g_uartHostMethod; // Connect to the UARTHostMethod instance.
+ return ret;
+ }
+ // Complete initialization of the UartHost object.
+ static int32_t Hi35xxAttach(struct UartHost *host, struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ // udd and port are structure objects customized by the vendor. Implement related functions as required.
+ struct UartDriverData *udd = NULL;
+ struct UartPl011Port *port = NULL;
+ ...
+ // Steps [1] to [7] assign values to udd and then to the UartHost object at the core layer.
+ udd = (struct UartDriverData *)OsalMemCalloc(sizeof(*udd));// [1]
+ ...
+ port = (struct UartPl011Port *)OsalMemCalloc(sizeof(struct UartPl011Port));// [2]
+ ...
+ udd->ops = Pl011GetOps();// [3] Perform operations, such as starting or stopping a device, setting attributes, and sending data.
+ udd->recv = PL011UartRecvNotify;// [4] Connect to the data receiving notification function (conditional lock mechanism).
+ udd->count = 0; // [5]
+ port->udd = udd; // [6] Enable conversion between UartPl011Port and UartDriverData.
+ ret = UartGetConfigFromHcs(port, device->property);// (Mandatory) Transfer the attributes of HdfDeviceObject to the vendor custom structure.
+ // The sample code is as follows:
+ ...
+ udd->private = port; // [7]
+
+ host->priv = udd; // (Mandatory) Enable conversion between UartHost and UartDriverData.
+ host->num = udd->num;// (Mandatory) UART device number
+ UartAddDev(host); // (Mandatory) Function in uart_dev.c at the core layer used to register a character device node with the VFS so that the UART can be accessed in user mode through this virtual file node.
+ return HDF_SUCCESS;
+ }
+
+ static int32_t UartGetConfigFromHcs(struct UartPl011Port *port, const struct DeviceResourceNode *node)
+ {
+ uint32_t tmp, regPbase, iomemCount;
+ struct UartDriverData *udd = port->udd;
+ struct DeviceResourceIface *iface = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
+ ...
+ // Extract the value based on the request parameter and assign the value to the vendor custom structure.
+ if (iface->GetUint32(node, "num", &udd->num, 0) != HDF_SUCCESS) {
+ HDF_LOGE("%s: read busNum fail", __func__);
+ return HDF_FAILURE;
+ }
+ ...
+ return 0;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ void HdfUartDeviceRelease(struct HdfDeviceObject *device)
+ {
+ struct UartHost *host = NULL;
+ ...
+ host = UartHostFromDevice(device);// Forcibly convert HdfDeviceObject to UartHost by using service. For details about the value assignment, see the Bind function.
+ ...
+ if (host->priv != NULL) {
+ Hi35xxDetach(host); // Memory release function customized by the vendor. For details, see the following description.
+ }
+ UartHostDestroy(host); // Call the function of the core layer to release the host.
+ }
+
+ static void Hi35xxDetach(struct UartHost *host)
+ {
+ struct UartDriverData *udd = NULL;
+ struct UartPl011Port *port = NULL;
+ ...
+ udd = host->priv; // Convert UartHost to UartDriverData.
+ ...
+ UartRemoveDev(host);// Remove the VFS.
+ port = udd->private;// Convert UartDriverData to UartPl011Port.
+ if (port != NULL) {
+ if (port->physBase != 0) {
+ OsalIoUnmap((void *)port->physBase);// Remove address mapping.
+ }
+ (void)OsalMemFree(port);
+ udd->private = NULL;
+ }
+ (void)OsalMemFree(udd);// Release UartDriverData.
+ host->priv = NULL;
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform-watchdog-des.md b/en/device-dev/driver/driver-platform-watchdog-des.md
index 6b907fcdf0dd75eb047d74a045d79a4ab16e00ce..ba879b0aea477c8babc0f125c51e9ee5bc0d6ac2 100644
--- a/en/device-dev/driver/driver-platform-watchdog-des.md
+++ b/en/device-dev/driver/driver-platform-watchdog-des.md
@@ -1,8 +1,7 @@
-# Watchdog
+# Watchdog
- [Overview](#section14918241977)
- - [Available APIs](#section20177131219818)
-
+- [Available APIs](#section1180575010271)
- [Usage Guidelines](#section10103184312813)
- [How to Use](#section10181195910815)
- [Opening a Watchdog](#section66089201107)
@@ -20,7 +19,7 @@
A watchdog, also called a watchdog timer, is a hardware timing device. If an error occurs in the main program of the system and fails to reset the watchdog timer, the watchdog timer sends a reset signal to restore the system to a normal state.
-### Available APIs
+## Available APIs
**Table 1** Watchdog APIs
@@ -93,18 +92,16 @@ A watchdog, also called a watchdog timer, is a hardware timing device. If an err
### How to Use
-[Figure 1](#fig19134125410189) illustrates the process of using a watchdog.
-
-**Figure 1** Process of using a watchdog
-
+[Figure 1](#fig430533913392) illustrates the process of using a watchdog.
-
+**Figure 1** Process of using a watchdog
+
### Opening a Watchdog
Use **WatchdogOpen** to open a watchdog. A system may have multiple watchdogs. You can open the specified watchdog by using the ID.
-DevHandle WatchdogOpen\(int16\_t wdtId\);
+int32\_t WatchdogOpen\(int16\_t wdtId\);
**Table 2** Description of WatchdogOpen
@@ -201,7 +198,7 @@ if (ret != 0) {
### Setting the Timeout Duration
-int32\_t WatchdogSetTimeout\(DevHandle \*handle, uint32\_t seconds\);
+int32\_t WatchdogSetTimeout\(PalHandle \*handle, uint32\_t seconds\);
**Table 4** Description of WatchdogSetTimeout
@@ -253,7 +250,7 @@ if (ret != 0) {
### Obtaining the Timeout Duration
-int32\_t WatchdogGetTimeout\(DevHandle \*handle, uint32\_t \*seconds\);
+int32\_t WatchdogGetTimeout\(PalHandle \*handle, uint32\_t \*seconds\);
**Table 5** Description of WatchdogGetTimeout
diff --git a/en/device-dev/driver/driver-platform-watchdog-develop.md b/en/device-dev/driver/driver-platform-watchdog-develop.md
new file mode 100644
index 0000000000000000000000000000000000000000..12dda102995817bc112fe87a384467665b349da2
--- /dev/null
+++ b/en/device-dev/driver/driver-platform-watchdog-develop.md
@@ -0,0 +1,364 @@
+# Watchdog
+
+- [Overview](#section1315827527160117)
+- [How to Develop](#section477974542160117)
+ - [WatchdogMethod](#section220331929)
+
+- [Development Example](#section1832270347160117)
+
+## Overview
+
+In the Hardware Driver Foundation \(HDF\) framework, the Watchdog \(also called Watchdog timer\) module uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
+
+**Figure 1** Independent service mode
+
+
+## How to Develop
+
+The Watchdog module adaptation involves the following steps:
+
+1. Instantiate the driver entry.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+
+2. Configure attribute files.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **watchdog\_config.hcs** file.
+
+3. Instantiate the Watchdog controller object.
+ - Initialize **WatchdogCntlr**.
+ - Instantiate **WatchdogMethod** in the **WatchdogCntlr** object.
+
+ > **NOTE:**
+ >For details, see [WatchdogMethod](#section220331929) and [Table 1](#table1370451732).
+
+
+4. Debug the driver.
+ - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the watchdog timer is successfully set.
+
+
+### WatchdogMethod
+
+```
+struct WatchdogMethod {
+ int32_t (*getStatus)(struct WatchdogCntlr *wdt, int32_t *status);
+ int32_t (*setTimeout)(struct WatchdogCntlr *wdt, uint32_t seconds);
+ int32_t (*getTimeout)(struct WatchdogCntlr *wdt, uint32_t *seconds);
+ int32_t (*start)(struct WatchdogCntlr *wdt);
+ int32_t (*stop)(struct WatchdogCntlr *wdt);
+ int32_t (*feed)(struct WatchdogCntlr *wdt);
+ int32_t (*getPriv)(struct WatchdogCntlr *wdt); // (Optional) If WatchdogCntlr has the priv member, instantiate priv.
+ void (*releasePriv)(struct WatchdogCntlr *wdt);// (Optional)
+};
+```
+
+**Table 1** Callbacks for the members in the WatchdogMethod structure
+
+
+Callback
+ |
+Input Parameter
+ |
+Output Parameter
+ |
+Return Value
+ |
+Description
+ |
+
|---|
+
+getStatus
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+ |
+status: int32_t pointer indicating the watchdog status (started or stopped).
+ |
+HDF_STATUS
+ |
+Obtains the watchdog status.
+ |
+
+start
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Starts a watchdog.
+ |
+
+stop
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Stops a watchdog.
+ |
+
+setTimeout
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+seconds: input time value, which is of the uint32_t type.
+ |
+–
+ |
+HDF_STATUS
+ |
+Sets the timeout period (in seconds) for a watchdog. Ensure that the actual watchdog running time complies with this setting.
+ |
+
+getTimeout
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+ |
+seconds: output time value, which is of the uint32_t type.
+ |
+HDF_STATUS
+ |
+Obtains the timeout period of a watchdog.
+ |
+
+feed
+ |
+wdt: structure pointer to the Watchdog controller at the core layer.
+ |
+–
+ |
+HDF_STATUS
+ |
+Feeds a watchdog.
+ |
+
+
+
+
+## Development Example
+
+The following uses **watchdog\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+
+ - Watchdog driver entry reference
+
+ ```
+ struct HdfDriverEntry g_watchdogDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = Hi35xxWatchdogBind, // See the Bind function.
+ .Init = Hi35xxWatchdogInit, // See the Init function.
+ .Release = Hi35xxWatchdogRelease, //See the Release function.
+ .moduleName = "HDF_PLATFORM_WATCHDOG",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
+ };
+ HDF_INIT(g_watchdogDriverEntry);// Call HDF_INIT to register the driver entry with the HDF framework.
+ ```
+
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the component attributes in the **watchdog\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **WatchdogCntlr** members at the core layer.
+
+ In this example, there is only one Watchdog controller. If there are multiple Watchdog controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **watchdog\_config** file.
+
+ - **device\_info.hcs** configuration reference
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ device_watchdog :: device {// Device node
+ device0:: deviceNode {// DeviceNode of the driver
+ The policy = 1; // The value 1 indicates that the driver publishes kernel-mode services. The value 2 indicates that the driver publishes user-mode services.
+ priority = 20; // Driver startup priority
+ permission = 0644; // Permission to create device nodes for the driver
+ moduleName = "HDF_PLATFORM_WATCHDOG";
+ // (Mandatory) Driver name. The value must be the same as that of moduleName in the driver entry structure.
+ serviceName = "HDF_PLATFORM_WATCHDOG_0";
+ // (Mandatory) Unique name of the service published by the driver.
+ deviceMatchAttr = "hisilicon_hi35xx_watchdog_0";
+ // (Mandatory) Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
+ }
+ }
+ }
+ }
+ ```
+
+ - **watchdog\_config.hcs** configuration reference
+
+ ```
+ root {
+ platform {
+ template watchdog_controller {// Template configuration. In the template, you can configure the common parameters shared by service nodes.
+ id = 0;
+ match_attr = "";
+ regBase = 0x12050000; // (Mandatory) Used for address mapping.
+ regStep = 0x1000; // (Mandatory) Used for address mapping.
+ }
+ controller_0x12050000 :: watchdog_controller {// (Mandatory) Keyword for matching the private data of the device driver.
+ match_attr = "hisilicon_hi35xx_watchdog_0"; // (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
+ }
+ // Configure this parameter when there are multiple watchdogs.
+ ...
+ }
+ }
+ ```
+
+3. Initialize the **WatchdogCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **WatchdogMethod** \(used to call underlying functions of the driver\) in **WatchdogCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+ - Custom structure reference
+
+ To the driver, the custom structure carries parameters and data. The values in the **watchdog\_config.hcs** file are read by the HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the index and the number of pins, are also transferred to the **WatchdogCntlr** object at the core layer.
+
+ ```
+ struct Hi35xxWatchdog {
+ struct WatchdogCntlr wdt; // (Mandatory) Carrier that connects the upper and underlying layers. For details, see the following description.
+ OsalSpinlock lock;
+ volatile unsigned char *regBase;// [Mandatory] Used for address mapping.
+ uint32_t phyBase; // (Mandatory) Used for address mapping.
+ uint32_t regStep; // (Mandatory) Used for address mapping.
+ };
+ // WatchdogCntlr is the core layer controller structure. Its members are assigned with values by using the Init function.
+ struct WatchdogCntlr {
+ struct IDeviceIoService service;// Driver service
+ struct HdfDeviceObject *device; // Drive device
+ OsalSpinlock lock; // This variable implements the spinlock function.
+ struct WatchdogMethod *ops; // Interface callback
+ int16_t wdtId; // ID of the watchdog device
+ void *priv; // Save the pointer.
+ };
+ ```
+
+ - Instantiate the callback function structure **WatchdogMethod** in **WatchdogCntlr**. Other members are initialized by using the **Init** and **Bind** functions.
+
+ ```
+ static struct WatchdogMethod g_method = {
+ .getStatus = Hi35xxWatchdogGetStatus,
+ .start = Hi35xxWatchdogStart,
+ .stop = Hi35xxWatchdogStop,
+ .setTimeout = Hi35xxWatchdogSetTimeout,
+ .getTimeout = Hi35xxWatchdogGetTimeout,
+ .feed = Hi35xxWatchdogFeed,
+ };
+ ```
+
+ - Init and Bind functions
+
+ Input parameters:
+
+ **HdfDeviceObject**: device object created by the HDF framework for each driver. It stores device-related private data and service APIs.
+
+ Return values:
+
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+
+ **Table 2** Input parameters and return values of the Init and Bind functions
+
+
+ Status (Value)
+ |
+ Description
+ |
+
|---|
+
+ HDF_ERR_INVALID_OBJECT
+ |
+ Failed to locate the watchdog device
+ |
+
+ HDF_ERR_MALLOC_FAIL
+ |
+ Failed to allocate memory
+ |
+
+ HDF_ERR_IO
+ |
+ I/O error
+ |
+
+ HDF_SUCCESS
+ |
+ Initialization successful
+ |
+
+ HDF_FAILURE
+ |
+ Initialization failed
+ |
+
+
+
+
+ Function description:
+
+ Initializes the custom structure object and **WatchdogCntlr**, and calls the **WatchdogCntlrAdd** function at the core layer.
+
+ ```
+ // Generally, the Init function initializes the members of the Hi35xxWatchdog structure based on the attribute values of the input parameter (HdfDeviceObject).
+ // In this example, the Bind function initializes the Hi35xxWatchdog structure.
+ static int32_t Hi35xxWatchdogInit(struct HdfDeviceObject *device)
+ {
+ (void)device;
+ return HDF_SUCCESS;
+ }
+
+ static int32_t Hi35xxWatchdogBind(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct Hi35xxWatchdog *hwdt = NULL;
+ ...
+ hwdt = (struct Hi35xxWatchdog *)OsalMemCalloc(sizeof(*hwdt));// Apply for memory for the Hi35xxWatchdog structure.
+ ...
+ hwdt->regBase = OsalIoRemap(hwdt->phyBase, hwdt->regStep); // Address mapping
+ ...
+ hwdt->wdt.priv = (void *)device->property;// (Optional) Assign the device attribute values to priv. However, priv is not called subsequently.
+ //If priv needs to be called, instantiate the getPriv and releasePriv member functions in WatchdogMethod.
+ hwdt->wdt.ops = &g_method; // (Mandatory) Assign the instantiated objects to the ops member so that the top layer can invoke the WatchdogMethod member functions.
+ hwdt->wdt.device = device; // (Mandatory) Enable conversion between HdfDeviceObject and WatchdogcCntlr.
+ ret = WatchdogCntlrAdd(&hwdt->wdt); // (Mandatory) Call this function to initialize the structure of the core layer. The driver accesses the platform core layer only after a success signal is returned.
+ if (ret != HDF_SUCCESS) {// If the operation fails, release the resources used by the Init function.
+ OsalIoUnmap((void *)hwdt->regBase);
+ OsalMemFree(hwdt);
+ return ret;
+ }
+ return HDF_SUCCESS;
+ }
+ ```
+
+ - Release function
+
+ Input parameters:
+
+ **HdfDeviceObject**: device object created by the HDF framework for each driver. It stores device-related private data and service APIs.
+
+ Return values:
+
+ –
+
+ Function description:
+
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+
+ ```
+ static void Hi35xxWatchdogRelease(struct HdfDeviceObject *device)
+ {
+ struct WatchdogCntlr *wdt = NULL;
+ struct Hi35xxWatchdog *hwdt = NULL;
+ ...
+ wdt = WatchdogCntlrFromDevice(device);// Convert HdfDeviceObject to WatchdogCntlr by the service member.
+ //return (device == NULL) ? NULL : (struct WatchdogCntlr *)device->service;
+ if (wdt == NULL) {
+ return;
+ }
+ WatchdogCntlrRemove(wdt); // Core layer function used to execute wdt->device->service = NULL and release cntlr->lock.
+ hwdt = (struct Hi35xxWatchdog *)wdt; // Convert WatchdogCntlr to HimciHost.
+ if (hwdt->regBase != NULL) {// Remove address mapping.
+ OsalIoUnmap((void *)hwdt->regBase);
+ hwdt->regBase = NULL;
+ }
+ OsalMemFree(hwdt); // Release the memory occupied by the vendor-defined objects.
+ }
+ ```
+
+
+
diff --git a/en/device-dev/driver/driver-platform.md b/en/device-dev/driver/driver-platform.md
index ddbfedc5a0e14056b2cbe96723c2fc71d174629f..c84f14e45a7fe6b519b87b55e8e025f58932b030 100644
--- a/en/device-dev/driver/driver-platform.md
+++ b/en/device-dev/driver/driver-platform.md
@@ -1,4 +1,4 @@
-# Platform Drivers
+# Platform Driver Usage
- **[GPIO](driver-platform-gpio-des.md)**
@@ -16,4 +16,6 @@
- **[MIPI DSI](driver-platform-mipidsi-des.md)**
+- **[PWM](driver-platform-pwm-des.md)**
+
diff --git a/en/device-dev/driver/driver.md b/en/device-dev/driver/driver.md
index a046ce6e68b6b7ede4a835f772a75962b1fc870c..bca7b47489b24cc2d47a713736a6aeaec3753103 100644
--- a/en/device-dev/driver/driver.md
+++ b/en/device-dev/driver/driver.md
@@ -1,9 +1,11 @@
-# Driver Usage Guidelines
+# Drivers
- **[HDF](driver-hdf.md)**
-- **[Platform Drivers](driver-platform.md)**
+- **[Platform Driver Development](driver-develop.md)**
-- **[Peripherals](driver-peripherals.md)**
+- **[Platform Driver Usage](driver-platform.md)**
+
+- **[Peripheral Driver Usage](driver-peripherals.md)**
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123582482.png b/en/device-dev/driver/figure/en-us_image_0000001123582482.png
deleted file mode 100644
index b5e82f09cd764b0cd9dc835e55f8f878b77eb91e..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/figure/en-us_image_0000001123582482.png and /dev/null differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001170229891.png b/en/device-dev/driver/figure/en-us_image_0000001170229891.png
deleted file mode 100644
index ba2c643927299fc56345601484e246a5abdb2535..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/figure/en-us_image_0000001170229891.png and /dev/null differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001170262141.png b/en/device-dev/driver/figures/2-wire-uart-communication.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001170262141.png
rename to en/device-dev/driver/figures/2-wire-uart-communication.png
diff --git a/en/device-dev/driver/figures/4-wire-uart-communication.png b/en/device-dev/driver/figures/4-wire-uart-communication.png
new file mode 100644
index 0000000000000000000000000000000000000000..6ac63e41108abd4776621356c3034fc52b6f436f
Binary files /dev/null and b/en/device-dev/driver/figures/4-wire-uart-communication.png differ
diff --git a/en/device-dev/driver/figure/architecture-of-the-display-driver-model.png b/en/device-dev/driver/figures/architecture-of-the-display-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figure/architecture-of-the-display-driver-model.png
rename to en/device-dev/driver/figures/architecture-of-the-display-driver-model.png
diff --git a/en/device-dev/driver/figure/architecture-of-the-input-driver-model.png b/en/device-dev/driver/figures/architecture-of-the-input-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figure/architecture-of-the-input-driver-model.png
rename to en/device-dev/driver/figures/architecture-of-the-input-driver-model.png
diff --git a/en/device-dev/driver/figure/architecture-of-the-sensor-driver-model.png b/en/device-dev/driver/figures/architecture-of-the-sensor-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figure/architecture-of-the-sensor-driver-model.png
rename to en/device-dev/driver/figures/architecture-of-the-sensor-driver-model.png
diff --git "a/en/device-dev/driver/figure/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png" b/en/device-dev/driver/figures/available-apis-of-the-wlan-module.png
similarity index 100%
rename from "en/device-dev/driver/figure/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png"
rename to en/device-dev/driver/figures/available-apis-of-the-wlan-module.png
diff --git a/en/device-dev/driver/figure/common-pins-of-the-touchscreen.png b/en/device-dev/driver/figures/common-pins-of-the-touchscreen.png
similarity index 100%
rename from en/device-dev/driver/figure/common-pins-of-the-touchscreen.png
rename to en/device-dev/driver/figures/common-pins-of-the-touchscreen.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001053405727.png b/en/device-dev/driver/figures/configuration-process.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001053405727.png
rename to en/device-dev/driver/figures/configuration-process.png
diff --git a/en/device-dev/driver/figure/dsi-transmitting-and-receiving-interface.png b/en/device-dev/driver/figures/dsi-transmitting-and-receiving-interface.png
similarity index 100%
rename from en/device-dev/driver/figure/dsi-transmitting-and-receiving-interface.png
rename to en/device-dev/driver/figures/dsi-transmitting-and-receiving-interface.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001054280608.png b/en/device-dev/driver/figures/en-us_image_0000001160971556.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001054280608.png
rename to en/device-dev/driver/figures/en-us_image_0000001160971556.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123540984.png b/en/device-dev/driver/figures/en-us_image_0000001206291517.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123540984.png
rename to en/device-dev/driver/figures/en-us_image_0000001206291517.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001206372673.png b/en/device-dev/driver/figures/en-us_image_0000001206372673.png
new file mode 100644
index 0000000000000000000000000000000000000000..f33d6dbfa31952eb162568bd5e81ff2e9387d3a5
Binary files /dev/null and b/en/device-dev/driver/figures/en-us_image_0000001206372673.png differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001054564784.png b/en/device-dev/driver/figures/hdf-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001054564784.png
rename to en/device-dev/driver/figures/hdf-driver-model.png
diff --git a/en/device-dev/driver/figures/independent-service-mode-10.png b/en/device-dev/driver/figures/independent-service-mode-10.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-10.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode-11.png b/en/device-dev/driver/figures/independent-service-mode-11.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-11.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode-12.png b/en/device-dev/driver/figures/independent-service-mode-12.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-12.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode-13.png b/en/device-dev/driver/figures/independent-service-mode-13.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-13.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode-14.png b/en/device-dev/driver/figures/independent-service-mode-14.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-14.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode-15.png b/en/device-dev/driver/figures/independent-service-mode-15.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode-15.png differ
diff --git a/en/device-dev/driver/figures/independent-service-mode.png b/en/device-dev/driver/figures/independent-service-mode.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1457af7a0512dbd08436c3dd9d24654c200b85a
Binary files /dev/null and b/en/device-dev/driver/figures/independent-service-mode.png differ
diff --git a/en/device-dev/driver/figure/mipi-dsi.png b/en/device-dev/driver/figures/mipi-dsi.png
similarity index 100%
rename from en/device-dev/driver/figure/mipi-dsi.png
rename to en/device-dev/driver/figures/mipi-dsi.png
diff --git a/en/device-dev/driver/figure/physical-connection-diagram-for-i2c.png b/en/device-dev/driver/figures/physical-connection-diagram-for-i2c.png
similarity index 100%
rename from en/device-dev/driver/figure/physical-connection-diagram-for-i2c.png
rename to en/device-dev/driver/figures/physical-connection-diagram-for-i2c.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001170187071.png b/en/device-dev/driver/figures/process-of-using-a-gpio.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001170187071.png
rename to en/device-dev/driver/figures/process-of-using-a-gpio.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123514210.png b/en/device-dev/driver/figures/process-of-using-a-mipi-dsi-device.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123514210.png
rename to en/device-dev/driver/figures/process-of-using-a-mipi-dsi-device.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001170227689.png b/en/device-dev/driver/figures/process-of-using-a-uart-device.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001170227689.png
rename to en/device-dev/driver/figures/process-of-using-a-uart-device.png
diff --git a/en/device-dev/driver/figures/process-of-using-a-watchdog.png b/en/device-dev/driver/figures/process-of-using-a-watchdog.png
new file mode 100644
index 0000000000000000000000000000000000000000..c2826f6fff6ba9092c0ccb3f9f7bf91e3c23a094
Binary files /dev/null and b/en/device-dev/driver/figures/process-of-using-a-watchdog.png differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123509750.png b/en/device-dev/driver/figures/process-of-using-an-i2c-device.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123509750.png
rename to en/device-dev/driver/figures/process-of-using-an-i2c-device.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123675706.png b/en/device-dev/driver/figures/process-of-using-an-rtc-device.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123675706.png
rename to en/device-dev/driver/figures/process-of-using-an-rtc-device.png
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123703482.png b/en/device-dev/driver/figures/process-of-using-an-spi-device.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123703482.png
rename to en/device-dev/driver/figures/process-of-using-an-spi-device.png
diff --git a/en/device-dev/driver/figures/service-free-mode-9.png b/en/device-dev/driver/figures/service-free-mode-9.png
new file mode 100644
index 0000000000000000000000000000000000000000..b6e5bd670bfa33120969b239d7564cff888a8fc3
Binary files /dev/null and b/en/device-dev/driver/figures/service-free-mode-9.png differ
diff --git a/en/device-dev/driver/figures/service-free-mode.png b/en/device-dev/driver/figures/service-free-mode.png
new file mode 100644
index 0000000000000000000000000000000000000000..b6e5bd670bfa33120969b239d7564cff888a8fc3
Binary files /dev/null and b/en/device-dev/driver/figures/service-free-mode.png differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001123742254.png b/en/device-dev/driver/figures/spi-controller-device-connection.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001123742254.png
rename to en/device-dev/driver/figures/spi-controller-device-connection.png
diff --git a/en/device-dev/driver/figure/ttl-interface.png b/en/device-dev/driver/figures/ttl-interface.png
similarity index 100%
rename from en/device-dev/driver/figure/ttl-interface.png
rename to en/device-dev/driver/figures/ttl-interface.png
diff --git a/en/device-dev/driver/figures/unified-service-mode-8.png b/en/device-dev/driver/figures/unified-service-mode-8.png
new file mode 100644
index 0000000000000000000000000000000000000000..6e922299f648f02da320ed101119f1a1698bc609
Binary files /dev/null and b/en/device-dev/driver/figures/unified-service-mode-8.png differ
diff --git a/en/device-dev/driver/figures/unified-service-mode.png b/en/device-dev/driver/figures/unified-service-mode.png
new file mode 100644
index 0000000000000000000000000000000000000000..6e922299f648f02da320ed101119f1a1698bc609
Binary files /dev/null and b/en/device-dev/driver/figures/unified-service-mode.png differ
diff --git a/en/device-dev/driver/figure/en-us_image_0000001170383063.png b/en/device-dev/driver/figures/wlan-framework.png
similarity index 100%
rename from en/device-dev/driver/figure/en-us_image_0000001170383063.png
rename to en/device-dev/driver/figures/wlan-framework.png
diff --git a/en/device-dev/get-code/figure/customizing-bundles.png b/en/device-dev/get-code/figure/customizing-bundles.png
index dcf65897e486f38eb7dfadf8cb87b981d41b7df3..f7158c1945d9699c7c96ba87ffe92a6c5266eef0 100644
Binary files a/en/device-dev/get-code/figure/customizing-bundles.png and b/en/device-dev/get-code/figure/customizing-bundles.png differ
diff --git a/en/device-dev/get-code/figure/example-distribution.png b/en/device-dev/get-code/figure/example-distribution.png
index 3a24b14afa5429a10663c8eb131b0712819cbd30..34478a9830be33d552accb67af2ce7d111eafc6b 100644
Binary files a/en/device-dev/get-code/figure/example-distribution.png and b/en/device-dev/get-code/figure/example-distribution.png differ
diff --git a/en/device-dev/get-code/figure/hpm-page.png b/en/device-dev/get-code/figure/hpm-page.png
index 65723fc68df95d9d4ceca1b6d3ff316e72bd9a84..7302e20d86e44d331d79e3aa15e58ded5b860088 100644
Binary files a/en/device-dev/get-code/figure/hpm-page.png and b/en/device-dev/get-code/figure/hpm-page.png differ
diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md
index b88beb7be4f295c51618194343e23a32aa29d41a..afad91900a056f6940c3df29fa813e8823cb916f 100644
--- a/en/device-dev/porting/Readme-EN.md
+++ b/en/device-dev/porting/Readme-EN.md
@@ -49,6 +49,7 @@ The download steps for other resources are the same as those in the mainline ver
- [Platform Driver Porting](porting-smallchip-driver-plat.md)
- [Device Driver Porting](porting-smallchip-driver-oom.md)
- [Standard System Porting Guide](standard-system-porting-guide.md)
+- [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting-linux-kernel-overview.md)
# Third-Party Library Porting Guide
diff --git a/en/device-dev/porting/figure/menuconfig.png b/en/device-dev/porting/figure/menuconfig.png
new file mode 100644
index 0000000000000000000000000000000000000000..2668799e706c34df82d75050e701f450e226a536
Binary files /dev/null and b/en/device-dev/porting/figure/menuconfig.png differ
diff --git a/en/device-dev/porting/figure/openharmony_kernel.png b/en/device-dev/porting/figure/openharmony_kernel.png
new file mode 100644
index 0000000000000000000000000000000000000000..2b7b88cb6c984107b4c6fb243685966345321b2d
Binary files /dev/null and b/en/device-dev/porting/figure/openharmony_kernel.png differ
diff --git a/en/device-dev/porting/figure/technical-architecture.png b/en/device-dev/porting/figure/technical-architecture.png
new file mode 100644
index 0000000000000000000000000000000000000000..c6f018f5ff05dfdde2f37f4d4a6c9654f2bd7001
Binary files /dev/null and b/en/device-dev/porting/figure/technical-architecture.png differ
diff --git a/en/device-dev/porting/porting-linux-kernel-overview.md b/en/device-dev/porting/porting-linux-kernel-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..9f9781702136237ad9f03f4360e4d090a152199d
--- /dev/null
+++ b/en/device-dev/porting/porting-linux-kernel-overview.md
@@ -0,0 +1,313 @@
+# A Method for Rapidly Porting the OpenHarmony Linux Kernel
+
+- [Overview](#section28051350151118)
+- [Overall Porting Approach](#section994883124)
+ - [Kernel Mode Layer and User Mode Layer](#section953481431217)
+ - [Composition of the Kernel Mode Layer](#section81437528121)
+ - [Overall Porting Process](#section86060191)
+
+- [Procedure](#section98871341171310)
+ - [Setting Up the Environment](#section16584650181314)
+ - [Porting Basic Kernel-Mode Code](#section95112081716)
+ - [Porting the HDF Feature](#section12971205681710)
+ - [Building the Image](#section1681965561911)
+ - [\(Optional\) Building and Running HDF Test Cases](#section460792312204)
+
+
+## Overview
+
+This document describes how to quickly port OpenHarmony to a third-party chip platform by using the existing capabilities of the Linux kernel of the third-party chip platform.
+
+## Overall Porting Approach
+
+### Kernel Mode Layer and User Mode Layer
+
+For easy description, we divide the OpenHarmony architecture into two parts:
+
+OpenHarmony = Kernel mode layer + User mode layer
+
+
+
+The kernel mode layer is the OpenHarmony kernel layer \(purple part in the figure\). It consists of the kernel, such as Linux Kernel and LiteOS, and features, such as Hardware Driver Foundation \(HDF\), running in the kernel mode.
+
+The user mode layer includes other parts except the OpenHarmony kernel layer. It consists of the system service layer, framework layer, and application layer from the bottom to the top.
+
+The user mode layer of OpenHarmony is loosely coupled with the third-party chip platform and is easy to port. The kernel and HDF at the kernel mode layer are closely coupled with the third-party chip platform and are difficult to port. This document focus on the porting of the kernel mode layer. In addition, it describes only the quick porting of the Linux kernel. It does not include the porting of LiteOS.
+
+### Composition of the Kernel Mode Layer
+
+The OpenHarmony kernel mode layer can be further divided as follows:
+
+OpenHarmony kernel mode layer = OpenHarmony Linux kernel + OpenHarmony kernel-mode features \(mandatory features, such as HDF, and optional features, such as HMDFS\)
+
+OpenHarmony Linux kernel = Standard LTS Linux kernel + Third-party SoC platform code + OpenHarmony basic kernel-mode code \(most basic code required for running of the OpenHarmony user mode layer\)
+
+Therefore, the OpenHarmony kernel mode layer includes the following:
+
+- Standard LTS Linux kernel
+- Third-party SoC platform code
+- OpenHarmony basic kernel-mode code
+- OpenHarmony kernel-mode features, such as HDF
+
+
+
+The standard LTS Linux kernel and third-party SoC chip platform code constitute the basis of a third-party Linux kernel. The OpenHarmony kernel mode layer can be composed of either of the following:
+
+- OpenHarmony kernel mode layer = Third-party Linux kernel + OpenHarmony basic kernel-mode code + OpenHarmony kernel-mode features \(such as HDF and HMDFS\)
+
+ In this case, the OpenHarmony kernel mode layer consists of the third-party Linux kernel and OpenHarmony basic code and features for the kernel mode.
+
+
+- OpenHarmony kernel mode layer = OpenHarmony Linux kernel + OpenHarmony kernel-mode features \(such as HDF and HMDFS\)
+
+ In this case, the OpenHarmony kernel mode layer consists of OpenHarmony kernel and features. However, the OpenHarmony kernel supports few third-party chip platforms.
+
+
+In the following, we elaborate how to port OpenHarmony that uses with the third-party Linux kernel.
+
+### Overall Porting Process
+
+The porting process is as follows:
+
+1. Prepare the build environment, including copying the existing kernel code of the third-party chip platform to the OpenHarmony build environment.
+2. Port the OpenHarmony basic kernel-mode code.
+3. Port OpenHarmony mandatory kernel-mode features \(such as HDF\).
+
+## Procedure
+
+The following uses Raspberry Pi 3b \(BCM2837\) as an example to describe how to port OpenHarmony to Raspberry Pi.
+
+### Setting Up the Environment
+
+1. Copy the third-party kernel code to the OpenHarmony build environment.
+
+ Build the standard Hi3516D V300 kernel, clone the Raspberry Pi kernel source code, and copy it to the manifest output directory.
+
+ ```
+ export PROJ_ROOT=[OpenHarmony manifest]
+ git clone https://gitee.com/xfan1024/oh-rpi3b-kernel.git
+ cp -r oh-rpi3b-kernel $PROJ_ROOT/out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b
+ ```
+
+2. Configure the Raspberry Pi kernel build environment.
+
+ ```
+ # Go to the Raspberry Pi kernel directory.
+ cd out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b
+
+ # Configure the build environment, and use clang provided by the project to build the Raspberry Pi kernel source code.
+ export PATH=$PROJ_ROOT/prebuilts/clang/ohos/linux-x86_64/llvm/bin:$PROJ_ROOT/prebuilts/gcc/linux-x86/arm/gcc-linaro-7.5.0-arm-linux-gnueabi/bin/:$PATH
+ export MAKE_OPTIONS="ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CC=clang HOSTCC=clang"
+ export PRODUCT_PATH=vendor/hisilicon/Hi3516DV300
+ ```
+
+3. Comment out the flags that cannot be recognized by **clang**.
+
+ In the **PROJ\_ROOT/out/KERNEL\_OBJ/kernel/src\_tmp/linux-rpi3b/arch/arm/Makefile** file, comment out the following line:
+
+ ```
+ KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
+ ```
+
+
+### Porting Basic Kernel-Mode Code
+
+Currently, the basic kernel-mode code of OpenHarmony is related to the log service. The lightweight kernel log service code includes the following:
+
+```
+drivers/staging/hilog
+drivers/staging/hievent
+```
+
+Copy the preceding code from the **kernel/linux/linux-4.19/drivers/staging** directory of OpenHarmony to **out/KERNEL\_OBJ/kernel/src\_tmp/linux-rpi3b/drivers/staging**.
+
+Add the following code to the third-party kernel file **Kconfig** in the **drivers/staging** directory:
+
+```
+source "drivers/staging/hilog/Kconfig"
+source "drivers/staging/hievent/Kconfig"
+```
+
+Enable the CONFIG macros **CONFIG\_HILOG** and **CONFIG\_HIEVENT** in the kernel **config** section.
+
+For details about how to use the logs, see [Hilog\_lite](https://gitee.com/openharmony/hiviewdfx_hilog_lite/blob/master/README.md).
+
+### Porting the HDF Feature
+
+1. Install HDF patches.
+
+ Run the shell script to apply HDF patches.
+
+ 1. Set the three variables in the **patch\_hdf.sh** script.
+ 2. Obtain the **patch\_hdf.sh** script.
+ 3. Run the **patch\_hdf.sh** script to pass the three variables in sequence.
+
+ Run the following command:
+
+ ```
+ ./patch_hdf.sh [Project root directory path] [Kernel directory path] [HDF patch file]
+ ```
+
+ The following uses Raspberry Pi 3b as an example:
+
+ ```
+ # Go to the Raspberry Pi kernel directory.
+ PROJ_ROOT/drivers/adapter/khdf/linux/patch_hdf.sh \
+ PROJ_ROOT # Specify the path of the project root directory.\
+ PROJ_ROOT/out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b # Specify the kernel directory for applying the patch.\
+ PROJ_ROOT/kernel/linux/patches/linux-4.19/hi3516dv300_patch/hdf.patch # HDF patch file.
+ ```
+
+2. Configure the **config** file.
+
+ Configure basic HDF settings. If other functions are required, enable the corresponding driver switch by using **menuconfig**.
+
+ After HDF patches are installed, the HDF function is disabled by default. To enable the HDF function, perform the following settings:
+
+ ```
+ CONFIG_DRIVERS_HDF=y
+ CONFIG_HDF_SUPPORT_LEVEL=2
+ CONFIG_DRIVERS_HDF_PLATFORM=y
+ CONFIG_DRIVERS_HDF_PLATFORM_MIPI_DSI=y
+ CONFIG_DRIVERS_HDF_PLATFORM_GPIO=y
+ CONFIG_DRIVERS_HDF_PLATFORM_I2C=y
+ CONFIG_DRIVERS_HDF_PLATFORM_UART=y
+ CONFIG_DRIVERS_HDF_TEST=y
+ ```
+
+ Alternatively, run the following command to enable the HDF configuration on the **menuconfig** page:
+
+ ```
+ # Generate the .config file.
+ make ${MAKE_OPTIONS} rpi3b_oh_defconfig
+
+ # Modify the HDF kernel configuration.
+ make ${MAKE_OPTIONS} menuconfig
+ # [*] Device Drivers
+ # [*] HDF driver framework support --->
+ ```
+
+ The configuration \(in **Device Drivers** \> **HDF driver framework support**\) is as follows:
+
+ 
+
+
+### Building the Image
+
+```
+# Run the following command:
+make ${MAKE_OPTIONS} -j33 zImage
+```
+
+### \(Optional\) Building and Running HDF Test Cases
+
+**Overview**
+
+The HDF test cases are used to verify basic functions of the HDF framework and peripherals. This document describes the HDF kernel-mode test cases.
+
+**Prerequisites**
+
+- In **menuconfig**, **CONFIG\_DRIVERS\_HDF\_TEST** is set to **y**.
+- The standard Hi3516D V300 kernel is built completely.
+
+**Test Case Build and Test Method**
+
+Use the [hdc\_std](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md) tool to push the test case execution file to the device and execute the test cases. The procedure is as follows:
+
+1. Build the HDF test cases.
+2. Use the **hdc\_std** tool to push the test case execution file to the device.
+3. Go to the **data/test** directory of the device and execute the test file.
+
+The procedure is as follows:
+
+1. Build the HDF test cases.
+
+ Run the following command:
+
+ ```
+ ./build.sh --product-name Hi3516DV300 --build-target hdf_test
+ ```
+
+ Wait until the build is complete.
+
+2. Copy the test files to the target device \(Raspberry Pi in this example\).
+
+ Method 1: Use the [hdc\_std](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md) tool.
+
+ 1. Create the **data/test** directory in Raspberry Pi.
+
+ ```
+ mkdir -p data/test
+ ```
+
+ 2. Push the dependencies and test cases to Raspberry Pi.
+
+ ```
+ hdc file send XXX\out\ohos-arm-release\hdf\hdf\libhdf_test_common.z.so /system/lib
+ hdc file send XXX\out\ohos-arm-release\tests\unittest\hdf\config\hdf_adapter_uhdf_test_config /data/test
+ hdc file send XXX\out\ohos-arm-release\tests\unittest\hdf\devmgr\DevMgrTest /data/test
+ hdc file send XXX\out\ohos-arm-release\tests\unittest\hdf\osal\OsalTest /data/test
+ hdc file send XXX\out\ohos-arm-release\tests\unittest\hdf\sbuf\SbufTest /data/test
+ ```
+
+ Method 2: Copy the test files to Raspberry Pi using its memory card.
+
+ 1. Remove the serial port and USB cable of Raspberry Pi from the PC, and remove its memory card. The **zImage** file in the memory card will be replaced. Back it up in advance.
+ 2. Insert the memory card into the port of the PC used for porting, download the **zImage** file and the **test/** folder to the PC, and then copy them to the root directory of the memory card.
+ 3. Insert the memory card into Raspberry Pi.
+
+ ```
+ # Enable the Raspberry Pi file system to read the root directory of the memory card.
+ mount -t vfat /dev/block/mmcblk0p1 /boot
+ cd /boot/[Test file directory]
+ # Enable system files to be modified.
+ mount -o remount,rw /
+ # Install the test library.
+ mv libhdf_test_common.z.so /system/lib
+ mkdir /data/test
+ mv * /data/test
+ ```
+
+3. Perform the test.
+ 1. Go to the **data/test** directory.
+
+ ```
+ cd /data/test
+ ```
+
+ 2. Assign the execute permission on the test files.
+
+ ```
+ chmod 777 hdf_adapter_uhdf_test_config DevMgrTest OsalTest SbufTest
+ ```
+
+ 3. Start the test.
+
+ ```
+ ./hdf_adapter_uhdf_test_config
+ ./DevMgrTest
+ ./OsalTest
+ ./SbufTest
+ ```
+
+ 4. If **PASSED** is displayed for all test items, HDF is functioning.
+
+ Example: DevMgrTest case
+
+ ```
+ ./DevMgrTest
+ Running main() from gmock_main.cc
+ [==========] Running 1 test from 1 test case.
+ [----------] Global test environment set-up.
+ [----------] 1 test from DevMgrTest
+ [ RUN ] DevMgrTest.DriverLoaderTest_001
+ [ OK ] DevMgrTest.DriverLoaderTest_001 (0 ms)
+ [----------] 1 test from DevMgrTest (0 ms total)
+ [----------] Global test environment tear-down
+ Gtest xml output finished
+ [==========] 1 test from 1 test case ran. (0 ms total)
+ [ PASSED ] 1 test.
+ ```
+
+
+
diff --git a/en/device-dev/quick-start/figure/checking-the-installation-result.png b/en/device-dev/quick-start/figure/checking-the-installation-result.png
deleted file mode 100644
index 90e51536da16b151e112aa3698cd339044afe3ea..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/checking-the-installation-result.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used-18.png b/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used-18.png
deleted file mode 100644
index cfa0ceb21f5a11d459b93721f512309c9d6da2ac..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used-18.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used.png b/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used.png
deleted file mode 100644
index cfa0ceb21f5a11d459b93721f512309c9d6da2ac..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port-19.png b/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port-19.png
deleted file mode 100644
index 0c1f60638087d0fe56127f2f842244355afad85f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port-19.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port.png b/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port.png
deleted file mode 100644
index 0c1f60638087d0fe56127f2f842244355afad85f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/failed-to-open-the-serial-port-17.png b/en/device-dev/quick-start/figure/failed-to-open-the-serial-port-17.png
deleted file mode 100644
index 25308b9cab52a166955e70ada35c3191d90dd64c..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/failed-to-open-the-serial-port-17.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/hi3516-upload-options.png b/en/device-dev/quick-start/figure/hi3516-upload-options.png
deleted file mode 100644
index 9c5ca0c7b10d63470e689a618b6f29efcdcb1852..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/hi3516-upload-options.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/hpm-version.png b/en/device-dev/quick-start/figure/hpm-version.png
deleted file mode 100644
index 61aec8202ac830a3598ef2c8a413be30c5a742f0..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/hpm-version.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/install.png b/en/device-dev/quick-start/figure/install.png
deleted file mode 100644
index 261e75499a68f8e80a6a002dc0f57bf523c3c428..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/install.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/installation-complete.png b/en/device-dev/quick-start/figure/installation-complete.png
deleted file mode 100644
index 56b0f47cb9948e49e4aef36c6e59bd631bee5b12..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/installation-complete.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/installing-python.png b/en/device-dev/quick-start/figure/installing-python.png
deleted file mode 100644
index 624db2266d404907bbf9b7038ef2a092c1837476..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/installing-python.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/installing-the-deveco-device-tool.png b/en/device-dev/quick-start/figure/installing-the-deveco-device-tool.png
deleted file mode 100644
index bc895e3b216c8029d72bacb260db74d2378e3853..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/installing-the-deveco-device-tool.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/options.png b/en/device-dev/quick-start/figure/options.png
deleted file mode 100644
index ee96ae5fee13abd79cfcea30b18539e4824a7716..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/options.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/restarting-burning-20.png b/en/device-dev/quick-start/figure/restarting-burning-20.png
deleted file mode 100644
index 208a4fbace342514f59f0000c4d50f5dc9321f0f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/restarting-burning-20.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/restarting-burning.png b/en/device-dev/quick-start/figure/restarting-burning.png
deleted file mode 100644
index 208a4fbace342514f59f0000c4d50f5dc9321f0f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/restarting-burning.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/serial-port-connection-15.png b/en/device-dev/quick-start/figure/serial-port-connection-15.png
deleted file mode 100644
index 8eb26425f53028a08eb40e3037ecd302f3082270..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/serial-port-connection-15.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/serial-port-connection-5.png b/en/device-dev/quick-start/figure/serial-port-connection-5.png
deleted file mode 100644
index 063a5ff561d4a29f48744c3133724eb6b45e8a47..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/serial-port-connection-5.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/setting-11.png b/en/device-dev/quick-start/figure/setting-11.png
deleted file mode 100644
index 55de1b4d9a39386800658bed77fcbec9a51cda12..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/setting-11.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/setting.png b/en/device-dev/quick-start/figure/setting.png
deleted file mode 100644
index d5c8aa48799deb909d7cd047a984cc52db2dd01a..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/setting.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/settings-2.png b/en/device-dev/quick-start/figure/settings-2.png
deleted file mode 100644
index 1e7dd2cdb515e871a1c5d34b3332b097bc02351b..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/settings-2.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/setup-was-successful.png b/en/device-dev/quick-start/figure/setup-was-successful.png
deleted file mode 100644
index 773abcd91a0c0ee1d3f5f87218216fc337d8f62f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/setup-was-successful.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/start.png b/en/device-dev/quick-start/figure/start.png
deleted file mode 100644
index 0aacb08e575da85502302836c390512e55402db3..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/start.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution-16.png b/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution-16.png
deleted file mode 100644
index 6a85551cd30c8c0576c138d86dc66ddf73dccb44..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution-16.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/system-startup-6.png b/en/device-dev/quick-start/figure/system-startup-6.png
deleted file mode 100644
index 105e9a83292ff333cafb813ecd6647dd256a9443..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/system-startup-6.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/upload-options.png b/en/device-dev/quick-start/figure/upload-options.png
deleted file mode 100644
index 913ba69f3215ac779124430b22fab3b6fb6b3993..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/upload-options.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figure/visual-studio-code.png b/en/device-dev/quick-start/figure/visual-studio-code.png
deleted file mode 100644
index 2609aa029260a137c76c299fead396c07b8c8e45..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figure/visual-studio-code.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/11.png b/en/device-dev/quick-start/figures/11.png
new file mode 100644
index 0000000000000000000000000000000000000000..ff9105c313d5755f140920bbfc2399e3ccb5e2f5
Binary files /dev/null and b/en/device-dev/quick-start/figures/11.png differ
diff --git a/en/device-dev/quick-start/figure/deveco-device-tool-logo.png b/en/device-dev/quick-start/figures/2021-01-27_170334.png
similarity index 100%
rename from en/device-dev/quick-start/figure/deveco-device-tool-logo.png
rename to en/device-dev/quick-start/figures/2021-01-27_170334.png
diff --git a/en/device-dev/quick-start/figure/appearance-of-hi3861-wlan-module.png b/en/device-dev/quick-start/figures/appearance-of-hi3861-wlan-module.png
similarity index 100%
rename from en/device-dev/quick-start/figure/appearance-of-hi3861-wlan-module.png
rename to en/device-dev/quick-start/figures/appearance-of-hi3861-wlan-module.png
diff --git a/en/device-dev/quick-start/figure/appearance-of-the-hi3861-mother-board.png b/en/device-dev/quick-start/figures/appearance-of-the-hi3861-mother-board.png
similarity index 100%
rename from en/device-dev/quick-start/figure/appearance-of-the-hi3861-mother-board.png
rename to en/device-dev/quick-start/figures/appearance-of-the-hi3861-mother-board.png
diff --git a/en/device-dev/quick-start/figure/bootloader.png b/en/device-dev/quick-start/figures/bootloader.png
similarity index 100%
rename from en/device-dev/quick-start/figure/bootloader.png
rename to en/device-dev/quick-start/figures/bootloader.png
diff --git a/en/device-dev/quick-start/figure/button.png b/en/device-dev/quick-start/figures/button.png
similarity index 100%
rename from en/device-dev/quick-start/figure/button.png
rename to en/device-dev/quick-start/figures/button.png
diff --git a/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png b/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png
new file mode 100644
index 0000000000000000000000000000000000000000..0a54838f89062fd67328ef76e4a1cf770c6aee13
Binary files /dev/null and b/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png differ
diff --git a/en/device-dev/quick-start/figure/directory-for-storing-the-generated-files.png b/en/device-dev/quick-start/figures/directory-for-storing-the-generated-files.png
similarity index 100%
rename from en/device-dev/quick-start/figure/directory-for-storing-the-generated-files.png
rename to en/device-dev/quick-start/figures/directory-for-storing-the-generated-files.png
diff --git a/en/device-dev/quick-start/figure/download-ecdsa.png b/en/device-dev/quick-start/figures/download-ecdsa.png
similarity index 100%
rename from en/device-dev/quick-start/figure/download-ecdsa.png
rename to en/device-dev/quick-start/figures/download-ecdsa.png
diff --git a/en/device-dev/quick-start/figure/download-six.png b/en/device-dev/quick-start/figures/download-six.png
similarity index 100%
rename from en/device-dev/quick-start/figure/download-six.png
rename to en/device-dev/quick-start/figures/download-six.png
diff --git a/en/device-dev/quick-start/figure/download-the-source-code.png b/en/device-dev/quick-start/figures/download-the-source-code.png
similarity index 100%
rename from en/device-dev/quick-start/figure/download-the-source-code.png
rename to en/device-dev/quick-start/figures/download-the-source-code.png
diff --git a/en/device-dev/quick-start/figure/download-zlib.png b/en/device-dev/quick-start/figures/download-zlib.png
similarity index 100%
rename from en/device-dev/quick-start/figure/download-zlib.png
rename to en/device-dev/quick-start/figures/download-zlib.png
diff --git a/en/device-dev/quick-start/figure/start-burning.png b/en/device-dev/quick-start/figures/en-us_image_0000001215342695.png
similarity index 100%
rename from en/device-dev/quick-start/figure/start-burning.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001215342695.png
diff --git a/en/device-dev/quick-start/figure/erase-u-boot.png b/en/device-dev/quick-start/figures/erase-u-boot.png
similarity index 100%
rename from en/device-dev/quick-start/figure/erase-u-boot.png
rename to en/device-dev/quick-start/figures/erase-u-boot.png
diff --git a/en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection-21.png b/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-0.png
similarity index 100%
rename from en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection-21.png
rename to en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-0.png
diff --git a/en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection.png b/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
similarity index 100%
rename from en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
rename to en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
diff --git a/en/device-dev/quick-start/figure/failed-to-open-the-serial-port.png b/en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png
similarity index 100%
rename from en/device-dev/quick-start/figure/failed-to-open-the-serial-port.png
rename to en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png
diff --git a/en/device-dev/quick-start/figure/getting-started-for-the-standard-system.png b/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png
similarity index 100%
rename from en/device-dev/quick-start/figure/getting-started-for-the-standard-system.png
rename to en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png
diff --git a/en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network-25.png b/en/device-dev/quick-start/figures/hi3516-allowing-the-visual-studio-code-application-to-access-the-network.png
similarity index 100%
rename from en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network-25.png
rename to en/device-dev/quick-start/figures/hi3516-allowing-the-visual-studio-code-application-to-access-the-network.png
diff --git a/en/device-dev/quick-start/figure/burning-succeeded-4.png b/en/device-dev/quick-start/figures/hi3516-burning-succeeded-net.png
similarity index 100%
rename from en/device-dev/quick-start/figure/burning-succeeded-4.png
rename to en/device-dev/quick-start/figures/hi3516-burning-succeeded-net.png
diff --git a/en/device-dev/quick-start/figure/deveco-device-toollogo.png b/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-logo.png
similarity index 100%
rename from en/device-dev/quick-start/figure/deveco-device-toollogo.png
rename to en/device-dev/quick-start/figures/hi3516-deveco-device-tool-logo.png
diff --git a/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png
new file mode 100644
index 0000000000000000000000000000000000000000..937a17d71744d81d509543594b094939e8a89070
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png differ
diff --git a/en/device-dev/quick-start/figure/firewall-and-network-protection-23.png b/en/device-dev/quick-start/figures/hi3516-firewall-and-network-protection.png
similarity index 100%
rename from en/device-dev/quick-start/figure/firewall-and-network-protection-23.png
rename to en/device-dev/quick-start/figures/hi3516-firewall-and-network-protection.png
diff --git a/en/device-dev/quick-start/figure/hardware-connections-0.png b/en/device-dev/quick-start/figures/hi3516-hardware-connections.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hardware-connections-0.png
rename to en/device-dev/quick-start/figures/hi3516-hardware-connections.png
diff --git a/en/device-dev/quick-start/figure/network-and-firewall-setting-22.png b/en/device-dev/quick-start/figures/hi3516-network-and-firewall-setting.png
similarity index 100%
rename from en/device-dev/quick-start/figure/network-and-firewall-setting-22.png
rename to en/device-dev/quick-start/figures/hi3516-network-and-firewall-setting.png
diff --git a/en/device-dev/quick-start/figure/record-the-serial-port-number-1.png b/en/device-dev/quick-start/figures/hi3516-record-the-serial-port-number.png
similarity index 100%
rename from en/device-dev/quick-start/figure/record-the-serial-port-number-1.png
rename to en/device-dev/quick-start/figures/hi3516-record-the-serial-port-number.png
diff --git a/en/device-dev/quick-start/figure/restart-the-development-board-3.png b/en/device-dev/quick-start/figures/hi3516-restart-the-development-board.png
similarity index 100%
rename from en/device-dev/quick-start/figure/restart-the-development-board-3.png
rename to en/device-dev/quick-start/figures/hi3516-restart-the-development-board.png
diff --git a/en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application-24.png b/en/device-dev/quick-start/figures/hi3516-selecting-the-visual-studio-code-application.png
similarity index 100%
rename from en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application-24.png
rename to en/device-dev/quick-start/figures/hi3516-selecting-the-visual-studio-code-application.png
diff --git a/en/device-dev/quick-start/figure/settings.png b/en/device-dev/quick-start/figures/hi3516-settings.png
similarity index 100%
rename from en/device-dev/quick-start/figure/settings.png
rename to en/device-dev/quick-start/figures/hi3516-settings.png
diff --git a/en/device-dev/quick-start/figures/hi3516-upload-options.png b/en/device-dev/quick-start/figures/hi3516-upload-options.png
new file mode 100644
index 0000000000000000000000000000000000000000..7d9768119778aeee7d0b927879c0da2bcdc4821a
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3516-upload-options.png differ
diff --git a/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png b/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png
new file mode 100644
index 0000000000000000000000000000000000000000..fb2db198cc61ed10136f0e3382deed352300a62b
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png differ
diff --git a/en/device-dev/quick-start/figure/hi3516d-v300-front-view-27.png b/en/device-dev/quick-start/figures/hi3516d-v300-front-view-1.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hi3516d-v300-front-view-27.png
rename to en/device-dev/quick-start/figures/hi3516d-v300-front-view-1.png
diff --git a/en/device-dev/quick-start/figure/hi3516d-v300-front-view.png b/en/device-dev/quick-start/figures/hi3516d-v300-front-view.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hi3516d-v300-front-view.png
rename to en/device-dev/quick-start/figures/hi3516d-v300-front-view.png
diff --git a/en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network.png b/en/device-dev/quick-start/figures/hi3518-allowing-the-visual-studio-code-application-to-access-the-network.png
similarity index 100%
rename from en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network.png
rename to en/device-dev/quick-start/figures/hi3518-allowing-the-visual-studio-code-application-to-access-the-network.png
diff --git a/en/device-dev/quick-start/figure/3518_bootloader.png b/en/device-dev/quick-start/figures/hi3518-bootloader.png
similarity index 100%
rename from en/device-dev/quick-start/figure/3518_bootloader.png
rename to en/device-dev/quick-start/figures/hi3518-bootloader.png
diff --git a/en/device-dev/quick-start/figure/burning-succeeded-14.png b/en/device-dev/quick-start/figures/hi3518-burning-succeeded.png
similarity index 100%
rename from en/device-dev/quick-start/figure/burning-succeeded-14.png
rename to en/device-dev/quick-start/figures/hi3518-burning-succeeded.png
diff --git a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..5b573a4ddfe89fe25cb1b567736823244fdb9e97
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png differ
diff --git a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png
new file mode 100644
index 0000000000000000000000000000000000000000..a7cdfed371fa65d05faec7651d89145ad5a24a96
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png differ
diff --git a/en/device-dev/quick-start/figure/error.png b/en/device-dev/quick-start/figures/hi3518-error-for-not-finding-python.png
similarity index 100%
rename from en/device-dev/quick-start/figure/error.png
rename to en/device-dev/quick-start/figures/hi3518-error-for-not-finding-python.png
diff --git a/en/device-dev/quick-start/figure/firewall-and-network-protection.png b/en/device-dev/quick-start/figures/hi3518-firewall-and-network-protection.png
similarity index 100%
rename from en/device-dev/quick-start/figure/firewall-and-network-protection.png
rename to en/device-dev/quick-start/figures/hi3518-firewall-and-network-protection.png
diff --git a/en/device-dev/quick-start/figure/hardware-connections-8.png b/en/device-dev/quick-start/figures/hi3518-hardware-connections.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hardware-connections-8.png
rename to en/device-dev/quick-start/figures/hi3518-hardware-connections.png
diff --git a/en/device-dev/quick-start/figure/3518_monitor.png b/en/device-dev/quick-start/figures/hi3518-monitor.png
similarity index 100%
rename from en/device-dev/quick-start/figure/3518_monitor.png
rename to en/device-dev/quick-start/figures/hi3518-monitor.png
diff --git a/en/device-dev/quick-start/figure/network-and-firewall-setting.png b/en/device-dev/quick-start/figures/hi3518-network-and-firewall-setting.png
similarity index 100%
rename from en/device-dev/quick-start/figure/network-and-firewall-setting.png
rename to en/device-dev/quick-start/figures/hi3518-network-and-firewall-setting.png
diff --git a/en/device-dev/quick-start/figure/error2.png b/en/device-dev/quick-start/figures/hi3518-reason-no-python-soft-link.png
similarity index 100%
rename from en/device-dev/quick-start/figure/error2.png
rename to en/device-dev/quick-start/figures/hi3518-reason-no-python-soft-link.png
diff --git a/en/device-dev/quick-start/figure/3518_reboot_success.png b/en/device-dev/quick-start/figures/hi3518-reboot-success.png
similarity index 100%
rename from en/device-dev/quick-start/figure/3518_reboot_success.png
rename to en/device-dev/quick-start/figures/hi3518-reboot-success.png
diff --git a/en/device-dev/quick-start/figure/record-the-serial-port-number-10.png b/en/device-dev/quick-start/figures/hi3518-record-the-serial-port-number.png
similarity index 100%
rename from en/device-dev/quick-start/figure/record-the-serial-port-number-10.png
rename to en/device-dev/quick-start/figures/hi3518-record-the-serial-port-number.png
diff --git a/en/device-dev/quick-start/figure/3518_reset_success.png b/en/device-dev/quick-start/figures/hi3518-reset-success.png
similarity index 100%
rename from en/device-dev/quick-start/figure/3518_reset_success.png
rename to en/device-dev/quick-start/figures/hi3518-reset-success.png
diff --git a/en/device-dev/quick-start/figure/restart-the-development-board-12.png b/en/device-dev/quick-start/figures/hi3518-restart-the-development-board.png
similarity index 100%
rename from en/device-dev/quick-start/figure/restart-the-development-board-12.png
rename to en/device-dev/quick-start/figures/hi3518-restart-the-development-board.png
diff --git a/en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application.png b/en/device-dev/quick-start/figures/hi3518-selecting-the-visual-studio-code-application.png
similarity index 100%
rename from en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application.png
rename to en/device-dev/quick-start/figures/hi3518-selecting-the-visual-studio-code-application.png
diff --git a/en/device-dev/quick-start/figure/settings-9.png b/en/device-dev/quick-start/figures/hi3518-settings.png
similarity index 100%
rename from en/device-dev/quick-start/figure/settings-9.png
rename to en/device-dev/quick-start/figures/hi3518-settings.png
diff --git a/en/device-dev/quick-start/figure/solution-26.png b/en/device-dev/quick-start/figures/hi3518-solution-set-python-soft-link.png
similarity index 100%
rename from en/device-dev/quick-start/figure/solution-26.png
rename to en/device-dev/quick-start/figures/hi3518-solution-set-python-soft-link.png
diff --git a/en/device-dev/quick-start/figure/upload-13.png b/en/device-dev/quick-start/figures/hi3518-upload.png
similarity index 100%
rename from en/device-dev/quick-start/figure/upload-13.png
rename to en/device-dev/quick-start/figures/hi3518-upload.png
diff --git a/en/device-dev/quick-start/figure/hi3518e-v300-front-view.png b/en/device-dev/quick-start/figures/hi3518e-v300-front-view.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hi3518e-v300-front-view.png
rename to en/device-dev/quick-start/figures/hi3518e-v300-front-view.png
diff --git a/en/device-dev/quick-start/figure/hi3518e-v300-rear-view.png b/en/device-dev/quick-start/figures/hi3518e-v300-rear-view.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hi3518e-v300-rear-view.png
rename to en/device-dev/quick-start/figures/hi3518e-v300-rear-view.png
diff --git a/en/device-dev/quick-start/figure/burning-succeeded.png b/en/device-dev/quick-start/figures/hi3861-burning-succeeded.png
similarity index 100%
rename from en/device-dev/quick-start/figure/burning-succeeded.png
rename to en/device-dev/quick-start/figures/hi3861-burning-succeeded.png
diff --git a/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png
new file mode 100644
index 0000000000000000000000000000000000000000..512ee4ff2e053da12259a2f9d3163df75cb41a52
Binary files /dev/null and b/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png differ
diff --git a/en/device-dev/quick-start/figure/hi3861-functions.png b/en/device-dev/quick-start/figures/hi3861-functions.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hi3861-functions.png
rename to en/device-dev/quick-start/figures/hi3861-functions.png
diff --git a/en/device-dev/quick-start/figure/hardware-connections.png b/en/device-dev/quick-start/figures/hi3861-hardware-connections.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hardware-connections.png
rename to en/device-dev/quick-start/figures/hi3861-hardware-connections.png
diff --git a/en/device-dev/quick-start/figure/record-the-serial-port-number.png b/en/device-dev/quick-start/figures/hi3861-record-the-serial-port-number.png
similarity index 100%
rename from en/device-dev/quick-start/figure/record-the-serial-port-number.png
rename to en/device-dev/quick-start/figures/hi3861-record-the-serial-port-number.png
diff --git a/en/device-dev/quick-start/figure/restart-the-development-board.png b/en/device-dev/quick-start/figures/hi3861-restart-the-development-board.png
similarity index 100%
rename from en/device-dev/quick-start/figure/restart-the-development-board.png
rename to en/device-dev/quick-start/figures/hi3861-restart-the-development-board.png
diff --git a/en/device-dev/quick-start/figure/upload.png b/en/device-dev/quick-start/figures/hi3861-upload.png
similarity index 100%
rename from en/device-dev/quick-start/figure/upload.png
rename to en/device-dev/quick-start/figures/hi3861-upload.png
diff --git a/en/device-dev/quick-start/figure/hisilicon-arm-linux.png b/en/device-dev/quick-start/figures/hisilicon-arm-linux.png
similarity index 100%
rename from en/device-dev/quick-start/figure/hisilicon-arm-linux.png
rename to en/device-dev/quick-start/figures/hisilicon-arm-linux.png
diff --git a/en/device-dev/quick-start/figure/ip-address-information.png b/en/device-dev/quick-start/figures/ip-address-information-3.png
similarity index 100%
rename from en/device-dev/quick-start/figure/ip-address-information.png
rename to en/device-dev/quick-start/figures/ip-address-information-3.png
diff --git a/en/device-dev/quick-start/figures/ip-address-information.png b/en/device-dev/quick-start/figures/ip-address-information.png
new file mode 100644
index 0000000000000000000000000000000000000000..72dd05e3ae1eb91156df98cb1915b6264b3bbe5a
Binary files /dev/null and b/en/device-dev/quick-start/figures/ip-address-information.png differ
diff --git a/en/device-dev/quick-start/figure/login-serial-port.png b/en/device-dev/quick-start/figures/login-serial-port.png
similarity index 100%
rename from en/device-dev/quick-start/figure/login-serial-port.png
rename to en/device-dev/quick-start/figures/login-serial-port.png
diff --git a/en/device-dev/quick-start/figure/monitor.png b/en/device-dev/quick-start/figures/monitor.png
similarity index 100%
rename from en/device-dev/quick-start/figure/monitor.png
rename to en/device-dev/quick-start/figures/monitor.png
diff --git a/en/device-dev/quick-start/figure/open-the-serial-port-tool.png b/en/device-dev/quick-start/figures/open-the-serial-port-tool.png
similarity index 100%
rename from en/device-dev/quick-start/figure/open-the-serial-port-tool.png
rename to en/device-dev/quick-start/figures/open-the-serial-port-tool.png
diff --git a/en/device-dev/quick-start/figure/opening-the-deveco-serial-port.png b/en/device-dev/quick-start/figures/opening-the-deveco-serial-port.png
similarity index 100%
rename from en/device-dev/quick-start/figure/opening-the-deveco-serial-port.png
rename to en/device-dev/quick-start/figures/opening-the-deveco-serial-port.png
diff --git a/en/device-dev/quick-start/figures/options.png b/en/device-dev/quick-start/figures/options.png
new file mode 100644
index 0000000000000000000000000000000000000000..0bf756d8a9fea4865c8b65b7dadc4463e2346ab7
Binary files /dev/null and b/en/device-dev/quick-start/figures/options.png differ
diff --git a/en/device-dev/quick-start/figure/press-any-key-to-enter-the-system.gif b/en/device-dev/quick-start/figures/press-any-key-to-enter-the-system.gif
similarity index 100%
rename from en/device-dev/quick-start/figure/press-any-key-to-enter-the-system.gif
rename to en/device-dev/quick-start/figures/press-any-key-to-enter-the-system.gif
diff --git a/en/device-dev/quick-start/figure/reason-for-not-finding-python.png b/en/device-dev/quick-start/figures/reason-for-not-finding-python.png
similarity index 100%
rename from en/device-dev/quick-start/figure/reason-for-not-finding-python.png
rename to en/device-dev/quick-start/figures/reason-for-not-finding-python.png
diff --git a/en/device-dev/quick-start/figure/reason-2.png b/en/device-dev/quick-start/figures/reason-no-python-soft-link.png
similarity index 100%
rename from en/device-dev/quick-start/figure/reason-2.png
rename to en/device-dev/quick-start/figures/reason-no-python-soft-link.png
diff --git a/en/device-dev/quick-start/figure/reboot_success.png b/en/device-dev/quick-start/figures/reboot_success.png
similarity index 100%
rename from en/device-dev/quick-start/figure/reboot_success.png
rename to en/device-dev/quick-start/figures/reboot_success.png
diff --git a/en/device-dev/quick-start/figure/reset_success.png b/en/device-dev/quick-start/figures/reset_success.png
similarity index 100%
rename from en/device-dev/quick-start/figure/reset_success.png
rename to en/device-dev/quick-start/figures/reset_success.png
diff --git a/en/device-dev/quick-start/figure/running-commands-on-the-terminal-panel.png b/en/device-dev/quick-start/figures/running-commands-on-the-terminal-panel.png
similarity index 100%
rename from en/device-dev/quick-start/figure/running-commands-on-the-terminal-panel.png
rename to en/device-dev/quick-start/figures/running-commands-on-the-terminal-panel.png
diff --git a/en/device-dev/quick-start/figure/save-the-parameter-settings.png b/en/device-dev/quick-start/figures/save-the-parameter-settings.png
similarity index 100%
rename from en/device-dev/quick-start/figure/save-the-parameter-settings.png
rename to en/device-dev/quick-start/figures/save-the-parameter-settings.png
diff --git a/en/device-dev/quick-start/figure/selecting-the-target-build-version.png b/en/device-dev/quick-start/figures/selecting-the-target-build-version.png
similarity index 100%
rename from en/device-dev/quick-start/figure/selecting-the-target-build-version.png
rename to en/device-dev/quick-start/figures/selecting-the-target-build-version.png
diff --git a/en/device-dev/quick-start/figure/serial-port-connection.png b/en/device-dev/quick-start/figures/serial-port-connection.png
old mode 100755
new mode 100644
similarity index 100%
rename from en/device-dev/quick-start/figure/serial-port-connection.png
rename to en/device-dev/quick-start/figures/serial-port-connection.png
diff --git a/en/device-dev/quick-start/figure/serial-port-displayed-after-the-u-boot-is-burnt.png b/en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png
similarity index 100%
rename from en/device-dev/quick-start/figure/serial-port-displayed-after-the-u-boot-is-burnt.png
rename to en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png
diff --git a/en/device-dev/quick-start/figure/serial-port-entry.png b/en/device-dev/quick-start/figures/serial-port-entry.png
similarity index 100%
rename from en/device-dev/quick-start/figure/serial-port-entry.png
rename to en/device-dev/quick-start/figures/serial-port-entry.png
diff --git a/en/device-dev/quick-start/figures/setenv-bootargs.png b/en/device-dev/quick-start/figures/setenv-bootargs.png
new file mode 100644
index 0000000000000000000000000000000000000000..802cce4e760102043f177cb2fa71e8bd16539ba1
Binary files /dev/null and b/en/device-dev/quick-start/figures/setenv-bootargs.png differ
diff --git a/en/device-dev/quick-start/figures/snap28.png b/en/device-dev/quick-start/figures/snap28.png
new file mode 100644
index 0000000000000000000000000000000000000000..2dcc6878e24dc6aa415fcbea24a8c4878aad5242
Binary files /dev/null and b/en/device-dev/quick-start/figures/snap28.png differ
diff --git a/en/device-dev/quick-start/figure/installing-visual-studio-code.png b/en/device-dev/quick-start/figures/snap33.png
similarity index 100%
rename from en/device-dev/quick-start/figure/installing-visual-studio-code.png
rename to en/device-dev/quick-start/figures/snap33.png
diff --git a/en/device-dev/quick-start/figures/snap34.png b/en/device-dev/quick-start/figures/snap34.png
new file mode 100644
index 0000000000000000000000000000000000000000..a0c66f66fa6e77e545cc6ac3db2d6cf10f646387
Binary files /dev/null and b/en/device-dev/quick-start/figures/snap34.png differ
diff --git a/en/device-dev/quick-start/figures/snap8.png b/en/device-dev/quick-start/figures/snap8.png
new file mode 100644
index 0000000000000000000000000000000000000000..157f5e2d0f5b33f998560f7e85efb49d6786786c
Binary files /dev/null and b/en/device-dev/quick-start/figures/snap8.png differ
diff --git a/en/device-dev/quick-start/figure/solution-7.png b/en/device-dev/quick-start/figures/solution-add-soft-link.png
similarity index 100%
rename from en/device-dev/quick-start/figure/solution-7.png
rename to en/device-dev/quick-start/figures/solution-add-soft-link.png
diff --git a/en/device-dev/quick-start/figure/solution.png b/en/device-dev/quick-start/figures/solution.png
similarity index 100%
rename from en/device-dev/quick-start/figure/solution.png
rename to en/device-dev/quick-start/figures/solution.png
diff --git a/en/device-dev/quick-start/figure/start-the-system.png b/en/device-dev/quick-start/figures/start-the-system.png
similarity index 100%
rename from en/device-dev/quick-start/figure/start-the-system.png
rename to en/device-dev/quick-start/figures/start-the-system.png
diff --git a/en/device-dev/quick-start/figure/starting-the-ide-terminal-tool.png b/en/device-dev/quick-start/figures/starting-the-ide-terminal-tool.png
similarity index 100%
rename from en/device-dev/quick-start/figure/starting-the-ide-terminal-tool.png
rename to en/device-dev/quick-start/figures/starting-the-ide-terminal-tool.png
diff --git a/en/device-dev/quick-start/figure/successful-building.png b/en/device-dev/quick-start/figures/successful-building.png
similarity index 100%
rename from en/device-dev/quick-start/figure/successful-building.png
rename to en/device-dev/quick-start/figures/successful-building.png
diff --git a/en/device-dev/quick-start/figure/successful-installation-(scons-version-requirement-3-0-4-or-later).png b/en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png
similarity index 100%
rename from en/device-dev/quick-start/figure/successful-installation-(scons-version-requirement-3-0-4-or-later).png
rename to en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png
diff --git a/en/device-dev/quick-start/figure/successful-networking-of-the-wlan-module.png b/en/device-dev/quick-start/figures/successful-networking-of-the-wlan-module.png
similarity index 100%
rename from en/device-dev/quick-start/figure/successful-networking-of-the-wlan-module.png
rename to en/device-dev/quick-start/figures/successful-networking-of-the-wlan-module.png
diff --git a/en/device-dev/quick-start/figure/successful-resetting-of-the-wlan-module.png b/en/device-dev/quick-start/figures/successful-resetting-of-the-wlan-module.png
similarity index 100%
rename from en/device-dev/quick-start/figure/successful-resetting-of-the-wlan-module.png
rename to en/device-dev/quick-start/figures/successful-resetting-of-the-wlan-module.png
diff --git a/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution.png b/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png
similarity index 100%
rename from en/device-dev/quick-start/figure/successful-system-startup-and-program-execution.png
rename to en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png
diff --git a/en/device-dev/quick-start/figure/symptom.png b/en/device-dev/quick-start/figures/symptom-for-not-finding-python.png
similarity index 100%
rename from en/device-dev/quick-start/figure/symptom.png
rename to en/device-dev/quick-start/figures/symptom-for-not-finding-python.png
diff --git a/en/device-dev/quick-start/figure/system-startup.png b/en/device-dev/quick-start/figures/system-startup.png
old mode 100755
new mode 100644
similarity index 100%
rename from en/device-dev/quick-start/figure/system-startup.png
rename to en/device-dev/quick-start/figures/system-startup.png
diff --git a/en/device-dev/quick-start/figures/terminal-list.png b/en/device-dev/quick-start/figures/terminal-list.png
new file mode 100644
index 0000000000000000000000000000000000000000..a680547b305cccb4d8ea6cae3cbf2d046b841ff8
Binary files /dev/null and b/en/device-dev/quick-start/figures/terminal-list.png differ
diff --git a/en/device-dev/quick-start/figure/terminal-panel.png b/en/device-dev/quick-start/figures/terminal-panel.png
similarity index 100%
rename from en/device-dev/quick-start/figure/terminal-panel.png
rename to en/device-dev/quick-start/figures/terminal-panel.png
diff --git a/en/device-dev/quick-start/figure/u-boot-erased-successfully.png b/en/device-dev/quick-start/figures/u-boot-erased-successfully.png
similarity index 100%
rename from en/device-dev/quick-start/figure/u-boot-erased-successfully.png
rename to en/device-dev/quick-start/figures/u-boot-erased-successfully.png
diff --git a/en/device-dev/quick-start/figure/upload-options-28.png b/en/device-dev/quick-start/figures/upload-options-2.png
similarity index 100%
rename from en/device-dev/quick-start/figure/upload-options-28.png
rename to en/device-dev/quick-start/figures/upload-options-2.png
diff --git a/en/device-dev/quick-start/figures/upload-options.png b/en/device-dev/quick-start/figures/upload-options.png
new file mode 100644
index 0000000000000000000000000000000000000000..0b0d0cf88b9a78e6beea45e74b7633fa8c3ce523
Binary files /dev/null and b/en/device-dev/quick-start/figures/upload-options.png differ
diff --git a/en/device-dev/quick-start/figure/wadrecvcb-function.png b/en/device-dev/quick-start/figures/wadrecvcb-function.png
similarity index 100%
rename from en/device-dev/quick-start/figure/wadrecvcb-function.png
rename to en/device-dev/quick-start/figures/wadrecvcb-function.png
diff --git a/en/device-dev/quick-start/oem_minitinier_des_3516.md b/en/device-dev/quick-start/oem_minitinier_des_3516.md
index d4c8484af9eafe3482227a92b444a3b402d72eac..96a485efd9dc9bf3ff70d3db05b34b76530a8d0c 100644
--- a/en/device-dev/quick-start/oem_minitinier_des_3516.md
+++ b/en/device-dev/quick-start/oem_minitinier_des_3516.md
@@ -8,7 +8,7 @@
Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.
**Figure 1** Hi3516D V300 front view
-
+
## Development Board Specifications
diff --git a/en/device-dev/quick-start/oem_minitinier_des_3518.md b/en/device-dev/quick-start/oem_minitinier_des_3518.md
index a4dd13f06438dbf82bfd5e00895dd9a0ebdac9bb..7731c1898448f7b6b3c6dfd149e3365ab68cc6cb 100644
--- a/en/device-dev/quick-start/oem_minitinier_des_3518.md
+++ b/en/device-dev/quick-start/oem_minitinier_des_3518.md
@@ -8,10 +8,10 @@
Hi3518E V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and the advanced low-power process and architecture design, leading the industry in terms of low bit rate, high image quality, and low power consumption.
**Figure 1** Hi3518E V300 front view
-
+
**Figure 2** Hi3518E V300 rear view
-
+
## Development Board Specifications
diff --git a/en/device-dev/quick-start/oem_minitinier_des_3861.md b/en/device-dev/quick-start/oem_minitinier_des_3861.md
index 25055ec06c7acf5f821af4797ce582b802b4e028..bc30d3567ca085777cd7fb6f92a54c73e9413771 100644
--- a/en/device-dev/quick-start/oem_minitinier_des_3861.md
+++ b/en/device-dev/quick-start/oem_minitinier_des_3861.md
@@ -10,12 +10,12 @@
The Hi3861 WLAN module is a development board with 2 x 5 cm form factor. It contains a 2.4 GHz WLAN SoC that highly integrates the IEEE 802.11b/g/n baseband and radio frequency \(RF\) circuit. This module provides open and easy-to-use development and debugging environments for running OpenHarmony.
**Figure 1** Appearance of Hi3861 WLAN module
-
+
The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board.
**Figure 2** Appearance of the Hi3861 mother board
-
+
- The RF circuit includes modules such as the power amplifier \(PA\), low noise amplifier \(LNA\), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer.
- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing \(OFDM\) technology and is backward compatible with the direct sequence spread spectrum \(DSSS\) and complementary code keying \(CCK\) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol.
@@ -23,7 +23,7 @@ The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expan
- The Hi3861 chip applies to Internet of Things \(IoT\) devices such as smart home appliances.
**Figure 3** Hi3861 functions
- 
+ 
## Resources and Constraints
diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup-linux.md b/en/device-dev/quick-start/quickstart-lite-env-setup-linux.md
index 7d4a8f3cca9c9e80c4be95e1217ed70606b779d3..0269526b75c0d8ea2fd76c036e3a83ecdf3fd542 100644
--- a/en/device-dev/quick-start/quickstart-lite-env-setup-linux.md
+++ b/en/device-dev/quick-start/quickstart-lite-env-setup-linux.md
@@ -92,7 +92,7 @@ You need to acquire [source code](../get-code/sourcecode-acquire.md), download
Run the following command to install the libraries and tools required for compilation:
```
-sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg-config flex bison perl bc openssl libssl-dev libelf-dev libc6-dev-amd64 binutils binutils-dev libdwarf-dev u-boot-tools mtd-utils gcc-arm-linux-gnueabi
+sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg-config flex bison perl bc openssl libssl-dev libelf-dev libc6-dev-amd64 binutils binutils-dev libdwarf-dev u-boot-tools mtd-utils gcc-arm-linux-gnueabi cpio device-tree-compiler
```
## Installing Python3
@@ -108,11 +108,11 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg
1. Check the Ubuntu version.
- ```
- cat /etc/issue
- ```
+ ```
+ cat /etc/issue
+ ```
- 1. Install Python based on the Ubuntu version.
+ 2. Install Python based on the Ubuntu version.
- If the Ubuntu version is 18 or later, run the following command:
```
@@ -175,7 +175,7 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg
3. Decompress the LLVM installation package to **\~/llvm**.
```
- tar -zxvf llvm.tar.gz -C ~/
+ tar -zxvf llvm.tar -C ~/
```
4. Set an environment variable.
diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup-windows.md b/en/device-dev/quick-start/quickstart-lite-env-setup-windows.md
index 9adc8cfa971293fe7a7f93694330fbec6393779f..cda9d122b4aebcd39d4b062831c8a46b22aef423 100644
--- a/en/device-dev/quick-start/quickstart-lite-env-setup-windows.md
+++ b/en/device-dev/quick-start/quickstart-lite-env-setup-windows.md
@@ -1,190 +1,65 @@
-# Setting Up Windows Development Environment
+# Setting Up Windows Development Environment
-- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
-- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
-- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
-- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
-- [Installing HPM](#en-us_topic_0000001058091994_section173054793610)
-- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
+- [Installing DevEco Device Tool](#en-us_topic_0000001058091994_section10761564496)
System requirements:
- OS: 64-bit Windows 10
- User name: cannot contain Chinese characters
-DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
-
-1. Installing Visual Studio Code
-2. Installing Python
-3. Installing Node.js
-4. Installing HPM
-5. Installing the DevEco Device Tool Plug-in
-
-## Obtaining the Software
-
-
-
-
-## Installing Visual Studio Code
+## Installing DevEco Device Tool
-> **NOTE:**
->If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
-
-1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
-
- 
-
-2. After the installation is complete, open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
-
-## Installing Python
-
-1. Double-click the Python software package, select **Add Python 3.8 to PATH**, and click **Install Now**.
-
- 
-
-2. After the installation is complete, click **Close**.
+DevEco Device Tool is installed in Visual Studio Code as a plug-in and depends on Python, Node.js, and HPM for running.
- 
-
-3. Open the CLT, and run **python --version** to check the installation result.
-
- 
-
-4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
-
- ```
- pip config set global.trusted-host repo.huaweicloud.com
- pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
- pip config set global.timeout 120
- ```
-
-
-## Installing Node.js
+DevEco Device Tool supports integrated installation. The DevEco Device Tool setup wizard checks whether the adaptation versions of Visual Studio Code, Python, Node.js and HPM tools have been installed. If any of the tools is not installed, you'll be prompted to select the tool to be automatically installed.
> **NOTE:**
->If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
-
-1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
-2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
+>Before installing DevEco Device Tool, make sure the user name of the host does not contain Chinese characters. Otherwise, the **DevEco Home** page will be stuck loading and the DevEco Device Tool cannot work.
-## Installing HPM
+1. Log in to the [HarmonyOS Device website](https://device.harmonyos.com/cn/ide#download_beta) with your HUAWEI ID and download DevEco Device Tool V3.0 Beta1 or a later version. If you do not have a HUAWEI ID, [register](https://developer.huawei.com/consumer/en/doc/start/registration-and-verification-0000001053628148) one first.
+2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**.
+3. Set the installation path of DevEco Device Tool and click **Next**.
+4. When prompted, select the tools to be automatically installed and click **Next**.
-Before installing HPM, ensure that Node.js has been installed
+ 
-and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/en/docs/ide/user-guides/npm_proxy-0000001054491032) first.
-
-> **NOTE:**
->If HPM has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
-
-1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
-
- ```
- npm config set registry https://repo.huaweicloud.com/repository/npm/
- ```
-
-2. Open the CLT and run the following command to install the latest version of HPM:
-
- ```
- npm install -g @ohos/hpm-cli
- ```
-
- 
-
-3. After the installation is complete, run the following command to obtain the installation result:
+ > **NOTE:**
+ >When the setup wizard detects that a compatible Python version has been installed, it prompts you to select the installed Python version or download the recommended Python version.
- ```
- hpm -V
- ```
+5. In the dialog box shown below, click **Next** to download and install the tools.
+ 
-## Installing the DevEco Device Tool Plug-in
+6. In the displayed Python setup wizard, select **Add Python 3.8 to PATH** and click **Install Now**. After the installation is complete, click **Close**.
-Before installing DevEco Device Tool, make sure the user name of the host does not contain Chinese characters. Otherwise, the **DevEco Home** page will be stuck loading and the DevEco Device Tool cannot work.
+ > **NOTE:**
+ >If you have selected the compatible Python version installed on your device, the Python setup wizard will not be displayed. In this case, you skip this step.
+ >If DevEco Device Tool 2.1 Release is installed, the Python version must be 3.8.x. If DevEco Device Tool V3.0 Beta1 or a later version is installed, the Python version must be 3.8.x or 3.9.x.
-DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/en/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
+ 
-> **NOTE:**
->Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
-
-1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
-2. DevEco Device Tool checks whether the toolkit on which the installation depends meets the requirements. If the requirements are not met, follow the preceding installation instructions in this section.
+7. In the Visual Studio Code setup wizard, install Visual Studio Code as prompted. During the installation, select **Add to PATH \(requires shell restart\)**.
> **NOTE:**
- >If Visual Studio Code has been installed but fails to be detected, restart your computer.
+ >If you are using the correct version of Visual Studio Code, the Visual Studio Code setup wizard will not be displayed. In this case, you skip this step.
- 
+ 
-3. Click **Install**.
+8. In the Node.js setup wizard, retain the default settings and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
- 
+ > **NOTE:**
+ >If you are using the correct version of Node.js, the Node.js setup wizard will not be displayed. In this case, you skip this step.
-4. After the installation is complete, click **Close**.
+9. Wait for the DevEco Device Tool setup wizard to automatically install the HPM and DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard.
- 
+ > **NOTE:**
+ >If you are using the correct version of HPM, the setup wizard does not download or install HPM.
-5. Start Visual Studio Code. The C/C++ and CodeLLDB plug-ins on which DevEco Device Tool depends will be automatically installed. After the installation is complete, clickon the left of Visual Studio Code to check whether C/C++, CodeLLDB, and DevEco Device Tool are included in the INSTALLED list.
+10. Start Visual Studio Code. The C/C++ and CodeLLDB plug-ins on which DevEco Device Tool depends will be automatically installed. After the installation is complete, click  on the left of Visual Studio Code to check whether C/C++, CodeLLDB, and DevEco Device Tool are included in the **INSTALLED** list.
> **NOTE:**
>If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
- 
+ 
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-faqs.md
index deeb9226580b909c8872ef16250f46ae7a649b58..1617e45faa78e9c0a12f48c900e068c8cdf48769 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-faqs.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-faqs.md
@@ -1,40 +1,32 @@
# FAQs
-- [What should I do when the images failed to be burnt over the selected serial port?](#section627268185113)
+- ["Error: Opening COMxx: Access denied" Is Displayed After a Serial Port Is Selected for Burning](#section627268185113)
- [What should I do when Windows-based PC failed to be connected to the board?](#section195391036568)
- [What should I do when the image failed to be burnt?](#section571164016565)
- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1039835245619)
- [What should I do when no command output is displayed?](#section14871149155911)
-## What should I do when the images failed to be burnt over the selected serial port?
+## "Error: Opening COMxx: Access denied" Is Displayed After a Serial Port Is Selected for Burning
- **Symptom**
**Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
- **Figure 1** Failed to open the serial port
- 
+ 
- **Possible Causes**
The serial port has been used.
-- **Solutions**
-
-1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
-
- **Figure 2** Checking whether the serial port is used
- 
+- Solution
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
+ The serial port may be in use. Perform the following steps to troubleshoot:
- **Figure 3** Disabling the terminal using the serial port
- 
+ 1. Search for the serial port from the drop-down list in the **TERMINAL** panel.
-3. Click **Burn**, select the serial port, and start burning images again.
+ 
- **Figure 4** Restarting burning
- 
+ 2. Click the dustbin for the terminal using the serial port to disable the terminal.
## What should I do when Windows-based PC failed to be connected to the board?
@@ -43,8 +35,8 @@
The file image cannot be obtained after clicking **Burn** and selecting a serial port.
- **Figure 5** Failed to obtain the image file due to unavailable connection
- 
+ **Figure 1** Failed to obtain the image file due to unavailable connection
+ 
- **Possible Causes**
@@ -57,23 +49,19 @@
1. Check whether the network cable is properly connected.
2. Click **Windows Firewall**.
- **Figure 6** Network and firewall setting
- 
+ 
3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
- **Figure 7** Firewall and network protection
- 
+ 
4. Select the Visual Studio Code application.
- **Figure 8** Selecting the Visual Studio Code application
- 
+ 
5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
- **Figure 9** Allowing the Visual Studio Code application to access the network
- 
+ 
## What should I do when the image failed to be burnt?
@@ -95,17 +83,17 @@
- **Symptom**
- 
+ 
- **Possible Cause 1**: Python is not installed.
- **Solutions**
- Install Python as instructed in [Installing and Configuring Python](quickstart-lite-env-setup-linux.md#section1238412211211).
+ [Install Python](../quick-start/quickstart-lite-env-setup-linux.md).
- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
- 
+ 
- **Solutions**
@@ -120,7 +108,7 @@
Example:
- 
+ 
## What should I do when no command output is displayed?
@@ -137,7 +125,7 @@
Change the serial port number.
- Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](#section627268185113) in the **Running an Image** section to change the serial port number.
+ Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step 1 in the **Running an Image** section to change the serial port number.
- **Possible Cause 2**
@@ -164,7 +152,7 @@
3. Log in to the serial port after the burning is complete.
- **Figure 10** Serial port displayed after the U-Boot is burnt
- 
+ **Figure 2** Serial port displayed after the U-Boot is burnt
+ 
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-program.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-program.md
index b9b82fdab933ec95f6bc88cfc7f3375130d0d43a..38c5419e03d6b5b659cf2e9a1d269e86dd3e19d9 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-program.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-program.md
@@ -433,13 +433,13 @@ Perform the [building](quickstart-lite-steps-hi3516-running.md#section107767131
>If the connection fails, rectify the fault by referring to [FAQs](quickstart-lite-steps-hi3516-faqs.md#section14871149155911).
**Figure 1** Serial port connection
- 
+ 
1. Click **Monitor** to enable the serial port.
2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to step [2](quickstart-lite-steps-hi3516-running.md#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to step [3](quickstart-lite-steps-hi3516-running.md#ld26f18828aa44c36bfa36be150e60e49) otherwise.
+ 3. Go to step [2](#li109940111259) if the board is started for the first time or the startup parameters need to be modified; go to step [3](#li448312542515) otherwise.
-2. \(Mandatory when the board is started for the first time\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
+2. \(Mandatory when the board is started for the first time\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
> **NOTICE:**
>The default waiting time in the U-Boot is 2s. You can press **Enter** to interrupt the waiting and run the **reset** command to restart the system after "hisilicon" is displayed.
@@ -480,10 +480,10 @@ Perform the [building](quickstart-lite-steps-hi3516-running.md#section107767131
> **NOTICE:**
>**go 0x80000000** is optional. It indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
-3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
+3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
**Figure 2** System startup
- 
+ 
4. In the root directory, run the **./bin/hello\_uart** command line to execute the demo program. The compilation result is shown in the following example.
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md
index 504d878c0049bb2f9be5c29f9a54d9ae5e123115..59508fb974d16f0362180bb6b8c887cd9f1fe187 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md
@@ -3,9 +3,9 @@
- [Creating a Program](#section204672145202)
- [Building](#section1077671315253)
- [Burning](#section1347011412201)
- - [Programming Flash Memory Through the Network Port](#section1935410617363)
+ - [Burning Through the Network Port](#section1935410617363)
+ - [Running an Image](#section24721014162010)
-- [Running an Image](#section24721014162010)
- [Running a Program](#section5276734182615)
This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
@@ -140,8 +140,8 @@ Select ipcamera_hispark_taurus@hisilicon and press Enter.
hb build -f (Start building.)
```
-**Figure 1** Settings
-
+**Figure 1** Hi3516 settings
+
The result files are generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
@@ -152,9 +152,9 @@ The result files are generated in the **out/hispark\_taurus/ipcamera\_hispark\_
The Hi3516 development board allows you to burn flash memory over the USB port, serial port, or network port. The following uses the network port burning as an example.
-### Programming Flash Memory Through the Network Port
+### Burning Through the Network Port
-To program flash memory through the network port in the Windows or Linux environment:
+To burn Hi3516D V300 through the network port in the Windows or Linux environment:
1. Connect the PC and the target development board through the serial port, network port, and power port. For details, see [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3516-0000001152041033).
2. Open Device Manager, then check and record the serial port number corresponding to the development board.
@@ -162,73 +162,74 @@ To program flash memory through the network port in the Windows or Linux environ
> **NOTE:**
>If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
- 
+ 
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+3. Open DevEco Device Tool, choose **QUICK ACCESS** \> **DevEco Home** \> **Projects**, and then click **Settings**.
- 
+ 
4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3516dv300** tab page, configure the programming options.
+5. On the **hi3516dv300** tab page, configure the burning options.
- **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li142386399535).
- - **upload\_protocol**: Select the programming protocol **hiburn-net**.
- - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
+ - **upload\_protocol**: Select the burning protocol **hiburn-net**.
+ - **upload\_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time.
- 
+ 
-6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
-7. Set the IP address of the network port for programming:
+6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Burning to Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
+7. Set the IP address of the network port for burning:
- **upload\_net\_server\_ip**: Select the IP address set in step [6](#en-us_topic_0000001056443961_li1558813168234), such as 192.168.1.2.
- **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+ - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+ - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- 
+ 
8. When you finish modifying, click **Save** in the upper right corner.
-9. Open the project file and go to  \> **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start programming.
+9. Open the project file and go to  \> **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start burning.
- 
+ 
10. When the following message is displayed, power off the development board and then power it on.
- 
+ 
-11. Start programming. If the following message is displayed, it indicates that the programming is successful.
+11. If the following message is displayed, it indicates that the burning is successful.
- 
+ 
+12. When the burning is successful, perform the operations in Running an Image to start the system.
-## Running an Image
+### Running an Image
-After programming is completed, you need to configure the bootloader to run the OpenHarmony system.
+After burning is completed, you need to configure the bootloader to run the OpenHarmony system.
-1. In the Hi3516D V300 task, click **Configure bootloader \(Boot OS\)** to configure the bootloader.
+1. In the Hi3516D V300 task, click **Configure bootloader \(Boot OS\)** to configure the bootloader.
- >  **NOTE:**
- > The bootloader configuration in DevEco Device Tool has been adapted to Hi3516D V300. Therefore, no manual modification is needed.
+ > **NOTE:**
+ >The bootloader configuration in DevEco Device Tool has been adapted to Hi3516D V300. Therefore, no manual modification is needed.
- 
+ 
-2. When the message shown below is displayed, restart the development board. If **SUCCESS** is displayed, it indicates that the configuration is successful.
+2. When the message shown below is displayed, restart the development board. If **SUCCESS** is displayed, it indicates that the configuration is successful.
- 
+ 
-3. Click **Monitor** on the taskbar to start the serial port tool.
+3. Click **Monitor** on the taskbar to start the serial port tool.
- 
+ 
-4. Follow the onscreen instructions until **OHOS \#** is displayed, indicating that the system is started successfully.
+4. Follow the onscreen instructions until **OHOS \#** is displayed, indicating that the system is started successfully.
- 
+ 
## Running a Program
In the root directory, run the **./bin/helloworld** command to operate the demo program. The compilation result is shown in the following example.
-**Figure 4** Successful system startup and program execution
-
+**Figure 2** Successful system startup and program execution
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md
index 1f64423bc409cdeb956ced2ebd2a6a1a985d276f..8371c50e5c20bac4ee3b345ae63f43afd4147171 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md
@@ -19,8 +19,8 @@
The following figure shows the hardware connections.
-**Figure 1** Hardware connections
-
+**Figure 1** Hi3516 hardware connections
+
### Software
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-faqs.md
index 5a8cee73c5fc04a0a390d534672ebfbe4c4c589d..d1181a9b8cb6835452dd237dc6236970111a225e 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-faqs.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-faqs.md
@@ -1,40 +1,32 @@
# FAQs
-- [What should I do when the images failed to be burnt over the selected serial port?](#section1498892119619)
+- ["Error: Opening COMxx: Access denied" Is Displayed After a Serial Port Is Selected for Burning](#section1498892119619)
- [What should I do when Windows-based PC failed to be connected to the board?](#section8512971816)
- [What should I do when the image failed to be burnt?](#section1767804111198)
- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#en-us_topic_0000001053466255_section1039835245619)
- [What should I do when no command output is displayed?](#en-us_topic_0000001053466255_section14871149155911)
-## What should I do when the images failed to be burnt over the selected serial port?
+## "Error: Opening COMxx: Access denied" Is Displayed After a Serial Port Is Selected for Burning
- **Symptom**
**Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
- **Figure 1** Failed to open the serial port
- 
+ 
- **Possible Causes**
The serial port has been used.
-- **Solutions**
-
-1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
-
- **Figure 2** Checking whether the serial port is used
- 
+- Solution
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
+ The serial port may be in use. Perform the following steps to troubleshoot:
- **Figure 3** Disabling the terminal using the serial port
- 
+ 1. Search for the serial port from the drop-down list in the **TERMINAL** panel.
-3. Click **Burn**, select the serial port, and start burning images again.
+ 
- **Figure 4** Restarting burning
- 
+ 2. Click the dustbin for the terminal using the serial port to disable the terminal.
## What should I do when Windows-based PC failed to be connected to the board?
@@ -43,8 +35,8 @@
The file image cannot be obtained after clicking **Burn** and selecting a serial port.
- **Figure 5** Failed to obtain the image file due to unavailable connection
- 
+ **Figure 1** Failed to obtain the image file due to unavailable connection
+ 
- **Possible Causes**
@@ -57,23 +49,19 @@
1. Check whether the network cable is properly connected.
2. Click **Windows Firewall**.
- **Figure 6** Network and firewall setting
- 
+ 
3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
- **Figure 7** Firewall and network protection
- 
+ 
4. Select the Visual Studio Code application.
- **Figure 8** Selecting the Visual Studio Code application
- 
+ 
5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
- **Figure 9** Allowing the Visual Studio Code application to access the network
- 
+ 
## What should I do when the image failed to be burnt?
@@ -95,7 +83,7 @@
- **Symptom**
- 
+ 
- **Possible Cause 1**
@@ -104,11 +92,11 @@
- **Solutions**
- Install Python as instructed in [Installing and Configuring Python](quickstart-lite-env-setup-linux.md#section1238412211211).
+ [Install Python](../quick-start/quickstart-lite-env-setup-linux.md).
- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
- 
+ 
- **Solutions**
@@ -123,7 +111,7 @@
Example:
- 
+ 
## What should I do when no command output is displayed?
@@ -140,7 +128,7 @@
Change the serial port number.
- Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](#section1498892119619) in the **Running an Image** section to change the serial port number.
+ Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step 1 in the **Running an Image** section to change the serial port number.
- **Possible Cause 2**
@@ -167,6 +155,6 @@
3. Log in to the serial port after the burning is complete.
- 
+ 
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-running.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-running.md
index e93979ee8fe20f0c904939749678ff5a6e344d8b..c1887587a3c2c2e87ed2c40d816f061ab0b471f6 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-running.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-running.md
@@ -139,22 +139,22 @@ hb build -f (Start building.)
The result files are generated in the **out/hispark\_aries/ipcamera\_hispark\_aries** directory.
-**Figure 1** Settings
-
+**Figure 1** Hi3518 settings
+
> **NOTICE:**
>The U-Boot file of the Hi3518E V300 development board can be obtained from the following path: device/hisilicon/hispark\_aries/sdk\_liteos/uboot/out/boot/u-boot-hi3518ev300.bin
## Burning
-Programming the flash memory is the process of downloading compiled program files to a chipset development board to provide a basis for subsequent debugging. With the one-click flash memory programming function of DevEco Device Tool, you can program flash memory on development boards quickly and efficiently.
+Burning is the process of downloading compiled program files to a chipset development board to provide a basis for subsequent debugging. With the one-click burning function of DevEco Device Tool, you can burn development boards quickly and efficiently.
-The Hi3518E V300 development board allows you to program flash memory through the USB port or serial port.
+You can burn the Hi3518E V300 development board through the USB port or serial port.
-- **Windows system: Supports programming through the USB port or serial port**
-- **Linux system: Supports programming through the serial port \(Linux+Windows dual system: Supports programming through the serial port or USB port\)**
+- **Windows system: Supports burning through the USB port or serial port**
+- **Linux system: Supports burning through the serial port \(Linux+Windows dual system: Supports burning through the serial port or USB port\)**
-Except for environment setup, the operations of programming are the same for Windows and Linux.
+Except for environment setup, the operations of burning are the same for Windows and Linux.
The following uses the USB port burning as an example.
@@ -164,68 +164,76 @@ The following uses the USB port burning as an example.
> **NOTE:**
>If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
- 
+ 
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+3. Open DevEco Device Tool, choose **QUICK ACCESS** \> **DevEco Home** \> **Projects**, and then click **Settings**.
- 
+ 
4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3518ev300** tab page, set the programming options.
+
+ > **NOTE:**
+ >If the file to be burnt is obtained by copying, you must manually change the path of the file to be burnt: Click the tab of the file to be burnt, select **Partition\_bin** from the **New Option** drop-down list box in **Partition Settings**, and set the path of the file to be burnt in **Partition\_bin**.
+
+5. On the **hi3518ev300** tab page, set the burning options.
- **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001057313128_li46411811196).
- - **upload\_protocol**: Select the programming protocol **hiburn-usb**.
- - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
+ - **upload\_protocol**: Select the burning protocol **hiburn-usb**.
+ - **upload\_partitions**: Select the files to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time.
- 
+ 
6. When you finish modifying, click **Save** in the upper right corner.
-7. Open the project file, go to  \> **PROJECT TASKS** \> **hi3518ev300\_fastboot** \> **Erase** to erase U-Boot.
+7. Open the project file, go to  \> **PROJECT TASKS** \> **hi3518ev300\_fastboot** \> **Erase** to erase U-Boot.
- 
+ 
8. When the following message is displayed, power off the development board and then power it on.
- 
+ 
9. If the following message is displayed, it indicates that U-Boot is erased successfully.
- 
+ 
-10. Go to **hi3518ev300** \> **Upload** to start programming.
+10. Go to **hi3518ev300** \> **Upload** to start burning.
- 
+ > **NOTE:**
+ >If this is the first time you burn the Hi3516D V300 or Hi3518E V300 board, the message "not find the Devices" may be displayed. In this case, follow the steps in [Installing the USB Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/usb_driver-0000001058690393) and start burning again.
+
+ 
-11. If the following message is displayed, it indicates that the programming is successful.
+11. If the following message is displayed, it indicates that the burning is successful.
- 
+ 
+12. When the burning is successful, perform the operations in Running an Image to start the system.
## Running an Image
-After programming is completed, you need to configure the bootloader to run the OpenHarmony system.
+After burning is completed, you need to configure the bootloader to run the OpenHarmony system.
-1. In the Hi3518E V300 task, click **Configure bootloader \(Boot OS\)** to configure the bootloader.
+1. In the Hi3518E V300 task, click **Configure bootloader \(Boot OS\)** to configure the bootloader.
- >  **NOTE:**
- > The bootloader configuration in DevEco Device Tool has been adapted to Hi3518E V300. Therefore, no manual modification is needed.
+ > **NOTE:**
+ >The bootloader configuration in DevEco Device Tool has been adapted to Hi3518E V300. Therefore, no manual modification is needed.
- 
+ 
-2. When the message shown below is displayed, restart the development board. If **SUCCESS** is displayed, it indicates that the configuration is successful.
+2. When the message shown below is displayed, restart the development board. If **SUCCESS** is displayed, it indicates that the configuration is successful.
- 
+ 
-3. Click **Monitor** on the taskbar to start the serial port tool.
+3. Click **Monitor** on the taskbar to start the serial port tool.
- 
+ 
-4. Follow the onscreen instructions until **OHOS \#** is displayed, indicating that the system is started successfully.
+4. Follow the onscreen instructions until **OHOS \#** is displayed, indicating that the system is started successfully.
- 
+ 
## Follow-up Learning
-Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/device-wlan-sdk.md).
+Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/device-iotcamera.md).
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-setting.md
index 91da405234eb524779de6c50ac851ed00980111b..86ea4fcf9292f50befdb11bc555bdbeb2cfe614c 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3518-setting.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3518-setting.md
@@ -19,8 +19,8 @@
The following figure shows the hardware connections.
- **Figure 1** Hardware connections
- 
+ **Figure 1** Hi3518 hardware connections
+ 
### Software
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-connection.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-connection.md
index 342f6f4b21e4a4a64dcf2116c36d2ffa3c986a9d..0344e5a38233563788876017df319e286ca10c4c 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-connection.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-connection.md
@@ -15,27 +15,27 @@ If the Linux environment is installed using Docker, perform the building by refe
1. Open the HUAWEI DevEco Device Tool and choose **View** \> **Terminal**.
**Figure 1** Starting the IDE terminal tool
- 
+ 
On the **TERMINAL** panel, run the ssh command, for example, **ssh** **_user_@_ipaddr_**, to connect to the Linux server.
**Figure 2** TERMINAL panel
- 
+ 
2. Go to the root directory of the code, run the **hb set** and **.** commands on the **TERMINAL** panel, and select the **wifiiot\_hispark\_pegasus** version.
**Figure 3** Selecting the target build version
- 
+ 
3. Run the **hb build** command to start building.
**Figure 4** Running commands on the TERMINAL panel
- 
+ 
4. Check whether the building is successful. If yes, **wifiiot\_hispark\_pegasus build success** will be displayed, as shown in the following figure.
**Figure 5** Successful building
- 
+ 
5. Check whether the following files are generated in the **./out/wifiiot/** directory.
@@ -44,19 +44,19 @@ If the Linux environment is installed using Docker, perform the building by refe
```
**Figure 6** Directory for storing the generated files
- 
+ 
## Burning Images
-Programming the flash memory is the process of downloading compiled program files to a chipset development board to provide a basis for subsequent debugging. With the one-click flash memory programming function of DevEco Device Tool, you can program flash memory on development boards quickly and efficiently.
+Burning is the process of downloading compiled program files to a chipset development board to provide a basis for subsequent debugging. With the one-click burning function of DevEco Device Tool, you can burn development boards quickly and efficiently.
-**The Hi3861 V100 development board allows you to program flash memory through the serial port using the burn-serial or hiburn-serial protocol. The hiburn-serial protocol is applicable to both Windows and Linux systems, while the burn-serial is applicable to Linux only.**
+**You can burn to the Hi3861 V100 development board through the serial port using the burn-serial or hiburn-serial protocol. The hiburn-serial protocol is applicable to both Windows and Linux systems, while the burn-serial is applicable to Linux only.**
> **NOTE:**
>The burn-serial protocol is used for compatibility with the projects of historical versions. It does not differ from hiburn-serial in operations.
-The operations for programming flash memory in Windows and Linux are the same. The only difference lies in the environment setup for DevEco Device Tool.
+The operations for burning in Windows and Linux are the same. The only difference lies in the environment setup for DevEco Device Tool.
1. Connect the PC and the target development board through the USB port. For details, see [Introduction to the Hi3861 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3861-0000001105041324).
2. Open Device Manager, then check and record the serial port number corresponding to the development board.
@@ -64,33 +64,37 @@ The operations for programming flash memory in Windows and Linux are the same. T
> **NOTE:**
>If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3861 Series Development Board](https://device.harmonyos.com/en/docs/ide/user-guides/hi3861-drivers-0000001058153433).
- 
+ 
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+3. Open DevEco Device Tool, choose **QUICK ACCESS** \> **DevEco Home** \> **Projects**, and then click **Settings**.
- 
+ 
4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3861** tab page, set the programming options.
+
+ > **NOTE:**
+ >If the file to be burnt is obtained by copying, you must manually change the path of the file to be burnt: Click the tab of the file to be burnt, select **Partition\_bin** from the **New Option** drop-down list box in **Partition Settings**, and set the path of the file to be burnt in **Partition\_bin**.
+
+5. On the **hi3861** tab page, set the burning options.
- **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056563976_li848662117291).
- - **upload\_protocol**: Select the programming protocol. For Windows, set this parameter to **burn-serial** or **hiburn-serial**. For Linux, set this parameter to **hiburn-serial**.
- - **upload\_partitions**: Select the file to be programmed. **hi3861\_app** is selected by default.
+ - **upload\_protocol**: Select the burning protocol. For Windows, set this parameter to **burn-serial** or **hiburn-serial**. For Linux, set this parameter to **hiburn-serial**.
+ - **upload\_partitions**: Select the files to be burnt. **hi3861\_app** is selected by default.
- 
+ 
6. When you finish modifying, click **Save** in the upper right corner.
-7. Open the project file. In the DevEco Device Tool window, go to **PROJECT TASKS** \> **hi3861** \> **Upload** to start programming.
+7. Open the project file. In the DevEco Device Tool window, go to **PROJECT TASKS** \> **hi3861** \> **Upload** to start burning.
- 
+ 
8. When the following information is displayed, press the RST button on the development board to restart it.
- 
+ 
-9. Start programming. If the following message is displayed, it indicates that the programming is successful.
+9. If the following message is displayed, it indicates that the burning is successful.
- 
+ 
## Connecting WLAN Module to the Internet.
@@ -100,12 +104,12 @@ After completing version building and burning, do as follows to connect the WLAN
1. Click the icon of **DevEco: Serial Monitor** at the bottom of DevEco Studio to keep the connection between the Windows workstation and the WLAN module.
**Figure 7** Opening the DevEco serial port
- 
+ 
2. Reset the WLAN module. The message **ready to OS start** is displayed on the **TERMINAL** panel, indicating that the WLAN module is started successfully.
**Figure 8** Successful resetting of the WLAN module
- 
+ 
3. Run the following AT commands in sequence via the DevEco serial port terminal to start the STA mode, connect to the specified AP, and enable Dynamic Host Configuration Protocol \(DHCP\).
@@ -126,6 +130,6 @@ After completing version building and burning, do as follows to connect the WLAN
```
**Figure 9** Successful networking of the WLAN module
- 
+ 
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-faqs.md
index 2d5e461309e175732d22cf48d5784760fc467d80..562c7a2e91314830069dcf5130adac7cdf4dfc0d 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-faqs.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-faqs.md
@@ -9,6 +9,7 @@
- [What should I do when the message Could not find a version that satisfies the requirement six\>=1.9.0 is displayed during compilation and building?](#section4498158162320)
- [What should I do when the message cannot find -lgcc is displayed during compilation and building?](#section11181036112615)
- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1571810194619)
+- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section108385316482)
- [What should I do when an error with lsb\_release occurs during kconfiglib installation?](#section691681635814)
## What should I do when the message **configure: error: no acceptable C compiler found in $PATH** is displayed during Python 3 installation?
@@ -60,7 +61,7 @@
The following error occurs during Python 3 installation:
```
- zipimport.ZipImportError: can't decompress data; zlib not avaliable
+ zipimport.ZipImportError: can't decompress data; zlib not available
```
- **Possible Causes**
@@ -73,7 +74,7 @@
Solution 2: If the software source does not contain **zlib**, download the source code from [http://www.zlib.net/](http://www.zlib.net/).
- 
+ 
Then run the following commands to install **zlib** offline:
@@ -134,7 +135,7 @@
- Download the source code from [https://pypi.org/project/pycrypto/\#files](https://pypi.org/project/pycrypto/#files).
- 
+ 
- Save the source code package to the Linux server, decompress the package, and run the **python3 setup.py install** command to install **Crypto**.
- Rebuild an environment.
@@ -164,7 +165,7 @@
- Download the installation package from [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files).
- 
+ 
- Save the installation package to the Linux server and run the **pip3 install ecdsa-0.15-py2.py3-none-any.whl** command to install **ecdsa**.
- Rebuild an environment.
@@ -194,7 +195,7 @@
- Download the installation package from [https://pypi.org/project/six/\#files](https://pypi.org/project/six/#files).
- 
+ 
- Save the source code to the Linux server and run the **pip3 install six-1.14.0-py2.py3-none-any.whl** command to install **six**.
- Rebuild an environment.
@@ -243,11 +244,11 @@
- **Possible Cause 1:** Python is not installed.
- **Solutions**
- Install Python as instructed in [Installing and Configuring Python](quickstart-lite-env-setup-linux.md#section1238412211211).
+ [Install Python](../quick-start/quickstart-lite-env-setup-linux.md).
- **Possible Cause 2:** The soft link that points to the Python does not exist in the **usr/bin** directory.
- 
+ 
- **Solutions**
@@ -262,7 +263,23 @@
Example:
- 
+ 
+
+
+## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
+
+- **Symptom**
+
+ 
+
+
+- **Possible Causes**
+
+ Python 3 is not installed.
+
+- **Solutions**
+
+ [Install Python](../quick-start/quickstart-lite-env-setup-linux.md).
## What should I do when an error with **lsb\_release** occurs during **kconfiglib** installation?
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md
index 07f64c162a635091e62aa501b76e4d0edd74974e..2eab40b209aa314c811a32bb28d64422f9ff0688 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md
@@ -136,7 +136,7 @@ To parse the call stack information, the **Hi3861\_wifiiot\_app.asm** file is
3. Based on the above call stack information, it can be determined that an exception occurs in the **WadRecvCB** function.
- 
+ 
4. Check and modify the code.
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md
index e13a094dd2c13ef1f57ecf1f72a99d46528dfea8..3a70fb05f651284987ca09193c83a9232f196ca9 100644
--- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md
+++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md
@@ -23,8 +23,8 @@
The following figure shows the hardware connections.
-**Figure 1** Hardware connections
-
+**Figure 1** Hi3861 hardware connections
+
### Software
@@ -124,7 +124,7 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
```
**Figure 2** Successful installation \(SCons version requirement: 3.0.4 or later\)
- .png "successful-installation-(scons-version-requirement-3-0-4-or-later)")
+ .png "successful-installation-(scons-version-requirement-3-0-4-or-later)")
### Installing Python Modules
@@ -220,13 +220,13 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
> **NOTICE:**
>- The Hi3861 platform supports only the static link of the libgcc library. The dynamic link is not recommended because version 3 of the GNU General Public License \(GPLv3\) will be polluted during commercial distribution.
->- Steps 2 to 15 of the following procedure are used to build the **gcc\_riscv32** image. You can simply [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz) and skip these steps.
+>- Steps 2 to 15 of the following procedure are used to build the **gcc\_riscv32** image. You can and skip these steps and directly [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz).
1. Start a Linux server.
2. Install the **GCC**, **G++**, **Bison**, **Flex**, **Makeinfo** tools to ensure that the toolchain can be correctly compiled.
```
- sudo apt-get install gcc && sudo apt-get install g++ && sudo apt-get install flex bison && sudo apt-get install texinfo
+ sudo apt-get install gcc g++ flex bison texinfo
```
3. Download the RISC-V GNU toolchain.
@@ -353,6 +353,6 @@ Perform the following operations on the Windows station.
2. Install the driver.
3. After the driver is installed, remove and then insert the USB cable. The serial port entry should be displayed as shown in the following figure.
- 
+ 
diff --git a/en/device-dev/quick-start/quickstart-standard-burn.md b/en/device-dev/quick-start/quickstart-standard-burn.md
index 97c5c0dc3012b7528beca2cfbc103a18c148ad92..4a3c55797f5096e23b2be873b7c821776f617c87 100644
--- a/en/device-dev/quick-start/quickstart-standard-burn.md
+++ b/en/device-dev/quick-start/quickstart-standard-burn.md
@@ -1,30 +1,29 @@
# Burning Images
-- [Prerequisites](#section232415263110)
- - [Programming Flash Memory Through the Network Port](#section998903784810)
+- [Prerequisites](#section18547185418328)
+- [Programming Flash Memory Through the Network Port](#section1965361953312)
+Burning of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
-Programming flash memory of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
+Hi3516D V300 supports burning of the standard system through the USB port, network port, or serial port, where:
-Hi3516D V300 supports programming flash memory of the standard system through the USB port, network port, or serial port, where:
+- **Windows system: Supports burning through the USB port, serial port, or network port**
+- **Linux system: Supports burning through the network port or serial port**
-- **Windows system: Supports programming through the USB port, serial port, or network port**
-- **Linux system: Supports programming through the network port or serial port**
-
-Except for environment setup, the operations of programming are the same for Windows and Linux.
+Except for environment setup, the operations of burning are the same for Windows and Linux.
> **NOTE:**
->Currently, the Hi3516D V300 development board supports system burning over the network port, USB port, or serial port. This document uses the network port as an example. For details about system burning over other ports, see [Programming Flash Memory on Hi3516D V300](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
+>Currently, the Hi3516D V300 development board supports programming flash memory of the standard system through the USB port, network port, or serial port. This document uses the network port as an example. For details about programming flash memory over other ports, see [Programming Flash Memory on Hi3516D V300](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
-## Prerequisites
+## Prerequisites
-In DevEco Device Tool, select **Import Project** to open the folder where the target file is located. Set **MCU** to **Hi3516DV300** under **HiSilicon\_Arm\_Linux** and **Framework** to **Hb**.
+In DevEco Device Tool, select **Import Project** to open the folder where the target file is located. Set **MCU** to **Hi3516DV300** under **HiSilicon\_Arm\_Linux** and **Framework** to **Ohos-sources** or **Hpm**.
-
+
-### Programming Flash Memory Through the Network Port
+## Programming Flash Memory Through the Network Port
-The Hi3516DV300 supports programming through the network port in Windows or Linux.
+The Hi3516DV300 supports burning through the network port in Windows or Linux.
1. Connect the PC and the target development board through the serial port, network port, and power port. For details, see [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3516-0000001152041033).
2. Open Device Manager, then check and record the serial port number corresponding to the development board.
@@ -32,37 +31,42 @@ The Hi3516DV300 supports programming through the network port in Windows or Linu
> **NOTE:**
>If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
- 
+ 
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+3. Open DevEco Device Tool, choose **QUICK ACCESS** \> **DevEco Home** \> **Projects**, and then click **Settings**.
- 
+ 
-4. On the **hi3516dv300** tab page, configure the programming options.
+4. On the **hi3516dv300** tab page, configure the burning options.
- **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li1050616379507).
- - **upload\_protocol**: Select the programming protocol **hiburn-net**.
+ - **upload\_protocol**: Select the burning protocol **hiburn-net**.
- **upload\_partitions**: Select the files to be burnt. By default, **fastboot**, **boot**, **updater**, **misc**, **system**, **vendor**, and **userdata** are burnt at the same time.
- 
+ 
-5. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
-6. Set the IP address of the network port for programming:
+5. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Burning to Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
+6. Set the IP address of the network port for burning:
- - **upload\_net\_server\_ip**: Select the IP address set in step [6](en-us_topic_0000001056443961.md#li1558813168234), such as 192.168.1.2.
- - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+ - **upload\_net\_server\_ip**: Select the IP address set in step [5](#en-us_topic_0000001056443961_li85106114532), such as 192.168.1.2.
+ - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 255.255.255.0.
+ - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.1.
+ - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.3.
- 
+ 
7. When you finish modifying, click **Save** in the upper right corner.
-8. When the following message is displayed, power off the development board and then power it on.
+8. Open the project file and go to  \> **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start burning.
+
+ 
+
+9. When the following message is displayed, power off the development board and then power it on.
- 
+ 
-9. Start programming. If the following message is displayed, it indicates that the programming is successful.
+10. If the following message is displayed, it indicates that the burning is successful.
- 
+ 
+11. When the burning is successful, perform the operations in [Running an Image](https://device.harmonyos.com/en/docs/start/introduce/quickstart-standard-running-0000001142160948) to start the system.
diff --git a/en/device-dev/quick-start/quickstart-standard-docker-environment.md b/en/device-dev/quick-start/quickstart-standard-docker-environment.md
index e04092d2cefc7a508a45a7a83e647e38a6e409ce..e96a662f9ccefdab9c56c67dacf59378671cef34 100644
--- a/en/device-dev/quick-start/quickstart-standard-docker-environment.md
+++ b/en/device-dev/quick-start/quickstart-standard-docker-environment.md
@@ -1,9 +1,10 @@
-# Setting Up Ubuntu Development Environment in Docker Mode
+# Setting Up a Ubuntu Development Environment in Docker Mode
- [Obtaining Standard-System Source Code](#section8761819202511)
- [Prerequisites](#section102871547153314)
- [Procedure](#section429012478331)
+- [Running prebuilts](#section0495320152619)
- [Obtaining the Docker Environment](#section181431248132513)
- [Building Source Code](#section92391739152318)
@@ -19,7 +20,7 @@ The standard OpenHarmony system provides a Docker environment which encapsulates
1. Register your account with Gitee.
2. Register an SSH public key for access to Gitee.
-3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information.
+3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information.
```
git config --global user.name "yourname"
@@ -38,13 +39,14 @@ The standard OpenHarmony system provides a Docker environment which encapsulates
### Procedure
+Two methods are provided for you to obtain the OpenHarmony master code. You are advised to create a new folder and run the related commands in this folder to download the source code. This folder will then be the root directory of the source code.
+
Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
```
repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'
-bash build/prebuilts_download.sh
```
Method 2: Use the **repo** tool to download the source code over HTTPS.
@@ -53,9 +55,18 @@ Method 2: Use the **repo** tool to download the source code over HTTPS.
repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'
+```
+
+## Running prebuilts
+
+Go to the root directory of the source code and run the following script to install the compiler and binary tool:
+
+```
bash build/prebuilts_download.sh
```
+By default, the downloaded prebuilts binary file is stored in **OpenHarmony\_2.0\_canary\_prebuilts** \(which is in the same directory as **OpenHarmony**\).
+
## Obtaining the Docker Environment
**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
@@ -66,14 +77,14 @@ bash build/prebuilts_download.sh
docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.5
```
-2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+2. Go to the root directory of source code and run the following command to access the Docker build environment:
```
docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.5
```
-**Method 2: Using the Dockerfile to build a local docker image**
+**Method 2: Using the Dockerfile to Build a Local Docker Image**
1. Obtain the Dockerfile script for a local Docker image.
@@ -88,7 +99,7 @@ bash build/prebuilts_download.sh
./build.sh
```
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+3. Go to the root directory of source code and run the following command to access the Docker build environment:
```
docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.5
@@ -97,17 +108,17 @@ bash build/prebuilts_download.sh
## Building Source Code
-1. Run the following script to start building for Standard-System Devices \(reference memory ≥ 128 MB\):
+1. Run the following script to start building for standard-system devices \(reference memory ≥ 128 MB\).
- ```
- ./build.sh --product-name {product_name}
- ```
+ ```
+ ./build.sh --product-name {product_name}
+ ```
- **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
+ **product\_name** indicates the platform supported by the current distribution, for example, Hi3516D V300.
- Files generated during the build are stored in the **out/ohos-arm-release/** directory, and the generated image is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
+ Files generated during building are stored in the **out/ohos-arm-release/** directory, and the generated image is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
-2. Burn the image. For details, see [Burning Images](quickstart-standard-burn.md).
+2. Burn the image. For details, see [Burning Images](quickstart-standard-burn.md).
> **NOTE:**
>You can exit Docker by simply running the **exit** command.
diff --git a/en/device-dev/quick-start/quickstart-standard-faqs.md b/en/device-dev/quick-start/quickstart-standard-faqs.md
index 649bcba046dcb5d9429291e69e44cc933bbbd077..2d297fdc29a43b04fc89d0dda28bdb925394b9c4 100644
--- a/en/device-dev/quick-start/quickstart-standard-faqs.md
+++ b/en/device-dev/quick-start/quickstart-standard-faqs.md
@@ -1,10 +1,13 @@
# FAQs
+- [What Should I Do If "ImportError: No module named apt\_pkg" Is Displayed During Compilation and Building?](#section32195464215)
+
+## What Should I Do If "ImportError: No module named apt\_pkg" Is Displayed During Compilation and Building?
+
- **Symptom**
The message "ImportError: No module named apt\_pkg" is displayed when an unidentifiable command is executed on the Linux server.
-
- **Possible Causes**
There is a compatibility issue of python3-apt.
diff --git a/en/device-dev/quick-start/quickstart-standard-overview.md b/en/device-dev/quick-start/quickstart-standard-overview.md
index 04c6ab992fc7b1bcde7d148efd9a54fec258ea24..01e74b19743ebc83ed0f6d7fd8ca6ccd21b0e823 100644
--- a/en/device-dev/quick-start/quickstart-standard-overview.md
+++ b/en/device-dev/quick-start/quickstart-standard-overview.md
@@ -13,14 +13,14 @@ This document uses the recommended Hi3516D V300 development board as an example.
The following figure shows the process of getting started for the standard system, during which, you can set up the Ubuntu development environment in Docker mode or by using the installation package.
**Figure 1** Getting started for the standard system
-
+
## Introduction to the Development Board
Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.
**Figure 2** Hi3516D V300 front view
-
+
## Development Board Specifications
@@ -40,7 +40,7 @@ Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the indust
External components
|
-- Ethernet port
- Audio and video
- One voice input
- One mono (AC_L) output, connected to a 3 W power amplifier (LM4871)
- Micro-HDMI (one HDMI 1.4)
+- Ethernet port
- Audio and video
- One voice input
- One mono output (AC_L), connected to a 3 W power amplifier (LM4871)
- Micro-HDMI (one HDMI 1.4)
- Cameras
- Sensor IMX335
- M12 lens with a focal length of 4 mm and an aperture of 1.8
- Display
- 2.35-inch LCD connector
- 5.5-inch LCD connector
- External components and interfaces
- microSD card interface
- JTAG/I2S interface
- ADC interface
- Steer gear interface
- Grove connector
- USB 2.0 (Type C)
- Three function keys: two custom keys and one update key
- LED indicator (including green and red)
diff --git a/en/device-dev/quick-start/quickstart-standard-package-environment.md b/en/device-dev/quick-start/quickstart-standard-package-environment.md
index fcfe369fefdcae2c148e879ff5a8fa5628a3c662..8e0b4e69770cd43df8eb390cb138eb98b618410b 100644
--- a/en/device-dev/quick-start/quickstart-standard-package-environment.md
+++ b/en/device-dev/quick-start/quickstart-standard-package-environment.md
@@ -1,4 +1,4 @@
-# Setting Up Ubuntu Development Environment with Installation Package
+# Setting Up a Ubuntu Development Environment Using the Installation Package
- [Installing Dependent Tools](#section18431165519244)
- [Obtaining Standard-System Source Code](#section113751052102517)
@@ -25,7 +25,7 @@ sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex biso
1. Register your account with Gitee.
2. Register an SSH public key for access to Gitee.
-3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information.
+3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information.
```
git config --global user.name "yourname"
@@ -44,6 +44,8 @@ sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex biso
### Procedure
+Two methods are provided for you to obtain the OpenHarmony master code. You are advised to create a new folder and run the related commands in this folder to download the source code. This folder will then be the root directory of the source code.
+
Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
```
diff --git a/en/device-dev/quick-start/quickstart-standard-running.md b/en/device-dev/quick-start/quickstart-standard-running.md
index 5ee6df5ffaa8846b0f3ae4670d8ef8c590fe8f72..8375204a05f4c8b0cf46030ccb89996ba3a8f3bd 100644
--- a/en/device-dev/quick-start/quickstart-standard-running.md
+++ b/en/device-dev/quick-start/quickstart-standard-running.md
@@ -1,6 +1,9 @@
# Running an Image
-## Running an Image
+- [Running an Image](#section153991115191314)
+- [Next](#section5600113114323)
+
+## Running an Image
After the image burning is complete, perform the following steps to run the system:
@@ -9,23 +12,23 @@ After the image burning is complete, perform the following steps to run the syst
1. In DevEco Device Tool, click **Monitor** to open the serial port tool.
- 
+ 
2. Restart the development board. Before the autoboot countdown ends, press any key to enter the system.
- 
+ 
3. Run the following commands to set system boot parameters:
```
- setenv bootargs 'mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused androidboot.selinux=permissive skip_initramfs rootdelay=5 init=/init root=/dev/mmcblk0p5 rootfstype=ext4 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),1M(misc),3307M(system),256M(vendor),-(userdata)'
+ setenv bootargs 'mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused rootdelay=10 hardware=Hi3516DV300 init=/init root=/dev/ram0 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),2M(misc),3307M(system),256M(vendor),-(userdata)';
```
```
- setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800; bootm 0x80000000";
+ setenv bootcmd 'mmc read 0x0 0x82000000 0x800 0x4800; bootm 0x82000000'
```
- 
+ 
4. Save the parameter settings.
@@ -33,7 +36,7 @@ After the image burning is complete, perform the following steps to run the syst
save
```
- 
+ 
5. Restart the development board to start the system.
@@ -41,8 +44,10 @@ After the image burning is complete, perform the following steps to run the syst
reset
```
- 
+ 
+
+
+## Next
-## Next
+Congratulations! You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Clock App](../guide/device-clock-guide.md).
-Congratulations! You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Clock App](../guide/device-clock-guide.md).
diff --git a/en/device-dev/quick-start/quickstart-standard-windows-environment.md b/en/device-dev/quick-start/quickstart-standard-windows-environment.md
index 2367d7b0784499dfea575b3a83be13cf270c262a..2a91d675138760f1ee33ff0f34374a384144a061 100644
--- a/en/device-dev/quick-start/quickstart-standard-windows-environment.md
+++ b/en/device-dev/quick-start/quickstart-standard-windows-environment.md
@@ -1,190 +1,65 @@
-# Setting Up Windows Development Environment
+# Setting Up a Windows Development Environment
-- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
-- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
-- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
-- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
-- [Installing HPM](#en-us_topic_0000001058091994_section173054793610)
-- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
+- [Installing DevEco Device Tool](#en-us_topic_0000001058091994_section10761564496)
System requirements:
- OS: 64-bit Windows 10
- User name: cannot contain Chinese characters
-DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
-
-1. Installing Visual Studio Code
-2. Installing Python
-3. Installing Node.js
-4. Installing HPM
-5. Installing the DevEco Device Tool Plug-in
-
-## Obtaining the Software
-
-
-
-
-## Installing Visual Studio Code
+## Installing DevEco Device Tool
-> **NOTE:**
->If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
-
-1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
-
- 
-
-2. After the installation is complete, open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
-
-## Installing Python
-
-1. Double-click the Python software package, select **Add Python 3.8 to PATH**, and click **Install Now**.
-
- 
-
-2. After the installation is complete, click **Close**.
+DevEco Device Tool is installed in Visual Studio Code as a plug-in and depends on Python, Node.js, and HPM for running.
- 
-
-3. Open the CLT, and run **python --version** to check the installation result.
-
- 
-
-4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
-
- ```
- pip config set global.trusted-host repo.huaweicloud.com
- pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
- pip config set global.timeout 120
- ```
-
-
-## Installing Node.js
+DevEco Device Tool supports integrated installation. The DevEco Device Tool setup wizard checks whether the adaptation versions of Visual Studio Code, Python, Node.js and HPM tools have been installed. If any of the tools is not installed, you'll be prompted to select the tool to be automatically installed.
> **NOTE:**
->If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
-
-1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
-2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
+>Before installing DevEco Device Tool, make sure the user name of the host does not contain Chinese characters. Otherwise, the **DevEco Home** page will be stuck loading and the DevEco Device Tool cannot work.
-## Installing HPM
+1. Log in to the [HarmonyOS Device website](https://device.harmonyos.com/cn/ide#download_beta) with your HUAWEI ID and download DevEco Device Tool V3.0 Beta1 or a later version. If you do not have a HUAWEI ID, [register](https://developer.huawei.com/consumer/en/doc/start/registration-and-verification-0000001053628148) one first.
+2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**.
+3. Set the installation path of DevEco Device Tool and click **Next**.
+4. When prompted, select the tools to be automatically installed and click **Next**.
-Before installing HPM, ensure that Node.js has been installed
+ 
-and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/en/docs/ide/user-guides/npm_proxy-0000001054491032) first.
-
-> **NOTE:**
->If HPM has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
-
-1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
-
- ```
- npm config set registry https://repo.huaweicloud.com/repository/npm/
- ```
-
-2. Open the CLT and run the following command to install the latest version of HPM:
-
- ```
- npm install -g @ohos/hpm-cli
- ```
-
- 
-
-3. After the installation is complete, run the following command to obtain the installation result:
+ > **NOTE:**
+ >When the setup wizard detects that a compatible Python version has been installed, it prompts you to select the installed Python version or download the recommended Python version.
- ```
- hpm -V
- ```
+5. In the dialog box shown below, click **Next** to download and install the tools.
+ 
-## Installing the DevEco Device Tool Plug-in
+6. In the displayed Python setup wizard, select **Add Python 3.8 to PATH** and click **Install Now**. After the installation is complete, click **Close**.
-Before installing DevEco Device Tool, make sure the user name of the host does not contain Chinese characters. Otherwise, the **DevEco Home** page will be stuck loading and the DevEco Device Tool cannot work.
+ > **NOTE:**
+ >If you have selected the compatible Python version installed on your device, the Python setup wizard will not be displayed. In this case, you skip this step.
+ >If DevEco Device Tool 2.1 Release is installed, the Python version must be 3.8.x. If DevEco Device Tool V3.0 Beta1 or a later version is installed, the Python version must be 3.8.x or 3.9.x.
-DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/en/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
+ 
-> **NOTE:**
->Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
-
-1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
-2. DevEco Device Tool checks whether the toolkit on which the installation depends meets the requirements. If the requirements are not met, follow the preceding installation instructions in this section.
+7. In the Visual Studio Code setup wizard, install Visual Studio Code as prompted. During the installation, select **Add to PATH \(requires shell restart\)**.
> **NOTE:**
- >If Visual Studio Code has been installed but fails to be detected, restart your computer.
+ >If you are using the correct version of Visual Studio Code, the Visual Studio Code setup wizard will not be displayed. In this case, you skip this step.
- 
+ 
-3. Click **Install**.
+8. In the Node.js setup wizard, retain the default settings and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
- 
+ > **NOTE:**
+ >If you are using the correct version of Node.js, the Node.js setup wizard will not be displayed. In this case, you skip this step.
-4. After the installation is complete, click **Close**.
+9. Wait for the DevEco Device Tool setup wizard to automatically install the HPM and DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard.
- 
+ > **NOTE:**
+ >If you are using the correct version of HPM, the setup wizard does not download or install HPM.
-5. Start Visual Studio Code. The C/C++ and CodeLLDB plug-ins on which DevEco Device Tool depends will be automatically installed. After the installation is complete, click on the left of Visual Studio Code to check whether C/C++, CodeLLDB, and DevEco Device Tool are included in the INSTALLED list.
+10. Start Visual Studio Code. The C/C++ and CodeLLDB plug-ins on which DevEco Device Tool depends will be automatically installed. After the installation is complete, click  on the left of Visual Studio Code to check whether C/C++, CodeLLDB, and DevEco Device Tool are included in the **INSTALLED** list.
> **NOTE:**
>If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
- 
+ 
diff --git a/en/device-dev/quick-start/quickstart-standard.md b/en/device-dev/quick-start/quickstart-standard.md
index a464c3dc670ed78a5631b62380839dbee0873e7a..e939227a4b3f8d152ec892f06ee37bc1b816e45b 100644
--- a/en/device-dev/quick-start/quickstart-standard.md
+++ b/en/device-dev/quick-start/quickstart-standard.md
@@ -2,11 +2,11 @@
- **[Introduction](quickstart-standard-overview.md)**
-- **[Setting Up Windows Development Environment](quickstart-standard-windows-environment.md)**
+- **[Setting Up a Windows Development Environment](quickstart-standard-windows-environment.md)**
-- **[Setting Up Ubuntu Development Environment in Docker Mode](quickstart-standard-docker-environment.md)**
+- **[Setting Up a Ubuntu Development Environment in Docker Mode](quickstart-standard-docker-environment.md)**
-- **[Setting Up Ubuntu Development Environment with Installation Package](quickstart-standard-package-environment.md)**
+- **[Setting Up a Ubuntu Development Environment Using the Installation Package](quickstart-standard-package-environment.md)**
- **[Burning Images](quickstart-standard-burn.md)**
diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md
index 443fc64a65979c301836ab0cca38856d7cf3aa59..90d19a51f44f7845c2ae865d43a43f23fedcc8ed 100644
--- a/en/device-dev/subsystems/Readme-EN.md
+++ b/en/device-dev/subsystems/Readme-EN.md
@@ -49,6 +49,9 @@
- [Development Guidelines](subsys-application-framework-guide.md)
- [Development Example](subsys-application-framework-demo.md)
- [OTA Upgrade](subsys-ota-guide.md)
+- [Telephony Service ](subsys-tel.md)
+ - [Telephony Service](telephony-service.md)
+ - [Development Guidelines](development-guidelines.md)
- [Security](subsys-security.md)
- [Overview](subsys-security-overview.md)
- [Development Guidelines on Application Signature Verification](subsys-security-sigverify.md)
diff --git a/en/device-dev/subsystems/development-guidelines.md b/en/device-dev/subsystems/development-guidelines.md
new file mode 100644
index 0000000000000000000000000000000000000000..1f930477fe690212dfe6107d353628da2ff5931e
--- /dev/null
+++ b/en/device-dev/subsystems/development-guidelines.md
@@ -0,0 +1,616 @@
+# Development Guidelines
+
+- [Initializing a Modem Vendor Library](#section211mcpsimp)
+ - [When to Use](#section213mcpsimp)
+ - [Available APIs](#section811343241215)
+ - [How to Develop](#section51031144122)
+ - [Debugging and Verification](#section5351151517132)
+
+- [Responding to Modem Service Requests](#section295mcpsimp)
+ - [When to Use](#section297mcpsimp)
+ - [Available APIs](#section9503155219134)
+ - [How to Develop](#section17190412101414)
+ - [Debugging and Verification](#section10207938171413)
+
+- [Reporting Modem Events](#section390mcpsimp)
+ - [When to Use](#section401mcpsimp)
+ - [Available APIs](#section191193791518)
+ - [How to Develop](#section16394112401512)
+ - [Debugging and Verification](#section16999174401516)
+ - [Development Examples](#section33444350167)
+
+- [Integrating Modem Vendor Libraries](#section590mcpsimp)
+ - [Configuring Compilation Information](#section592mcpsimp)
+ - [Debugging and Verification](#section620mcpsimp)
+
+
+## Initializing a Modem Vendor Library
+
+### When to Use
+
+Initializing a modem vendor library means to implement **const HRilOps \*RilInitOps\(const struct HRilReport \*reportOps\)** function in the vendor library. This function is mainly used to:
+
+- Receive function pointers to event callbacks of RIL Adapter. When a service event needs to be reported, the target pointer will be called to report the event to RIL Adapter.
+- Create a thread for reading modem nodes. In this thread, the data reported by the modem is read cyclically and parsed as a specific service event for reporting.
+- Return the function pointer of the service request API to RIL Adapter.
+
+### Available APIs
+
+The following table describes the API for initializing a modem vendor library.
+
+**Table 1** API for initializing a modem vendor library
+
+
+API
+ |
+Description
+ |
+
|---|
+
+const HRilOps *RilInitOps(const struct HRilReport * reportOps)
+ |
+Function: Provides an entry for running a modem vendor library.
+Input parameter:
+reportOps: Specifies the pointer to the event callback function, which is passed by RIL Adapter.
+Return result: function pointer of the service request API.
+ |
+
+
+
+
+### How to Develop
+
+1. Set the event callback function pointers passed by RIL Adapter through **RilInitOps**.
+
+ ```
+ // Define the callback function pointers of the modem vendor library.
+ static struct HRilReport g_reportOps = {
+ OnCallReport, // Callback function for call services
+ OnDataReport, // Callback function for cellular data services
+ OnModemReport, // Callback function for modem services
+ OnNetworkReport, // Callback function for network search services
+ OnSimReport, // Callback function for SIM card services
+ OnSmsReport // Callback function for SMS services
+ };
+ ```
+
+
+1. Create the **g\_reader** main thread to enable message looping.
+
+ ```
+ pthread_attr_t t;
+ pthread_attr_init(&t);
+ pthread_attr_setdetachstate(&t, PTHREAD_CREATE_DETACHED);
+ ret = pthread_create(&g_reader, &t, ReaderLoop, &t); // Create the g_reader thread.
+ ```
+
+
+1. In the **g\_eventListeners** thread, use **open\(\)** to open a modem node and then create the **g\_reader** thread to read and process messages reported by the modem.
+
+ ```
+ g_fd = open(g_devicePath, O_RDWR); // Open the device node specified by g_devicePath.
+ pthread_attr_init(&attr);
+ pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
+ ret = pthread_create(&g_eventListeners, &attr, EventListeners, NULL);
+ ```
+
+
+1. Return the function pointer of the service request API.
+
+ ```
+ // Structure for the service request API of the call module
+ typedef struct {
+ // Obtain the call list.
+ void (*GetCallList)(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ // Make a call.
+ void (*Dial)(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ // Disconnect a call.
+ void (*Hangup)(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ // Reject a call.
+ void (*Reject)(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ // Answer a call.
+ void (*Answer)(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ } HRilCallReq;
+
+ // Callback function pointers of the call module
+ static const HRilCallReq g_callReqOps = {
+ .GetCallList = ReqGetCallList, // Obtain the call list.
+ .Dial = ReqDial, // Make a call.
+ .Hangup = ReqHangup, // Disconnect a call.
+ .Reject = ReqReject, // Reject a call.
+ .Answer = ReqAnswer, // Answer a call.
+ };
+
+ // Service request structure
+ typedef struct {
+ const HRilCallReq *callOps; // Pointer to the structure of call service requests
+ const HRilSimReq *simOps; // Pointer to the structure of SIM card service requests
+ const HRilSmsReq *smsOps; // Pointer to the structure of SMS and MMS service requests
+ const HRilDataReq *dataOps; // Pointer to the structure of cellular data service requests
+ const HRilNetworkReq *networkOps; // Pointer to the structure of network search service requests
+ const HRilModemReq *modemOps; // Pointer to the structure of modem service requests
+ } HRilOps;
+
+ // Service request APIs
+ HRilOps g_hrilOps = {
+ .callOps = &g_callReqOps, // API for call service requests
+ .simOps = &g_simReqOps, // API for SIM card service requests
+ .smsOps = &g_smsReqOps, // API for SMS and MMS service requests
+ .networkOps = &g_networkReqOps, // API for cellular data service requests
+ .dataOps = &g_dataReqOps, // API for network search service requests
+ .modemOps = &g_modemReqOps, // API for modem service requests
+ };
+ ```
+
+
+### Debugging and Verification
+
+1. Use the [hdc\_std](en-us_topic_0000001080478129.md#section05992022154916) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device. For details about how to integrate a library file, see [Integrating Modem Vendor Libraries](#section590mcpsimp).
+
+ ```
+ hdc_std file send libril_vendor.z.so /system/lib/
+ ```
+
+2. Reboot the debugging device.
+
+ ```
+ hdc_std shell sync
+ hdc_std shell reboot
+ ```
+
+3. Run the **hdc\_std shell hilog** command to view the debug log, and check whether the **RilInitOps\(\)** function is successfully executed. The following debug log is for reference:
+
+ ```
+ 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [RilAdapterDispatch-(hril_hdf.c:55)] sbuf IPC obtain test success!
+ 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [LoadVendor-(hril_hdf.c:33)] RilInit rilInit start
+ 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [LoadVendor -(hril_hdf.c:45)] RilInit rilInit completed
+ ```
+
+
+## Responding to Modem Service Requests
+
+### When to Use
+
+After receiving a specific telephony service request, RIL Adapter calls the target function pointer obtained in modem vendor library initialization to send a specific service request to the vendor library. Then, the vendor library processes the request based on the request ID.
+
+### Available APIs
+
+The following table describes the APIs for responding to modem service requests, with the dial module as an example.
+
+**Table 2** APIs for responding to modem service requests
+
+
+API
+ |
+Description
+ |
+
|---|
+
+void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen);
+ |
+Function: Processes number dial requests.
+Input parameters:
+- requestInfo: request type
+
+
+Return value: none
+ |
+
+void (*OnCallReport)(struct ReportInfo reportInfo, const void *data, size_t dataLen);
+ |
+Function: Reports the execution result of a service request to RIL Adapter.
+Input parameters:
+
+
+
+Return value: none
+ |
+
+
+
+
+### How to Develop
+
+1. Implement processing of dial requests in the **ReqDial\(\)** API.
+
+ ```
+ // Implement the API for processing dial requests.
+ void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen)
+ {
+ HRilDial *pDial = NULL;
+ char cmd[MAX_BUFF_SIZE] = {0};
+ const char *clir = NULL;
+ int ret;
+ int err = HRIL_ERR_SUCCESS;
+ struct ReportInfo reportInfo = {};
+ ResponseInfo *pResponse = NULL;
+ if (data == NULL) {
+ TELEPHONY_LOGE("data is null!!!");
+ err = HRIL_ERR_INVALID_PARAMETER;
+ reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0);
+ OnCallReport(reportInfo, NULL, 0);
+ return;
+ }
+ pDial = (HRilDial *)data;
+ switch (pDial->clir) {
+ case CALL_CLIR_INVOCATION:
+ clir = "I";
+ break; /* invocation */
+ case CALL_CLIR_SUPPRESSION:
+ clir = "i";
+ break; /* suppression */
+ case CALL_CLIR_SUBSCRIPTION_DEFUALT:
+ default:
+ clir = "";
+ break; /* subscription default */
+ }
+ (void)sprintf_s(cmd, MAX_BUFF_SIZE, "ATD%s%s;", pDial->address, clir);
+ ret = SendCommandLock(cmd, NULL, 0, &pResponse); // Send the AT command.
+ ......
+ }
+ ```
+
+2. After the modem executes the dial command, report the execution result to RIL Adapter via **OnCallReport\(\)**.
+
+ ```
+ ret = SendCommandLock(cmd, NULL, 0, &pResponse);
+ if (ret != 0 || (pResponse != NULL && pResponse->success == 0)) {
+ TELEPHONY_LOGE("ATD send failed");
+ err = HRIL_ERR_GENERIC_FAILURE;
+ }
+ reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0);
+ OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service.
+ ```
+
+
+### Debugging and Verification
+
+1. Use the [hdc\_std](en-us_topic_0000001080478129.md#section05992022154916) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device.
+
+ ```
+ hdc_std file send libril_vendor.z.so /system/lib/
+ ```
+
+2. Reboot the debugging device.
+
+ ```
+ hdc_std shell sync
+ hdc_std shell reboot
+ ```
+
+3. Run the **hdc\_std shell** command. Then, run the **./system/bin/ril\_adapter\_test** command, type **1**, and enter the phone number as prompted to test the call function.
+
+ ```
+ hdc_std shell
+ # ./system/bin/ril_adapter_test
+ ----> Test Enter --------->Call---------------------
+
+ 1----> RilUnitTest::OnRequestCallDialTest
+ 2----> RilUnitTest:: OnRequestCallHangupTest
+ 3----> RilUnitTest:: OnRequestCallAnswerTest
+ 4----> RilUnitTest::OnRequestCallGetCurrentCallsStatusTest
+ 5----> RilUnitTest::OnRequestRefusedCallTest
+
+ 1
+ ```
+
+4. Open another terminal window, and run the **hdc\_std shell hilog** command. Then, view the log to check whether **ReqDial\(\)** is successfully executed. The following debug log is for reference:
+
+ ```
+ 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [SendCommandLock-(at_support.c:210)] SendCommandLock enter, cmd: ATD17620373527
+ 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [SendCommandLock-(at_support.c:231)] SendCommandLock() command ATD17620373527
+ 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [WriteATCommand-(channel.c:115)] WriteATCommand enter, cmd:ATD17620373527
+ 01-01 05:27:27.421 136 187 D 02b01/Rilvendor: [ReadResponse-(channel.c:94)] g_bufferCur :
+ 01-01 05:27:27.421 136 187 D 02b01/Rilvendor: OK
+ 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:144)] processLine line = OK
+ 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ReadResponse-(channel.c:81)] ReadResponse enter
+ 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ProcessLastResponse-(channel.c:37)] last data more than one line , FindEndOfLine g_bufferCur:
+ 01-01 05:27:27.422 136 187 E 02b01/Rilvendor: [ProcessLastResponse-(channel.c:39)] g_bufferCur endLine is null
+ 01-01 05:27:27.422 136 187 E 02b01/Rilvendor:^ORIG:1,0
+ 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(at_support.c:234)] processLine line = ^ORIG:1,0
+ 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(vendor_report.c:234)] enter to [^ORIG:1,0]: (null)
+ 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(at_support.c:264)] err = 0, cmd:ADT17620373527
+ ```
+
+
+## Reporting Modem Events
+
+### When to Use
+
+A modem node thread reads the messages reported by the modem cyclically, parses the messages into specific events, and then reports the events to RIL Adapter.
+
+### Available APIs
+
+The following table describes the API for reporting modem events.
+
+**Table 3** API for reporting modem events
+
+
+API
+ |
+Description
+ |
+
|---|
+
+void OnNotifyOps(const char *s, const char *smsPdu)
+ |
+Function: Distributes the events reported by the modem.
+Input parameters:
+
+- smsPdu: PDU of the SMS message
+Return value: none
+ |
+
+
+
+
+### How to Develop
+
+1. Call **OnNotifyOps\(\)** in the g\_reader thread of the modem device node to parse reported modem events. On determining the command type, call **OnXxxReport\(\)** to report the parsed module events to the hril layer.
+
+ ```
+ // Parse the data reported by the modem as events proactively reported by the corresponding module.
+ void OnNotifyOps(const char *s, const char *smsPdu)
+ {
+ int ret = 0;
+ struct ReportInfo reportInfo = {0};
+ reportInfo.error = HRIL_ERR_SUCCESS;
+ reportInfo.type = HRIL_NOTIFICATION;
+ if (GetRadioState() == HRIL_RADIO_POWER_STATE_UNAVAILABLE) {
+ return;
+ }
+ TELEPHONY_LOGD("enter to [%{public}s]:%{public}s", s, smsPdu);
+ // Determine the type of the proactively reported events based on the AT command.
+ if (ReportStrWith(s, "+CRING:") || ReportStrWith(s, "RING") || ReportStrWith(s, "IRING") ||
+ ReportStrWith(s, "NO CARRIER") || ReportStrWith(s, "+CCWA") || ReportStrWith(s, "^CCALLSTATE") ||
+ ReportStrWith(s, "^CEND") || ReportStrWith(s, "^CCWA")) {
+ reportInfo.notifyId = HNOTI_CALL_STATE_UPDATED;
+ OnCallReport(reportInfo, NULL, 0);
+ } else if (ReportStrWith(s, "+CMT:")) {
+ reportInfo.notifyId = HNOTI_SMS_NEW_SMS;
+ OnSmsReport(reportInfo, (void *)smsPdu, strlen(smsPdu));
+ }
+ // Report the events of each module to the hril layer.
+ ...
+ }
+ ```
+
+
+1. Distribute the reported events from the **hril** layer to the Telephony Service layer.
+
+ ```
+ // Report the call status proactively.
+ int32_t HRilCall::CallStateUpdated(
+ int32_t slotId, int32_t notifyType, const HRilErrno e, const void *response, size_t responseLen)
+ {
+ struct HdfSBuf *dataSbuf = HdfSBufTypedObtain(SBUF_IPC);
+ if (serviceCallbackNotify_ == nullptr) {
+ TELEPHONY_LOGE("RilAdapter serviceCallbackNotify_ is null");
+ HdfSBufRecycle(dataSbuf);
+ return HDF_FAILURE;
+ }
+ // Distribute events.
+ int32_t ret = serviceCallbackNotify_->dispatcher->Dispatch(
+ serviceCallbackNotify_, HNOTI_CALL_STATE_UPDATED, dataSbuf, nullptr);
+ if (ret != HDF_SUCCESS) {
+ HdfSBufRecycle(dataSbuf);
+ return HDF_FAILURE;
+ }
+ HdfSBufRecycle(dataSbuf);
+ return HDF_SUCCESS;
+ }
+ ```
+
+
+### Debugging and Verification
+
+1. Use the [hdc\_std](en-us_topic_0000001080478129.md#section05992022154916) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device.
+
+ ```
+ hdc_std file send libril_vendor.z.so /system/lib/
+ ```
+
+2. Reboot the debugging device.
+
+ ```
+ hdc_std shell sync
+ hdc_std shell reboot
+ ```
+
+3. Run the **hdc\_std shell** command. Then, run the **./system/bin/ril\_adapter\_test** command, type **1**, and enter the phone number as prompted to test the call function.
+
+ ```
+ hdc_std shell
+ # ./system/bin/ril_adapter_test
+ ----> Test Enter --------->Call---------------------
+
+ 1----> RilUnitTest::OnRequestCallDialTest
+ 2----> RilUnitTest:: OnRequestCallHangupTest
+ 3----> RilUnitTest:: OnRequestCallAnswerTest
+ 4----> RilUnitTest::OnRequestCallGetCurrentCallsStatusTest
+ 5----> RilUnitTest::OnRequestRefusedCallTest
+
+ 1
+ ```
+
+4. Open another terminal window, and run the **hdc\_std shell hilog** command. Then, view the log to check whether **OnNotifyOps\(\)** is successfully executed. The following debug log is for reference:
+
+ ```
+ 01-01 00:08:01.334 546 551 D 02b01/TelRilTest: [DialResponse-(tel_ril_call.cpp:280)] DialResponse --> radioResponseInfo->serial:2, radioResponseInfo->error:0
+ 01-01 00:08:01.334 546 557 D 02b01/TelRilTest: [ProcessEvent-(tel_ril_test.cpp:1262)] TelRilTest::DemoHandler::ProcessEvent --> eventId:101
+ 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:93)] g_bufferCur :
+ 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: ^ORIG:1,0
+ 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:108)] AT< ^ORIG:1,0
+ 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:137)] processLine line = ^ORIG:1,0
+ 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:126)] enter to [^ORIG:1,0]:(null)
+ 01-01 00:08:01.335 143 512 W 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:167)] enter to is unrecognized command: ^ORIG:1,0
+ 01-01 00:08:01.335 143 512 D 02b01/Rilvendor: [ProcessLastResponse-(channel.c:37)] last data more than one line , FindEndOfLine g_bufferCur:
+ 01-01 00:08:01.335 143 512 E 02b01/Rilvendor: [ProcessLastResponse-(channel.c:39)] g_bufferCur endLine is null
+ 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:93)] g_bufferCur :
+ 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: ^CCALLSTATE: 1,0,1
+ 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:108)] AT< ^CCALLSTATE: 1,0,1
+ 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:137)] processLine line = ^CCALLSTATE: 1,0,1
+ 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:126)] enter to [^CCALLSTATE: 1,0,1]:(null)
+ 01-01 00:08:01.336 546 551 D 02b01/CoreService: [OnRemoteRequest-(tel_ril_manager.cpp:80)] RilManager OnRemoteRequest code:1001
+ 01-01 00:08:01.336 546 551 D 02b01/CoreService: [NotifyObserver-(observer_handler.cpp:76)] handler->SendEvent:8
+ ```
+
+
+### Development Examples
+
+- **Outgoing Call**
+
+ The following figure shows the API calling for an outgoing call.
+
+ **Figure 1** Time sequence of API calling for an outgoing call
+
+
+ 
+
+ When an application initiates an outgoing call, RIL Adapter receives a call request, and the **hril** layer invokes the **ReqDial\(\)** function. In **ReqDial\(\)**, the data passed by the Telephony Service is encapsulated as an AT command and sent to the modem. After executing the dial command, the modem reports the execution result to RIL Adapter through **OnCallReport\(\)**.
+
+ ```
+ // Callback function pointer of the call module
+ static const HRilCallReq g_callReqOps = {
+ .GetCallList = ReqGetCallList, // Obtain the call list.
+ .Dial = ReqDial, // Make a call.
+ .Hangup = ReqHangup, // Disconnect a call.
+ .Reject = ReqReject, // Reject a call.
+ .Answer = ReqAnswer, // Answer a call.
+ };
+
+ // Service request APIs
+ HRilOps g_hrilOps = {
+ .callOps = &g_callReqOps, // API for call service requests
+ .simOps = &g_simReqOps, // API for SIM card service requests
+ .smsOps = &g_smsReqOps, // API for SMS and MMS service requests
+ .networkOps = &g_networkReqOps, // API for cellular data service requests
+ .dataOps = &g_dataReqOps, // API for network search service requests
+ .modemOps = &g_modemReqOps, // API for modem service requests
+ };
+
+ // Implement the API for processing dial requests.
+ void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen)
+ {
+ HRilDial *pDial = NULL;
+ char cmd[MAX_BUFF_SIZE] = {0};
+ const char *clir = NULL;
+ int ret;
+ int err = HRIL_ERR_SUCCESS;
+ struct ReportInfo reportInfo = {};
+ ResponseInfo *pResponse = NULL;
+ if (data == NULL) {
+ TELEPHONY_LOGE("data is null!!!");
+ err = HRIL_ERR_INVALID_PARAMETER;
+ reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0);
+ OnCallReport(reportInfo, NULL, 0);
+ return;
+ }
+ pDial = (HRilDial *)data;
+ switch (pDial->clir) {
+ case CALL_CLIR_INVOCATION:
+ clir = "I";
+ break; /* invocation */
+ case CALL_CLIR_SUPPRESSION:
+ clir = "i";
+ break; /* suppression */
+ case CALL_CLIR_SUBSCRIPTION_DEFUALT:
+ default:
+ clir = "";
+ break; /* subscription default */
+ }
+ (void)sprintf_s(cmd, MAX_BUFF_SIZE, "ATD%s%s;", pDial->address, clir);
+ ret = SendCommandLock(cmd, NULL, 0, &pResponse); // Send the AT command.
+ if (ret != 0) {
+ err = HRIL_ERR_CMD_SEND_FAILURE;
+ TELEPHONY_LOGE("ATD send failed");
+ } else {
+ if (pResponse != NULL && pResponse->success == 0) {
+ TELEPHONY_LOGE("ReqDial return ERROR");
+ err = HRIL_ERR_CMD_NO_CARRIER;
+ }
+ }
+ reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0);
+ OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service.
+ FreeResponseInfo(pResponse);
+ }
+ ```
+
+
+- **Incoming Call**
+
+ The following figure shows the API calling of an incoming call.
+
+ **Figure 2** Time sequence of API calling for an incoming call
+
+
+ 
+
+ The **g\_reader** thread cyclically reads the messages reported by the modem. When the modem receives an incoming call event, it actively reports the information about the incoming call.
+
+ The **g\_reader** thread calls **OnNotifyOps\(\)** to parse the reported information. If the parsed data reported by the modem starts with characters such as **+CRING** or **RING**, it indicates that an incoming call event exists. In this case, the event is reported to RIL Adapter through **OnCallReport\(reportInfo, NULL, 0\)**.
+
+ ```
+ // Parse the data reported by the modem as events proactively reported by the corresponding module.
+ void OnNotifyOps(const char *s, const char *smsPdu)
+ {
+ int ret = 0;
+ struct ReportInfo reportInfo = {0};
+ reportInfo.error = HRIL_ERR_SUCCESS;
+ reportInfo.type = HRIL_NOTIFICATION;
+ if (GetRadioState() == HRIL_RADIO_POWER_STATE_UNAVAILABLE) {
+ return;
+ }
+ TELEPHONY_LOGD("enter to [%{public}s]:%{public}s", s, smsPdu);
+ // Determine the type of the proactively reported events based on the AT command.
+ if (ReportStrWith(s, "+CRING:") || ReportStrWith(s, "RING") || ReportStrWith(s, "IRING") ||
+ ReportStrWith(s, "NO CARRIER") || ReportStrWith(s, "+CCWA") || ReportStrWith(s, "^CCALLSTATE") ||
+ ReportStrWith(s, "^CEND") || ReportStrWith(s, "^CCWA")) {
+ reportInfo.notifyId = HNOTI_CALL_STATE_UPDATED;
+ OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service.
+ } else if (ReportStrWith(s, "+CMT:")) {
+ reportInfo.notifyId = HNOTI_SMS_NEW_SMS;
+ OnSmsReport(reportInfo, (void *)smsPdu, strlen(smsPdu));
+ }
+ // add your codes
+ ......
+ }
+ ```
+
+
+## Integrating Modem Vendor Libraries
+
+### Configuring Compilation Information
+
+Compile the modem vendor library into a dynamic library by using **BUILD.gn**. Upon startup, RIL Adapter loads the dynamic library to the system in dlopen mode and then initializes the library. For details about how to implement vendor library initialization, see [Initializing a Modem Vendor Library](#section211mcpsimp). The following is an example of **BUILD.gn**:
+
+```
+import("//build/ohos.gni")
+RIL_ADAPTER = "//base/telephony"
+ohos_shared_library("ril_vendor") { // Modem vendor library
+ sources = [ // Source files to compile
+ "at_call.c",
+ "at_data.c",
+ "xxx.c",
+ ]
+ include_dirs = [ // Header files
+ "$RIL_ADAPTER/ril_adapter/vendor/include",
+ "$RIL_ADAPTER/ril_adapter/interfaces/innerkits",
+ "include",
+ ]
+ deps = [ // Internal dependencies
+ "//drivers/adapter/uhdf2/osal:libhdf_utils",
+ "//base/telephony/core_service/utils:libtelephony_common",
+ ]
+ external_deps = [ "hilog:libhilog" ] // External dependencies
+
+ part_name = "ril_adapter" // Part name
+ subsystem_name = "telephony" // Subsystem name
+}
+```
+
+### Debugging and Verification
+
+1. Compile the code.
+2. Check whether **libril\_vendor.z.so** exists in the **/out/ohos-arm-release/telephony/ril\_adapter** directory. If yes, the integration is successful. Otherwise, correct the error and perform debugging and verification again.
+
diff --git a/en/device-dev/subsystems/figure/The-following-figure-shows-the-context-structure-of-the-Startup-subsystem.png b/en/device-dev/subsystems/figure/The-following-figure-shows-the-context-structure-of-the-Startup-subsystem.png
new file mode 100644
index 0000000000000000000000000000000000000000..10619e78af9ac158497eea260dfdc623788fd810
Binary files /dev/null and b/en/device-dev/subsystems/figure/The-following-figure-shows-the-context-structure-of-the-Startup-subsystem.png differ
diff --git a/en/device-dev/subsystems/figure/en-us_image_0000001171507146.png b/en/device-dev/subsystems/figure/en-us_image_0000001171507146.png
new file mode 100644
index 0000000000000000000000000000000000000000..529f4561b0fa18d68e4463ebc74e6b1911b589c9
Binary files /dev/null and b/en/device-dev/subsystems/figure/en-us_image_0000001171507146.png differ
diff --git a/en/device-dev/subsystems/figure/en-us_image_0000001210683929.png b/en/device-dev/subsystems/figure/en-us_image_0000001210683929.png
new file mode 100644
index 0000000000000000000000000000000000000000..741f53d3654db337ea8bc2bc4ef793e3135c83ee
Binary files /dev/null and b/en/device-dev/subsystems/figure/en-us_image_0000001210683929.png differ
diff --git a/en/device-dev/subsystems/figure/en-us_image_0000001214727595.png b/en/device-dev/subsystems/figure/en-us_image_0000001214727595.png
new file mode 100644
index 0000000000000000000000000000000000000000..5383e32ce2a16c5271debea44f40c6dfb2a79fd1
Binary files /dev/null and b/en/device-dev/subsystems/figure/en-us_image_0000001214727595.png differ
diff --git a/en/device-dev/subsystems/subsys-boot-overview.md b/en/device-dev/subsystems/subsys-boot-overview.md
index 0f33270e686ae27a5218f174960dd9069d35c285..5fe25a4c8d8066041da0b2b5f48590de06bed9df 100644
--- a/en/device-dev/subsystems/subsys-boot-overview.md
+++ b/en/device-dev/subsystems/subsys-boot-overview.md
@@ -7,7 +7,7 @@
The following figure shows the context structure of the Startup subsystem.
-
+
Upon completion of system power-on and kernel loading, system services and applications are started as follows:
@@ -35,7 +35,7 @@ The Startup subsystem consists of the following modules:
- bootstrap module
- This module provides entry identifiers for starting services and features. When samgr is started, the entry function identified by boostrap is called and system services are started.
+ This module provides entry identifiers for starting services and features. When samgr is started, the entry function identified by bootstrap is called and system services are started.
- syspara module
diff --git a/en/device-dev/subsystems/subsys-boot-syspara.md b/en/device-dev/subsystems/subsys-boot-syspara.md
index c0c51a6a8239d9ce6e5ff92c7c5fe42a50ac4e4e..86019f7ae60ec42c9083de6f641d4e55f0e749db 100644
--- a/en/device-dev/subsystems/subsys-boot-syspara.md
+++ b/en/device-dev/subsystems/subsys-boot-syspara.md
@@ -260,7 +260,7 @@ The following table provides the sequence of loading system parameter value defi
|
/vendor/etc/param/*.para
|
-The definition file containing system parameters in the vendor directory is loaded with the secondary priority. It can overwrite the definition file containing system parrameters in the system directory.
+ | The definition file containing system parameters in the vendor directory is loaded with the secondary priority. It can overwrite the definition file containing system parameters in the system directory.
|
|
System parameters in the system directory
diff --git a/en/device-dev/subsystems/subsys-tel.md b/en/device-dev/subsystems/subsys-tel.md
new file mode 100644
index 0000000000000000000000000000000000000000..b99d321dbbd08136cad53418227ef408c23c40ef
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-tel.md
@@ -0,0 +1,6 @@
+# Subsystems
+
+- [Telephony Service](telephony-service.md)
+ - [Telephony Service](telephony-service.md)
+ - [Development Guidelines](development-guidelines.md)
+
diff --git a/en/device-dev/subsystems/telephony-service.md b/en/device-dev/subsystems/telephony-service.md
new file mode 100644
index 0000000000000000000000000000000000000000..f91b93bd849e1074b608d7161196d693d23e88aa
--- /dev/null
+++ b/en/device-dev/subsystems/telephony-service.md
@@ -0,0 +1,46 @@
+# Telephony Service
+
+- [Introduction](#section184mcpsimp)
+- [Basic Concepts](#section187mcpsimp)
+- [Working Principles](#section194mcpsimp)
+- [Constraints](#section205mcpsimp)
+
+## Introduction
+
+This document provides development guidelines related to the telephony subsystem, including modem vendor library integration, initialization, service request responding, and modem event reporting. It is intended as a reference for developers of different modem chips, helping them efficiently develop telephony service-related functions.
+
+## Basic Concepts
+
+- Telephony Service: core service layer of the telephony subsystem. Its main functions are as follows:
+ - Initializes the RIL Manager module, SIM card module, and network search modules.
+ - Provides access to the RIL Adapter service, and implements communication with RIL Adapter by registering the callback service.
+ - Implements communication between modules, such as the call module and SMS module, by subscribing to callbacks.
+
+- RIL Adapter: RIL adaptation layer of the Telephony subsystem. This layer provides functions such as vendor library loading and service API implementation. It shields the differences of modems supplied by different vendors to provide a unified API for the telephony service layer. It communicates with the telephony service layer by registering the Hardware Driver Foundation \(HDF\) service.
+- HDF: Hardware Driver Foundation, which allows for unified access from peripheral devices and provides a framework for driver development and management.
+- hdc\_std: OpenHarmony Device Connector, a command line tool provided by OpenHarmony for developers to debug device connectivity.
+
+## Working Principles
+
+**Figure 1** RIL Adapter architecture
+
+
+
+
+As shown in the preceding figure, RIL Adapter is logically divided into three layers: **hril\_hdf**, **hril**, and **vendorlib**.
+
+- **hril\_hdf**: unique entry of RIL Adapter. The main function of this layer is to load modem vendor library files. Wherein, **modem\_adapter** enables a single firmware to adapt to different modems.
+
+ Specifically, **hril\_hdf** obtains the modem type from the kernel and then loads the target modem vendor library based on the modem type.
+
+- **hril**: OpenHarmony Radio Interface Layer, which provides APIs for communication between the **vendorlib** and various Telephony Service modules, including the SIM card, network search, cellular call, cellular data, and SMS/MMS modules.
+- **vendorlib**: Modem vendor library file. Different modem vendor libraries are developed based on standard APIs or service request IDs provided by RIL Adapter. \(**vendorlib** is provided by modem vendors.\)
+
+After **hril\_hdf** is executed, **vendorlib** is dynamically loaded so that it can obtain the pointers to the response processing and event reporting functions from **hril\_hdf**. After this process is complete, **hril\_hdf** can communicate with a modem through **vendorlib**.
+
+## Constraints
+
+**Specifications**
+
+At least one modem must be supported by a device vendor. If no modem is supported, **vendorlib** APIs do not need to be implemented.
+
diff --git a/en/readme.md b/en/readme.md
index 66043bf4a9e15b055b05dd7d80b524bfa0032faf..8df0f62f265a3f798337e59cb1b802fdc9f4bbc9 100644
--- a/en/readme.md
+++ b/en/readme.md
@@ -49,6 +49,7 @@ This project stores OpenHarmony documentation, including the quick start guide,
- **porting**:
- [Standard System SoC Porting Guide](device-dev/porting/standard-system-porting-guide.md)
+ - [A Method for Rapidly Porting the OpenHarmony Linux Kernel ](device-dev/porting/porting-linux-kernel-overview.md)
- **bundles**:
- [HPM Bundle Development Specifications](device-dev/bundles/bundles-standard-rules.md)
diff --git a/zh-cn/device-dev/guide/oem_wifi_sdk_des.md b/zh-cn/device-dev/guide/oem_wifi_sdk_des.md
index 678a8f2f287387542b48e814888d8676bac99f81..03d75354c30d9f2f2b6ae3642486ad5a98162960 100644
--- a/zh-cn/device-dev/guide/oem_wifi_sdk_des.md
+++ b/zh-cn/device-dev/guide/oem_wifi_sdk_des.md
@@ -101,7 +101,7 @@ OpenHarmony WLAN模组基于Hi3861平台提供了丰富的外设操作能力，
## 验证
-编译过程请参考《[Hi3861快速入门-源码编译](../quick-start/quickstart-lite-steps-hi3861-connection.md#section191121332125319)》，烧录过程请参考《[Hi3861快速入门-镜像烧录](../quick-start/quickstart-lite-steps-hi3861-connection.md#section19458165166)》。
+编译过程请参考《[Hi3861快速入门-源码编译](../quick-start/quickstart-lite-steps-hi3861-connection.md#section191121332125319)》，烧录过程请参考《[Hi3861快速入门-镜像烧录](../quick-start/quickstart-lite-steps-hi3861-connection.md#section3288165814218)》。
完成以上两步后，按下RST键复位模组，可发现LED在周期性闪烁，与预期相符，验证完毕。
|
|
|---|
|