!3249 同步英文到3.1release分支【不需要翻译】

Merge pull request !3249 from duangavin123/OpenHarmony-3.1-Release

en/device-dev/device-dev-guide.md

@@ -40,7 +40,7 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of<br/>&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Mini&nbsp;Systems](kernel/kernel-mini-overview.md)<br/>-&nbsp;[Kernel&nbsp;for&nbsp;Small&nbsp;Systems](kernel/kernel-small-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-mini-lite.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices&nbsp;based<br/>&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[WLAN-connected&nbsp;Products](guide/device-wlan-led-control.md)<br/>-&nbsp;[Cameras&nbsp;Without&nbsp;a&nbsp;Screen](guide/device-iotcamera-control-overview.md)<br/>-&nbsp;[Cameras&nbsp;with&nbsp;a&nbsp;Screen](guide/device-camera-control-overview.md) |
 | Porting&nbsp;and&nbsp;adaptation | -&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the&nbsp;<br/>OpenHarmony&nbsp;to&nbsp;an&nbsp;SoC<br/>-&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a<br/>&nbsp;third-party&nbsp;library | -&nbsp;[Mini&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/oem_transplant_chip_prepare_knows.md)<br/>-&nbsp;[Small&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/porting-smallchip-prepare-needs.md)<br/>-&nbsp;[Third-Party&nbsp;Library&nbsp;Porting&nbsp;Guide&nbsp;for&nbsp;Mini&nbsp;and&nbsp;Small&nbsp;Systems](porting/porting-thirdparty-overview.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) |
 
 
@@ -54,6 +54,6 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Standard&nbsp;Systems](kernel/kernel-standard-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-standard-large.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices<br/>&nbsp;based&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[Development&nbsp;Guidelines&nbsp;on&nbsp;Clock&nbsp;Apps](guide/device-clock-guide.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Platform&nbsp;Drivers](guide/device-driver-demo.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Peripheral&nbsp;Drivers](guide/device-outerdriver-demo.md) |
 | Porting&nbsp;and&nbsp;adaptation | Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a&nbsp;third-party&nbsp;library | -&nbsp;[Standard&nbsp;System&nbsp;Porting&nbsp;Guide](porting/standard-system-porting-guide.md)<br/>-&nbsp;[A&nbsp;Method&nbsp;for&nbsp;Rapidly&nbsp;Porting&nbsp;the&nbsp;OpenHarmony&nbsp;Linux&nbsp;Kernel](porting/porting-linux-kernel.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) 
 

en/device-dev/driver/Readme-EN.md

@@ -9,6 +9,7 @@
   - [HDF Development Example](driver-hdf-sample.md)
 - [Platform Driver Development](driver-develop.md)
   - [ADC](driver-platform-adc-develop.md)
+  - [DAC](driver-platform-dac-develop.md)
   - [GPIO](driver-platform-gpio-develop.md)
   - [HDMI](driver-platform-hdmi-develop.md)
   - [I2C](driver-platform-i2c-develop.md)
@@ -26,12 +27,14 @@
   - [Watchdog](driver-platform-watchdog-develop.md)
 - [Platform Driver Usage](driver-platform.md)
   - [ADC](driver-platform-adc-des.md)
+  - [DAC](driver-platform-dac-des.md)
   - [GPIO](driver-platform-gpio-des.md)
   - [HDMI](driver-platform-hdmi-des.md)
   - [I2C](driver-platform-i2c-des.md)
   - [I3C](driver-platform-i3c-des.md)
   - [MIPI CSI](driver-platform-mipicsi-des.md)
   - [MIPI DSI](driver-platform-mipidsi-des.md)
+  - [Pin](driver-platform-pin-des.md)
   - [PWM](driver-platform-pwm-des.md)
   - [Regulator](driver-platform-regulator-des.md)
   - [RTC](driver-platform-rtc-des.md)
@@ -46,4 +49,6 @@
   - [WLAN](driver-peripherals-external-des.md)
   - [Audio](driver-peripherals-audio-des.md)
   - [USB](driver-peripherals-usb-des.md)
-  - [Camera](driver-peripherals-camera-des.md)
\ No newline at end of file
+  - [Camera](driver-peripherals-camera-des.md)
+  - [Vibrator](driver-peripherals-vibrator-des.md)
+  - [Light](driver-peripherals-light-des.md)
\ No newline at end of file

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

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-develop.md)**  
 
+-   **[DAC](driver-platform-dac-develop.md)**  
+
 -   **[GPIO](driver-platform-gpio-develop.md)**  
 
 -   **[HDMI](driver-platform-hdmi-develop.md)**

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

