!818 文档更新

Merge pull request !818 from duangavin123/master

en/device-dev/Readme-EN.md

@@ -153,7 +153,7 @@ In addition, OpenHarmony provides a series of optional system components that ca
 </td>
 <td class="cellrowborder" valign="top" width="36.053605360536054%" headers="mcps1.2.4.1.2 "><p id="p185185615284"><a name="p185185615284"></a><a name="p185185615284"></a>Porting and adapting the <span id="text1434016533511"><a name="text1434016533511"></a><a name="text1434016533511"></a>OpenHarmony</span> to a third-party library</p>
 </td>
-<td class="cellrowborder" valign="top" width="36.07360736073608%" headers="mcps1.2.4.1.3 "><a name="ul14724164204819"></a><a name="ul14724164204819"></a><ul id="ul14724164204819"><li><a href="porting/standard-system-porting-guide.md">Standard System SoC Porting Guide</a></li></ul>
+<td class="cellrowborder" valign="top" width="36.07360736073608%" headers="mcps1.2.4.1.3 "><a name="ul14724164204819"></a><a name="ul14724164204819"></a><ul id="ul14724164204819"><li><a href="porting/standard-system-porting-guide.md">Standard System SoC Porting Guide</a></li><li><a href="porting/porting-linux-kernel-overview.md">A Method for Rapidly Porting the OpenHarmony Linux Kernel </a></li></ul>
 </td>
 </tr>
 <tr id="row869853125119"><td class="cellrowborder" valign="top" width="27.872787278727873%" headers="mcps1.2.4.1.1 "><p id="p3691530511"><a name="p3691530511"></a><a name="p3691530511"></a>Contributing components</p>

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)

en/device-dev/driver/driver-develop.md

+# Platform Driver Development<a name="EN-US_TOPIC_0000001160769576"></a>
+
+-   **[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)**  
+
+

en/device-dev/driver/driver-hdf-development.md

@@ -5,12 +5,10 @@
 
 ## Introduction<a name="section157425168112"></a>
 
-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<a name="fig5487113011526"></a>  
-
-
-![](figure/en-us_image_0000001054564784.png)
+**Figure  1**  HDF driver model<a name="fig3580184214210"></a>  
+![](figures/hdf-driver-model.png "hdf-driver-model")
 
 ## How to Develop<a name="section1969312275533"></a>
 
@@ -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.
 

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<a name="section59914284576"></a>
 
@@ -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<a name="fig814111371944"></a>  
-
-
-![](figure/en-us_image_0000001053405727.png)
+**Figure  1**  Configuration process<a name="fig772653312159"></a>  
+![](figures/configuration-process.png "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<a name="section1316625413586"></a>
+### Keywords<a name="section4522107333"></a>
 
 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
 </tbody>
 </table>
 
-## Basic Syntax<a name="section173481622115918"></a>
+### Basic Structures<a name="section853042911312"></a>
 
 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<a name="section96521601302"></a>
+### Data Types<a name="section177001259134"></a>
 
-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<a name="section8164295515"></a>
+### Pre-Processing<a name="section14867121641"></a>
 
 **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<a name="section0338205819610"></a>
+### Comments<a name="section1323412417"></a>
 
 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<a name="section179799204716"></a>
+### Reference Modifications<a name="section193708571145"></a>
 
 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<a name="section382424014712"></a>
+### Node Replication<a name="section1487792020513"></a>
 
 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<a name="section165211112586"></a>
+### Delete<a name="section1096515391155"></a>
 
 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 {
 >![](../public_sys-resources/icon-note.gif) **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<a name="section192841514490"></a>
+### Attribute References<a name="section20271317611"></a>
 
 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<a name="section520134294"></a>
+### Template<a name="section958819191063"></a>
 
 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<a name="section8260625101012"></a>
+### Introduction to hc-gen<a name="section359734416616"></a>
 
 Parameter description:
 

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.

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)**  
 

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<a name="section729758162218"></a>
 
-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<a name="fig967034316227"></a>  
-
+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/en-us_image_0000001170383063.png)
+**Figure  1**  WLAN framework<a name="fig4415112614415"></a>  
+![](figures/wlan-framework.png "wlan-framework")
 
 ### WLAN Driver API Architecture<a name="section178022416377"></a>
 