@@ -159,9 +159,9 @@ The following example shows code for developing an LCD driver:
 #define HORIZONTAL_BACK_PORCH     20
 #define HORIZONTAL_FRONT_PORCH    20
 #define HORIZONTAL_SYNC_WIDTH     10
-#define VERTIACL_BACK_PORCH       14
-#define VERTIACL_FRONT_PORCH      16
-#define VERTIACL_SYNC_WIDTH       2
+#define VERTICAL_BACK_PORCH       14
+#define VERTICAL_FRONT_PORCH      16
+#define VERTICAL_SYNC_WIDTH       2
 #define FRAME_RATE                60
 
 /* PanelInfo structure */
@@ -300,9 +300,9 @@ static struct PanelInfo g_panelInfo = {
     .hbp = HORIZONTAL_BACK_PORCH,       /* horizontal back porch */
     .hfp = HORIZONTAL_FRONT_PORCH,      /* horizontal front porch */
     .hsw = HORIZONTAL_SYNC_WIDTH,       /* horizontal sync width */
-    .vbp = VERTIACL_BACK_PORCH,         /* vertiacl back porch */
-    .vfp = VERTIACL_FRONT_PORCH,        /* vertiacl front porch */
-    .vsw = VERTIACL_SYNC_WIDTH,         /* vertiacl sync width */
+    .vbp = VERTICAL_BACK_PORCH,         /* vertical back porch */
+    .vfp = VERTICAL_FRONT_PORCH,        /* vertical front porch */
+    .vsw = VERTICAL_SYNC_WIDTH,         /* vertical sync width */
     .frameRate = FRAME_RATE,            /* frame rate */
     .intfType = MIPI_DSI,               /* panel interface type */
     .intfSync = OUTPUT_USER,            /* output timming type */

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

@@ -148,7 +148,7 @@ The light driver model provides APIs to obtain information about all the lights
          HdfWorkDestroy(&drvData->work);
          HdfWorkQueueDestroy(&drvData->workQueue);
          (void)OsalMutexDestroy(&drvData->mutex);
-         (void)OsalMemFree(drvData);
+         OsalMemFree(drvData);
          g_lightDrvData = NULL;
      }
      ```

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

 # Sensor
-  
+ 
 
 ## Overview
 
@@ -7,7 +7,8 @@
 
 The sensor driver model masks the sensor hardware differences and provides interfaces for the upper-layer sensor service to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data changes, and setting sensor options. The model is developed on the Hardware Driver Foundation (HDF), Operating System Abstraction Layer (OSAL), and platform driver interfaces (such as the I2C, SPI, and UART buses). It provides functionalities such as cross-OS migration and differentiated device configurations. The figure below shows the architecture of the sensor driver model.
 
-**Figure 1** Sensor driver model 
+**Figure 1** Sensor driver model
+ 
 ![Sensor driver model](figures/sensor_driver_model.png)
 
 ### Basic Concepts
@@ -44,12 +45,12 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen
 ### When to Use
 
 - Data provided by the gravity and gyroscope sensors denotes the tilt and rotation of the device, which helps your application improve user experience in games.
-- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This can further reduce power consumption.
+- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This prevents the screen from being accidentally touched and further reduces power consumption.
 - Data provided by the barometric pressure sensor helps your application accurately determine the altitude of the device.
 - Data provided by the ambient light sensor helps your device automatically adjust its backlight.
 - Data provided by the Hall effect sensor implements the smart cover mode of your device. When the smart cover is closed, a small window is opened on the phone to reduce power consumption. 
 
-### Available APIs<a name="section188213414114"></a>
+### Available APIs
 
 The sensor driver model offers the following APIs:
 
@@ -61,7 +62,7 @@ The sensor driver model offers the following APIs:
 
 The sensor driver model provides APIs for the hardware service to make sensor service development easier. See the table below.
 
-**Table 1** APIs for the members in the PinCntlrMethod structure
+**Table 1** APIs of the sensor driver model
 
 | API| Description| 
 | ----- | -------- |
@@ -111,9 +112,9 @@ The sensor driver model also provides certain driver development APIs that need
 | void ReadSensorData(void) | Reads sensor data.|
 
 
-For details about the interface implementation, see [How to Develop](#section7893102915819).
+For details about the interface implementation, see "How to Develop" below.
 
-### How to Develop<a name="section7893102915819"></a>
+### How to Develop
 1. Develop the acceleration sensor abstract driver. Specifically, implement the **Bind**, **Init**, **Release**, and **Dispatch** functions.
 
    - Implement the entry function for the acceleration sensor.
@@ -513,12 +514,11 @@ For details about the interface implementation, see [How to Develop](#section789
 
 >![](../public_sys-resources/icon-note.gif) **NOTE**
 >
->- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see [Table 2](#table1156812588320).
->
->- You need to implement the following functions: certain sensor operation interfaces (listed in [Table 3](#table1083014911336)) and sensor chipset HCS configuration.
-> - You also need to verify basic driver functions.
+>- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see Table 2.
+>- You need to implement the following functions: certain sensor operation interfaces (listed in Table 3) and sensor chipset HCS configuration.
+>- You also need to verify basic driver functions.
 
-### Commissioning and Verifying<a name="section106021256121219"></a>
+### How to Verify
 
 After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. Use the developer self-test platform as the test environment.
 
@@ -545,7 +545,7 @@ void HdfSensorTest::SetUpTestCase()
 {
     g_sensorDev = NewSensorInterfaceInstance();
     if (g_sensorDev == nullptr) {
-        printf("test sensorHdi get Module instace failed\n\r");
+        printf("test sensorHdi get Module instance failed\n\r");
     }
 }
 /* Release case resources. */

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

+# DAC
+
+
+## Overview
+
+### DAC
+
+A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics.
+
+The DAC APIs provide a set of methods for DAC data transfer, including:
+
+- Opening or closing a DAC device
+- Setting the target digital-to-analog (DA) value
+
+
+### Basic Concepts
+
+The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies.
+
+- Resolution
+
+  The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution.
+
+- Conversion precision
+
+  Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused.
+
+- Conversion speed
+
+  The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed.
+  
+  The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages.
+  
+  The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number.
+
+### Working Principles
+
+In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode.
+
+The DAC module is divided into the following layers:
+- The interface layer provides APIs for opening or closing a device and writing data.
+- The core layer provides the capabilities of binding, initializing, and releasing devices.
+- The adaptation layer implements other functions.
+
+![](../public_sys-resources/icon-note.gif)NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
+
+**Figure 1** Unified service mode
+
+![](figures/unified-service-mode.png "DAC-unified-service-mode")
+
+### Constraints
+
+ Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems.
+
+## Development Guidelines
+
+### When to Use
+
+ The DAC module converts digital signals into analog signals in the form of current, voltage, or charge. It is mainly used in audio devices. Audio players and headsets use the DAC module as the digital-to-analog conversion channels.
+
+### Available APIs
+
+The table below describes the APIs of the DAC module. For more details, see API Reference.
+
+**Table 1** DAC driver APIs
+
+| API                                                     | Description        |
+| :------------------------------------------------------------| :------------ |
+| DevHandle DacOpen(uint32_t number)                           | Opens a DAC device. |
+| void DacClose(DevHandle handle)                              | Closes a DAC device. |
+| int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val) | Sets the target DA value. |
+
+### How to Develop
+
+The figure below illustrates the process of using a DAC device.
+
+**Figure 2** Process of using a DAC device
+ 
+![](figures/process-of-using-DAC.png "Process of using a DAC")
+
+#### Opening a DAC Device
+
+Call **DacOpen()** to open a DAC device before performing the DA conversion.
+
+```
+DevHandle DacOpen(uint32_t number);
+```
+
+**Table 2** Description of DacOpen
+
+| **Parameter**      | Description         |
+| ---------- | ----------------- |
+| number     | DAC device number.        |
+| **Return Value**| **Description**   |
+| NULL       | Failed to open the DAC device.  |
+| Device handle  | Handle of the DAC device opened.|
+
+
+
+Open device 1 of the two ADC devices (numbered 0 and 1) in the system.
+
+```
+DevHandle dacHandle = NULL; /* DAC device handle /
+
+/* Open the DAC device. */
+dacHandle = DacOpen(1);
+if (dacHandle == NULL) {
+    HDF_LOGE("DacOpen: failed\n");
+    return;
+}
+```
+
+#### Setting the Target DA Value
+
+```
+int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val);
+```
+
+**Table 3** Description of DacWrite
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| channel    | DAC channel number. |
+| val        | DA value to set.    |
+| **Return Value**| **Description**|
+| 0          | The operation is successful.      |
+| Negative value      | The operation failed.      |
+
+```
+/* Write the target DA value through the DAC_CHANNEL_NUM channel. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+```
+
+#### Closing a DAC Device
+
+After the DAC communication is complete, call **DacClose()** to close the DAC device.
+```
+void DacClose(DevHandle handle);
+```
+
+**Table 4** Description of DacClose
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| **Return Value**| **Description**|
+| void       | -            |
+
+
+
+Example:
+
+```
+DacClose(dacHandle); /* Close the DAC device. */
+```
+
+## Development Example
+
+The procedure is as follows:
+
+1. Open the DAC device based on the device number and obtain the device handle.
+2. Set the DA value. If the operation fails, close the device handle.
+3. Close the DAC device handle if the access to the DAC is complete.
+
+You can obtain the operation result by printing the log information based on the **val**.
+
+```
+#include "hdmi_if.h"          /* Header file for DAC APIs */
+#include "hdf_log.h"         /* Header file for log APIs */
+
+/* Define device 0, channel 1. */
+#define DAC_DEVICE_NUM 0
+#define DAC_CHANNEL_NUM 1
+
+/* Main entry of DAC routines. */
+static int32_t TestCaseDac(void)
+{
+    // Set the target DA value.
+    uint32_t val = 2;
+    int32_t ret;
+    DevHandle dacHandle;
+
+    /* Open the DAC device. */
+    dacHandle = DacOpen(DAC_DEVICE_NUM);
+    if (dacHandle == NULL) {
+        HDF_LOGE("%s: Open DAC%u fail!", __func__, DAC_DEVICE_NUM);
+        return -1;
+    }
+
+    /* Write data. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+
+    /* Close the DAC device. */
+    DacClose(dacHandle);
+
+    return 0;
+}
+```

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

@@ -225,7 +225,7 @@ if (ret != 2) {
 }
 ```
 
->![](./public_sys-resources/icon-caution.gif) **Caution**
+>![](../public_sys-resources/icon-caution.gif) **Caution**
 >
 >-   The device address in the **I3cMsg** structure does not contain the read/write flag bit. The read/write information is passed by the read/write control bit in the member variable **flags**.
 >-   The **I3cTransfer()** function does not limit the number of message structures or the length of data in each message structure. The I3C controller determines these two limits.

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

@@ -164,9 +164,9 @@ The I3C module adaptation involves the following steps:
     
         ```c
         struct VirtualI3cCntlr {
-            struct AdcDevice device;// (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
+            struct I3cCntlr cntlr;   // (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
             volatile unsigned char *regBase;// (Mandatory) Register base address.
-            uint32_t regBasePhy; // (Mandatory) Physical base address of the register.
+            uint32_t regBasePhy;     // (Mandatory) Physical base address of the register.
             uint32_t regSize;        // (Mandatory) Bit width of the register.
             uint16_t busId;          // (Mandatory) Device number.
             uint16_t busMode;

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

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-des.md)**  
 
+-   **[DAC](driver-platform-dac-des.md)**  
+
 -   **[GPIO](driver-platform-gpio-des.md)**  
 
 -   **[HDMI](driver-platform-hdmi-des.md)**  
@@ -14,6 +16,8 @@
 
 -   **[MIPI DSI](driver-platform-mipidsi-des.md)**  
 
+-   **[Pin](driver-platform-pin-des.md)**
+
 -   **[PWM](driver-platform-pwm-des.md)**  
 
 -   **[RTC](driver-platform-rtc-des.md)**  

en/device-dev/get-code/Readme-EN.md

 # Source Code Acquisition
 
-- [Source Code Acquisition](sourcecode-acquire.md)
-- [Tool Acquisition](gettools.md)
-  - [Docker Environment](gettools-acquire.md)
-  - [IDE](gettools-ide.md)
-
+- [Obtaining Source Code](sourcecode-acquire.md)
+- Obtaining Tools
+    - [Overview](gettools-overview.md)
+    - [Docker Environments](gettools-acquire.md)
+    - [IDE](gettools-ide.md)

en/device-dev/get-code/gettools-acquire.md

@@ -166,7 +166,7 @@ Files generated during building are stored in the  **out/{device_name}/**  direc
 
 ## HPM-based Docker Environment<a name="section485713518337"></a>
 
-**docker\_dist**  is a template component in the  [HPM](https://hpm.harmonyos.com/#/en/home)  system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and [hpm-cli](../bundles/hpm-part-development.md) development environments, perform the following steps to access the Docker environment:
+**docker\_dist**  is a template component in the  [HPM](https://hpm.harmonyos.com/#/en/home)  system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and hpm-cli development environments, perform the following steps to access the Docker environment:
 
 ### Setting Up the Docker Environment<a name="section3295842510"></a>
 

en/device-dev/get-code/gettools-ide.md

-# IDE<a name="EN-US_TOPIC_0000001128361880"></a>
+# IDE
 
-## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)<a name="section2452141120244"></a>
+## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)
 
 HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE\) provided to develop applications for OpenHarmony devices. It allows on-demand customization of OpenHarmony components, code editing, building, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see  [HUAWEI DevEco Device Tool](https://device.harmonyos.com/en/ide)  and  [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
 
-The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below.
 
-![](figure/evolution-roadmap.png)
+## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
 
-## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)<a name="section0904101019258"></a>
-
-HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see  [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio)  and  [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387).
+HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see  [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio)  and  [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-deveco-studio-overview-0000001263280421).