@@ -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<a name="fig15016395217"></a>  
+**Figure  2**  Available APIs of the WLAN module<a name="fig1492411431166"></a>  
+![](figures/available-apis-of-the-wlan-module.png "available-apis-of-the-wlan-module")
 
-
-![](figure/接口分布图4.png)
-
-### Available APIs<a name="section149681312202415"></a>
+## Available APIs<a name="section7331102018815"></a>
 
 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
 </tbody>
 </table>
 
-## Development Guidelines<a name="section15957746172412"></a>
+## How to Develop<a name="section15957746172412"></a>
 
 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<a name="section11776186132513"></a>
-
 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.

en/device-dev/driver/driver-peripherals-lcd-des.md

 # LCD<a name="EN-US_TOPIC_0000001052857284"></a>
 
 -   [Overview](#section141575391542)
-    -   [API Description](#section14711163785519)
-
--   [Development Guidelines](#section12394223125615)
-    -   [How to Develop](#section515923045814)
-
+-   [API Description](#section53793327396)
+-   [How to Develop](#section12394223125615)
 -   [Development Example](#section7441155155813)
 
 ## Overview<a name="section141575391542"></a>
@@ -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<a name="fig69138814229"></a>  
-![](figure/architecture-of-the-display-driver-model.png "architecture-of-the-display-driver-model")
-
--   **Display driver model**
+![](figures/architecture-of-the-display-driver-model.png "architecture-of-the-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<a name="section14711163785519"></a>
+## API Description<a name="section53793327396"></a>
 
 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<a name="fig6936451331"></a>  
-    ![](figure/mipi-dsi.png "mipi-dsi")
+    ![](figures/mipi-dsi.png "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<a name="fig141611855635"></a>  
-    ![](figure/ttl-interface.png "ttl-interface")
+    ![](figures/ttl-interface.png "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<a name="section12394223125615"></a>
+## How to Develop<a name="section12394223125615"></a>
 
 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<a name="section515923045814"></a>
-
 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:

en/device-dev/driver/driver-peripherals-sensor-des.md

 # Sensor<a name="EN-US_TOPIC_0000001078401780"></a>
 
 -   [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<a name="fig10451455446"></a>  
-![](figure/architecture-of-the-sensor-driver-model.png "architecture-of-the-sensor-driver-model")
+![](figures/architecture-of-the-sensor-driver-model.png "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<a name="section188213414114"></a>
+## Available APIs<a name="section20930112117478"></a>
 
 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<a name="section1140943382"></a>
+## How to Develop<a name="section1140943382"></a>
 
 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<a name="section7893102915819"></a>
-
 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.

en/device-dev/driver/driver-peripherals-touch-des.md

 # TOUCHSCREEN<a name="EN-US_TOPIC_0000001052857350"></a>
 
 -   [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<a name="fig6251184817261"></a>  
-![](figure/architecture-of-the-input-driver-model.png "architecture-of-the-input-driver-model")
+![](figures/architecture-of-the-input-driver-model.png "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<a name="section17667171301711"></a>
+## Available APIs<a name="section105459441659"></a>
 
 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<a name="fig1290384314416"></a>  
-![](figure/common-pins-of-the-touchscreen.png "common-pins-of-the-touchscreen")
+![](figures/common-pins-of-the-touchscreen.png "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<a name="section65745222184"></a>
+## How to Develop<a name="section65745222184"></a>
 
 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<a name="section865734181916"></a>
+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<a name="section263714411191"></a>

en/device-dev/driver/driver-peripherals.md

-# Peripheral Driver Development<a name="EN-US_TOPIC_0000001157319411"></a>
+# Peripheral Driver Usage<a name="EN-US_TOPIC_0000001157319411"></a>
 
 -   **[LCD](driver-peripherals-lcd-des.md)**  
 

en/device-dev/driver/driver-platform-gpio-des.md

-# GPIO<a name="EN-US_TOPIC_0000001051777586"></a>
+# GPIO<a name="EN-US_TOPIC_0000001206171135"></a>
 
 -   [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<a name="section17715915181611"></a>
+## Available APIs<a name="section589913442203"></a>
 
 **Table  1**  APIs available for the GPIO driver
 
-<a name="table1731550155318"></a>
-<table><thead align="left"><tr id="row4419501537"><th class="cellrowborder" valign="top" width="19.74%" id="mcps1.2.4.1.1"><p id="p641050105320"><a name="p641050105320"></a><a name="p641050105320"></a>Capability</p>
+<a name="table89681075215"></a>
+<table><thead align="left"><tr id="row996807162115"><th class="cellrowborder" valign="top" width="19.74%" id="mcps1.2.4.1.1"><p id="p296817716212"><a name="p296817716212"></a><a name="p296817716212"></a>Capability</p>
 </th>
-<th class="cellrowborder" valign="top" width="32.36%" id="mcps1.2.4.1.2"><p id="p54150165315"><a name="p54150165315"></a><a name="p54150165315"></a>Function</p>
+<th class="cellrowborder" valign="top" width="32.36%" id="mcps1.2.4.1.2"><p id="p596897172119"><a name="p596897172119"></a><a name="p596897172119"></a>Function</p>
 </th>
-<th class="cellrowborder" valign="top" width="47.9%" id="mcps1.2.4.1.3"><p id="p941150145313"><a name="p941150145313"></a><a name="p941150145313"></a>Description</p>
+<th class="cellrowborder" valign="top" width="47.9%" id="mcps1.2.4.1.3"><p id="p39681677213"><a name="p39681677213"></a><a name="p39681677213"></a>Description</p>
 </th>
 </tr>
 </thead>
-<tbody><tr id="row34145016535"><td class="cellrowborder" rowspan="2" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p229610227124"><a name="p229610227124"></a><a name="p229610227124"></a>GPIO read/write</p>
+<tbody><tr id="row896847202113"><td class="cellrowborder" rowspan="2" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p1796814719210"><a name="p1796814719210"></a><a name="p1796814719210"></a>GPIO read/write</p>
 </td>
-<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p19389143041518"><a name="p19389143041518"></a><a name="p19389143041518"></a>GpioRead</p>
+<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p39683732112"><a name="p39683732112"></a><a name="p39683732112"></a>GpioRead</p>
 </td>
-<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p8738101941716"><a name="p8738101941716"></a><a name="p8738101941716"></a>Reads the level value of a GPIO pin.</p>
+<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p59687710219"><a name="p59687710219"></a><a name="p59687710219"></a>Reads the level value of a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row5632152611414"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p143890309153"><a name="p143890309153"></a><a name="p143890309153"></a>GpioWrite</p>
+<tr id="row17968872212"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p396812722116"><a name="p396812722116"></a><a name="p396812722116"></a>GpioWrite</p>
 </td>
-<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p67306152404"><a name="p67306152404"></a><a name="p67306152404"></a>Writes the level value of a GPIO pin.</p>
+<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p396814715219"><a name="p396814715219"></a><a name="p396814715219"></a>Writes the level value of a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row17493124814141"><td class="cellrowborder" rowspan="2" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p321814526178"><a name="p321814526178"></a><a name="p321814526178"></a>GPIO settings</p>
+<tr id="row129681576218"><td class="cellrowborder" rowspan="2" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p1496813782116"><a name="p1496813782116"></a><a name="p1496813782116"></a>GPIO settings</p>
 </td>
-<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p16390153015156"><a name="p16390153015156"></a><a name="p16390153015156"></a>GpioSetDir</p>
+<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p29688742119"><a name="p29688742119"></a><a name="p29688742119"></a>GpioSetDir</p>
 </td>
-<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p1873761519408"><a name="p1873761519408"></a><a name="p1873761519408"></a>Sets the direction for a GPIO pin.</p>
+<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p179682792111"><a name="p179682792111"></a><a name="p179682792111"></a>Sets the direction for a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row10681146181417"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p15390153014151"><a name="p15390153014151"></a><a name="p15390153014151"></a>GpioGetDir</p>
+<tr id="row1196817715217"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p896827182120"><a name="p896827182120"></a><a name="p896827182120"></a>GpioGetDir</p>
 </td>
-<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p974061515406"><a name="p974061515406"></a><a name="p974061515406"></a>Obtains the direction for a GPIO pin.</p>
+<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p39689792111"><a name="p39689792111"></a><a name="p39689792111"></a>Obtains the direction for a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row10288191441518"><td class="cellrowborder" rowspan="4" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p13927416134716"><a name="p13927416134716"></a><a name="p13927416134716"></a>GPIO interrupt settings</p>
+<tr id="row69682071217"><td class="cellrowborder" rowspan="4" valign="top" width="19.74%" headers="mcps1.2.4.1.1 "><p id="p296818714213"><a name="p296818714213"></a><a name="p296818714213"></a>GPIO interrupt settings</p>
 </td>
-<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p17390113013158"><a name="p17390113013158"></a><a name="p17390113013158"></a>GpioSetIrq</p>
+<td class="cellrowborder" valign="top" width="32.36%" headers="mcps1.2.4.1.2 "><p id="p1396916710216"><a name="p1396916710216"></a><a name="p1396916710216"></a>GpioSetIrq</p>
 </td>
-<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p10314104354416"><a name="p10314104354416"></a><a name="p10314104354416"></a>Sets the ISR function for a GPIO pin.</p>
+<td class="cellrowborder" valign="top" width="47.9%" headers="mcps1.2.4.1.3 "><p id="p99693712113"><a name="p99693712113"></a><a name="p99693712113"></a>Sets the ISR function for a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row163795912473"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p523618345323"><a name="p523618345323"></a><a name="p523618345323"></a>GpioUnSetIrq</p>
+<tr id="row4969117172110"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p119692079215"><a name="p119692079215"></a><a name="p119692079215"></a>GpioUnSetIrq</p>
 </td>
-<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p1138195912478"><a name="p1138195912478"></a><a name="p1138195912478"></a>Cancels the setting of the ISR function for a GPIO pin.</p>
+<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p1996916792114"><a name="p1996916792114"></a><a name="p1996916792114"></a>Cancels the setting of the ISR function for a GPIO pin.</p>
 </td>
 </tr>
-<tr id="row155161515124816"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p657344273218"><a name="p657344273218"></a><a name="p657344273218"></a>GpioEnableIrq</p>
+<tr id="row396907112117"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p109694717216"><a name="p109694717216"></a><a name="p109694717216"></a>GpioEnableIrq</p>
 </td>
-<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p115163154488"><a name="p115163154488"></a><a name="p115163154488"></a>Enables a GPIO interrupt.</p>
+<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p2969473216"><a name="p2969473216"></a><a name="p2969473216"></a>Enables a GPIO interrupt.</p>
 </td>
 </tr>
-<tr id="row1742119174820"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p1865114616324"><a name="p1865114616324"></a><a name="p1865114616324"></a>GpioDisableIrq</p>
+<tr id="row14969117152113"><td class="cellrowborder" valign="top" headers="mcps1.2.4.1.1 "><p id="p18969157182116"><a name="p18969157182116"></a><a name="p18969157182116"></a>GpioDisableIrq</p>
 </td>
-<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p97421219174820"><a name="p97421219174820"></a><a name="p97421219174820"></a>Disables a GPIO interrupt.</p>
+<td class="cellrowborder" valign="top" headers="mcps1.2.4.1.2 "><p id="p19690710214"><a name="p19690710214"></a><a name="p19690710214"></a>Disables a GPIO interrupt.</p>
 </td>
 </tr>
 </tbody>
@@ -91,12 +90,10 @@ The GPIO APIs define a set of standard functions for performing operations on GP
 
 ### How to Use<a name="section103477714216"></a>
 
-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<a name="fig1399416053717"></a>  
-
+The GPIO APIs use the GPIO pin number to specify a pin.  [Figure 1](#fig16151101653713)  shows the general process of using a GPIO.
 
-![](figure/en-us_image_0000001170187071.png)
+**Figure  1**  Process of using a GPIO<a name="fig16151101653713"></a>  
+![](figures/process-of-using-a-gpio.png "process-of-using-a-gpio")
 
 ### Determining a GPIO Pin Number<a name="section370083272117"></a>
 

en/device-dev/driver/driver-platform-i2c-des.md

-# I2C<a name="EN-US_TOPIC_0000001052778273"></a>
+# I2C<a name="EN-US_TOPIC_0000001206171515"></a>
 
 -   [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<a name="fig1135561232714"></a>  
-    ![](figure/physical-connection-diagram-for-i2c.png "physical-connection-diagram-for-i2c")
+    ![](figures/physical-connection-diagram-for-i2c.png "physical-connection-diagram-for-i2c")
 
 
-### Available APIs<a name="section459052019177"></a>
+## Available APIs<a name="section545869122317"></a>
 
 **Table  1**  APIs available for the I2C driver
 
@@ -70,12 +69,10 @@
 
 ### How to Use<a name="section1338373417288"></a>
 
-[Figure 2](#fig166181128151112)  illustrates the process of an I2C device.
-
-**Figure  2**  Process of using an I2C device<a name="fig166181128151112"></a>  
-
+[Figure 2](#fig183017194234)  illustrates the process of an I2C device.
 
-![](figure/en-us_image_0000001123509750.png)
+**Figure  2**  Process of using an I2C device<a name="fig183017194234"></a>  
+![](figures/process-of-using-an-i2c-device.png "process-of-using-an-i2c-device")
 
 ### Opening an I2C Controller<a name="section13751110132914"></a>
 
@@ -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);

en/device-dev/driver/driver-platform-mipidsi-des.md

-# MIPI DSI<a name="EN-US_TOPIC_0000001062724343"></a>
+# MIPI DSI<a name="EN-US_TOPIC_0000001160971534"></a>
 
 -   [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<a name="fig1122611461203"></a>  
-    ![](figure/dsi-transmitting-and-receiving-interface.png "dsi-transmitting-and-receiving-interface")
+    ![](figures/dsi-transmitting-and-receiving-interface.png "dsi-transmitting-and-receiving-interface")
 
 
-### Available APIs<a name="section129611916132011"></a>
+## Available APIs<a name="section12720125432316"></a>
 
 **Table  1**  APIs for MIPI DSI
 
@@ -94,12 +93,10 @@
 
 ### How to Use<a name="section49299119344"></a>
 
-[Figure 2](#fig99821771782)  shows the process of using a MIPI DSI device.
-
-**Figure  2**  Process of using a MIPI DSI device<a name="fig99821771782"></a>  
-
+[Figure 2](#fig129103491241)  shows the process of using a MIPI DSI device.
 
-![](figure/en-us_image_0000001123514210.png)
+**Figure  2**  Process of using a MIPI DSI device<a name="fig129103491241"></a>  
+![](figures/process-of-using-a-mipi-dsi-device.png "process-of-using-a-mipi-dsi-device")
 
 ### Obtains a MIPI DSI device handle.<a name="section5126155683811"></a>
 

en/device-dev/driver/driver-platform-rtc-des.md

-# RTC<a name="EN-US_TOPIC_0000001051778226"></a>
+# RTC<a name="EN-US_TOPIC_0000001206373007"></a>
 
 -   [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<a name="section3373340142215"></a>
+## Available APIs<a name="section20331159102519"></a>
 
 **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<a name="fig166181128151112"></a>  
-
+[Figure 1](#fig1610020107333)  illustrates the process of using an RTC device.
 
-![](figure/en-us_image_0000001123675706.png)
+**Figure  1**  Process of using an RTC device<a name="fig1610020107333"></a>  
+![](figures/process-of-using-an-rtc-device.png "process-of-using-an-rtc-device")
 
 ### Creating an RTC Device Handle<a name="section1131212144310"></a>
 

en/device-dev/driver/driver-platform-sdio-des.md

-# SDIO<a name="EN-US_TOPIC_0000001053055057"></a>
+# SDIO<a name="EN-US_TOPIC_0000001160653028"></a>
 
 -   [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<a name="fig1185316527498"></a>  
     
 
-    ![](figure/en-us_image_0000001054280608.png)
+    ![](figures/en-us_image_0000001160971556.png)
 
 -   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<a name="section08064247248"></a>
+## Available APIs<a name="section12601496259"></a>
 
 **Table  1**  APIs available for the SDIO driver
 
@@ -170,7 +169,7 @@
 **Figure  2**  Process of using an SDIO<a name="fig1343742311264"></a>  
 
 
-![](figure/en-us_image_0000001123540984.png)
+![](figures/en-us_image_0000001206291517.png)
 
 ### Opening an SDIO Controller<a name="section10782428132616"></a>
 

en/device-dev/driver/driver-platform-spi-des.md

-# SPI<a name="EN-US_TOPIC_0000001053057951"></a>
+# SPI<a name="EN-US_TOPIC_0000001206171293"></a>
 
 -   [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<a name="fig15227181812587"></a>  
-
+-   [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/en-us_image_0000001123742254.png)
+**Figure  1**  SPI controller/device connection<a name="fig89085710359"></a>  
+![](figures/spi-controller-device-connection.png "spi-controller-device-connection")
 
 -   SPI communication is usually initiated by the SPI controller and is operated as follows:
 
@@ -54,7 +51,7 @@
 >![](../public_sys-resources/icon-note.gif) **NOTE:** 
 >Currently, these functions are only applicable in the communication initiated by the SPI controller.
 
-### Available APIs<a name="section232141411476"></a>
+## Available APIs<a name="section1325964832615"></a>
 
 **Table  1**  APIs for the SPI driver
 
@@ -119,12 +116,10 @@
 
 ### How to Use<a name="section32846814820"></a>
 
-[Figure 2](#fig23885455594)  shows the process of using an SPI device.
-
-**Figure  2**  Process of using an SPI device<a name="fig23885455594"></a>  
-
+[Figure 2](#fig1586912310348)  shows the process of using an SPI device.
 
-![](figure/en-us_image_0000001123703482.png)
+**Figure  2**  Process of using an SPI device<a name="fig1586912310348"></a>  
+![](figures/process-of-using-an-spi-device.png "process-of-using-an-spi-device")
 
 ### Obtaining an SPI Device Handle<a name="section1927265711481"></a>
 

en/device-dev/driver/driver-platform-uart-des.md

-# UART<a name="EN-US_TOPIC_0000001052215244"></a>
+# UART<a name="EN-US_TOPIC_0000001160652800"></a>
 
 -   [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<a name="fig209936401896"></a>  
-        
-
-        ![](figure/en-us_image_0000001170262141.png)
-
-        **Figure  2**  4-wire UART communication<a name="fig1435614171015"></a>  
-        
+        **Figure  1**  2-wire UART communication<a name="fig68294715408"></a>  
+        ![](figures/2-wire-uart-communication.png "2-wire-uart-communication")
 
-        ![](figure/en-us_image_0000001123582482.png)
+        **Figure  2**  4-wire UART communication<a name="fig179241542163112"></a>  
+        ![](figures/4-wire-uart-communication.png "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<a name="section1680292311549"></a>
+## Available APIs<a name="section1928742202715"></a>
 
 **Table  1**  APIs for the UART driver
 
@@ -122,12 +117,10 @@
 
 ### How to Use<a name="section1858116395510"></a>
 
-[Figure 3](#fig1852173020185)  shows the process of using a UART device.
-
-**Figure  3**  Process of using a UART device<a name="fig1852173020185"></a>  
-
+[Figure 3](#fig99673244388)  shows the process of using a UART device.
 
-![](figure/en-us_image_0000001170227689.png)
+**Figure  3**  Process of using a UART device<a name="fig99673244388"></a>  
+![](figures/process-of-using-a-uart-device.png "process-of-using-a-uart-device")
 
 ### Obtaining a UART Device Handle<a name="section124512065617"></a>
 

en/device-dev/driver/driver-platform.md

-# Platform Drivers<a name="EN-US_TOPIC_0000001111199424"></a>
+# Platform Driver Usage<a name="EN-US_TOPIC_0000001111199424"></a>
 
 -   **[GPIO](driver-platform-gpio-des.md)**  
 
@@ -16,4 +16,6 @@
 
 -   **[MIPI DSI](driver-platform-mipidsi-des.md)**  
 
+-   **[PWM](driver-platform-pwm-des.md)**  
+