diff --git a/en/device-dev/driver/Readme-EN.md b/en/device-dev/driver/Readme-EN.md
index 18678440ad06c989d251367330af5c65e8d93a59..74bbfd98ee953e2de921c20acd52e4f144975c16 100644
--- a/en/device-dev/driver/Readme-EN.md
+++ b/en/device-dev/driver/Readme-EN.md
@@ -8,66 +8,19 @@
- [Driver Configuration Management](driver-configuration-management.md)
- [HDF Development Example](hdfdevelopment-example.md)
-- [Driver Platform](driver-platform.md)
+- [Platform Drivers](platform-drivers.md)
- [GPIO](gpio.md)
- - [GPIO Overview](gpiooverview.md)
- - [GPIO Usage Guidelines](gpiousage-guidelines.md)
- - [GPIO Usage Example](gpiousage-example.md)
-
- [I2C](i2c.md)
- - [I2C Overview](i2c-overview.md)
- - [I2C Usage Guidelines](i2c-usage-guidelines.md)
- - [I2C Usage Example](i2c-usage-example.md)
-
- [RTC](rtc.md)
- - [RTC Overview](rtc-overview.md)
- - [RTC Usage Guidelines](rtc-usage-guidelines.md)
- - [RTC Usage Example](rtc-usage-example.md)
-
- [SDIO](sdio.md)
- - [SDIO Overview](sdiooverview.md)
- - [SDIO Usage Guidelines](sdiousage-guidelines.md)
- - [SDIO Usage Example](sdiousage-example.md)
-
- [SPI](spi.md)
- - [SPI Overview](spioverview.md)
- - [SPI Usage Guidelines](spiusage-guidelines.md)
- - [SPI Usage Example](spiusage-example.md)
-
- [UART](uart.md)
- - [UART Overview](uartoverview.md)
- - [UART Usage Guidelines](uartusage-guidelines.md)
- - [UART Usage Example](uartusage-example.md)
-
- - [WATCHDOG](watchdog.md)
- - [Watchdog Overview](watchdogoverview.md)
- - [Watchdog Usage Guidelines](watchdogusage-guidelines.md)
- - [Watchdog Usage Example](watchdogusage-example.md)
-
+ - [Watchdog](watchdog.md)
- [MIPI DSI](mipi-dsi.md)
- - [MIPI DSI Overview](mipi-dsi-overview.md)
- - [Usage Guidelines](usage-guidelines.md)
- - [Usage Example](usage-example.md)
- [Peripherals](peripherals.md)
- [LCD](lcd.md)
- - [LCD Overview](lcdoverview.md)
- - [LCD Development Guidelines](lcddevelopment-guidelines.md)
- - [LCD Development Example](lcddevelopment-example.md)
-
- [TOUCHSCREEN](touchscreen.md)
- - [Touchscreen Overview](touchscreenoverview.md)
- - [Touchscreen Development Guidelines](touchscreendevelopment-guidelines.md)
- - [Touchscreen Development Example](touchscreendevelopment-example.md)
-
- - [SENSOR](sensor.md)
- - [Sensor Driver Overview](sensor-driver-overview.md)
- - [Sensor Driver Development Guidelines](sensor-driver-development-guidelines.md)
- - [Sensor Driver Development Example](sensor-driver-development-example.md)
- - [Sensor Driver Test Guidelines](sensor-driver-test-guidelines.md)
-
+ - [Sensor](sensor.md)
- [WLAN](wlan.md)
- - [WLAN Overview](wlanoverview.md)
- - [WLAN Development Guidelines](wlandevelopment-guidelines.md)
- - [WLAN Development Example](wlandevelopment-example.md)
diff --git a/en/device-dev/driver/driver-development.md b/en/device-dev/driver/driver-development.md
index f9c14ec11f06e6f5c5448751c6967e3de0dac1fa..20f2b610b30401be941e55fd4e4c90669112f07b 100644
--- a/en/device-dev/driver/driver-development.md
+++ b/en/device-dev/driver/driver-development.md
@@ -5,9 +5,9 @@
## 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. The following figure shows the HDF driver management 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](#fig5487113011526) shows the HDF driver model.
-**Figure 1** HDF driver management model
+**Figure 1** HDF driver model

@@ -24,9 +24,9 @@ Driver development based on the HDF consists of two parts: driver implementation
```
#include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver.
- #include "hdf_log.h" // Header file of the log interface provided by the HDF.
+ #include "hdf_log.h" // Header file that describes the log APIs provided by the HDF.
- #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If the tag is not specified, HDF_TAG is used by default.
+ #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used.
// The driver service interface must be bound to the HDF for you to use the service capability.
int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject)
@@ -123,7 +123,7 @@ Driver development based on the HDF consists of two parts: driver implementation
device0 :: deviceNode { // DeviceNode of the sample driver
policy = 1; // Driver service release policy. For details, see section Driver Service Management.
priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random.
- preload = 0; // On-demand driver loading. For details, see "NOTE" at the end of this section.
+ preload = 0; // On-demand loading of the driver. For details, see "NOTE" at the end of this section.
permission = 0664; // Permission for the driver to create device nodes.
moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure.
serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique.
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057902344.png b/en/device-dev/driver/figures/en-us_image_0000001123509750.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057902344.png
rename to en/device-dev/driver/figures/en-us_image_0000001123509750.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001072553354.png b/en/device-dev/driver/figures/en-us_image_0000001123514210.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001072553354.png
rename to en/device-dev/driver/figures/en-us_image_0000001123514210.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054440624.png b/en/device-dev/driver/figures/en-us_image_0000001123540984.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054440624.png
rename to en/device-dev/driver/figures/en-us_image_0000001123540984.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054007499.png b/en/device-dev/driver/figures/en-us_image_0000001123582482.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054007499.png
rename to en/device-dev/driver/figures/en-us_image_0000001123582482.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054728498.png b/en/device-dev/driver/figures/en-us_image_0000001123675706.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054728498.png
rename to en/device-dev/driver/figures/en-us_image_0000001123675706.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054726248.png b/en/device-dev/driver/figures/en-us_image_0000001123703482.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054726248.png
rename to en/device-dev/driver/figures/en-us_image_0000001123703482.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054142582.png b/en/device-dev/driver/figures/en-us_image_0000001123742254.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054142582.png
rename to en/device-dev/driver/figures/en-us_image_0000001123742254.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057342245.png b/en/device-dev/driver/figures/en-us_image_0000001170187071.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057342245.png
rename to en/device-dev/driver/figures/en-us_image_0000001170187071.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054006983.png b/en/device-dev/driver/figures/en-us_image_0000001170227689.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054006983.png
rename to en/device-dev/driver/figures/en-us_image_0000001170227689.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057622716.png b/en/device-dev/driver/figures/en-us_image_0000001170229891.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057622716.png
rename to en/device-dev/driver/figures/en-us_image_0000001170229891.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001053926237.png b/en/device-dev/driver/figures/en-us_image_0000001170262141.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001053926237.png
rename to en/device-dev/driver/figures/en-us_image_0000001170262141.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001055299108.png b/en/device-dev/driver/figures/en-us_image_0000001170383063.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001055299108.png
rename to en/device-dev/driver/figures/en-us_image_0000001170383063.png
diff --git a/en/device-dev/driver/gpio.md b/en/device-dev/driver/gpio.md
index a35dc16408feb1ef8d9c6b7ad878a8d99d00fea6..e8f0e7c2075fed687c1f7af2117c6020d6d468a0 100644
--- a/en/device-dev/driver/gpio.md
+++ b/en/device-dev/driver/gpio.md
@@ -1,9 +1,560 @@
-# GPIO
+# GPIO
-- **[GPIO Overview](gpiooverview.md)**
+- [Overview](#section1635911016188)
+ - [Available APIs](#section17715915181611)
-- **[GPIO Usage Guidelines](gpiousage-guidelines.md)**
+- [Usage Guidelines](#section259614242196)
+ - [How to Use](#section103477714216)
+ - [Determining a GPIO Pin Number](#section370083272117)
+ - [Using APIs to Operate GPIO Pins](#section13604050132118)
-- **[GPIO Usage Example](gpiousage-example.md)**
+- [Usage Example](#section25941262111)
+## Overview
+
+Generally, a general-purpose input/output \(GPIO\) controller manages all GPIO pins by group. Each group of GPIO pins is associated with one or more registers. The GPIO pins are operated by reading data from and writing data to the registers.
+
+The GPIO APIs define a set of standard functions for performing operations on GPIO pins, including:
+
+- Setting the pin direction, which can be input or output \(High impedance is not supported currently.\)
+
+- Reading and writing level values, which can be low or high
+- Setting an interrupt service routine \(ISR\) function and interrupt trigger mode for a pin
+- Enabling or disabling a pin interrupt
+
+### Available APIs
+
+**Table 1** APIs available for the GPIO driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
GPIO read/write
+
+
GpioRead
+
+
Reads the level value of a GPIO pin.
+
+
+
GpioWrite
+
+
Writes the level value of a GPIO pin.
+
+
+
GPIO settings
+
+
GpioSetDir
+
+
Sets the direction for a GPIO pin.
+
+
+
GpioGetDir
+
+
Obtains the direction for a GPIO pin.
+
+
+
GPIO interrupt settings
+
+
GpioSetIrq
+
+
Sets the ISR function for a GPIO pin.
+
+
+
GpioUnSetIrq
+
+
Cancels the setting of the ISR function for a GPIO pin.
+
+
+
GpioEnableIrq
+
+
Enables a GPIO interrupt.
+
+
+
GpioDisableIrq
+
+
Disables a GPIO interrupt.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### 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
+
+
+
+
+### Determining a GPIO Pin Number
+
+The method for converting GPIO pin numbers varies according to the GPIO controller model, parameters, and controller driver of different system on chips \(SoCs\).
+
+- Hi3516DV300
+
+ A controller manages 12 groups of GPIO pins. Each group contains 8 GPIO pins.
+
+ GPIO pin number = GPIO group index \(0-11\) x Number of GPIO pins in each group \(8\) + Offset in the group
+
+ Example: GPIO number of GPIO10\_3 = 10 x 8 + 3 = 83
+
+- Hi3518EV300
+
+ A controller manages 10 groups of GPIO pins. Each group contains 10 GPIO pins.
+
+ GPIO pin number = GPIO group index \(0–9\) x Number of GPIO pins in each group \(10\) + Offset in the group
+
+ Example: GPIO pin number of GPIO7\_3 = 7 x 10 + 3 = 73
+
+
+### Using APIs to Operate GPIO Pins
+
+- Set the direction for a GPIO pin.
+
+ Before performing read/write operations on a GPIO pin, call the following function to set the direction:
+
+ int32\_t GpioSetDir\(uint16\_t gpio, uint16\_t dir\);
+
+ **Table 2** Description of GpioSetDir
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
dir
+
+
Direction to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the direction for a GPIO pin.
+
+
+
Negative value
+
+
Failed to set the direction for a GPIO pin.
+
+
+
+
+
+
+- Read or write the level value for a GPIO pin.
+
+ To read the level value of a GPIO pin, call the following function:
+
+ int32\_t GpioRead\(uint16\_t gpio, uint16\_t \*val\);
+
+ **Table 3** Description of GpioRead
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
val
+
+
Pointer to the level value.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in reading the level value.
+
+
+
Negative value
+
+
Failed to read the level value.
+
+
+
+
+
+ To write the level value for a GPIO pin, call the following function:
+
+ int32\_t GpioWrite\(uint16\_t gpio, uint16\_t val\);
+
+ **Table 4** Description of GpioWrite
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
val
+
+
Level value to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing the level value.
+
+
+
Negative value
+
+
Failed to write the level value.
+
+
+
+
+
+ Example:
+
+ ```
+ int32_t ret;
+ uint16_t val;
+ /* Set the output direction for GPIO3. */
+ ret = GpioSetDir(3, GPIO_DIR_OUT);
+ if (ret != 0) {
+ HDF_LOGE("GpioSerDir: failed, ret %d\n", ret);
+ return;
+ }
+ /* Write the low level GPIO_VAL_LOW for GPIO3. */
+ ret = GpioWrite(3, GPIO_VAL_LOW);
+ if (ret != 0) {
+ HDF_LOGE("GpioWrite: failed, ret %d\n", ret);
+ return;
+ }
+ /* Set the input direction for GPIO6. */
+ ret = GpioSetDir(6, GPIO_DIR_IN);
+ if (ret != 0) {
+ HDF_LOGE("GpioSetDir: failed, ret %d\n", ret);
+ return;
+ }
+ /* Read the level value of GPIO6. */
+ ret = GpioRead(6, &val);
+ ```
+
+
+- Set the ISR function for a GPIO pin.
+
+ To set the ISR function for a GPIO pin, call the following function:
+
+ int32\_t GpioSetIrq\(uint16\_t gpio, uint16\_t mode, GpioIrqFunc func, void \*arg\);
+
+ **Table 5** Description of GpioSetIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
mode
+
+
Interrupt trigger mode.
+
+
+
func
+
+
ISR function to set.
+
+
+
arg
+
+
Pointer to the parameters passed to the ISR function.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the ISR function for a GPIO pin.
+
+
+
Negative value
+
+
Failed to set the ISR function for a GPIO pin.
+
+
+
+
+
+ > **CAUTION:**
+ >Only one ISR function can be set for a GPIO pin at a time. If **GpioSetIrq** is called repeatedly, the previous IRS function will be replaced.
+
+ If the ISR function is no longer required, call the following function to cancel the setting:
+
+ int32\_t GpioUnSetIrq\(uint16\_t gpio\);
+
+ **Table 6** Description of GpioUnSetIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in canceling the ISR function.
+
+
+
Negative value
+
+
Failed to cancel the ISR function.
+
+
+
+
+
+ After the ISR function is set, call the following function to enable a GPIO interrupt:
+
+ int32\_t GpioEnableIrq\(uint16\_t gpio\);
+
+ **Table 7** Description of GpioEnableIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in enabling a GPIO interrupt.
+
+
+
Negative value
+
+
Failed to enable a GPIO interrupt.
+
+
+
+
+
+ > **CAUTION:**
+ >The configured ISR function can be responded only after the GPIO interrupt is enabled.
+
+ Use the following function to disable the GPIO interrupt:
+
+ int32\_t GpioDisableIrq\(uint16\_t gpio\);
+
+ **Table 8** Description of GpioDisableIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in disabling a GPIO interrupt.
+
+
+
Negative value
+
+
Failed to disable a GPIO interrupt.
+
+
+
+
+
+ Example:
+
+ ```
+ /* ISR function */
+ */
+ int32_t MyCallBackFunc(uint16_t gpio, void *data)
+ {
+ HDF_LOGI("%s: gpio:%u interrupt service in! data=%p\n", __func__, gpio, data);
+ return 0;
+ }
+
+ int32_t ret;
+ /* Set the ISR function to MyCallBackFunc, the parameter to NULL, and the interrupt trigger mode to rising edge. */
+ ret = GpioSetIrq(3, OSAL_IRQF_TRIGGER_RISING, MyCallBackFunc, NULL);
+ if (ret != 0) {
+ HDF_LOGE("GpioSetIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Enable an interrupt for GPIO3. */
+ ret = GpioEnableIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioEnableIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Disable the interrupt for GPIO3. */
+ ret = GpioDisableIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioDisableIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Cancel the ISR function for GPIO3. */
+ ret = GpioUnSetIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioUnSetIrq: failed, ret %d\n", ret);
+ return;
+ }
+ ```
+
+
+## Usage Example
+
+In this example, we test the interrupt trigger of a GPIO pin as follows: Set the ISR function for the pin, set the trigger mode to rising edge and failing edge, write high and low levels to the pin alternately to generate level fluctuation, and observe the execution of the ISR function.
+
+Select an idle GPIO pin. This example uses a Hi3516D V300 development board and GPIO pin GPIO10\_3, which is numbered GPIO83.
+
+You can select an idle GPIO pin based on the development board and schematic diagram.
+
+```
+#include "gpio_if.h"
+#include "hdf_log.h"
+#include "osal_irq.h"
+#include "osal_time.h"
+
+static uint32_t g_irqCnt;
+
+/* ISR function */
+static int32_t TestCaseGpioIrqHandler(uint16_t gpio, void *data)
+{
+ HDF_LOGE("%s: irq triggered! on gpio:%u, data=%p", __func__, gpio, data);
+ g_irqCnt++; /* If the ISR function is triggered, the number of global interrupts is incremented by 1. */
+ return GpioDisableIrq(gpio);
+}
+
+/* Test case function */
+static int32_t TestCaseGpioIrqEdge(void)
+{
+ int32_t ret;
+ uint16_t valRead;
+ uint16_t mode;
+ uint16_t gpio = 83; /* Number of the GPIO pin to test */
+ uint32_t timeout;
+
+ /* Set the output direction for the pin. */
+ ret = GpioSetDir(gpio, GPIO_DIR_OUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set dir fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Disable the interrupt of the pin. */
+ ret = GpioDisableIrq(gpio);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: disable irq fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Set the ISR function for the pin. The trigger mode is both rising edge and falling edge. */
+ mode = OSAL_IRQF_TRIGGER_RISING | OSAL_IRQF_TRIGGER_FALLING;
+ HDF_LOGE("%s: mode:%0x\n", __func__, mode);
+ ret = GpioSetIrq(gpio, mode, TestCaseGpioIrqHandler, NULL);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set irq fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Enable the interrupt for this pin. */
+ ret = GpioEnableIrq(gpio);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: enable irq fail! ret:%d\n", __func__, ret);
+ (void)GpioUnSetIrq(gpio);
+ return ret;
+ }
+
+ g_irqCnt = 0; /* Reset the global counter. */
+ timeout = 0; /* Reset the waiting time. */
+ /* Wait for the ISR function of this pin to trigger. The timeout duration is 1000 ms. */
+ while (g_irqCnt <= 0 && timeout < 1000) {
+ (void)GpioRead(gpio, &valRead);
+ (void)GpioWrite(gpio, (valRead == GPIO_VAL_LOW) ? GPIO_VAL_HIGH : GPIO_VAL_LOW);
+ HDF_LOGE("%s: wait irq timeout:%u\n", __func__, timeout);
+ OsalMDelay(200); /* wait for irq trigger */
+ timeout += 200;
+ }
+ (void)GpioUnSetIrq(gpio);
+ return (g_irqCnt > 0) ? HDF_SUCCESS : HDF_FAILURE;
+}
+```
diff --git a/en/device-dev/driver/gpiooverview.md b/en/device-dev/driver/gpiooverview.md
deleted file mode 100644
index a05df150d2b1b166350337754bb024e4d58e7e67..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiooverview.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# GPIO Overview
-
-- [Introduction](#section15318165672215)
-- [Available APIs](#section18977142162418)
-
-## Introduction
-
-GPIO is short for general-purpose input/output. Generally, a GPIO controller manages all GPIO pins by group. Each group of GPIO pins is associated with one or more registers. The GPIO pins are operated by reading data from and writing data to the registers.
-
-The GPIO APIs define a set of standard functions for performing operations on GPIO pins, including:
-
-- Setting the pin direction, which can be input or output \(High impedance is not supported currently.\)
-
-- Reading and writing level values, which can be low or high
-- Setting an interrupt service routine \(ISR\) function and interrupt trigger mode for a pin
-- Enabling or disabling a pin interrupt
-
-## Available APIs
-
-**Table 1** APIs available for the GPIO driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
GPIO read/write
-
-
GpioRead
-
-
Reads the level value of a GPIO pin.
-
-
-
GpioWrite
-
-
Writes the level value of a GPIO pin.
-
-
-
GPIO settings
-
-
GpioSetDir
-
-
Sets the direction for a GPIO pin.
-
-
-
GpioGetDir
-
-
Obtains the direction for a GPIO pin.
-
-
-
GPIO interrupt settings
-
-
-
-
-
GpioSetIrq
-
-
Sets the ISR function for a GPIO pin.
-
-
-
GpioUnSetIrq
-
-
Cancels the setting of the ISR function for a GPIO pin.
-
-
-
GpioEnableIrq
-
-
Enables a GPIO interrupt.
-
-
-
GpioDisableIrq
-
-
Disables a GPIO interrupt.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/gpiousage-example.md b/en/device-dev/driver/gpiousage-example.md
deleted file mode 100644
index bfdb21eed1d8feece2e48d130b8d0cea1ae17a58..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiousage-example.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# GPIO Usage Example
-
-In this example, we test the interrupt trigger of a GPIO pin as follows: Set the ISR function for the pin, set the trigger mode to rising edge and failing edge, write high and low levels to the pin alternately to generate level fluctuation, and observe the execution of the ISR function.
-
-Select an idle GPIO pin. This example uses a Hi3516D V300 development board and GPIO pin GPIO10\_3, which is numbered GPIO83.
-
-You can select an idle GPIO pin based on the development board and schematic diagram.
-
-```
-#include "gpio_if.h"
-#include "hdf_log.h"
-#include "osal_irq.h"
-#include "osal_time.h"
-
-static uint32_t g_irqCnt;
-
-/* ISR function */
-static int32_t TestCaseGpioIrqHandler(uint16_t gpio, void *data)
-{
- HDF_LOGE("%s: irq triggered! on gpio:%u, data=%p", __func__, gpio, data);
- g_irqCnt++; /* If the ISR function is triggered, the number of global interrupts is incremented by 1. */
- return GpioDisableIrq(gpio);
-}
-
-/* Test case function */
-static int32_t TestCaseGpioIrqEdge(void)
-{
- int32_t ret;
- uint16_t valRead;
- uint16_t mode;
- uint16_t gpio = 83; /* Number of the GPIO pin to test */
- uint32_t timeout;
-
- /* Set the output direction for the pin. */
- ret = GpioSetDir(gpio, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set dir fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Disable the interrupt of the pin. */
- ret = GpioDisableIrq(gpio);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: disable irq fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Set the ISR function for the pin. The trigger mode is both rising edge and falling edge. */
- mode = OSAL_IRQF_TRIGGER_RISING | OSAL_IRQF_TRIGGER_FALLING;
- HDF_LOGE("%s: mode:%0x\n", __func__, mode);
- ret = GpioSetIrq(gpio, mode, TestCaseGpioIrqHandler, NULL);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set irq fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Enable the interrupt for this pin. */
- ret = GpioEnableIrq(gpio);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: enable irq fail! ret:%d\n", __func__, ret);
- (void)GpioUnSetIrq(gpio);
- return ret;
- }
-
- g_irqCnt = 0; /* Reset the global counter. */
- timeout = 0; /* Reset the waiting time. */
- /* Wait for the ISR function of this pin to trigger. The timeout duration is 1000 ms. */
- while (g_irqCnt <= 0 && timeout < 1000) {
- (void)GpioRead(gpio, &valRead);
- (void)GpioWrite(gpio, (valRead == GPIO_VAL_LOW) ? GPIO_VAL_HIGH : GPIO_VAL_LOW);
- HDF_LOGE("%s: wait irq timeout:%u\n", __func__, timeout);
- OsalMDelay(200); /* wait for irq trigger */
- timeout += 200;
- }
- (void)GpioUnSetIrq(gpio);
- return (g_irqCnt > 0) ? HDF_SUCCESS : HDF_FAILURE;
-}
-```
-
diff --git a/en/device-dev/driver/gpiousage-guidelines.md b/en/device-dev/driver/gpiousage-guidelines.md
deleted file mode 100644
index 67c29e26454fde7b66ef285e993d01d08f09d8ba..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiousage-guidelines.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# GPIO Usage Guidelines
-
-- [How to Use](#section1583613406410)
-- [Determining a GPIO Pin Number](#section135943361443)
-- [Using APIs to Operate GPIO Pins](#section69151114115315)
-
-## 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
-
-
-
-
-## Determining a GPIO Pin Number
-
-The method for converting GPIO pin numbers varies according to the GPIO controller model, parameters, and controller driver of different system on chips \(SoCs\).
-
-- Hi3516D V300
-
- A controller manages 12 groups of GPIO pins. Each group contains 8 GPIO pins.
-
- GPIO pin number = GPIO group index \(0-11\) x Number of GPIO pins in each group \(8\) + Offset in the group
-
- Example: GPIO number of GPIO10\_3 = 10 x 8 + 3 = 83
-
-- Hi3518E V300
-
- A controller manages 10 groups of GPIO pins. Each group contains 10 GPIO pins.
-
- GPIO pin number = GPIO group index \(0–9\) x Number of GPIO pins in each group \(10\) + Offset in the group
-
- Example: GPIO pin number of GPIO7\_3 = 7 x 10 + 3 = 73
-
-
-## Using APIs to Operate GPIO Pins
-
-- Set the direction for a GPIO pin.
-
- Before performing read/write operations on a GPIO pin, call the following function to set the direction:
-
- int32\_t GpioSetDir\(uint16\_t gpio, uint16\_t dir\);
-
- **Table 1** Description of GpioSetDir
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
dir
-
-
Direction to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The setting is successful.
-
-
-
Negative value
-
-
The setting failed.
-
-
-
-
-
-- Read or write the level value for a GPIO pin.
-
- To read the level value of a GPIO pin, call the following function:
-
- int32\_t GpioRead\(uint16\_t gpio, uint16\_t \*val\);
-
- **Table 2** Description of GpioRead
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
val
-
-
Pointer to the level value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in reading the level value.
-
-
-
Negative value
-
-
Failed to read the level value.
-
-
-
-
-
- To write the level value for a GPIO pin, call the following function:
-
- int32\_t GpioWrite\(uint16\_t gpio, uint16\_t val\);
-
- **Table 3** Description of GpioWrite
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
val
-
-
Level value to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing the level value.
-
-
-
Negative value
-
-
Failed to write the level value.
-
-
-
-
-
- Example:
-
- ```
- int32_t ret;
- uint16_t val;
- /* Set the output direction for GPIO3. */
- ret = GpioSetDir(3, GPIO_DIR_OUT);
- if (ret != 0) {
- HDF_LOGE("GpioSerDir: failed, ret %d\n", ret);
- return;
- }
- /* Write the low level GPIO_VAL_LOW for GPIO3. */
- ret = GpioWrite(3, GPIO_VAL_LOW);
- if (ret != 0) {
- HDF_LOGE("GpioWrite: failed, ret %d\n", ret);
- return;
- }
- /* Set the input direction for GPIO6. */
- ret = GpioSetDir(6, GPIO_DIR_IN);
- if (ret != 0) {
- HDF_LOGE("GpioSetDir: failed, ret %d\n", ret);
- return;
- }
- /* Read the level value of GPIO6. */
- ret = GpioRead(6, &val);
- ```
-
-
-- Set the ISR function for a GPIO pin.
-
- To set the ISR function for a GPIO pin, call the following function:
-
- int32\_t GpioSetIrq\(uint16\_t gpio, uint16\_t mode, GpioIrqFunc func, void \*arg\);
-
- **Table 4** Description of GpioSetIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
mode
-
-
Interrupt trigger mode.
-
-
-
func
-
-
ISR function to set.
-
-
-
arg
-
-
Pointer to the parameters passed to the ISR function.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The setting is successful.
-
-
-
Negative value
-
-
The setting failed.
-
-
-
-
-
- > **CAUTION:**
- >Only one ISR function can be set for a GPIO pin at a time. If **GpioSetIrq** is called repeatedly, the previous IRS function will be replaced.
-
- If the ISR function is no longer required, call the following function to cancel the setting:
-
- int32\_t GpioUnSetIrq\(uint16\_t gpio\);
-
- **Table 5** Description of GpioUnSetIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The ISR function is canceled.
-
-
-
Negative value
-
-
Failed to cancel the ISR function.
-
-
-
-
-
- After the ISR function is set, call the following function to enable a GPIO interrupt:
-
- int32\_t GpioEnableIrq\(uint16\_t gpio\);
-
- **Table 6** Description of GpioEnableIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The GPIO interrupt is enabled.
-
-
-
Negative value
-
-
Failed to enable a GPIO interrupt.
-
-
-
-
-
- > **CAUTION:**
- >The configured ISR function can be responded only after the ISR function is enabled.
-
- Use the following function to disable the GPIO interrupt:
-
- int32\_t GpioDisableIrq\(uint16\_t gpio\);
-
- **Table 7** Description of GpioDisableIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The GPIO interrupt is disabled.
-
-
-
Negative value
-
-
Failed to disable the GPIO interrupt.
-
-
-
-
-
- Example:
-
- ```
- /* ISR function */
- */
- int32_t MyCallBackFunc(uint16_t gpio, void *data)
- {
- HDF_LOGI("%s: gpio:%u interrupt service in! data=%p\n", __func__, gpio, data);
- return 0;
- }
-
- int32_t ret;
- /* Set the ISR function to MyCallBackFunc, the parameter to NULL, and the interrupt trigger mode to rising edge. */
- ret = GpioSetIrq(3, OSAL_IRQF_TRIGGER_RISING, MyCallBackFunc, NULL);
- if (ret != 0) {
- HDF_LOGE("GpioSetIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Enable an interrupt for GPIO3. */
- ret = GpioEnableIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioEnableIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Disable the interrupt for GPIO3. */
- ret = GpioDisableIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioDisableIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Cancel the ISR function for GPIO3. */
- ret = GpioUnSetIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioUnSetIrq: failed, ret %d\n", ret);
- return;
- }
- ```
-
-
diff --git a/en/device-dev/driver/i2c-overview.md b/en/device-dev/driver/i2c-overview.md
deleted file mode 100644
index 407a149be21029b30d63559117a93b846ce70c00..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-overview.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# I2C Overview
-
-- [Introduction](#section5361140416)
-- [Available APIs](#section7606310210)
-
-## Introduction
-
-- The Inter-Integrated Circuit \(I2C\) is a simple, bidirectional, and synchronous serial bus that uses merely two wires.
-- In an I2C communication, one controller communicates with one or more devices through the serial data line \(SDA\) and serial clock line \(SCL\), as shown in [Figure 1](#fig1135561232714).
-
-- I2C data transfer must begin with a **START** condition and end with a **STOP** condition. Data is transmitted byte-by-byte from the most significant bit to the least significant bit.
-- Each I2C node is recognized by a unique address and can serve as either a controller or a device. When the controller needs to communicate with a device, it writes the device address to the bus through broadcast. A device matching this address sends a response to set up a data transfer channel.
-
-- The I2C APIs define a set of common functions for I2C data transfer, including:
-
- - I2C controller management: opening or closing an I2C controller
- - I2C message transfer: custom transfer by using a message array
-
- **Figure 1** Physical connection diagram for I2C
- 
-
-
-## Available APIs
-
-**Table 1** APIs available for the I2C driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
I2C controller management
-
-
I2cOpen
-
-
Opens an I2C controller.
-
-
-
I2cClose
-
-
Closes an I2C controller.
-
-
-
I2C message transfer
-
-
I2cTransfer
-
-
Performs a custom transfer.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/i2c-usage-example.md b/en/device-dev/driver/i2c-usage-example.md
deleted file mode 100644
index 438961611a6aba9bcb7e9a89617650a63e7dcd36..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-usage-example.md
+++ /dev/null
@@ -1,192 +0,0 @@
-# I2C Usage Example
-
-This example describes how to use I2C APIs by using an I2C device on a development board.
-
-This example shows a simple register read/write operation on TouchPad on a Hi3516D V300 development board. The basic hardware information is as follows:
-
-- SoC: hi3516dv300
-
-- Touch IC: The I2C address is 0x38, and the bit width of Touch IC's internal register is 1 byte.
-
-- Schematic diagram: TouchPad is mounted to I2C controller 3. The reset pin of Touch IC is GPIO3.
-
-In this example, first we reset Touch IC. \(The development board supplies power to Touch IC by default after being powered on, and this use case does not consider the power supply\). Then, we perform a read/wirte operation on an internal register to test whether the I2C channel is normal.
-
-> **NOTE:**
->The example focuses on I2C device access and verifies the I2C channel. The read and write values of the device register are not concerned. The behavior caused by the read and write operations on the register is determined by the device itself.
-
-Example:
-
-```
-#include "i2c_if.h" /* Header file of I2C APIs */
-#include "gpio_if.h" /* Header file of GPIO APIs */
-#include "hdf_log.h" /* Header file for log APIs */
-#include "osal_io.h" /* Header file of I/O read and write APIs */
-#include "osal_time.h" /* Header file of delay and sleep APIs */
-
-/* Define a TP device structure to store I2C and GPIO hardware information. */
-struct TpI2cDevice {
- uint16_t rstGpio; /* Reset pin */
- uint16_t busId; /* I2C bus ID */
- uint16_t addr; /* I2C device address */
- uint16_t regLen; /* Register bit width */
- DevHandle i2cHandle; /* I2C controller handle */
-};
-
-/* I2C pin I/O configuration. For details, see the SoC register manual. */
-#define I2C3_DATA_REG_ADDR 0x112f008c /* Address of the SDA pin configuration register of I2C controller 3
-#define I2C3_CLK_REG_ADDR 0x112f0090 /* Address of the SCL pin configuration register of I2C controller 3
-#define I2C_REG_CFG 0x5f1 /* Configuration values of SDA and SCL pins of I2C controller 3
-
-static void TpSocIoCfg(void)
-{
- /* Set the I/O function of the two pins corresponding to I2C controller 3 to I2C. */
- OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_DATA_REG_ADDR));
- OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_CLK_REG_ADDR));
-}
-
-/* Initialize the reset pin of the TP. Pull up the pin for 20 ms, pull down the pin for 50 ms, and then pull up the pin for 20 ms to complete the resetting. */
-static int32_t TestCaseGpioInit(struct TpI2cDevice *tpDevice)
-{
- int32_t ret;
-
- /* Set the output direction for the reset pin. */
- ret = GpioSetDir(tpDevice->rstGpio, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst dir fail!:%d", __func__, ret);
- return ret;
- }
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst hight fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(20);
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_LOW);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst low fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(50);
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst high fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(20);
-
- return HDF_SUCCESS;
-}
-
-/* Use I2cTransfer to encapsulate a register read/write auxiliary function. Use flag to indicate the read or write operation. */
-static int TpI2cReadWrite(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen, uint8_t flag)
-{
- int index = 0;
- unsigned char regBuf[4] = {0};
- struct I2cMsg msgs[2] = {0};
-
- /* Perform length adaptation for the single- or dual-byte register. */
- if (tpDevice->regLen == 1) {
- regBuf[index++] = regAddr & 0xFF;
- } else {
- regBuf[index++] = (regAddr >> 8) & 0xFF;
- regBuf[index++] = regAddr & 0xFF;
- }
-
- /* Fill in the I2cMsg message structure. */
- msgs[0].addr = tpDevice->addr;
- msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
- msgs[0].len = tpDevice->regLen;
- msgs[0].buf = regBuf;
-
- msgs[1].addr = tpDevice->addr;
- msgs[1].flags = (flag == 1)? I2C_FLAG_READ: 0; /* Add the read flag. */
- msgs[1].len = dataLen;
- msgs[1].buf = regData;
-
- if (I2cTransfer(tpDevice->i2cHandle, msgs, 2) != 2) {
- HDF_LOGE("%s: i2c read err", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-/* TP register read function */
-static inline int TpI2cReadReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen)
-{
- return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 1);
-}
-
-/* TP register write function */
-static inline int TpI2cWriteReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen)
-{
- return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 0);
-}
-
-/* Main entry of I2C */
-static int32_t TestCaseI2c(void)
-{
- int32_t i;
- int32_t ret;
- unsigned char bufWrite[7] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xA, 0xB, 0xC };
- unsigned char bufRead[7] = {0};
- static struct TpI2cDevice tpDevice;
-
- /* I/O pin function configuration */
- TpSocIoCfg();
-
- /* Initialize TP device information. */
- tpDevice.rstGpio = 3;
- tpDevice.busId = 3;
- tpDevice.addr = 0x38;
- tpDevice.regLen = 1;
- tpDevice.i2cHandle = NULL;
-
- /* Initialize the GPIO pin. */
- ret = TestCaseGpioInit(&tpDevice);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: gpio init fail!:%d", __func__, ret);
- return ret;
- }
-
- /* Open an I2C controller. */
- tpDevice.i2cHandle = I2cOpen(tpDevice.busId);
- if (tpDevice.i2cHandle == NULL) {
- HDF_LOGE("%s: Open I2c:%u fail!", __func__, tpDevice.busId);
- return -1;
- }
-
- /* Continuously write 7-byte data to register 0xD5 of TP-IC. */
- ret = TpI2cWriteReg(&tpDevice, 0xD5, bufWrite, 7);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: tp i2c write reg fail!:%d", __func__, ret);
- I2cClose(tpDevice.i2cHandle);
- return -1;
- }
- OsalMSleep(10);
-
- /* Continuously read 7-byte data from register 0xDO of TP-IC. */
- ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret);
- I2cClose(tpDevice.i2cHandle);
- return -1;
- }
-
- HDF_LOGE("%s: tp i2c write&read reg success!", __func__);
- for (i = 0; i < 7; i++) {
- HDF_LOGE("%s: bufRead[%d] = 0x%x", __func__, i, bufRead[i]);
- }
-
- /* Close the I2C controller. */
- I2cClose(tpDevice.i2cHandle);
- return ret;
-}
-```
-
diff --git a/en/device-dev/driver/i2c-usage-guidelines.md b/en/device-dev/driver/i2c-usage-guidelines.md
deleted file mode 100644
index 9a207bcc3878e779d7345ae5b14b18b0b4cdc46b..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-usage-guidelines.md
+++ /dev/null
@@ -1,171 +0,0 @@
-# I2C Usage Guidelines
-
-- [How to Use](#section333203315215)
-- [Opening an I2C Controller](#section123631358135713)
-- [Performing I2C Communication](#section11091522125812)
-- [Closing an I2C Controller](#section13519505589)
-
-## How to Use
-
-[Figure 1](#fig166181128151112) illustrates the process of an I2C device.
-
-**Figure 1** Process of using an I2C device
-
-
-
-
-## Opening an I2C Controller
-
-Call the following function to open an I2C controller:
-
-DevHandle I2cOpen\(int16\_t number\);
-
-**Table 1** Description of I2cOpen
-
-
-
Parameter
-
-
Description
-
-
-
-
number
-
-
I2C controller ID.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to open the I2C controller.
-
-
-
Device handle
-
-
Handle of the I2C controller.
-
-
-
-
-
-This example assumes that the system has eight I2C controllers \(numbered from 0 to 7\) and I2C controller 3 is to open.
-
-```
-DevHandle i2cHandle = NULL; /* I2C controller handle */
-
-/* Open an I2C controller. */
-i2cHandle = I2cOpen(3);
-if (i2cHandle == NULL) {
- HDF_LOGE("I2cOpen: failed\n");
- return;
-}
-```
-
-## Performing I2C Communication
-
-Use the following function for message transfer:
-
-int32\_t I2cTransfer\(DevHandle handle, struct I2cMsg \*msgs, int16\_t count\);
-
-**Table 2** Description of I2cTransfer
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Handle of an I2C controller.
-
-
-
msgs
-
-
Message array of the data to transfer.
-
-
-
count
-
-
Length of the message array.
-
-
-
Return Value
-
-
Description
-
-
-
Positive integer
-
-
Number of message structures that are successfully transmitted.
-
-
-
Negative value
-
-
Failed to perform the message transfer.
-
-
-
-
-
-The type of an I2C message transfer is defined by **I2cMsg**. Each message structure indicates a read or write operation. Multiple read or write operations can be performed by using a message array.
-
-```
-int32_t ret;
-uint8_t wbuff[2] = { 0x12, 0x13 };
-uint8_t rbuff[2] = { 0 };
-struct I2cMsg msgs[2]; /* Custom message array for transfer */
-msgs[0].buf = wbuff; /* Data to write */
-msgs[0].len = 2; /* The length of the data to write is 2. */
-msgs[0].addr = 0x5A; /* The address of the device to write the data is 0x5A. */
-msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
-msgs[1].buf = rbuff; /* Data to read */
-msgs[1].len = 2; /* The length of the data to read is 2. */
-msgs[1].addr = 0x5A; /* The address of the device to read the data is 0x5A. */
-msgs[1].flags = I2C_FLAG_READ /* I2C_FLAG_READ is configured, indicating the read operation. */
-/* Perform a custom transfer to transfer two messages. */
-ret = I2cTransfer(i2cHandle, msgs, 2);
-if (ret != 2) {
- HDF_LOGE("I2cTransfer: failed, ret %d\n", ret);
- return;
-}
-```
-
-> **CAUTION:**
->- The device address in the **I2cMsg** structure does not contain the read/write flag bit. The read/write information is transferred by the read/write control bit in the member variable **flags**.
->- The **I2cTransfer** function does not limit the number of message structures, which is determined by the I2C controller.
->- The **I2cTransfer** function does not limit the data length of each message structure, which is determined by the I2C controller.
->- The **I2cTransfer** function may cause the system to sleep and therefore cannot be invoked in the interrupt context.
-
-## Closing an I2C Controller
-
-Call the following function to close the I2C controller after the communication is complete:
-
-void I2cClose\(DevHandle handle\);
-
-**Table 3** Description of I2cClose
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Handle of an I2C controller.
-
-
-
-
-
-```
-I2cClose(i2cHandle); /* Close the I2C controller. */
-```
-
diff --git a/en/device-dev/driver/i2c.md b/en/device-dev/driver/i2c.md
index 12167aeab9625b16e078335a504c96cf4cfe8422..98c3ddc01c9caffa5f46ba74ff859b805c6e48a8 100644
--- a/en/device-dev/driver/i2c.md
+++ b/en/device-dev/driver/i2c.md
@@ -1,9 +1,426 @@
-# I2C
+# I2C
-- **[I2C Overview](i2c-overview.md)**
+- [Overview](#section5361140416)
+ - [Available APIs](#section459052019177)
-- **[I2C Usage Guidelines](i2c-usage-guidelines.md)**
+- [Usage Guidelines](#section1695201514281)
+ - [How to Use](#section1338373417288)
+ - [Opening an I2C Controller](#section13751110132914)
+ - [Performing I2C Communication](#section9202183372916)
+ - [Closing an I2C Controller](#section19481164133018)
-- **[I2C Usage Example](i2c-usage-example.md)**
+- [Usage Example](#section5302202015300)
+## Overview
+
+- The Inter-Integrated Circuit \(I2C\) is a simple, bidirectional, and synchronous serial bus that uses merely two wires.
+- In an I2C communication, one controller communicates with one or more devices through the serial data line \(SDA\) and serial clock line \(SCL\), as shown in [Figure 1](#fig1135561232714).
+
+- I2C data transfer must begin with a **START** condition and end with a **STOP** condition. Data is transmitted byte-by-byte from the most significant bit to the least significant bit.
+- Each I2C node is recognized by a unique address and can serve as either a controller or a device. When the controller needs to communicate with a device, it writes the device address to the bus through broadcast. A device matching this address sends a response to set up a data transfer channel.
+
+- The I2C APIs define a set of common functions for I2C data transfer, including:
+
+ - I2C controller management: opening or closing an I2C controller
+ - I2C message transfer: custom transfer by using a message array
+
+ **Figure 1** Physical connection diagram for I2C
+ 
+
+
+### Available APIs
+
+**Table 1** APIs available for the I2C driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
I2C controller management
+
+
I2cOpen
+
+
Opens an I2C controller.
+
+
+
I2cClose
+
+
Closes an I2C controller.
+
+
+
I2C message transfer
+
+
I2cTransfer
+
+
Performs a custom transfer.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig166181128151112) illustrates the process of an I2C device.
+
+**Figure 2** Process of using an I2C device
+
+
+
+
+### Opening an I2C Controller
+
+Call the following function to open an I2C controller:
+
+DevHandle I2cOpen\(int16\_t number\);
+
+**Table 2** Description of I2cOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
number
+
+
I2C controller ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to open the I2C controller.
+
+
+
Device handle
+
+
Handle of the I2C controller.
+
+
+
+
+
+This example assumes that the system has eight I2C controllers \(numbered from 0 to 7\) and I2C controller 3 is to open.
+
+```
+DevHandle i2cHandle = NULL; /* I2C controller handle */
+
+/* Open an I2C controller. */
+i2cHandle = I2cOpen(3);
+if (i2cHandle == NULL) {
+ HDF_LOGE("I2cOpen: failed\n");
+ return;
+}
+```
+
+### Performing I2C Communication
+
+Use the following function for message transfer:
+
+int32\_t I2cTransfer\(DevHandle handle, struct I2cMsg \*msgs, int16\_t count\);
+
+**Table 3** Description of I2cTransfer
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Handle of an I2C controller.
+
+
+
msgs
+
+
Message array of the data to transfer.
+
+
+
count
+
+
Length of the message array.
+
+
+
Return Value
+
+
Description
+
+
+
Positive integer
+
+
Number of message structures that are successfully transmitted.
+
+
+
Negative value
+
+
Failed to perform the message transfer.
+
+
+
+
+
+The type of an I2C message transfer is defined by **I2cMsg**. Each message structure indicates a read or write operation. Multiple read or write operations can be performed by using a message array.
+
+```
+int32_t ret;
+uint8_t wbuff[2] = { 0x12, 0x13 };
+uint8_t rbuff[2] = { 0 };
+struct I2cMsg msgs[2]; /* Custom message array for transfer */
+msgs[0].buf = wbuff; /* Data to write */
+msgs[0].len = 2; /* The length of the data to write is 2. */
+msgs[0].addr = 0x5A; /* The address of the device to write the data is 0x5A. */
+msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
+msgs[1].buf = rbuff; /* Data to read */
+msgs[1].len = 2; /* The length of the data to read is 2. */
+msgs[1].addr = 0x5A; /* The address of the device to read is 0x5A. */
+msgs[1].flags = I2C_FLAG_READ /* I2C_FLAG_READ is configured, indicating the read operation. */
+/* Perform a custom transfer to transfer two messages. */
+ret = I2cTransfer(i2cHandle, msgs, 2);
+if (ret != 2) {
+ HDF_LOGE("I2cTransfer: failed, ret %d\n", ret);
+ return;
+}
+```
+
+> **CAUTION:**
+>- The device address in the **I2cMsg** structure does not contain the read/write flag bit. The read/write information is transferred by the read/write control bit in the member variable **flags**.
+>- The **I2cTransfer** function does not limit the number of message structures, which is determined by the I2C controller.
+>- The **I2cTransfer** function does not limit the data length of each message structure, which is determined by the I2C controller.
+>- The **I2cTransfer** function may cause the system to sleep and therefore cannot be called in the interrupt context.
+
+### Closing an I2C Controller
+
+Call the following function to close the I2C controller after the communication is complete:
+
+void I2cClose\(DevHandle \*handle\);
+
+**Table 4** Description of I2cClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Handle of an I2C controller.
+
+
+
+
+
+```
+I2cClose(i2cHandle); /* Close the I2C controller. */
+```
+
+## Usage Example
+
+This example describes how to use I2C APIs with an I2C device on a development board.
+
+This example shows a simple register read/write operation on TouchPad on a Hi3516D V300 development board. The basic hardware information is as follows:
+
+- SoC: hi3516dv300
+
+- Touch IC: The I2C address is 0x38, and the bit width of Touch IC's internal register is 1 byte.
+
+- Schematic diagram: TouchPad is mounted to I2C controller 3. The reset pin of Touch IC is GPIO3.
+
+In this example, first we reset Touch IC. \(The development board supplies power to Touch IC by default after being powered on, and this use case does not consider the power supply\). Then, we perform a read/write operation on an internal register to test whether the I2C channel is normal.
+
+> **NOTE:**
+>The example focuses on I2C device access and verifies the I2C channel. The read and write values of the device register are not concerned. The behavior caused by the read and write operations on the register is determined by the device itself.
+
+Example:
+
+```
+#include "i2c_if.h" /* Header file of I2C APIs */
+#include "gpio_if.h" /* Header file of GPIO APIs */
+#include "hdf_log.h" /* Header file for log APIs */
+#include "osal_io.h" /* Header file of I/O read and write APIs */
+#include "osal_time.h" /* Header file of delay and sleep APIs */
+
+/* Define a TP device structure to store I2C and GPIO hardware information. */
+struct TpI2cDevice {
+ uint16_t rstGpio; /* Reset pin */
+ uint16_t busId; /* I2C bus ID */
+ uint16_t addr; /* I2C device address */
+ uint16_t regLen; /* Register bit width */
+ DevHandle i2cHandle; /* I2C controller handle */
+};
+
+/* I2C pin I/O configuration. For details, see the SoC register manual. */
+#define I2C3_DATA_REG_ADDR 0x112f008c /* Address of the SDA pin configuration register of I2C controller 3
+#define I2C3_CLK_REG_ADDR 0x112f0090 /* Address of the SCL pin configuration register of I2C controller 3
+#define I2C_REG_CFG 0x5f1 /* Configuration values of SDA and SCL pins of I2C controller 3
+
+static void TpSocIoCfg(void)
+{
+ /* Set the I/O function of the two pins corresponding to I2C controller 3 to I2C. */
+ OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_DATA_REG_ADDR));
+ OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_CLK_REG_ADDR));
+}
+
+/* Initialize the reset pin of the TP. Pull up the pin for 20 ms, pull down the pin for 50 ms, and then pull up the pin for 20 ms to complete the resetting. */
+static int32_t TestCaseGpioInit(struct TpI2cDevice *tpDevice)
+{
+ int32_t ret;
+
+ /* Set the output direction for the reset pin. */
+ ret = GpioSetDir(tpDevice->rstGpio, GPIO_DIR_OUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst dir fail!:%d", __func__, ret);
+ return ret;
+ }
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst hight fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(20);
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_LOW);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst low fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(50);
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst high fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(20);
+
+ return HDF_SUCCESS;
+}
+
+/* Use I2cTransfer to encapsulate a register read/write auxiliary function. Use flag to indicate the read or write operation. */
+static int TpI2cReadWrite(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen, uint8_t flag)
+{
+ int index = 0;
+ unsigned char regBuf[4] = {0};
+ struct I2cMsg msgs[2] = {0};
+
+ /* Perform length adaptation for the single- or dual-byte register. */
+ if (tpDevice->regLen == 1) {
+ regBuf[index++] = regAddr & 0xFF;
+ } else {
+ regBuf[index++] = (regAddr >> 8) & 0xFF;
+ regBuf[index++] = regAddr & 0xFF;
+ }
+
+ /* Fill in the I2cMsg message structure. */
+ msgs[0].addr = tpDevice->addr;
+ msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
+ msgs[0].len = tpDevice->regLen;
+ msgs[0].buf = regBuf;
+
+ msgs[1].addr = tpDevice->addr;
+ msgs[1].flags = (flag == 1)? I2C_FLAG_READ: 0; /* Add the read flag. */
+ msgs[1].len = dataLen;
+ msgs[1].buf = regData;
+
+ if (I2cTransfer(tpDevice->i2cHandle, msgs, 2) != 2) {
+ HDF_LOGE("%s: i2c read err", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+/* TP register read function */
+static inline int TpI2cReadReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen)
+{
+ return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 1);
+}
+
+/* TP register write function */
+static inline int TpI2cWriteReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen)
+{
+ return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 0);
+}
+
+/* Main entry of I2C */
+static int32_t TestCaseI2c(void)
+{
+ int32_t i;
+ int32_t ret;
+ unsigned char bufWrite[7] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xA, 0xB, 0xC };
+ unsigned char bufRead[7] = {0};
+ static struct TpI2cDevice tpDevice;
+
+ /* I/O pin function configuration */
+ TpSocIoCfg();
+
+ /* Initialize TP device information. */
+ tpDevice.rstGpio = 3;
+ tpDevice.busId = 3;
+ tpDevice.addr = 0x38;
+ tpDevice.regLen = 1;
+ tpDevice.i2cHandle = NULL;
+
+ /* Initialize the GPIO pin. */
+ ret = TestCaseGpioInit(&tpDevice);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: gpio init fail!:%d", __func__, ret);
+ return ret;
+ }
+
+ /* Open an I2C controller. */
+ tpDevice.i2cHandle = I2cOpen(tpDevice.busId);
+ if (tpDevice.i2cHandle == NULL) {
+ HDF_LOGE("%s: Open I2c:%u fail!", __func__, tpDevice.busId);
+ return -1;
+ }
+
+ /* Continuously write 7-byte data to register 0xD5 of TP-IC. */
+ ret = TpI2cWriteReg(&tpDevice, 0xD5, bufWrite, 7);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: tp i2c write reg fail!:%d", __func__, ret);
+ I2cClose(tpDevice.i2cHandle);
+ return -1;
+ }
+ OsalMSleep(10);
+
+ /* Continuously read 7-byte data from register 0xDO of TP-IC. */
+ ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret);
+ I2cClose(tpDevice.i2cHandle);
+ return -1;
+ }
+
+ HDF_LOGE("%s: tp i2c write&read reg success!", __func__);
+ for (i = 0; i < 7; i++) {
+ HDF_LOGE("%s: bufRead[%d] = 0x%x", __func__, i, bufRead[i]);
+ }
+
+ /* Close the I2C controller. */
+ I2cClose(tpDevice.i2cHandle);
+ return ret;
+}
+```
diff --git a/en/device-dev/driver/lcd.md b/en/device-dev/driver/lcd.md
index 9930511412c592f0dc36c9fe4b50ee9f206944a9..855cd171cdd46b66867d31c0f51cb53afffccdfb 100644
--- a/en/device-dev/driver/lcd.md
+++ b/en/device-dev/driver/lcd.md
@@ -1,9 +1,363 @@
-# LCD
+# LCD
-- **[LCD Overview](lcdoverview.md)**
+- [Overview](#section141575391542)
+ - [API Description](#section14711163785519)
-- **[LCD Development Guidelines](lcddevelopment-guidelines.md)**
+- [Development Guidelines](#section12394223125615)
+ - [How to Develop](#section515923045814)
-- **[LCD Development Example](lcddevelopment-example.md)**
+- [Development Example](#section7441155155813)
+## Overview
+
+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](hdfoverview.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 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.
+
+ - 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.
+
+ - 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.
+
+
+### 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
+
+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:
+ - Powering on/off the LCD device
+
+ Based on the LCD hardware connection, use the GPIO interfaces provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
+
+ - Sending the initialization sequence
+
+ Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier.
+
+
+4. Implement other HDF interfaces as required, for example, the **Release** interface.
+5. Use the HDF to create other device nodes for implementing service logic or debugging as required.
+
+## Development Example
+
+Add the device description.
+
+```
+/* Description of the display driver */
+display :: host {
+ hostName = "display_host";
+ /* Description of the HDF display driver */
+ device_hdf_disp :: device {
+ device0 :: deviceNode {
+ policy = 2;
+ priority = 200;
+ permission = 0660;
+ moduleName = "HDF_DISP";
+ serviceName = "hdf_disp";
+ }
+ }
+ /* Description of the driver device at the SoC adapter layer */
+ device_hi35xx_disp :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 199;
+ moduleName = "HI351XX_DISP";
+ }
+ }
+ /* Description of the LCD driver */
+ device_lcd :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 100;
+ preload = 0;
+ moduleName = "LCD_Sample";
+ }
+ device1 :: deviceNode {
+ policy = 0;
+ priority = 100;
+ preload = 2;
+ moduleName = "LCD_SampleXX";
+ }
+ }
+}
+```
+
+The following example shows how to adapt to the MIPI device to the Hi35xx series chips at the SoC adapter layer:
+
+```
+static int32_t MipiDsiInit(struct PanelInfo *info)
+{
+ int32_t ret;
+ struct DevHandle *mipiHandle = NULL;
+ struct MipiCfg cfg;
+
+ mipiHandle = MipiDsiOpen(0);
+ if (mipiHandle == NULL) {
+ HDF_LOGE("%s: MipiDsiOpen failure", __func__);
+ return HDF_FAILURE;
+ }
+ cfg.lane = info->mipi.lane;
+ cfg.mode = info->mipi.mode;
+ cfg.format = info->mipi.format;
+ cfg.burstMode = info->mipi.burstMode;
+ cfg.timing.xPixels = info->width;
+ cfg.timing.hsaPixels = info->hsw;
+ cfg.timing.hbpPixels = info->hbp;
+ cfg.timing.hlinePixels = info->width + info->hbp + info->hfp + info->hsw;
+ cfg.timing.vsaLines = info->vsw;
+ cfg.timing.vbpLines = info->vbp;
+ cfg.timing.vfpLines = info->vfp;
+ cfg.timing.ylines = info->height;
+ /* 0 : no care */
+ cfg.timing.edpiCmdSize = 0;
+ cfg.pixelClk = CalcPixelClk(info);
+ cfg.phyDataRate = CalcDataRate(info);
+ /* config mipi device */
+ ret = MipiDsiSetCfg(mipiHandle, &cfg);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s:MipiDsiSetCfg failure", __func__);
+ }
+ MipiDsiClose(mipiHandle);
+ HDF_LOGI("%s:pixelClk = %d, phyDataRate = %d\n", __func__,
+ cfg.pixelClk, cfg.phyDataRate);
+ return ret;
+}
+```
+
+The following example shows code for developing an LCD driver:
+
+```
+#define RESET_GPIO 5
+#define MIPI_DSI0 0
+#define BLK_PWM1 1
+#define PWM_MAX_PERIOD 100000
+/* backlight setting */
+#define MIN_LEVEL 0
+#define MAX_LEVEL 255
+#define DEFAULT_LEVEL 100
+
+#define WIDTH 480
+#define HEIGHT 960
+#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 FRAME_RATE 60
+
+/* PanelInfo structure */
+struct PanelInfo {
+ uint32_t width;
+ uint32_t height;
+ uint32_t hbp;
+ uint32_t hfp;
+ uint32_t hsw;
+ uint32_t vbp;
+ uint32_t vfp;
+ uint32_t vsw;
+ uint32_t frameRate;
+ enum LcdIntfType intfType;
+ enum IntfSync intfSync;
+ struct MipiDsiDesc mipi;
+ struct BlkDesc blk;
+ struct PwmCfg pwm;
+};
+
+/* Initialization sequence of the LCD panel */
+static uint8_t g_payLoad0[] = { 0xF0, 0x5A, 0x5A };
+static uint8_t g_payLoad1[] = { 0xF1, 0xA5, 0xA5 };
+static uint8_t g_payLoad2[] = { 0xB3, 0x03, 0x03, 0x03, 0x07, 0x05, 0x0D, 0x0F, 0x11, 0x13, 0x09, 0x0B };
+static uint8_t g_payLoad3[] = { 0xB4, 0x03, 0x03, 0x03, 0x06, 0x04, 0x0C, 0x0E, 0x10, 0x12, 0x08, 0x0A };
+static uint8_t g_payLoad4[] = { 0xB0, 0x54, 0x32, 0x23, 0x45, 0x44, 0x44, 0x44, 0x44, 0x60, 0x00, 0x60, 0x1C };
+static uint8_t g_payLoad5[] = { 0xB1, 0x32, 0x84, 0x02, 0x87, 0x12, 0x00, 0x50, 0x1C };
+static uint8_t g_payLoad6[] = { 0xB2, 0x73, 0x09, 0x08 };
+static uint8_t g_payLoad7[] = { 0xB6, 0x5C, 0x5C, 0x05 };
+static uint8_t g_payLoad8[] = { 0xB8, 0x23, 0x41, 0x32, 0x30, 0x03 };
+static uint8_t g_payLoad9[] = { 0xBC, 0xD2, 0x0E, 0x63, 0x63, 0x5A, 0x32, 0x22, 0x14, 0x22, 0x03 };
+static uint8_t g_payLoad10[] = { 0xb7, 0x41 };
+static uint8_t g_payLoad11[] = { 0xC1, 0x0c, 0x10, 0x04, 0x0c, 0x10, 0x04 };
+static uint8_t g_payLoad12[] = { 0xC2, 0x10, 0xE0 };
+static uint8_t g_payLoad13[] = { 0xC3, 0x22, 0x11 };
+static uint8_t g_payLoad14[] = { 0xD0, 0x07, 0xFF };
+static uint8_t g_payLoad15[] = { 0xD2, 0x63, 0x0B, 0x08, 0x88 };
+static uint8_t g_payLoad16[] = { 0xC6, 0x08, 0x15, 0xFF, 0x10, 0x16, 0x80, 0x60 };
+static uint8_t g_payLoad17[] = { 0xc7, 0x04 };
+static uint8_t g_payLoad18[] = {
+ 0xC8, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52, 0x43, 0x4C, 0x40,
+ 0x3D, 0x30, 0x1E, 0x06, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52,
+ 0x43, 0x4C, 0x40, 0x3D, 0x30, 0x1E, 0x06
+};
+static uint8_t g_payLoad19[] = { 0x11 };
+static uint8_t g_payLoad20[] = { 0x29 };
+
+struct DsiCmdDesc g_OnCmd[] = {
+ { 0x29, 0, sizeof(g_payLoad0), g_payLoad0 },
+ { 0x29, 0, sizeof(g_payLoad1), g_payLoad1 },
+ { 0x29, 0, sizeof(g_payLoad2), g_payLoad2 },
+ { 0x29, 0, sizeof(g_payLoad3), g_payLoad3 },
+ { 0x29, 0, sizeof(g_payLoad4), g_payLoad4 },
+ { 0x29, 0, sizeof(g_payLoad5), g_payLoad5 },
+ { 0x29, 0, sizeof(g_payLoad6), g_payLoad6 },
+ { 0x29, 0, sizeof(g_payLoad7), g_payLoad7 },
+ { 0x29, 0, sizeof(g_payLoad8), g_payLoad8 },
+ { 0x29, 0, sizeof(g_payLoad9), g_payLoad9 },
+ { 0x23, 0, sizeof(g_payLoad10), g_payLoad10 },
+ { 0x29, 0, sizeof(g_payLoad11), g_payLoad11 },
+ { 0x29, 0, sizeof(g_payLoad12), g_payLoad12 },
+ { 0x29, 0, sizeof(g_payLoad13), g_payLoad13 },
+ { 0x29, 0, sizeof(g_payLoad14), g_payLoad14 },
+ { 0x29, 0, sizeof(g_payLoad15), g_payLoad15 },
+ { 0x29, 0, sizeof(g_payLoad16), g_payLoad16 },
+ { 0x23, 0, sizeof(g_payLoad17), g_payLoad17 },
+ { 0x29, 1, sizeof(g_payLoad18), g_payLoad18 },
+ { 0x05, 120, sizeof(g_payLoad19), g_payLoad19 },
+ { 0x05, 120, sizeof(g_payLoad20), g_payLoad20 },
+};
+static DevHandle g_mipiHandle = NULL;
+static DevHandle g_pwmHandle = NULL;
+
+/* Set the status of the reset pin. */
+static int32_t LcdResetOn(void)
+{
+ int32_t ret;
+ ret = GpioSetDir(RESET_GPIO, GPIO_DIR_OUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("GpioSetDir failure, ret:%d", ret);
+ return HDF_FAILURE;
+ }
+ ret = GpioWrite(RESET_GPIO, GPIO_VAL_HIGH);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("GpioWrite failure, ret:%d", ret);
+ return HDF_FAILURE;
+ }
+ /* delay 20ms */
+ OsalMSleep(20);
+ return HDF_SUCCESS;
+}
+
+static int32_t SampleInit(void)
+{
+ /* Obtain the MIPI DSI device handle. */
+ g_mipiHandle = MipiDsiOpen(MIPI_DSI0);
+ if (g_mipiHandle == NULL) {
+ HDF_LOGE("%s: MipiDsiOpen failure", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+static int32_t SampleOn(void)
+{
+ int32_t ret;
+ /* Power on the LCD. */
+ ret = LcdResetOn();
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: LcdResetOn failure", __func__);
+ return HDF_FAILURE;
+ }
+ if (g_mipiHandle == NULL) {
+ HDF_LOGE("%s: g_mipiHandle is null", __func__);
+ return HDF_FAILURE;
+ }
+ /* Send the initialization sequence via MIPI. */
+ int32_t count = sizeof(g_OnCmd) / sizeof(g_OnCmd[0]);
+ int32_t i;
+ for (i = 0; i < count; i++) {
+ ret = MipiDsiTx(g_mipiHandle, &(g_OnCmd[i]));
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("MipiDsiTx failure");
+ return HDF_FAILURE;
+ }
+ }
+ /* Set MIPI to the high speed (HS) mode. */
+ MipiDsiSetHsMode(g_mipiHandle);
+ return HDF_SUCCESS;
+}
+
+/* PanelInfo structure variables */
+static struct PanelInfo g_panelInfo = {
+ .width = WIDTH, /* width */
+ .height = HEIGHT, /* height */
+ .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 */
+ .frameRate = FRAME_RATE, /* frame rate */
+ .intfType = MIPI_DSI, /* panel interface type */
+ .intfSync = OUTPUT_USER, /* output timming type */
+ /* mipi config info */
+ .mipi = { DSI_2_LANES, DSI_VIDEO_MODE, VIDEO_BURST_MODE, FORMAT_RGB_24_BIT },
+ /* backlight config info */
+ .blk = { BLK_PWM, MIN_LEVEL, MAX_LEVEL, DEFAULT_LEVEL },
+ .pwm = { BLK_PWM1, PWM_MAX_PERIOD },
+};
+
+/* Basic APIs that need to be adapted for the chip driver */
+static struct PanelData g_panelData = {
+ .info = &g_panelInfo,
+ .init = SampleInit,
+ .on = SampleOn,
+ .off = SampleOff,
+ .setBacklight = SampleSetBacklight,
+};
+
+/* Entry function of the chip driver */
+int32_t SampleEntryInit(struct HdfDeviceObject *object)
+{
+ HDF_LOGI("%s: enter", __func__);
+ if (object == NULL) {
+ HDF_LOGE("%s: param is null!", __func__);
+ return HDF_FAILURE;
+ }
+ /* Register the chip driver APIs with the platform driver. */
+ if (PanelDataRegister(&g_panelData) != HDF_SUCCESS) {
+ HDF_LOGE("%s: PanelDataRegister error!", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+struct HdfDriverEntry g_sampleDevEntry = {
+ .moduleVersion = 1,
+ .moduleName = "LCD_SAMPLE",
+ .Init = SampleEntryInit,
+};
+
+HDF_INIT(g_sampleDevEntry);
+```
diff --git a/en/device-dev/driver/lcddevelopment-example.md b/en/device-dev/driver/lcddevelopment-example.md
deleted file mode 100644
index 35122ca4fa69878a8c36e658da23082b0c0084e0..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcddevelopment-example.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# LCD Development Example
-
-Add the device description.
-
-```
-/* Description of the display driver */
-display :: host {
- hostName = "display_host";
- /* Description of the HDF display driver */
- device_hdf_disp :: device {
- device0 :: deviceNode {
- policy = 2;
- priority = 200;
- permission = 0660;
- moduleName = "HDF_DISP";
- serviceName = "hdf_disp";
- }
- }
- /* Description of the driver device at the SoC adapter layer */
- device_hi35xx_disp :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 199;
- moduleName = "HI351XX_DISP";
- }
- }
- /* Description of the LCD driver */
- device_lcd :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 100;
- preload = 0;
- moduleName = "LCD_Sample";
- }
- device1 :: deviceNode {
- policy = 0;
- priority = 100;
- preload = 2;
- moduleName = "LCD_SampleXX";
- }
- }
-}
-```
-
-The following example shows how to adapt to the MIPI device to the Hi35xx series chips at the SoC adapter layer:
-
-```
-static int32_t MipiDsiInit(struct PanelInfo *info)
-{
- int32_t ret;
- struct DevHandle *mipiHandle = NULL;
- struct MipiCfg cfg;
-
- mipiHandle = MipiDsiOpen(0);
- if (mipiHandle == NULL) {
- HDF_LOGE("%s: MipiDsiOpen failure", __func__);
- return HDF_FAILURE;
- }
- cfg.lane = info->mipi.lane;
- cfg.mode = info->mipi.mode;
- cfg.format = info->mipi.format;
- cfg.burstMode = info->mipi.burstMode;
- cfg.timing.xPixels = info->width;
- cfg.timing.hsaPixels = info->hsw;
- cfg.timing.hbpPixels = info->hbp;
- cfg.timing.hlinePixels = info->width + info->hbp + info->hfp + info->hsw;
- cfg.timing.vsaLines = info->vsw;
- cfg.timing.vbpLines = info->vbp;
- cfg.timing.vfpLines = info->vfp;
- cfg.timing.ylines = info->height;
- /* 0 : no care */
- cfg.timing.edpiCmdSize = 0;
- cfg.pixelClk = CalcPixelClk(info);
- cfg.phyDataRate = CalcDataRate(info);
- /* config mipi device */
- ret = MipiDsiSetCfg(mipiHandle, &cfg);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s:MipiDsiSetCfg failure", __func__);
- }
- MipiDsiClose(mipiHandle);
- HDF_LOGI("%s:pixelClk = %d, phyDataRate = %d\n", __func__,
- cfg.pixelClk, cfg.phyDataRate);
- return ret;
-}
-```
-
-The following example shows code for developing an LCD driver:
-
-```
-#define RESET_GPIO 5
-#define MIPI_DSI0 0
-#define BLK_PWM1 1
-#define PWM_MAX_PERIOD 100000
-/* backlight setting */
-#define MIN_LEVEL 0
-#define MAX_LEVEL 255
-#define DEFAULT_LEVEL 100
-
-#define WIDTH 480
-#define HEIGHT 960
-#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 FRAME_RATE 60
-
-/* Panel information structure */
-struct PanelInfo {
- uint32_t width;
- uint32_t height;
- uint32_t hbp;
- uint32_t hfp;
- uint32_t hsw;
- uint32_t vbp;
- uint32_t vfp;
- uint32_t vsw;
- uint32_t frameRate;
- enum LcdIntfType intfType;
- enum IntfSync intfSync;
- struct MipiDsiDesc mipi;
- struct BlkDesc blk;
- struct PwmCfg pwm;
-};
-
-/* Initialization sequence of the LCD panel */
-static uint8_t g_payLoad0[] = { 0xF0, 0x5A, 0x5A };
-static uint8_t g_payLoad1[] = { 0xF1, 0xA5, 0xA5 };
-static uint8_t g_payLoad2[] = { 0xB3, 0x03, 0x03, 0x03, 0x07, 0x05, 0x0D, 0x0F, 0x11, 0x13, 0x09, 0x0B };
-static uint8_t g_payLoad3[] = { 0xB4, 0x03, 0x03, 0x03, 0x06, 0x04, 0x0C, 0x0E, 0x10, 0x12, 0x08, 0x0A };
-static uint8_t g_payLoad4[] = { 0xB0, 0x54, 0x32, 0x23, 0x45, 0x44, 0x44, 0x44, 0x44, 0x60, 0x00, 0x60, 0x1C };
-static uint8_t g_payLoad5[] = { 0xB1, 0x32, 0x84, 0x02, 0x87, 0x12, 0x00, 0x50, 0x1C };
-static uint8_t g_payLoad6[] = { 0xB2, 0x73, 0x09, 0x08 };
-static uint8_t g_payLoad7[] = { 0xB6, 0x5C, 0x5C, 0x05 };
-static uint8_t g_payLoad8[] = { 0xB8, 0x23, 0x41, 0x32, 0x30, 0x03 };
-static uint8_t g_payLoad9[] = { 0xBC, 0xD2, 0x0E, 0x63, 0x63, 0x5A, 0x32, 0x22, 0x14, 0x22, 0x03 };
-static uint8_t g_payLoad10[] = { 0xb7, 0x41 };
-static uint8_t g_payLoad11[] = { 0xC1, 0x0c, 0x10, 0x04, 0x0c, 0x10, 0x04 };
-static uint8_t g_payLoad12[] = { 0xC2, 0x10, 0xE0 };
-static uint8_t g_payLoad13[] = { 0xC3, 0x22, 0x11 };
-static uint8_t g_payLoad14[] = { 0xD0, 0x07, 0xFF };
-static uint8_t g_payLoad15[] = { 0xD2, 0x63, 0x0B, 0x08, 0x88 };
-static uint8_t g_payLoad16[] = { 0xC6, 0x08, 0x15, 0xFF, 0x10, 0x16, 0x80, 0x60 };
-static uint8_t g_payLoad17[] = { 0xc7, 0x04 };
-static uint8_t g_payLoad18[] = {
- 0xC8, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52, 0x43, 0x4C, 0x40,
- 0x3D, 0x30, 0x1E, 0x06, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52,
- 0x43, 0x4C, 0x40, 0x3D, 0x30, 0x1E, 0x06
-};
-static uint8_t g_payLoad19[] = { 0x11 };
-static uint8_t g_payLoad20[] = { 0x29 };
-
-struct DsiCmdDesc g_OnCmd[] = {
- { 0x29, 0, sizeof(g_payLoad0), g_payLoad0 },
- { 0x29, 0, sizeof(g_payLoad1), g_payLoad1 },
- { 0x29, 0, sizeof(g_payLoad2), g_payLoad2 },
- { 0x29, 0, sizeof(g_payLoad3), g_payLoad3 },
- { 0x29, 0, sizeof(g_payLoad4), g_payLoad4 },
- { 0x29, 0, sizeof(g_payLoad5), g_payLoad5 },
- { 0x29, 0, sizeof(g_payLoad6), g_payLoad6 },
- { 0x29, 0, sizeof(g_payLoad7), g_payLoad7 },
- { 0x29, 0, sizeof(g_payLoad8), g_payLoad8 },
- { 0x29, 0, sizeof(g_payLoad9), g_payLoad9 },
- { 0x23, 0, sizeof(g_payLoad10), g_payLoad10 },
- { 0x29, 0, sizeof(g_payLoad11), g_payLoad11 },
- { 0x29, 0, sizeof(g_payLoad12), g_payLoad12 },
- { 0x29, 0, sizeof(g_payLoad13), g_payLoad13 },
- { 0x29, 0, sizeof(g_payLoad14), g_payLoad14 },
- { 0x29, 0, sizeof(g_payLoad15), g_payLoad15 },
- { 0x29, 0, sizeof(g_payLoad16), g_payLoad16 },
- { 0x23, 0, sizeof(g_payLoad17), g_payLoad17 },
- { 0x29, 1, sizeof(g_payLoad18), g_payLoad18 },
- { 0x05, 120, sizeof(g_payLoad19), g_payLoad19 },
- { 0x05, 120, sizeof(g_payLoad20), g_payLoad20 },
-};
-static DevHandle g_mipiHandle = NULL;
-static DevHandle g_pwmHandle = NULL;
-
-/* Set the status of the reset pin. */
-static int32_t LcdResetOn(void)
-{
- int32_t ret;
- ret = GpioSetDir(RESET_GPIO, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("GpioSetDir failure, ret:%d", ret);
- return HDF_FAILURE;
- }
- ret = GpioWrite(RESET_GPIO, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("GpioWrite failure, ret:%d", ret);
- return HDF_FAILURE;
- }
- /* delay 20ms */
- OsalMSleep(20);
- return HDF_SUCCESS;
-}
-
-static int32_t SampleInit(void)
-{
- /* Obtain the MIPI DSI device handle. */
- g_mipiHandle = MipiDsiOpen(MIPI_DSI0);
- if (g_mipiHandle == NULL) {
- HDF_LOGE("%s: MipiDsiOpen failure", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-static int32_t SampleOn(void)
-{
- int32_t ret;
- /* Power on the LCD. */
- ret = LcdResetOn();
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: LcdResetOn failure", __func__);
- return HDF_FAILURE;
- }
- if (g_mipiHandle == NULL) {
- HDF_LOGE("%s: g_mipiHandle is null", __func__);
- return HDF_FAILURE;
- }
- /* Send the initialization sequence via MIPI. */
- int32_t count = sizeof(g_OnCmd) / sizeof(g_OnCmd[0]);
- int32_t i;
- for (i = 0; i < count; i++) {
- ret = MipiDsiTx(g_mipiHandle, &(g_OnCmd[i]));
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("MipiDsiTx failure");
- return HDF_FAILURE;
- }
- }
- /* Set MIPI to the high speed (HS) mode. */
- MipiDsiSetHsMode(g_mipiHandle);
- return HDF_SUCCESS;
-}
-
-/* PanelInfo structure variables */
-static struct PanelInfo g_panelInfo = {
- .width = WIDTH, /* width */
- .height = HEIGHT, /* height */
- .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 */
- .frameRate = FRAME_RATE, /* frame rate */
- .intfType = MIPI_DSI, /* panel interface type */
- .intfSync = OUTPUT_USER, /* output timming type */
- /* mipi config info */
- .mipi = { DSI_2_LANES, DSI_VIDEO_MODE, VIDEO_BURST_MODE, FORMAT_RGB_24_BIT },
- /* backlight config info */
- .blk = { BLK_PWM, MIN_LEVEL, MAX_LEVEL, DEFAULT_LEVEL },
- .pwm = { BLK_PWM1, PWM_MAX_PERIOD },
-};
-
-/* Basic APIs that need to be adapted for the chip driver */
-static struct PanelData g_panelData = {
- .info = &g_panelInfo,
- .init = SampleInit,
- .on = SampleOn,
- .off = SampleOff,
- .setBacklight = SampleSetBacklight,
-};
-
-/* Entry function of the chip driver */
-int32_t SampleEntryInit(struct HdfDeviceObject *object)
-{
- HDF_LOGI("%s: enter", __func__);
- if (object == NULL) {
- HDF_LOGE("%s: param is null!", __func__);
- return HDF_FAILURE;
- }
- /* Register the chip driver APIs with the platform driver. */
- if (PanelDataRegister(&g_panelData) != HDF_SUCCESS) {
- HDF_LOGE("%s: PanelDataRegister error!", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-struct HdfDriverEntry g_sampleDevEntry = {
- .moduleVersion = 1,
- .moduleName = "LCD_SAMPLE",
- .Init = SampleEntryInit,
-};
-
-HDF_INIT(g_sampleDevEntry);
-```
-
diff --git a/en/device-dev/driver/lcddevelopment-guidelines.md b/en/device-dev/driver/lcddevelopment-guidelines.md
deleted file mode 100644
index a7d0f9cb7453fe32c2c9448eba76bd2cac09ec45..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcddevelopment-guidelines.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# LCD Development Guidelines
-
-- [How to Develop](#section3904154911218)
-
-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:
- - Powering on/off the LCD device
-
- Based on the LCD hardware connection, use the GPIO interfaces provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
-
- - Sending the initialization sequence
-
- Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier.
-
-
-4. Implement other HDF interfaces as required, for example, the **Release** interface.
-5. Use the HDF to create other device nodes for implementing service logic or debugging as required.
-
diff --git a/en/device-dev/driver/lcdoverview.md b/en/device-dev/driver/lcdoverview.md
deleted file mode 100644
index 08ba05e1f409a702a3b4334ce7124a4e80f5af57..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcdoverview.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# LCD Overview
-
-- [Introduction](#section3781515122118)
-- [API Description](#section20280192712120)
-
-## Introduction
-
-The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](hdfoverview.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. It 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 to 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 common 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.
-
- - 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.
-
- Based on the display driver model, various capabilities, and APIs, you can greatly simplify the display driver development and improve the efficiency.
-
-
-## 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. It transmits data signals, clock signals, and control signals \(such as line synchronization signals, frame synchronization signals, and data validity signals\) under the control of control 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\).
-
-
diff --git a/en/device-dev/driver/mipi-dsi-overview.md b/en/device-dev/driver/mipi-dsi-overview.md
deleted file mode 100644
index ec579fba093ecad64f31fd5d00b429878829a652..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/mipi-dsi-overview.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# MIPI DSI Overview
-
-- [Introduction](#section1369320102013)
-- [Available APIs](#section6577545192317)
-
-## Introduction
-
-- The Display Serial Interface \(DSI\) is a specification stipulated by the Mobile Industry Processor Interface \(MIPI\) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals \(usually LCDs or similar display devices\) in serial mode, or reads information such as status and pixel from the peripherals.
-
-- MIPI DSI is capable of working in both high speed \(HS\) mode and low power \(LP\) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
- - [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
-
-**Table 1** APIs for MIPI DSI
-
-
-
Sets configuration parameters for a MIPI DSI device.
-
-
-
MipiDsiGetCfg
-
-
Obtains the configuration parameters of a MIPI DSI device.
-
-
-
Obtaining /Releasing device handles
-
-
MipiDsiOpen
-
-
Obtains a MIPI DSI device handle.
-
-
-
MipiDsiClose
-
-
Releases a specified MIPI DSI device handle.
-
-
-
Setting the LP or HS mode
-
-
MipiDsiSetLpMode
-
-
Sets LP mode for a MIPI DSI device.
-
-
-
MipiDsiSetHsMode
-
-
Sets HS mode for a MIPI DSI device.
-
-
-
Reading/Sending commands
-
-
MipiDsiTx
-
-
Sends a display command set (DCS) command for sending data.
-
-
-
MipiDsiRx
-
-
Receives a DCS command for reading data with the specified length.
-
-
-
-
-
-> **NOTE:**
->All functions described in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/mipi-dsi.md b/en/device-dev/driver/mipi-dsi.md
index f50672962f5c2602a93f63821ac290de3271ad02..698edad62a3f929529342af06aa7ccdcb33cea43 100644
--- a/en/device-dev/driver/mipi-dsi.md
+++ b/en/device-dev/driver/mipi-dsi.md
@@ -1,9 +1,554 @@
-# MIPI DSI
+# MIPI DSI
-- **[MIPI DSI Overview](mipi-dsi-overview.md)**
+- [Overview](#section16806142183217)
+ - [Available APIs](#section129611916132011)
-- **[Usage Guidelines](usage-guidelines.md)**
+- [Usage Guidelines](#section037231715335)
+ - [How to Use](#section49299119344)
+ - [Obtains a MIPI DSI device handle.](#section5126155683811)
+ - [Setting MIPI DSI Configuration Parameters](#section201164274344)
+ - [Sending/Receiving the Pointer to a Command](#section199401342173415)
+ - [Releasing the MIPI DSI Device Handle](#section161011610357)
-- **[Usage Example](usage-example.md)**
+- [Usage Example](#section17470126123520)
+## Overview
+
+- The Display Serial Interface \(DSI\) is a specification stipulated by the Mobile Industry Processor Interface \(MIPI\) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals \(usually LCDs or similar display devices\) in serial mode, or reads information such as status and pixel from the peripherals.
+
+- MIPI DSI is capable of working in both high speed \(HS\) mode and low power \(LP\) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
+- [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
+
+**Table 1** APIs for MIPI DSI
+
+
+
Sets configuration parameters for a MIPI DSI device.
+
+
+
MipiDsiGetCfg
+
+
Obtains configuration parameters of a MIPI DSI device.
+
+
+
Obtaining /Releasing device handles
+
+
MipiDsiOpen
+
+
Obtains a MIPI DSI device handle.
+
+
+
MipiDsiClose
+
+
Releases a specified MIPI DSI device handle.
+
+
+
Setting the LP or HS mode
+
+
MipiDsiSetLpMode
+
+
Sets LP mode for a MIPI DSI device.
+
+
+
MipiDsiSetHsMode
+
+
Sets HS mode for a MIPI DSI device.
+
+
+
Reading/Sending commands
+
+
MipiDsiTx
+
+
Sends a display command set (DCS) command for sending data.
+
+
+
MipiDsiRx
+
+
Receives a DCS command for reading data with the specified length.
+
+
+
+
+
+> **NOTE:**
+>All functions described in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig99821771782) shows the process of using a MIPI DSI device.
+
+**Figure 2** Process of using a MIPI DSI device
+
+
+
+
+### Obtains a MIPI DSI device handle.
+
+Before performing MIPI DSI communication, obtain a MIPI DSI device handle by calling **MipiDsiOpen**. This function returns a MIPI DSI device handle with a specified channel ID.
+
+DevHandle MipiDsiOpen\(uint8\_t id\);
+
+**Table 2** Description of **MipiDsiOpen**
+
+
+
Parameter
+
+
Description
+
+
+
+
id
+
+
MIPI DSI channel ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to receive the specified command.
+
+
+
Device handle
+
+
MIPI DSI device handle with a specified channel ID, whose data type is DevHandle.
+
+
+
+
+
+The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
+
+```
+DevHandle mipiDsiHandle = NULL; /* Device handle */
+chnId = 0; /* MIPI DSI channel ID */
+
+/* Obtain the MIPI DSI device handle based on a specified channel ID. */
+mipiDsiHandle = MipiDsiOpen(chnId);
+if (mipiDsiHandle == NULL) {
+ HDF_LOGE("MipiDsiOpen: failed\n");
+ return;
+}
+```
+
+### Setting MIPI DSI Configuration Parameters
+
+- Set MIPI DSI configuration parameters by calling the following function:
+
+int32\_t MipiDsiSetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
+
+**Table 3** Description of **MipiDsiSetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
MIPI DSI device handle.
+
+
+
cfg
+
+
Pointer to MIPI DSI configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting MIPI DSI configuration parameters.
+
+```
+MipiDsiClose(mipiHandle); /* Release the MIPI DSI device handle */
+```
+
+## Usage Example
+
+The following is an example of using a MIPI DSI device:
+
+```
+#include "hdf.h"
+#include "mipi_dsi_if.h"
+
+void PalMipiDsiTestSample(void)
+{
+ uint8_t chnId;
+ int32_t ret;
+ DevHandle handle = NULL;
+
+ /* Device channel ID */
+ chnId = 0;
+ /* Obtain the MIPI DSI device handle based on a specified channel ID. */
+ handle = MipiDsiOpen(chnId);
+ if (handle == NULL) {
+ HDF_LOGE("MipiDsiOpen: failed!\n");
+ return;
+ }
+ /* MIPI DSI configuration parameters */
+ struct MipiCfg cfg = {0};
+ cfg.lane = DSI_4_LANES;
+ cfg.mode = DSI_CMD_MODE;
+ cfg.burstMode = VIDEO_NON_BURST_MODE_SYNC_EVENTS;
+ cfg.format = FORMAT_RGB_24_BIT;
+ cfg.pixelClk = 174;
+ cfg.phyDataRate = 384;
+ cfg.timingInfo.hsaPixels = 50;
+ cfg.timingInfo.hbpPixels = 55;
+ cfg.timingInfo.hlinePixels = 1200;
+ cfg.timingInfo.yResLines = 1800;
+ cfg.timingInfo.vbpLines = 33;
+ cfg.timingInfo.vsaLines = 76;
+ cfg.timingInfo.vfpLines = 120;
+ cfg.timingInfo.xResPixels = 1342;
+ /* Set MIPI DSI configuration parameters. */
+ ret = MipiDsiSetCfg(g_handle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("%s: SetMipiCfg fail! ret=%d\n", __func__, ret);
+ return;
+ }
+ /* Send the command for initializing the PANEL register. */
+ struct DsiCmdDesc *cmd = OsalMemCalloc(sizeof(struct DsiCmdDesc));
+ if (cmd == NULL) {
+ return;
+ }
+ cmd->dtype = DTYPE_DCS_WRITE;
+ cmd->dlen = 1;
+ cmd->payload = OsalMemCalloc(sizeof(uint8_t));
+ if (cmd->payload == NULL) {
+ HdfFree(cmd);
+ return;
+ }
+ *(cmd->payload) = DTYPE_GEN_LWRITE;
+ MipiDsiSetLpMode(mipiHandle);
+ ret = MipiDsiTx(mipiHandle, cmd);
+ MipiDsiSetHsMode(mipiHandle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: MipiDsiTx fail! ret=%d\n", __func__, ret);
+ HdfFree(cmd->payload);
+ HdfFree(cmd);
+ return;
+ }
+ HdfFree(cmd->payload);
+ HdfFree(cmd);
+ /* Pointer to the register that reads the PANEL status */
+ uint8_t readVal = 0;
+ struct DsiCmdDesc *cmdRead = OsalMemCalloc(sizeof(struct DsiCmdDesc));
+ if (cmdRead == NULL) {
+ return;
+ }
+ cmdRead->dtype = DTYPE_DCS_READ;
+ cmdRead->dlen = 1;
+ cmdRead->payload = OsalMemCalloc(sizeof(uint8_t));
+ if (cmdRead->payload == NULL) {
+ HdfFree(cmdRead);
+ return;
+ }
+ *(cmdRead->payload) = DDIC_REG_STATUS;
+ MipiDsiSetLpMode(g_handle);
+ ret = MipiDsiRx(g_handle, cmdRead, sizeof(readVal), &readVal);
+ MipiDsiSetHsMode(g_handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: MipiDsiRx fail! ret=%d\n", __func__, ret);
+ HdfFree(cmdRead->payload);
+ HdfFree(cmdRead);
+ return;
+ }
+ HdfFree(cmdRead->payload);
+ HdfFree(cmdRead);
+ /* Release the MIPI DSI device handle. */
+ MipiDsiClose(handle);
+}
+```
diff --git a/en/device-dev/driver/peripherals.md b/en/device-dev/driver/peripherals.md
index 42016f572c98cb63bfd17d6994f67367f3c8bc5d..7c9a9629fc13e5a3929bc4aae2419c44cc70b402 100644
--- a/en/device-dev/driver/peripherals.md
+++ b/en/device-dev/driver/peripherals.md
@@ -4,7 +4,7 @@
- **[TOUCHSCREEN](touchscreen.md)**
-- **[SENSOR](sensor.md)**
+- **[Sensor](sensor.md)**
- **[WLAN](wlan.md)**
diff --git a/en/device-dev/driver/driver-platform.md b/en/device-dev/driver/platform-drivers.md
similarity index 66%
rename from en/device-dev/driver/driver-platform.md
rename to en/device-dev/driver/platform-drivers.md
index d75727d7407e71e9088a907083d02278462474e3..c7607bb8d079f569092a4a11fc54474f9f260777 100644
--- a/en/device-dev/driver/driver-platform.md
+++ b/en/device-dev/driver/platform-drivers.md
@@ -1,4 +1,4 @@
-# Driver Platform
+# Platform Drivers
- **[GPIO](gpio.md)**
@@ -12,7 +12,7 @@
- **[UART](uart.md)**
-- **[WATCHDOG](watchdog.md)**
+- **[Watchdog](watchdog.md)**
- **[MIPI DSI](mipi-dsi.md)**
diff --git a/en/device-dev/driver/rtc-overview.md b/en/device-dev/driver/rtc-overview.md
deleted file mode 100644
index 97aa8a24369a26fed6689751accb5ab46ce7fa89..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-overview.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# RTC Overview
-
-- [Introduction](#section104842041574)
-- [Available APIs](#section16892932155715)
-
-## Introduction
-
-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
-
-**Table 1** APIs provided by the RTC driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
RTC handle
-
-
RtcOpen
-
-
Opens the RTC device to obtain its handle.
-
-
-
RtcClose
-
-
Releases a specified handle of the RTC device.
-
-
-
RTC time
-
-
RtcReadTime
-
-
Reads time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
RtcWriteTime
-
-
Writes time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
RTC alarm
-
-
RtcReadAlarm
-
-
Reads the RTC alarm time that was set last time.
-
-
-
RtcWriteAlarm
-
-
Writes the RTC alarm time based on the alarm index.
-
-
-
RtcRegisterAlarmCallback
-
-
Registers RtcAlarmCallback that will be invoked when an alarm is generated at the specified time.
-
-
-
RtcAlarmInterruptEnable
-
-
Enables or disables RTC alarm interrupts.
-
-
-
RTC configuration
-
-
RtcGetFreq
-
-
Reads the frequency of the external crystal oscillator connected to the RTC driver.
-
-
-
RtcSetFreq
-
-
Sets the frequency of the external crystal oscillator connected to the RTC driver.
-
-
-
RtcReset
-
-
Resets the RTC.
-
-
-
Custom register
-
-
RtcReadReg
-
-
Reads the configuration of a custom RTC register based on the register index.
-
-
-
RtcWriteReg
-
-
Writes the configuration of a custom RTC register based on the register index.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/rtc-usage-example.md b/en/device-dev/driver/rtc-usage-example.md
deleted file mode 100644
index e546c2f1433a2ce6810b93b43fd26f4c17f8e5a7..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-usage-example.md
+++ /dev/null
@@ -1,97 +0,0 @@
-# RTC Usage Example
-
-This section describes the process of using RTC APIs:
-
-1. During the OS startup, the HDF identifies the RTC component in the system.
-2. The HDF initializes and creates the RTC device.
-3. You can perform operations on the RTC device by calling different APIs.
-4. Call the **RtcClose** function to release the device handle and device resources.
-
-Example:
-
-```
-#include "rtc_if.h"
-int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
-{
- if (alarmIndex == RTC_ALARM_INDEX_A) {
- /* Process alarm A. */
- printf("RTC Alarm A callback function\n\r");
- } else if (alarmIndex == RTC_ALARM_INDEX_B) {
- /* Process alarm B. */
- printf("RTC Alarm B callback function\n\r");
- } else {
- /* Process the error. */
- }
- return 0;
-}
-
-void RtcTestSample(void)
-{
- int32_t ret;
- struct RtcTime tm;
- struct RtcTime alarmTime;
- uint32_t freq;
- DevHandle handle = NULL;
-
- /* Obtain the RTC device handle. */
- handle = RtcOpen();
- if (handle == NULL) {
- /* Process the error. */
- }
- /* Register RtcAlarmCallback for alarm A. */
- ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC external crystal frequency. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
- freq = 32768; /* 32768 Hz */
- ret = RtcSetFreq(handle, freq);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Enable the RTC alarm interrupts. */
- ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC time to 2020/01/01 00:00:10 .990. */
- tm.year = 2020;
- tm.month = 01;
- tm.day = 01;
- tm.hour= 0;
- tm.minute = 0;
- tm.second = 10;
- tm.millisecond = 990;
- /* Write the RTC time information. */
- ret = RtcWriteTime(handle, &tm);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC alarm time to 2020/01/01 00:00:30 .100. */
- alarmTime.year = 2020;
- alarmTime.month = 01;
- alarmTime.day = 01;
- alarmTime.hour = 0;
- alarmTime.minute = 0;
- alarmTime.second = 30;
- alarmTime.millisecond = 100;
- /* Set the alarm time information for RTC_ALARM_INDEX_A. When the specified time is reached, "RTC Alarm A callback function" is printed. */
- ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
- if (ret != 0) {
- /* Process the error. */
- }
-
- /* Read the RTC real time. */
- ret = RtcReadTime(handle, &tm);
- if (ret != 0) {
- /* Process the error. */
- }
- sleep(5)
- printf("RTC read time:\n\r");
- printf("year-month-date-weekday hour:minute:second .millisecond %04u-%02u-%02u-%u %02u:%02u:%02u .%03u",
- tm.year, tm.month, tm.day, tm.weekday, tm.hour, tm.minute, tm.second, tm.millisecond);
- /* Release the RTC device handle. */
- RtcClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/rtc-usage-guidelines.md b/en/device-dev/driver/rtc-usage-guidelines.md
deleted file mode 100644
index 3d0a2f6638021e4ab54ec680a06b134a873685b8..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-usage-guidelines.md
+++ /dev/null
@@ -1,741 +0,0 @@
-# RTC Usage Guidelines
-
-- [How to Use](#section620515765714)
-- [Creating an RTC Device Handle](#section0702183665711)
-- [Releasing the RTC Device Handle](#section639962619542)
-- [Registering RtcAlarmCallback](#section123631358135713)
-- [Performing RTC-related Operations](#section11091522125812)
-
-## How to Use
-
-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 an RTC device.
-
-**Figure 1** Process of using an RTC device
-
-
-
-
-## Creating an RTC Device Handle
-
-After the RTC driver is loaded successfully, you can use the API provided by the HDF and call APIs of the RTC driver.
-
-> **NOTE:**
->Currently, only one RTC device is supported in the OS.
-
-DevHandle RtcOpen\(void\);
-
-**Table 1** Description of **RtcOpen**
-
-
-
Parameter
-
-
Description
-
-
-
void
-
-
N/A
-
-
-
Return Value
-
-
Description
-
-
-
handle
-
-
Returns the pointer if the operation is successful.
-
-
-
NULL
-
-
The operation fails.
-
-
-
-
-
-```
-DevHandle handle = NULL;
-
-/* Obtain the RTC device handle. */
-handle = RtcOpen();
-if (handle == NULL) {
- /* Process the error. */
-}
-```
-
-## Releasing the RTC Device Handle
-
-You can call the following function to release the RTC device handle, thereby releasing resources of the device:
-
-void RtcClose\(DevHandle handle\);
-
-**Table 2** Description of **RtcClose**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle
-
-
-
-
-
-```
-/* Release the RTC device handle. */
-RtcClose(handle);
-```
-
-## Registering RtcAlarmCallback
-
-After the OS is started, call the following function to register **RtcAlarmCallback**, which will be invoked when an alarm is generated at the specified time:
-
-int32\_t RtcRegisterAlarmCallback\(DevHandle handle, enum RtcAlarmIndex alarmIndex, RtcAlarmCallback cb\);
-
-**Table 3** Description of **RtcRegisterAlarmCallback**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
cb
-
-
Callback that will be invoked when an alarm is generated at the specified time.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
-
-```
-/* Register an RTC alarm callback. */
-int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
-{
- if (alarmIndex == RTC_ALARM_INDEX_A) {
- /* Process alarm A. */
- } else if (alarmIndex == RTC_ALARM_INDEX_B) {
- /* Process alarm B. */
- } else {
- /* Process the error. */
- }
- return 0;
-}
-int32_t ret;
-/* Register RtcAlarmCallback for alarm A. */
-ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-## Performing RTC-related Operations
-
-- Reading RTC time
-
-Call the following function to read time information from the RTC driver, including the year, month, the day fo the week, day, hour, minute, second, and millisecond:
-
-int32\_t RtcReadTime\(DevHandle handle, struct RtcTime \*time\);
-
-**Table 4** Description of **RtcReadTime**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
time
-
-
Pointer to the time information read from the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-struct RtcTime tm;
-
-/* Read time information from the RTC driver. */
-ret = RtcReadTime(handle, &tm);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting RTC time
-
-Call the following function to set the RTC time:
-
-int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
-
-**Table 5** Description of **RtcWriteTime**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
time
-
-
Pointer to the time information written into the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-> **NOTE:**
->The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
-
-```
-int32_t ret;
-struct RtcTime tm;
-
-/* Set the RTC time to UTC 2020/01/01 00:59:00 .000. */
-tm.year = 2020;
-tm.month = 01;
-tm.day = 01;
-tm.hour= 00;
-tm.minute = 59;
-tm.second = 00;
-tm.millisecond = 0;
-/* Write the RTC time information. */
-ret = RtcWriteTime(handle, &tm);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading the RTC alarm time
-
-Call the following function to read the alarm time:
-
-int32\_t RtcReadAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
-
-**Table 6** Description of **RtcReadAlarm**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
time
-
-
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-struct RtcTime alarmTime;
-
-/* Read the RTC alarm time information of alarm RTC_ALARM_INDEX_A. */
-ret = RtcReadAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting RTC alarm time
-
-Call the following function to set the RTC alarm time based on the alarm index:
-
-int32\_t RtcWriteAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
-
-**Table 7** Description of **RtcWriteAlarm**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
time
-
-
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-> **NOTE:**
->The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
-
-```
-int32_t ret;
-struct RtcTime alarmTime;
-
-/* Set the RTC alarm time to 2020/01/01 00:59:59 .000. */
-alarmTime.year = 2020;
-alarmTime.month = 01;
-alarmTime.day = 01;
-alarmTime.hour = 00;
-alarmTime.minute = 59;
-alarmTime.second = 59;
-alarmTime.millisecond = 0;
-/* Set the alarm time of alarm RTC_ALARM_INDEX_A. */
-ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Enabling or disabling alarm interrupts
-
-Before performing alarm operations, use this function to enable alarm interrupts, so that **RtcAlarmCallback** will be called when the alarm is not generated upon a timeout.
-
-int32\_t RtcAlarmInterruptEnable\(DevHandle handle, enum RtcAlarmIndex alarmIndex, uint8\_t enable\);
-
-**Table 8** Description of **RtcAlarmInterruptEnable**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
enable
-
-
Whether to enable RTC alarm interrupts. Value 1 means to enable alarm interrupts and value 0 means to disable alarm interrupts.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-
-/* Enable the RTC alarm interrupts. */
-ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading RTC external frequency
-
-Call the following function to read the frequency of the external crystal oscillator connected to the RTC driver:
-
-int32\_t RtcGetFreq\(DevHandle handle, uint32\_t \*freq\);
-
-**Table 9** Description of **RtcGetFreq**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
freq
-
-
Frequency to set for the external crystal oscillator, in Hz.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint32_t freq = 0;
-
-/* Read frequency of the external crystal oscillator connected to the RTC driver */
-ret = RtcGetFreq(handle, &freq);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting the frequency of the external crystal oscillator connected to the RTC driver
-
-Call the following function to set the frequency of the external crystal oscillator connected to the RTC driver:
-
-int32\_t RtcSetFreq\(DevHandle handle, uint32\_t freq\);
-
-**Table 10** Description of **RtcSetFreq**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
freq
-
-
Frequency to set for the external crystal oscillator, in Hz.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint32_t freq = 32768; /* 32768 Hz */
-
-/* Set the frequency of the external crystal oscillator. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
-ret = RtcSetFreq(handle, freq);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Resetting the RTC driver
-
-Call the following function to perform a reset on the RTC driver. After the reset, the registers are restored to the default values:
-
-int32\_t RtcReset\(DevHandle handle\);
-
-**Table 11** Description of **RtcReset**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-
-/* Reset the RTC driver. After the reset, the configuration registers are restored to the default values. */
-ret = RtcReset(handle);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading the configuration of a custom RTC register
-
-Call the following function to read the configuration of a custom RTC register based on the register index \(one index corresponds to one byte of the configuration value\):
-
-int32\_t RtcReadReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t \*value\);
-
-**Table 12** Description of **RtcReadReg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
usrDefIndex
-
-
Index of the custom register.
-
-
-
value
-
-
Register value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
-uint8_t value = 0;
-
-/* Read the configuration of a custom RTC register based on the register index. One index corresponds to one byte of the configuration value. */
-ret = RtcReadReg(handle, usrDefIndex, &value);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting the configuration of a custom RTC register
-
-Call the following function to configure a register based on the specified register index \(one index corresponds to one byte of the configuration value\):
-
-int32\_t RtcWriteReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t value\);
-
-**Table 13** Description of **RtcWriteReg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
usrDefIndex
-
-
Index of the custom register.
-
-
-
value
-
-
Register value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
-uint8_t value = 0x10;
-
-/* Configure a register based on the specified register index. One index corresponds to one byte of the configuration value. */
-ret = RtcWriteReg(handle, usrDefIndex, value);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
diff --git a/en/device-dev/driver/rtc.md b/en/device-dev/driver/rtc.md
index 50b89f7b7c1fb24aeac3e2922dce7da627864006..322dac86cfa1e366118f70852c8c37e589ee9695 100644
--- a/en/device-dev/driver/rtc.md
+++ b/en/device-dev/driver/rtc.md
@@ -1,9 +1,944 @@
-# RTC
+# RTC
-- **[RTC Overview](rtc-overview.md)**
+- [Overview](#section104842041574)
+ - [Available APIs](#section3373340142215)
-- **[RTC Usage Guidelines](rtc-usage-guidelines.md)**
+- [Usage Guidelines](#section20636145604113)
+ - [How to Use](#section16919828134215)
+ - [Creating an RTC Device Handle](#section1131212144310)
+ - [Releasing the RTC Device Handle](#section10744117144314)
+ - [Registering RtcAlarmCallback](#section14839440184320)
+ - [Performing RTC-related Operations](#section161927578433)
-- **[RTC Usage Example](rtc-usage-example.md)**
+- [Usage Example](#section1186111020456)
+## Overview
+
+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
+
+**Table 1** APIs provided by the RTC driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
RTC handle
+
+
RtcOpen
+
+
Opens the RTC device to obtain its handle.
+
+
+
RtcClose
+
+
Releases a specified handle of the RTC device.
+
+
+
RTC time
+
+
RtcReadTime
+
+
Reads time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
RtcWriteTime
+
+
Writes time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
RTC alarm
+
+
RtcReadAlarm
+
+
Reads the RTC alarm time that was set last time.
+
+
+
RtcWriteAlarm
+
+
Writes the RTC alarm time based on the alarm index.
+
+
+
RtcRegisterAlarmCallback
+
+
Registers RtcAlarmCallback that will be invoked when an alarm is generated at the specified time.
+
+
+
RtcAlarmInterruptEnable
+
+
Enables or disables RTC alarm interrupts.
+
+
+
RTC configuration
+
+
RtcGetFreq
+
+
Reads the frequency of the external crystal oscillator connected to the RTC driver.
+
+
+
RtcSetFreq
+
+
Sets the frequency of the external crystal oscillator connected to the RTC driver.
+
+
+
RtcReset
+
+
Resets the RTC.
+
+
+
Custom register
+
+
RtcReadReg
+
+
Reads the configuration of a custom RTC register based on the register index.
+
+
+
RtcWriteReg
+
+
Writes the configuration of a custom RTC register based on the register index.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+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
+
+
+
+
+### Creating an RTC Device Handle
+
+After the RTC driver is loaded, you can use the API provided by the HDF and call APIs of the RTC driver.
+
+> **NOTE:**
+>Currently, only one RTC device is supported in the OS.
+
+DevHandle RtcOpen\(void\);
+
+**Table 2** Description of RtcOpen
+
+
+
Parameter
+
+
Description
+
+
+
void
+
+
NA
+
+
+
Return Value
+
+
Description
+
+
+
handle
+
+
Returns the if the operation is successful.
+
+
+
NULL
+
+
The operation fails.
+
+
+
+
+
+```
+DevHandle handle = NULL;
+
+/* Obtain the RTC device handle. */
+handle = RtcOpen();
+if (handle == NULL) {
+ /* Process the error. */
+}
+```
+
+### Releasing the RTC Device Handle
+
+You can call the following function to release the RTC device handle, thereby releasing resources of the device:
+
+void RtcClose\(DevHandle handle\);
+
+**Table 3** Description of RtcClose
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
+
+
+```
+/* Release the RTC device handle. */
+RtcClose(handle);
+```
+
+### Registering RtcAlarmCallback
+
+After the OS is started, call the following function to register **RtcAlarmCallback**, which will be invoked when an alarm is generated at the specified time:
+
+int32\_t RtcRegisterAlarmCallback\(DevHandle handle, enum RtcAlarmIndex alarmIndex, RtcAlarmCallback cb\);
+
+**Table 4** Description of RtcRegisterAlarmCallback
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
cb
+
+
Callback that will be invoked when an alarm is generated at the specified time.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
+
+```
+/* Register an RTC alarm callback. */
+int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
+{
+ if (alarmIndex == RTC_ALARM_INDEX_A) {
+ /* Process alarm A. */
+ } else if (alarmIndex == RTC_ALARM_INDEX_B) {
+ /* Process alarm B. */
+ } else {
+ /* Process the error. */
+ }
+ return 0;
+}
+int32_t ret;
+/* Register RtcAlarmCallback for alarm A. */
+ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+### Performing RTC-related Operations
+
+- Reading RTC time
+
+Call the following function to read time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond:
+
+int32\_t RtcReadTime\(DevHandle handle, struct RtcTime \*time\);
+
+**Table 5** Description of RtcReadTime
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
time
+
+
Pointer to the time information read from the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+struct RtcTime tm;
+
+/* Read time information from the RTC driver. */
+ret = RtcReadTime(handle, &tm);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting RTC time
+
+Call the following function to set the RTC time:
+
+int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
+
+**Table 6** Description of RtcWriteTime
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
time
+
+
Pointer to the time information written into the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+> **NOTE:**
+>The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
+
+```
+int32_t ret;
+struct RtcTime tm;
+
+/* Set the RTC time to UTC 2020/01/01 00:59:00 .000. */
+tm.year = 2020;
+tm.month = 01;
+tm.day = 01;
+tm.hour= 00;
+tm.minute = 59;
+tm.second = 00;
+tm.millisecond = 0;
+/* Write the RTC time information. */
+ret = RtcWriteTime(handle, &tm);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading the RTC alarm time
+
+Call the following function to read the alarm time:
+
+int32\_t RtcReadAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
+
+**Table 7** Description of RtcReadAlarm
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
time
+
+
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+struct RtcTime alarmTime;
+
+/* Read the RTC alarm time information of alarm RTC_ALARM_INDEX_A. */
+ret = RtcReadAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting RTC alarm time
+
+Call the following function to set the RTC alarm time based on the alarm index:
+
+int32\_t RtcWriteAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
+
+**Table 8** Description of RtcWriteAlarm
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
time
+
+
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+> **NOTE:**
+>The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
+
+```
+int32_t ret;
+struct RtcTime alarmTime;
+
+/* Set the RTC alarm time to 2020/01/01 00:59:59 .000. */
+alarmTime.year = 2020;
+alarmTime.month = 01;
+alarmTime.day = 01;
+alarmTime.hour = 00;
+alarmTime.minute = 59;
+alarmTime.second = 59;
+alarmTime.millisecond = 0;
+/* Set the alarm time of alarm RTC_ALARM_INDEX_A. */
+ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Enabling or disabling alarm interrupts
+
+Before performing alarm operations, use the following function to enable alarm interrupts, so that **RtcAlarmCallback** will be called when the alarm is not generated upon a timeout:
+
+int32\_t RtcAlarmInterruptEnable\(DevHandle handle, enum RtcAlarmIndex alarmIndex, uint8\_t enable\);
+
+**Table 9** Description of RtcAlarmInterruptEnable
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
enable
+
+
Whether to enable RTC alarm interrupts. The value 1 means to enable alarm interrupts and 0 means to disable alarm interrupts.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+
+/* Enable the RTC alarm interrupts. */
+ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading RTC external frequency
+
+Call the following function to read the frequency of the external crystal oscillator connected to the RTC driver:
+
+int32\_t RtcGetFreq\(DevHandle handle, uint32\_t \*freq\);
+
+**Table 10** Description of RtcGetFreq
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
freq
+
+
Pointer to the frequency to set for the external crystal oscillator, in Hz.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint32_t freq = 0;
+
+/* Read frequency of the external crystal oscillator connected to the RTC driver */
+ret = RtcGetFreq(handle, &freq);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting the frequency of the external crystal oscillator connected to the RTC driver
+
+Call the following function to set the frequency of the external crystal oscillator connected to the RTC driver:
+
+int32\_t RtcSetFreq\(DevHandle handle, uint32\_t freq\);
+
+**Table 11** Description of RtcSetFreq
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
freq
+
+
Frequency to set for the external crystal oscillator, in Hz
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint32_t freq = 32768; /* 32768 Hz */
+
+/* Set the frequency of the external crystal oscillator. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
+ret = RtcSetFreq(handle, freq);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Resetting the RTC driver
+
+Call the following function to perform a reset on the RTC driver \(after the reset, the registers are restored to the default values\):
+
+int32\_t RtcReset\(DevHandle handle\);
+
+**Table 12** Description of RtcReset
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+
+/* Reset the RTC driver. After the reset, the configuration registers are restored to the default values. */
+ret = RtcReset(handle);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading the configuration of a custom RTC register
+
+Call the following function to read the configuration of a custom RTC register based on the register index \(one index corresponds to one byte of the configuration value\):
+
+int32\_t RtcReadReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t \*value\);
+
+**Table 13** Description of RtcReadReg
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
usrDefIndex
+
+
Index of the custom register
+
+
+
value
+
+
Pointer to the register value
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
+uint8_t value = 0;
+
+/* Read the configuration of a custom RTC register based on the register index. One index corresponds to one byte of the configuration value. */
+ret = RtcReadReg(handle, usrDefIndex, &value);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting the configuration of a custom RTC register
+
+Call the following function to configure a register based on the specified register index \(one index corresponds to one byte of the configuration value\):
+
+int32\_t RtcWriteReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t value\);
+
+**Table 14** Description of RtcWriteReg
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
usrDefIndex
+
+
Index of the custom register
+
+
+
value
+
+
Register value
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
+uint8_t value = 0x10;
+
+/* Configure a register based on the specified register index. One index corresponds to one byte of the configuration value. */
+ret = RtcWriteReg(handle, usrDefIndex, value);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+## Usage Example
+
+This section describes the process of using RTC APIs:
+
+1. During the OS startup, the HDF identifies the RTC component in the system.
+2. The HDF initializes and creates the RTC device.
+3. You can perform operations on the RTC device by calling different APIs.
+4. Call the **RtcClose** function to release the device handle and device resources.
+
+Example:
+
+```
+#include "rtc_if.h"
+int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
+{
+ if (alarmIndex == RTC_ALARM_INDEX_A) {
+ /* Process alarm A. */
+ printf("RTC Alarm A callback function\n\r");
+ } else if (alarmIndex == RTC_ALARM_INDEX_B) {
+ /* Process alarm B. */
+ printf("RTC Alarm B callback function\n\r");
+ } else {
+ /* Process the error. */
+ }
+ return 0;
+}
+
+void RtcTestSample(void)
+{
+ int32_t ret;
+ struct RtcTime tm;
+ struct RtcTime alarmTime;
+ uint32_t freq;
+ DevHandle handle = NULL;
+
+ /* Obtain the RTC device handle. */
+ handle = RtcOpen();
+ if (handle == NULL) {
+ /* Process the error. */
+ }
+ /* Register RtcAlarmCallback for alarm A. */
+ ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC external crystal frequency. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
+ freq = 32768; /* 32768 Hz */
+ ret = RtcSetFreq(handle, freq);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Enable the RTC alarm interrupts. */
+ ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC time to 2020/01/01 00:00:10 .990. */
+ tm.year = 2020;
+ tm.month = 01;
+ tm.day = 01;
+ tm.hour= 0;
+ tm.minute = 0;
+ tm.second = 10;
+ tm.millisecond = 990;
+ /* Write the RTC time information. */
+ ret = RtcWriteTime(handle, &tm);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC alarm time to 2020/01/01 00:00:30 .100. */
+ alarmTime.year = 2020;
+ alarmTime.month = 01;
+ alarmTime.day = 01;
+ alarmTime.hour = 0;
+ alarmTime.minute = 0;
+ alarmTime.second = 30;
+ alarmTime.millisecond = 100;
+ /* Set the alarm time information for RTC_ALARM_INDEX_A. When the specified time is reached, "RTC Alarm A callback function" is printed. */
+ ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+
+ /* Read the RTC real time. */
+ ret = RtcReadTime(handle, &tm);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ sleep(5)
+ printf("RTC read time:\n\r");
+ printf("year-month-date-weekday hour:minute:second .millisecond %04u-%02u-%02u-%u %02u:%02u:%02u .%03u",
+ tm.year, tm.month, tm.day, tm.weekday, tm.hour, tm.minute, tm.second, tm.millisecond);
+ /* Release the RTC device handle. */
+ RtcClose(handle);
+}
+```
diff --git a/en/device-dev/driver/sdio.md b/en/device-dev/driver/sdio.md
index 43fb762051920268c93821121065cd4ebec24ecb..f286ab45ca7e495c1c1e060d8bc06989342588cc 100644
--- a/en/device-dev/driver/sdio.md
+++ b/en/device-dev/driver/sdio.md
@@ -1,9 +1,1068 @@
-# SDIO
+# SDIO
-- **[SDIO Overview](sdiooverview.md)**
+- [Overview](#section1155271783811)
+ - [Available APIs](#section08064247248)
-- **[SDIO Usage Guidelines](sdiousage-guidelines.md)**
+- [Usage Guidelines](#section1878939192515)
+ - [How to Use](#section1490685512255)
+ - [Opening an SDIO Controller](#section10782428132616)
+ - [Claiming a Host Exclusively](#section11263172312715)
+ - [Enabling the SDIO Device](#section17861486271)
+ - [Claiming an SDIO IRQ](#section521213262286)
+ - [Performing SDIO Communication](#section85661522153420)
+ - [Releasing the SDIO IRQ](#section1683449352)
+ - [Disabling the SDIO Device](#section15379324143611)
+ - [Releasing the Exclusively Claimed Host](#section536018263713)
+ - [Closing an SDIO Controller](#section4752739183716)
-- **[SDIO Usage Example](sdiousage-example.md)**
+- [Usage Example](#section376910122382)
+## Overview
+
+- Secure Digital Input/Output \(SDIO\) is a peripheral interface evolved from the Secure Digital \(SD\) memory card interface. The SDIO interface is compatible with SD memory cards and can be connected to devices that support the SDIO interface.
+- SDIO is widely used. Currently, many smartphones support SDIO, and many SDIO peripherals are developed for connections to smartphones. Common SDIO peripherals include WLAN, GPS, cameras, and Bluetooth.
+- The SDIO bus has two ends, named host and device. All communication starts when the host sends a command. The device can communicate with the host as long as it can parse the command of the host. An SDIO host can connect to multiple devices, as shown in the figure below.
+
+ - CLK signal: clock signal sent from the host to the device
+ - VDD signal: power signal
+ - VSS signal: ground signal
+ - D0-3 signal: four data lines. The DAT1 signal cable is multiplexed as the interrupt line. In 1-bit mode, DAT0 is used to transmit data. In 4-bit mode, DAT0 to DAT3 are used to transmit data.
+ - CMD signal: used by the host to send commands and the device to respond to commands.
+
+ **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
+
+**Table 1** APIs available for the SDIO driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
SDIO device opening/closing
+
+
SdioOpen
+
+
Opens an SDIO controller with a specified bus number.
+
+
+
SdioClose
+
+
Closes an SDIO controller.
+
+
+
SDIO reading/writing
+
+
SdioReadBytes
+
+
Incrementally reads a given length of data from a specified SDIO address.
+
+
+
SdioWriteBytes
+
+
Incrementally writes a given length of data into a specified SDIO address.
+
+
+
SdioReadBytesFromFixedAddr
+
+
Reads a given length of data from a fixed SDIO address.
+
+
+
SdioWriteBytesToFixedAddr
+
+
Writes a given length of data into a fixed SDIO address.
+
+
+
SdioReadBytesFromFunc0
+
+
Reads a given length of data from the address space of SDIO function 0.
+
+
+
SdioWriteBytesToFunc0
+
+
Writes a given length of data into the address space of SDIO function 0.
+
+
+
SDIO block size setting
+
+
SdioSetBlockSize
+
+
Sets the block size.
+
+
+
SDIO common information retrieval/setting
+
+
SdioGetCommonInfo
+
+
Obtains common information.
+
+
+
SdioSetCommonInfo
+
+
Sets common information.
+
+
+
SDIO data flushing
+
+
SdioFlushData
+
+
Flushes data.
+
+
+
SDIO host exclusively claiming or releasing
+
+
SdioClaimHost
+
+
Claims a host exclusively.
+
+
+
SdioReleaseHost
+
+
Releases the exclusively claimed host.
+
+
+
SDIO device enablement
+
+
SdioEnableFunc
+
+
Enables an SDIO device.
+
+
+
SdioDisableFunc
+
+
Disables an SDIO device.
+
+
+
SDIO IRQ claiming/releasing
+
+
SdioClaimIrq
+
+
Claims an SDIO IRQ.
+
+
+
SdioReleaseIrq
+
+
Releases an SDIO IRQ.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig1343742311264) illustrates the process of using an SDIO.
+
+**Figure 2** Process of using an SDIO
+
+
+
+
+### Opening an SDIO Controller
+
+Before performing SDIO communication, obtain the device handle of an SDIO controller by calling **SdioOpen**. This function returns the device handle of the SDIO controller with a specified bus number.
+
+DevHandle SdioOpen\(int16\_t mmcBusNum, struct SdioFunctionConfig \*config\);
+
+**Table 2** Parameters and return values of SdioOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
mmcBusNum
+
+
Bus number.
+
+
+
config
+
+
SDIO functionality configurations.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain the device handle of an SDIO controller.
+
+
+
Device handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to open an SDIO controller.
+
+```
+DevHandle handle = NULL;
+struct SdioFunctionConfig config;
+config.funcNr = 1;
+config.vendorId = 0x123;
+config.deviceId = 0x456;
+/* Open an SDIO controller whose bus number is 1. */
+handle = SdioOpen(1, &config);
+if (handle == NULL) {
+ HDF_LOGE("SdioOpen: failed!\n");
+}
+```
+
+### Claiming a Host Exclusively
+
+After obtaining the device handle of an SDIO controller, exclusively claim the host before performing subsequent operations on the SDIO device.
+
+void SdioClaimHost\(DevHandle handle\);
+
+**Table 3** Parameter description of SdioClaimHost
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to exclusively claim a host.
+
+```
+SdioClaimHost(handle); /* Claim a host exclusively. */
+```
+
+### Enabling the SDIO Device
+
+Before accessing a register, enable the SDIO device.
+
+int32\_t SdioEnableFunc\(DevHandle handle\);
+
+**Table 4** Parameters and return values of SdioEnableFunc
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO device is enabled.
+
+
+
Negative value
+
+
Failed to enable the SDIO device.
+
+
+
+
+
+The following example shows how to enable the SDIO device.
+
+```
+int32_t ret;
+/* Enable the SDIO device. */
+ret = SdioEnableFunc(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
+}
+```
+
+### Claiming an SDIO IRQ
+
+Before SDIO communication, claim an SDIO IRQ.
+
+int32\_t SdioClaimIrq\(DevHandle handle, SdioIrqHandler \*handler\);
+
+**Table 5** Parameters and return values of SdioClaimIrq
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
handler
+
+
Pointer to the SDIO IRQ function.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO IRQ is claimed.
+
+
+
Negative value
+
+
Failed to claim an SDIO IRQ.
+
+
+
+
+
+The following example shows how to claim an SDIO IRQ.
+
+```
+/* Implement the SDIO IRQ function based on the application. */
+static void SdioIrqFunc(void *data)
+{
+ if (data == NULL) {
+ HDF_LOGE("SdioIrqFunc: data is NULL.\n");
+ return;
+ }
+ /* You need to add specific implementations. */
+}
+
+int32_t ret;
+/* Claim an SDIO IRQ. */
+ret = SdioClaimIrq(handle, SdioIrqFunc);
+if (ret != 0) {
+ HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
+}
+```
+
+### Performing SDIO Communication
+
+- Incrementally write a given length of data into the SDIO device.
+
+The corresponding function is as follows:
+
+int32\_t SdioWriteBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 6** Parameters and return values of SdioWriteBytes
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Start address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+The following example shows how to incrementally write a given length of data into the SDIO device.
+
+```
+int32_t ret;
+uint8_t wbuff[] = {1,2,3,4,5};
+uint32_t addr = 0x100 + 0x09;
+/* Incrementally write 5-byte data into the start address 0x109 of the SDIO device. */
+ret = SdioWriteBytes(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]));
+if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+}
+```
+
+- Incrementally read a given length of data from the SDIO device.
+
+The corresponding function is as follows:
+
+int32\_t SdioReadBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 7** Parameters and return values of SdioReadBytes
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+The following example shows how to incrementally read a given length of data from the SDIO device.
+
+```
+int32_t ret;
+uint8_t rbuff[5] = {0};
+uint32_t addr = 0x100 + 0x09;
+/* Incrementally read 5-byte data from the start address 0x109 of the SDIO device. */
+ret = SdioReadBytes(handle, rbuff, addr, 5);
+if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+}
+```
+
+- Write a given length of data into the fixed address of an SDIO device.
+
+ The corresponding function is as follows:
+
+ int32\_t SdioWriteBytesToFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
+
+ **Table 8** Parameters and return values of SdioWriteBytesToFixedAddr
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Fixed address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
scatterLen
+
+
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+ The following example shows how to write a given length of data into the fixed address of an SDIO device.
+
+ ```
+ int32_t ret;
+ uint8_t wbuff[] = {1, 2, 3, 4, 5};
+ uint32_t addr = 0x100 + 0x09;
+ /* Write 5-byte data into the fixed address 0x109 of the SDIO device. */
+ ret = SdioWriteBytesToFixedAddr(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]), 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
+ }
+ ```
+
+- Read a given length of data from the fixed address of an SDIO device.
+
+ The corresponding function is as follows:
+
+ int32\_t SdioReadBytesFromFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
+
+ **Table 9** Parameters and return values of SdioReadBytesFromFixedAddr
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
scatterLen
+
+
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+ The following example shows how to read a given length of data from the fixed address of an SDIO device.
+
+ ```
+ int32_t ret;
+ uint8_t rbuff[5] = {0};
+ uint32_t addr = 0x100 + 0x09;
+ /* Read 5-byte data from the fixed address 0x109 of the SDIO device. */
+ ret = SdioReadBytesFromFixedAddr(handle, rbuff, addr, 5, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
+ }
+ ```
+
+
+- Writes a given length of data into the address space of SDIO function 0.
+
+Currently, only 1-byte data can be written. The corresponding function is as follows:
+
+int32\_t SdioWriteBytesToFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 10** Parameters and return values of SdioWriteBytesToFunc0
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Start address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+The following example shows how to write a given length of data into the address space of SDIO function 0.
+
+```
+int32_t ret;
+uint8_t wbuff = 1;
+/* Write 1-byte data into the address 0x2 of SDIO function 0. */
+ret = SdioWriteBytesToFunc0(handle, &wbuff, 0x2, 1);
+if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
+}
+```
+
+- Reads a given length of data from the address space of SDIO function 0.
+
+Currently, only 1-byte data can be read. The corresponding function is as follows:
+
+int32\_t SdioReadBytesFromFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 11** Parameters and return values of SdioReadBytesFromFunc0
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+The following example shows how to read a given length of data from the address space of SDIO function 0.
+
+```
+int32_t ret;
+uint8_t rbuff;
+/* Read 1-byte data from the address 0x2 of SDIO function 0. */
+ret = SdioReadBytesFromFunc0(handle, &rbuff, 0x2, 1);
+if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
+}
+```
+
+### Releasing the SDIO IRQ
+
+After the SDIO communication, release the SDIO IRQ.
+
+int32\_t SdioReleaseIrq\(DevHandle handle\);
+
+**Table 12** Parameters and return values of SdioReleaseIrq
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO IRQ is released.
+
+
+
Negative value
+
+
Failed to release the SDIO IRQ.
+
+
+
+
+
+The following example shows how to release the SDIO IRQ.
+
+```
+int32_t ret;
+/* Release the SDIO IRQ. */
+ret = SdioReleaseIrq(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
+}
+```
+
+### Disabling the SDIO Device
+
+After the SDIO communication, disable the SDIO device.
+
+int32\_t SdioDisableFunc\(DevHandle handle\);
+
+**Table 13** Parameters and return values of SdioDisableFunc
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO device is disabled.
+
+
+
Negative value
+
+
Failed to disable the SDIO device.
+
+
+
+
+
+The following example shows how to disable the SDIO device.
+
+```
+int32_t ret;
+/* Disable the SDIO device. */
+ret = SdioDisableFunc(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
+}
+```
+
+### Releasing the Exclusively Claimed Host
+
+After the SDIO communication, release the exclusively claimed host.
+
+void SdioReleaseHost\(DevHandle handle\);
+
+**Table 14** Parameter description of SdioReleaseHost
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to release the exclusively claimed host.
+
+```
+SdioReleaseHost(handle); /* Release the exclusively claimed host. */
+```
+
+### Closing an SDIO Controller
+
+After the SDIO communication, close the SDIO controller.
+
+void SdioClose\(DevHandle handle\);
+
+This function releases the resources requested.
+
+**Table 15** Parameter description of SdioClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to close an SDIO controller.
+
+```
+SdioClose(handle); /* Close an SDIO controller. */
+```
+
+## Usage Example
+
+The following example shows how to use an SDIO device. First, open an SDIO controller whose bus number is 1, exclusively claim a host, enable the SDIO device, claim an SDIO IRQ, and then perform SDIO communication \(such as reading and writing\). After the SDIO communication, release the SDIO IRQ, disable the SDIO device, release the host, and close the SDIO controller.
+
+```
+#include "hdf_log.h"
+#include "sdio_if.h"
+
+#define TEST_FUNC_NUM 1 /* The I/O function whose ID is 1 is used. */
+#define TEST_FBR_BASE_ADDR 0x100 /* FBR base address of the I/O function whose ID is 1 */
+#define TEST_ADDR_OFFSET 9 /* Address offset of the register to read or write */
+#define TEST_DATA_LEN 3 /* Length of the data to read or write */
+#define TEST_BLOCKSIZE 2 /* Size of a data block, in bytes */
+
+/* Implement the SDIO IRQ function based on the application. */
+static void SdioIrqFunc(void *data)
+{
+ if (data == NULL) {
+ HDF_LOGE("SdioIrqFunc: data is NULL.\n");
+ return;
+ }
+ /* You need to add specific implementations. */
+}
+
+void SdioTestSample(void)
+{
+ int32_t ret;
+ DevHandle handle = NULL;
+ uint8_t data[TEST_DATA_LEN] = {0};
+ struct SdioFunctionConfig config = {1, 0x123, 0x456};
+ uint8_t val;
+ uint32_t addr;
+
+ /* Open an SDIO controller whose bus number is 1. */
+ handle = SdioOpen(1, &config);
+ if (handle == NULL) {
+ HDF_LOGE("SdioOpen: failed!\n");
+ return;
+ }
+ /* Claim a host exclusively. */
+ SdioClaimHost(handle);
+ /* Enable the SDIO device. */
+ ret = SdioEnableFunc(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
+ goto ENABLE_ERR;
+ }
+ /* Claim an SDIO IRQ. */
+ ret = SdioClaimIrq(handle, SdioIrqFunc);
+ if (ret != 0) {
+ HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
+ goto CLAIM_IRQ_ERR;
+ }
+ /* Set the block size to 2 bytes. */
+ ret = SdioSetBlockSize(handle, TEST_BLOCKSIZE);
+ if (ret != 0) {
+ HDF_LOGE("SdioSetBlockSize: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 3-byte data from the incremental address of an SDIO device. */
+ addr = TEST_FBR_BASE_ADDR * TEST_FUNC_NUM + TEST_ADDR_OFFSET;
+ ret = SdioReadBytes(handle, data, addr, TEST_DATA_LEN);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 3-byte data into the incremental address of an SDIO device. */
+ ret = SdioWriteBytes(handle, data, addr, TEST_DATA_LEN);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 1-byte data from the SDIO device. */
+ ret = SdioReadBytes(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data into the SDIO device. */
+ ret = SdioWriteBytes(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 3-byte data from the fixed address of an SDIO device. */
+ ret = SdioReadBytesFromFixedAddr(handle, data, addr, TEST_DATA_LEN, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data to the fixed address of an SDIO device. */
+ ret = SdioWriteBytesToFixedAddr(handle, data, addr, 1, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 1-byte data from SDIO function 0. */
+ addr = 0x02;
+ ret = SdioReadBytesFromFunc0(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data into SDIO function 0. */
+ ret = SdioWriteBytesToFunc0(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+COMM_ERR:
+ /* Release the SDIO IRQ. */
+ ret = SdioReleaseIrq(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
+ }
+CLAIM_IRQ_ERR:
+ /* Disable the SDIO device. */
+ ret = SdioDisableFunc(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
+ }
+ENABLE_ERR:
+ /* Release the exclusively claimed host. */
+ SdioReleaseHost(handle);
+ /* Close an SDIO controller. */
+ SdioClose(handle);
+}
+```
diff --git a/en/device-dev/driver/sdiooverview.md b/en/device-dev/driver/sdiooverview.md
deleted file mode 100644
index 9890cf8f3c60999f90d41db98e8143600066308b..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiooverview.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# SDIO Overview
-
-- [Introduction](#section1155271783811)
-- [Available APIs](#section10204143763819)
-
-## Introduction
-
-- Secure Digital Input/Output \(SDIO\) is a peripheral interface evolved from the Secure Digital \(SD\) memory card interface. The SDIO interface is compatible with SD memory cards and can be connected to devices that support the SDIO interface.
-- SDIO is widely used. Currently, many smartphones support SDIO, and many SDIO peripherals are developed for connections to smartphones. Common SDIO peripherals include WLAN, GPS, cameras, and Bluetooth.
-- The SDIO bus has two ends, named host and device. All communication starts when the host sends a command. The device can communicate with the host as long as it can parse the command of the host. An SDIO host can connect to multiple devices, as shown in the figure below.
-
- - CLK signal: clock signal sent from the host to the device
- - VDD signal: power signal
- - VSS signal: ground signal
- - D0-3 signal: four data lines. The DAT1 signal cable is multiplexed as the interrupt line. In 1-bit mode, DAT0 is used to transmit data. In 4-bit mode, DAT0 to DAT3 are used to transmit data.
- - CMD signal: used by the host to send commands and the device to respond to commands.
-
- **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
-
-**Table 1** APIs available for the SDIO driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
SDIO device opening/closing
-
-
SdioOpen
-
-
Opens an SDIO controller with a specified bus number.
-
-
-
SdioClose
-
-
Closes an SDIO controller.
-
-
-
SDIO reading/writing
-
-
SdioReadBytes
-
-
Incrementally reads a given length of data from a specified SDIO address.
-
-
-
SdioWriteBytes
-
-
Incrementally writes a given length of data into a specified SDIO address.
-
-
-
SdioReadBytesFromFixedAddr
-
-
Reads a given length of data from a fixed SDIO address.
-
-
-
SdioWriteBytesToFixedAddr
-
-
Writes a given length of data into a fixed SDIO address.
-
-
-
SdioReadBytesFromFunc0
-
-
Reads a given length of data from the address space of SDIO function 0.
-
-
-
SdioWriteBytesToFunc0
-
-
Writes a given length of data into the address space of SDIO function 0.
-
-
-
SDIO block size setting
-
-
SdioSetBlockSize
-
-
Sets the block size.
-
-
-
SDIO common information retrieval/setting
-
-
SdioGetCommonInfo
-
-
Obtains common information.
-
-
-
SdioSetCommonInfo
-
-
Sets common information.
-
-
-
SDIO data flushing
-
-
SdioFlushData
-
-
Flushes data.
-
-
-
SDIO host exclusively claiming or releasing
-
-
SdioClaimHost
-
-
Claims a host exclusively.
-
-
-
SdioReleaseHost
-
-
Releases the exclusively claimed host.
-
-
-
SDIO device enablement
-
-
SdioEnableFunc
-
-
Enables an SDIO device.
-
-
-
SdioDisableFunc
-
-
Disables an SDIO device.
-
-
-
SDIO IRQ claiming/releasing
-
-
SdioClaimIrq
-
-
Claims an SDIO IRQ.
-
-
-
SdioReleaseIrq
-
-
Releases an SDIO IRQ.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/sdiousage-example.md b/en/device-dev/driver/sdiousage-example.md
deleted file mode 100644
index 558f4cf191206f4a01f28850d14d667208b592fc..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiousage-example.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# SDIO Usage Example
-
-The following example shows how to use an SDIO device. First, open an SDIO controller whose bus number is 1, exclusively claim a host, enable the SDIO device, claim an SDIO IRQ, and then perform SDIO communication \(such as reading and writing\). After the SDIO communication, release the SDIO IRQ, disable the SDIO device, release the host, and close the SDIO controller.
-
-```
-#include "hdf_log.h"
-#include "sdio_if.h"
-
-#define TEST_FUNC_NUM 1 /* The I/O function whose ID is 1 is used. */
-#define TEST_FBR_BASE_ADDR 0x100 /* FBR base address of the I/O function whose ID is 1 */
-#define TEST_ADDR_OFFSET 9 /* Address offset of the register to read or write */
-#define TEST_DATA_LEN 3 /* Length of the data to read or write */
-#define TEST_BLOCKSIZE 2 /* Size of a data block, in bytes */
-
-/* Implement the SDIO IRQ function based on the application. */
-static void SdioIrqFunc(void *data)
-{
- if (data == NULL) {
- HDF_LOGE("SdioIrqFunc: data is NULL.\n");
- return;
- }
- /* You need to add specific implementations. */
-}
-
-void SdioTestSample(void)
-{
- int32_t ret;
- DevHandle handle = NULL;
- uint8_t data[TEST_DATA_LEN] = {0};
- struct SdioFunctionConfig config = {1, 0x123, 0x456};
- uint8_t val;
- uint32_t addr;
-
- /* Open an SDIO controller whose bus number is 1. */
- handle = SdioOpen(1, &config);
- if (handle == NULL) {
- HDF_LOGE("SdioOpen: failed!\n");
- return;
- }
- /* Claim a host exclusively. */
- SdioClaimHost(handle);
- /* Enable the SDIO device. */
- ret = SdioEnableFunc(handle);
- if (ret != 0) {
- HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
- goto ENABLE_ERR;
- }
- /* Claim an SDIO IRQ. */
- ret = SdioClaimIrq(handle, SdioIrqFunc);
- if (ret != 0) {
- HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
- goto CLAIM_IRQ_ERR;
- }
- /* Set the block size to 2 bytes. */
- ret = SdioSetBlockSize(handle, TEST_BLOCKSIZE);
- if (ret != 0) {
- HDF_LOGE("SdioSetBlockSize: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 3-byte data from the incremental address of an SDIO device. */
- addr = TEST_FBR_BASE_ADDR * TEST_FUNC_NUM + TEST_ADDR_OFFSET;
- ret = SdioReadBytes(handle, data, addr, TEST_DATA_LEN);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 3-byte data into the incremental address of an SDIO device. */
- ret = SdioWriteBytes(handle, data, addr, TEST_DATA_LEN);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 1-byte data from the SDIO device. */
- ret = SdioReadBytes(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data into the SDIO device. */
- ret = SdioWriteBytes(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 3-byte data from the fixed address of an SDIO device. */
- ret = SdioReadBytesFromFixedAddr(handle, data, addr, TEST_DATA_LEN, 0);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data to the fixed address of an SDIO device. */
- ret = SdioWriteBytesToFixedAddr(handle, data, addr, 1, 0);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 1-byte data from SDIO function 0. */
- addr = 0x02;
- ret = SdioReadBytesFromFunc0(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data into SDIO function 0. */
- ret = SdioWriteBytesToFunc0(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
-COMM_ERR:
- /* Release the SDIO IRQ. */
- ret = SdioReleaseIrq(handle);
- if (ret != 0) {
- HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
- }
-CLAIM_IRQ_ERR:
- /* Disable the SDIO device. */
- ret = SdioDisableFunc(handle);
- if (ret != 0) {
- HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
- }
-ENABLE_ERR:
- /* Release the exclusively claimed host. */
- SdioReleaseHost(handle);
- /* Close an SDIO controller. */
- SdioClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/sdiousage-guidelines.md b/en/device-dev/driver/sdiousage-guidelines.md
deleted file mode 100644
index 402cf305ebb98196a477530f749e0bc07f9710bd..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiousage-guidelines.md
+++ /dev/null
@@ -1,787 +0,0 @@
-# SDIO Usage Guidelines
-
-- [How to Use](#section1962415610383)
-- [Opening an SDIO Controller](#section814751015461)
-- [Claiming a Host Exclusively](#section49274582455)
-- [Enabling the SDIO Device](#section1431520410489)
-- [Claiming an SDIO IRQ](#section3662781537)
-- [Performing SDIO Communication](#section391941913484)
-- [Releasing the SDIO IRQ](#section56205204481)
-- [Disabling the SDIO Device](#section181181621124815)
-- [Releasing the Exclusively Claimed Host](#section657117215486)
-- [Closing an SDIO Controller](#section1898172114818)
-
-## How to Use
-
-[Figure 1](spiusage-guidelines.md#fig23885455594) illustrates the process of using an SDIO.
-
-**Figure 1** Process of using an SDIO
-
-
-
-
-## Opening an SDIO Controller
-
-Before performing SDIO communication, obtain the device handle of an SDIO controller by calling **SdioOpen**. This function returns the device handle of the SDIO controller with a specified bus number.
-
-DevHandle SdioOpen\(int16\_t mmcBusNum, struct SdioFunctionConfig \*config\);
-
-**Table 1** Parameters and return values of SdioOpen
-
-
-
Parameter
-
-
Description
-
-
-
-
mmcBusNum
-
-
Bus number.
-
-
-
config
-
-
SDIO functionality configurations.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the device handle of an SDIO controller.
-
-
-
Device handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to open an SDIO controller.
-
-```
-DevHandle handle = NULL;
-struct SdioFunctionConfig config;
-config.funcNr = 1;
-config.vendorId = 0x123;
-config.deviceId = 0x456;
-/* Open an SDIO controller whose bus number is 1. */
-handle = SdioOpen(1, &config);
-if (handle == NULL) {
- HDF_LOGE("SdioOpen: failed!\n");
-}
-```
-
-## Claiming a Host Exclusively
-
-After obtaining the device handle of an SDIO controller, exclusively claim the host before performing subsequent operations on the SDIO device.
-
-void SdioClaimHost\(DevHandle handle\);
-
-**Table 2** Parameter description of SdioClaimHost
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to exclusively claim a host.
-
-```
-SdioClaimHost(handle); /* Claim a host exclusively. */
-```
-
-## Enabling the SDIO Device
-
-Before accessing a register, enable the SDIO device.
-
-int32\_t SdioEnableFunc\(DevHandle handle\);
-
-**Table 3** Parameters and return values of SdioEnableFunc
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO device is enabled.
-
-
-
Negative value
-
-
Failed to enable the SDIO device.
-
-
-
-
-
-The following example shows how to enable the SDIO device.
-
-```
-int32_t ret;
-/* Enable the SDIO device. */
-ret = SdioEnableFunc(handle);
-if (ret != 0) {
- HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
-}
-```
-
-## Claiming an SDIO IRQ
-
-Before SDIO communication, claim an SDIO IRQ.
-
-int32\_t SdioClaimIrq\(DevHandle handle, SdioIrqHandler \*handler\);
-
-**Table 4** Parameters and return values of SdioClaimIrq
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
handler
-
-
Pointer to the SDIO IRQ function.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO IRQ is claimed.
-
-
-
Negative value
-
-
Failed to claim an SDIO IRQ.
-
-
-
-
-
-The following example shows how to claim an SDIO IRQ.
-
-```
-/* Implement the SDIO IRQ function based on the application. */
-static void SdioIrqFunc(void *data)
-{
- if (data == NULL) {
- HDF_LOGE("SdioIrqFunc: data is NULL.\n");
- return;
- }
- /* You need to add specific implementations. */
-}
-
-int32_t ret;
-/* Claim an SDIO IRQ. */
-ret = SdioClaimIrq(handle, SdioIrqFunc);
-if (ret != 0) {
- HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
-}
-```
-
-## Performing SDIO Communication
-
-- Incrementally write a given length of data into the SDIO device.
-
-The corresponding function is as follows:
-
-int32\_t SdioWriteBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 5** Parameters and return values of SdioWriteBytes
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Start address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
-The following example shows how to incrementally write a given length of data into the SDIO device.
-
-```
-int32_t ret;
-uint8_t wbuff[] = {1,2,3,4,5};
-uint32_t addr = 0x100 + 0x09;
-/* Incrementally write 5-byte data into the start address 0x109 of the SDIO device. */
-ret = SdioWriteBytes(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]));
-if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
-}
-```
-
-- Incrementally read a given length of data from the SDIO device.
-
-The corresponding function is as follows:
-
-int32\_t SdioReadBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 6** Parameters and return values of SdioReadBytes
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
-The following example shows how to incrementally read a given length of data from the SDIO device.
-
-```
-int32_t ret;
-uint8_t rbuff[5] = {0};
-uint32_t addr = 0x100 + 0x09;
-/* Incrementally read 5-byte data from the start address 0x109 of the SDIO device. */
-ret = SdioReadBytes(handle, rbuff, addr, 5);
-if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
-}
-```
-
-- Write a given length of data into the fixed address of an SDIO device.
-
- The corresponding function is as follows:
-
- int32\_t SdioWriteBytesToFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
-
- **Table 7** Parameters and return values of SdioWriteBytesToFixedAddr
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Fixed address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
scatterLen
-
-
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
- The following example shows how to write a given length of data into the fixed address of an SDIO device.
-
- ```
- int32_t ret;
- uint8_t wbuff[] = {1, 2, 3, 4, 5};
- uint32_t addr = 0x100 + 0x09;
- /* Write 5-byte data into the fixed address 0x109 of the SDIO device. */
- ret = SdioWriteBytesToFixedAddr(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]), 0);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
- }
- ```
-
-- Read a given length of data from the fixed address of an SDIO device.
-
- The corresponding function is as follows:
-
- int32\_t SdioReadBytesFromFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
-
- **Table 8** Parameters and return values of SdioReadBytesFromFixedAddr
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
scatterLen
-
-
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
- The following example shows how to read a given length of data from the fixed address of an SDIO device.
-
- ```
- int32_t ret;
- uint8_t rbuff[5] = {0};
- uint32_t addr = 0x100 + 0x09;
- /* Read 5-byte data from the fixed address 0x109 of the SDIO device. */
- ret = SdioReadBytesFromFixedAddr(handle, rbuff, addr, 5, 0);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
- }
- ```
-
-
-- Write a given length of data into the address space of SDIO function 0.
-
-Currently, only 1-byte data can be written. The corresponding function is as follows:
-
-int32\_t SdioWriteBytesToFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 9** Parameters and return values of SdioWriteBytesToFunc0
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Start address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
-The following example shows how to write a given length of data into the address space of SDIO function 0.
-
-```
-int32_t ret;
-uint8_t wbuff = 1;
-/* Write 1-byte data into the address 0x2 of SDIO function 0. */
-ret = SdioWriteBytesToFunc0(handle, &wbuff, 0x2, 1);
-if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
-}
-```
-
-- Read a given length of data from the address space of SDIO function 0.
-
-Currently, only 1-byte data can be read. The corresponding function is as follows:
-
-int32\_t SdioReadBytesFromFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 10** Parameters and return values of SdioReadBytesFromFunc0
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
-The following example shows how to read a given length of data from the address space of SDIO function 0.
-
-```
-int32_t ret;
-uint8_t rbuff;
-/* Read 1-byte data from the address 0x2 of SDIO function 0. */
-ret = SdioReadBytesFromFunc0(handle, &rbuff, 0x2, 1);
-if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
-}
-```
-
-## Releasing the SDIO IRQ
-
-After the SDIO communication, release the SDIO IRQ.
-
-int32\_t SdioReleaseIrq\(DevHandle handle\);
-
-**Table 11** Parameters and return values of SdioReleaseIrq
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO IRQ is released.
-
-
-
Negative value
-
-
Failed to release the SDIO IRQ.
-
-
-
-
-
-The following example shows how to release the SDIO IRQ.
-
-```
-int32_t ret;
-/* Release the SDIO IRQ. */
-ret = SdioReleaseIrq(handle);
-if (ret != 0) {
- HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
-}
-```
-
-## Disabling the SDIO Device
-
-After the SDIO communication, disable the SDIO device.
-
-int32\_t SdioDisableFunc\(DevHandle handle\);
-
-**Table 12** Parameters and return values of SdioDisableFunc
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO device is disabled.
-
-
-
Negative value
-
-
Failed to disable the SDIO device.
-
-
-
-
-
-The following example shows how to disable the SDIO device.
-
-```
-int32_t ret;
-/* Disable the SDIO device. */
-ret = SdioDisableFunc(handle);
-if (ret != 0) {
- HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
-}
-```
-
-## Releasing the Exclusively Claimed Host
-
-After the SDIO communication, release the exclusively claimed host.
-
-void SdioReleaseHost\(DevHandle handle\);
-
-**Table 13** Parameter description of SdioReleaseHost
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to release the exclusively claimed host.
-
-```
-SdioReleaseHost(handle); /* Release the exclusively claimed host. */
-```
-
-## Closing an SDIO Controller
-
-After the SDIO communication, close the SDIO controller.
-
-void SdioClose\(DevHandle handle\);
-
-This function releases the resources requested.
-
-**Table 14** Parameter description of SdioClose
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to close an SDIO controller.
-
-```
-SdioClose(handle); /* Close an SDIO controller. */
-```
-
diff --git a/en/device-dev/driver/sensor-driver-development-example.md b/en/device-dev/driver/sensor-driver-development-example.md
deleted file mode 100644
index acab2c70f8f15eb2f313206a50e289af4ab759db..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-development-example.md
+++ /dev/null
@@ -1,583 +0,0 @@
-# Sensor Driver Development Example
-
-This section provides a code example of how to load and start the acceleration sensor driver based on the HDF driver model. For details about the mechanism, see [HDF Driver Development](driver-development.md). This example uses the Bosch BMI160 acceleration sensor that communicates over I2C.
-
-1. Register the driver entry of the acceleration sensor.
-
-- Implementation of the entry function
-
-```
-/* Register the entry structure object of the acceleration sensor. */
-struct HdfDriverEntry g_sensorAccelDevEntry = {
- .moduleVersion = 1, /* Version number of the acceleration sensor module */
- .moduleName = "HDF_SENSOR_ACCEL", /* Name of the acceleration sensor module. The value must be the same as that of moduleName in the device_info.hcs file. */
- .Bind = BindAccelDriver, /* Binding function of the acceleration sensor */
- .Init = InitAccelDriver, /* Initialization function of the acceleration sensor */
- .Release = ReleaseAccelDriver, /* Resource release function of the acceleration sensor */
-};
-
-/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function first and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
-HDF_INIT(g_sensorAccelDevEntry);
-```
-
-- Acceleration sensor configuration
-
-The acceleration sensor model uses the HCS as the configuration source code. For details about the HCS configuration fields, see [Driver Configuration Management](driver-configuration-management.md).
-
-```
-/* HCS configuration of the acceleration sensor device */
-device_sensor_accel :: device {
- device0 :: deviceNode {
- policy = 1; /* Policy for providing the driver service */
- priority = 105; /* Driver startup priority (0–200). A larger value indicates a lower priority. The default value 100 is recommended. The sequence for loading devices with the same priority is random. */
- preload = 2; /* Field for specifying whether to load the driver. Value 0 means to load the driver, and 2 means the opposite. */
- permission = 0664; /* Permission for the driver to create device nodes */
- moduleName = "HDF_SENSOR_ACCEL"; /* Driver name. The value must be the same as that of moduleName in the driver entry structure. */
- serviceName = "sensor_accel"; /* Name of the service provided by the driver. The name must be unique. */
- deviceMatchAttr = "hdf_sensor_accel_driver"; /* 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. */
- }
-}
-```
-
-1. Initialize and deinitialize the acceleration sensor driver.
-
-- Initialization entry function **init**
-
-```
-/* Bind the service provided by the acceleration sensor driver to the HDF. */
-int32_t BindAccelDriver(struct HdfDeviceObject *device)
-{
- CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
-
- static struct IDeviceIoService service = {
- .object = {0},
- .Dispatch = DispatchAccel,
- };
- device->service = &service;
-
- return HDF_SUCCESS;
-}
-/* After detecting that the device is in position, call RegisterAccelChipOps to register the differentiation adaptation function. */
-int32_t RegisterAccelChipOps(struct AccelOpsCall *ops)
-{
- struct AccelDrvData *drvData = NULL;
-
- CHECK_NULL_PTR_RETURN_VALUE(ops, HDF_ERR_INVALID_PARAM);
-
- drvData = AccelGetDrvData();
- drvData->ops.Init = ops->Init;
- drvData->ops.ReadData = ops->ReadData;
- return HDF_SUCCESS;
-}
-/* Hook the acceleration sensor driver normalization function. */
-static int32_t InitAccelOps(struct SensorDeviceInfo *deviceInfo)
-{
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- (void)memset_s((void *)deviceInfo, sizeof(*deviceInfo), 0, sizeof(*deviceInfo));
- deviceInfo->ops.GetInfo = SetAccelInfo;
- deviceInfo->ops.Enable = SetAccelEnable;
- deviceInfo->ops.Disable = SetAccelDisable;
- deviceInfo->ops.SetBatch = SetAccelBatch;
- deviceInfo->ops.SetMode = SetAccelMode;
- deviceInfo->ops.SetOption = SetAccelOption;
-
- if (memcpy_s(&deviceInfo->sensorInfo, sizeof(deviceInfo->sensorInfo),
- &drvData->accelCfg->sensorInfo, sizeof(drvData->accelCfg->sensorInfo)) != EOK) {
- HDF_LOGE("%s: copy sensor info failed", __func__);
- return HDF_FAILURE;
- }
- /* The sensor type ID can be configured in the HCS configuration file or here. */
- drvData->accelCfg->sensorInfo.sensorTypeId = SENSOR_TAG_ACCELEROMETER;
- drvData->accelCfg->sensorInfo.sensorId = SENSOR_TAG_ACCELEROMETER;
-
- return HDF_SUCCESS;
-}
-/* Initialize the sensor register. */
-static int32_t InitAccelAfterConfig(void)
-{
- struct SensorDeviceInfo deviceInfo;
-
- if (InitAccelConfig() != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel config failed", __func__);
- return HDF_FAILURE;
- }
-
- if (InitAccelOps(&deviceInfo) != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel ops failed", __func__);
- return HDF_FAILURE;
- }
-
- if (AddSensorDevice(&deviceInfo) != HDF_SUCCESS) {
- HDF_LOGE("%s: add accel device failed", __func__);
- return HDF_FAILURE;
- }
-
- return HDF_SUCCESS;
-}
-/* Call the device detection function to hook the differentiated device function. */
-static int32_t DetectAccelChip(void)
-{
- int32_t num;
- int32_t ret;
- int32_t loop;
- struct AccelDrvData *drvData = AccelGetDrvData();
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
-
- num = sizeof(g_accelDetectIfList) / sizeof(g_accelDetectIfList[0]);
- for (loop = 0; loop < num; ++loop) {
- if (g_accelDetectIfList[loop].DetectChip != NULL) {
- ret = g_accelDetectIfList[loop].DetectChip(drvData->accelCfg);
- if (ret == HDF_SUCCESS) {
- drvData->detectFlag = true;
- break;
- }
- }
- }
-
- if (loop == num) {
- HDF_LOGE("%s: detect accel device failed", __func__);
- drvData->detectFlag = false;
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-/* The entry function of the acceleration sensor driver is used to initialize the structure object of the sensor private data, allocate space for the HCS data configuration object of the sensor, invoke the entry function for initializing the sensor HCS data configuration, detect whether the sensor device is in position, create the sensor data reporting timer, implement the sensor normalization API, and register the sensor device. */
-int32_t InitAccelDriver(struct HdfDeviceObject *device)
-{
- /* Obtain the private data structure object of the sensor. */
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- /* When detecting sensors of the same type from different vendors, the function checks whether this type of sensors is in position. If yes, it no longer detects the other sensors of this type and directly returns the result. */
- if (drvData->detectFlag) {
- HDF_LOGE("%s: accel sensor have detected", __func__);
- return HDF_SUCCESS;
- }
-
- CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
- /* Allocate space for the private data structure objects for storing sensor data configurations. The allocated space needs to be released when the driver is released. */
- drvData->accelCfg = (struct SensorCfgData *)OsalMemCalloc(sizeof(*cfg));
- if (drvData->accelCfg == NULL) {
- HDF_LOGE("%s: malloc sensor config data failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->accelCfg->regCfgGroup = &g_regCfgGroup[0];
- /* Initializing the sensor configuration data aims to parse the configuration information of the sensor communication bus, basic sensor information, sensor attributes, whether the sensor is in position, and register group information. */
- if (GetSensorBaseConfigData(device->property, drvData->accelCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: get sensor base config failed", __func__);
- goto Base_CONFIG_EXIT;
- }
-
- if (DetectAccelChip() != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor detect device no exist", __func__);
- goto DETECT_CHIP_EXIT;
- }
- drvData->detectFlag = true;
- if (ParseSensorRegConfig(drvData->accelCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: detect sensor device failed", __func__);
- goto REG_CONFIG_EXIT;
- }
-
- if (InitAccelAfterConfig() != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel after config failed", __func__);
- goto INIT_EXIT;
- }
-
- HDF_LOGI("%s: init accel driver success", __func__);
- return HDF_SUCCESS;
-
-INIT_EXIT:
- DestroySensorThread(&drvData->thread, &drvData->threadStatus);
- (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
-REG_CONFIG_EXIT:
- ReleaseSensorAllRegConfig(drvData->accelCfg);
- (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
-DETECT_CHIP_EXIT:
- drvData->detectFlag = false;
-BASE_CONFIG_EXIT:
- drvData->accelCfg->root = NULL;
- drvData->accelCfg->regCfgGroup = NULL;
- OsalMemFree(drvData->accelCfg);
- drvData->accelCfg = NULL;
- return HDF_FAILURE;
-}
-
-/* Release the resources allocated during driver initialization. */
-void ReleaseAccelDriver(struct HdfDeviceObject *device)
-{
- (void)device;
- struct AccelDrvData *drvData = NULL;
-
- drvData = AccelGetDrvData();
- (void)DestroySensorThread(&drvData->thread, &drvData->threadStatus);
- (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
- drvData->detectFlag = false;
-
- if (drvData->accelCfg != NULL) {
- drvData->accelCfg->root = NULL;
- drvData->accelCfg->regCfgGroup = NULL;
- ReleaseSensorAllRegConfig(drvData->accelCfg);
- (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
- OsalMemFree(drvData->accelCfg);
- drvData->accelCfg = NULL;
- }
-
- drvData->initStatus = false;
-}
-```
-
-1. Configure the acceleration sensor register group.
-
-You only need to configure the acceleration sensor data according to the template. Template configuration parsing has been implemented via the **InitSensorConfigData** function and only needs to be called during initialization. If new configuration items are added, you need to modify this function accordingly.
-
-```
-Acceleration sensor data configuration template (accel_config.hcs)
-root {
- sensorAccelConfig {
- accelChipConfig {
- /* Sensor information template */
- template sensorInfo {
- sensorName = "accelerometer"; /* Acceleration sensor name. The value contains a maximum of 16 bytes. */
- vendorName = "borsh_bmi160"; /* Sensor vendor name. The value contains a maximum of 16 bytes. */
- firmwareVersion = "1.0"; /* Sensor firmware version number. The default value is 1.0. The value contains a maximum of 16 bytes. */
- hardwareVersion = "1.0"; /* Sensor hardware version number. The default value is 1.0. The value contains a maximum of 16 bytes. */
- sensorTypeId = 1; /* Sensor type ID. For details, see SensorTypeTag. */
- sensorId = 1; /* Sensor ID, which is defined by the sensor driver developer. The SensorTypeTag enums are recommended. */
- maxRange = 8; /* Maximum measurement range of the sensor. Set this parameter based on your business requirements. */
- precision = 0; /* Sensor accuracy, which is used together with sensor data reporting. For details, see SensorEvents. */
- power = 230; /* Power consumption of the sensor */
- }
- /* Template of the bus type and configuration information used by the sensor */
- template sensorBusConfig {
- busType = 0; /* 0 for the I2C bus and 1 for the SPI bus */
- busNum = 6; /* Device ID allocated to the sensor on the chip */
- busAddr = 0; /* Address allocated to the sensor on the chip */
- regWidth = 1; /* Width of the sensor register address */
- regBigEndian = 0; /* Endian mode of the sensor register */
- }
- /* Sensor attribute template */
- template sensorAttr {
- chipName = ""; /* Sensor chip name */
- chipIdRegister = 0xf; /* Address of the register detecting whether the sensor is in position */
- chipIdValue = 0xd1; /* Value of the register detecting whether the sensor is in position */
- }
- }
- }
-}
-
-/* You can modify the template configuration based on the differences of sensor devices. If no modification is made, the default template configuration is used. */
-root {
- sensorAccelConfig {
- accel_bmi160_chip_config : accelChipConfig {
- match_attr = "hdf_sensor_accel_driver"; /* The value must be the same as the match_attr field configured for the acceleration sensor. */
- accelInfo :: sensorInfo {
- vendorName = "borsh_bmi160";
- sensorTypeId = 1;
- sensorId = 1;
- }
- accelBusConfig :: sensorBusConfig {
- busType = 0; /* I2C communication mode */
- busNum = 6;
- busAddr = 0x68;
- regWidth = 1; /* 1-byte bit width */
- }
- accelAttr :: sensorAttr {
- chipName = "bmi160";
- chipIdRegister = 0x00;
- chipIdValue = 0xd1;
- }
- accelRegConfig {
- /* regAddr: Register address
- value: Register value
- mask: Mask of the register value
- len: Length (in bytes) of the register value
- delay: Register delay (in milliseconds)
- opsType: Operation type. The options can be 0 (no operation), 1 (read), 2 (write), 3 (read and check), and 4 (bit update).
- calType: Calculation type. The options can be 0 (none), 1 (write), 2 (negate), 3 (XOR) 4, (left shift), and 5 (right shift).
- shiftNum: Number of shifts
- debug: Debugging switch. The value can be 0 (disabled) or 1 (enabled).
- save: Data saving switch. The value can be 0 (not save data) or 1 (save data).
- */
- /* Groups of sensor register operations. Registers can be configured in sequence based on the groups. */
- /* Register address, register value, mask of the register value, data length of the register value, register delay, operation type, calculation type, number of shifts, debugging switch, data saving switch */
- /* Initialize the register groups. */
- initSeqConfig = [
- 0x7e, 0xb6, 0xff, 1, 5, 2, 0, 0, 0, 0,
- 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
- ];
- /* Enable the register groups. */
- enableSeqConfig = [
- 0x7e, 0x11, 0xff, 1, 5, 2, 0, 0, 0, 0,
- 0x41, 0x03, 0xff, 1, 0, 2, 0, 0, 0, 0,
- 0x40, 0x08, 0xff, 1, 0, 2, 0, 0, 0, 0
- ];
- /* Disable the register groups. */
- disableSeqConfig = [
- 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
- ];
- }
- }
- }
-}
-```
-
-1. Implement APIs for acceleration sensor driver operations.
-
-You need to implement normalized APIs based on sensor types.
-
-```
-/* Leave a function empty if it is not used. */
-static int32_t SetAccelInfo(struct SensorBasicInfo *info)
-{
- (void)info;
-
- return HDF_ERR_NOT_SUPPORT;
-}
-/* Deliver the configuration of enabling the register groups. */
-static int32_t SetAccelEnable(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
- ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_ENABLE_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor disable config failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->threadStatus = SENSOR_THREAD_RUNNING;
-
- return HDF_SUCCESS;
-}
-/* Deliver the configuration of disabling the register groups. */
-static int32_t SetAccelDisable(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
-
- ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_DISABLE_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor disable config failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->threadStatus = SENSOR_THREAD_STOPPED;
-
- return HDF_SUCCESS;
-}
-/* Set the sampling interval and data reporting interval of the sensor. */
-static int32_t SetAccelBatch(int64_t samplingInterval, int64_t interval)
-{
- (void)interval;
-
- struct AccelDrvData *drvData = AccelGetDrvData();
- drvData->interval = samplingInterval;
-
- return HDF_SUCCESS;
-}
-/* Set the data reporting mode of the sensor. Currently, the real-time mode is supported. */
-static int32_t SetAccelMode(int32_t mode)
-{
- return (mode == SENSOR_WORK_MODE_REALTIME) ? HDF_SUCCESS : HDF_FAILURE;
-}
-/* Set the sensor options. */
-static int32_t SetAccelOption(uint32_t option)
-{
- (void)option;
- return HDF_ERR_NOT_SUPPORT;
-}
-```
-
-- Differentiated processing APIs
-
- ```
- /* If a device is successfully detected, register the differentiated processing function to the accel driver model. */
- int32_t DetectAccelBim160Chip(struct SensorCfgData *data)
- {
- int32_t ret;
- struct AccelOpsCall ops;
- CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
-
- if (strcmp(ACCEL_CHIP_NAME_BMI160, data->sensorAttr.chipName) != 0) {
- return HDF_SUCCESS;
- }
- ret = InitAccelPreConfig();
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: init BMI160 bus mux config", __func__);
- return HDF_FAILURE;
- }
- if (DetectSensorDevice(data) != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
-
- /* Differentiated processing function */
- ops.Init = InitBmi160;
- ops.ReadData = ReadBmi160Data;
- ret = RegisterAccelChipOps(&ops);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: register BMI160 accel failed", __func__);
- (void)ReleaseSensorBusHandle(&data->busCfg);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
- }
- /* Initialization processing function */
- static int32_t InitBmi160(struct SensorCfgData *data)
- {
- int32_t ret;
-
- CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
- ret = SetSensorRegCfgArray(&data->busCfg, data->regCfgGroup[SENSOR_INIT_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: bmi160 sensor init config failed", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
- }
- /* Data processing function */
- int32_t ReadBmi160Data(struct SensorCfgData *data)
- {
- int32_t ret;
- struct AccelData rawData = { 0, 0, 0 };
- int32_t tmp[ACCEL_AXIS_NUM];
- struct SensorReportEvent event;
-
- (void)memset_s(&event, sizeof(event), 0, sizeof(event));
-
- ret = ReadBmi160RawData(data, &rawData, &event.timestamp);
- if (ret != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
-
- event.sensorId = SENSOR_TAG_ACCELEROMETER;
- event.option = 0;
- event.mode = SENSOR_WORK_MODE_REALTIME;
-
- rawData.x = rawData.x * BMI160_ACC_SENSITIVITY_2G;
- rawData.y = rawData.y * BMI160_ACC_SENSITIVITY_2G;
- rawData.z = rawData.z * BMI160_ACC_SENSITIVITY_2G;
-
- tmp[ACCEL_X_AXIS] = (rawData.x * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
- tmp[ACCEL_Y_AXIS] = (rawData.y * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
- tmp[ACCEL_Z_AXIS] = (rawData.z * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
-
- event.dataLen = sizeof(tmp);
- event.data = (uint8_t *)&tmp;
- ret = ReportSensorEvent(&event);
- return ret;
- }
- ```
-
-- Data processing function
-
-Create a sensor timer to periodically sample data based on the configured sampling interval and report the data to the data subscriber.
-
-```
-/* Scheduled working thread of the sensor */
-static int32_t ReadAccelDataThreadWorker(void *arg)
-{
- (void)arg;
- int64_t interval;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- drvData->threadStatus = SENSOR_THREAD_START;
- while (true) {
- if (drvData->threadStatus == SENSOR_THREAD_RUNNING) {
- if (drvData->ops.ReadData != NULL) {
- (void)drvData->ops.ReadData(drvData->accelCfg);
- }
- interval = OsalDivS64(drvData->interval, (SENSOR_CONVERT_UNIT * SENSOR_CONVERT_UNIT));
- OsalMSleep(interval);
- } else if (drvData->threadStatus == SENSOR_THREAD_DESTROY) {
- break;
- } else {
- OsalMSleep(ACC_DEFAULT_SAMPLING_200_MS / SENSOR_CONVERT_UNIT / SENSOR_CONVERT_UNIT);
- }
-
- if ((!drvData->initStatus) || (drvData->interval < 0) || drvData->threadStatus != SENSOR_THREAD_RUNNING) {
- continue;
- }
- }
-
- return HDF_SUCCESS;
-}
-/* Create a sensor timer and initialize the sensor device. */
-static int32_t InitAccelConfig(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- if (drvData->threadStatus != SENSOR_THREAD_NONE && drvData->threadStatus != SENSOR_THREAD_DESTROY) {
- HDF_LOGE("%s: accel thread have created", __func__);
- return HDF_SUCCESS;
- }
-
- ret = CreateSensorThread(&drvData->thread, ReadAccelDataThreadWorker, "hdf_sensor_accel", drvData);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel create thread failed", __func__);
- drvData->threadStatus = SENSOR_THREAD_NONE;
- return HDF_FAILURE;
- }
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->ops.Init, HDF_ERR_INVALID_PARAM);
-
- ret = drvData->ops.Init(drvData->accelCfg);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel create thread failed", __func__);
- drvData->threadStatus = SENSOR_THREAD_NONE;
- return HDF_FAILURE;
- }
- drvData->initStatus = true;
- return HDF_SUCCESS;
-}
-```
-
-- Major data structures
-
-```
-/* Sensor conversion units */
-#define SENSOR_CONVERT_UNIT 1000
-#define SENSOR_1K_UNIT 1024
-/* Sensitivity conversion value of the sensor with a 2g measurement range */
-#define BMI160_ACC_SENSITIVITY_2G 61
-/* Address of the sensor data sampling register */
-#define BMI160_ACCEL_X_LSB_ADDR 0X12
-#define BMI160_ACCEL_X_MSB_ADDR 0X13
-#define BMI160_ACCEL_Y_LSB_ADDR 0X14
-#define BMI160_ACCEL_Y_MSB_ADDR 0X15
-#define BMI160_ACCEL_Z_LSB_ADDR 0X16
-#define BMI160_ACCEL_Z_MSB_ADDR 0X17
-/* Data dimension of the sensor */
-enum AccelAxisNum {
- ACCEL_X_AXIS = 0,
- ACCEL_Y_AXIS = 1,
- ACCEL_Z_AXIS = 2,
- ACCEL_AXIS_NUM = 3,
-};
-/* Each dimension of the sensor */
-struct AccelData {
- int32_t x;
- int32_t y;
- int32_t z;
-};
-/* Private data structure of the sensor */
-struct AccelDrvData {
- bool detectFlag;
- uint8_t threadStatus;
- uint8_t initStatus;
- int64_t interval;
- struct SensorCfgData *accelCfg;
- struct OsalThread thread;
- struct AccelOpsCall ops;
-};
-/* Differentiation adaptation function */
-struct AccelOpsCall {
- int32_t (*Init)(struct SensorCfgData *data);
- int32_t (*ReadData)(struct SensorCfgData *data);
-};
-```
-
diff --git a/en/device-dev/driver/sensor-driver-development-guidelines.md b/en/device-dev/driver/sensor-driver-development-guidelines.md
deleted file mode 100644
index afbb833cac70c19f9612461c6d2f9983f58ef544..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-development-guidelines.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Sensor Driver Development Guidelines
-
-- [How to Develop](#section18816105182315)
-
-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 information 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 need to 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.
-4. Implement APIs for acceleration sensor driver operations. The driver APIs for various types of sensors, such as **init**, **GetInfo**, **Enable**, **Disable**, **SetBatch**, **SetMode**, **SetOption**, and **ReadSensorData**, are normalized to deliver sensor driver configurations and report sensor data.
-
-> **NOTE:**
->The sensor driver model provides a collection of APIs to implement sensor driver capabilities, including the driver device management capabilities, abstract bus and platform operation capabilities, general configuration capabilities, and configuration parsing capabilities. For details about the APIs, see [Table 2](sensor-driver-overview.md#table1156812588320). You need to implement the following APIs: some operations to perform on sensors \([Table 3](sensor-driver-overview.md#table1083014911336)\), differentiated data configuration of the sensor HCS, and verification of basic driver functions.
-
diff --git a/en/device-dev/driver/sensor-driver-overview.md b/en/device-dev/driver/sensor-driver-overview.md
deleted file mode 100644
index b3d5e86797f93b7c753fdece5fa02adb18f8fbba..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-overview.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# Sensor Driver Overview
-
-- [Introduction](#section667413271505)
-- [Available APIs](#section7255104114110)
-
-## Introduction
-
-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:
-
-- Hardware Driver Interfaces \(HDIs\) for sensors: Facilitate service development.
-- APIs for implementing sensor driver model capabilities: Implement the capabilities of registering, loading, and unregistering sensor drivers as well as detecting sensor devices depending on the HDF, normalize APIs for sensor devices of the same type, and offer 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\), implement differentiated configuration for sensors of the same type and serialized configuration of sensor device parameters, and offer APIs for some sensor device operations to simplify sensor driver development.
-
-## Available APIs
-
-The following table lists the APIs provided by the sensor driver model.
-
-**Table 1** External APIs provided by the sensor driver model
-
-
-
Obtains information about all sensors in the system. The information about a sensor generally includes the sensor name, sensor vendor, firmware version, hardware version, sensor type ID, sensor ID, maximum measurement range, accuracy, and power.
-
-
-
Setting
-
-
int32_t Enable(int32_t sensorId)
-
-
Enables the sensor that has been subscribed to. The subscriber can obtain the sensor data only after the sensor is enabled.
-
-The following table lists the APIs provided by the sensor driver model for driver developers. You can directly call these APIs without any implementations.
-
-**Table 2** APIs provided by the sensor driver model for driver developers
-
-
-
Obtains basic configuration information such as sensor, bus, and attribute configurations based on the HCS resource configuration of the sensor device, and initializes the basic configuration data structure.
-
-The following table lists the APIs that need to be implemented by driver developers.
-
-**Table 3** APIs that need to be implemented by driver developers
-
-
-
Category
-
-
API
-
-
Description
-
-
-
-
Basic functions
-
-
int32_t init(void)
-
-
Initializes the configuration of a sensor device after it is detected successfully.
-
-
-
int32_t GetInfo(struct SensorBasicInfo *info)
-
-
Obtains the basic information about the current sensor device from the HCS of sensor devices.
-
-
-
int32_t Enable(void)
-
-
Enables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
-
-
-
int32_t Disable(void)
-
-
Disables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
Sets the processing time of the data reporting thread for the current sensor device based on the data sampling interval and data reporting interval.
-
-
-
int32_t SetMode(int32_t mode)
-
-
Sets the data reporting mode of the current sensor device.
-
-
-
int32_t SetOption(uint32_t option)
-
-
Sets the register configuration such as the measurement range and accuracy based on sensor options.
-
-
-
void ReadSensorData(void)
-
-
Reads sensor data.
-
-
-
-
-
-For details about the API implementation, see the [sensor driver development example](sensor-driver-development-example.md).
-
diff --git a/en/device-dev/driver/sensor-driver-test-guidelines.md b/en/device-dev/driver/sensor-driver-test-guidelines.md
deleted file mode 100644
index 042112036cdad78e9aa732e54c8423f8c3ed115e..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-test-guidelines.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Sensor Driver Test Guidelines
-
-After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. The developer self-test platform is used as the test environment.
-
-```
-/* Specify whether to report sensor data. */
-static int32_t g_sensorDataFlag = 0;
-/* Retain the address of the sensor interface instance. */
-static const struct SensorInterface *g_sensorDev = nullptr;
-
-/* Register the data reporting function. */
-static int SensorTestDataCallback(struct SensorEvents *event)
-{
- if (event == nullptr) {
- return -1;
- }
- float *data = (float*)event->data;
- printf("time [%lld] sensor id [%d] x-[%f] y-[%f] z-[%f]\n\r", event->timestamp,
- event->sensorId, (*data), *(data + 1), *(data + g_axisZ));
- if (*data > 1e-5) {
- g_sensorDataFlag = 1;
- }
- return 0;
-}
-/* Initialize the sensor interface instance before executing the test cases. */
-void HdfSensorTest::SetUpTestCase()
-{
- g_sensorDev = NewSensorInterfaceInstance();
- if (g_sensorDev == nullptr) {
- printf("test sensorHdi get Module instace failed\n\r");
- }
-}
-/* Release case resources. */
-void HdfSensorTest::TearDownTestCase()
-{
- if (g_sensorDev != nullptr) {
- FreeSensorInterfaceInstance();
- g_sensorDev = nullptr;
- }
-}
-/* Verify the sensor driver. */
-HWTEST_F(HdfSensorTest,TestAccelDriver_001, TestSize.Level0)
-{
- int32_t sensorInterval = 1000000000; /* Data sampling interval, in nanoseconds */
- int32_t pollTime = 5; /* Data sampling duration, in seconds */
- int32_t accelSensorId = 1; /* Acceleration sensor type ID, which is 1 */
- int32_t count = 0;
- int ret;
- struct SensorInformation *sensorInfo = nullptr;
-
- ret = g_sensorDev->Register(SensorTestDataCallback)
- EXPECT_EQ(SENSOR_NULL_PTR, ret);
-
- ret = g_sensorDev->GetAllSensors(&sensorInfo, &count);
- EXPECT_EQ(0, ret);
- if (sensorInfo == nullptr) {
- EXPECT_NE(nullptr, sensorInfo);
- return;
- }
- /* Print the obtained sensor list. */
- for (int i = 0; i < count; i++) {
- printf("get sensoriId[%d], info name[%s]\n\r", sensorInfo[i]->sensorId, sensorInfo[i]->sensorName);
- }
- ret = g_sensorDev->Enable(accelSensorId);
- EXPECT_EQ(0, ret);
- g_sensorDataFlag = 0;
-
- ret = g_sensorDev->SetBatch(accelSensorId, sensorInterval, pollTime);
- EXPECT_EQ(0, ret);
- /* Observe the printed data within the period specified by pollTime. */
- OsalSleep(pollTime);
- EXPECT_EQ(1, g_sensorDataFlag);
-
- ret = g_sensorDev->Disable(accelSensorId);
- g_sensorDataFlag = 0;
- EXPECT_EQ(0, ret);
-
- ret = g_sensorDev->Unregister();
- EXPECT_EQ(0, ret);
-}
-```
-
diff --git a/en/device-dev/driver/sensor.md b/en/device-dev/driver/sensor.md
index f9e8d552c0cbad2c430e9457122a25b1d62ee4df..cf8d8ab7e560f4fadde97a41444ce1d8fe177316 100644
--- a/en/device-dev/driver/sensor.md
+++ b/en/device-dev/driver/sensor.md
@@ -1,11 +1,929 @@
-# SENSOR
+# Sensor
-- **[Sensor Driver Overview](sensor-driver-overview.md)**
+- [Overview](#section3634112111)
+ - [Available APIs](#section188213414114)
-- **[Sensor Driver Development Guidelines](sensor-driver-development-guidelines.md)**
+- [Development Guidelines](#section1140943382)
+ - [How to Develop](#section7893102915819)
-- **[Sensor Driver Development Example](sensor-driver-development-example.md)**
+- [Development Example](#section257750691)
+- [Test Guidelines](#section106021256121219)
-- **[Sensor Driver Test Guidelines](sensor-driver-test-guidelines.md)**
+## Overview
+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:
+
+- Hardware Driver Interfaces \(HDIs\) for sensors: These HDIs facilitate service development.
+- 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
+
+The following table lists the APIs provided by the sensor driver model.
+
+**Table 1** External APIs provided by the sensor driver model
+
+
+
Obtains information about all sensors in the system. The information about a sensor generally includes the sensor name, sensor vendor, firmware version, hardware version, sensor type ID, sensor ID, maximum measurement range, accuracy, and power.
+
+
+
Setting
+
+
int32_t Enable(int32_t sensorId)
+
+
Enables the sensor that has been subscribed to. The subscriber can obtain the sensor data only after the sensor is enabled.
+
+The following table lists the APIs provided by the sensor driver model for driver developers. You can directly call these APIs without any implementations.
+
+**Table 2** APIs provided by the sensor driver model for driver developers
+
+
+
Obtains basic configuration information such as sensor, bus, and attribute configurations based on the HCS resource configuration of the sensor device, and initializes the basic configuration data structure.
+
+The following table lists the APIs that need to be implemented by driver developers.
+
+**Table 3** APIs that need to be implemented by driver developers
+
+
+
Category
+
+
API
+
+
Description
+
+
+
+
Basic functions
+
+
int32_t init(void)
+
+
Initializes the configuration of a sensor device after it is detected.
+
+
+
int32_t GetInfo(struct SensorBasicInfo *info)
+
+
Obtains the basic information about the current sensor device from the HCS of sensor devices.
+
+
+
int32_t Enable(void)
+
+
Enables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
+
+
+
int32_t Disable(void)
+
+
Disables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
Sets the processing time of the data reporting thread for the current sensor device based on the data sampling interval and data reporting interval.
+
+
+
int32_t SetMode(int32_t mode)
+
+
Sets the data reporting mode of the current sensor device.
+
+
+
int32_t SetOption(uint32_t option)
+
+
Sets the register configuration such as the measurement range and accuracy based on sensor options.
+
+
+
void ReadSensorData(void)
+
+
Reads sensor data.
+
+
+
+
+
+For details about the API implementation, see Sensor Driver Development Example.
+
+## Development Guidelines
+
+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.
+4. Implement APIs for acceleration sensor driver operations. The driver APIs for various types of sensors, such as **init**, **GetInfo**, **Enable**, **Disable**, **SetBatch**, **SetMode**, **SetOption**, and **ReadSensorData**, are normalized to deliver sensor driver configurations and report sensor data.
+
+> **NOTE:**
+>The sensor driver model provides a collection of APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, general configuration, and configuration parsing capabilities. For details about the APIs, see [Table 2](#table1156812588320). You need to implement the following APIs: some operations to perform on sensors \([Table 3](#table1083014911336)\), differentiated data configuration of the sensor HCS, and verification of basic driver functions.
+
+## Development Example
+
+This section uses a code example to demonstrate how to load and start the acceleration sensor driver based on the HDF driver model. For details about the mechanism, see [HDF Driver Development](driver-development.md). This example uses the Bosch BMI160 acceleration sensor that communicates over I2C.
+
+1. Register the driver entry of the acceleration sensor.
+
+- Implementation of the entry function
+
+```
+/* Register the entry structure object of the acceleration sensor. */
+struct HdfDriverEntry g_sensorAccelDevEntry = {
+ .moduleVersion = 1, /* Version of the acceleration sensor module */
+ .moduleName = "HDF_SENSOR_ACCEL", /* Name of the acceleration sensor module. The value must be the same as that of moduleName in the device_info.hcs file. */
+ .Bind = BindAccelDriver, /* Binding function of the acceleration sensor */
+ .Init = InitAccelDriver, /* Initialization function of the acceleration sensor */
+ .Release = ReleaseAccelDriver, /* Resource release function of the acceleration sensor */
+};
+
+/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function first and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
+HDF_INIT(g_sensorAccelDevEntry);
+```
+
+- Acceleration sensor configuration
+
+The acceleration sensor model uses the HCS as the configuration source code. For details about the HCS configuration fields, see [Driver Configuration Management](driver-configuration-management.md).
+
+```
+/* HCS configuration of the acceleration sensor device */
+device_sensor_accel :: device {
+ device0 :: deviceNode {
+ policy = 1; /* Policy for providing the driver service */
+ priority = 105; /* Driver startup priority (0–200). A larger value indicates a lower priority. The default value 100 is recommended. The sequence for loading devices with the same priority is random. */
+ preload = 2; /* Field for specifying whether to load the driver. The value 0 means to load the driver, and 2 means the opposite. */
+ permission = 0664; /* Permission for the driver to create device nodes */
+ moduleName = "HDF_SENSOR_ACCEL"; /* Driver name. The value must be the same as that of moduleName in the driver entry structure. */
+ serviceName = "sensor_accel"; /* Name of the service provided by the driver. The name must be unique. */
+ deviceMatchAttr = "hdf_sensor_accel_driver"; /* 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. */
+ }
+}
+```
+
+1. Initialize and deinitialize the acceleration sensor driver.
+
+- Initialization entry function **init**
+
+```
+/* Bind the service provided by the acceleration sensor driver to the HDF. */
+int32_t BindAccelDriver(struct HdfDeviceObject *device)
+{
+ CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
+
+ static struct IDeviceIoService service = {
+ .object = {0},
+ .Dispatch = DispatchAccel,
+ };
+ device->service = &service;
+
+ return HDF_SUCCESS;
+}
+/* After detecting that the device is in position, call RegisterAccelChipOps to register the differentiation adaptation function. */
+int32_t RegisterAccelChipOps(struct AccelOpsCall *ops)
+{
+ struct AccelDrvData *drvData = NULL;
+
+ CHECK_NULL_PTR_RETURN_VALUE(ops, HDF_ERR_INVALID_PARAM);
+
+ drvData = AccelGetDrvData();
+ drvData->ops.Init = ops->Init;
+ drvData->ops.ReadData = ops->ReadData;
+ return HDF_SUCCESS;
+}
+/* Hook the acceleration sensor driver normalization function. */
+static int32_t InitAccelOps(struct SensorDeviceInfo *deviceInfo)
+{
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ (void)memset_s((void *)deviceInfo, sizeof(*deviceInfo), 0, sizeof(*deviceInfo));
+ deviceInfo->ops.GetInfo = SetAccelInfo;
+ deviceInfo->ops.Enable = SetAccelEnable;
+ deviceInfo->ops.Disable = SetAccelDisable;
+ deviceInfo->ops.SetBatch = SetAccelBatch;
+ deviceInfo->ops.SetMode = SetAccelMode;
+ deviceInfo->ops.SetOption = SetAccelOption;
+
+ if (memcpy_s(&deviceInfo->sensorInfo, sizeof(deviceInfo->sensorInfo),
+ &drvData->accelCfg->sensorInfo, sizeof(drvData->accelCfg->sensorInfo)) != EOK) {
+ HDF_LOGE("%s: copy sensor info failed", __func__);
+ return HDF_FAILURE;
+ }
+ /* The sensor type ID can be configured in the HCS configuration file or here. */
+ drvData->accelCfg->sensorInfo.sensorTypeId = SENSOR_TAG_ACCELEROMETER;
+ drvData->accelCfg->sensorInfo.sensorId = SENSOR_TAG_ACCELEROMETER;
+
+ return HDF_SUCCESS;
+}
+/* Initialize the sensor register. */
+static int32_t InitAccelAfterConfig(void)
+{
+ struct SensorDeviceInfo deviceInfo;
+
+ if (InitAccelConfig() != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ if (InitAccelOps(&deviceInfo) != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel ops failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ if (AddSensorDevice(&deviceInfo) != HDF_SUCCESS) {
+ HDF_LOGE("%s: add accel device failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ return HDF_SUCCESS;
+}
+/* Call the device detection function to hook the differentiated device function. */
+static int32_t DetectAccelChip(void)
+{
+ int32_t num;
+ int32_t ret;
+ int32_t loop;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+
+ num = sizeof(g_accelDetectIfList) / sizeof(g_accelDetectIfList[0]);
+ for (loop = 0; loop < num; ++loop) {
+ if (g_accelDetectIfList[loop].DetectChip != NULL) {
+ ret = g_accelDetectIfList[loop].DetectChip(drvData->accelCfg);
+ if (ret == HDF_SUCCESS) {
+ drvData->detectFlag = true;
+ break;
+ }
+ }
+ }
+
+ if (loop == num) {
+ HDF_LOGE("%s: detect accel device failed", __func__);
+ drvData->detectFlag = false;
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+/* The entry function of the acceleration sensor driver is used to initialize the structure object of the sensor private data, allocate space for the HCS data configuration object of the sensor, invoke the entry function for initializing the sensor HCS data configuration, detect whether the sensor device is in position, create the sensor data reporting timer, implement the sensor normalization API, and register the sensor device. */
+int32_t InitAccelDriver(struct HdfDeviceObject *device)
+{
+ /* Obtain the private data structure object of the sensor. */
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ /* When detecting sensors of the same type from different vendors, the function checks whether this type of sensors is in position. If yes, it no longer detects the other sensors of this type and directly returns the result. */
+ if (drvData->detectFlag) {
+ HDF_LOGE("%s: accel sensor have detected", __func__);
+ return HDF_SUCCESS;
+ }
+
+ CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
+ /* Allocate space for the private data structure objects for storing sensor data configurations. The allocated space needs to be released when the driver is released. */
+ drvData->accelCfg = (struct SensorCfgData *)OsalMemCalloc(sizeof(*cfg));
+ if (drvData->accelCfg == NULL) {
+ HDF_LOGE("%s: malloc sensor config data failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->accelCfg->regCfgGroup = &g_regCfgGroup[0];
+ /* Initializing the sensor configuration data aims to parse the configuration information of the sensor communication bus, basic sensor information, sensor attributes, whether the sensor is in position, and register group information. */
+ if (GetSensorBaseConfigData(device->property, drvData->accelCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: get sensor base config failed", __func__);
+ goto Base_CONFIG_EXIT;
+ }
+
+ if (DetectAccelChip() != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor detect device no exist", __func__);
+ goto DETECT_CHIP_EXIT;
+ }
+ drvData->detectFlag = true;
+ if (ParseSensorRegConfig(drvData->accelCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: detect sensor device failed", __func__);
+ goto REG_CONFIG_EXIT;
+ }
+
+ if (InitAccelAfterConfig() != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel after config failed", __func__);
+ goto INIT_EXIT;
+ }
+
+ HDF_LOGI("%s: init accel driver success", __func__);
+ return HDF_SUCCESS;
+
+INIT_EXIT:
+ DestroySensorThread(&drvData->thread, &drvData->threadStatus);
+ (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
+REG_CONFIG_EXIT:
+ ReleaseSensorAllRegConfig(drvData->accelCfg);
+ (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
+DETECT_CHIP_EXIT:
+ drvData->detectFlag = false;
+BASE_CONFIG_EXIT:
+ drvData->accelCfg->root = NULL;
+ drvData->accelCfg->regCfgGroup = NULL;
+ OsalMemFree(drvData->accelCfg);
+ drvData->accelCfg = NULL;
+ return HDF_FAILURE;
+}
+
+/* Release the resources allocated during driver initialization. */
+void ReleaseAccelDriver(struct HdfDeviceObject *device)
+{
+ (void)device;
+ struct AccelDrvData *drvData = NULL;
+
+ drvData = AccelGetDrvData();
+ (void)DestroySensorThread(&drvData->thread, &drvData->threadStatus);
+ (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
+ drvData->detectFlag = false;
+
+ if (drvData->accelCfg != NULL) {
+ drvData->accelCfg->root = NULL;
+ drvData->accelCfg->regCfgGroup = NULL;
+ ReleaseSensorAllRegConfig(drvData->accelCfg);
+ (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
+ OsalMemFree(drvData->accelCfg);
+ drvData->accelCfg = NULL;
+ }
+
+ drvData->initStatus = false;
+}
+```
+
+1. Configure the acceleration sensor register group.
+
+You only need to configure the acceleration sensor data according to the template. Template configuration parsing has been implemented via the **InitSensorConfigData** function and only needs to be called during initialization. If new configuration items are added, you need to modify this function accordingly.
+
+```
+Acceleration sensor data configuration template (accel_config.hcs)
+root {
+ sensorAccelConfig {
+ accelChipConfig {
+ /* Sensor information template */
+ template sensorInfo {
+ sensorName = "accelerometer"; /* Acceleration sensor name. The value contains a maximum of 16 bytes. */
+ vendorName = "borsh_bmi160"; /* Sensor vendor name. The value contains a maximum of 16 bytes. */
+ firmwareVersion = "1.0"; /* Sensor firmware version. The default value is 1.0. The value contains a maximum of 16 bytes. */
+ hardwareVersion = "1.0"; /* Sensor hardware version. The default value is 1.0. The value contains a maximum of 16 bytes. */
+ sensorTypeId = 1; /* Sensor type ID. For details, see SensorTypeTag. */
+ sensorId = 1; /* Sensor ID, which is defined by the sensor driver developer. The SensorTypeTag enums are recommended. */
+ maxRange = 8; /* Maximum measurement range of the sensor. Set this parameter based on your business requirements. */
+ precision = 0; /* Sensor accuracy, which is used together with sensor data reporting. For details, see SensorEvents. */
+ power = 230; /* Power consumption of the sensor */
+ }
+ /* Template of the bus type and configuration information used by the sensor */
+ template sensorBusConfig {
+ busType = 0; /* 0:i2c 1:spi */
+ busNum = 6; /* Device ID allocated to the sensor on the chip */
+ busAddr = 0; /* Address allocated to the sensor on the chip */
+ regWidth = 1; /* Width of the sensor register address */
+ regBigEndian = 0; /* Endian mode of the sensor register */
+ }
+ /* Sensor attribute template */
+ template sensorAttr {
+ chipName = ""; /* Sensor chip name */
+ chipIdRegister = 0xf; /* Address of the register detecting whether the sensor is in position */
+ chipIdValue = 0xd1; /* Value of the register detecting whether the sensor is in position */
+ }
+ }
+ }
+}
+
+/* You can modify the template configuration based on the differences of sensor devices. If no modification is made, the default template configuration is used. */
+root {
+ sensorAccelConfig {
+ accel_bmi160_chip_config : accelChipConfig {
+ match_attr = "hdf_sensor_accel_driver"; /* The value must be the same as the match_attr field configured for the acceleration sensor. */
+ accelInfo :: sensorInfo {
+ vendorName = "borsh_bmi160";
+ sensorTypeId = 1;
+ sensorId = 1;
+ }
+ accelBusConfig :: sensorBusConfig {
+ busType = 0; /* I2C communication mode */
+ busNum = 6;
+ busAddr = 0x68;
+ regWidth = 1; /* 1-byte bit width */
+ }
+ accelAttr :: sensorAttr {
+ chipName = "bmi160";
+ chipIdRegister = 0x00;
+ chipIdValue = 0xd1;
+ }
+ accelRegConfig {
+ /* regAddr: Register address
+ value: Register value
+ mask: Mask of the register value
+ len: Length (in bytes) of the register value
+ delay: Register delay (in milliseconds)
+ opsType: Operation type. The options can be 0 (no operation), 1 (read), 2 (write), 3 (read and check), and 4 (bit update).
+ calType: Calculation type. The options can be 0 (none), 1 (write), 2 (negate), 3 (XOR) 4, (left shift), and 5 (right shift).
+ shiftNum: Number of shifts
+ debug: Debugging switch. The value can be 0 (disabled) or 1 (enabled).
+ save: Data saving switch. The value can be 0 (not save data) or 1 (save data).
+ */
+ /* Groups of sensor register operations. Registers can be configured in sequence based on the groups. */
+ /* Register address, register value, mask of the register value, data length of the register value, register delay, operation type, calculation type, number of shifts, debugging switch, data saving switch */
+ /* Initialize the register groups. */
+ initSeqConfig = [
+ 0x7e, 0xb6, 0xff, 1, 5, 2, 0, 0, 0, 0,
+ 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
+ ];
+ /* Enable the register groups. */
+ enableSeqConfig = [
+ 0x7e, 0x11, 0xff, 1, 5, 2, 0, 0, 0, 0,
+ 0x41, 0x03, 0xff, 1, 0, 2, 0, 0, 0, 0,
+ 0x40, 0x08, 0xff, 1, 0, 2, 0, 0, 0, 0
+ ];
+ /* Disable the register groups. */
+ disableSeqConfig = [
+ 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
+ ];
+ }
+ }
+ }
+}
+```
+
+1. Implement APIs for acceleration sensor driver operations.
+
+You need to implement normalized APIs based on sensor types.
+
+```
+/* Leave a function empty if it is not used. */
+static int32_t SetAccelInfo(struct SensorBasicInfo *info)
+{
+ (void)info;
+
+ return HDF_ERR_NOT_SUPPORT;
+}
+/* Deliver the configuration of enabling the register groups. */
+static int32_t SetAccelEnable(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+ ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_ENABLE_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor disable config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->threadStatus = SENSOR_THREAD_RUNNING;
+
+ return HDF_SUCCESS;
+}
+/* Deliver the configuration of disabling the register groups. */
+static int32_t SetAccelDisable(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+
+ ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_DISABLE_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor disable config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->threadStatus = SENSOR_THREAD_STOPPED;
+
+ return HDF_SUCCESS;
+}
+/* Set the sampling interval and data reporting interval of the sensor. */
+static int32_t SetAccelBatch(int64_t samplingInterval, int64_t interval)
+{
+ (void)interval;
+
+ struct AccelDrvData *drvData = AccelGetDrvData();
+ drvData->interval = samplingInterval;
+
+ return HDF_SUCCESS;
+}
+/* Set the data reporting mode of the sensor. Currently, the real-time mode is supported. */
+static int32_t SetAccelMode(int32_t mode)
+{
+ return (mode == SENSOR_WORK_MODE_REALTIME) ? HDF_SUCCESS : HDF_FAILURE;
+}
+/* Set the sensor options. */
+static int32_t SetAccelOption(uint32_t option)
+{
+ (void)option;
+ return HDF_ERR_NOT_SUPPORT;
+}
+```
+
+- Differentiated processing APIs
+
+ ```
+ /* If a device is detected, register the differentiated processing function to the accel driver model. */
+ int32_t DetectAccelBim160Chip(struct SensorCfgData *data)
+ {
+ int32_t ret;
+ struct AccelOpsCall ops;
+ CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
+
+ if (strcmp(ACCEL_CHIP_NAME_BMI160, data->sensorAttr.chipName) != 0) {
+ return HDF_SUCCESS;
+ }
+ ret = InitAccelPreConfig();
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: init BMI160 bus mux config", __func__);
+ return HDF_FAILURE;
+ }
+ if (DetectSensorDevice(data) != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+
+ /* Differentiated processing function */
+ ops.Init = InitBmi160;
+ ops.ReadData = ReadBmi160Data;
+ ret = RegisterAccelChipOps(&ops);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: register BMI160 accel failed", __func__);
+ (void)ReleaseSensorBusHandle(&data->busCfg);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+ /* Initialization processing function */
+ static int32_t InitBmi160(struct SensorCfgData *data)
+ {
+ int32_t ret;
+
+ CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
+ ret = SetSensorRegCfgArray(&data->busCfg, data->regCfgGroup[SENSOR_INIT_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: bmi160 sensor init config failed", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+ /* Data processing function */
+ int32_t ReadBmi160Data(struct SensorCfgData *data)
+ {
+ int32_t ret;
+ struct AccelData rawData = { 0, 0, 0 };
+ int32_t tmp[ACCEL_AXIS_NUM];
+ struct SensorReportEvent event;
+
+ (void)memset_s(&event, sizeof(event), 0, sizeof(event));
+
+ ret = ReadBmi160RawData(data, &rawData, &event.timestamp);
+ if (ret != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+
+ event.sensorId = SENSOR_TAG_ACCELEROMETER;
+ event.option = 0;
+ event.mode = SENSOR_WORK_MODE_REALTIME;
+
+ rawData.x = rawData.x * BMI160_ACC_SENSITIVITY_2G;
+ rawData.y = rawData.y * BMI160_ACC_SENSITIVITY_2G;
+ rawData.z = rawData.z * BMI160_ACC_SENSITIVITY_2G;
+
+ tmp[ACCEL_X_AXIS] = (rawData.x * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+ tmp[ACCEL_Y_AXIS] = (rawData.y * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+ tmp[ACCEL_Z_AXIS] = (rawData.z * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+
+ event.dataLen = sizeof(tmp);
+ event.data = (uint8_t *)&tmp;
+ ret = ReportSensorEvent(&event);
+ return ret;
+ }
+ ```
+
+- Data processing function
+
+Create a sensor timer to periodically sample data based on the configured sampling interval and report the data to the data subscriber.
+
+```
+/* Scheduled working thread of the sensor */
+static int32_t ReadAccelDataThreadWorker(void *arg)
+{
+ (void)arg;
+ int64_t interval;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ drvData->threadStatus = SENSOR_THREAD_START;
+ while (true) {
+ if (drvData->threadStatus == SENSOR_THREAD_RUNNING) {
+ if (drvData->ops.ReadData != NULL) {
+ (void)drvData->ops.ReadData(drvData->accelCfg);
+ }
+ interval = OsalDivS64(drvData->interval, (SENSOR_CONVERT_UNIT * SENSOR_CONVERT_UNIT));
+ OsalMSleep(interval);
+ } else if (drvData->threadStatus == SENSOR_THREAD_DESTROY) {
+ break;
+ } else {
+ OsalMSleep(ACC_DEFAULT_SAMPLING_200_MS / SENSOR_CONVERT_UNIT / SENSOR_CONVERT_UNIT);
+ }
+
+ if ((!drvData->initStatus) || (drvData->interval < 0) || drvData->threadStatus != SENSOR_THREAD_RUNNING) {
+ continue;
+ }
+ }
+
+ return HDF_SUCCESS;
+}
+/* Create a sensor timer and initialize the sensor device. */
+static int32_t InitAccelConfig(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ if (drvData->threadStatus != SENSOR_THREAD_NONE && drvData->threadStatus != SENSOR_THREAD_DESTROY) {
+ HDF_LOGE("%s: accel thread have created", __func__);
+ return HDF_SUCCESS;
+ }
+
+ ret = CreateSensorThread(&drvData->thread, ReadAccelDataThreadWorker, "hdf_sensor_accel", drvData);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel create thread failed", __func__);
+ drvData->threadStatus = SENSOR_THREAD_NONE;
+ return HDF_FAILURE;
+ }
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->ops.Init, HDF_ERR_INVALID_PARAM);
+
+ ret = drvData->ops.Init(drvData->accelCfg);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel create thread failed", __func__);
+ drvData->threadStatus = SENSOR_THREAD_NONE;
+ return HDF_FAILURE;
+ }
+ drvData->initStatus = true;
+ return HDF_SUCCESS;
+}
+```
+
+- Major data structures
+
+```
+/* Sensor conversion units */
+#define SENSOR_CONVERT_UNIT 1000
+#define SENSOR_1K_UNIT 1024
+/* Sensitivity conversion value of the sensor with a 2g measurement range */
+#define BMI160_ACC_SENSITIVITY_2G 61
+/* Address of the sensor data sampling register */
+#define BMI160_ACCEL_X_LSB_ADDR 0X12
+#define BMI160_ACCEL_X_MSB_ADDR 0X13
+#define BMI160_ACCEL_Y_LSB_ADDR 0X14
+#define BMI160_ACCEL_Y_MSB_ADDR 0X15
+#define BMI160_ACCEL_Z_LSB_ADDR 0X16
+#define BMI160_ACCEL_Z_MSB_ADDR 0X17
+/* Data dimension of the sensor */
+enum AccelAxisNum {
+ ACCEL_X_AXIS = 0,
+ ACCEL_Y_AXIS = 1,
+ ACCEL_Z_AXIS = 2,
+ ACCEL_AXIS_NUM = 3,
+};
+/* Each dimension of the sensor */
+struct AccelData {
+ int32_t x;
+ int32_t y;
+ int32_t z;
+};
+/* Private data structure of the sensor */
+struct AccelDrvData {
+ bool detectFlag;
+ uint8_t threadStatus;
+ uint8_t initStatus;
+ int64_t interval;
+ struct SensorCfgData *accelCfg;
+ struct OsalThread thread;
+ struct AccelOpsCall ops;
+};
+/* Differentiation adaptation function */
+struct AccelOpsCall {
+ int32_t (*Init)(struct SensorCfgData *data);
+ int32_t (*ReadData)(struct SensorCfgData *data);
+};
+```
+
+## Test Guidelines
+
+After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. The developer self-test platform is used as the test environment.
+
+```
+/* Specify whether to report sensor data. */
+static int32_t g_sensorDataFlag = 0;
+/* Retain the address of the sensor interface instance. */
+static const struct SensorInterface *g_sensorDev = nullptr;
+
+/* Register the data reporting function. */
+static int SensorTestDataCallback(struct SensorEvents *event)
+{
+ if (event == nullptr) {
+ return -1;
+ }
+ float *data = (float*)event->data;
+ printf("time [%lld] sensor id [%d] x-[%f] y-[%f] z-[%f]\n\r", event->timestamp,
+ event->sensorId, (*data), *(data + 1), *(data + g_axisZ));
+ if (*data > 1e-5) {
+ g_sensorDataFlag = 1;
+ }
+ return 0;
+}
+/* Initialize the sensor interface instance before executing the test cases. */
+void HdfSensorTest::SetUpTestCase()
+{
+ g_sensorDev = NewSensorInterfaceInstance();
+ if (g_sensorDev == nullptr) {
+ printf("test sensorHdi get Module instace failed\n\r");
+ }
+}
+/* Release case resources. */
+void HdfSensorTest::TearDownTestCase()
+{
+ if (g_sensorDev != nullptr) {
+ FreeSensorInterfaceInstance();
+ g_sensorDev = nullptr;
+ }
+}
+/* Verify the sensor driver. */
+HWTEST_F(HdfSensorTest,TestAccelDriver_001, TestSize.Level0)
+{
+ int32_t sensorInterval = 1000000000; /* Data sampling interval, in nanoseconds */
+ int32_t pollTime = 5; /* Data sampling duration, in seconds */
+ int32_t accelSensorId = 1; /* Acceleration sensor type ID, which is 1 */
+ int32_t count = 0;
+ int ret;
+ struct SensorInformation *sensorInfo = nullptr;
+
+ ret = g_sensorDev->Register(SensorTestDataCallback)
+ EXPECT_EQ(SENSOR_NULL_PTR, ret);
+
+ ret = g_sensorDev->GetAllSensors(&sensorInfo, &count);
+ EXPECT_EQ(0, ret);
+ if (sensorInfo == nullptr) {
+ EXPECT_NE(nullptr, sensorInfo);
+ return;
+ }
+ /* Print the obtained sensor list. */
+ for (int i = 0; i < count; i++) {
+ printf("get sensoriId[%d], info name[%s]\n\r", sensorInfo[i]->sensorId, sensorInfo[i]->sensorName);
+ }
+ ret = g_sensorDev->Enable(accelSensorId);
+ EXPECT_EQ(0, ret);
+ g_sensorDataFlag = 0;
+
+ ret = g_sensorDev->SetBatch(accelSensorId, sensorInterval, pollTime);
+ EXPECT_EQ(0, ret);
+ /* Observe the printed data within the period specified by pollTime. */
+ OsalSleep(pollTime);
+ EXPECT_EQ(1, g_sensorDataFlag);
+
+ ret = g_sensorDev->Disable(accelSensorId);
+ g_sensorDataFlag = 0;
+ EXPECT_EQ(0, ret);
+
+ ret = g_sensorDev->Unregister();
+ EXPECT_EQ(0, ret);
+}
+```
diff --git a/en/device-dev/driver/spi.md b/en/device-dev/driver/spi.md
index c635810c74cbb62be99562f6848983e4b7437058..93b6085f61eb8fa578518eddbf2175f4cd17c0bd 100644
--- a/en/device-dev/driver/spi.md
+++ b/en/device-dev/driver/spi.md
@@ -1,9 +1,566 @@
-# SPI
+# SPI
-- **[SPI Overview](spioverview.md)**
+- [Overview](#section193356154511)
+ - [Available APIs](#section232141411476)
-- **[SPI Usage Guidelines](spiusage-guidelines.md)**
+- [Usage Guidelines](#section71363452477)
+ - [How to Use](#section32846814820)
+ - [Obtaining an SPI Device Handle](#section1927265711481)
+ - [Obtaining SPI Device Configuration Parameters](#section541133418493)
+ - [Setting SPI Device Configuration Parameters](#section7870106145010)
+ - [Performing SPI Communication](#section13324155195013)
+ - [Destroying the SPI Device Handle](#section19661632135117)
-- **[SPI Usage Example](spiusage-example.md)**
+- [Usage Example](#section06541058155120)
+## Overview
+
+- Serial Peripheral Interface \(SPI\) is a serial bus specification used for high-speed, full-duplex, and synchronous communication.
+- SPI is developed by Motorola. It is commonly used for communication with flash memory, real-time clocks, sensors, and analog-to-digital \(A/D\) converters.
+- SPI works in controller/device mode. Generally, there is one SPI controller that controls one or more SPI devices. They are connected via four wires:
+ - SCLK: clock signals output from the SPI controller
+ - MOSI: data output from the SPI controller and input into an SPI device
+ - MISO: data output from an SPI device and input into the SPI controller
+ - 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
+
+
+
+
+- SPI communication is usually initiated by the SPI controller and is operated as follows:
+
+1. A single SPI device is selected at a time via the CS to communicate with the SPI controller.
+2. Clock signals are provided for the selected SPI device via the SCLK.
+3. The SPI controller sends data to SPI devices via the MOSI, and receives data from SPI devices via the MISO.
+
+- SPI can work in one of the following four modes, equivalent to one of the four possible states for Clock Polarity \(CPOL\) and Clock Phase \(CPHA\):
+ - If both CPOL and CPHA are **0**, the clock signal level is low in the idle state and data is sampled on the first clock edge.
+ - If CPOL is **0** and CPHA is **1**, the clock signal level is low in the idle state and data is sampled on the second clock edge.
+ - If CPOL is **1** and CPHA is **0**, the clock signal level is high in the idle state and data is sampled on the first clock edge.
+ - If both CPOL and CPHA are **1**, the clock signal level is high in the idle state and data is sampled on the second clock edge.
+
+
+- SPI defines a set of common functions for operating an SPI device, including those for:
+ - Obtaining and releasing the handle of an SPI device.
+ - Reading or writing data of a specified length from or into an SPI device.
+ - Customizing data reading or writing via **SpiMsg**.
+ - Obtaining and setting SPI device configuration parameters.
+
+
+> **NOTE:**
+>Currently, these functions are only applicable in the communication initiated by the SPI controller.
+
+### Available APIs
+
+**Table 1** APIs for the SPI driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
SPI device handle obtaining/releasing
+
+
SpiOpen
+
+
Obtains an SPI device handle.
+
+
+
SpiClose
+
+
Releases an SPI device handle.
+
+
+
SPI reading/writing
+
+
SpiRead
+
+
Reads data of a specified length from an SPI device.
+
+
+
SpiWrite
+
+
Writes data of a specified length into an SPI device.
+
+
+
SpiTransfer
+
+
Transfers SPI data.
+
+
+
SPI device configuration
+
+
+
SpiSetCfg
+
+
Sets configuration parameters for an SPI device.
+
+
+
SpiGetCfg
+
+
Obtains configuration parameters of an SPI device.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig23885455594) shows the process of using an SPI device.
+
+**Figure 2** Process of using an SPI device
+
+
+
+
+### Obtaining an SPI Device Handle
+
+Before performing SPI communication, obtain an SPI device handle by calling **SpiOpen**. This function returns an SPI device handle with a specified bus number and CS number.
+
+DevHandle SpiOpen\(const struct SpiDevInfo \*info\);
+
+**Table 2** Description of **SpiOpen**
+
+
+
Parameter
+
+
Description
+
+
+
info
+
+
Pointer to the SPI device descriptor.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain an SPI device handle.
+
+
+
Device handle
+
+
Returns the pointer to the SPI device handle.
+
+
+
+
+
+The following example shows how to obtain an SPI device handle based on the assumption that both the bus number and CS number of the SPI device are **0**.
+
+```
+struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
+DevHandle spiHandle = NULL; /* SPI device handle */
+spiDevinfo.busNum = 0; /* SPI device bus number */
+spiDevinfo.csNum = 0; /* SPI device CS number */
+
+/* Obtain an SPI device handle. */
+spiHandle = SpiOpen(&spiDevinfo);
+if (spiHandle == NULL) {
+ HDF_LOGE("SpiOpen: failed\n");
+ return;
+}
+```
+
+### Obtaining SPI Device Configuration Parameters
+
+After obtaining the SPI device handle, obtain the SPI device configuration parameters by calling the following function:
+
+int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
+
+**Table 3** Description of **SpiGetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
cfg
+
+
Pointer to SPI device configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining SPI device configuration parameters.
+
+
+
Negative value
+
+
Failed to obtain SPI device configuration parameters.
+
+
+
+
+
+```
+int32_t ret;
+struct SpiCfg cfg = {0}; /* SPI configuration information */
+ret = SpiGetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
+}
+```
+
+### Setting SPI Device Configuration Parameters
+
+After obtaining the SPI device handle, set SPI device configuration parameters by calling the following function:
+
+int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
+
+**Table 4** Description of **SpiSetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
cfg
+
+
Pointer to SPI device configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting SPI device configuration parameters.
+
+
+
Negative value
+
+
Failed to set SPI device configuration parameters.
+
+
+
+
+
+```
+int32_t ret;
+struct SpiCfg cfg = {0}; /* SPI configuration information */
+cfg.mode = SPI_MODE_LOOP; /* Communication in loopback mode */
+cfg.transferMode = PAL_SPI_POLLING_TRANSFER; /* Communication in polling mode */
+cfg.maxSpeedHz = 115200; /* Maximum transmission frequency */
+cfg.bitsPerWord = 8; /* The width of per word to be read or written is 8 bits. */
+ret = SpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
+}
+```
+
+### Performing SPI Communication
+
+- Writing data of a specific length into an SPI device
+
+To write data into an SPI device only once, call the following function:
+
+int32\_t SpiWrite\(DevHandle handle, uint8\_t \*buf, uint32\_t len\);
+
+**Table 5** Description of **SpiWrite**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
buf
+
+
Pointer to the data to write.
+
+
+
len
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing data into an SPI device.
+
+
+
Negative value
+
+
Failed to write data into an SPI device.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t wbuff[4] = {0x12, 0x34, 0x56, 0x78};
+/* Write data of a specific length into an SPI device. */
+ret = SpiWrite(spiHandle, wbuff, 4);
+if (ret != 0) {
+ HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
+}
+```
+
+- Reading data of a specific length from an SPI device
+
+To read data from an SPI device only once, call the following function:
+
+int32\_t SpiRead\(DevHandle handle, uint8\_t \*buf, uint32\_t len\);
+
+**Table 6** Description of **SpiRead**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
buf
+
+
Pointer to the data to read.
+
+
+
len
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in reading data from an SPI device.
+
+
+
Negative value
+
+
Failed to read data from an SPI device.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t rbuff[4] = {0};
+/* Read data of a specific length from an SPI device. */
+ret = SpiRead(spiHandle, rbuff, 4);
+if (ret != 0) {
+ HDF_LOGE("SpiRead: failed, ret %d\n", ret);
+}
+```
+
+- Launching a custom transfer
+
+To launch a custom transfer, call the following function:
+
+int32\_t SpiTransfer\(DevHandle handle, struct SpiMsg \*msgs, uint32\_t count\);
+
+**Table 7** Description of **SpiTransfer**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
msgs
+
+
Pointer to the message array to be transferred.
+
+
+
count
+
+
Number of messages in the message array.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in launching the custom transfer.
+
+
+
Negative value
+
+
Failed to launch the custom transfer.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t wbuff[1] = {0x12};
+uint8_t rbuff[1] = {0};
+struct SpiMsg msg; /* Custom message to be transferred */
+msg.wbuf = wbuff; /* Pointer to the data to write */
+msg.rbuf = rbuff; /* Pointer to the data to read */
+msg.len = 1; /* The length of the data to read or write is 1 bit. */
+msg.csChange = 1; /* Disable the CS before the next transfer. */
+msg.delayUs = 0; /* No delay before the next transfer */
+msg.speed = 115200; /* Speed of this transfer */
+/* Launch a custom transfer. The number of messages to be transferred is 1. */
+ret = SpiTransfer(spiHandle, &msg, 1);
+if (ret != 0) {
+ HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
+}
+```
+
+### Destroying the SPI Device Handle
+
+After the SPI communication, destroy the SPI device handle by calling the following function:
+
+void SpiClose\(DevHandle handle\);
+
+This function will release the resources previously obtained.
+
+**Table 8** Description of **SpiClose**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
+
+
+```
+PalHandleDestroy(spiHandle); /* Destroy the SPI device handle. */
+```
+
+## Usage Example
+
+The following example shows how to obtain an SPI device handle, set the configuration parameters, and then read or write data from or into the SPI device, and finally destroy the SPI device handle.
+
+```
+#include "hdf_log.h"
+#include "spi_if.h"
+
+void SpiTestSample(void)
+{
+ int32_t ret;
+ struct SpiCfg cfg; /* SPI device configuration information */
+ struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
+ DevHandle spiHandle = NULL; /* SPI device handle */
+ struct SpiMsg msg; /* Custom message to be transferred */
+ uint8_t rbuff[4] = { 0 };
+ uint8_t wbuff[4] = { 0x12, 0x34, 0x56, 0x78 };
+ uint8_t wbuff2[4] = { 0xa1, 0xb2, 0xc3, 0xd4 };
+
+ spiDevinfo.busNum = 0; /* SPI device bus number */
+ spiDevinfo.csNum = 0; /* SPI device CS number */
+ spiHandle = SpiOpen(&spiDevinfo); /* Obtain an SPI device handle based on spiDevinfo. */
+ if (spiHandle == NULL) {
+ HDF_LOGE("SpiOpen: failed\n");
+ return;
+ }
+ /* Obtain configuration parameters of an SPI device. */
+ ret = SpiGetCfg(spiHandle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
+ goto err;
+ }
+ cfg.maxSpeedHz = 115200; /* Change the maximum clock frequency to 115200. */
+ cfg.bitsPerWord = 8; /* Change the word width to 8 bits. */
+ /* Set configuration parameters for an SPI device. */
+ ret = SpiSetCfg(spiHandle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Write specified length of data into an SPI device. */
+ ret = SpiWrite(spiHandle, wbuff, 4);
+ if (ret != 0) {
+ HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Read data of a specified length from an SPI device. */
+ ret = SpiRead(spiHandle, rbuff, 4);
+ if (ret != 0) {
+ HDF_LOGE("SpiRead: failed, ret %d\n", ret);
+ goto err;
+ }
+ msg.wbuf = wbuff2; /* Pointer to the data to write */
+ msg.rbuf = rbuff; /* Pointer to the data to read */
+ msg.len = 4; /* The length of the data to read or write is 4 bits. */
+ msg.csChange = 1; /* Disable the CS before the next transfer. */
+ msg.delayUs = 0; /* No delay before the next transfer */
+ msg.speed = 115200; /* Speed of this transfer */
+ /* Launch a custom transfer. The number of messages to be transferred is 1. */
+ ret = SpiTransfer(spiHandle, &msg, 1);
+ if (ret != 0) {
+ HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
+ goto err;
+ }
+err:
+ /* Destroy the SPI device handle. */
+ SpiClose(spiHandle);
+}
+```
diff --git a/en/device-dev/driver/spioverview.md b/en/device-dev/driver/spioverview.md
deleted file mode 100644
index 46303b336baaec8295a11afacc466aed62809c29..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spioverview.md
+++ /dev/null
@@ -1,107 +0,0 @@
-# SPI Overview
-
-- [Introduction](#section9202632114011)
-- [Available APIs](#section1859594134119)
-
-## Introduction
-
-- Serial Peripheral Interface \(SPI\) is a serial bus specification used for high-speed, full-duplex, and synchronous communication.
-- SPI is developed by Motorola. It is commonly used for communication with flash memory, real-time clocks, sensors, and analog-to-digital \(A/D\) converters.
-- SPI works in controller/device mode. Generally, there is one SPI controller that controls one or more SPI devices. They are connected via four wires:
- - SCLK: clock signals output from the SPI controller
- - MOSI: data output from the SPI controller and input into an SPI device
- - MISO: data output from an SPI device and input into the SPI controller
- - 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
-
-
-
-
-- SPI communication is usually initiated by the SPI controller and is operated as follows:
-
-1. A single SPI device is selected at a time via the CS to communicate with the SPI controller.
-2. Clock signals are provided for the selected SPI device via the SCLK.
-3. The SPI controller sends data to SPI devices via the MOSI, and receives data from SPI devices via the MISO.
-
-- SPI can work in one of the following four modes, equivalent to one of the four possible states for Clock Polarity \(CPOL\) and Clock Phase \(CPHA\):
- - If both CPOL and CPHA are **0**, the clock signal level is low in the idle state and data is sampled on the first clock edge.
- - If CPOL is **0** and CPHA is **1**, the clock signal level is low in the idle state and data is sampled on the second clock edge.
- - If CPOL is **1** and CPHA is **0**, the clock signal level is high in the idle state and data is sampled on the first clock edge.
- - If both CPOL and CPHA are **1**, the clock signal level is high in the idle state and data is sampled on the second clock edge.
-
-
-- SPI defines a set of common functions for operating an SPI device, including those for:
- - Obtaining and releasing the handle of an SPI device.
- - Reading or writing data of a specified length from or into an SPI device.
- - Customizing data reading or writing via **SpiMsg**.
- - Obtaining and setting SPI device configuration parameters.
-
-
-> **NOTE:**
->Currently, these functions are only applicable in the communication initiated by the SPI controller.
-
-## Available APIs
-
-**Table 1** APIs for the SPI driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
SPI device handle obtaining/releasing
-
-
SpiOpen
-
-
Obtains an SPI device handle.
-
-
-
SpiClose
-
-
Releases an SPI device handle.
-
-
-
SPI reading/writing
-
-
SpiRead
-
-
Reads data of a specified length from an SPI device.
-
-
-
SpiWrite
-
-
Writes data of a specified length into an SPI device.
-
-
-
SpiTransfer
-
-
Transfers SPI data.
-
-
-
SPI device configuration
-
-
-
SpiSetCfg
-
-
Sets configuration parameters for an SPI device.
-
-
-
SpiGetCfg
-
-
Obtains configuration parameters of an SPI device.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/spiusage-example.md b/en/device-dev/driver/spiusage-example.md
deleted file mode 100644
index f3d6cb2b6f667233355952efa8c7c91e780bc182..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spiusage-example.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# SPI Usage Example
-
-The following is a usage example of an SPI device, including how to obtain an SPI device handle, set the configuration parameters, and then read or write data from or into the SPI device, and finally destroy the SPI device handle.
-
-```
-#include "hdf_log.h"
-#include "spi_if.h"
-
-void SpiTestSample(void)
-{
- int32_t ret;
- struct SpiCfg cfg; /* SPI device configuration information */
- struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
- DevHandle spiHandle = NULL; /* SPI device handle */
- struct SpiMsg msg; /* Custom message to be transferred */
- uint8_t rbuff[4] = { 0 };
- uint8_t wbuff[4] = { 0x12, 0x34, 0x56, 0x78 };
- uint8_t wbuff2[4] = { 0xa1, 0xb2, 0xc3, 0xd4 };
-
- spiDevinfo.busNum = 0; /* SPI device bus number */
- spiDevinfo.csNum = 0; /* SPI device CS number */
- spiHandle = SpiOpen(&spiDevinfo); /* Obtain an SPI device handle based on spiDevinfo. */
- if (spiHandle == NULL) {
- HDF_LOGE("SpiOpen: failed\n");
- return;
- }
- /* Obtain configuration parameters of an SPI device. */
- ret = SpiGetCfg(spiHandle, &cfg);
- if (ret != 0) {
- HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
- goto err;
- }
- cfg.maxSpeedHz = 115200; /* Change the maximum clock frequency to 115200. */
- cfg.bitsPerWord = 8; /* Change the word width to 8 bits. */
- /* Set configuration parameters for an SPI device. */
- ret = SpiSetCfg(spiHandle, &cfg);
- if (ret != 0) {
- HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
- goto err;
- }
- /* Write specified length of data into an SPI device. */
- ret = SpiWrite(spiHandle, wbuff, 4);
- if (ret != 0) {
- HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
- goto err;
- }
- /* Read data of a specified length from an SPI device. */
- ret = SpiRead(spiHandle, rbuff, 4);
- if (ret != 0) {
- HDF_LOGE("SpiRead: failed, ret %d\n", ret);
- goto err;
- }
- msg.wbuf = wbuff2; /* Pointer to the data to write */
- msg.rbuf = rbuff; /* Pointer to the data to read */
- msg.len = 4; /* The length of the data to be read or written is 4 bits. */
- msg.csChange = 1; /* Disable the CS before the next transfer. */
- msg.delayUs = 0; /* No delay before the next transfer */
- msg.speed = 115200; /* Speed of this transfer */
- /* Launch a custom transfer. The number of messages to be transferred is 1. */
- ret = SpiTransfer(spiHandle, &msg, 1);
- if (ret != 0) {
- HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
- goto err;
- }
-err:
- /* Destroy the SPI device handle. */
- SpiClose(spiHandle);
-}
-```
-
diff --git a/en/device-dev/driver/spiusage-guidelines.md b/en/device-dev/driver/spiusage-guidelines.md
deleted file mode 100644
index f5f9c482c055005b3544881cf16ef8e4e197abc3..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spiusage-guidelines.md
+++ /dev/null
@@ -1,386 +0,0 @@
-# SPI Usage Guidelines
-
-- [How to Use](#section691514116412)
-- [Obtaining an SPI Device Handle](#section12372204616215)
-- [Obtaining SPI Device Configuration Parameters](#section17121446171311)
-- [Setting SPI Device Configuration Parameters](#section97691946634)
-- [Performing SPI Communication](#section197116254416)
-- [Destroying the SPI Device Handle](#section117661819108)
-
-## How to Use
-
-[Figure 1](#fig23885455594) shows the process of using an SPI device.
-
-**Figure 1** Process of using an SPI device
-
-
-
-
-## Obtaining an SPI Device Handle
-
-Before performing SPI communication, obtain an SPI device handle by calling **SpiOpen**. This function returns an SPI device handle with a specified bus number and CS number.
-
-DevHandle SpiOpen\(const struct SpiDevInfo \*info\);
-
-**Table 1** Description of **SpiOpen**
-
-
-
Parameter
-
-
Description
-
-
-
info
-
-
Pointer to the SPI device descriptor.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain an SPI device handle.
-
-
-
Device handle
-
-
Returns the pointer to the SPI device handle.
-
-
-
-
-
-The following example shows how to obtain an SPI device handle based on the assumption that both the bus number and CS number of the SPI device are **0**.
-
-```
-struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
-DevHandle spiHandle = NULL; /* SPI device handle */
-spiDevinfo.busNum = 0; /* SPI device bus number */
-spiDevinfo.csNum = 0; /* SPI device CS number */
-
-/* Obtain an SPI device handle. */
-spiHandle = SpiOpen(&spiDevinfo);
-if (spiHandle == NULL) {
- HDF_LOGE("SpiOpen: failed\n");
- return;
-}
-```
-
-## Obtaining SPI Device Configuration Parameters
-
-After obtaining the SPI device handle, obtain the SPI device configuration parameters by calling the following function:
-
-int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-
-**Table 2** Description of **SpiGetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
cfg
-
-
Pointer to SPI device configuration parameters.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining SPI device configuration parameters.
-
-
-
Negative value
-
-
Failed to obtain SPI device configuration parameters.
-
-
-
-
-
-```
-int32_t ret;
-struct SpiCfg cfg = {0}; /* SPI configuration information */
-ret = PalSpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
-if (ret != 0) {
- HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
-}
-```
-
-## Setting SPI Device Configuration Parameters
-
-After obtaining the SPI device handle, set SPI device configuration parameters by calling the following function:
-
-int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-
-**Table 3** Description of **SpiSetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
cfg
-
-
Pointer to SPI device configuration parameters.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting SPI device configuration parameters.
-
-
-
Negative value
-
-
Failed to set SPI device configuration parameters.
-
-
-
-
-
-```
-int32_t ret;
-struct SpiCfg cfg = {0}; /* SPI configuration information */
-cfg.mode = SPI_MODE_LOOP; /* Communicate in loopback mode. */
-cfg.comMode = PAL_SPI_POLLING_TRANSFER; /* Communicate in polling mode. */
-cfg.maxSpeedHz = 115200; /* Maximum transmission frequency */
-cfg.bitsPerWord = 8; /* The width of per word to be read or written is 8 bits. */
-ret = SpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
-if (ret != 0) {
- HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
-}
-```
-
-## Performing SPI Communication
-
-- Writing data of a specified length into an SPI device
-
-To write data into an SPI device only once, call the following function:
-
-int32\_t SpiWrite\(DevHandle handle, uint8\_t \*buf, uint32\_t len\);
-
-**Table 4** Description of **SpiWrite**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
buf
-
-
Pointer to the data to write.
-
-
-
len
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing data into an SPI device.
-
-
-
Negative value
-
-
Failed to write data into an SPI device.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t wbuff[4] = {0x12, 0x34, 0x56, 0x78};
-/* Write data of a specified length into an SPI device. */
-ret = SpiWrite(spiHandle, wbuff, 4);
-if (ret != 0) {
- HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
-}
-```
-
-- Reading data of a specified length from an SPI device
-
-To read data from an SPI device only once, call the following function:
-
-int32\_t SpiRead\(DevHandle handle, uint8\_t \*buf, uint32\_t len\);
-
-**Table 5** Description of **SpiRead**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
buf
-
-
Pointer to the data to read.
-
-
-
len
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in reading data from an SPI device.
-
-
-
Negative value
-
-
Failed to read data from an SPI device.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t rbuff[4] = {0};
-/* Read data of a specified length from an SPI device. */
-ret = SpiRead(spiHandle, rbuff, 4);
-if (ret != 0) {
- HDF_LOGE("SpiRead: failed, ret %d\n", ret);
-}
-```
-
-- Launching a custom transfer
-
-To launch a custom transfer, call the following function:
-
-int32\_t SpiTransfer\(DevHandle handle, struct SpiMsg \*msgs, uint32\_t count\);
-
-**Table 6** Description of **SpiTransfer**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
msgs
-
-
Pointer to the message array to be transferred.
-
-
-
count
-
-
Length of the message array.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in launching the custom transfer.
-
-
-
Negative value
-
-
Failed to launch the custom transfer.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t wbuff[1] = {0x12};
-uint8_t rbuff[1] = {0};
-struct SpiMsg msg; /* Custom message to be transferred */
-msg.wbuf = wbuff; /* Pointer to the data to read */
-msg.rbuf = rbuff; /* Pointer to the data to read */
-msg.len = 1; /* The length of the data to be read or written is 1 bit. */
-msg.csChange = 1; /* Disable the CS before the next transfer. */
-msg.delayUs = 0; /* No delay before the next transfer */
-msg.speed = 115200; /* Speed of this transfer */
-/* Launch a custom transfer. The number of messages to be transferred is 1. */
-ret = SpiTransfer(spiHandle, &msg, 1);
-if (ret != 0) {
- HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
-}
-```
-
-## Destroying the SPI Device Handle
-
-After the SPI communication, destroy the SPI device handle by calling the following function:
-
-void SpiClose\(DevHandle handle\);
-
-This function will release the resources previously obtained.
-
-**Table 7** Description of **SpiClose**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle
-
-
-
-
-
-```
-PalHandleDestroy(spiHandle); /* Destroy the SPI device handle. */
-```
-
diff --git a/en/device-dev/driver/touchscreen.md b/en/device-dev/driver/touchscreen.md
index 49b35d23fb1f1ea0438f92292ae22e794a155dbb..8a4c422ce4a440a5b6ec90381f86922b67b71189 100644
--- a/en/device-dev/driver/touchscreen.md
+++ b/en/device-dev/driver/touchscreen.md
@@ -1,9 +1,410 @@
-# TOUCHSCREEN
+# TOUCHSCREEN
-- **[Touchscreen Overview](touchscreenoverview.md)**
+- [Overview](#section175431838101617)
+ - [Available APIs](#section17667171301711)
-- **[Touchscreen Development Guidelines](touchscreendevelopment-guidelines.md)**
+- [Development Guidelines](#section65745222184)
+ - [How to Develop](#section865734181916)
-- **[Touchscreen Development Example](touchscreendevelopment-example.md)**
+- [Development Example](#section263714411191)
+ - [Add the touchscreen driver-related descriptions.](#section18249155619195)
+ - [Board-level Hardware Configuration and Private Data Configuration](#section3571192072014)
+ - [Adding the Touchscreen Driver](#section6356758162015)
+## Overview
+
+- **Functions of the Touchscreen driver**
+
+ The Touchscreen driver is used to power on its integrated circuit \(IC\), configure and initialize hardware pins, register interrupts, configure Inter-Integrated Circuit \(I2C\) or SPI APIs, set input-related configurations, and download and update firmware.
+
+
+- **Layers of the Touchscreen driver**
+
+ This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver.
+
+ The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
+
+
+**Figure 1** Architecture of the input driver model
+
+
+- **Input driver model**
+
+ The input driver model mainly consists of the device manager, common drivers, and chip drivers. The platform data channel provides capabilities for sending data generated by the touchscreen from the kernel to the user space. The driver model adapts to different touchscreen devices and hardware platforms via the configuration file, improving the efficiency of the touchscreen development. The description for each part of the input driver model is as follows:
+
+ - Input device manager: provides input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
+
+ - Input common driver: provides common abstract drivers \(such as the touchscreen common driver\) of various input devices for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
+
+ - Input chip driver: provides different chip drivers of each vendor. You can minimize the workload for the input chip driver development by calling differentiated APIs reserved by the input platform driver.
+
+ - Event hub: provides a unified data reporting channel, which enables input devices to report input events.
+
+ - HDF input config: parses and manages the board-level configuration as well as the private configuration of input devices.
+
+
+- **Advantages of developing drivers based on the HDF**
+
+ The touchscreen driver is developed based on the [HDF](driver-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
+
+Based on the attributes of the pins, interfaces on the touchscreens can be classified into the following types:
+
+- Power interfaces
+- I/O control interfaces
+- Communications interfaces
+
+**Figure 2** Common pins of the touchscreen
+
+
+The interfaces shown in the figure are described as follows:
+
+1. **Power interfaces**
+ - LDO\_1P8: 1.8 V digital circuits
+ - LDO\_3P3: 3.3 V analog circuits
+
+ Generally, the touchscreen driver IC is separated from the LCD driver IC. In this case, the touchscreen driver IC requires both 1.8 V and 3.3 V power supplies. Nowadays, the touchscreen driver IC and LCD driver IC can be integrated. Therefore, the touchscreen, requires only the 1.8 V power supply, and the 3.3 V power required internally is supplied by the LCD VSP power \(typical value: 5.5 V\) in the driver IC.
+
+
+2. **I/O control interfaces**
+ - RESET: reset pin, which is used to reset the driver IC on the host when suspending or resuming the system.
+ - 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](i2c.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](spi.md#section71363452477).
+
+
+## Development Guidelines
+
+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.
+
+ \(2\) Load the input device management driver. The input management driver is loaded automatically by the HDF to create and initialize the device manager.
+
+ \(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.
+
+ \(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.
+
+ \(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
+
+1. Add the touchscreen driver-related descriptions.
+
+ Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [Driver Development](driver-development.md#section1969312275533).
+
+2. Complete the board-level configuration and private data configuration of the touchscreen.
+
+ Configure the required I/O pins. For example, configure a register for the I2C pin reserved for the touchscreen to use I2C for transmitting data.
+
+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](gpio.md#section259614242196).
+
+
+## Development Example
+
+This example describes how to develop the touchscreen driver.
+
+### Add the touchscreen driver-related descriptions.
+
+The information about modules of the input driver model is shown as follows and enables the HDF to load the modules in sequence. For details, see [Driver Development](driver-development.md).
+
+```
+input :: host {
+ hostName = "input_host";
+ priority = 100;
+ device_input_manager :: device {
+ device0 :: deviceNode {
+ policy = 2; // Publish services externally.
+ priority = 100; // Loading priority. The input device manager in the input driver has the highest priority.
+ preload = 0; // Value 0 indicates that the driver is to be loaded, and value 1 indicates the opposite.
+ permission = 0660;
+ moduleName = "HDF_INPUT_MANAGER";
+ serviceName = "input_dev_manager";
+ deviceMatchAttr = "";
+ }
+ }
+ device_hdf_touch :: device {
+ device0 :: deviceNode {
+ policy = 2;
+ priority = 120;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH";
+ serviceName = "event1";
+ deviceMatchAttr = "touch_device1";
+ }
+ }
+
+ device_touch_chip :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 130;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH_SAMPLE";
+ serviceName = "hdf_touch_sample_service";
+ deviceMatchAttr = "zsj_sample_5p5";
+ }
+ }
+}
+```
+
+### Board-level Hardware Configuration and Private Data Configuration
+
+The following describes the configuration of the board-level hardware and private data of the touchscreen. You can modify the configuration based on service requirements.
+
+```
+root {
+ input_config {
+ touchConfig {
+ touch0 {
+ boardConfig {
+ match_attr = "touch_device1";
+ inputAttr {
+ inputType = 0; // Value 0 indicates that the input device is a touchscreen.
+ solutionX = 480;
+ solutionY = 960;
+ devName = "main_touch"; // Device name
+ }
+ busConfig {
+ busType = 0; // Value 0 indicates the I2C bus.
+ busNum = 6;
+ clkGpio = 86;
+ dataGpio = 87;
+ i2cClkIomux = [0x114f0048, 0x403]; // Register configuration of the i2c_clk pin
+ i2cDataIomux = [0x114f004c, 0x403]; // Register configuration of the i2c_data pin
+ }
+ pinConfig {
+ rstGpio = 3;
+ intGpio = 4;
+ rstRegCfg = [0x112f0094, 0x400]; // Register configuration of the reset pin
+ intRegCfg = [0x112f0098, 0x400]; // Register configuration of the interrupt pin
+ }
+ powerConfig {
+ vccType = 2; // Values 1, 2, and 3 indicate the low-dropout regulator (LDO), GPIO, and PMIC, respectively.
+ vccNum = 20; // The GPIO number is 20.
+ vccValue = 1800; // The voltage amplitude is 1800 mV.
+ vciType = 1;
+ vciNum = 12;
+ vciValue = 3300;
+ }
+ featureConfig {
+ capacitanceTest = 0;
+ gestureMode = 0;
+ gloverMOde = 0;
+ coverMode = 0;
+ chargerMode = 0;
+ knuckleMode = 0;
+ }
+ }
+ chipConfig {
+ template touchChip {
+ match_attr = "";
+ chipName = "sample";
+ vendorName = "zsj";
+ chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
+ busType = 0;
+ deviceAddr = 0x5D;
+ irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
+ maxSpeed = 400;
+ chipVersion = 0;
+ powerSequence {
+ /* Power-on sequence is described as follows:
+ [Type, status, direction, delay]
+ Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
+ Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
+ Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
+ Delay time, in milliseconds.
+ */
+ powerOnSeq = [4, 0, 1, 0,
+ 3, 0, 1, 10,
+ 3, 1, 2, 60,
+ 4, 2, 0, 0];
+ suspendSeq = [3, 0, 2, 10];
+ resumeSeq = [3, 1, 2, 10];
+ powerOffSeq = [3, 0, 2, 10,
+ 1, 0, 2, 20];
+ }
+ }
+ chip0 :: touchChip {
+ match_attr = "zsj_sample_5p5";
+ chipInfo = "ZIDN45100";
+ chipVersion = 0;
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+### Adding the Touchscreen Driver
+
+The following example shows how to implement the differentiated APIs provided by the platform driver to obtain and parse the touchscreen data. You can adjust the development process based on the board and touchscreen in use.
+
+```
+/* Parse the touch reporting data read from the touchscreen into coordinates. */
+static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
+{
+ int32_t resX = device->driver->boardCfg->attr.resolutionX;
+ int32_t resY = device->driver->boardCfg->attr.resolutionY;
+
+ for (int32_t i = 0; i < pointNum; i++) {
+ frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ frame->fingers[i].valid = true;
+ }
+}
+/* Obtain the touch reporting data from the chip. */
+static int32_t ChipDataHandle(ChipDevice *device)
+{
+ int32_t ret;
+ uint8_t touchStatus = 0;
+ uint8_t pointNum;
+ uint8_t buf[GT_POINT_SIZE * MAX_SUPPORT_POINT] = {0};
+ InputI2cClient *i2cClient = &device->driver->i2cClient;
+ uint8_t reg[GT_ADDR_LEN] = {0};
+ FrameData *frame = &device->driver->frameData;
+ reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
+ ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
+ if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
+ return HDF_FAILURE;
+ }
+ OsalMutexLock(&device->driver->mutex);
+ (void)memset_s(frame, sizeof(FrameData), 0, sizeof(FrameData));
+ if (touchStatus == GT_EVENT_UP) {
+ frame->realPointNum = 0;
+ frame->definedEvent = TOUCH_UP;
+ goto exit;
+ }
+ reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
+ pointNum = touchStatus & GT_FINGER_NUM_MASK;
+ if (pointNum <= 0 || pointNum > MAX_SUPPORT_POINT) {
+ HDF_LOGE("%s: pointNum is invalid, %d", __func__, pointNum);
+ (void)ChipCleanBuffer(i2cClient);
+ OsalMutexUnlock(&device->driver->mutex);
+ return HDF_FAILURE;
+ }
+ frame->realPointNum = pointNum;
+ frame->definedEvent = TOUCH_DOWN;
+ /* Read the touch reporting data from the register. */
+ (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
+ /* Parse the touch reporting data. */
+ ParsePointData(device, frame, buf, pointNum);
+exit:
+ OsalMutexUnlock(&device->driver->mutex);
+ if (ChipCleanBuffer(i2cClient) != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+static struct TouchChipOps g_sampleChipOps = {
+ .Init = ChipInit,
+ .Detect = ChipDetect,
+ .Resume = ChipResume,
+ .Suspend = ChipSuspend,
+ .DataHandle = ChipDataHandle,
+};
+
+static TouchChipCfg *ChipConfigInstance(struct HdfDeviceObject *device)
+{
+ TouchChipCfg *chipCfg = (TouchChipCfg *)OsalMemAlloc(sizeof(TouchChipCfg));
+ if (chipCfg == NULL) {
+ HDF_LOGE("%s: instance chip config failed", __func__);
+ return NULL;
+ }
+ (void)memset_s(chipCfg, sizeof(TouchChipCfg), 0, sizeof(TouchChipCfg));
+ /* Parse the private configuration of the touchscreen. */
+ if (ParseTouchChipConfig(device->property, chipCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: parse chip config failed", __func__);
+ OsalMemFree(chipCfg);
+ chipCfg = NULL;
+ }
+ return chipCfg;
+}
+
+static ChipDevice *ChipDeviceInstance(void)
+{
+ ChipDevice *chipDev = (ChipDevice *)OsalMemAlloc(sizeof(ChipDevice));
+ if (chipDev == NULL) {
+ HDF_LOGE("%s: instance chip device failed", __func__);
+ return NULL;
+ }
+ (void)memset_s(chipDev, sizeof(ChipDevice), 0, sizeof(ChipDevice));
+ return chipDev;
+}
+
+static void FreeChipConfig(TouchChipCfg *config)
+{
+ if (config->pwrSeq.pwrOn.buf != NULL) {
+ OsalMemFree(config->pwrSeq.pwrOn.buf);
+ }
+ if (config->pwrSeq.pwrOff.buf != NULL) {
+ OsalMemFree(config->pwrSeq.pwrOff.buf);
+ }
+ OsalMemFree(config);
+}
+
+static int32_t HdfSampleChipInit(struct HdfDeviceObject *device)
+{
+ TouchChipCfg *chipCfg = NULL;
+ ChipDevice *chipDev = NULL;
+ HDF_LOGE("%s: enter", __func__);
+ if (device == NULL) {
+ return HDF_ERR_INVALID_PARAM;
+ }
+ /* Parse the private configuration of the touchscreen. */
+ chipCfg = ChipConfigInstance(device);
+ if (chipCfg == NULL) {
+ return HDF_ERR_MALLOC_FAIL;
+ }
+ /* Instantiate the touchscreen device. */
+ chipDev = ChipDeviceInstance();
+ if (chipDev == NULL) {
+ goto freeCfg;
+ }
+ chipDev->chipCfg = chipCfg;
+ chipDev->ops = &g_sampleChipOps;
+ chipDev->chipName = chipCfg->chipName;
+ chipDev->vendorName = chipCfg->vendorName;
+
+ /* Register the touchscreen device with the platform driver. */
+ if (RegisterChipDevice(chipDev) != HDF_SUCCESS) {
+ goto freeDev;
+ }
+ HDF_LOGI("%s: exit succ, chipName = %s", __func__, chipCfg->chipName);
+ return HDF_SUCCESS;
+
+freeDev:
+ OsalMemFree(chipDev);
+freeCfg:
+ FreeChipConfig(chipCfg);
+ return HDF_FAILURE;
+}
+
+struct HdfDriverEntry g_touchSampleChipEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH_SAMPLE",
+ .Init = HdfSampleChipInit,
+};
+
+HDF_INIT(g_touchSampleChipEntry);
+```
+
diff --git a/en/device-dev/driver/touchscreendevelopment-example.md b/en/device-dev/driver/touchscreendevelopment-example.md
deleted file mode 100644
index 8d49343af5e1b1c2e1aaaa1fc113d75f2dc8a540..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreendevelopment-example.md
+++ /dev/null
@@ -1,300 +0,0 @@
-# Touchscreen Development Example
-
-- [Device Description Configuration](#section85281142102317)
-- [Board-level Hardware Configuration and Private Data Configuration](#section189081946192410)
-- [Adding the Touchscreen Driver](#section19856687253)
-
-This example describes how to develop the touchscreen driver.
-
-## Device Description Configuration
-
-The information about modules of the input driver model is shown as follows and enables the HDF to load the modules in sequence. For details, see [Driver Development](driver-development.md).
-
-```
-input :: host {
- hostName = "input_host";
- priority = 100;
- device_input_manager :: device {
- device0 :: deviceNode {
- policy = 2; // Publish services externally.
- priority = 100; // Loading priority. The input device manager in the input driver has the highest priority.
- preload = 0; // Value 0 indicates that the driver is to be loaded, and value 1 indicates the opposite.
- permission = 0660;
- moduleName = "HDF_INPUT_MANAGER";
- serviceName = "input_dev_manager";
- deviceMatchAttr = "";
- }
- }
- device_hdf_touch :: device {
- device0 :: deviceNode {
- policy = 2;
- priority = 120;
- preload = 0;
- permission = 0660;
- moduleName = "HDF_TOUCH";
- serviceName = "event1";
- deviceMatchAttr = "touch_device1";
- }
- }
-
- device_touch_chip :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 130;
- preload = 0;
- permission = 0660;
- moduleName = "HDF_TOUCH_SAMPLE";
- serviceName = "hdf_touch_sample_service";
- deviceMatchAttr = "zsj_sample_5p5";
- }
- }
-}
-```
-
-## Board-level Hardware Configuration and Private Data Configuration
-
-The following describes the configuration of the board-level hardware and private data of the touchscreen. You can modify the configuration based on the service requirements.
-
-```
-root {
- input_config {
- touchConfig {
- touch0 {
- boardConfig {
- match_attr = "touch_device1";
- inputAttr {
- inputType = 0; // Value 0 indicates that the input device is a touchscreen.
- solutionX = 480;
- solutionY = 960;
- devName = "main_touch"; // Device name
- }
- busConfig {
- busType = 0; // Value 0 indicates the I2C bus.
- busNum = 6;
- clkGpio = 86;
- dataGpio = 87;
- i2cClkIomux = [0x114f0048, 0x403]; // Register configuration of the i2c_clk pin
- i2cDataIomux = [0x114f004c, 0x403]; // Register configuration of the i2c_data pin
- }
- pinConfig {
- rstGpio = 3;
- intGpio = 4;
- rstRegCfg = [0x112f0094, 0x400]; // Register configuration of the reset pin
- intRegCfg = [0x112f0098, 0x400]; // Register configuration of the interrupt pin
- }
- powerConfig {
- vccType = 2; // Values 1, 2, and 3 indicate the low-dropout regulator (LDO), GPIO, and PMIC, respectively.
- vccNum = 20; // The GPIO number is 20.
- vccValue = 1800; // The voltage amplitude is 1800 mV.
- vciType = 1;
- vciNum = 12;
- vciValue = 3300;
- }
- featureConfig {
- capacitanceTest = 0;
- gestureMode = 0;
- gloverMOde = 0;
- coverMode = 0;
- chargerMode = 0;
- knuckleMode = 0;
- }
- }
- chipConfig {
- template touchChip {
- match_attr = "";
- chipName = "sample";
- vendorName = "zsj";
- chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
- busType = 0;
- deviceAddr = 0x5D;
- irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
- maxSpeed = 400;
- chipVersion = 0;
- powerSequence {
- /* Power-on sequence is described as follows:
- [Type, status, direction, delay]
- Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
- Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
- Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
- Delay time, in milliseconds.
- */
- powerOnSeq = [4, 0, 1, 0,
- 3, 0, 1, 10,
- 3, 1, 2, 60,
- 4, 2, 0, 0];
- suspendSeq = [3, 0, 2, 10];
- resumeSeq = [3, 1, 2, 10];
- powerOffSeq = [3, 0, 2, 10,
- 1, 0, 2, 20];
- }
- }
- chip0 :: touchChip {
- match_attr = "zsj_sample_5p5";
- chipInfo = "ZIDN45100";
- chipVersion = 0;
- }
- }
- }
- }
- }
-}
-```
-
-## Adding the Touchscreen Driver
-
-The following example shows how to implement the differentiated APIs provided by the platform driver to obtain and parse the touchscreen data. You can adjust the development process based on the board and touchscreen in use.
-
-```
-/* Parse the touch reporting data read from the touchscreen into coordinates. */
-static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
-{
- int32_t resX = device->driver->boardCfg->attr.resolutionX;
- int32_t resY = device->driver->boardCfg->attr.resolutionY;
-
- for (int32_t i = 0; i < pointNum; i++) {
- frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- frame->fingers[i].valid = true;
- }
-}
-/* Obtain the touch reporting data from the chip. */
-static int32_t ChipDataHandle(ChipDevice *device)
-{
- int32_t ret;
- uint8_t touchStatus = 0;
- uint8_t pointNum;
- uint8_t buf[GT_POINT_SIZE * MAX_SUPPORT_POINT] = {0};
- InputI2cClient *i2cClient = &device->driver->i2cClient;
- uint8_t reg[GT_ADDR_LEN] = {0};
- FrameData *frame = &device->driver->frameData;
- reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
- ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
- if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
- return HDF_FAILURE;
- }
- OsalMutexLock(&device->driver->mutex);
- (void)memset_s(frame, sizeof(FrameData), 0, sizeof(FrameData));
- if (touchStatus == GT_EVENT_UP) {
- frame->realPointNum = 0;
- frame->definedEvent = TOUCH_UP;
- goto exit;
- }
- reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
- pointNum = touchStatus & GT_FINGER_NUM_MASK;
- if (pointNum <= 0 || pointNum > MAX_SUPPORT_POINT) {
- HDF_LOGE("%s: pointNum is invalid, %d", __func__, pointNum);
- (void)ChipCleanBuffer(i2cClient);
- OsalMutexUnlock(&device->driver->mutex);
- return HDF_FAILURE;
- }
- frame->realPointNum = pointNum;
- frame->definedEvent = TOUCH_DOWN;
- /* Read the touch reporting data from the register. */
- (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
- /* Parse the touch reporting data. */
- ParsePointData(device, frame, buf, pointNum);
-exit:
- OsalMutexUnlock(&device->driver->mutex);
- if (ChipCleanBuffer(i2cClient) != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-static struct TouchChipOps g_sampleChipOps = {
- .Init = ChipInit,
- .Detect = ChipDetect,
- .Resume = ChipResume,
- .Suspend = ChipSuspend,
- .DataHandle = ChipDataHandle,
-};
-
-static TouchChipCfg *ChipConfigInstance(struct HdfDeviceObject *device)
-{
- TouchChipCfg *chipCfg = (TouchChipCfg *)OsalMemAlloc(sizeof(TouchChipCfg));
- if (chipCfg == NULL) {
- HDF_LOGE("%s: instance chip config failed", __func__);
- return NULL;
- }
- (void)memset_s(chipCfg, sizeof(TouchChipCfg), 0, sizeof(TouchChipCfg));
- /* Parse the private configuration of the touchscreen. */
- if (ParseTouchChipConfig(device->property, chipCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: parse chip config failed", __func__);
- OsalMemFree(chipCfg);
- chipCfg = NULL;
- }
- return chipCfg;
-}
-
-static ChipDevice *ChipDeviceInstance(void)
-{
- ChipDevice *chipDev = (ChipDevice *)OsalMemAlloc(sizeof(ChipDevice));
- if (chipDev == NULL) {
- HDF_LOGE("%s: instance chip device failed", __func__);
- return NULL;
- }
- (void)memset_s(chipDev, sizeof(ChipDevice), 0, sizeof(ChipDevice));
- return chipDev;
-}
-
-static void FreeChipConfig(TouchChipCfg *config)
-{
- if (config->pwrSeq.pwrOn.buf != NULL) {
- OsalMemFree(config->pwrSeq.pwrOn.buf);
- }
- if (config->pwrSeq.pwrOff.buf != NULL) {
- OsalMemFree(config->pwrSeq.pwrOff.buf);
- }
- OsalMemFree(config);
-}
-
-static int32_t HdfSampleChipInit(struct HdfDeviceObject *device)
-{
- TouchChipCfg *chipCfg = NULL;
- ChipDevice *chipDev = NULL;
- HDF_LOGE("%s: enter", __func__);
- if (device == NULL) {
- return HDF_ERR_INVALID_PARAM;
- }
- /* Parse the private configuration of the touchscreen. */
- chipCfg = ChipConfigInstance(device);
- if (chipCfg == NULL) {
- return HDF_ERR_MALLOC_FAIL;
- }
- /* Instantiate the touchscreen device. */
- chipDev = ChipDeviceInstance();
- if (chipDev == NULL) {
- goto freeCfg;
- }
- chipDev->chipCfg = chipCfg;
- chipDev->ops = &g_sampleChipOps;
- chipDev->chipName = chipCfg->chipName;
- chipDev->vendorName = chipCfg->vendorName;
-
- /* Register the touchscreen device with the platform driver. */
- if (RegisterChipDevice(chipDev) != HDF_SUCCESS) {
- goto freeDev;
- }
- HDF_LOGI("%s: exit succ, chipName = %s", __func__, chipCfg->chipName);
- return HDF_SUCCESS;
-
-freeDev:
- OsalMemFree(chipDev);
-freeCfg:
- FreeChipConfig(chipCfg);
- return HDF_FAILURE;
-}
-
-struct HdfDriverEntry g_touchSampleChipEntry = {
- .moduleVersion = 1,
- .moduleName = "HDF_TOUCH_SAMPLE",
- .Init = HdfSampleChipInit,
-};
-
-HDF_INIT(g_touchSampleChipEntry);
-```
-
diff --git a/en/device-dev/driver/touchscreendevelopment-guidelines.md b/en/device-dev/driver/touchscreendevelopment-guidelines.md
deleted file mode 100644
index 9e1543c1e668c4bdc8aa62be3073a6539ff5f1de..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreendevelopment-guidelines.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Touchscreen Development Guidelines
-
-- [How to Develop](#section1255740132616)
-
-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:
- - Add the touchscreen driver-related descriptions: You can add the touchscreen driver-related descriptions, such as the loading priority, board-level hardware information, and private data, by referring to the existing template.
-
- - Load the input device manager driver: The HDF automatically loads the input device manager driver, which then creates the device manager and initializes it.
-
- - Load the touchscreen common driver: The HDF automatically loads the touchscreen common driver, which then parses the board-level configuration, initializes the hardware, and provides the API for registering the touchscreen.
-
- - Load the touchscreen chip driver: The HDF automatically loads the touchscreen chip driver, which then instantiates the touchscreen device, parses the private data, and implements differentiated APIs provided by the platform.
-
- - Register the touchscreen device with the platform driver: Register the instantiated touchscreen device with the platform driver, bind this device to the platform driver, and complete touchscreen initialization such as interrupt registration and power-on and power-off.
-
- - Register the input device: Instantiate the input device and register it with the input manager after the touchscreen is initialized.
-
-
-## How to Develop
-
-1. Add the touchscreen driver-related descriptions.
-
- Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [How to Develop](driver-development.md#section1969312275533).
-
-2. Complete the board-level configuration and private data configuration of the touchscreen.
-
- Configure the required I/O pins. For example, configure a register for the I2C pin reserved for the touchscreen to use I2C for transmitting data.
-
-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 Usage Guidelines](gpiousage-guidelines.md).
-
-
diff --git a/en/device-dev/driver/touchscreenoverview.md b/en/device-dev/driver/touchscreenoverview.md
deleted file mode 100644
index b136894e5ade080a07e5ff457b20fd74eefd33b9..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreenoverview.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# Touchscreen Overview
-
-- [Introduction](#section124332411260)
-- [Available APIs](#section10542625172618)
-
-## Introduction
-
-- **Functions of the Touchscreen driver**
-
- The Touchscreen driver is used to power on its integrated circuit \(IC\), configure and initialize hardware pins, register interrupts, configure Inter-Integrated Circuit \(I2C\) or SPI APIs, set input-related configurations, and download and update firmware.
-
-
-- **Layers of the Touchscreen driver**
-
- This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver.
-
- The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
-
-
-**Figure 1** Architecture of the input driver model
-
-
-- **Input driver model**
-
- The input driver model mainly consists of the device manager, common drivers, and chip drivers. The platform data channel provides capabilities for sending data generated by the touchscreen from the kernel to the user space. The driver model adapts to different touchscreen devices and hardware platforms via the configuration file, improving the efficiency of the touchscreen development. The description for each part of the input driver model is as follows:
-
- - Input device manager: provides various input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
-
- - Input common driver: provides common abstract drivers \(such as the touchscreen common driver\) of various input devices for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
-
- - Input chip driver: provides different chip drivers of each vendor. You can minimize the workload for the input chip driver development by calling differentiated APIs reserved by the input platform driver.
-
- - Event hub: provides a unified data reporting channel, which enables various input devices to report input events.
-
- - HDF input config: parses and manages the board-level configuration as well as the private configuration of input devices.
-
-
-- **Advantages of developing drivers based on the HDF**
-
- The touchscreen driver is developed based on the HDF 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
-
-Based on the attributes of the pins, interfaces on the touchscreens can be classified into the following types:
-
-- Power interfaces
-- I/O control interfaces
-- Communications interfaces
-
-**Figure 2** Common pins of the touchscreen
-
-
-The interfaces shown in the figure are described as follows:
-
-1. **Power interfaces**
- - LDO\_1P8: 1.8 V digital circuits
- - LDO\_3P3: 3.3 V analog circuits
-
- Generally, the touchscreen driver IC is separated from the LCD driver IC. In this case, the touchscreen driver IC requires both 1.8 V and 3.3 V power supplies. Nowadays, the touchscreen driver IC and LCD driver IC can be integrated. Therefore, the touchscreen, requires only the 1.8 V power supply, and the 3.3 V power required internally is supplied by the LCD VSP power \(typical value: 5.5 V\) in the driver IC.
-
-
-2. **I/O control interfaces**
- - RESET: reset pin, which is used to reset the driver IC on the host when suspending or resuming the system.
- - 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 Usage Guidelines](i2c-usage-guidelines.md).
- - 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 Usage Guidelines](spiusage-guidelines.md).
-
-
diff --git a/en/device-dev/driver/uart.md b/en/device-dev/driver/uart.md
index 9abd98bb4e661a01011d233577ae4109bcdd208e..508eb32cd95a235ddff1965a5602d7bfc4578292 100644
--- a/en/device-dev/driver/uart.md
+++ b/en/device-dev/driver/uart.md
@@ -1,9 +1,682 @@
-# UART
+# UART
-- **[UART Overview](uartoverview.md)**
+- [Overview](#section833012453535)
+ - [Available APIs](#section1680292311549)
-- **[UART Usage Guidelines](uartusage-guidelines.md)**
+- [Usage Guidelines](#section12779050105412)
+ - [How to Use](#section1858116395510)
+ - [Obtaining a UART Device Handle](#section124512065617)
+ - [Setting the UART Baud Rate](#section86881004579)
+ - [Obtaining the UART Baud Rate](#section897032965712)
+ - [Setting the UART Device Attributes](#section129141884588)
+ - [Obtaining UART Device Attributes](#section18689637165812)
+ - [Setting the UART Transmission Mode](#section72713435918)
+ - [Writing Data of a Specified Length into a UART Device](#section128001736155919)
+ - [Reading Data of a Specified Length from a UART Device](#section92851601604)
+ - [Destroying the UART Device Handle](#section1477410521406)
-- **[UART Usage Example](uartusage-example.md)**
+- [Usage Example](#section35404241311)
+## Overview
+
+- 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)\).
+ - 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
+
+
+ 
+
+
+- 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
+
+**Table 1** APIs for the UART driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
Obtaining and releasing device handles
+
+
+
UartOpen
+
+
Obtains the UART device handle.
+
+
+
UartClose
+
+
Releases a specified UART device handle.
+
+
+
Reading and writing data
+
+
+
UartRead
+
+
Reads data of a specified length from a UART device.
+
+
+
UartWrite
+
+
Writes data of a specified length into a UART device.
+
+
+
Obtaining and setting the baud rate
+
+
UartGetBaud
+
+
Obtains the UART baud rate.
+
+
+
UartSetBaud
+
+
Sets the UART baud rate.
+
+
+
Obtaining and setting device attributes
+
+
+
UartGetAttribute
+
+
Obtains the UART device attributes.
+
+
+
UartSetAttribute
+
+
Sets the UART device attributes.
+
+
+
Setting the transmission mode
+
+
UartSetTransMode
+
+
Sets the UART transmission mode.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 3](#fig1852173020185) shows the process of using a UART device.
+
+**Figure 3** Process of using a UART device
+
+
+
+
+### Obtaining a UART Device Handle
+
+Before performing UART communication, call **UartOpen** to obtain a UART device handle. This function returns the pointer to the UART device handle with a specified port number.
+
+DevHandle UartOpen\(uint32\_t port\);
+
+**Table 2** Description of UartOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
port
+
+
UART port number.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain the UART device handle.
+
+
+
Device handle
+
+
UART device handle.
+
+
+
+
+
+The following example shows how to obtain a UART device handle based on the assumption that the UART port number is **3**:
+
+```
+DevHandle handle = NULL; /* The UART device handle */
+uint32_t port = 3; /* UART port number */
+handle = UartOpen(port);
+if (handle == NULL) {
+ HDF_LOGE("UartOpen: failed!\n");
+ return;
+}
+```
+
+### Setting the UART Baud Rate
+
+After obtaining the UART device handle, set the UART baud rate by calling the following function:
+
+int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
+
+**Table 3** Description of UartSetBaud
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
baudRate
+
+
Baud rate of the UART to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART baud rate.
+
+
+
Negative value
+
+
Failed to set the UART baud rate.
+
+
+
+
+
+The following example shows how to set the UART baud rate to **9600**:
+
+```
+int32_t ret;
+/* Set the UART baud rate to 9600. */
+ret = UartSetBaud(handle, 9600);
+if (ret != 0) {
+ HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
+}
+```
+
+### Obtaining the UART Baud Rate
+
+After setting the UART baud rate, obtain the current baud rate by calling the following function:
+
+int32\_t UartGetBaud\(DevHandle handle, uint32\_t \*baudRate\);
+
+**Table 4** Description of UartGetBaud
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
baudRate
+
+
Pointer to the UART baud rate.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining the UART baud rate.
+
+
+
Negative value
+
+
Failed to obtain the UART baud rate.
+
+
+
+
+
+The following example shows how to obtain the UART baud rate:
+
+```
+int32_t ret;
+uint32_t baudRate;
+/* Obtain the UART baud rate. */
+ret = UartGetBaud(handle, &baudRate);
+if (ret != 0) {
+ HDF_LOGE("UartGetBaud: failed, ret %d\n", ret);
+}
+```
+
+### Setting the UART Device Attributes
+
+Before performing UART communication, set the UART device attributes by calling the following function:
+
+int32\_t UartSetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
+
+**Table 5** Description of UartSetAttribute
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
attribute
+
+
Pointer to the UART device attributes to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART device attributes.
+
+
+
Negative value
+
+
Failed to set the UART device attributes.
+
+
+
+
+
+The following example shows how to set the UART device attributes:
+
+```
+int32_t ret;
+struct UartAttribute attribute;
+attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
+attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
+attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
+attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
+attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
+attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
+attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
+/* Set the UART device attributes. */
+ret = UartSetAttribute(handle, &attribute);
+if (ret != 0) {
+ HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
+}
+```
+
+### Obtaining UART Device Attributes
+
+After setting the UART device attributes, obtain the current device attributes by calling the following function:
+
+int32\_t UartGetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
+
+**Table 6** Description of UartGetAttribute
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
attribute
+
+
Pointer to the UART device attributes.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining the UART device attributes.
+
+
+
Negative value
+
+
Failed to obtain the UART device attributes.
+
+
+
+
+
+The following example shows how to obtain the UART device attributes:
+
+```
+int32_t ret;
+struct UartAttribute attribute;
+/* Obtain the UART attributes. */
+ret = UartGetAttribute(handle, &attribute);
+if (ret != 0) {
+ HDF_LOGE("UartGetAttribute: failed, ret %d\n", ret);
+}
+```
+
+### Setting the UART Transmission Mode
+
+Before performing UART communication, set the UART transmission mode by calling the following function:
+
+int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
+
+**Table 7** Description of UartSetTransMode
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
mode
+
+
UART transmission mode to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART transmission mode.
+
+
+
Negative value
+
+
Failed to set the UART transmission mode.
+
+
+
+
+
+The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
+
+```
+int32_t ret;
+/* Set the UART transmission mode. */
+ret = UartSetTransMode(handle, UART_MODE_RD_BLOCK);
+if (ret != 0) {
+ HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
+}
+```
+
+### Writing Data of a Specified Length into a UART Device
+
+To write data into a UART device, call the following function:
+
+int32\_t UartWrite\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
+
+**Table 8** Description of UartWrite
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing data into the UART device.
+
+
+
Negative value
+
+
Failed to write data into the UART device.
+
+
+
+
+
+The following example shows how to write data of a specified length into the UART device:
+
+```
+int32_t ret;
+uint8_t wbuff[5] = {1, 2, 3, 4, 5};
+/* Write 5-byte data into the UART device. */
+ret = UartWrite(handle, wbuff, 5);
+if (ret != 0) {
+ HDF_LOGE("UartWrite: failed, ret %d\n", ret);
+}
+```
+
+### Reading Data of a Specified Length from a UART Device
+
+To write data into a UART device, call the following function:
+
+int32\_t UartRead\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
+
+**Table 9** Description of UartRead
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
data
+
+
Pointer to the buffer for receiving the data.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
Non-negative value
+
+
Length of the data read from the UART device.
+
+
+
Negative value
+
+
Failed to read data from the UART device.
+
+
+
+
+
+The following example shows how to read data of a specified length from the UART device:
+
+```
+int32_t ret;
+uint8_t rbuff[5] = {0};
+/* Read 5-byte data from the UART device. */
+ret = UartRead(handle, rbuff, 5);
+if (ret < 0) {
+ HDF_LOGE("UartRead: failed, ret %d\n", ret);
+}
+```
+
+> **CAUTION:**
+>Data is successfully read from the UART device if a non-negative value is returned. If the return value is **0**, no valid data can be read from the UART device. If the return value is greater than **0**, the return value is the length of the data actually read from the UART device. The length is less than or equal to the value of **size** and does not exceed the maximum length of data to read at a time specified by the UART controller in use.
+
+### Destroying the UART Device Handle
+
+After the UART communication, destroy the UART device handle by calling the following function:
+
+void UartClose\(DevHandle handle\);
+
+This function will release the resources previously obtained.
+
+**Table 10** Description of UartClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
+
+
+The following example shows how to destroy the UART device handle:
+
+```
+UartClose(handle); /* Destroy the UART device handle. */
+```
+
+## Usage Example
+
+The following is a usage example of a UART device, including how to obtain the UART device handle, set the baud rate, device attributes, and transmission mode, read data from or write data into the UART device, and then destroy the UART device handle.
+
+```
+#include "hdf_log.h"
+#include "uart_if.h"
+
+void UartTestSample(void)
+{
+ int32_t ret;
+ uint32_t port;
+ DevHandle handle = NULL;
+ uint8_t wbuff[5] = { 1, 2, 3, 4, 5 };
+ uint8_t rbuff[5] = { 0 };
+ struct UartAttribute attribute;
+ attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
+ attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
+ attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
+ attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
+ attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
+ attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
+ attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
+ /* Set the UART port number actually used. */
+ port = 1;
+ /* Obtain the UART device handle. */
+ handle = UartOpen(port);
+ if (handle == NULL) {
+ HDF_LOGE("UartOpen: failed!\n");
+ return;
+ }
+ /* Set the UART baud rate to 9600. */
+ ret = UartSetBaud(handle, 9600);
+ if (ret != 0) {
+ HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Set the UART device attributes. */
+ ret = UartSetAttribute(handle, &attribute);
+ if (ret != 0) {
+ HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Set the UART transmission mode to non-blocking mode. */
+ ret = UartSetTransMode(handle, UART_MODE_RD_NONBLOCK);
+ if (ret != 0) {
+ HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Write 5-byte data into the UART device. */
+ ret = UartWrite(handle, wbuff, 5);
+ if (ret != 0) {
+ HDF_LOGE("UartWrite: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Read 5-byte data from the UART device. */
+ ret = UartRead(handle, rbuff, 5);
+ if (ret < 0) {
+ HDF_LOGE("UartRead: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+_ERR:
+ /* Destroy the UART device handle. */
+ UartClose(handle);
+}
+```
diff --git a/en/device-dev/driver/uartoverview.md b/en/device-dev/driver/uartoverview.md
deleted file mode 100644
index 2238f2ca5564f4f1faa35bf16590c51a6492ad07..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartoverview.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# UART Overview
-
-- [Introduction](#section14770623164917)
-- [Available APIs](#section149505462492)
-
-## Introduction
-
-- 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)\).
- - 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
-
-
- 
-
-
-- 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
-
-**Table 1** APIs for the UART driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
Obtaining and releasing device handles
-
-
-
UartOpen
-
-
Obtains the UART device handle.
-
-
-
UartClose
-
-
Releases a specified UART device handle.
-
-
-
Reading and writing data
-
-
-
UartRead
-
-
Reads data of a specified length from a UART device.
-
-
-
UartWrite
-
-
Writes data of a specified length into a UART device.
-
-
-
Obtaining and setting the baud rate
-
-
UartGetBaud
-
-
Obtains the UART baud rate.
-
-
-
UartSetBaud
-
-
Sets the UART baud rate.
-
-
-
Obtaining and setting device attributes
-
-
-
UartGetAttribute
-
-
Obtains the UART device attributes.
-
-
-
UartSetAttribute
-
-
Sets the UART device attributes.
-
-
-
Setting the transmission mode
-
-
UartSetTransMode
-
-
Sets the UART transmission mode.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/uartusage-example.md b/en/device-dev/driver/uartusage-example.md
deleted file mode 100644
index 32572d405213dc537c54c2dafdd7c1902e64a048..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartusage-example.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# UART Usage Example
-
-The following is a usage example of a UART device, including how to obtain the UART device handle, set the baud rate, device attributes, and transmission mode, read data from or write data into the UART device, and then destroy the UART device handle.
-
-```
-#include "hdf_log.h"
-#include "uart_if.h"
-
-void UartTestSample(void)
-{
- int32_t ret;
- uint32_t port;
- DevHandle handle = NULL;
- uint8_t wbuff[5] = { 1, 2, 3, 4, 5 };
- uint8_t rbuff[5] = { 0 };
- struct UartAttribute attribute;
- attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
- attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
- attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
- attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
- attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
- attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
- attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
- /* Set the UART port number actually used. */
- port = 1;
- /* Obtain the UART device handle. */
- handle = UartOpen(port);
- if (handle == NULL) {
- HDF_LOGE("UartOpen: failed!\n");
- return;
- }
- /* Set the UART baud rate to 9600. */
- ret = UartSetBaud(handle, 9600);
- if (ret != 0) {
- HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Set the UART device attributes. */
- ret = UartSetAttribute(handle, &attribute);
- if (ret != 0) {
- HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Set the UART transmission mode to non-blocking mode. */
- ret = UartSetTransMode(handle, UART_MODE_RD_NONBLOCK);
- if (ret != 0) {
- HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Write 5-byte data into the UART device. */
- ret = UartWrite(handle, wbuff, 5);
- if (ret != 0) {
- HDF_LOGE("UartWrite: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Read 5-byte data from the UART device. */
- ret = UartRead(handle, rbuff, 5);
- if (ret < 0) {
- HDF_LOGE("UartRead: failed, ret %d\n", ret);
- goto _ERR;
- }
-_ERR:
- /* Destroy the UART device handle. */
- UartClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/uartusage-guidelines.md b/en/device-dev/driver/uartusage-guidelines.md
deleted file mode 100644
index edd894e92db887d324ef8b51934c720791bb8b5e..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartusage-guidelines.md
+++ /dev/null
@@ -1,506 +0,0 @@
-# UART Usage Guidelines
-
-- [How to Use](#section47784125013)
-- [Obtaining a UART Device Handle](#section146445153110)
-- [Setting the UART Baud Rate](#section1862705516339)
-- [Obtaining the UART Baud Rate](#section1263651563414)
-- [Setting the UART Device Attributes](#section1770091483814)
-- [Obtaining UART Device Attributes](#section117543316384)
-- [Setting the UART Transmission Mode](#section187233112369)
-- [Writing Data of a Specified Length into a UART Device](#section82416423368)
-- [Reading Data of a Specified Length from a UART Device](#section192177171373)
-- [Destroying the UART Device Handle](#section63131236354)
-
-## How to Use
-
-[Figure 1](#fig1852173020185) shows the process of using a UART device.
-
-**Figure 1** Process of using a UART device
-
-
-
-
-## Obtaining a UART Device Handle
-
-Before performing UART communication, call **UartOpen** to obtain a UART device handle. This function returns the pointer to the UART device handle with a specified port number.
-
-DevHandle UartOpen\(uint32\_t port\);
-
-**Table 1** Description of **UartOpen**
-
-
-
Parameter
-
-
Description
-
-
-
-
port
-
-
UART port number.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the UART device handle.
-
-
-
Device handle
-
-
Pointer to the UART device handle.
-
-
-
-
-
-The following example shows how to obtain a UART device handle based on the assumption that the UART port number is **3**:
-
-```
-DevHandle handle = NULL; /* The UART device handle */
-uint32_t port = 3; /* UART port number */
-handle = UartOpen(port);
-if (handle == NULL) {
- HDF_LOGE("UartOpen: failed!\n");
- return;
-}
-```
-
-## Setting the UART Baud Rate
-
-After obtaining the UART device handle, set the UART baud rate by calling the following function:
-
-int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
-
-**Table 2** Description of **UartSetBaud**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
baudRate
-
-
Baud rate of the UART to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART baud rate.
-
-
-
Negative value
-
-
Failed to set the UART baud rate.
-
-
-
-
-
-The following example shows how to set the UART baud rate to **9600**:
-
-```
-int32_t ret;
-/* Set the UART baud rate to 9600. */
-ret = UartSetBaud(handle, 9600);
-if (ret != 0) {
- HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
-}
-```
-
-## Obtaining the UART Baud Rate
-
-After setting the UART baud rate, obtain the current baud rate by calling the following function:
-
-int32\_t UartGetBaud\(DevHandle handle, uint32\_t \*baudRate\);
-
-**Table 3** Description of **UartGetBaud**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
baudRate
-
-
Pointer to the UART baud rate.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining the UART baud rate.
-
-
-
Negative value
-
-
Failed to obtain the UART baud rate.
-
-
-
-
-
-The following example shows how to obtain the UART baud rate:
-
-```
-int32_t ret;
-uint32_t baudRate;
-/* Obtain the UART baud rate. */
-ret = UartGetBaud(handle, &baudRate);
-if (ret != 0) {
- HDF_LOGE("UartGetBaud: failed, ret %d\n", ret);
-}
-```
-
-## Setting the UART Device Attributes
-
-Before performing UART communication, set the UART device attributes by calling the following function:
-
-int32\_t UartSetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-
-**Table 4** Description of **UartSetAttribute**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
attribute
-
-
Pointer to the UART device attributes to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART device attributes.
-
-
-
Negative value
-
-
Failed to set the UART device attributes.
-
-
-
-
-
-The following example shows how to set the UART device attributes:
-
-```
-int32_t ret;
-struct UartAttribute attribute;
-attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
-attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
-attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
-attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
-attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
-attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
-attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
-/* Set the UART device attributes. */
-ret = UartSetAttribute(handle, &attribute);
-if (ret != 0) {
- HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
-}
-```
-
-## Obtaining UART Device Attributes
-
-After setting the UART device attributes, obtain the current device attributes by calling the following function:
-
-int32\_t UartGetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-
-**Table 5** Description of **UartGetAttribute**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
attribute
-
-
Pointer to the UART device attributes.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining the UART device attributes.
-
-
-
Negative value
-
-
Failed to obtain the UART device attributes.
-
-
-
-
-
-The following example shows how to obtain the UART device attributes:
-
-```
-int32_t ret;
-struct UartAttribute attribute;
-/* Obtain the UART attributes. */
-ret = UartGetAttribute(handle, &attribute);
-if (ret != 0) {
- HDF_LOGE("UartGetAttribute: failed, ret %d\n", ret);
-}
-```
-
-## Setting the UART Transmission Mode
-
-Before performing UART communication, set the UART transmission mode by calling the following function:
-
-int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
-
-**Table 6** Description of **UartSetTransMode**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
mode
-
-
UART transmission mode to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART transmission mode.
-
-
-
Negative value
-
-
Failed to set the UART transmission mode.
-
-
-
-
-
-The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
-
-```
-int32_t ret;
-/* Set the UART transmission mode. */
-ret = UartSetTransMode(handle, UART_MODE_RD_BLOCK);
-if (ret != 0) {
- HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
-}
-```
-
-## Writing Data of a Specified Length into a UART Device
-
-To write data into a UART device, call the following function:
-
-int32\_t UartWrite\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
-
-**Table 7** Description of **UartWrite**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing data into the UART device.
-
-
-
Negative value
-
-
Failed to write data into the UART device.
-
-
-
-
-
-The following example shows how to write data of a specified length into the UART device:
-
-```
-int32_t ret;
-uint8_t wbuff[5] = {1, 2, 3, 4, 5};
-/* Write 5-byte data into the UART device. */
-ret = UartWrite(handle, wbuff, 5);
-if (ret != 0) {
- HDF_LOGE("UartWrite: failed, ret %d\n", ret);
-}
-```
-
-## Reading Data of a Specified Length from a UART Device
-
-To read data from a UART device, call the following function:
-
-int32\_t UartRead\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
-
-**Table 8** Description of **UartRead**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
data
-
-
Pointer to the buffer for receiving the data.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
Non-negative value
-
-
Length of the data read from the UART device.
-
-
-
Negative value
-
-
Failed to read data from the UART device.
-
-
-
-
-
-The following example shows how to read data of a specified length from the UART device:
-
-```
-int32_t ret;
-uint8_t rbuff[5] = {0};
-/* Read 5-byte data from the UART device. */
-ret = UartRead(handle, rbuff, 5);
-if (ret < 0) {
- HDF_LOGE("UartRead: failed, ret %d\n", ret);
-}
-```
-
-> **CAUTION:**
->Data is successfully read from the UART device if a non-negative value is returned. If the return value is **0**, no valid data can be read from the UART device. If the return value is greater than **0**, the return value is the length of the data actually read from the UART device. The length is less than or equal to the value of **size** and does not exceed the maximum length of data to read at a time specified by the UART controller in use.
-
-## Destroying the UART Device Handle
-
-After the UART communication, destroy the UART device handle by calling the following function:
-
-void UartClose\(DevHandle handle\);
-
-This function will release the resources previously obtained.
-
-**Table 9** Description of **UartClose**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle
-
-
-
-
-
-The following example shows how to destroy the UART device handle:
-
-```
-UartClose(handle); /* Destroy the UART device handle. */
-```
-
diff --git a/en/device-dev/driver/usage-example.md b/en/device-dev/driver/usage-example.md
deleted file mode 100644
index e16e8f2eeadcc12bd537fa8655692af0e88c9893..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/usage-example.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Usage Example
-
-The following is an example of using a MIPI DSI device:
-
-```
-#include "hdf.h"
-#include "mipi_dsi_if.h"
-
-void PalMipiDsiTestSample(void)
-{
- uint8_t chnId;
- int32_t ret;
- DevHandle handle = NULL;
-
- /* Device channel ID */
- chnId = 0;
- /* Obtain the MIPI DSI device handle based on a specified channel ID. */
- handle = MipiDsiOpen(chnId);
- if (handle == NULL) {
- HDF_LOGE("MipiDsiOpen: failed!\n");
- return;
- }
- /* MIPI DSI configuration parameters */
- struct MipiCfg cfg = {0};
- cfg.lane = DSI_4_LANES;
- cfg.mode = DSI_CMD_MODE;
- cfg.burstMode = VIDEO_NON_BURST_MODE_SYNC_EVENTS;
- cfg.format = FORMAT_RGB_24_BIT;
- cfg.pixelClk = 174;
- cfg.phyDataRate = 384;
- cfg.timingInfo.hsaPixels = 50;
- cfg.timingInfo.hbpPixels = 55;
- cfg.timingInfo.hlinePixels = 1200;
- cfg.timingInfo.yResLines = 1800;
- cfg.timingInfo.vbpLines = 33;
- cfg.timingInfo.vsaLines = 76;
- cfg.timingInfo.vfpLines = 120;
- cfg.timingInfo.xResPixels = 1342;
- /* Set MIPI DSI configuration parameters. */
- ret = MipiDsiSetCfg(g_handle, &cfg);
- if (ret != 0) {
- HDF_LOGE("%s: SetMipiCfg fail! ret=%d\n", __func__, ret);
- return;
- }
- /* Send the command for initializing the PANEL register. */
- struct DsiCmdDesc *cmd = OsalMemCalloc(sizeof(struct DsiCmdDesc));
- if (cmd == NULL) {
- return;
- }
- cmd->dtype = DTYPE_DCS_WRITE;
- cmd->dlen = 1;
- cmd->payload = OsalMemCalloc(sizeof(uint8_t));
- if (cmd->payload == NULL) {
- HdfFree(cmd);
- return;
- }
- *(cmd->payload) = DTYPE_GEN_LWRITE;
- MipiDsiSetLpMode(mipiHandle);
- ret = MipiDsiTx(mipiHandle, cmd);
- MipiDsiSetHsMode(mipiHandle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: MipiDsiTx fail! ret=%d\n", __func__, ret);
- HdfFree(cmd->payload);
- HdfFree(cmd);
- return;
- }
- HdfFree(cmd->payload);
- HdfFree(cmd);
- /* Pointer to the register that reads the PANEL status */
- uint8_t readVal = 0;
- struct DsiCmdDesc *cmdRead = OsalMemCalloc(sizeof(struct DsiCmdDesc));
- if (cmdRead == NULL) {
- return;
- }
- cmdRead->dtype = DTYPE_DCS_READ;
- cmdRead->dlen = 1;
- cmdRead->payload = OsalMemCalloc(sizeof(uint8_t));
- if (cmdRead->payload == NULL) {
- HdfFree(cmdRead);
- return;
- }
- *(cmdRead->payload) = DDIC_REG_STATUS;
- MipiDsiSetLpMode(g_handle);
- ret = MipiDsiRx(g_handle, cmdRead, sizeof(readVal), &readVal);
- MipiDsiSetHsMode(g_handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: MipiDsiRx fail! ret=%d\n", __func__, ret);
- HdfFree(cmdRead->payload);
- HdfFree(cmdRead);
- return;
- }
- HdfFree(cmdRead->payload);
- HdfFree(cmdRead);
- /* Release the MIPI DSI device handle. */
- MipiDsiClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/usage-guidelines.md b/en/device-dev/driver/usage-guidelines.md
deleted file mode 100644
index 1934eaf6e0bb68cb83d76d0114635f10f5ec59b7..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/usage-guidelines.md
+++ /dev/null
@@ -1,365 +0,0 @@
-# Usage Guidelines
-
-- [How to Use](#section8982671284)
-- [Obtaining a MIPI DSI Device Handle](#section57982569176)
-- [Setting MIPI DSI Configuration Parameters](#section5935410201815)
-- [Sending/Receiving the Pointer to a Command](#section611661316194)
-- [Releasing the MIPI DSI Device Handle](#section217313211199)
-
-## How to Use
-
-[Figure 1](#fig99821771782) shows the process of using a MIPI DSI device.
-
-**Figure 1** Process of using a MIPI DSI device
-
-
-
-
-## Obtaining a MIPI DSI Device Handle
-
-Before performing MIPI DSI communication, obtain a MIPI DSI device handle by calling **MipiDsiOpen**. This function returns a MIPI DSI device handle with a specified channel ID.
-
-DevHandle MipiDsiOpen\(uint8\_t id\);
-
-**Table 1** Description of **MipiDsiOpen**
-
-
-
Parameter
-
-
Description
-
-
-
id
-
-
MIPI DSI channel ID.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the MIPI DSI channel ID.
-
-
-
Device handle
-
-
MIPI DSI device handle with a specified channel ID, whose data type is DevHandle.
-
-
-
-
-
-The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
-
-```
-DevHandle mipiDsiHandle = NULL; /* Device handle */
-chnId = 0; /* MIPI DSI channel ID */
-
-/* Obtain the MIPI DSI device handle based on a specified channel ID. */
-mipiDsiHandle = MipiDsiOpen(chnId);
-if (mipiDsiHandle == NULL) {
- HDF_LOGE("MipiDsiOpen: failed\n");
- return;
-}
-```
-
-## Setting MIPI DSI Configuration Parameters
-
-- Set MIPI DSI configuration parameters by calling the following function:
-
-int32\_t MipiDsiSetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
-
-**Table 2** Description of **MipiDsiSetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
MIPI DSI device handle
-
-
-
cfg
-
-
Pointer to MIPI DSI configuration parameters
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting MIPI DSI configuration parameters.
-
-```
-MipiDsiClose(mipiHandle); /* Release the MIPI DSI device handle */
-```
-
diff --git a/en/device-dev/driver/watchdog.md b/en/device-dev/driver/watchdog.md
index b8f20d1dad97959da8207df5b166e177854a35a9..6a8bcd9802657d57d6bf00786111cacd5e0141b6 100644
--- a/en/device-dev/driver/watchdog.md
+++ b/en/device-dev/driver/watchdog.md
@@ -1,9 +1,557 @@
-# WATCHDOG
+# Watchdog
-- **[Watchdog Overview](watchdogoverview.md)**
+- [Overview](#section14918241977)
+ - [Available APIs](#section20177131219818)
-- **[Watchdog Usage Guidelines](watchdogusage-guidelines.md)**
+- [Usage Guidelines](#section10103184312813)
+ - [How to Use](#section10181195910815)
+ - [Opening a Watchdog](#section66089201107)
+ - [Obtaining the Watchdog Status](#section786624341011)
+ - [Setting the Timeout Duration](#section182386137111)
+ - [Obtaining the Timeout Duration](#section1883310371114)
+ - [Starting a Watchdog](#section82501405123)
+ - [Feeding a Watchdog](#section3547530101211)
+ - [Stopping a Watchdog](#section944595841217)
+ - [Closing a Watchdog](#section96561824121311)
-- **[Watchdog Usage Example](watchdogusage-example.md)**
+- [Usage Example](#section1724514523135)
+## Overview
+
+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
+
+**Table 1** Watchdog APIs
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
Open/Close
+
+
WatchdogOpen
+
+
Opens a watchdog.
+
+
+
WatchdogClose
+
+
Closes a watchdog.
+
+
+
Start/Stop
+
+
WatchdogStart
+
+
Starts a watchdog.
+
+
+
WatchdogStop
+
+
Stops a watchdog.
+
+
+
Timeout duration
+
+
WatchdogSetTimeout
+
+
Sets the watchdog timeout duration.
+
+
+
WatchdogGetTimeout
+
+
Obtains the watchdog timeout duration.
+
+
+
Status
+
+
WatchdogGetStatus
+
+
Obtains the watchdog status.
+
+
+
Feeding
+
+
WatchdogFeed
+
+
Feeds a watchdog, or resets a watchdog timer.
+
+
+
+
+
+> **NOTE:**
+>All watchdog functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 1](#fig19134125410189) 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.
+
+int32\_t WatchdogOpen\(int16\_t wdtId\);
+
+**Table 2** Description of WatchdogOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
wdtId
+
+
Watchdog ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to open the watchdog.
+
+
+
DevHandle pointer
+
+
Pointer to the watchdog handle.
+
+
+
+
+
+```
+DevHandle handle = NULL;
+handle = WatchdogOpen(0); /* Open watchdog 0.*/
+if (handle == NULL) {
+ HDF_LOGE("WatchdogOpen: failed, ret %d\n", ret);
+ return;
+}
+```
+
+### Obtaining the Watchdog Status
+
+int32\_t WatchdogGetStatus\(DevHandle handle, int32\_t \*status\);
+
+**Table 3** Description of WatchdogGetStatus
+
+
+
+
+```
+int32_t ret;
+/* Stop the watchdog. */
+ret = WatchdogStop(handle);
+if (ret != 0) {
+ HDF_LOGE("WatchdogStop: failed, ret %d\n", ret);
+ return;
+}
+```
+
+### Closing a Watchdog
+
+If the watchdog is no longer required, call **WatchdogClose** to close the watchdog handle.
+
+void WatchdogClose\(DevHandle handle\);
+
+**Table 9** Description of WatchdogClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Watchdog handle.
+
+
+
+
+
+```
+/* Close the watchdog. */
+ret = WatchdogClose(handle);
+```
+
+## Usage Example
+
+This example provides a complete process for using a watchdog.
+
+In this example, open a watchdog, set the timeout duration, and start the watchdog.
+
+- Feed the watchdog periodically to ensure that the system is not reset due to timer expiry.
+- Stop feeding the watchdog and check whether the system is reset after the timer expires.
+
+Example:
+
+```
+#include "watchdog_if.h"
+#include "hdf_log.h"
+#include "osal_irq.h"
+#include "osal_time.h"
+
+#define WATCHDOG_TEST_TIMEOUT 2
+#define WATCHDOG_TEST_FEED_TIME 6
+
+static int32_t TestCaseWatchdog(void)
+{
+ int32_t i;
+ int32_t ret;
+ uint32_t timeout;
+ DevHandle handle = NULL;
+
+ /* Open watchdog 0. */
+ handle = WatchdogOpen(0);
+ if (handle == NULL) {
+ HDF_LOGE("Open watchdog fail!");
+ return -1;
+ }
+
+ /* Set the timeout duration. */
+ ret = WatchdogSetTimeout(handle, WATCHDOG_TEST_TIMEOUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set timeout fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+
+ /* Obtain the configured timeout duration. */
+ ret = WatchdogGetTimeout(handle, &timeout);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: get timeout fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+ HDF_LOGI("%s: read timeout back:%u\n", __func__, timeout);
+
+ /* Start the watchdog. The timer starts. */
+ ret = WatchdogStart(handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: satrt fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+
+ /* Feed the watchdog every 1s. */
+ for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
+ HDF_LOGE("%s: feeding watchdog %d times... \n", __func__, i);
+ ret = WatchdogFeed(handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: feed dog fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+ OsalSleep(1);
+ }
+ /* Because the interval for feeding the watchdog is shorter than the timeout duration, the system does not reset, and logs can be printed normally. */
+ HDF_LOGE("%s: no reset ... feeding test OK!!!\n", __func__);
+
+ /* Enable the timer to expire by stopping feeding the watchdog. */
+ for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
+ HDF_LOGE("%s: watiting dog buck %d times... \n", __func__, i);
+ OsalSleep(1);
+ }
+
+ /* The system resets when the timer expires. If the code is correct, the log below is not displayed. */
+ HDF_LOGE("%s: dog has't buck!!! \n", __func__, i);
+ WatchdogClose(handle);
+ return -1;
+}
+```
diff --git a/en/device-dev/driver/watchdogoverview.md b/en/device-dev/driver/watchdogoverview.md
deleted file mode 100644
index 04b3b373d03c4773f5bc45ba9ef3ca8cabc29a85..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogoverview.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Watchdog Overview
-
-- [Introduction](#section3579126111816)
-- [Available APIs](#section17429111981812)
-
-## Introduction
-
-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
-
-**Table 1** Watchdog APIs
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
Open/Close
-
-
WatchdogOpen
-
-
Opens a watchdog.
-
-
-
WatchdogClose
-
-
Closes a watchdog.
-
-
-
Start/Stop
-
-
WatchdogStart
-
-
Starts a watchdog.
-
-
-
WatchdogStop
-
-
Stops a watchdog.
-
-
-
Timeout duration
-
-
WatchdogSetTimeout
-
-
Sets the watchdog timeout duration.
-
-
-
WatchdogGetTimeout
-
-
Obtains the watchdog timeout duration.
-
-
-
Status
-
-
WatchdogGetStatus
-
-
Obtains the watchdog status.
-
-
-
Feeding
-
-
WatchdogFeed
-
-
Feeds a watchdog, or resets a watchdog timer.
-
-
-
-
-
-> **NOTE:**
->All watchdog functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/watchdogusage-example.md b/en/device-dev/driver/watchdogusage-example.md
deleted file mode 100644
index 98f6acfa0e383b059ed257df8411ef03f3f9ee72..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogusage-example.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Watchdog Usage Example
-
-This example provides a complete process for using a watchdog.
-
-In this example, open a watchdog, set the timeout duration, and start the watchdog.
-
-- Feed the watchdog periodically to ensure that the system is not reset due to timer expiry.
-- Stop feeding the watchdog and check whether the system is reset after the timer expires.
-
-Example:
-
-```
-#include "watchdog_if.h"
-#include "hdf_log.h"
-#include "osal_irq.h"
-#include "osal_time.h"
-
-#define WATCHDOG_TEST_TIMEOUT 2
-#define WATCHDOG_TEST_FEED_TIME 6
-
-static int32_t TestCaseWatchdog(void)
-{
- int32_t i;
- int32_t ret;
- uint32_t timeout;
- DevHandle handle = NULL;
-
- /* Open watchdog 0. */
- handle = WatchdogOpen(0);
- if (handle == NULL) {
- HDF_LOGE("Open watchdog fail!");
- return -1;
- }
-
- /* Set the timeout duration. */
- ret = WatchdogSetTimeout(handle, WATCHDOG_TEST_TIMEOUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set timeout fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
-
- /* Obtain the configured timeout duration. */
- ret = WatchdogGetTimeout(handle, &timeout);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: get timeout fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
- HDF_LOGI("%s: read timeout back:%u\n", __func__, timeout);
-
- /* Start the watchdog. The timer starts. */
- ret = WatchdogStart(handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: satrt fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
-
- /* Feed the watchdog every 1s. */
- for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
- HDF_LOGE("%s: feeding watchdog %d times... \n", __func__, i);
- ret = WatchdogFeed(handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: feed dog fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
- OsalSleep(1);
- }
- /* Because the interval for feeding the watchdog is shorter than the timeout duration, the system does not reset, and logs can be printed normally. */
- HDF_LOGE("%s: no reset ... feeding test OK!!!\n", __func__);
-
- /* Enable the timer to expire by stopping feeding the watchdog. */
- for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
- HDF_LOGE("%s: watiting dog buck %d times... \n", __func__, i);
- OsalSleep(1);
- }
-
- /* The system resets when the timer expires. If the code is correct, the log below is not displayed. */
- HDF_LOGE("%s: dog has't buck!!! \n", __func__, i);
- WatchdogClose(handle);
- return -1;
-}
-```
-
diff --git a/en/device-dev/driver/watchdogusage-guidelines.md b/en/device-dev/driver/watchdogusage-guidelines.md
deleted file mode 100644
index e3eb5c091fb98497a9bc2f31dfe40cb69df93244..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogusage-guidelines.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Watchdog Usage Guidelines
-
-- [How to Use](#section0719414187)
-- [Opening a Watchdog](#section198171379261)
-- [Obtaining the Watchdog Status](#section206592910275)
-- [Setting the Timeout Duration](#section19605128182714)
-- [Obtaining the Timeout Duration](#section11111516208)
-- [Starting a Watchdog](#section141174192814)
-- [Feeding a Watchdog](#section179101435113910)
-- [Stopping a Watchdog](#section15282123192816)
-- [Closing a Watchdog](#section7857850173411)
-
-## How to Use
-
-[Figure 1](#fig19134125410189) 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 a specified watchdog by using the ID.
-
-int32\_t WatchdogOpen\(int16\_t wdtId\);
-
-.
-
-**Table 1** Description of WatchdogOpen
-
-
-
-
-```
-int32_t ret;
-/* Stop the watchdog. */
-ret = WatchdogStop(handle);
-if (ret != 0) {
- HDF_LOGE("WatchdogStop: failed, ret %d\n", ret);
- return;
-}
-
-```
-
-## Closing a Watchdog
-
-If the watchdog is no longer required, call **WatchdogClose** to close the watchdog handle.
-
-void WatchdogClose\(DevHandle handle\);
-
-**Table 8** Description of WatchdogClose
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Watchdog handle.
-
-
-
-
-
-```
-/* Close the watchdog. */
-ret = WatchdogClose(handle);
-```
-
diff --git a/en/device-dev/driver/wlan.md b/en/device-dev/driver/wlan.md
index d6d1fba4014eca409dc4a0d4ef645b1dc9cdffe3..5bc198f48d4a2166091ec2ff7fdfca40d0f26617 100644
--- a/en/device-dev/driver/wlan.md
+++ b/en/device-dev/driver/wlan.md
@@ -1,9 +1,622 @@
-# WLAN
+# WLAN
-- **[WLAN Overview](wlanoverview.md)**
+- [Overview](#section729758162218)
+ - [WLAN Driver API Architecture](#section178022416377)
+ - [Available APIs](#section149681312202415)
-- **[WLAN Development Guidelines](wlandevelopment-guidelines.md)**
+- [Development Guidelines](#section15957746172412)
+ - [How to Develop](#section11776186132513)
-- **[WLAN Development Example](wlandevelopment-example.md)**
+- [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
+
+
+
+
+### WLAN Driver API Architecture
+
+The WLAN module provides the following three types of APIs:
+
+1. Capability APIs for the HDI layer
+
+2. Capability APIs directly invoked by drivers
+
+3. Capability APIs for vendors
+
+**Figure 2** Available APIs of the WLAN module
+
+
+
+
+### 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.
+
+**Table 1** APIs that can be directly called by driver developers
+
+
+
+
+The WLAN driver module provides APIs for driver developers, such as initializing/deregistering, opening/stopping a **NetDevice**, and obtaining the state of a **NetDevice**. [Table 2](#table74613501475) describes some APIs.
+
+**Table 2** APIs for driver developers of WLAN vendors to implement
+
+
+
+
+The WLAN driver provides the HDI layer with the APIs for creating and destroying an **IWiFi** object and setting the MAC address. [Table 3](#table141076311618) describes some APIs.
+
+**Table 3** APIs provided by the WLAN HAL module
+
+
+
-
-The WLAN driver module provides APIs for driver developers, such as initializing/deregistering, opening/stopping a **NetDevice**, and obtaining the state of a **NetDevice**. [Table 2](#table74613501475) provides some APIs.
-
-**Table 2** APIs for driver developers of WLAN vendors to implement
-
-
-
-
-The WLAN driver provides the HDI layer with the APIs for creating and destroying an **IWiFi** object and setting the MAC address. [Table 3](#table141076311618) provides some APIs.
-
-**Table 3** APIs provided by the WLAN HAL module
-
-
-
+
+## Preparations
+
+Before using the Docker environment, perform the following operations:
+
+1. Install Docker. For details, see [Install Docker Engine](https://docs.docker.com/engine/install/).
+2. Obtain the OpenHarmony source code. For details, see [Source Code Acquisition](source-code-acquisition.md).
+
+ > **NOTE:**
+ >You do not need to obtain the source code for the HPM-based Docker environment.
+
+
+## Standalone Docker Environment
+
+The Docker image of OpenHarmony is hosted on [HUAWEI CLOUD SWR](https://console.huaweicloud.com/swr/?region=cn-south-1&locale=en-us#/app/warehouse/warehouseMangeDetail/goldensir/openharmony-docker/openharmony-docker?type=ownImage). Using the Docker image will help simplify environment configurations needed for the building. The following describes the detailed procedure.
+
+### Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ Run the following command in Ubuntu:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+ Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
+
+ ```
+ docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+
+**Method 2: Using the Dockerfile to Build a Local Docker Image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ Run the following command in Ubuntu:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+ Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
+
+ ```
+ docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+
+### Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
+
+The following uses the Hi3516 platform as an example to describe the build procedure.
+
+Set the build path to the current path.
+
+```
+hb set
+ .
+```
+
+**Figure 1** Setting page
+
+
+
+
+> **NOTE:**
+>The mapping between the development board and the building GUI:
+>- Hi3861: wifiiot\_hispark\_pegasus@hisilicon
+>- Hi3516: ipcamera\_hispark\_taurus@hisilicon
+>- Hi3518: ipcamera\_hispark\_aries@hisilicon
+
+1. Select **ipcamera\_hispark\_taurus@hisilicon** and press **Enter**.
+2. Start building.
+
+ ```
+ hb build -f
+ ```
+
+3. View the build result.
+
+ The files will be generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
+
+
+### Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+2. Go to the root directory of OpenHarmony 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.1
+ ```
+
+
+**Method 2: Using the Dockerfile to Build a Local Docker Image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker/standard
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
+ ```
+
+
+### Building for Standard-System Devices \(reference memory ≥ 128 MB\)
+
+1. Run the preprocessing script in the root directory of the source code.
+
+ ```
+ ../scripts/prepare.sh
+ ```
+
+2. Run the following script to start building for standard-system devices \(reference memory ≥ 128 MB\).
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the platform supported by the current distribution, for example, Hi3516D V300.
+
+ 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.
+
+
+> **NOTE:**
+>You can exit Docker by simply running the **exit** command.
+
+## HPM-based 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](https://device.harmonyos.com/en/docs/develop/bundles/oem_bundle_guide_prepare-0000001050129846) development environments, perform the following steps to access the Docker environment:
+
+### Setting Up the Docker Environment
+
+1. Initialize the installation template by running the following command in any of the working directories:
+
+ ```
+ hpm init -t @ohos/docker_dist
+ ```
+
+2. Modify the **publishAs** field.
+
+ The obtained bundle is of the template type. Open the **bundle.json** file in the current directory and change the value of **publishAs** from **template** to **distribution** as needed.
+
+
+### Obtaining and Building Source Code
+
+Start building. Docker can be automatically installed only in Ubuntu. If you are using any other operating system, manually install Docker before pulling the image.
+
+- **Automatically Installing Docker \(Ubuntu\)**
+
+ Running the following command will automatically install Docker, pull the Docker image, and start the pulling and building of the corresponding solution in the container.
+
+ **Method 1:**
+
+ Add a parameter to specify the solution. For example:
+
+ ```
+ hpm run docker solution={product}
+ ```
+
+ **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
+
+ **Method 2:**
+
+ Set an environment variable to specify the solution, and then run the build command.
+
+ 1. Select the desired solution.
+
+ ```
+ export solution={product}
+ ```
+
+ **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
+
+ 2. Obtain and build the source code.
+
+ ```
+ hpm run docker
+ ```
+
+
+ This example uses the **@ohos/hispark\_taurus** solution for illustration. If the execution is successful, the output is as follows:
+
+ ```
+ ...
+ ohos ipcamera_hispark_taurus build success!
+ @ohos/hispark_taurus: distribution building completed.
+ ```
+
+
+- **Manually Installing Docker \(Non-Ubuntu\)**
+
+ Perform the following operations to install Docker:
+
+ ```
+ # Pull the image.
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.3# Compile the Docker image in the Linux environment.
+ hpm run distWithDocker solution={product}
+ # When using Windows, make sure to configure the Git Bash.
+ hpm config set shellPath "Git Bash path"
+ hpm run distWithDocker solution={product}
+ ```
+
+
diff --git a/en/device-dev/get-code/figures/3.png b/en/device-dev/get-code/figures/3.png
index c99cddf919e6f912aa19c43189f1fdbe895764ac..7936efcb1acc374be338d44d8d2911fa82f29076 100644
Binary files a/en/device-dev/get-code/figures/3.png and b/en/device-dev/get-code/figures/3.png differ
diff --git a/en/device-dev/get-code/ide.md b/en/device-dev/get-code/ide.md
new file mode 100644
index 0000000000000000000000000000000000000000..f3551de3126341e207afe450d509d8d37cc0979a
--- /dev/null
+++ b/en/device-dev/get-code/ide.md
@@ -0,0 +1,17 @@
+# IDE
+
+- [Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)](#section2452141120244)
+- [Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)](#section0904101019258)
+
+## 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.
+
+
+
+## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
+
+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).
+
diff --git a/en/device-dev/get-code/source-code-acquisition.md b/en/device-dev/get-code/source-code-acquisition.md
index f7a7c3f5c758bcac5d10c91de12a53e406205cfd..1646c8a96402bd54dd77a359cf3364a0a90bb8cb 100644
--- a/en/device-dev/get-code/source-code-acquisition.md
+++ b/en/device-dev/get-code/source-code-acquisition.md
@@ -26,11 +26,10 @@ The open-source code repositories are available at [https://openharmony.gitee.c
## Overview of Source Code Acquisition
-This document describes how to acquire OpenHarmony source code and provides its directory structure. The OpenHarmony code is open to you as [bundles](../bundles/overview.md), which can be obtained in any of the following ways:
+This document describes how to acquire OpenHarmony source code and provides its directory structure. The OpenHarmony code is open to you as [bundles](../bundles/development-specifications.md), which can be obtained in any of the following ways:
- **Method 1**: Acquire the source code from a code repository. You can use the **repo** or **git** tool to download the latest code from the code repository.
- **Method 2**: Obtain the source code from the HarmonyOS Package Manager \(HPM\). Visit the [HPM](https://hpm.harmonyos.com/#/en/home) website, search for your desired open-source distribution, and download the bundle list \(or customize bundles and download the bundle list\). Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC.
-- **Method 3**: Download the compressed file of a distribution from an image site. This method provides a fast download speed, so you can also use this method for obtaining the source code of an earlier version.
## Method 1: Acquiring Source Code from a Code Repository
@@ -40,9 +39,9 @@ This document describes how to acquire OpenHarmony source code and provides its
- You have interconnected your software with OpenHarmony and need official certification from OpenHarmony.
-- You want to contribute code to the OpenHarmony community after chips, modules, and applications are certified by OpenHarmony.
+- You want to contribute code to the OpenHarmony community after obtaining official OpenHarmony certification for chips, modules, and applications.
-- You need to address OpenHarmony issues.
+- You need to rectify OpenHarmony issues.
- You want to learn OpenHarmony source code.
@@ -62,7 +61,7 @@ This document describes how to acquire OpenHarmony source code and provides its
4. Run the following commands to install the **repo** tool:
```
- curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
chmod a+x /usr/local/bin/repo
pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
```
@@ -70,7 +69,7 @@ This document describes how to acquire OpenHarmony source code and provides its
### How to Use
-**Obtaining the Source Code for Mini, Small, and Standard Systems \(2.0 Canary\)**
+**Obtaining the Source Code for Mini/Small/Standard Systems \(2.0 Canary\)**
> **NOTE:**
>You can obtain the latest features from the master code, and develop commercial functionalities based on the release code, which is more stable.
@@ -109,7 +108,7 @@ This document describes how to acquire OpenHarmony source code and provides its
- Obtaining the source code of other OpenHarmony releases
- For details about how to obtain the source code of other releases, see the [Release Notes](https://gitee.com/openharmony/docs/blob/master/en/release-notes/OpenHarmony-Release-Notes.md).
+ For details about how to obtain the source code of other OpenHarmony releases, see the [Release Notes](https://gitee.com/openharmony/docs/blob/master/en/release-notes/OpenHarmony-Release-Notes.md).
## Method 2: Acquiring Source Code from HPM
@@ -197,7 +196,7 @@ You must install **Node.js** and HPM on your local PC. The installation proced
To ensure the download performance, you are advised to download the source code or the corresponding solution from the image library of the respective site listed in the table below.
> **NOTE:**
->- The table below provides only the sites for downloading the source code of the latest OpenHarmony Master and LTS versions. For details about earlier versions and how to obtain their source code, see the [Release Notes](https://gitee.com/openharmony/docs/tree/master/en/release-notes).
+>- The table below provides only the sites for downloading the latest OpenHarmony master and LTS code. For details about how to obtain the source code of earlier versions, see the [Release Notes](https://gitee.com/openharmony/docs/tree/master/en/release-notes).
>- The Master 1.0 version is no longer maintained.
**Table 1** Sites for acquiring source code from image sites
@@ -225,7 +224,7 @@ To ensure the download performance, you are advised to download the source code
diff --git a/en/device-dev/get-code/tool-acquisition.md b/en/device-dev/get-code/tool-acquisition.md
index ddfc607243ddd0682ed23b79e3f95d59ae1addc6..dd1797b10426918c0921386817fb51c1b9e83a3b 100644
--- a/en/device-dev/get-code/tool-acquisition.md
+++ b/en/device-dev/get-code/tool-acquisition.md
@@ -1,283 +1,7 @@
-# Tool Acquisition
+# Tool Acquisition
-- [How to Obtain the Docker Environment](#section107932281315)
-- [HPM-based Docker](#section485713518337)
- - [Setting Up the Docker Environment](#section18957202218355)
- - [Building](#section69141039143518)
+- **[Docker Environment](docker-environment.md)**
-- [Standalone Docker Environment](#section2858536103611)
- - [Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)](#section319412277287)
- - [Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)](#section631485163615)
- - [Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)](#section13585262391)
- - [Building for Standard-System Devices \(reference memory ≥ 128 MB\)](#section193711513406)
+- **[IDE](ide.md)**
-- [Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)](#section2452141120244)
-- [Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)](#section0904101019258)
-
-## How to Obtain the Docker Environment
-
-OpenHarmony provides the following two types of Docker environments for you to quickly get the development environment ready:
-
-- HPM-based Docker environment: applicable when using the HarmonyOS Package Manager \(HPM\) to build a distribution.
-- Standalone Docker environment: applicable when using Ubuntu or Windows to build a distribution.
-
- The following table lists container-based options needed for building in the standalone Docker environment.
-
- **Table 1** Docker image
-
-
-
The OpenHarmony build environment has been pre-installed. This repository applies to Mini-System Devices (reference memory ≥ 128 KB) and Small-System Devices (reference memory ≥ 1 MB).
The OpenHarmony build environment has been pre-installed. This repository applies to Standard-System Devices (reference memory ≥ 128 MB).
-
-
-
-
-
- > **NOTE:**
- >For details about how to install Docker, see [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/).
-
-
-## HPM-based Docker
-
-**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](https://device.harmonyos.com/en/docs/develop/bundles/oem_bundle_guide_prepare-0000001050129846) development environments, perform the following steps to access the Docker environment:
-
-### Setting Up the Docker Environment
-
-1. Initialize the installation template by running the following command in any of the working directories:
-
- ```
- hpm init -t @ohos/docker_dist
- ```
-
-2. Modify the **publishAs** field.
-
- The obtained bundle is of the template type. Open the **bundle.json** file in the current directory and change the value of **publishAs** from **template** to **distribution** as needed.
-
-
-### Building
-
-Start building. Docker can be automatically installed only on Ubuntu. If you are using any other operating system, manually install Docker before pulling the image.
-
-- **Automatically Installing Docker \(Ubuntu\)**
-
- Running the following command will automatically install Docker, pull the Docker image, and start the pulling and building of the corresponding solution in the container.
-
- Method 1:
-
- Add a parameter to specify the solution. For example:
-
- ```
- hpm run docker solution={product}
- ```
-
- **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
-
- Method 2:
-
- Set an environment variable to specify the solution, and then run the build command.
-
- 1. Select the desired solution.
-
- ```
- export solution={product}
- ```
-
- **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
-
- 2. Start building.
-
- ```
- hpm run docker
- ```
-
- This example uses the **@ohos/hispark\_taurus** solution for illustration. If the execution is successful, the output is as follows:
-
- ```
- ...
- ohos ipcamera_hispark_taurus build success!
- @ohos/hispark_taurus: distribution building completed.
- ```
-
-
-- **Manually Installing Docker \(Non-Ubuntu\)**
-
- Perform the following operations to install Docker:
-
- ```
- # Pull the image.
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.3# Compile the Docker image in the Linux environment.
- hpm run distWithDocker solution={product}
- # When using Windows, make sure to configure the Git Bash.
- hpm config set shellPath "Git Bash path"
- hpm run distWithDocker solution={product}
- ```
-
-
-## Standalone Docker Environment
-
-The Docker image of OpenHarmony is hosted on [HUAWEI CLOUD SWR](https://console.huaweicloud.com/swr/?region=cn-south-1&locale=en-us#/app/warehouse/warehouseMangeDetail/goldensir/openharmony-docker/openharmony-docker?type=ownImage). Using the Docker image will help simplify environment configurations needed for the building. After configuring the development environments, perform the procedures below to access the Docker environment. Both Ubuntu and Windows are supported. The following procedures use Ubuntu as an example.
-
-### Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
-
-**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
-
-1. Obtain the Docker image.
-
- ```
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
-2. Go to the root directory of OpenHarmony 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:0.0.5
- ```
-
-
-**Method 2: Using the Dockerfile to Build a Local Docker Image**
-
-1. Obtain the Dockerfile script for a local Docker image.
-
- ```
- git clone https://gitee.com/openharmony/docs.git
- ```
-
-2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
-
- ```
- cd docs/docker
- ./build.sh
- ```
-
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony openharmony-docker:0.0.5
- ```
-
-
-### Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
-
-The following uses the Hi3516 platform as an example to describe the build procedure. Run the following build scripts to start building:
-
-Set the build path to the current path.
-
-```
-hb set
- .
-```
-
-**Figure 1** Setting page
-
-
-
-
-> **NOTE:**
->The mapping between the development board and the building GUI:
->- Hi3861: wifiiot\_hispark\_pegasus@hisilicon
->- Hi3516: ipcamera\_hispark\_taurus@hisilicon
->- Hi3518: ipcamera\_hispark\_aries@hisilicon
-
-1. Select **ipcamera\_hispark\_taurus@hisilicon** and press **Enter**.
-2. Start building.
-
- ```
- hb build -f
- ```
-
-3. View the build result.
-
- The files will be generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
-
-
-### Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)
-
-**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
-
-1. Obtain the Docker image.
-
- ```
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
- ```
-
-2. Go to the root directory of OpenHarmony 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.1
- ```
-
-
-**Method 2: Using the Dockerfile to Build a Local Docker Image**
-
-1. Obtain the Dockerfile script for a local Docker image.
-
- ```
- git clone https://gitee.com/openharmony/docs.git
- ```
-
-2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
-
- ```
- cd docs/docker/standard
- ./build.sh
- ```
-
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
- ```
-
-
-### Building for Standard-System Devices \(reference memory ≥ 128 MB\)
-
-1. Run the preprocessing script in the root directory of the source code.
-
- ```
- ../scripts/prepare.sh
- ```
-
-2. Run the following script to start building for Standard-System Devices \(reference memory ≥ 128 MB\).
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the platform supported by the current distribution, for example, Hi3516D V300.
-
- Files generated during compilation 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.
-
-
-> **NOTE:**
->You can exit Docker by simply running the **exit** command.
-
-## 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-based smart devices. It allows on-demand customization of OpenHarmony components, code editing, compilation, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see [Tool Acquisition](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.
-
-
-
-## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
-
-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, compilation, 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 [Tool Acquisition](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).
diff --git a/en/device-dev/guide/Readme-EN.md b/en/device-dev/guide/Readme-EN.md
index 31bb3cfd5f930e15379766651d890690ab24f29c..66faa01846f2a827da6df370ecb98299781e7c6f 100644
--- a/en/device-dev/guide/Readme-EN.md
+++ b/en/device-dev/guide/Readme-EN.md
@@ -1,10 +1,10 @@
-# Development Examples
+# Device Development
- [WLAN-connected Products](wlan-connected-products.md)
- - [LED Peripheral Control](led-peripheral-control.md)
- - [Overview](overview.md)
- - [Development](development.md)
- - [Verification](verification.md)
+ - [Overview](overview.md)
+ - [Development](development.md)
+ - [Verification](verification.md)
+ - [Third-Party SDK Integration](third-party-sdk-integration.md)
- [Cameras Without a Screen](cameras-without-a-screen.md)
- [Camera Control](camera-control.md)
@@ -41,15 +41,16 @@
- [How to Develop](how-to-develop.md)
- [Signing and Packaging](signing-and-packaging.md)
- [Running on the Device](running-on-the-device-9.md)
+ - [FAQs](faqs-10.md)
- [Development Example for Platform Drivers](development-example-for-platform-drivers.md)
- - [Overview](overview-10.md)
- - [Preparations](preparations-11.md)
- - [Development](development-12.md)
+ - [Overview](overview-11.md)
+ - [Preparations](preparations-12.md)
+ - [Development](development-13.md)
- [Building and Burning](building-and-burning.md)
- [Development Example for Peripheral Drivers](development-example-for-peripheral-drivers.md)
- - [Overview](overview-13.md)
+ - [Overview](overview-14.md)
- [Hardware Resources](hardware-resources.md)
- [Input Driver Model](input-driver-model.md)
@@ -59,7 +60,7 @@
- [Configuring the Touchscreen](configuring-the-touchscreen.md)
- [Adapting to the Private Drivers of the Touchscreen](adapting-to-the-private-drivers-of-the-touchscreen.md)
- - [Building and Burning](building-and-burning-14.md)
+ - [Building and Burning](building-and-burning-15.md)
- [Debugging and Verification](debugging-and-verification.md)
- [Startup Log Analysis](startup-log-analysis.md)
diff --git a/en/device-dev/guide/building-and-burning-14.md b/en/device-dev/guide/building-and-burning-15.md
similarity index 100%
rename from en/device-dev/guide/building-and-burning-14.md
rename to en/device-dev/guide/building-and-burning-15.md
diff --git a/en/device-dev/guide/debugging-and-packaging.md b/en/device-dev/guide/debugging-and-packaging.md
index 97df7e21ab4e36ac3420ba1494bf8452fa5f226e..2d4c192fb9c4948b510b6f0ad85d9e50f0a50a03 100644
--- a/en/device-dev/guide/debugging-and-packaging.md
+++ b/en/device-dev/guide/debugging-and-packaging.md
@@ -1,4 +1,4 @@
# Debugging and Packaging
-After the code is compiled, debug your application and package it into an App Pack. For details about how to debug and package an application, see [Debugging Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/debug_overview-0000001053822404) and [Building Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201) in the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). Currently, IPCamera applications do not support signature. You should release an unsigned App Pack.
+After the code is compiled, debug your application and package it into an App Pack. For details about how to debug and package an application, see [Debugging Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ide_debug_device-0000001053822404) and [Building Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201) in the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). Currently, IPCamera applications do not support signature. You should release an unsigned App Pack.
diff --git a/en/device-dev/guide/development-12.md b/en/device-dev/guide/development-13.md
similarity index 100%
rename from en/device-dev/guide/development-12.md
rename to en/device-dev/guide/development-13.md
diff --git a/en/device-dev/guide/development-example-for-peripheral-drivers.md b/en/device-dev/guide/development-example-for-peripheral-drivers.md
index 4333c26e067bd1ce6981ef3e0a558e5f03578822..4cf054e30c54e1a78a75d0710c20dd5357d73547 100644
--- a/en/device-dev/guide/development-example-for-peripheral-drivers.md
+++ b/en/device-dev/guide/development-example-for-peripheral-drivers.md
@@ -1,12 +1,12 @@
# Development Example for Peripheral Drivers
-- **[Overview](overview-13.md)**
+- **[Overview](overview-14.md)**
- **[Setting Up the Environment](setting-up-the-environment.md)**
- **[Developing a Touchscreen Driver](developing-a-touchscreen-driver.md)**
-- **[Building and Burning](building-and-burning-14.md)**
+- **[Building and Burning](building-and-burning-15.md)**
- **[Debugging and Verification](debugging-and-verification.md)**
diff --git a/en/device-dev/guide/development-example-for-platform-drivers.md b/en/device-dev/guide/development-example-for-platform-drivers.md
index fbb47fb7d32d8b300c97f77d4f5fff0f1d616501..7e35c4dbfcf093c1d26247e6240c4b89ab144b49 100644
--- a/en/device-dev/guide/development-example-for-platform-drivers.md
+++ b/en/device-dev/guide/development-example-for-platform-drivers.md
@@ -1,10 +1,10 @@
# Development Example for Platform Drivers
-- **[Overview](overview-10.md)**
+- **[Overview](overview-11.md)**
-- **[Preparations](preparations-11.md)**
+- **[Preparations](preparations-12.md)**
-- **[Development](development-12.md)**
+- **[Development](development-13.md)**
- **[Building and Burning](building-and-burning.md)**
diff --git a/en/device-dev/guide/input-driver-model.md b/en/device-dev/guide/input-driver-model.md
index a4f2cdb3720235bcf0fd941caf6ae05c68792bd8..dc90f115f3a774274b52f9199fc6af2e5f005fd9 100644
--- a/en/device-dev/guide/input-driver-model.md
+++ b/en/device-dev/guide/input-driver-model.md
@@ -8,5 +8,5 @@ The input driver model mainly consists of the device manager, common drivers, an
In addition, the input driver model implements functions for reporting input data and parsing input device configurations.
-For details about the input driver model, see [Touchscreen Overview](https://device.harmonyos.com/en/docs/develop/drive/oem_drive_touch_des-0000001052857350)[Touchscreen Overview](../driver/touchscreenoverview.md).
+For details about the input driver model, see [Touchscreen Overview](../driver/touchscreen.md).
diff --git a/en/device-dev/guide/led-peripheral-control.md b/en/device-dev/guide/led-peripheral-control.md
deleted file mode 100644
index abe05cea370b4b7743e120ce2207aa54834de1b1..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/led-peripheral-control.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# LED Peripheral Control
-
-- **[Overview](overview.md)**
-
-- **[Development](development.md)**
-
-- **[Verification](verification.md)**
-
-
diff --git a/en/device-dev/guide/overview-10.md b/en/device-dev/guide/overview-11.md
similarity index 100%
rename from en/device-dev/guide/overview-10.md
rename to en/device-dev/guide/overview-11.md
diff --git a/en/device-dev/guide/overview-13.md b/en/device-dev/guide/overview-14.md
similarity index 100%
rename from en/device-dev/guide/overview-13.md
rename to en/device-dev/guide/overview-14.md
diff --git a/en/device-dev/guide/photographing-3.md b/en/device-dev/guide/photographing-3.md
index 7d6450e761f1a0d4823c683ae95546de5a0a18fb..eda733f15340836efaf5e6d25417821836bc333d 100644
--- a/en/device-dev/guide/photographing-3.md
+++ b/en/device-dev/guide/photographing-3.md
@@ -385,6 +385,7 @@ None
Surface *surface = Surface::CreateSurface();
if (surface == nullptr) {
delete fc;
+ return;
}
surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
fc->AddSurface(*surface);
diff --git a/en/device-dev/guide/photographing.md b/en/device-dev/guide/photographing.md
index a1617550bfbd2352e3bb1fc4739d93ed25f8fb78..a8da63373f6c284ee608836d504e38e5ee7c1569 100644
--- a/en/device-dev/guide/photographing.md
+++ b/en/device-dev/guide/photographing.md
@@ -385,6 +385,7 @@ None
Surface *surface = Surface::CreateSurface();
if (surface == nullptr) {
delete fc;
+ return;
}
surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
fc->AddSurface(*surface);
diff --git a/en/device-dev/guide/preparations-11.md b/en/device-dev/guide/preparations-12.md
similarity index 100%
rename from en/device-dev/guide/preparations-11.md
rename to en/device-dev/guide/preparations-12.md
diff --git a/en/device-dev/guide/running-on-the-device-9.md b/en/device-dev/guide/running-on-the-device-9.md
index b97c20b8a10a83bdcd1c7216a5d231212abb341d..24ee3034d3955b33096ed0bd1c53970e2ff6b4c0 100644
--- a/en/device-dev/guide/running-on-the-device-9.md
+++ b/en/device-dev/guide/running-on-the-device-9.md
@@ -1,6 +1,6 @@
# Running on the Device
-Before you install the app and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905). Burn OpenHarmony into the development board, and run it on the board. For details about how to build, burn, and run an image, see [Getting Started with Hi3516](../quick-start/how-to-develop-12.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the app:
+Before you install the app and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/tool_install-0000001050164976). Burn OpenHarmony into the development board, and run it on the board. For details about how to build, burn, and run an image, see [Getting Started with Hi3516](../quick-start/standard-system.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the app:
1. Obtain the HDC client from the following path:
diff --git a/en/device-dev/guide/running-on-the-device.md b/en/device-dev/guide/running-on-the-device.md
index 79167a2934ce10c5e799b2c59d09830ac68e7ac4..91094bd0cdac0db24108e37a958efd8e5e7b5643 100644
--- a/en/device-dev/guide/running-on-the-device.md
+++ b/en/device-dev/guide/running-on-the-device.md
@@ -1,8 +1,8 @@
# Running on the Device
-Before you install the application and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/tool_install-0000001050164976). Burn OpenHarmony into the development board, and run it on the board. For details about how to compile, burn, and run an image, see the [Getting Started with Hi3516](../quick-start/hi3516-development-board.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the application:
+Before you install the application and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905). Burn OpenHarmony into the development board, and run it on the board. For details about how to compile, burn, and run an image, see the [Hi3516 Development Board](../quick-start/hi3516-development-board.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the application:
-1. Store the compiled unsigned application installation package and installation tool in an SD card and insert the SD card into the development board slot. The installation tool is in **idev\_tools** of the directory where the image file is generated.
+1. Store the compiled unsigned application installation package and installation tool in an SD card and insert the SD card into the development board slot. The installation tool is in **dev\_tools** of the directory where the image file is generated.
2. Run the following command to disable signature verification, which is enabled by default for application installation:
```
diff --git a/en/device-dev/guide/use-case-5.md b/en/device-dev/guide/use-case-5.md
index f4e481e1cef8c4815def24a9aa9c604df9b01680..588b3b8addbefced4208d220eeac28dfe9f6af6a 100644
--- a/en/device-dev/guide/use-case-5.md
+++ b/en/device-dev/guide/use-case-5.md
@@ -3,7 +3,7 @@
This use case takes **camera\_sample** \(contained in the source code\) as an example for photographing, recording, and previewing on the development board.
- You can obtain source code of the sample from **applications/sample/camera/media/camera\_sample.cpp**.
-- Before running the sample camera, you need to compile, burn, and run the image. For details, see [Getting Started with Hi3516](../quick-start/hi3516-development-board.md).
+- Before running the sample camera, you need to compile, burn, and run the image. For details, see [Hi3516 Development Board](../quick-start/hi3516-development-board.md).
> **NOTE:**
>After the development board is started, the home screen is loaded and displayed above the media layer by default. To prevent covering **camera\_sample**, you should remove the home screen during compilation or packaging.
diff --git a/en/device-dev/guide/use-case.md b/en/device-dev/guide/use-case.md
index 274e2d375df15cf35285544f1c48c37f6b8e3c94..0847510fb3ad77af238ced704cc3ec071cadd0f7 100644
--- a/en/device-dev/guide/use-case.md
+++ b/en/device-dev/guide/use-case.md
@@ -1,6 +1,6 @@
# Use Case
-- For details about the development board, compilation, burning, and image running, see [Getting Started with Hi3518](../quick-start/hi3518-development-board.md). A compilation result file of sample code is stored in **out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample**. You can copy the file to a TF card, or modify the compilation script of **camera\_sample** to copy the result to **rootfs.img**.
+- For details about the development board, compilation, burning, and image running, see [Hi3518 Development Board](../quick-start/hi3518-development-board.md). A compilation result file of sample code is stored in **out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample**. You can copy the file to a TF card, or modify the compilation script of **camera\_sample** to copy the result to **rootfs.img**.
Modify **output\_dir** in **applications/sample/camera/media/BUILD.gn**.
diff --git a/en/device-dev/guide/wlan-connected-products.md b/en/device-dev/guide/wlan-connected-products.md
index 184f46eb0e144c6d086c2b35264557825fe5bb8e..b06843d5c1aabd428f24e5e9299f41388b776531 100644
--- a/en/device-dev/guide/wlan-connected-products.md
+++ b/en/device-dev/guide/wlan-connected-products.md
@@ -1,5 +1,11 @@
# WLAN-connected Products
-- **[LED Peripheral Control](led-peripheral-control.md)**
+- **[Overview](overview.md)**
+
+- **[Development](development.md)**
+
+- **[Verification](verification.md)**
+
+- **[Third-Party SDK Integration](third-party-sdk-integration.md)**
diff --git a/en/device-dev/kernel/Readme-EN.md b/en/device-dev/kernel/Readme-EN.md
index 2ec9f17abde6255b6bfb7b20df50fac5357972ea..632db9a594c4addf991b9b8e2c20ee1e46ff8020 100644
--- a/en/device-dev/kernel/Readme-EN.md
+++ b/en/device-dev/kernel/Readme-EN.md
@@ -1,7 +1,7 @@
# Kernel
-- [Lite Kernel](lite-kernel.md)
- - [OpenHarmony Lite Kernel Basic Functions](openharmony-lite-kernel-basic-functions.md)
+- [Kernel for Mini and Small Systems](kernel-for-mini-and-small-systems.md)
+ - [Basic Kernel](basic-kernel.md)
- [Process](process.md)
- [Thread](thread.md)
- [Memory](memory.md)
@@ -86,7 +86,7 @@
- [Magic Key Usage](magic-key-usage.md)
- [User-Space Exception Information](user-space-exception-information.md)
-- [Linux Kernel](linux-kernel.md)
+- [Kernel for Standard Systems](kernel-for-standard-systems.md)
- [Linux Kernel Overview](linux-kernel-overview.md)
- [Guidelines for Using Patches on OpenHarmony Development Boards](guidelines-for-using-patches-on-openharmony-development-boards.md)
- [Guidelines for Compiling and Building the Linux Kernel](guidelines-for-compiling-and-building-the-linux-kernel.md)
diff --git a/en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md b/en/device-dev/kernel/basic-kernel.md
similarity index 60%
rename from en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md
rename to en/device-dev/kernel/basic-kernel.md
index 8e3d07b35fb20071a4799e33f88480253820194f..ba8c2da4bd4e435d1e9f789d7ac33526d90d0fe4 100644
--- a/en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md
+++ b/en/device-dev/kernel/basic-kernel.md
@@ -1,4 +1,4 @@
-# OpenHarmony Lite Kernel Basic Functions
+# Basic Kernel
- **[Process](process.md)**
diff --git a/en/device-dev/kernel/lite-kernel.md b/en/device-dev/kernel/kernel-for-mini-and-small-systems.md
similarity index 55%
rename from en/device-dev/kernel/lite-kernel.md
rename to en/device-dev/kernel/kernel-for-mini-and-small-systems.md
index 3927b0fb506a8a301ca2b168f58e99170365406a..5f89928742c258eef81bcaad2de9772be208f4ef 100644
--- a/en/device-dev/kernel/lite-kernel.md
+++ b/en/device-dev/kernel/kernel-for-mini-and-small-systems.md
@@ -1,6 +1,6 @@
-# Lite Kernel
+# Kernel for Mini and Small Systems
-- **[OpenHarmony Lite Kernel Basic Functions](openharmony-lite-kernel-basic-functions.md)**
+- **[Basic Kernel](basic-kernel.md)**
- **[OpenHarmony Lite Kernel File System](openharmony-lite-kernel-file-system.md)**
diff --git a/en/device-dev/kernel/linux-kernel.md b/en/device-dev/kernel/kernel-for-standard-systems.md
similarity index 82%
rename from en/device-dev/kernel/linux-kernel.md
rename to en/device-dev/kernel/kernel-for-standard-systems.md
index 9391b466f5f056bda10b6cff24a0142cce6fef51..8d387b3cc01fdbce5d256b3f0cfdee160224a696 100644
--- a/en/device-dev/kernel/linux-kernel.md
+++ b/en/device-dev/kernel/kernel-for-standard-systems.md
@@ -1,4 +1,4 @@
-# Linux Kernel
+# Kernel for Standard Systems
- **[Linux Kernel Overview](linux-kernel-overview.md)**
diff --git a/en/device-dev/quick-start/overview.md b/en/device-dev/overview.md
similarity index 81%
rename from en/device-dev/quick-start/overview.md
rename to en/device-dev/overview.md
index 63cb2b8be145243d7324f5d29d28b303cad6d6aa..4a5832db5a9e81baccd6d4cbb4bf500c0f5a06a3 100644
--- a/en/device-dev/quick-start/overview.md
+++ b/en/device-dev/overview.md
@@ -30,6 +30,9 @@ In addition, OpenHarmony provides a series of optional system components that ca
## Document Outline
+- [Mini and Small System Development Guidelines](#table3762949121211)
+- [Standard System Development Guidelines](#table17667535516)
+
**Table 1** Mini and small system development guidelines \(reference memory < 128 MB\)
@@ -45,49 +48,49 @@ In addition, OpenHarmony provides a series of optional system components that ca
diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md
index b4f760b020e0cd05bae29470c24a27d49696bb63..19358865944306c284b052025edf7ff622ab9baa 100644
--- a/en/device-dev/porting/Readme-EN.md
+++ b/en/device-dev/porting/Readme-EN.md
@@ -1,4 +1,4 @@
-# Porting Guide
+# Third-Party Library Porting Guide
- [Third-Party Library Porting Guide](third-party-library-porting-guide.md)
- [Overview](overview.md)
diff --git a/en/device-dev/porting/porting-a-library-built-using-cmake.md b/en/device-dev/porting/porting-a-library-built-using-cmake.md
index a7d399c983a5841878aa59c6c4bd01dec39d4135..14cf6c7028e991bb73c0ae2a381d5ab49635ec6f 100644
--- a/en/device-dev/porting/porting-a-library-built-using-cmake.md
+++ b/en/device-dev/porting/porting-a-library-built-using-cmake.md
@@ -227,7 +227,7 @@ The following steps show how to configure and modify the toolchains for cross-co
1. Set up the OpenHarmony environment.
- Using Hi3518EV300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](https://gitee.com/openharmony/docs/blob/master/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md).
+ Using Hi3518EV300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](https://device.harmonyos.com/en/docs/start/introduce/oem_development_ex_3518-0000001105528572).
The following screen is displayed after a successful login to the OS.
@@ -306,7 +306,7 @@ The following steps show how to configure and modify the toolchains for cross-co
GN file for adding the third-party library to the OpenHarmony project
Script file for GN to call the shell command to convert compilation from GN to CMake.
diff --git a/en/device-dev/porting/system-modules.md b/en/device-dev/porting/system-modules.md
index 686ea0751d80679d063a624cf1eceb04c415fbd0..3484579267a00f1c2576bde63501efc60fc72d5f 100644
--- a/en/device-dev/porting/system-modules.md
+++ b/en/device-dev/porting/system-modules.md
@@ -22,5 +22,5 @@ For details about how to use SAMGR, see [samgr\_lite](https://gitee.com/openhar
The design for X \(DFX\) subsystem mainly includes design for reliability \(DFR\) and design for testability \(DFT\), providing code maintenance and testing.
-For details, see [dfx](../subsystems/dfx.md).
+For details, see **[DFX](../subsystems/DFX.md)**.
diff --git a/en/device-dev/quick-start/Readme-EN.md b/en/device-dev/quick-start/Readme-EN.md
index 4aab1f04bc1ebcfdf3856df5a8f7b02d9cf26265..8dc877bf65ca566b3ec191ba5f5d332c2d13a58d 100644
--- a/en/device-dev/quick-start/Readme-EN.md
+++ b/en/device-dev/quick-start/Readme-EN.md
@@ -1,6 +1,5 @@
# Getting Started
-- [Overview](overview.md)
- [Mini and Small Systems](mini-and-small-systems.md)
- [Overview](overview-0.md)
- [Introduction to the Development Boards](introduction-to-the-development-boards.md)
@@ -33,12 +32,10 @@
- [FAQs](faqs-6.md)
- [Standard System](standard-system.md)
- - [Overview](overview-7.md)
- - [Environment Setup](environment-setup-8.md)
- - [Overview](overview-9.md)
- - [Windows Development Environment](windows-development-environment-10.md)
- - [Preparing the Ubuntu Build Environment](preparing-the-ubuntu-build-environment.md)
- - [FAQs](faqs-11.md)
-
- - [How to Develop](how-to-develop-12.md)
+ - [Introduction](introduction.md)
+ - [Setting Up Windows Development Environment](setting-up-windows-development-environment.md)
+ - [Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md)
+ - [Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md)
+ - [Burning Images](burning-images.md)
+ - [FAQs](faqs-7.md)
diff --git a/en/device-dev/quick-start/burning-images.md b/en/device-dev/quick-start/burning-images.md
new file mode 100644
index 0000000000000000000000000000000000000000..b63966d94334be8ec473b7d641fb4f36c33b8866
--- /dev/null
+++ b/en/device-dev/quick-start/burning-images.md
@@ -0,0 +1,205 @@
+# Burning Images
+
+- [Next](#section5600113114323)
+
+Programming flash memory of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
+
+The Hi3516DV300 of the Hi3516 series development boards supports programming flash memory of a regular system through the USB port, network port, or serial port, where:
+
+- **Windows system: Supports programming through the USB port, serial port, or network port**
+- **Linux system: Supports programming through the serial port or network port \(Linux+Windows dual system: Also supports programming through the USB port\)**
+
+Except for environment setup, the operations of programming 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 the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
+
+### Prerequisites
+
+[Open a project](https://device.harmonyos.com/en/docs/ide/user-guides/open_project-0000001071680043) in DevEco Device Tool and select the folder where the file to be programmed is located. Select **Hi3516DV300** for the development board type and **Hb** for **Framework**.
+
+### Programming Flash Memory Through the Network Port
+
+The Hi3516DV300 supports programming through the network port in Windows or Linux.
+
+1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_3516-0000001052670587).
+2. Open Device Manager, then check and record the serial port number corresponding to the development board.
+
+ > **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**.
+
+ 
+
+4. On the **Partition Configuration** tab page, enter the information about the files to be programmed, including the following.
+
+
+
Name
+
+
Binary
+
+
Memory
+
+
System
+
+
Address
+
+
Length
+
+
Board
+
+
Type
+
+
+
+
fastboot
+
+
Select u-boot-hi3516dv300_emmc.bin.
+
+
emmc
+
+
none
+
+
0x000000
+
+
0x100000
+
+
Select hi3516dv300.
+
+
NA
+
+
+
boot
+
+
Select uImage.
+
+
emmc
+
+
none
+
+
0x100000
+
+
0xf00000
+
+
NA
+
+
+
updater
+
+
Select updater.img.
+
+
emmc
+
+
ext3/4
+
+
0x1000000
+
+
0x1400000
+
+
NA
+
+
+
misc
+
+
Leave it blank.
+
+
emmc
+
+
none
+
+
0x2400000
+
+
0x100000
+
+
NA
+
+
+
system
+
+
Select system.img.
+
+
emmc
+
+
ext3/4
+
+
0x2500000
+
+
0xceb00000
+
+
NA
+
+
+
vendor
+
+
Select vendor.img.
+
+
emmc
+
+
ext3/4
+
+
0xd1000000
+
+
0x10000000
+
+
NA
+
+
+
userdata
+
+
Select userdata.img.
+
+
emmc
+
+
ext3/4
+
+
0xe1000000
+
+
0x5b800000
+
+
NA
+
+
+
+
+
+ 
+
+5. On the **hi3516dv300** tab page, configure the programming 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\_partitions**: Select the file to be programmed, including the following: fastboot, boot, updater, misc, system, vendor, and userdata.
+
+ 
+
+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:
+
+ - **upload\_net\_server\_ip**: Select the IP address set in [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.
+
+ 
+
+8. When you finish modifying, click **Save** in the upper right corner.
+9. Open the project file, go to  \> **PROJECT TASKS** \> **fastboot** \> **Erase** to erase U-boot.
+
+ 
+
+10. When the following message is displayed, power off the development board and then power it on.
+
+ 
+
+11. Start programming. When the following message is displayed, it indicates that the programming is successful.
+
+ 
+
+
+## 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/development-example-for-clock-apps.md).
+
diff --git a/en/device-dev/quick-start/developing-a-driver.md b/en/device-dev/quick-start/developing-a-driver.md
index ab35222428df5f2d3c2b909f178486c45c4c9e40..6c57fde80bf1f8b93cd500152bcc0999fd4faa77 100644
--- a/en/device-dev/quick-start/developing-a-driver.md
+++ b/en/device-dev/quick-start/developing-a-driver.md
@@ -1,4 +1,4 @@
-# Developing a Driver
+# Developing a Driver
- [Introduction to Driver](#s8efc1952ebfe4d1ea717182e108c29bb)
- [Compiling and Burning](#section660016185110)
@@ -439,7 +439,7 @@ Compile and burn images by referring to [Building](../quick-start/running-a-hel
1. Click **Monitor** to enable the serial port.
2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to step [2](running-a-hello-ohos-program.md#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to step [3](running-a-hello-ohos-program.md#ld26f18828aa44c36bfa36be150e60e49) otherwise.
+ 3. Go to step [2](running-a-hello-ohos-program.md#en-us_topic_0000001151888681_l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to step [3](running-a-hello-ohos-program.md#en-us_topic_0000001151888681_ld26f18828aa44c36bfa36be150e60e49) 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.
diff --git a/en/device-dev/quick-start/environment-setup-7.md b/en/device-dev/quick-start/environment-setup-7.md
deleted file mode 100644
index ef15df388b11feb122f95d983f3232819c631f78..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/environment-setup-7.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Environment Setup
-
-- **[Overview](overview-8.md)**
-
-- **[Windows Development Environment](windows-development-environment-9.md)**
-
-- **[Ubuntu Build Environment](ubuntu-build-environment-10.md)**
-
-- **[FAQs](faqs-11.md)**
-
-
diff --git a/en/device-dev/quick-start/environment-setup-8.md b/en/device-dev/quick-start/environment-setup-8.md
deleted file mode 100644
index 2428c3c9e47baa0d290309f02302c9b49a9336fd..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/environment-setup-8.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Environment Setup
-
-- **[Overview](overview-9.md)**
-
-- **[Windows Development Environment](windows-development-environment-10.md)**
-
-- **[Preparing the Ubuntu Build Environment](preparing-the-ubuntu-build-environment.md)**
-
-- **[FAQs](faqs-11.md)**
-
-
diff --git a/en/device-dev/quick-start/environment-setup.md b/en/device-dev/quick-start/environment-setup.md
index d1b7756c427d8503df33e4091497f2a54abf3a79..289f31965d0c38aea69d9ff15c917b6df62d8019 100644
--- a/en/device-dev/quick-start/environment-setup.md
+++ b/en/device-dev/quick-start/environment-setup.md
@@ -1,4 +1,4 @@
-# Environment Setup
+# Environment Setup
- **[Overview](overview-1.md)**
diff --git a/en/device-dev/quick-start/faq.md b/en/device-dev/quick-start/faq.md
index b1c6da1ec2a9aa32b80bc52b228db109730b05df..b1ed6400050ae7938c1873878e305e8779acac1f 100644
--- a/en/device-dev/quick-start/faq.md
+++ b/en/device-dev/quick-start/faq.md
@@ -1,4 +1,4 @@
-# FAQ
+# FAQ
- [What should I do if garbled characters and segmentation faults occur during hb installation?](#section411894616119)
- [What should I do if the message "cannot import 'sysconfig' from 'distutils'" is displayed during hb installation?](#section629417571626)
diff --git a/en/device-dev/quick-start/faqs-2.md b/en/device-dev/quick-start/faqs-2.md
deleted file mode 100644
index d85c04678ebb9340c0f9a240f9a143642177d280..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/faqs-2.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# FAQs
-
-- [What should I do when the images failed to be burnt over the selected serial port?](#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?
-
-- **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
- 
-
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
-
- **Figure 3** Disabling the terminal using the serial port
- 
-
-3. Click **Burn**, select the serial port, and start burning images again.
-
- **Figure 4** Restarting burning
-
-
- 
-
-
-## What should I do when Windows-based PC failed to be connected to the board?
-
-- **Symptom**
-
- 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
- 
-
-- **Possible Causes**
-
- The board is disconnected from the Windows-based PC.
-
- Windows Firewall does not allow Visual Studio Code to access the network.
-
-- **Solutions**
-
-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?
-
-- **Symptom**
-
- The burning status is not displayed after clicking **Burn** and selecting a serial port.
-
-- **Possible Causes**
-
- The IDE is not restarted after the DevEco plug-in is installed.
-
-- **Solutions**
-
- Restart the IDE.
-
-
-## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
-
-- **Symptom**
-
- 
-
-
-- **Possible Cause 1**: Python is not installed.
-- **Solutions**
-
- Install Python by referring to [Installing and Configuring Python](../quick-start/ubuntu-build-environment.md).
-
-- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
-
- 
-
-- **Solutions**
-
- Run the following commands:
-
- ```
- # cd /usr/bin/
- # which python3
- # ln -s /usr/local/bin/python3 python
- # python --version
- ```
-
- Example:
-
- 
-
-
-## What should I do when no command output is displayed?
-
-- **Symptom**
-
- The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
-
-- **Possible Cause 1**
-
- The serial port is connected incorrectly.
-
-- **Solutions**
-
- 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](../quick-start/running-a-hello-ohos-program.md) in the **Running an Image** section to change the serial port number.
-
-
-- **Possible Cause 2**
-
- The U-boot of the board is damaged.
-
-- **Solutions**
-
- Burn the U-boot.
-
- If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
-
-
-1. Obtain the U-boot file.
-
- > **NOTICE:**
- >The U-boot file of the two boards can be obtained from the following paths, respectively.
- >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
- >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
-
-2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
-
- Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
-
-3. Log in to the serial port after the burning is complete.
-
- **Figure 10** Serial port displayed after the U-boot is burnt
- 
-
-
diff --git a/en/device-dev/quick-start/faqs-3.md b/en/device-dev/quick-start/faqs-3.md
index f756777596c26d45581846666d5bf7a16ab3c632..12c3a207b5cb348e0fc45f60c7985eacb886e61b 100644
--- a/en/device-dev/quick-start/faqs-3.md
+++ b/en/device-dev/quick-start/faqs-3.md
@@ -1,4 +1,4 @@
-# FAQs
+# FAQs
- [What should I do when the images failed to be burnt over the selected serial port?](#section627268185113)
- [What should I do when Windows-based PC failed to be connected to the board?](#section195391036568)
@@ -97,7 +97,7 @@
- **Symptom**
- 
+ 
- **Possible Cause 1**: Python is not installed.
@@ -107,7 +107,7 @@
- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
- 
+ 
- **Solutions**
@@ -122,7 +122,7 @@
Example:
- 
+ 
## What should I do when no command output is displayed?
diff --git a/en/device-dev/quick-start/faqs-5.md b/en/device-dev/quick-start/faqs-5.md
deleted file mode 100644
index 86fbd180f7f576ae1c9e7a97cfea432ed7220e2e..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/faqs-5.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# FAQs
-
-- [What should I do when the images failed to be burnt over the selected serial port?](#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?
-
-- **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
- 
-
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
-
- **Figure 3** Disabling the terminal using the serial port
- 
-
-3. Click **Burn**, select the serial port, and start burning images again.
-
- **Figure 4** Restarting burning
-
-
- 
-
-
-## What should I do when Windows-based PC failed to be connected to the board?
-
-- **Symptom**
-
- 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
- 
-
-- **Possible Causes**
-
- The board is disconnected from the Windows-based PC.
-
- Windows Firewall does not allow Visual Studio Code to access the network.
-
-- **Solutions**
-
-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?
-
-- **Symptom**
-
- The burning status is not displayed after clicking **Burn** and selecting a serial port.
-
-- **Possible Causes**
-
- The IDE is not restarted after the DevEco plug-in is installed.
-
-- **Solutions**
-
- Restart the IDE.
-
-
-## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
-
-- **Symptom**
-
- 
-
-
-- **Possible Cause 1**
-
- Python is not installed.
-
-- **Solutions**
-
- Install Python by referring to [Installing and Configuring Python](../quick-start/ubuntu-build-environment.md).
-
-- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
-
- 
-
-- **Solutions**
-
- Run the following commands:
-
- ```
- # cd /usr/bin/
- # which python3
- # ln -s /usr/local/bin/python3 python
- # python --version
- ```
-
- Example:
-
- 
-
-
-## What should I do when no command output is displayed?
-
-- **Symptom**
-
- The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
-
-- **Possible Cause 1**
-
- The serial port is connected incorrectly.
-
-- **Solutions**
-
- 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](../quick-start/running-a-hello-ohos-program.md) in the **Running an Image** section to change the serial port number.
-
-
-- **Possible Cause 2**
-
- The U-boot of the board is damaged.
-
-- **Solutions**
-
- Burn the U-boot.
-
- If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
-
-
-1. Obtain the U-boot file.
-
- > **NOTICE:**
- >The U-boot file of the two boards can be obtained from the following paths, respectively.
- >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
- >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
-
-2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
-
- Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
-
-3. Log in to the serial port after the burning is complete.
-
- 
-
-
diff --git a/en/device-dev/quick-start/faqs-6.md b/en/device-dev/quick-start/faqs-6.md
index b428e3cf9fa250e5f077130f331806683bfbd8cf..05d53356aed9ab16ac8fe65e19da9dbe70089533 100644
--- a/en/device-dev/quick-start/faqs-6.md
+++ b/en/device-dev/quick-start/faqs-6.md
@@ -1,4 +1,4 @@
-# FAQs
+# FAQs
- [What should I do when the images failed to be burnt over the selected serial port?](#section1498892119619)
- [What should I do when Windows-based PC failed to be connected to the board?](#section8512971816)
@@ -97,7 +97,7 @@
- **Symptom**
- 
+ 
- **Possible Cause 1**
@@ -110,7 +110,7 @@
- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
- 
+ 
- **Solutions**
@@ -125,7 +125,7 @@
Example:
- 
+ 
## What should I do when no command output is displayed?
@@ -169,6 +169,6 @@
3. Log in to the serial port after the burning is complete.
- 
+ 
diff --git a/en/device-dev/quick-start/faqs-11.md b/en/device-dev/quick-start/faqs-7.md
similarity index 88%
rename from en/device-dev/quick-start/faqs-11.md
rename to en/device-dev/quick-start/faqs-7.md
index 1a0b63cdc83f58505a315d982274ade0ffaa8a59..649bcba046dcb5d9429291e69e44cc933bbbd077 100644
--- a/en/device-dev/quick-start/faqs-11.md
+++ b/en/device-dev/quick-start/faqs-7.md
@@ -1,4 +1,4 @@
-# FAQs
+# FAQs
- **Symptom**
diff --git a/en/device-dev/quick-start/faqs.md b/en/device-dev/quick-start/faqs.md
index 67bf3ab4671f458cde77df06005ebd128a57eeec..43db6c0373612483fa0cc1e752058e256bf9665e 100644
--- a/en/device-dev/quick-start/faqs.md
+++ b/en/device-dev/quick-start/faqs.md
@@ -1,4 +1,4 @@
-# FAQs
+# FAQs
- [What should I do when the message configure: error: no acceptable C compiler found in $PATH is displayed during Python 3 installation?](#section1221016541119)
- [What should I do when the message -bash: make: command not found is displayed during Python 3 installation?](#section1913477181213)
@@ -134,7 +134,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 +164,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 +194,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.
@@ -247,7 +247,7 @@
- **Possible Cause 2:** The soft link that points to the Python does not exist in the **usr/bin** directory.
- 
+ 
- **Solutions**
@@ -262,7 +262,7 @@
Example:
- 
+ 
## What should I do when an error with **lsb\_release** occurs during **kconfiglib** installation?
diff --git a/en/device-dev/quick-start/figures/1-19.png b/en/device-dev/quick-start/figures/1-19.png
deleted file mode 100644
index 8ed1535a6bc23dc5bd02fbd5a3f1392f46ad8d83..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/1-19.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/1-20.png b/en/device-dev/quick-start/figures/1-20.png
deleted file mode 100644
index 8ed1535a6bc23dc5bd02fbd5a3f1392f46ad8d83..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/1-20.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-17.png b/en/device-dev/quick-start/figures/2021-01-27_170334-17.png
deleted file mode 100644
index 1e7dd2cdb515e871a1c5d34b3332b097bc02351b..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/2021-01-27_170334-17.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-18.png b/en/device-dev/quick-start/figures/2021-01-27_170334-18.png
index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..1e7dd2cdb515e871a1c5d34b3332b097bc02351b 100644
Binary files a/en/device-dev/quick-start/figures/2021-01-27_170334-18.png and b/en/device-dev/quick-start/figures/2021-01-27_170334-18.png differ
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-6.png b/en/device-dev/quick-start/figures/2021-01-27_170334-6.png
deleted file mode 100644
index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/2021-01-27_170334-6.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/2021-01-27_181047.png b/en/device-dev/quick-start/figures/2021-01-27_181047.png
deleted file mode 100644
index 587ca51a1010c3fefcc79be73ffc5584075551ed..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/2021-01-27_181047.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/2021-01-28_112953.png b/en/device-dev/quick-start/figures/2021-01-28_112953.png
deleted file mode 100644
index a3a92549a345ad7ebb1d0142a50d2c41c4ede9f4..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/2021-01-28_112953.png and /dev/null differ
diff --git "a/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png" "b/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png"
new file mode 100644
index 0000000000000000000000000000000000000000..1ccb47f20022261cc291e8b435f263c00e8d4a27
Binary files /dev/null and "b/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png" differ
diff --git a/en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network-17.png b/en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network-17.png
deleted file mode 100644
index 13d77ce93c78ac07039c8f09741db1db1d05a124..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network-17.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/changjian1-12.png b/en/device-dev/quick-start/figures/changjian1-12.png
deleted file mode 100644
index 208a4fbace342514f59f0000c4d50f5dc9321f0f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/changjian1-12.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used-10.png b/en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used-10.png
deleted file mode 100644
index cfa0ceb21f5a11d459b93721f512309c9d6da2ac..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used-10.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/chuankou1-7.png b/en/device-dev/quick-start/figures/chuankou1-7.png
deleted file mode 100644
index 8eb26425f53028a08eb40e3037ecd302f3082270..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/chuankou1-7.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port-11.png b/en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port-11.png
deleted file mode 100644
index 0c1f60638087d0fe56127f2f842244355afad85f..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port-11.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001078313582.png b/en/device-dev/quick-start/figures/en-us_image_0000001078313582.png
deleted file mode 100644
index d09a7cc3c72dff150d1a06ab4a7fcaebb7de3265..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001078313582.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001113969536.png b/en/device-dev/quick-start/figures/en-us_image_0000001113969536.png
deleted file mode 100644
index baac7b26450b8bc195a0db0bb3bb41119c0d9828..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001113969536.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png b/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png
deleted file mode 100644
index c5548cb227bd024b49aa3adba0a20869581448e8..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001117621400.png b/en/device-dev/quick-start/figures/en-us_image_0000001117621400.png
new file mode 100644
index 0000000000000000000000000000000000000000..bfb378217e99536cf076deecfb0f0677cb51eef8
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001117621400.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001119945810.png b/en/device-dev/quick-start/figures/en-us_image_0000001119945810.png
deleted file mode 100644
index 8a4060e64fdd059143a3ec1adb9ee6937fa4af84..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001119945810.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001120802173.png b/en/device-dev/quick-start/figures/en-us_image_0000001120802173.png
deleted file mode 100644
index 5576e74b99dc2ae0ea635d3f684b560b93fce516..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001120802173.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001120802383.png b/en/device-dev/quick-start/figures/en-us_image_0000001120802383.png
deleted file mode 100644
index 4921a82341b8828a6117343b77f7c92b0d99a2c6..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001120802383.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001121061169.png b/en/device-dev/quick-start/figures/en-us_image_0000001121061169.png
deleted file mode 100644
index 5081b5a4be6269549d271afe84f96f7f489fc419..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001121061169.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105524466.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311066.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105524466.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311066.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105216304.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311070.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105216304.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311070.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001152176131.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311072.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001152176131.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311072.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001096963405.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311090.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001096963405.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311090.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001078089378.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311092.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001078089378.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311092.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001073835952.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311094.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001073835952.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311094.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311096.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311096.png
new file mode 100644
index 0000000000000000000000000000000000000000..0cd7b0a67ce7110774979284e69c462058723756
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001128311096.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160649343.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311098.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001160649343.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311098.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311100.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311100.png
new file mode 100644
index 0000000000000000000000000000000000000000..61aec8202ac830a3598ef2c8a413be30c5a742f0
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001128311100.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311104.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311104.png
new file mode 100644
index 0000000000000000000000000000000000000000..773abcd91a0c0ee1d3f5f87218216fc337d8f62f
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001128311104.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001078404538.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311116.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001078404538.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311116.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001057235392.png b/en/device-dev/quick-start/figures/en-us_image_0000001128311118.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001057235392.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128311118.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001151976061.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470864.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001151976061.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128470864.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105376252.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470880.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105376252.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128470880.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001073057176.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470900.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001073057176.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128470900.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470902.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470902.png
new file mode 100644
index 0000000000000000000000000000000000000000..43e43b52b677660cec4d049784b246aebe1a2434
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001128470902.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160529355.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470904.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001160529355.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128470904.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470906.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470906.png
new file mode 100644
index 0000000000000000000000000000000000000000..281958fe76a787acc5d0b98f5ea248fa5abf2405
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001128470906.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001078244328.png b/en/device-dev/quick-start/figures/en-us_image_0000001128470922.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001078244328.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128470922.png
diff --git a/zh-cn/device-dev/quick-start/figures/zh-cn_image_0000001096154076.png b/en/device-dev/quick-start/figures/en-us_image_0000001128471042.png
old mode 100755
new mode 100644
similarity index 100%
rename from zh-cn/device-dev/quick-start/figures/zh-cn_image_0000001096154076.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001128471042.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160528243.png b/en/device-dev/quick-start/figures/en-us_image_0000001160528243.png
deleted file mode 100644
index 571af4fc8e53f59f246496ad670cc6b84f4473f3..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001160528243.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160649345.png b/en/device-dev/quick-start/figures/en-us_image_0000001160649345.png
deleted file mode 100644
index 1819a2816fa617fa6389646fd6a4b1ab0d97272d..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001160649345.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001152056191.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270699.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001152056191.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270699.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105216296.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270713.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105216296.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270713.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105056492.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270715.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105056492.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270715.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270727.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270727.png
new file mode 100644
index 0000000000000000000000000000000000000000..2609aa029260a137c76c299fead396c07b8c8e45
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001174270727.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001116405268.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270729.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001116405268.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270729.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001163529159.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270731.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001163529159.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270731.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270733.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270733.png
new file mode 100644
index 0000000000000000000000000000000000000000..72dd05e3ae1eb91156df98cb1915b6264b3bbe5a
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001174270733.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270735.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270735.png
new file mode 100644
index 0000000000000000000000000000000000000000..2710fef9266dde76a9c555bc2edecebd8e3d8d1b
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001174270735.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001152256221.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270737.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001152256221.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270737.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001151976069.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270739.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001151976069.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270739.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105376260.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270743.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105376260.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270743.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001163569275.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270749.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001163569275.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270749.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001074285712.png b/en/device-dev/quick-start/figures/en-us_image_0000001174270751.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001074285712.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174270751.png
diff --git "a/en/device-dev/quick-start/figures/3861\350\203\214\351\235\242.png" b/en/device-dev/quick-start/figures/en-us_image_0000001174350615.png
similarity index 100%
rename from "en/device-dev/quick-start/figures/3861\350\203\214\351\235\242.png"
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350615.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001152176139.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350623.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001152176139.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350623.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001073388838.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350633.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001073388838.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350633.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001163568181.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350641.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001163568181.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350641.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001073242197.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350643.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001073242197.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350643.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160529359.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350647.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001160529359.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350647.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001077956808.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350649.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001077956808.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350649.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350651.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350651.png
new file mode 100644
index 0000000000000000000000000000000000000000..686385e096a24ec1906169d2b11f75030c386b9f
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001174350651.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350653.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350653.png
new file mode 100644
index 0000000000000000000000000000000000000000..e0dc22d338e23ca54b973597bf9f94ae4fd08a42
Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001174350653.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001105536118.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350659.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001105536118.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350659.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001152256235.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350661.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001152256235.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350661.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001074445364.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350669.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001074445364.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350669.png
diff --git a/zh-cn/device-dev/quick-start/figures/zh-cn_image_0000001143154485.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350781.png
old mode 100755
new mode 100644
similarity index 100%
rename from zh-cn/device-dev/quick-start/figures/zh-cn_image_0000001143154485.png
rename to en/device-dev/quick-start/figures/en-us_image_0000001174350781.png
diff --git a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-13.png b/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-13.png
deleted file mode 100644
index 548e03da4b76123cb67d41cbd1de4a0f33f5ef4b..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-13.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port-9.png b/en/device-dev/quick-start/figures/failed-to-open-the-serial-port-9.png
deleted file mode 100644
index 25308b9cab52a166955e70ada35c3191d90dd64c..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port-9.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/firewall-and-network-protection-15.png b/en/device-dev/quick-start/figures/firewall-and-network-protection-15.png
deleted file mode 100644
index 82faf7d05d2a40e9deae2649a1f59fccea67bdc2..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/firewall-and-network-protection-15.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png b/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png
new file mode 100644
index 0000000000000000000000000000000000000000..216265660cd0364189cd438da8b7e2600a7a5099
Binary files /dev/null and b/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png differ
diff --git a/en/device-dev/quick-start/figures/network-and-firewall-setting-14.png b/en/device-dev/quick-start/figures/network-and-firewall-setting-14.png
deleted file mode 100644
index 9487849c5f8a860e9680016ff3657404b2c0ad6e..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/network-and-firewall-setting-14.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application-16.png b/en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application-16.png
deleted file mode 100644
index 81812f492838b439ea507d4afb763ff751c0a467..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application-16.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution-8.png b/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution-8.png
deleted file mode 100644
index 6a85551cd30c8c0576c138d86dc66ddf73dccb44..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution-8.png and /dev/null differ
diff --git a/en/device-dev/quick-start/hi3516-development-board.md b/en/device-dev/quick-start/hi3516-development-board.md
index 39c132f0a8319e74b4bdb0e5cad6c6d6beef3993..53148cbe9a1fba7264055edc9fdad8eb193c00ad 100644
--- a/en/device-dev/quick-start/hi3516-development-board.md
+++ b/en/device-dev/quick-start/hi3516-development-board.md
@@ -1,4 +1,4 @@
-# Hi3516 Development Board
+# Hi3516 Development Board
- [Introduction](#section26131214194212)
- [Development Board Specifications](#section15192203316533)
diff --git a/en/device-dev/quick-start/hi3516.md b/en/device-dev/quick-start/hi3516.md
index 17987269923620c2ceb55de66d076c128da4da15..e33aa899315932687a01de028a7f0fccba0a91b2 100644
--- a/en/device-dev/quick-start/hi3516.md
+++ b/en/device-dev/quick-start/hi3516.md
@@ -1,4 +1,4 @@
-# Hi3516
+# Hi3516
- **[Setting Up the Environment](setting-up-the-environment-2.md)**
diff --git a/en/device-dev/quick-start/hi3518-development-board.md b/en/device-dev/quick-start/hi3518-development-board.md
index 1ba46e856f9b491ab4e240ab888ea3fe5a2fc803..262d456b50b47d8c91593999dd5a8f2d5a935d66 100644
--- a/en/device-dev/quick-start/hi3518-development-board.md
+++ b/en/device-dev/quick-start/hi3518-development-board.md
@@ -1,4 +1,4 @@
-# Hi3518 Development Board
+# Hi3518 Development Board
- [Introduction](#section14815247616)
- [Development Board Specifications](#section765112478446)
diff --git a/en/device-dev/quick-start/hi3518.md b/en/device-dev/quick-start/hi3518.md
index 3f7e2e5dcd0bddac839cd3184a3a27920df556e6..817d4c826164210f795e36503f49dded0c49529e 100644
--- a/en/device-dev/quick-start/hi3518.md
+++ b/en/device-dev/quick-start/hi3518.md
@@ -1,4 +1,4 @@
-# Hi3518
+# Hi3518
- **[Setting Up the Environment](setting-up-the-environment-4.md)**
diff --git a/en/device-dev/quick-start/hi3861-development-board.md b/en/device-dev/quick-start/hi3861-development-board.md
index 4e9d3ce1665264cd57b814aaea67f1f5039c9cd8..6790ab0fe64db575950bef8225613438ccbad63a 100644
--- a/en/device-dev/quick-start/hi3861-development-board.md
+++ b/en/device-dev/quick-start/hi3861-development-board.md
@@ -1,4 +1,4 @@
-# Hi3861 Development Board
+# Hi3861 Development Board
- [Introduction](#section19352114194115)
- [Resources and Constraints](#section82610215014)
@@ -19,7 +19,7 @@ The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expan
**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.
@@ -29,7 +29,7 @@ The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expan
**Figure 3** Hi3861 functions
- 
+ 
## Resources and Constraints
diff --git a/en/device-dev/quick-start/hi3861.md b/en/device-dev/quick-start/hi3861.md
index 8032fdd2ab4b2f7e0a23dcb8b127733d1c1900dc..100cdfcabc277a736ed2238f4b8cd93e345624a0 100644
--- a/en/device-dev/quick-start/hi3861.md
+++ b/en/device-dev/quick-start/hi3861.md
@@ -1,4 +1,4 @@
-# Hi3861
+# Hi3861
- **[Setting Up the Environment](setting-up-the-environment.md)**
diff --git a/en/device-dev/quick-start/how-to-develop-12.md b/en/device-dev/quick-start/how-to-develop-12.md
deleted file mode 100644
index f6fe9c7a06d672e94059bb92f907cf1e96311cc1..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/how-to-develop-12.md
+++ /dev/null
@@ -1,246 +0,0 @@
-# How to Develop
-
-- [Environment Setup](#section1246439101710)
-- [Build](#section375234715135)
-- [Burning](#section111671738101213)
- - [Prerequisites](#section1458192114718)
- - [Programming Flash Memory Through the USB Port](#section18423113662120)
-
-- [Development Example](#section5600113114323)
-
-## Environment Setup
-
-For details about setting up the standard OpenHarmony environment, see [Setting Up the Environment](overview-9.md).
-
-> **NOTE:**
->For details about the environment requirements of the third-party development board, refer to the official guide of the development board.
-
-## Build
-
-If you are using the Docker environment, refer to the Docker usage guide to build the system. If you are using the installation package, perform the following operations in the Linux environment.
-
-1. Go to the root directory of the source code and run the following command to build the distribution.
-
- ```
- ./build.sh --product-name Hi3516DV300
- ```
-
- **product\_name** indicates the platform supported by the current distribution,
-
-2. Check the build result. After the build is complete, the following information is displayed in the log:
-
- ```
- build system image successful.
- =====build Hi3516DV300 successful.
- ```
-
- 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.
-
- > **NOTE:**
- >For details about module-specific build operations, see [Compilation and Building Overview](../subsystems/building-guidelines-for-the-standard-system.md).
-
-
-## Burning
-
-Programming flash memory of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
-
-The Hi3516DV300 of the Hi3516 series development boards supports programming flash memory of a regular system through the USB port, network port, or serial port, where:
-
-- **Windows system: Supports programming through the USB port, serial port, or network port**
-- **Linux system: Supports programming through the serial port or network port \(Linux+Windows dual system: Also supports programming through the USB port\)**
-
-Except for environment setup, the burning operations are the same for Windows and Linux.
-
-> **NOTE:**
->Currently, the Hi3516D V300 development board supports system burning over the USB port, network port, or serial port. This document uses the USB port as an example. For details about system burning over other ports, see [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
-
-### Prerequisites
-
-[Open a project](https://device.harmonyos.com/en/docs/ide/user-guides/open_project-0000001071680043) in DevEco Device Tool and select the folder where the file to be programmed is located. Select **Hi3516DV300** for the development board type and **Hb** for **Framework**.
-
-### Programming Flash Memory Through the USB Port
-
-The Hi3516DV300 supports programming through the USB port in Windows or Linux+Windows environment.
-
-1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_3516-0000001052670587).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **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**.
-
- 
-
-4. On the **Partition Configuration** tab page, enter the information about the files to be programmed, including the following.
-
-
-
Name
-
-
Binary
-
-
Memory
-
-
System
-
-
Address
-
-
Length
-
-
Board
-
-
Type
-
-
-
-
fastboot
-
-
Select u-boot-hi3516dv300_emmc.bin.
-
-
emmc
-
-
none
-
-
0x000000
-
-
0x100000
-
-
Select hi3516dv300.
-
-
NA
-
-
-
boot
-
-
Select uImage.
-
-
emmc
-
-
none
-
-
0x100000
-
-
0xf00000
-
-
NA
-
-
-
updater
-
-
Select updater.img.
-
-
emmc
-
-
ext3/4
-
-
0x1000000
-
-
0x1400000
-
-
NA
-
-
-
misc
-
-
Leave it blank.
-
-
emmc
-
-
none
-
-
0x2400000
-
-
0x100000
-
-
NA
-
-
-
system
-
-
Select system.img.
-
-
emmc
-
-
ext3/4
-
-
0x2500000
-
-
0xceb00000
-
-
NA
-
-
-
vendor
-
-
Select vendor.img.
-
-
emmc
-
-
ext3/4
-
-
0xd1000000
-
-
0x10000000
-
-
NA
-
-
-
userdata
-
-
Select userdata.img.
-
-
emmc
-
-
ext3/4
-
-
0xe1000000
-
-
0x5b800000
-
-
NA
-
-
-
-
-
- 
-
-5. On the **hi3516dv300** tab page, configure the programming options.
-
- - **upload\_port**: Select the serial port number obtained in step 2.
- - **upload\_protocol**: Select the programming protocol **hiburn-usb**.
- - **upload\_partitions**: Select the file to be programmed, including the following: fastboot, boot, updater, misc, system, vendor, and userdata.
-
- 
-
-6. When you finish modifying, click **Save** in the upper right corner.
-7. Open the project file, go to  \> **PROJECT TASKS** \> **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 **hi3516dv300** \> **Upload** to start programming.
-
- > **NOTE:**
- >If this is the first time you program flash memory on the Hi3516 or Hi3518 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 programming again.
-
- 
-
-11. If the following message is displayed, it indicates that the programming is successful.
-
- 
-
-
-## Development Example
-
-You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Platform Drivers](../guide/overview-10.md).
-
diff --git a/en/device-dev/quick-start/how-to-develop.md b/en/device-dev/quick-start/how-to-develop.md
index 1d961ebf4b57ac2a26aa4e377987a6bddd50c2d2..3e5f705cb569a6d3c7f9543dd24a75159e1682aa 100644
--- a/en/device-dev/quick-start/how-to-develop.md
+++ b/en/device-dev/quick-start/how-to-develop.md
@@ -1,4 +1,4 @@
-# How to Develop
+# How to Develop
- **[Hi3861](hi3861.md)**
diff --git a/en/device-dev/quick-start/introduction-to-the-development-boards.md b/en/device-dev/quick-start/introduction-to-the-development-boards.md
index 6703a78fe6d3e877145d5198435d3c2f99c971c4..3848dad5841c053f27b1b5f6280a8a34cb6b41c4 100644
--- a/en/device-dev/quick-start/introduction-to-the-development-boards.md
+++ b/en/device-dev/quick-start/introduction-to-the-development-boards.md
@@ -1,4 +1,4 @@
-# Introduction to the Development Boards
+# Introduction to the Development Boards
- **[Hi3861 Development Board](hi3861-development-board.md)**
diff --git a/en/device-dev/quick-start/introduction.md b/en/device-dev/quick-start/introduction.md
new file mode 100644
index 0000000000000000000000000000000000000000..7209c5c0f18b55e253bca942025b9d0682e390b3
--- /dev/null
+++ b/en/device-dev/quick-start/introduction.md
@@ -0,0 +1,54 @@
+# Introduction
+
+- [Quick Start Process](#section7825218111517)
+- [Introduction to the Development Board](#en-us_topic_0000001053666242_section047719215429)
+- [Development Board Specifications](#en-us_topic_0000001053666242_section15192203316533)
+
+This document helps you quickly understand how to set up a standard OpenHarmony system, and how to build, burn, and start the system. You can develop the standard system in Windows and build source code in Linux.
+
+This document uses the recommended Hi3516D V300 development board as an example.
+
+## Quick Start Process
+
+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
+
+**Table 1** Specifications of the Hi3516 development board
+
+
+
Item
+
+
Description
+
+
+
+
Processor and internal memory
+
+
Hi3516D V300
1 GB DDR3
8 GB eMMC4.5
+
+
+
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)
+
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/overview-0.md b/en/device-dev/quick-start/overview-0.md
index 9a73241369434d4ec249a00b0f9231c5a9d83a3a..8a7a6ba8fdb2b61d099ce7b399c04efe6056f5d6 100644
--- a/en/device-dev/quick-start/overview-0.md
+++ b/en/device-dev/quick-start/overview-0.md
@@ -1,4 +1,4 @@
-# Overview
+# Overview
The mini and small OpenHarmony systems are suitable for IoT devices with limited memory. This document describes the system development with three typical development boards: Hi3861 WLAN module, Hi3516D V300, and Hi3518E V300.
diff --git a/en/device-dev/quick-start/overview-1.md b/en/device-dev/quick-start/overview-1.md
index d490f51d2ebc128dda830e011b63b20e637b1136..5b5feef48c5ae0f1668069c6cb4fce756fe4b2b6 100644
--- a/en/device-dev/quick-start/overview-1.md
+++ b/en/device-dev/quick-start/overview-1.md
@@ -1,4 +1,4 @@
-# Overview
+# Overview
Use the DevEco Device Tool for development, build, burning, and debugging of OpenHarmony.
diff --git a/en/device-dev/quick-start/overview-6.md b/en/device-dev/quick-start/overview-6.md
deleted file mode 100644
index c4f01181922cdde3dd4924e6ef8978c03f260a1c..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/overview-6.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Overview
-
-This document helps you quickly understand how to set up a standard OpenHarmony system, and how to build, burn, and start the system. This document uses the recommended Hi3516D V300 development board as an example.
-
diff --git a/en/device-dev/quick-start/overview-7.md b/en/device-dev/quick-start/overview-7.md
deleted file mode 100644
index c4f01181922cdde3dd4924e6ef8978c03f260a1c..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/overview-7.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Overview
-
-This document helps you quickly understand how to set up a standard OpenHarmony system, and how to build, burn, and start the system. This document uses the recommended Hi3516D V300 development board as an example.
-
diff --git a/en/device-dev/quick-start/overview-8.md b/en/device-dev/quick-start/overview-8.md
deleted file mode 100644
index 050e338e9d4009463c20bb282f0c8b9bd9f69370..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/overview-8.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Overview
-
-- [Introduction](#section18217135811916)
-- [Environment Requirements](#section466851916410)
- - [Hardware](#section19682305453)
- - [Software](#section1595725202314)
-
-
-## Introduction
-
-In a standard system, you can use the DevEco Device Tool for development and burning in Windows, and for build in Linux. This document describes how to set up the environment.
-
-> **NOTE:**
->The procedure for setting up a Windows standard-system environment is basically the same as that for setting up a Windows mini- or small-system environment. Therefore, you can skip section [Windows Development Environment](windows-development-environment-9.md) if you have set up a Windows mini- or small-system environment.
-
-## Environment Requirements
-
-### Hardware
-
-- Linux compile server
-- Windows workstation \(host computer\)
-
-### Software
-
-**Table 1** Development platform requirements
-
-
-
Platform
-
-
Software
-
-
Description
-
-
Remarks
-
-
-
-
Linux compile server
-
-
Operating system
-
-
Ubuntu 18.04 64-bit or later is used for the Linux OS, and bash is used as the shell. The server hardware specifications are as follows:
-
Hard disk: at least 400 GB
CPU: at least 8 cores
Memory: at least 32 GB
-
Common software such as samba and vim is installed in the OS by default. Adaptation is required to support Linux file sharing.
-
-
You can develop programs on the Windows workstation or Linux server via a remote login.
-
-
-
Windows workstation
-
-
Operating system
-
-
Windows XP/Windows7/Windows10
-
-
-
-
-
diff --git a/en/device-dev/quick-start/overview-9.md b/en/device-dev/quick-start/overview-9.md
deleted file mode 100644
index 2afccc92c3ac98b0d6f181c1ba69f706364a0562..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/overview-9.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Overview
-
-- [Introduction](#section18217135811916)
-- [Environment Requirements](#section466851916410)
- - [Hardware](#section19682305453)
- - [Software](#section1595725202314)
-
-
-## Introduction
-
-In a standard OpenHarmony system, you can use the DevEco Device Tool for development and burning in Windows, and for build in Linux. This document describes how to set up the environment.
-
-> **NOTE:**
->The procedure for setting up a Windows standard-system environment is basically the same as that for setting up a Windows mini- or small-system environment. Therefore, you can skip section [Windows Development Environment](windows-development-environment-10.md) if you have set up a Windows mini- or small-system environment.
-
-## Environment Requirements
-
-### Hardware
-
-- Linux compile server
-- Windows workstation \(host computer\)
-
-### Software
-
-**Table 1** Development platform requirements
-
-
-
Platform
-
-
Software
-
-
Description
-
-
Remarks
-
-
-
-
Linux compile server
-
-
Operating system
-
-
Ubuntu 18.04 64-bit or later is used for the Linux OS, and bash is used as the shell. The server hardware specifications are as follows:
-
Hard disk: at least 400 GB
CPU: at least 8 cores
Memory: at least 32 GB
-
Common software such as samba and vim is installed in the OS by default. Adaptation is required to support Linux file sharing.
-
-
You can develop programs on the Windows workstation or Linux server via a remote login.
-
-
-
Windows workstation
-
-
Operating system
-
-
Windows XP/Windows7/Windows10
-
-
-
-
-
diff --git a/en/device-dev/quick-start/preparing-the-ubuntu-build-environment.md b/en/device-dev/quick-start/preparing-the-ubuntu-build-environment.md
deleted file mode 100644
index e1f0774daadb6d6f807a95c16affac8e8a630b27..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/preparing-the-ubuntu-build-environment.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# Preparing the Ubuntu Build Environment
-
-- [Method 1: Setting up an Ubuntu Build Environment Using a Docker Environment](#section1643363843714)
- - [Obtaining Standard-System Source Code](#section58448331029)
- - [Installing and Using the Docker Environment](#section22916211916)
-
-- [Method 2: Setting up an Ubuntu Build Environment Using an Installation Package](#section25961010189)
- - [Installing Dependent Tools](#section109262032104819)
- - [Obtaining Standard-System Source Code](#section6325556113718)
- - [Obtaining prebuilts](#section16453104219209)
-
-
-You can use either the Docker environment or installation package provided by OpenHarmony to set up an Ubuntu build environment. This section describes the two methods.
-
-## Method 1: Setting up an Ubuntu Build Environment Using a Docker Environment
-
-The standard OpenHarmony system provides a Docker environment which encapsulates build tools. To use the Docker environment, perform the following steps:
-
-1. Obtain the standard-system source code.
-2. Install and use the Docker environment.
-
-### Obtaining Standard-System Source Code
-
-Obtain the [standard-system source code](https://repo.huaweicloud.com/harmonyos/os/2.0/code-2.0-canary.tar.gz). The obtained source code is the static code. If you want to obtain the latest source code from Gitee, use [repo](../get-code/source-code-acquisition.md).
-
-### Installing and Using the Docker Environment
-
-For details, see [Installing and Using Docker](../get-code/tool-acquisition.md).
-
-## Method 2: Setting up an Ubuntu Build Environment Using an Installation Package
-
-The procedure is as follows:
-
-1. Install dependent tools.
-2. Obtain the standard-system source code.
-3. Obtain prebuilts.
-
-### Installing Dependent Tools
-
-The installation command is as follows:
-
-```
-sudo apt-get install binutils git-core git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4
-```
-
-> **CAUTION:**
->The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, use the corresponding installation commands based on the installation package name. If the Ubuntu version is later than 18.04, Python 2.7 and python-minimal must be installed.
-
-### Obtaining Standard-System Source Code
-
-Obtain the [standard-system source code](https://repo.huaweicloud.com/harmonyos/os/2.0/code-2.0-canary.tar.gz). The obtained source code is the static code. If you want to obtain the latest source code from Gitee, use [repo](../get-code/source-code-acquisition.md).
-
-### Obtaining prebuilts
-
-1. Go to the OpenHarmony working directory.
-
- ```
- cd OpenHarmony
- ```
-
-2. Execute the following script:
-
- ```
- 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**\).
-
-
diff --git a/en/device-dev/quick-start/running-a-hello-ohos-program-4.md b/en/device-dev/quick-start/running-a-hello-ohos-program-4.md
deleted file mode 100644
index 62c151696188113379a554af194eae697f0f22b4..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/running-a-hello-ohos-program-4.md
+++ /dev/null
@@ -1,268 +0,0 @@
-# Running a Hello OHOS Program
-
-- [Creating a Program](#section1550972416485)
-- [Building](#section234175193114)
-- [Burning](#section7609155824819)
-- [Running an Image](#section17612105814480)
-- [Follow-up Learning](#section9712145420182)
-
-This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
-
-## Creating a Program
-
-1. Create a directory and the program source code.
-
- Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program.
-
- ```
- #include
-
- int main(int argc, char **argv)
- {
- printf("\n************************************************\n");
- printf("\n\t\tHello OHOS!\n");
- printf("\n************************************************\n\n");
-
- return 0;
- }
- ```
-
-2. Create a build file.
-
- Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows:
-
- ```
- import("//build/lite/config/component/lite_component.gni")
- lite_component("hello-OHOS") {
- features = [ ":helloworld" ]
- }
- executable("helloworld") {
- output_name = "helloworld"
- sources = [ "src/helloworld.c" ]
- include_dirs = []
- defines = []
- cflags_c = []
- ldflags = []
- }
- ```
-
-3. Add a new component.
-
- Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
-
- ```
- {
- "components": [
- {
- "component": "camera_sample_communication",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/communication"
- ],
- "targets": [
- "//applications/sample/camera/communication:sample"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##start##
- {
- "component": "hello_world_app",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/apps"
- ],
- "targets": [
- "//applications/sample/camera/apps:hello-OHOS"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##end##
- {
- "component": "camera_sample_app",
- "description": "Camera related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/launcher",
- "applications/sample/camera/cameraApp",
- "applications/sample/camera/setting",
- "applications/sample/camera/gallery",
- "applications/sample/camera/media"
- ],
- ```
-
-4. Modify the board configuration file.
-
- Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_aries/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
-
- ```
- {
- "subsystem": "applications",
- "components": [
- ##start##
- { "component": "hello_world_app", "features":[] },
- ##end##
- { "component": "camera_sample_app", "features":[] }
-
- ]
- },
- ```
-
-
-## Building
-
-If the Linux environment is installed using Docker, perform the compilation by referring to [Using Docker to Prepare the Build Environment](../get-code/tool-acquisition.md). If the Linux compilation environment is installed using a software package, execute the following commands to compile source code in the root directory of the source code package.
-
-```
-hb set (Set the building path.)
-. (Select the current path.)
-Select ipcamera_hispark_aries@hisilicon and press Enter.
-hb build -f (Start building.)
-```
-
-The result files are generated in the **out/hispark\_aries/ipcamera\_hispark\_aries** directory.
-
-**Figure 1** 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
-
-The USB port is the only burning mode supported by the Hi3518 development board.
-
-1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3518EV300 is used as an example. For details, please refer to [Introduction to the Hi3518 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_hi3518-0000001050170473).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **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**.
-
- 
-
-4. On the **hi3518ev300** tab page, set the programming 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.
-
- 
-
-5. Switch between the **hi3518ev300\_fastboot**, **hi3518ev300\_kernel**, **hi3518ev300\_rootfs**, and **hi3518ev300\_userfs** tab pages, and modify the settings. In general cases, you can leave the fields at their default settings. To change the default settings, select the target item in the **New Option** field first.
-
- 
-
-6. When you finish modifying, click **Save** in the upper right corner.
-
- 
-
-7. Open the project file, go to  \> **PROJECT TASKS** \> **partition: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 **env:hi3518ev300** \> **Upload** to start programming.
-
- 
-
-11. If the following message is displayed, it indicates that the programming is successful.
-
- 
-
-
-## Running an Image
-
-1. Connect to a serial port.
-
- > **NOTICE:**
- >If the connection fails, rectify the fault by referring to [FAQs](../quick-start/faqs-2.md).
-
- **Figure 2** Serial port connection
-
-
- 
-
- 1. Click **Monitor** to enable the serial port. The **TERMINAL** window is displayed.
- 2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to [step 2](#li9441185382314) if the board is started for the first time or the startup parameters need to be modified; go to [step 3](#li6442853122312) otherwise.
-
-2. \(Mandatory for the first burning\) Modify the **bootcmd** and **bootargs** parameters of U-boot. This step is a fixed operation and the result can be saved. However, you need to perform the following steps again if U-boot needs to be reburnt.
-
- **Table 1** Parameters of the U-boot
-
-
-
Run this command to set the content of bootcmd. Select the flash whose number is 0, and read content that has a size of 0x600000 (6 MB) and a start address of 0x100000 to memory address 0x40000000. The size must be the same as that of the OHOS_Image.bin file in the IDE.
-
-
-
setenv bootargs "console=ttyAMA0,115200n8 root=flash fstype=jffs2 rw rootaddr=7 M rootsize=8 M";
-
-
In this command, bootargs is set to the serial port output, the baud rate is 115200, the data bit is 8, and the rootfs is mounted to the flash memory. The file system type is set to jffs2 rw, which provides the read-write attribute for the JFFS2 file system. rootaddr=7 M rootsize=8 M indicates the actual start address and length of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
-
-
-
saveenv
-
-
saveenv means to save the current configuration.
-
-
-
reset
-
-
reset means to reset the board.
-
-
-
pri
-
-
pri means to view the displayed parameters.
-
-
-
-
-
- > **NOTICE:**
- >**go 0x40000000** \(optional\) 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. If **hisilicon \#** is displayed during the startup, run the **reset** command. After the system automatically starts and **OHOS** is displayed, run the **./bin/helloworld** command and then press **Enter**. The system is started successfully if information shown in the following figure is displayed.
-
- **Figure 3** Successful system startup and program execution
- 
-
-
-## Follow-up Learning
-
-Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/cameras-with-a-screen.md).
-
diff --git a/en/device-dev/quick-start/running-a-hello-ohos-program-5.md b/en/device-dev/quick-start/running-a-hello-ohos-program-5.md
index 713bd45a6bda1acfa95c9b2061669fd5475ebb1a..e3f5d5e2955b1b44c9999d567a171ca426f5104b 100644
--- a/en/device-dev/quick-start/running-a-hello-ohos-program-5.md
+++ b/en/device-dev/quick-start/running-a-hello-ohos-program-5.md
@@ -1,4 +1,4 @@
-# Running a Hello OHOS Program
+# Running a Hello OHOS Program
- [Creating a Program](#section1550972416485)
- [Building](#section234175193114)
@@ -46,9 +46,9 @@ This section describes how to create, compile, burn, and run the first program,
}
```
-3. Add a new component.
+3. Add a component.
- Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
+ Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **"\#\#start\#\#"** and **"\#\#end\#\#"** is the new configuration \(Delete the rows where **"\#\#start\#\#"** and **"\#\#end\#\#"** are located after the configurations are added.\)
```
{
@@ -128,7 +128,7 @@ This section describes how to create, compile, burn, and run the first program,
## Building
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/tool-acquisition.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
```
hb set (Set the building path.)
@@ -143,53 +143,53 @@ The result files are generated in the **out/hispark\_aries/ipcamera\_hispark\_a

> **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
+>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
The USB port is the only burning mode supported by the Hi3518 development board.
-1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3518EV300 is used as an example. For details, please refer to [Introduction to the Hi3518 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_hi3518-0000001050170473).
+1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3518EV300 is used as an example. For details, see [Introduction to the Hi3518 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3518-0000001105201138).
2. Open Device Manager, then check and record the serial port number corresponding to the development board.
> **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**.
- 
+ 
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.
- - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001057313128_li46411811196).
+ - **upload\_port**: Select the serial port number obtained in [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.
- 
+ 
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 and click . In the DevEco Device Tool window, choose **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.
- 
+ 
11. If the following message is displayed, it indicates that the programming is successful.
- 
+ 
## Running an Image
@@ -208,9 +208,9 @@ The USB port is the only burning mode supported by the Hi3518 development board.
2. Press **Enter** repeatedly until **hisilicon** displays.
3. Go to [step 2](#li9441185382314) if the board is started for the first time or the startup parameters need to be modified; go to [step 3](#li6442853122312) otherwise.
-2. \(Mandatory for the first burning\) Modify the **bootcmd** and **bootargs** parameters of U-boot. This step is a fixed operation and the result can be saved. However, you need to perform the following steps again if U-boot needs to be reburnt.
+2. \(Mandatory for first-time burning\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. This step is a fixed operation and the result can be saved. However, you need to perform the following steps again if U-Boot needs to be reburnt.
- **Table 1** Parameters of the U-boot
+ **Table 1** Parameters of the U-Boot
Command
@@ -248,7 +248,7 @@ The USB port is the only burning mode supported by the Hi3518 development board.
> **NOTICE:**
- >**go 0x40000000** \(optional\) 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.
+ >**go 0x40000000** \(optional\) 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. If **hisilicon \#** is displayed during the startup, run the **reset** command. After the system automatically starts and **OHOS** is displayed, run the **./bin/helloworld** command and then press **Enter**. The system is started successfully if information shown in the following figure is displayed.
diff --git a/en/device-dev/quick-start/running-a-hello-ohos-program.md b/en/device-dev/quick-start/running-a-hello-ohos-program.md
index 5f38a61c19e21dfa897231cf60086708b586ca67..19bf8bf16abb4c45546b42a8d4bf1f5551ce19e1 100644
--- a/en/device-dev/quick-start/running-a-hello-ohos-program.md
+++ b/en/device-dev/quick-start/running-a-hello-ohos-program.md
@@ -1,4 +1,4 @@
-# Running a Hello OHOS Program
+# Running a Hello OHOS Program
- [Creating a Program](#section204672145202)
- [Building](#section1077671315253)
@@ -129,7 +129,7 @@ This section describes how to create, compile, burn, and run the first program,
## Building
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/tool-acquisition.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
```
hb set (Set the building path.)
@@ -150,49 +150,49 @@ 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.
-1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_3516-0000001052670587).
+1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [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.
> **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**.

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, set the programming options.
- - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li142386399535).
+ - **upload\_port**: Select the serial port number obtained in [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.
- 
+ 
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:
- - **upload\_net\_server\_ip**: Select the IP address set in [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\_server\_ip**: Select the IP address set in [6](#en-us_topic_0000001056443961_li1558813168234). Example: 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.
- 
+ 
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 click . In the DevEco Device Tool window, choose **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start programming.
- 
+ 
10. When the following message is displayed, power off the development board and then power it on.
- 
+ 
-11. Start programming. When the following message is displayed, it indicates that the programming is successful.
+11. Start burning. When the following message is displayed, the burning is successful.
- 
+ 
## Running an Image
diff --git a/en/device-dev/quick-start/running-a-hello-world-program.md b/en/device-dev/quick-start/running-a-hello-world-program.md
index 8cb794b97c38fb0ae33cc2c32b80370bb9245584..033f919351f898df2b656b5512bedf524a613adb 100644
--- a/en/device-dev/quick-start/running-a-hello-world-program.md
+++ b/en/device-dev/quick-start/running-a-hello-world-program.md
@@ -1,4 +1,4 @@
-# Running a Hello World Program
+# Running a Hello World Program
- [Modifying Source Code](#section79601457101015)
- [Debugging and Verification](#section1621064881419)
@@ -135,7 +135,7 @@ To parse the call stack information, the **Hi3861\_wifiiot\_app.asm** file is
3. Determine that an exception occurs in the **WadRecvCB** function based on the call stack information.
- 
+ 
4. Check and modify the code.
diff --git a/en/device-dev/quick-start/setting-up-the-environment-1.md b/en/device-dev/quick-start/setting-up-the-environment-1.md
deleted file mode 100644
index 49586bc1993e592982cc191d1e38c96a1eaa8b89..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-the-environment-1.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Setting Up the Environment
-
-- [Environment Requirements](#section179175261196)
- - [Hardware](#section5840424125014)
- - [Software](#section965634210501)
-
-- [Installing Linux Build Tools](#section182916865219)
- - [Changing Linux Shell to Bash](#section1715027152617)
- - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
- - [Installing a File Packing Tool](#section1969111820270)
- - [Installing the JVM](#section1692618112713)
-
-
-## Environment Requirements
-
-### Hardware
-
-- Hi3516D V300 IoT camera development board
-- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3516D V300 development board through the USB-to-serial cable and network cable.\)
-
-The following figure shows the hardware connections.
-
-**Figure 1** Hardware connections
-
-
-
-
-### Software
-
-> **NOTICE:**
->This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section182916865219).
-
-The following table describes the tools required for setting up the general environment for a Linux server of the Hi3516 development board and how to obtain these tools.
-
-**Table 1** Development tools and obtaining methods
-
-
-
Development Tool
-
-
Description
-
-
How to Obtain
-
-
-
-
bash
-
-
Processes CLI commands.
-
-
System configuration
-
-
-
Basic software package for compilation and building (required only for Ubuntu 20+)
-
-
Provides a basic software package for compilation and building.
-
-
Internet
-
-
-
dosfstools, mtools, and mtd-utils
-
-
Pack files.
-
-
apt-get install
-
-
-
Java virtual machine (JVM)
-
-
Compiles, debugs, and runs Java programs.
-
-
apt-get install
-
-
-
-
-
-## Installing Linux Build Tools
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install compilation tools like **LLVM** and **hc-gen**.
->- \(Recommended\) If you obtain the source code through an image site or a code repository, you should install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
-
-### Changing Linux Shell to Bash
-
-Check whether bash is used as the shell.
-
-```
-ls -l /bin/sh
-```
-
-If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
-
-**Method 1:** Run the following command on the device and then click **No**.
-
-```
-sudo dpkg-reconfigure dash
-```
-
-**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
-
-```
-sudo rm -rf /bin/sh
-sudo ln -s /bin/bash /bin/sh
-```
-
-### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
-
-Install the software.
-
-```
-sudo apt-get install build-essential && sudo apt-get install gcc && sudo apt-get install g++ && sudo apt-get install make && sudo apt-get install zlib* && sudo apt-get install libffi-dev
-```
-
-### Installing a File Packing Tool
-
-1. Start a Linux server.
-2. Install **dosfstools**.
-
- ```
- sudo apt-get install dosfstools
- ```
-
-3. Install **mtools**.
-
- ```
- sudo apt-get install mtools
- ```
-
-4. Install **mtd-utils**.
-
- ```
- sudo apt-get install mtd-utils
- ```
-
-
-### Installing the JVM
-
-1. Start a Linux server.
-2. Install the Java Runtime Environment \(JRE\).
-
- ```
- sudo apt-get install default-jre
- ```
-
-3. Install the Java Development Kit \(JDK\).
-
- ```
- sudo apt-get install default-jdk
- ```
-
-
diff --git a/en/device-dev/quick-start/setting-up-the-environment-2.md b/en/device-dev/quick-start/setting-up-the-environment-2.md
index 1c3604b02e1ab335b5ae9d4480b59826bccbe253..0e8430d75a7fa0bfe54420a0fcb8638108732710 100644
--- a/en/device-dev/quick-start/setting-up-the-environment-2.md
+++ b/en/device-dev/quick-start/setting-up-the-environment-2.md
@@ -1,4 +1,4 @@
-# Setting Up the Environment
+# Setting Up the Environment
- [Environment Requirements](#section179175261196)
- [Hardware](#section5840424125014)
diff --git a/en/device-dev/quick-start/setting-up-the-environment-3.md b/en/device-dev/quick-start/setting-up-the-environment-3.md
deleted file mode 100644
index 7f27e367398083b4f12aa2f2346b449b73d56109..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-the-environment-3.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# Setting Up the Environment
-
-- [Environment Requirements](#section1724111409282)
- - [Hardware](#section487353718276)
- - [Software Requirements](#section17315193935817)
-
-- [Installing Linux Build Tools](#section8831868501)
- - [Changing Linux Shell to Bash](#section1715027152617)
- - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
- - [Installing a File Packing Tool](#section1686964015274)
- - [Installing hc-gen](#section18706403274)
-
-
-## Environment Requirements
-
-### Hardware
-
-- Hi3518E V300 IoT camera development board
-- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3518E V300 development board through the USB-to-serial cable and network cable.\)
-
- The following figure shows the hardware connections.
-
-
-**Figure 1** Hardware connections
-
-
-### Software Requirements
-
-> **NOTICE:**
->This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section8831868501).
-
-The following table describes the tools required for setting up the general environment for a Linux server of the Hi3518 development board and how to obtain these tools.
-
-**Table 1** Development tools and obtaining methods
-
-
-
Development Tool
-
-
Description
-
-
How to Obtain
-
-
-
-
bash
-
-
Processes CLI commands.
-
-
System configuration
-
-
-
Basic software package for compilation and building (required only for Ubuntu 20+)
-
-
Provides a basic software package for compilation and building.
-
-
Internet
-
-
-
dosfstools, mtools, and mtd-utils
-
-
Pack files.
-
-
apt-get install
-
-
-
-
-
-## Installing Linux Build Tools
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **hc-gen**.
->- \(Recommended\) If you obtain the source code through an image site or a code repository, you should install the compilation tool **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
-
-### Changing Linux Shell to Bash
-
-Check whether bash is used as the shell.
-
-```
-ls -l /bin/sh
-```
-
-If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
-
-**Method 1:** Run the following command on the device and then click **No**.
-
-```
-sudo dpkg-reconfigure dash
-```
-
-**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
-
-```
-sudo rm -rf /bin/sh
-sudo ln -s /bin/bash /bin/sh
-```
-
-### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
-
-Install the software.
-
-```
-sudo apt-get install build-essential && sudo apt-get install gcc && sudo apt-get install g++ && sudo apt-get install make && sudo apt-get install zlib* && sudo apt-get install libffi-dev
-```
-
-### Installing a File Packing Tool
-
-1. Start a Linux server.
-2. Install **dosfstools**.
-
- ```
- sudo apt-get install dosfstools
- ```
-
-3. Install **mtools**.
-
- ```
- sudo apt-get install mtools
- ```
-
-4. Install **mtd-utils**.
-
- ```
- sudo apt-get install mtd-utils
- ```
-
-
-### Installing hc-gen
-
-1. Start a Linux server.
-2. Download [hc-gen](https://repo.huaweicloud.com/harmonyos/compiler/hc-gen/0.65/linux/hc-gen-0.65-linux.tar).
-3. Decompress the hc-gen installation package to **\~/hc-gen** on the Linux server.
-
- ```
- tar -xvf hc-gen-0.65-linux.tar -C ~/
- ```
-
-4. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/hc-gen:$PATH
- ```
-
-5. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-
diff --git a/en/device-dev/quick-start/setting-up-the-environment-4.md b/en/device-dev/quick-start/setting-up-the-environment-4.md
index e8938baf915d5fc9fad719a6c46684307c607d56..606871622b0805662544e092fd9c1e64e4f1cb27 100644
--- a/en/device-dev/quick-start/setting-up-the-environment-4.md
+++ b/en/device-dev/quick-start/setting-up-the-environment-4.md
@@ -1,4 +1,4 @@
-# Setting Up the Environment
+# Setting Up the Environment
- [Environment Requirements](#section1724111409282)
- [Hardware](#section487353718276)
diff --git a/en/device-dev/quick-start/setting-up-the-environment.md b/en/device-dev/quick-start/setting-up-the-environment.md
index 382dc5ac66d2cd78bfb6bd1e307b9a362b1aafee..9eb8b040c6320fb44813778e45d0cfe647623a74 100644
--- a/en/device-dev/quick-start/setting-up-the-environment.md
+++ b/en/device-dev/quick-start/setting-up-the-environment.md
@@ -1,4 +1,4 @@
-# Setting Up the Environment
+# Setting Up the Environment
- [Environment Requirements](#section466851916410)
- [Hardware](#section19202111020215)
@@ -362,6 +362,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/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md
new file mode 100644
index 0000000000000000000000000000000000000000..0a3ca86c3294e3af31e06cd636d3c886c897ce94
--- /dev/null
+++ b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md
@@ -0,0 +1,118 @@
+# Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code
+
+- [Obtaining Standard-System Source Code](#section8761819202511)
+ - [Prerequisites](#section102871547153314)
+ - [Procedure](#section429012478331)
+
+- [Obtaining the Docker Environment](#section181431248132513)
+- [Building Source Code](#section92391739152318)
+
+The standard OpenHarmony system provides a Docker environment which encapsulates build tools.
+
+> **NOTE:**
+>- Before using Docker, install it by following instructions in [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/).
+>- You can also use the [installation package](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md) to set up the Ubuntu development environment.
+
+## Obtaining Standard-System Source Code
+
+### Prerequisites
+
+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.
+
+ ```
+ git config --global user.name "yourname"
+ git config --global user.email "your-email-address"
+ git config --global credential.helper store
+ ```
+
+4. Run the following commands to install the **repo** tool:
+
+ ```
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ chmod a+x /usr/local/bin/repo
+ pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
+ ```
+
+
+### Procedure
+
+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'
+```
+
+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'
+```
+
+## Obtaining the Docker Environment
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+2. Go to the root directory of OpenHarmony 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.1
+ ```
+
+
+**Method 2: Using the Dockerfile to build a local docker image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker/standard
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
+ ```
+
+
+## Building Source Code
+
+1. Run the preprocessing script in the root directory of the source code.
+
+ ```
+ ../scripts/prepare.sh
+ ```
+
+2. Run the following script to start building for Standard-System Devices \(reference memory ≥ 128 MB\):
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
+
+ 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.
+
+3. Burn the image. For details, see [Burning Images](burning-images.md).
+
+> **NOTE:**
+>You can exit Docker by simply running the **exit** command.
+
diff --git a/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md
new file mode 100644
index 0000000000000000000000000000000000000000..0aaa9188a038d1279efdb270e4ffc2ac04ea2273
--- /dev/null
+++ b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md
@@ -0,0 +1,98 @@
+# Setting Up Ubuntu Development Environment with Installation Package and Building Source Code
+
+- [Installing Dependent Tools](#section18431165519244)
+- [Obtaining Standard-System Source Code](#section113751052102517)
+ - [Prerequisites](#section102871547153314)
+ - [Procedure](#section429012478331)
+
+- [Running prebuilts](#section0495320152619)
+- [Building Source Code](#section1664835963517)
+
+## Installing Dependent Tools
+
+The installation command is as follows:
+
+```
+sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gnutls-bin python3.8 python3-pip
+```
+
+> **NOTE:**
+>The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, modify the preceding installation command based on the installation package name.
+
+## Obtaining Standard-System Source Code
+
+### Prerequisites
+
+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.
+
+ ```
+ git config --global user.name "yourname"
+ git config --global user.email "your-email-address"
+ git config --global credential.helper store
+ ```
+
+4. Run the following commands to install the **repo** tool:
+
+ ```
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ chmod a+x /usr/local/bin/repo
+ pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
+ ```
+
+
+### Procedure
+
+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'
+```
+
+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**\).
+
+## Building Source Code
+
+Perform the following operations in the Linux environment:
+
+1. Go to the root directory of the source code and run the following command to build the distribution.
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
+
+2. Check the build result. After the build is complete, the following information is displayed in the log:
+
+ ```
+ build system image successful.
+ =====build Hi3516DV300 successful.
+ ```
+
+ 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.
+
+ > **NOTE:**
+ >For details about module-specific build operations, see [Compilation and Building Overview](../subsystems/building-guidelines-for-the-standard-system.md).
+
+3. Burn the image. For details, see [Burning Images](burning-images.md).
+
diff --git a/en/device-dev/quick-start/windows-development-environment-9.md b/en/device-dev/quick-start/setting-up-windows-development-environment.md
similarity index 99%
rename from en/device-dev/quick-start/windows-development-environment-9.md
rename to en/device-dev/quick-start/setting-up-windows-development-environment.md
index 91c42c4f088d5f467479bb40cd1819e67277cfe4..4308389e169c415c5a502738359d0eed094fd3fc 100644
--- a/en/device-dev/quick-start/windows-development-environment-9.md
+++ b/en/device-dev/quick-start/setting-up-windows-development-environment.md
@@ -1,4 +1,4 @@
-# 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)
diff --git a/en/device-dev/quick-start/standard-system.md b/en/device-dev/quick-start/standard-system.md
index 33f6ed2a876d5ef8f93d7ee22c0546ea37ba9c67..f0aa95fdac24012324baa361c8958305bcfd436f 100644
--- a/en/device-dev/quick-start/standard-system.md
+++ b/en/device-dev/quick-start/standard-system.md
@@ -1,9 +1,15 @@
# Standard System
-- **[Overview](overview-7.md)**
+- **[Introduction](introduction.md)**
-- **[Environment Setup](environment-setup-8.md)**
+- **[Setting Up Windows Development Environment](setting-up-windows-development-environment.md)**
-- **[How to Develop](how-to-develop-12.md)**
+- **[Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md)**
+
+- **[Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md)**
+
+- **[Burning Images](burning-images.md)**
+
+- **[FAQs](faqs-7.md)**
diff --git a/en/device-dev/quick-start/ubuntu-build-environment-10.md b/en/device-dev/quick-start/ubuntu-build-environment-10.md
deleted file mode 100644
index 6b44c27dfc7b0a91a0564f60fd486865db8b242b..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/ubuntu-build-environment-10.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Ubuntu Build Environment
-
-- [Setting up a Ubuntu Build Environment Using a Docker Environment](#section1643363843714)
- - [Obtaining System Source Code](#section58448331029)
- - [Installing and Using the Docker Environment](#section22916211916)
-
-- [Setting up a Ubuntu Build Environment Using an Installation Package](#section25961010189)
- - [Obtaining Standard-System Source Code](#section15424183111912)
- - [Installing Dependent Tools](#section109262032104819)
- - [Obtaining prebuilts](#section16453104219209)
- - [Configuring the Node.js Environment and Obtaining the Node\_modules Dependency Package](#section133741330192119)
- - [Installing the hc-gen Tool](#section149281248182116)
-
-
-You can use either the Docker environment or installation package provided by OpenHarmony to set up a Ubuntu build environment. This section describes the two methods.
-
-## Setting up a Ubuntu Build Environment Using a Docker Environment
-
-The standard OpenHarmony system provides a Docker environment which encapsulates build tools. To use the Docker environment, perform the following steps:
-
-1. Obtain the system source code.
-2. Install and use the Docker environment.
-
-### Obtaining System Source Code
-
-For details, see [Source Code Acquisition](../get-code/source-code-acquisition.md).
-
-### Installing and Using the Docker Environment
-
-For details, see [Installing and Using Docker](../get-code/tool-acquisition.md).
-
-## Setting up a Ubuntu Build Environment Using an Installation Package
-
-The procedure is as follows:
-
-1. Obtain the system source code.
-2. Install dependent tools.
-3. Obtain prebuilts.
-4. Configure the Node.js environment and obtain the Node\_modules dependency package.
-5. Install the hc-gen tool.
-
-### Obtaining Standard-System Source Code
-
-For details, see [Source Code Acquisition](../get-code/source-code-acquisition.md).
-
-### Installing Dependent Tools
-
-The installation command is as follows:
-
-```
-sudo apt-get install binutils git-core git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 python2.7 python-minimal
-```
-
-### Obtaining prebuilts
-
-1. Go to the OpenHarmony working directory.
-
- ```
- cd OpenHarmony
- ```
-
-2. Download the script.
-
- ```
- curl https://gitee.com/landwind/script-tools/raw/master/Shell/OpenHarmony/OpenHarmony_2.0_canary_prebuilts_download.sh >./prebuilts_download.sh
- ```
-
-3. Download and decompress the prebuilts package in a specified directory.
-
- ```
- bash ./prebuilts_download.sh
- ```
-
- By default, binary files are stored in the **OpenHarmony\_2.0\_canary\_prebuilts** directory, which is in the same directory as **OpenHarmony**. To change the storage path, change the value of **bin\_dir** in **prebuilts\_download.sh**.
-
-4. Return to the previous directory.
-
- ```
- cd -
- ```
-
-
-### Configuring the Node.js Environment and Obtaining the Node\_modules Dependency Package
-
-To build the JS framework, you need to download and configure Node.js on a Linux server. The procedure is as follows:
-
-1. Download Node.js on a Linux server.
-
- ```
- mkdir -p OpenHarmony/prebuilts/build-tools/common/nodejs # Create the nodejs directory.
- cd OpenHarmony/prebuilts/build-tools/common/nodejs # Go to the nodejs directory.
- wget --no-check-certificate https://nodejs.org/download/release/v12.18.4/node-v12.18.4-linux-x64.tar.gz # Download the Node.js package.
- ```
-
-2. Decompress the Node.js package and configure the Node.js environment.
-
- ```
- tar -zxvf node-v12.18.4-linux-x64.tar.gz # Decompress the Node.js package.
- echo "export PATH=`pwd`/node-v12.18.4-linux-x64/bin:${PATH}" >> ~/.bashrc;source ~/.bashrc # Set a Node.js environment variable.
- cd - # Return to the previous directory.
- ```
-
-3. Go to the **third\_party/jsframework** directory of the OpenHarmony code and download the **node\_modules** package.
-
- ```
- cd OpenHarmony/third_party/jsframework # Go to the jsframework directory.
- npm install # Download the node_modules package.
- cd - # Return to the previous directory.
- ```
-
-4. Store the **node\_modules** package in the **prebuilts/build-tools/common/js-framework** directory of the OpenHarmony code.
-
- ```
- mkdir -p OpenHarmony/prebuilts/build-tools/common/js-framework # Create the js-framework directory.
- cp -rp OpenHarmony/third_party/jsframework/node_modules OpenHarmony/prebuilts/build-tools/common/js-framework/
- ```
-
-
-### Installing the hc-gen Tool
-
-hc-gen is used to compile the driver. To install hc-gen, perform the following steps:
-
-1. Start a Linux server.
-2. Download [hc-gen](https://repo.huaweicloud.com/harmonyos/compiler/hc-gen/0.65/linux/hc-gen-0.65-linux.tar).
-3. Decompress the hc-gen installation package to **\~/hc-gen** on the Linux server.
-
- ```
- tar -xvf hc-gen-0.65-linux.tar -C ~/
- ```
-
-4. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/hc-gen:$PATH
- ```
-
-5. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-
diff --git a/en/device-dev/quick-start/ubuntu-build-environment.md b/en/device-dev/quick-start/ubuntu-build-environment.md
index 9c141637b5a7efad7834c91138be34c9a648f4f6..57782ef1846c3626ae726276bb36dd66aa163c9b 100644
--- a/en/device-dev/quick-start/ubuntu-build-environment.md
+++ b/en/device-dev/quick-start/ubuntu-build-environment.md
@@ -1,4 +1,4 @@
-# Ubuntu Build Environment
+# Ubuntu Build Environment
- [Obtaining Source Code and Tools](#section1897711811517)
- [Obtaining Source Code](#section1545225464016)
@@ -24,9 +24,9 @@ Perform the following steps to set up the build environment:
6. Install hb.
> **NOTICE:**
->- Docker is provided for the Ubuntu build environment, which encapsulates related build tools. If you use Docker to prepare the build environment, you do not need to perform the following steps in this section. Instead, refer to [Using Docker to Prepare the Build Environment](../get-code/tool-acquisition.md).
+>- Docker is provided for the Ubuntu build environment, which encapsulates related build tools. If you use Docker to prepare the build environment, you do not need to perform the following steps in this section. Instead, refer to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md).
>- By default, basic software, such as Samba and Vim, is installed in the system. Adaptation on the software is required to support file sharing between the Linux server and the Windows workstation.
->- For details about the compilation and building subsystem of OpenHarmony, see the [Compilation and Building Overview](../subsystems/compilation-and-building-overview.md).
+>- For details about the compilation and building subsystem of OpenHarmony, see the [Compilation and Building Overview](../subsystems/compilation-and-building.md).
## Obtaining Source Code and Tools
diff --git a/en/device-dev/quick-start/windows-development-environment-10.md b/en/device-dev/quick-start/windows-development-environment-10.md
deleted file mode 100644
index 91c42c4f088d5f467479bb40cd1819e67277cfe4..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/windows-development-environment-10.md
+++ /dev/null
@@ -1,183 +0,0 @@
-# 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)
-
-Operating system: 64-bit version of Windows 10.
-
-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
-
-> **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, restart the computer for the environment variables of Visual Studio Code to take effect.
-3. 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 xx to PATH**, and click **Install Now**.
-
- 
-
-2. After the installation is complete, click **Close**.
-
- 
-
-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
-
-> **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.
-
- 
-
-
-## Installing hpm
-
-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/cn/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:
-
- ```
- hpm -V
- ```
-
- 
-
-
-## Installing the DevEco Device Tool Plug-in
-
-To install the DevEco Device Tool plug-in, ensure that the **user name of the host cannot contain Chinese characters**; otherwise, the plug-in may fail to run.
-
-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/cn/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. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
-
- 
-
-3. After the installation is complete, the CLT is automatically closed.
-4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
-
- > **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/windows-development-environment.md b/en/device-dev/quick-start/windows-development-environment.md
index 9480f387cd1291caf27824c9edacdadc3f78587d..d0824ce00ea9573806c2a4c75f1df00a2de9aa0e 100644
--- a/en/device-dev/quick-start/windows-development-environment.md
+++ b/en/device-dev/quick-start/windows-development-environment.md
@@ -1,4 +1,4 @@
-# Windows Development Environment
+# Windows Development Environment
- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
@@ -87,7 +87,7 @@ DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedu
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, restart the computer for the environment variables of Visual Studio Code to take effect.
3. Open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
@@ -96,15 +96,15 @@ DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedu
1. Double-click the Python software package, select **Add Python xx to PATH**, and click **Install Now**.
- 
+ 
2. After the installation is complete, click **Close**.
- 
+ 
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:
@@ -123,7 +123,7 @@ DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedu
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.
- 
+ 
## Installing hpm
@@ -147,7 +147,7 @@ and that your network can access the Internet. If your network requires a proxy
npm install -g @ohos/hpm-cli
```
- 
+ 
3. After the installation is complete, run the following command to obtain the installation result:
@@ -155,7 +155,7 @@ and that your network can access the Internet. If your network requires a proxy
hpm -V
```
- 
+ 
## Installing the DevEco Device Tool Plug-in
@@ -170,14 +170,14 @@ DevEco Device Tool will automatically download and install the C/C++ and CodeLLD
1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
2. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
- 
+ 
3. After the installation is complete, the CLT is automatically closed.
-4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
+4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
> **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/wlan-connection.md b/en/device-dev/quick-start/wlan-connection.md
index cc0192a6873b1b66a3224c224b63dab3aabb06ef..6869012b733851e1555efbf1cce23ea5c51f7317 100644
--- a/en/device-dev/quick-start/wlan-connection.md
+++ b/en/device-dev/quick-start/wlan-connection.md
@@ -1,4 +1,4 @@
-# WLAN Connection
+# WLAN Connection
- [Building](#section191121332125319)
- [Burning Images](#section19458165166)
@@ -10,7 +10,7 @@ This example shows how to connect the WLAN module to the gateway using attention
This section describes how to perform the WLAN module building on a Linux server.
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/tool-acquisition.md). If the Linux environment is installed using a software package, perform the following steps:
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, perform the following steps:
1. Open the HUAWEI DevEco Device Tool and choose **View** \> **Terminal**.
@@ -63,39 +63,39 @@ If the Linux environment is installed using Docker, perform the building by refe
You can use the DevEco tool to perform the image burning of the Hi3861 WLAN module. For details about how to use the tool, see [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
-1. Connect the PC and the target development board through the USB port. For details, please refer to [Introduction to the Hi3861 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_wifi_start_des-0000001050168548).
+1. Connect the PC and the target development board through the USB port. For details, please refer to [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.
> **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 Boards](https://device.harmonyos.com/cn/docs/ide/user-guides/hi3861-drivers-0000001058153433).
+ >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3861 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3861-drivers-0000001058153433).
- 
+ 
3. Open DevEco Device Tool and go to **Projects** \> **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.
- - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056563976_li848662117291).
- - **upload\_protocol**: Select the programming protocol **burn-serial**.
- - **upload\_partitions**: Select the file to be programmed. **hi3861\_app** is selected by default.
+ - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001056563976_li848662117291).
+ - **upload\_protocol**: Select the burning protocol **burn-serial**.
+ - **upload\_partitions**: Select the file to be burned. **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.
- 
+ 
8. When the following information is displayed, press the RST button on the development board to restart it.
- 
+ 
-9. Start programming. When the following message is displayed, it indicates that the programming is successful.
+9. Start burning. When the following message is displayed, the burning is successful.
- 
+ 
## Connecting WLAN Module to the Internet.
diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md
index 9c21a040f361f15efc66c5fb965c8fff8de6532b..88e792a04740b935dedc3a7ddbbb1810da26c371 100644
--- a/en/device-dev/subsystems/Readme-EN.md
+++ b/en/device-dev/subsystems/Readme-EN.md
@@ -2,17 +2,15 @@
- [Compilation and Building](compilation-and-building.md)
- [Building Guidelines for Mini and Small Systems](building-guidelines-for-mini-and-small-systems.md)
- - [Compilation and Building Overview](compilation-and-building-overview.md)
- - [Compilation and Building Guidelines](compilation-and-building-guidelines.md)
- - [Compilation and Building FAQ](compilation-and-building-faq.md)
+ - [Compilation and Building](compilation-and-building-0.md)
- [Building Guidelines for the Standard System](building-guidelines-for-the-standard-system.md)
- - [Compilation and Building Overview](compilation-and-building-overview-0.md)
- - [Compilation and Building Guidelines](compilation-and-building-guidelines-1.md)
+ - [Compilation and Building Overview](compilation-and-building-overview.md)
+ - [Compilation and Building Guidelines](compilation-and-building-guidelines.md)
- [Distributed Remote Startup](distributed-remote-startup.md)
- [Graphics](graphics.md)
- - [Graphics](graphics-2.md)
+ - [Graphics](graphics-1.md)
- [Development Guidelines on Container Components](development-guidelines-on-container-components.md)
- [Development Guidelines on Layout Container Components](development-guidelines-on-layout-container-components.md)
- [Development Guidelines on Common Components](development-guidelines-on-common-components.md)
@@ -26,7 +24,7 @@
- [Development Guidelines on Previewing](development-guidelines-on-previewing.md)
- [Audio/Video](audio-video.md)
- - [Overview](overview-3.md)
+ - [Overview](overview-2.md)
- [Development Guidelines on Media Playback](development-guidelines-on-media-playback.md)
- [Development Guidelines on Media Recording](development-guidelines-on-media-recording.md)
@@ -59,21 +57,20 @@
- [Sensors Usage Example](sensors-usage-example.md)
- [Application Framework](application-framework.md)
- - [Overview](overview-4.md)
+ - [Overview](overview-3.md)
- [Setting Up a Development Environment](setting-up-a-development-environment.md)
- - [Development Guidelines](development-guidelines-5.md)
+ - [Development Guidelines](development-guidelines-4.md)
- [Development Example](development-example.md)
- [OTA Upgrade](ota-upgrade.md)
- [Security](security.md)
- - [Overview](overview-9.md)
+ - [Overview](overview-5.md)
- [Development Guidelines on Application Signature Verification](development-guidelines-on-application-signature-verification.md)
- [Development Guidelines on Application Permission Management](development-guidelines-on-application-permission-management.md)
- [Development Guidelines on IPC Authentication](development-guidelines-on-ipc-authentication.md)
- - [Development Guidelines on Trusted Device Group Management](development-guidelines-on-trusted-device-group-management.md)
- [Startup](startup.md)
- - [Startup](startup-10.md)
+ - [Startup](startup-6.md)
- [init Module](init-module.md)
- [appspawn Module](appspawn-module.md)
- [bootstrap Module](bootstrap-module.md)
@@ -83,7 +80,7 @@
- [Testing](testing.md)
- [DFX](dfx.md)
- - [DFX](dfx-11.md)
+ - [DFX](dfx-7.md)
- [Development Guidelines on HiLog ](development-guidelines-on-hilog.md)
- [Development Guidelines on HiLog\_Lite](development-guidelines-on-hilog_lite.md)
- [Development Guidelines on HiSysEvent](development-guidelines-on-hisysevent.md)
@@ -91,6 +88,7 @@
- [R&D Tools](r-d-tools.md)
- [bytrace Usage Guidelines](bytrace-usage-guidelines.md)
- [hdc\_std Usage Guidelines](hdc_std-usage-guidelines.md)
+ - [hdc\_std FAQs](hdc_std-faqs.md)
- [XTS](xts.md)
diff --git a/en/device-dev/subsystems/application-framework.md b/en/device-dev/subsystems/application-framework.md
index d58ed3003a09c0d1e1194097353e454d85afa061..c4973fc34d4cf0058bb54a3de6e3b25b667ef282 100644
--- a/en/device-dev/subsystems/application-framework.md
+++ b/en/device-dev/subsystems/application-framework.md
@@ -1,10 +1,10 @@
# Application Framework
-- **[Overview](overview-4.md)**
+- **[Overview](overview-3.md)**
- **[Setting Up a Development Environment](setting-up-a-development-environment.md)**
-- **[Development Guidelines](development-guidelines-5.md)**
+- **[Development Guidelines](development-guidelines-4.md)**
- **[Development Example](development-example.md)**
diff --git a/en/device-dev/subsystems/audio-video.md b/en/device-dev/subsystems/audio-video.md
index 16e2f5b0835dbade41d9c722ab0ff5de90d93b1f..7942eeb78ebe8c14f38f1076dd5006f81f308625 100644
--- a/en/device-dev/subsystems/audio-video.md
+++ b/en/device-dev/subsystems/audio-video.md
@@ -1,6 +1,6 @@
# Audio/Video
-- **[Overview](overview-3.md)**
+- **[Overview](overview-2.md)**
- **[Development Guidelines on Media Playback](development-guidelines-on-media-playback.md)**
diff --git a/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md b/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md
index d19baae14741babb44e57557e6b94a6e47401d91..cd4f2e3ca87186a59b38cb3136de9eefcc89fb12 100644
--- a/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md
+++ b/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md
@@ -1,9 +1,5 @@
# Building Guidelines for Mini and Small Systems
-- **[Compilation and Building Overview](compilation-and-building-overview.md)**
-
-- **[Compilation and Building Guidelines](compilation-and-building-guidelines.md)**
-
-- **[Compilation and Building FAQ](compilation-and-building-faq.md)**
+- **[Compilation and Building](compilation-and-building-0.md)**
diff --git a/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md b/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md
index bbc92d83896d1912837d2d34b0791a4e47e46004..9e40510e3ec30ac188d72e70130423f6081fe204 100644
--- a/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md
+++ b/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md
@@ -1,7 +1,7 @@
# Building Guidelines for the Standard System
-- **[Compilation and Building Overview](compilation-and-building-overview-0.md)**
+- **[Compilation and Building Overview](compilation-and-building-overview.md)**
-- **[Compilation and Building Guidelines](compilation-and-building-guidelines-1.md)**
+- **[Compilation and Building Guidelines](compilation-and-building-guidelines.md)**
diff --git a/en/device-dev/subsystems/compilation-and-building-0.md b/en/device-dev/subsystems/compilation-and-building-0.md
new file mode 100644
index 0000000000000000000000000000000000000000..b5236f69f98fab5ed637c306aa61d6039a79bcd0
--- /dev/null
+++ b/en/device-dev/subsystems/compilation-and-building-0.md
@@ -0,0 +1,998 @@
+# Compilation and Building
+
+- [Overview](#section10958256161119)
+ - [Basic Concepts](#section1732301411128)
+ - [Directory Structure](#section1588744014121)
+ - [Build Process](#section15761735134)
+
+- [Configuration Rules](#section2345183962710)
+ - [Module](#section142532518308)
+ - [Chipset](#section121501451143710)
+ - [Product](#section134549283435)
+
+- [Usage Guidelines](#section13754457192211)
+ - [Prerequisites](#section31651120233)
+ - [Using hb](#section1133304172313)
+ - [Adding a Module](#section167110415315)
+ - [Adding a Chipset Solution](#section1474718565412)
+ - [Adding a Product Solution](#section1097623294220)
+
+- [Troubleshooting](#section19909721104319)
+ - [Invalid -- w Option](#section138233464318)
+ - [Library ncurses Not Found](#section151033911442)
+ - [mcopy not Found](#section19811838104418)
+ - [No riscv File or Directory](#section03111118451)
+ - [No Crypto](#section69981127125013)
+ - [Unexpected Operator](#section967617530505)
+
+
+## Overview
+
+The Compilation and Building subsystem is a build framework that supports module-based OpenHarmony development using Generate Ninja \(GN\) and Ninja. You can use this subsystem to:
+
+- Assemble modules for a product and build the product.
+
+- Build chipset source code independently.
+- Build a single module independently.
+
+### Basic Concepts
+
+Learn the following concepts before you start compilation and building:
+
+- Subsystem
+
+ A subsystem is a logical concept. It consists of one or more modules. OpenHarmony is designed with a layered architecture, which consists of the kernel layer, system service layer, framework layer, and application layer from bottom to top. System functions are developed by the level of system, subsystem, and module. In a multi-device deployment scenario, you can customize subsystems and modules as required.
+
+
+- Module
+
+ A module is a reusable, configurable, and tailorable function unit. Each module has an independent directory, and multiple modules can be developed concurrently and built and tested independently.
+
+- **GN**
+
+ Generate Ninja \(GN\) is used to generate Ninja files.
+
+- **Ninja**
+
+ Ninja is a small high-speed build system.
+
+- **hb**
+
+ hb is a command line tool for OpenHarmony to execute build commands.
+
+
+### Directory Structure
+
+```
+build/lite
+├── components # Module description file
+├── figures # Figures in the readme file
+├── hb # hb pip installation package
+├── make_rootfs # Script used to create the file system image
+├── config # Build configuration
+│ ├── component # Module-related template definition
+│ ├── kernel # Kernel-related build configuration
+│ └── subsystem # Subsystem build configuration
+├── platform # ld script
+├── testfwk # Test build framework
+└── toolchain # Build toolchain configuration, which contains the compiler directories, build options, and linking options
+```
+
+### **Build Process**
+
+[Figure 1](#fig9744112715161) shows the build process.
+
+**Figure 1** Build process
+
+
+1. Use **hb set **to set the OpenHarmony source code directory and the product to build.
+2. Use **hb build** to build the product, development board, or module. The procedure is as follows:
+ - Read the **config.gni** file of the development board selected. The file contains the build toolchain, linking commands, and build options.
+ - Run the **gn gen** command to read the product configuration and generate the **out** directory and **ninja** files for the solution.
+ - Run **ninja -C out/board/product** to start the build.
+ - Package the build result, set the file attributes and permissions, and create a file system image.
+
+
+## Configuration Rules
+
+To ensure that the chipset and product solutions are pluggable and decoupled from OpenHarmony, the paths, directory trees, and configuration of modules, chipset solutions, and product solutions must comply with the following rules:
+
+### **Module**
+
+The source code directory for a module is named in the _\{Domain\}/\{Subsystem\}/\{Module\}_ format. The module directory tree is as follows:
+
+> **CAUTION:**
+>Define module attributes, such as the name, source code directory, function description, mandatory or not, build targets, RAM, ROM, build outputs, adapted kernels, configurable features, and dependencies, in the JSON file of the subsystem in the **build/lite/components** directory. When adding a module, add its definition to the JSON file of the corresponding subsystem. The module configured for a product must have been defined in a subsystem. Otherwise, the verification will fail.
+
+```
+component
+├── interfaces
+│ ├── innerkits # APIs exposed internally among modules
+│ └── kits # App APIs provided for app developers
+├── frameworks # Framework implementation
+├── services # Service implementation
+└── BUILD.gn # Build script
+```
+
+The following example shows how to define attributes of the sensor module of the pan-sensor subsystem:
+
+```
+{
+ "components": [
+ {
+ "component": "sensor_lite", # Module name
+ "description": "Sensor services", # Brief description of the module
+ "optional": "true", # Whether the module is mandatory for the system
+ "dirs": [ # Source code directory of the module
+ "base/sensors/sensor_lite"
+ ],
+ "targets": [ # Build entry of the module
+ "//base/sensors/sensor_lite/services:sensor_service"
+ ],
+ "rom": "92KB", # Module ROM
+ "ram": "~200KB", # Module RAM (estimated)
+ "output": [ "libsensor_frameworks.so" ], # Module build outputs
+ "adapted_kernel": [ "liteos_a" ], # Adapted kernel for the module
+ "features": [], # Configurable features of the module
+ "deps": {
+ "components": [ # Other modules on which the module depends
+ "samgr_lite",
+ "ipc_lite"
+
+ ],
+ "third_party": [ # Open-source third-party software on which the module depends
+ "bounds_checking_function"
+ ]
+ }
+ }
+ ]
+}
+```
+
+Observe the following rules when building the **BUILD.gn** module:
+
+- The build target name must be the same as the module name.
+- Define the configurable features in the **BUILD.gn** file of the module. Name the configurable features in the **ohos\_**\{_subsystem_\}**\_**\{_module_\}**\_**\{_feature_\} format. Define the features in module description and configure them in the **config.json** file.
+- Define macros in the **OHOS\_**\{_SUBSYSTEM_\}**\_**\{_MODULE_\}**\_**\{_FEATURE_\} format.
+
+ > **NOTE:**
+ >GN is used as the build script language for modules. For details about how to use GN, see the [GN Quick Start Guide](https://gn.googlesource.com/gn/+/master/docs/quick_start.md). In GN, a module is a build target, which can be a static library, a dynamic library, an executable file, or a group.
+
+
+The following example shows how to build the **foundation/graphic/ui/BUILD.gn** file for a graphics UI module:
+
+```
+ # Declare the configurable features of the module
+ declare_args() {
+ enable_ohos_graphic_ui_animator = false # Animation switch
+ ohos_ohos_graphic_ui_font = "vector" # Configurable font type, which can be vector or bitmap
+ }
+
+ # Basic module functions
+ shared_library("base") {
+ sources = [
+ ......
+ ]
+ include_dirs = [
+ ......
+ ]
+ }
+
+ # Build only when the animator is enabled
+ if(enable_ohos_graphic_ui_animator ) {
+ shared_library("animator") {
+ sources = [
+ ......
+ ]
+ include_dirs = [
+ ......
+ ]
+ deps = [ :base ]
+ }
+ }
+ ......
+ # It is recommended that the target name be the same as the module name, which can be an executable .bin file, shared_library (.so file), static_library (.a file), or a group.
+ executable("ui") {
+ deps = [
+ ":base"
+ ]
+
+ # The animator feature is configured by the product.
+ if(enable_ohos_graphic_ui_animator ) {
+ deps += [
+ "animator"
+ ]
+ }
+ }
+```
+
+### **Chipset**
+
+- The chipset solution is a complete solution based on a development board. The solution includes the drivers, API adaptation, and SDK.
+- The chipset solution is a special module, whose source code directory is named in the _**device**/\{Chipset solution vendor\}/\{Development board\}_ format.
+- The chipset solution module is built by default based on the development board selected by the product.
+
+The chipset solution directory tree is as follows:
+
+```
+device
+└── company # Chipset solution vendor
+ └── board # Name of the development board
+ ├── BUILD.gn # Build script
+ ├── hals # Southbound APIs for OS adaptation
+ ├── linux # Linux kernel version (optional)
+ │ └── config.gni # Build options for the Linux version
+ └── liteos_a # LiteOS kernel version (optional)
+ └── config.gni # Build options for the LiteOS Cortex-A version
+```
+
+> **NOTE:**
+>The **config.gni** file contains build-related configurations of the development board. The parameters in the file are globally visible to the system and can be used to build all OS modules during the build process.
+
+The **config.gni** file contains the following key parameters:
+
+```
+kernel_type: kernel used by the development board, for example, liteos_a, liteos_m, or linux.
+kernel_version: kernel version used by the development board, for example, 4.19.
+board_cpu: CPU of the development board, for example, cortex-a7 or riscv32.
+board_arch: chipset architecture of the development board, for example, armv7-a or rv32imac.
+board_toolchain: name of the customized build toolchain used by the development board, for example, gcc-arm-none-eabi. If this field is not specified, ohos-clang will be used by default.
+board_toolchain_prefix: prefix of the build toolchain, for example, gcc-arm-none-eabi.
+board_toolchain_type: build toolchain type, for example, gcc or clang. Currently, only GCC and clang are supported.
+board_cflags: build options of the .c file configured for the development board.
+board_cxx_flags: build options of the .cpp file configured for the development board.
+board_ld_flags: link options configured for the development board.
+```
+
+### **Product**
+
+The product solution is a complete product based on a development board. It includes the OS adaptation, module assembly configuration, startup configuration, and file system configuration. The source code directory of a product solution is named in the **vendor**/\{_Product solution vendor_\}/\{_Product name_\} format. A product solution is also a special module.
+
+The product solution directory tree is as follows:
+
+```
+vendor
+└── company # Product solution vendor
+ ├── product # Product name
+ │ ├── init_configs
+ │ │ ├── etc # Startup configuration of the init process (only required for the Linux kernel)
+ │ │ └── init.cfg # System service startup configuration
+ │ ├── hals # OS adaptation
+ │ ├── BUILD.gn # Product build script
+ │ └── config.json # Product configuration file
+ │ └── fs.yml # File system packaging configuration
+ └── ......
+```
+
+> **CAUTION:**
+>Create directories and files based on the preceding rules for new products. The Compilation and Building subsystem scans the configured products based on the rules.
+
+The key directories and files are described as follows:
+
+1. **vendor/company/product/init\_configs/etc**
+
+ This folder contains the **rcS**, **S**_xxx_, and **fstab** scripts. The **init** process runs the **rcS**, **fstab**, and **S**_00_-_xxx_ scripts in sequence before starting system services. The **S**_xxx_ script contains content related to the development board and product. It is used to create device nodes and directories, scan device nodes, and change file permissions. These scripts are copied from the **BUILD.gn** file to the **out** directory of the product as required and packaged into the **rootfs** image.
+
+2. **vendor/company/product/init\_configs/init.cfg**
+
+ This file is the configuration file for the **init** process to start services. Currently, the following commands are supported:
+
+ - **start**: starts a service.
+ - **mkdir**: creates a folder.
+ - **chmod**: changes the permission on a specified directory or file.
+ - **chown**: changes the owner group of a specified directory or file.
+ - **mount**: mounts a device.
+
+ The fields in the file are described as follows:
+
+ ```
+ {
+ "jobs" : [{ # Job array. A job corresponds to a command set. Jobs are executed in the following sequence: pre-init > init > post-init.
+ "name" : "pre-init",
+ "cmds" : [
+ "mkdir /storage/data", # Create a directory.
+ "chmod 0755 /storage/data", # Change the permission, which is in 0xxx format, for example, 0755.
+ "mkdir /storage/data/log",
+ "chmod 0755 /storage/data/log",
+ "chown 4 4 /storage/data/log", # Change the owner group. The first number indicates the UID, and the second indicates the GID.
+ ......
+ "mount vfat /dev/mmcblock0 /sdcard rw, umask=000" # The command is in the mount [File system type][source] [target] [flags] [data] format.
+ # Currently, flags can only be nodev, noexec, nosuid, or rdonly.
+ ]
+ }, {
+ "name" : "init",
+ "cmds" : [ # Start services based on the sequence of the cmds array.
+ "start shell", # Note that there is only one space between start and the service name.
+ ......
+ "start service1"
+ ]
+ }, {
+ "name" : "post-init", # Job that is finally executed. Operations performed after the init process is started, for example, mounting a device after the driver initialization.
+ "cmds" : []
+ }
+ ],
+ "services" : [{ # Service array. A service corresponds to a process.
+ "name" : "shell", # Service name
+ "path" : ["/sbin/getty", "-n", "-l", "/bin/sh", "-L", "115200", "ttyS000", "vt100"], # Full path of the executable file. It must start with "path".
+ "uid" : 0, # Process UID, which must be the same as that in the binary file.
+ "gid" : 0, # Process GID, which must be the same as that in the binary file.
+ "once" : 0, # Whether the process is a one-off process. 1: The proces is a one-off process. The init process does not restart it after the process exits. 0: The process is not a one-off process. The init process restarts it if the process exits.
+ "importance" : 0, # Whether the process is a key process. 1: The process is a key process. If it exits, the init process restarts the board. 0: The process is not a key process. If it exits, the init process does not restart the board.
+ "caps" : [4294967295]
+ },
+ ......
+ ]
+ }
+ ```
+
+3. **vendor/company/product/init\_configs/hals**
+
+ This file stores the content related to OS adaptation of the product. For details about APIs for implementing OS adaptation, see the readme file of each module.
+
+4. **vendor/company/product/config.json**
+
+ The **config.json** file is the main entry for the build and contains configurations of the development board, OS modules, and kernel.
+
+ The following example shows the **config.json** file of the IP camera developed based on the hispark\_taurus development board:
+
+ ```
+ {
+ "product_name": "ipcamera", # Product name
+ "ohos_version": "OpenHarmony 1.0", # OS version
+ "device_company": "hisilicon", # Chipset vendor
+ "board": "hispark_taurus", # Name of the development board
+ "kernel_type": "liteos_a", # Kernel type
+ "kernel_version": "3.0.0", # Kernel version
+ "subsystems": [
+ {
+ "subsystem": "aafwk", # Subsystem
+ "components": [
+ { "component": "ability", "features":[ "enable_ohos_appexecfwk_feature_ability = true" ] } # Module and its features
+ ]
+ },
+ {
+ ......
+ }
+ ......
+ More subsystems and modules
+ }
+ }
+ ```
+
+5. **vendor/company/product/fs.yml**
+
+ This file packages the build result to create a configuration file system image, for example, **rootfs.img** \(user-space root file system\) and **userfs.img** \(readable and writable file\). It consists of multiple lists, and each list corresponds to a file system. The fields are described as follows:
+
+ ```
+ fs_dir_name: (Mandatory) declares the name of the file system, for example, rootfs or userfs.
+ fs_dirs: (Optional) configures the mapping between the file directory in the out directory and the system file directory. Each file directory corresponds to a list.
+ source_dir: (Optional) specifies the target file directory in the out directory. If this field is missing, an empty directory will be created in the file system based on target_dir.
+ target_dir: (Mandatory) specifies the corresponding file directory in the file system.
+ ignore_files: (Optional) declares ignored files during the copy operation.
+ dir_mode: (Optional) specifies the file directory permission, which is set to 755 by default.
+ file_mode: (Optional) declares permissions of all files in the directory, which is set to 555 by default.
+ fs_filemode: (Optional) configures files that require special permissions. Each file corresponds to a list.
+ file_dir: (Mandatory) specifies the detailed file path in the file system.
+ file_mode: (Mandatory) declares file permissions.
+ fs_symlink: (Optional) configures the soft link of the file system.
+ fs_make_cmd: (Mandatory) creates the file system script. The script provided by the OS is stored in the build/lite/make_rootfs directory. Linux, LiteOS, ext4, jffs2, and vfat are supported. Chipset vendors can also customize the script as required.
+ fs_attr: (Optional) dynamically adjusts the file system based on configuration items.
+ ```
+
+ The **fs\_symlink** and **fs\_make\_cmd** fields support the following variables:
+
+ - $\{root\_path\}
+
+ Code root directory, which corresponds to **$\{ohos\_root\_path\}** of GN
+
+ - $\{out\_path\}
+
+ **out** directory of the product, which corresponds to **$\{root\_out\_dir\}** of GN
+
+ - $\{fs\_dir\}
+
+ File system directory, which consists of the following variables
+
+ - $\{root\_path\}
+ - $\{fs\_dir\_name\}
+
+
+ > **NOTE:**
+ >**fs.yml** is optional and does not need to be configured for devices without a file system.
+
+6. **vendor/company/product/BUILD.gn**
+
+ This file is the entry for building the source code of the solution vendor and copying the startup configuration file. The **BUILD.gn** file in the corresponding product directory will be built by default if a product is selected. The following example shows how to build the **BUILD.gn** file of a product:
+
+ ```
+ group("product") { # The target name must be the same as the product name (level-3 directory name under the product directory).
+ deps = []
+ # Copy the init configuration.
+ deps += [ "init_configs" ]
+ # Others
+ ......
+ }
+ ```
+
+
+## Usage Guidelines
+
+### Prerequisites
+
+The development environment has GN, Ninja, Python 3.7.4 or later, and hb available. For details about installation methods, see [Basic OS Environment Setup](../quick-start/environment-setup.md).
+
+### Using hb
+
+**hb** is a command line tool for OpenHarmony to execute build commands. Common hb commands are described as follows:
+
+**hb set**
+
+```
+hb set -h
+usage: hb set [-h] [-root [ROOT_PATH]] [-p]
+
+optional arguments:
+ -h, --help show this help message and exit
+ -root [ROOT_PATH], --root_path [ROOT_PATH]
+ Set OHOS root path
+ -p, --product Set OHOS board and kernel
+```
+
+- **hb set** \(without argument\): starts the default setting process.
+- **hb set -root** _dir_: sets the root directory of the code.
+- **hb set -p**: sets the product to build.
+
+**hb env**
+
+Displays the current configuration.
+
+```
+hb env
+[OHOS INFO] root path: xxx
+[OHOS INFO] board: hispark_taurus
+[OHOS INFO] kernel: liteos
+[OHOS INFO] product: ipcamera
+[OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
+[OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
+```
+
+**hb build**
+
+```
+hb build -h
+usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
+ [--dmverity] [--tee] [-p PRODUCT] [-f] [-n]
+ [-T [TARGET [TARGET ...]]] [-v] [-shs] [--patch]
+ [component [component ...]]
+
+positional arguments:
+ component name of the component
+
+optional arguments:
+ -h, --help show this help message and exit
+ -b BUILD_TYPE, --build_type BUILD_TYPE
+ release or debug version
+ -c COMPILER, --compiler COMPILER
+ specify compiler
+ -t [TEST [TEST ...]], --test [TEST [TEST ...]]
+ compile test suit
+ --dmverity Enable dmverity
+ --tee Enable tee
+ -p PRODUCT, --product PRODUCT
+ build a specified product with
+ {product_name}@{company}, eg: camera@huawei
+ -f, --full full code compilation
+ -n, --ndk compile ndk
+ -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
+ Compile single target
+ -v, --verbose show all command lines while building
+ -shs, --sign_haps_by_server
+ sign haps by server
+ --patch apply product patch before compiling
+
+ --dmverity Enable dmverity
+ -p PRODUCT, --product PRODUCT
+ build a specified product with
+ {product_name}@{company}, eg: ipcamera@hisilcon
+ -f, --full full code compilation
+ -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
+ Compile single target
+```
+
+- **hb build** \(without argument\): builds the code based on the configured code directory, product, and options. The **-f** option deletes all products to be built, which is equivalent to running **hb clean** and **hb build**.
+- **hb build** _\{module\_name\}_: builds a product module separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
+- **hb build -p ipcamera@hisilicon**: skips the **set** step and builds the product directly.
+- You can run **hb build** in **device/device\_company/board** to select the kernel and start the build based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
+
+**hb clean**
+
+You can run **hb clean** to clear the build result of the product in the **out** directory and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/xxx/xxx**.
+
+```
+hb clean
+usage: hb clean [-h] [out_path]
+
+positional arguments:
+ out_path clean a specified path.
+
+optional arguments:
+ -h, --help show this help message and exit
+```
+
+### Adding a Module
+
+To add a module, determine the subsystem to which the module belongs and the module name, and then perform the following steps:
+
+1. Add the module build script after the source code development is complete.
+
+ The following example adds the **BUILD.gn** script \(stored in the **applications/sample/hello\_world** directory\) to build the **hello\_world** module \(as an executable file\).
+
+ ```
+ executable("hello_world") {
+ include_dirs = [
+ "include",
+ ]
+ sources = [
+ "src/hello_world.c"
+ ]
+ }
+ ```
+
+ The above script is used to build **hello\_world** that can run on OpenHarmony.
+
+ To build the preceding module separately, select a product via the **hb set** command and run the **-T** command.
+
+ ```
+ hb build -f -T //applications/sample/hello_world
+ ```
+
+ After the module functions are verified on the development board, perform steps [2 to 4](#li11471037297) to configure the module to the product.
+
+2. Add module description.
+
+ The module description is stored in the **build/lite/components** directory. New modules must be added to the JSON file of the corresponding subsystem. The module description must contain the following fields:
+
+ - **module**: name of the module
+ - **description**: brief description of the module
+ - **optional**: whether the module is optional
+ - **dirs**: source code directory of the module
+ - **targets**: module build entry
+
+ For example, to add the **hello\_world** module to the application subsystem, add the **hello\_world** object to the **applications.json** file.
+
+ ```
+ {
+ "components": [
+ {
+ "component": "hello_world",
+ "description": "Hello world.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/hello_world"
+ ],
+ "targets": [
+ "//applications/sample/hello_world"
+ ]
+ },
+ ...
+ ]
+ }
+ ```
+
+3. Configure the module for the product.
+
+ The **config.json** file is stored in the **vendor/company/product/** directory. The file must contain the product name, OpenHarmony version, device vendor, development board, kernel type, kernel version, and the subsystem and module to configure. The following example adds the **hello\_world** module to the **my\_product.json** configuration file:
+
+ ```
+ {
+ "product_name": "hello_world_test",
+ "ohos_version": "OpenHarmony 1.0",
+ "device_company": "hisilicon",
+ "board": "hispark_taurus",
+ "kernel_type": "liteos_a",
+ "kernel_version": "1.0.0",
+ "subsystems": [
+ {
+ "subsystem": "applications",
+ "components": [
+ { "component": "hello_world", "features":[] }
+ ]
+ },
+ ...
+ ]
+ }
+ ```
+
+4. Build the product.
+
+ 1. Run the **hb set** command in the root code directory and select the product.
+
+ 2. Run the **hb build** command.
+
+
+### Adding a Chipset Solution
+
+The following uses the RTL8720 development board provided by Realtek as an example. To a chipset solution, perform the following steps:
+
+1. Create a directory for the chipset solution.
+
+ To create a directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](#section1625463413327), run the following command in the root code directory:
+
+ ```
+ mkdir -p device/realtek/rtl8720
+ ```
+
+2. Create a directory for kernel adaptation and build the **config.gni** file of the development board.
+
+ For example, to adapt the LiteOS Cortex-M kernel to the RTL8720 development board, configure the **device/realtek/rtl8720/liteos\_a/config.gni** file as follows:
+
+ ```
+ # Kernel type, e.g. "linux", "liteos_a", "liteos_m".
+ kernel_type = "liteos_a"
+
+ # Kernel version.
+ kernel_version = "3.0.0"
+
+ # Board CPU type, e.g. "cortex-a7", "riscv32".
+ board_cpu = "real-m300"
+
+ # Board arch, e.g. "armv7-a", "rv32imac".
+ board_arch = ""
+
+ # Toolchain name used for system compiling.
+ # E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
+ # Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
+ board_toolchain = "gcc-arm-none-eabi"
+
+ # The toolchain path instatlled, it's not mandatory if you have added toolchian path to your ~/.bashrc.
+ board_toolchain_path =
+ rebase_path("//prebuilts/gcc/linux-x86/arm/gcc-arm-none-eabi/bin",
+ root_build_dir)
+
+ # Compiler prefix.
+ board_toolchain_prefix = "gcc-arm-none-eabi-"
+
+ # Compiler type, "gcc" or "clang".
+ board_toolchain_type = "gcc"
+
+ # Board related common compile flags.
+ board_cflags = []
+ board_cxx_flags = []
+ board_ld_flags = []
+ ```
+
+3. Build the script.
+
+ Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. The content in the **device/realtek/rtl8720/BUILD.gn** file is configured as follows:
+
+ ```
+ group("rtl8720") { # The target can be shared_library, static_library, or an executable file.
+ # Content
+ ......
+ }
+ ```
+
+4. Build the chipset solution.
+
+ Run the **hb build** command in the development board directory to start the build.
+
+
+### Adding a Product Solution
+
+You can use the Compilation and Building subsystem to customize product solutions by assembling chipset solutions and modules. The procedure is as follows:
+
+1. Create a product directory.
+
+ The following uses the Wi-Fi IoT module on the RTL8720 development board as an example. Run the following command in the root code directory to create a product directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](#section1625463413327):
+
+ ```
+ mkdir -p vendor/my_company/wifiiot
+ ```
+
+2. Assemble the product.
+
+ Create the **config.json** file in the product directory. The **vendor/my\_company/wifiiot/config.json** file is as follows:
+
+ ```
+ {
+ "product_name": "wifiiot", # Product name
+ "ohos_version": "OpenHarmony 1.0", # OS version
+ "device_company": "realtek", # Name of the chipset solution vendor
+ "board": "rtl8720", # Name of the development board
+ "kernel_type": "liteos_m", # Kernel type
+ "kernel_version": "3.0.0", # Kernel version
+ "subsystems": [
+ {
+ "subsystem": "kernel", # Subsystem
+ "components": [
+ { "component": "liteos_m", "features":[] } # Module and its features
+ ]
+ },
+ ...
+ {
+ More subsystems and modules
+ }
+ ]
+ }
+ ```
+
+ Before the build, the Compilation and Building subsystem checks the validity of fields, including **device\_company**, **board**, **kernel\_type**, **kernel\_version**, **subsystem**, and **component**. The **device\_company**, **board**, **kernel\_type**, and **kernel\_version** fields must match the current chipset solution, and **subsystem** and **component** must match the module description in the **build/lite/components** file.
+
+3. Implement adaptation to OS APIs.
+
+ Create the **hals** directory in the product directory and store the source code as well as the build script for OS adaptation in this directory.
+
+4. Configure the system service.
+
+ Create the **init\_configs** directory in the product directory and then the **init.cfg** file in the newly created directory. Configure the system service to be started.
+
+5. \(Optional\) Configure the init process only for the Linux kernel.
+
+ Create the **etc** directory in the **init\_configs** directory, and then the **init.d** folder and the **fstab** file in the newly created directory. Then, create the **rcS** and **S**_xxx_ files in the **init.d** file and edit them based on product requirements.
+
+6. \(Optional\) Configure the file system image only for the development board that supports the file system.
+
+ Create the **fs.yml** file in the product directory and configure it as required. A typical **fs.yml** file is as follows:
+
+ ```
+ -
+ fs_dir_name: rootfs # Image name
+ fs_dirs:
+ -
+ # Copy the files in the out/my_board/my_product/bin directory to the rootfs/bin directory and ignore the .bin files related to testing.
+ source_dir: bin
+ target_dir: bin
+ ignore_files:
+ - Test.bin
+ - TestSuite.bin
+ -
+ # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the file permissions to 644 and folder permissions 755.
+ source_dir: libs
+ target_dir: lib
+ ignore_files:
+ - .a
+ dir_mode: 755
+ file_mode: 644
+ -
+ source_dir: usr/lib
+ target_dir: usr/lib
+ ignore_files:
+ - .a
+ dir_mode: 755
+ file_mode: 644
+ -
+ source_dir: config
+ target_dir: etc
+ -
+ source_dir: system
+ target_dir: system
+ -
+ source_dir: sbin
+ target_dir: sbin
+ -
+ source_dir: usr/bin
+ target_dir: usr/bin
+ -
+ source_dir: usr/sbin
+ target_dir: usr/sbin
+ -
+ # Create an empty proc directory.
+ target_dir: proc
+ -
+ target_dir: mnt
+ -
+ target_dir: opt
+ -
+ target_dir: tmp
+ -
+ target_dir: var
+ -
+ target_dir: sys
+ -
+ source_dir: etc
+ target_dir: etc
+ -
+ source_dir: vendor
+ target_dir: vendor
+ -
+ target_dir: storage
+
+ fs_filemode:
+ -
+ file_dir: lib/ld-uClibc-0.9.33.2.so
+ file_mode: 555
+ -
+ file_dir: lib/ld-2.24.so
+ file_mode: 555
+ -
+ file_dir: etc/init.cfg
+ file_mode: 400
+ fs_symlink:
+ -
+ # Create the soft link ld-musl-arm.so.1 -> libc.so in the rootfs/lib directory.
+ source: libc.so
+ link_name: ${fs_dir}/lib/ld-musl-arm.so.1
+ -
+ source: mksh
+ link_name: ${fs_dir}/bin/sh
+ -
+ source: mksh
+ link_name: ${fs_dir}/bin/shell
+ fs_make_cmd:
+ # Create an ext4 image for the rootfs directory using the script.
+ - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
+ -
+ fs_dir_name: userfs
+ fs_dirs:
+ -
+ source_dir: storage/etc
+ target_dir: etc
+ -
+ source_dir: data
+ target_dir: data
+ fs_make_cmd:
+ - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
+
+ ```
+
+7. \(Optional\) Configure patches if the product and modules need to be patched.
+
+ Create the **patch.yml** file in the product directory and configure it as required. A typical **patch.yml** file is as follows:
+
+ ```
+ # Directory in which the patch is to be installed
+ foundation/communication/dsoftbus:
+ # Directory in which the patch is stored
+ - foundation/communication/dsoftbus/1.patch
+ - foundation/communication/dsoftbus/2.patch
+ third_party/wpa_supplicant:
+ - third_party/wpa_supplicant/1.patch
+ - third_party/wpa_supplicant/2.patch
+ - third_party/wpa_supplicant/3.patch
+ ...
+ ```
+
+ If you add **--patch** when running the **hb build** command, the patch file can be added to the specified directory before the build.
+
+ ```
+ hb build -f --patch
+ ```
+
+8. Build the script.
+
+ Create the **BUILD.gn** file in the product directory and write the script. The following **BUILD.gn** file uses the Wi-Fi IoT module in [1](#li1970321162111) as an example:
+
+ ```
+ group("wifiiot") { # The target name must be the same as the product name.
+ deps = []
+ # Copy the init configuration.
+ deps += [ "init_configs" ]
+ # Build the hals directory.
+ deps += [ "hals" ]
+ # Others
+ ......
+ }
+ ```
+
+9. Build the product.
+
+ Run the **hb set** command in the code root directory, select the new product as prompted, and run the **hb build** command.
+
+
+## Troubleshooting
+
+### Invalid -- w Option
+
+- **Symptom**
+
+ The build fails, and "usr/sbin/ninja: invalid option -- w" is displayed.
+
+- **Cause**
+
+ The Ninja version in the build environment is outdated and does not support the **--w** option.
+
+- **Solution**
+
+ Uninstall Ninja and GN and follow the instructions provided in [Acquiring Tools](../get-code/tool-acquisition.md) to install Ninja and GN of the required version.
+
+
+### Library ncurses Not Found
+
+- **Symptom**
+
+ The build fails, and "/usr/bin/ld: cannot find -lncurses" is displayed.
+
+- **Cause**
+
+ The ncurses library is not installed.
+
+- **Solution**
+
+ ```
+ sudo apt-get install lib32ncurses5-dev
+ ```
+
+
+### mcopy not Found
+
+- **Symptom**
+
+ The build fails, and "line 77: mcopy: command not found" is displayed.
+
+- **Cause**
+
+ mcopy is not installed.
+
+- **Solution**
+
+ ```
+ sudo apt-get install dosfstools mtools
+ ```
+
+
+### No riscv File or Directory
+
+- **Symptom**
+
+ The build fails, and the following information is displayed:
+
+ riscv32-unknown-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory.
+
+- **Cause**
+
+ Permission is required to access files in the **riscv** compiler directory.
+
+- **Solution**
+
+ Run the following command to query the directory where **gcc\_riscv32** is located:
+
+ ```
+ which riscv32-unknown-elf-gcc
+ ```
+
+ Run the **chmod** command to change the directory permission to **755**.
+
+
+### No Crypto
+
+- **Symptom**
+
+ The build fails, and "No module named 'Crypto'" is displayed.
+
+- **Cause**
+
+ Crypto is not installed in Python 3.
+
+- **Solution**
+ 1. Run the following command to query the Python version:
+
+ ```
+ python3 --version
+ ```
+
+ 2. Ensure that Python 3.7 or later is installed, and then run the following command to install pycryptodome:
+
+ ```
+ sudo pip3 install pycryptodome
+ ```
+
+
+
+### Unexpected Operator
+
+- **Symptom**
+
+ The build fails, and "xx.sh \[: xx unexpected operator" is displayed.
+
+- **Cause**
+
+ The build environment is shell, not bash.
+
+- **Solution**
+
+ ```
+ sudo rm -rf /bin/sh
+ sudo ln -s /bin/bash /bin/sh
+ ```
+
+
diff --git a/en/device-dev/subsystems/compilation-and-building-faq.md b/en/device-dev/subsystems/compilation-and-building-faq.md
deleted file mode 100644
index 7c90a77cafe15b19f2bdcfbbc9d976158b83be9c..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-faq.md
+++ /dev/null
@@ -1,121 +0,0 @@
-# Compilation and Building FAQ
-
-- [Invalid -- w option](#section1019152312222)
-- [Ncurses library not found](#section21449422618)
-- [Mcopy not found](#section12477184992615)
-- [No riscv file or directory](#section178451337202716)
-- [No Crypto](#section1241481172819)
-- [Unexpected operator](#section3691222152919)
-
-## Invalid -- w option
-
-- **Problem**
-
- The compilation fails, and **usr/sbin/ninja: invalid option -- w** is displayed.
-
-- **Cause**
-
- The Ninja version in the compilation environment is outdated and does not support the **--w** option.
-
-- **Solution**
-
- Uninstall Ninja and GN and follow the instructions provided in [Acquiring Tools](../get-code/tool-acquisition.md) to obtain the provided compilation toolchain.
-
-
-## Ncurses library not found
-
-- **Problem**
-
- The compilation fails, and **/usr/bin/ld: cannot find -lncurses** is displayed.
-
-- **Cause**
-
- The ncurses library is not installed.
-
-- **Solution**
-
- ```
- sudo apt-get install lib32ncurses5-dev
- ```
-
-
-## Mcopy not found
-
-- **Problem**
-
- The compilation fails, and **line 77: mcopy: command not found** is displayed.
-
-- **Cause**
-
- Mcopy is not installed.
-
-- **Solution**
-
- ```
- sudo apt-get install dosfstools mtools
- ```
-
-
-## No riscv file or directory
-
-- **Problem**
-
- The compilation fails, and the following information is displayed: **riscv32-unknown-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory**.
-
-- **Cause**
-
- Permission is required to access files in the **riscv** compiler path.
-
-- **Solution**
- 1. Run the following command to query the directory where **gcc\_riscv32** is located:
-
- ```
- which riscv32-unknown-elf-gcc
- ```
-
- 2. Run the **chmod** command to change the directory permission to **755**.
-
-
-## No Crypto
-
-- **Problem**
-
- The compilation fails, and **No module named'Crypto loaded** is displayed.
-
-- **Cause**
-
- Crypto is not installed in Python 3.
-
-- **Solution**
- 1. Run the following command to query the Python version:
-
- ```
- python3 --version
- ```
-
- 2. Ensure that Python 3.7 or later is installed, and then run the following command to install pycryptodome:
-
- ```
- sudo pip3 install pycryptodome
- ```
-
-
-
-## Unexpected operator
-
-- **Problem**
-
- The compilation fails, and **xx.sh \[: xx unexpected operator** is displayed.
-
-- **Cause**
-
- The compilation environment is shell instead of bash.
-
-- **Solution**
-
- ```
- sudo rm -rf /bin/sh
- sudo ln -s /bin/bash /bin/sh
- ```
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-guidelines-1.md b/en/device-dev/subsystems/compilation-and-building-guidelines-1.md
deleted file mode 100644
index eddc2c96aaefe399e0c46c7d47eb3810ab59f67a..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-guidelines-1.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# Compilation and Building Guidelines
-
-- [Directory Structure](#section56731811102915)
-- [Building](#section1069873833818)
- - [Build Command](#section2740182614395)
-
-- [How to Develop](#section4207112818418)
-
-## Directory Structure
-
-```
-/build # Primary directory
-├── config # Build configuration items
-├── core
-│ └── gn # Build entry configuration
-├── loader # Loader of module configuration, which also generates a template for the module
-├── ohos # Configuration of the process for building and packaging OpenHarmony
-│ ├── kits # Build and packaging templates and processing flow for kits
-│ ├── ndk # NDK template and processing flow
-│ ├── notice # Notice template and processing flow
-│ ├── packages # Distribution packaging template and processing flow
-│ ├── sa_profile # SA template and processing flow
-│ ├── sdk # SDK template and processing flow, which contains the module configuration in the SDK
-│ └── testfwk # Processing flow related to the test
-├── scripts # Build-related Python script
-├── templates # C/C++ build templates
-└── toolchain # Toolchain configuration
-```
-
-## Building
-
-### Build Command
-
-- Run the following command in the root directory of the source code to build the full distribution:
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the product supported by the current distribution, for example, Hi3516D V300.
-
- The image generated after build is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
-
-- The build command supports the following options:
-
- ```
- --product-name # (Mandatory) Name of the product to build, for example, Hi3516D V300
- --build-target # (Optional) One or more build targets
- --gn-args # (Optional) One or more gn parameters
- --ccache # (Optional) Use of Ccache for build. This option takes effect only when Ccache is installed on the local PC.
- ```
-
-
-## How to Develop
-
-1. Add a module.
-
- The following steps use a custom module as an example to describe how to build the module, including build a library, an executable file, and a configuration file.
-
- The example module **partA** consists of **feature1**, **feature2**, and **feature3**. The target of **feature1** is a dynamic library, that of **feature2** is an executable file, and that of **feature3** is an etc configuration file.
-
- Add **partA** to a subsystem, for example, **subsystem\_examples** \(defined in the **test/examples/** directory\).
-
- The complete directory structure of **partA** is as follows:
-
- ```
- test/examples/partA
- ├── feature1
- │ ├── BUILD.gn
- │ ├── include
- │ │ └── helloworld1.h
- │ └── src
- │ └── helloworld1.cpp
- ├── feature2
- │ ├── BUILD.gn
- │ ├── include
- │ │ └── helloworld2.h
- │ └── src
- │ └── helloworld2.cpp
- └── feature3
- ├── BUILD.gn
- └── src
- └── config.conf
- ```
-
- Example 1: GN script \(**test/examples/partA/feature1/BUILD.gn**\) for building a dynamic library
-
- ```
- config("helloworld_lib_config") {
- include_dirs = [ "include" ]
- }
-
- ohos_shared_library("helloworld_lib") {
- sources = [
- "include/helloworld1.h",
- "src/helloworld1.cpp",
- ]
- public_configs = [ ":helloworld_lib_config" ]
- part_name = "partA"
- }
- ```
-
- Example 2: GN script \(**test/examples/partA/feature2/BUILD.gn**\) for building an executable file
-
- ```
- ohos_executable("helloworld_bin") {
- sources = [
- "src/helloworld2.cpp"
- ]
- include_dirs = [ "include" ]
- deps = [ # Dependent submodule
- "../feature1:helloworld_lib"
- ]
- external_deps = [ "partB:module1" ] # (Optional) If there is a cross-module dependency, the format is "module name: submodule name"
- install_enable = true # By default, the executable file is not installed. You need to set this parameter to true for installation.
- part_name = "partA"
- }
- ```
-
- Example 3: GN script \(**test/examples/partA/feature3/BUILD.gn**\) for building the etc configuration file \(submodule\).
-
- ```
- ohos_prebuilt_etc("feature3_etc") {
- source = "src/config.conf"
- relative_install_dir = "init" # (Optional) Directory for installing the submodule, which is relative to the default installation directory (/system/etc)
- part_name = "partA"
- }
- ```
-
- Example 4: Adding the module configuration file **test/examples/ohos.build** to the **ohos.build** file of this subsystem. Each subsystem has an **ohos.build** file in its root directory.
-
- ```
- "partA": {
- "module_list": [
- "//test/examples/partA/feature1:helloworld_lib",
- "//test/examples/partA/feature2:helloworld_bin",
- "//test/examples/partA/feature3:feature3_etc",
- ],
- "inner_kits": [
-
- ],
- "system_kits": [
-
- ],
- "test_list": [
-
- ]
- }
- ```
-
- The declaration of a module contains the following parts:
-
- - **module\_list**: submodule list of the module
- - **inner\_kits**: APIs for other modules that depend on this module through **external\_deps**
- - **system\_kits**: APIs for developers
- - **test\_list**: test cases for the submodules of the module
-
-2. Add the module to the product configuration file.
-
- Add **"subsystem\_examples:partA"** to the configuration file **productdefine/common/products/\{product-name\}.json** to build and package **partA** into the distribution.
-
-3. Build the module, including the library, executable file, and etc configuration file.
-
- For example, run the following command to build Hi3516D V300:
-
- ```
- ./build.sh --product-name Hi3516DV300 --ccache
- ```
-
-4. Obtain the build result.
-
- 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.
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-guidelines.md b/en/device-dev/subsystems/compilation-and-building-guidelines.md
index e89b07bebaaba173dafd27affe843b42d4e0e3f2..eddc2c96aaefe399e0c46c7d47eb3810ab59f67a 100644
--- a/en/device-dev/subsystems/compilation-and-building-guidelines.md
+++ b/en/device-dev/subsystems/compilation-and-building-guidelines.md
@@ -1,430 +1,174 @@
-# Compilation and Building Guidelines
+# Compilation and Building Guidelines
-- [Prerequisites](#section13333171022312)
-- [How to Use the hb Command Line Tool](#section477242204612)
-- [Adding a Module](#section4207112818418)
-- [Adding a Chipset Solution](#section2737141421917)
-- [Adding a Product Solution](#section720881917199)
+- [Directory Structure](#section56731811102915)
+- [Building](#section1069873833818)
+ - [Build Command](#section2740182614395)
-## Prerequisites
+- [How to Develop](#section4207112818418)
-Ensure that the development environment has GN, Ninja, Python 3.7.4 or later, and hb commands. For details about installation methods, see [Basic OS Environment Setup](../quick-start/environment-setup.md).
+## Directory Structure
-## How to Use the hb Command Line Tool
+```
+/build # Primary directory
+├── config # Build configuration items
+├── core
+│ └── gn # Build entry configuration
+├── loader # Loader of module configuration, which also generates a template for the module
+├── ohos # Configuration of the process for building and packaging OpenHarmony
+│ ├── kits # Build and packaging templates and processing flow for kits
+│ ├── ndk # NDK template and processing flow
+│ ├── notice # Notice template and processing flow
+│ ├── packages # Distribution packaging template and processing flow
+│ ├── sa_profile # SA template and processing flow
+│ ├── sdk # SDK template and processing flow, which contains the module configuration in the SDK
+│ └── testfwk # Processing flow related to the test
+├── scripts # Build-related Python script
+├── templates # C/C++ build templates
+└── toolchain # Toolchain configuration
+```
-hb is a command line tool for OpenHarmony to execute build commands. Common hb commands are described as follows:
+## Building
-1. **hb set**
+### Build Command
- ```
- hb set -h
- usage: hb set [-h] [-root [ROOT_PATH]] [-p]
-
- optional arguments:
- -h, --help show this help message and exit
- -root [ROOT_PATH], --root_path [ROOT_PATH]
- Set OHOS root path
- -p, --product Set OHOS board and kernel
- ```
-
- - If you run **hb set** with no argument, the default setting process starts.
- - You can run **hb set -root** _dir_ to set the root directory of the source code.
- - **hb set -p** is used to set the product to build.
-
-2. **hb env**
-
- View the current configuration.
-
- ```
- hb env
- [OHOS INFO] root path: xxx
- [OHOS INFO] board: hispark_taurus
- [OHOS INFO] kernel: liteos
- [OHOS INFO] product: ipcamera
- [OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
- [OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
- ```
-
-3. **hb build**
+- Run the following command in the root directory of the source code to build the full distribution:
```
- hb build -h
- usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
- [--dmverity] [-p PRODUCT] [-f] [-n]
- [component [component ...]]
-
- positional arguments:
- component name of the component
-
- optional arguments:
- -h, --help show this help message and exit
- -b BUILD_TYPE, --build_type BUILD_TYPE
- release or debug version
- -t [TEST [TEST ...]], --test [TEST [TEST ...]]
- compile test suit
- --dmverity Enable dmverity
- -p PRODUCT, --product PRODUCT
- build a specified product with
- {product_name}@{company}, eg: ipcamera@hisilcon
- -f, --full full code compilation
- -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
- Compile single target
+ ./build.sh --product-name {product_name}
```
- - If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option will delete all products to be built, which is equivalent to running **hb clean** and **hb build**.
- - You can run **hb build** _\{module\_name\}_ to build product modules separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
- - You can run **hb build -p ipcamera@hisilicon** to skip the setting step and compile the product directly.
- - You can run **hb build** in **device/device\_company/board** to select the kernel and start the build based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
+ **product\_name** indicates the product supported by the current distribution, for example, Hi3516D V300.
-4. **hb clean**
+ The image generated after build is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
- Clear the build result of the product in the **out** directory, and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/xxx/xxx**.
+- The build command supports the following options:
```
- hb clean
- usage: hb clean [-h] [out_path]
-
- positional arguments:
- out_path clean a specified path.
-
- optional arguments:
- -h, --help show this help message and exit
+ --product-name # (Mandatory) Name of the product to build, for example, Hi3516D V300
+ --build-target # (Optional) One or more build targets
+ --gn-args # (Optional) One or more gn parameters
+ --ccache # (Optional) Use of Ccache for build. This option takes effect only when Ccache is installed on the local PC.
```
-## Adding a Module
-
-To add a module, determine the subsystem to which the module belongs and the module name, and then perform the following steps:
+## How to Develop
-1. Add the module build script after the source code development is complete.
+1. Add a module.
- The following example adds the **BUILD.gn** script \(stored in the **applications/sample/hello\_world** directory\) to build the **hello\_world** module \(as an executable file\).
+ The following steps use a custom module as an example to describe how to build the module, including build a library, an executable file, and a configuration file.
- ```
- executable("hello_world") {
- include_dirs = [
- "include",
- ]
- sources = [
- "src/hello_world.c"
- ]
- }
- ```
+ The example module **partA** consists of **feature1**, **feature2**, and **feature3**. The target of **feature1** is a dynamic library, that of **feature2** is an executable file, and that of **feature3** is an etc configuration file.
- The added script is used to build **hello\_world** that can run on OpenHarmony.
+ Add **partA** to a subsystem, for example, **subsystem\_examples** \(defined in the **test/examples/** directory\).
- To build the preceding module separately, select a product via the **hb set** command and run the **-T** command.
+ The complete directory structure of **partA** is as follows:
```
- hb build -f -T //applications/sample/hello_world
+ test/examples/partA
+ ├── feature1
+ │ ├── BUILD.gn
+ │ ├── include
+ │ │ └── helloworld1.h
+ │ └── src
+ │ └── helloworld1.cpp
+ ├── feature2
+ │ ├── BUILD.gn
+ │ ├── include
+ │ │ └── helloworld2.h
+ │ └── src
+ │ └── helloworld2.cpp
+ └── feature3
+ ├── BUILD.gn
+ └── src
+ └── config.conf
```
- After the module functions are verified based on the development board, perform steps 2 to 5 to configure the module for the product.
-
-2. Add the module description.
-
- The module description is stored in the **build/lite/components** directory. New modules must be added to the JSON file of the corresponding subsystem. A module description must contain the following fields:
-
- - **module**: name of the module
- - **description**: brief description of the module
- - **optional**: whether the module is optional
- - **dirs**: source code directory of the module
- - **targets**: module build entry
-
- For example, to add the **hello\_world** module to the application subsystem, add the **hello\_world** object to the **applications.json** file.
+ Example 1: GN script \(**test/examples/partA/feature1/BUILD.gn**\) for building a dynamic library
```
- {
- "components": [
- {
- "component": "hello_world",
- "description": "Hello world.",
- "optional": "true",
- "dirs": [
- "applications/sample/hello_world"
- ],
- "targets": [
- "//applications/sample/hello_world"
- ]
- },
- ...
- ]
+ config("helloworld_lib_config") {
+ include_dirs = [ "include" ]
+ }
+
+ ohos_shared_library("helloworld_lib") {
+ sources = [
+ "include/helloworld1.h",
+ "src/helloworld1.cpp",
+ ]
+ public_configs = [ ":helloworld_lib_config" ]
+ part_name = "partA"
}
```
-3. Configure the module for the product.
-
- The **config.json** file is stored in the **vendor/company/product/** directory. The file must contain the product name, OpenHarmony version, device vendor, development board, kernel type, kernel version, and the subsystem and module to configure. The following example adds the **hello\_world** module to the **my\_product.json** configuration file:
+ Example 2: GN script \(**test/examples/partA/feature2/BUILD.gn**\) for building an executable file
```
- {
- "product_name": "hello_world_test",
- "ohos_version": "OpenHarmony 1.0",
- "device_company": "hisilicon",
- "board": "hispark_taurus",
- "kernel_type": "liteos_a",
- "kernel_version": "1.0.0",
- "subsystems": [
- {
- "subsystem": "applications",
- "components": [
- { "component": "hello_world", "features":[] }
- ]
- },
- ...
- ]
+ ohos_executable("helloworld_bin") {
+ sources = [
+ "src/helloworld2.cpp"
+ ]
+ include_dirs = [ "include" ]
+ deps = [ # Dependent submodule
+ "../feature1:helloworld_lib"
+ ]
+ external_deps = [ "partB:module1" ] # (Optional) If there is a cross-module dependency, the format is "module name: submodule name"
+ install_enable = true # By default, the executable file is not installed. You need to set this parameter to true for installation.
+ part_name = "partA"
}
```
-4. Build the product.
-
- 1. Run the **hb set** command in the root code directory to select the corresponding product.
-
- 2. Run the **hb build** command.
-
-
-## Adding a Chipset Solution
-
-The Compilation and Building subsystem allows you to add a chipset solution. Detailed operations are as follows:
-
-1. Create a directory for the chipset solution.
-
- Taking the RTL8720 development board of chipset provider Realtek for example, you need to run the following command in the root code directory to create a directory for the chipset solution based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](compilation-and-building-overview.md#section1625463413327).
+ Example 3: GN script \(**test/examples/partA/feature3/BUILD.gn**\) for building the etc configuration file \(submodule\).
```
- mkdir -p device/realtek/rtl8720
+ ohos_prebuilt_etc("feature3_etc") {
+ source = "src/config.conf"
+ relative_install_dir = "init" # (Optional) Directory for installing the submodule, which is relative to the default installation directory (/system/etc)
+ part_name = "partA"
+ }
```
-2. Create a directory for kernel adaptation and build the **config.gni** file of the development board.
-
- The following example adapts the LiteOS Cortex-M kernel to the RTL8720 development board of Realtek. The **device/realtek/rtl8720/liteos\_a/config.gni** file is configured as follows:
+ Example 4: Adding the module configuration file **test/examples/ohos.build** to the **ohos.build** file of this subsystem. Each subsystem has an **ohos.build** file in its root directory.
```
- # Kernel type, e.g. "linux", "liteos_a", "liteos_m".
- kernel_type = "liteos_a"
-
- # Kernel version.
- kernel_version = "3.0.0"
-
- # Board CPU type, e.g. "cortex-a7", "riscv32".
- board_cpu = "real-m300"
-
- # Board arch, e.g. "armv7-a", "rv32imac".
- board_arch = ""
+ "partA": {
+ "module_list": [
+ "//test/examples/partA/feature1:helloworld_lib",
+ "//test/examples/partA/feature2:helloworld_bin",
+ "//test/examples/partA/feature3:feature3_etc",
+ ],
+ "inner_kits": [
- # Toolchain name used for system compiling.
- # E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
- # Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
- board_toolchain = "gcc-arm-none-eabi"
+ ],
+ "system_kits": [
- # The toolchain path instatlled, it's not mandatory if you have added toolchian path to your ~/.bashrc.
- board_toolchain_path =
- rebase_path("//prebuilts/gcc/linux-x86/arm/gcc-arm-none-eabi/bin",
- root_build_dir)
+ ],
+ "test_list": [
- # Compiler prefix.
- board_toolchain_prefix = "gcc-arm-none-eabi-"
-
- # Compiler type, "gcc" or "clang".
- board_toolchain_type = "gcc"
-
- # Board related common compile flags.
- board_cflags = []
- board_cxx_flags = []
- board_ld_flags = []
- ```
-
-3. Build the script.
-
- Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. Taking the RTL8720 development board of Realtek as an example, the content in the **device/realtek/rtl8720/BUILD.gn** file is configured as follows:
-
- ```
- group("rtl8720") { # The target can be shared_library, static_library, or an executable file.
- # Content
- ......
- }
- ```
-
-4. Build the chipset solution.
-
- Run the **hb build** command in the development board directory to start the build.
-
-
-## Adding a Product Solution
-
-The Compilation and Building subsystem supports flexible assembly of chipset solutions and modules to customize desired product solutions. The operation procedure is as follows:
-
-1. Create a product directory.
-
- Taking the Wi-Fi IoT module based on the RTL8720 development board as an example, you need to run the following command in the root code directory to create a product directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](compilation-and-building-overview.md#section1625463413327).
-
- ```
- mkdir -p vendor/my_company/wifiiot
- ```
-
-2. Assemble the product.
-
- Create the **config.json** file in the product directory. Taking the Wi-Fi IoT module as an example, the **vendor/my\_company/wifiiot/config.json** file is as follows:
-
- ```
- {
- "product_name": "wifiiot", # Product name
- "ohos_version": "OpenHarmony 1.0", # In-use OS version
- "device_company": "realtek", # Name of the chipset solution vendor
- "board": "rtl8720", # Name of the development board
- "kernel_type": "liteos_m", # Selected kernel type
- "kernel_version": "3.0.0", # Selected kernel version
- "subsystems": [
- {
- "subsystem": "kernel", # Selected subsystem
- "components": [
- { "component": "liteos_m", "features":[] } # Selected module and its features
- ]
- },
- ...
- {
- More subsystems and modules
- }
]
- }
+ }
```
- Before the build, the Compilation and Building subsystem will check the validity of fields, including **device\_company**, **board**, **kernel\_type**, **kernel\_version**, **subsystem**, and **component**. The first four fields and the latter two fields must match the current chipset solution and the module description in the **build/lite/components** file, respectively.
-
-3. Implement adaptation of OS APIs.
+ The declaration of a module contains the following parts:
- Create the **hals** directory in the product directory and store the source code as well as the build script for OS adaptation in this directory.
+ - **module\_list**: submodule list of the module
+ - **inner\_kits**: APIs for other modules that depend on this module through **external\_deps**
+ - **system\_kits**: APIs for developers
+ - **test\_list**: test cases for the submodules of the module
-4. Configure the system service.
+2. Add the module to the product configuration file.
- Create the **init\_configs** directory in the product directory and then the **init.cfg** file in the newly created directory. You can configure the system service to be started on demand.
+ Add **"subsystem\_examples:partA"** to the configuration file **productdefine/common/products/\{product-name\}.json** to build and package **partA** into the distribution.
-5. Configure the init process \(only for the Linux kernel\).
+3. Build the module, including the library, executable file, and etc configuration file.
- You need to create the **etc** directory in the **init\_configs** directory, and then the **init.d** folder as well as the **fstab** file in the newly created directory. In addition, you need to create the **rcS** and **Sxxx** files in the **init.d** file and edit them based on product requirements.
-
-6. Configure the file system image \(required only for the development board that supports the file system\).
-
- Create the **fs.yml** file in the product directory and configure it as required. A typical **fs.yml** file is configured as follows:
+ For example, run the following command to build Hi3516D V300:
```
- -
- fs_dir_name: rootfs # Image name
- fs_dirs:
- -
- # Copy the files in the out/my_board/my_product/bin directory to the rootfs/bin directory and ignore the .bin files related to testing.
- source_dir: bin
- target_dir: bin
- ignore_files:
- - Test.bin
- - TestSuite.bin
- -
- # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the permissions on the files and folders to 644 and 755, respectively.
- source_dir: libs
- target_dir: lib
- ignore_files:
- - .a
- dir_mode: 755
- file_mode: 644
- -
- source_dir: usr/lib
- target_dir: usr/lib
- ignore_files:
- - .a
- dir_mode: 755
- file_mode: 644
- -
- source_dir: config
- target_dir: etc
- -
- source_dir: system
- target_dir: system
- -
- source_dir: sbin
- target_dir: sbin
- -
- source_dir: usr/bin
- target_dir: usr/bin
- -
- source_dir: usr/sbin
- target_dir: usr/sbin
- -
- # Create an empty proc directory.
- target_dir: proc
- -
- target_dir: mnt
- -
- target_dir: opt
- -
- target_dir: tmp
- -
- target_dir: var
- -
- target_dir: sys
- -
- source_dir: etc
- target_dir: etc
- -
- source_dir: vendor
- target_dir: vendor
- -
- target_dir: storage
-
- fs_filemode:
- -
- file_dir: lib/ld-uClibc-0.9.33.2.so
- file_mode: 555
- -
- file_dir: lib/ld-2.24.so
- file_mode: 555
- -
- file_dir: etc/init.cfg
- file_mode: 400
- fs_symlink:
- -
- # Create the soft link ld-musl-arm.so.1 -> libc.so in the rootfs/lib directory.
- source: libc.so
- link_name: ${fs_dir}/lib/ld-musl-arm.so.1
- -
- source: mksh
- link_name: ${fs_dir}/bin/sh
- -
- source: mksh
- link_name: ${fs_dir}/bin/shell
- fs_make_cmd:
- # Create an ext4 image for the rootfs directory using the script.
- - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
- -
- fs_dir_name: userfs
- fs_dirs:
- -
- source_dir: storage/etc
- target_dir: etc
- -
- source_dir: data
- target_dir: data
- fs_make_cmd:
- - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
- ```
-
-7. Build the script.
-
- Create the **BUILD.gn** file in the product directory and build the script based on your requirements. Taking the Wi-Fi IoT module in step 1 as an example, the **BUILD.gn** is configured as follows:
-
- ```
- group("wifiiot") { # The target name must be the same as the product name.
- deps = []
- # Copy the init configuration.
- deps += [ "init_configs" ]
- # Build the hals directory.
- deps += [ "hals" ]
- # Others
- ......
- }
+ ./build.sh --product-name Hi3516DV300 --ccache
```
-8. Build the product.
+4. Obtain the build result.
- Run the **hb set** command in the root code directory to select the new product as prompted, and then run the **hb build** command to start the build.
+ 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.
diff --git a/en/device-dev/subsystems/compilation-and-building-overview-0.md b/en/device-dev/subsystems/compilation-and-building-overview-0.md
deleted file mode 100644
index de4d2beab9d8c3f91f9d1ff841af68e9311b0fb6..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-overview-0.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Compilation and Building Overview
-
-- [Basic Concepts](#section175012297491)
-- [Working Principles](#section193961322175011)
-- [Limitations and Constraints](#section2029921310472)
-
-The compilation and building subsystem provides a framework based on Generate Ninja \(GN\) and Ninja. This subsystem allows you to:
-
-- Build products based on different chipset platforms, for example, Hi3516D V300.
-
-- Package capabilities required by a product by assembling modules based on the product configuration.
-
-## Basic Concepts
-
-It is considered best practice to learn the following basic concepts before you start building:
-
-- **Platform**
-
- A platform is a combination of development boards and kernels.
-
- Supported subsystems and modules vary according to the platform.
-
-- **Subsystems**
-
- OpenHarmony is designed with a layered architecture, which from bottom to top consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to module. In a multi-device deployment scenario, unnecessary subsystems and modules can be excluded from the system as required. A subsystem is a logical concept and is a flexible combination of functions.
-
-- **Module**
-
- A module is a reusable software binary unit that contains source code, configuration files, resource files, and build scripts. A module can be built independently, integrated in binary mode, and then tested independently.
-
-- **GN**
-
- GN is short for Generate Ninja, which is used to generate Ninja files.
-
-- **Ninja**
-
- Ninja is a small high-speed build system.
-
-
-## Working Principles
-
-The process to build OpenHarmony is as follows:
-
-- Parsing commands: Parse the name of the product to build and load related configurations.
-- Running GN: Configure toolchains and global options based on the parsed product name and compilation type.
-- Running Ninja: Start building and generate a product distribution.
-
-## Limitations and Constraints
-
-- You must download the source code using method 3 described in [Source Code Acquisition](../get-code/source-code-acquisition.md).
-- The build environment must be Ubuntu 18.04 or later.
-- You must install the software package required for build.
-
- The installation command is as follows:
-
- ```
- sudo apt-get install binutils git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4
- ```
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-overview.md b/en/device-dev/subsystems/compilation-and-building-overview.md
index 8cf7a6a1c1459288b1430f022740ef3a229663dd..de4d2beab9d8c3f91f9d1ff841af68e9311b0fb6 100644
--- a/en/device-dev/subsystems/compilation-and-building-overview.md
+++ b/en/device-dev/subsystems/compilation-and-building-overview.md
@@ -1,132 +1,60 @@
-# Compilation and Building Overview
+# Compilation and Building Overview
- [Basic Concepts](#section175012297491)
-- [Usage Guidelines](#section193961322175011)
+- [Working Principles](#section193961322175011)
- [Limitations and Constraints](#section2029921310472)
-The compilation and building subsystem is a building framework based on Generate Ninja \(GN\) and Ninja, which supports component-based OpenHarmony development. This subsystem can be used to:
+The compilation and building subsystem provides a framework based on Generate Ninja \(GN\) and Ninja. This subsystem allows you to:
-- Build existing products.
+- Build products based on different chipset platforms, for example, Hi3516D V300.
-- Build chipset source code independently.
-- Build a single component independently.
+- Package capabilities required by a product by assembling modules based on the product configuration.
## Basic Concepts
-It is considered best practice to learn the following basic concepts before you start development and building:
+It is considered best practice to learn the following basic concepts before you start building:
-- **Component**
+- **Platform**
- A component is a reusable software unit that can contain source code, configuration files, resource files, and compilation scripts.
+ A platform is a combination of development boards and kernels.
-- **GN**
-
- GN is short for Generate Ninja, which is used to generate Ninja files.
-
-- **Ninja**
-
- Ninja is a small high-speed building system.
-
-
-## Usage Guidelines
-
-1. **Building Process**
+ Supported subsystems and modules vary according to the platform.
- [Figure 1](#fig9744112715161) shows the building process.
+- **Subsystems**
- **Figure 1** Building process
- 
+ OpenHarmony is designed with a layered architecture, which from bottom to top consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to module. In a multi-device deployment scenario, unnecessary subsystems and modules can be excluded from the system as required. A subsystem is a logical concept and is a flexible combination of functions.
- 1. **hb set**: Set the OpenHarmony source code directory and the product to build.
- 2. **hb build**: Build the product, development board, or component. The process to build the solution is as follows:
- - **Reading configuration**: Read the development board configuration, which covers the toolchain, linking commands, and compilation options.
- - **Running gn**: Run the **gn gen** command to read the product configuration \(related to the development board, kernel, and system components\) and generate the **out** directory and **ninja** files for the solution.
- - **Running Ninja**: Run **ninja -C out/company/product** to start compilation.
- - **Packaging**: Package the compilation result to create a file system image.
+- **Module**
+ A module is a reusable software binary unit that contains source code, configuration files, resource files, and build scripts. A module can be built independently, integrated in binary mode, and then tested independently.
-2. **Building Commands**
-
- 1. **hb set**
-
- ```
- hb set -h
- usage: hb set [-h] [-root [ROOT_PATH]] [-p]
-
- optional arguments:
- -h, --help show this help message and exit
- -root [ROOT_PATH], --root_path [ROOT_PATH]
- Set OHOS root path
- -p, --product Set OHOS board and kernel
- ```
+- **GN**
- - If you run **hb set** with no argument, the default setting process starts.
- - You can run **hb set -root** _dir_ to set the root directory of the source code.
- - **hb set -p** is used to set the product to compile.
+ GN is short for Generate Ninja, which is used to generate Ninja files.
- 2. **hb env**
+- **Ninja**
- View the current configuration.
+ Ninja is a small high-speed build system.
- ```
- hb env
- [OHOS INFO] root path: xxx
- [OHOS INFO] board: hispark_taurus
- [OHOS INFO] kernel: liteos
- [OHOS INFO] product: ipcamera
- [OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
- [OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
- ```
- 3. **hb build**
+## Working Principles
- ```
- hb build -h
- usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
- [--dmverity] [-p PRODUCT] [-f] [-n]
- [component [component ...]]
-
- positional arguments:
- component name of the component
-
- optional arguments:
- -h, --help show this help message and exit
- -b BUILD_TYPE, --build_type BUILD_TYPE
- release or debug version
- -c COMPILER, --compiler COMPILER
- specify compiler
- -t [TEST [TEST ...]], --test [TEST [TEST ...]]
- compile test suite
- --dmverity Enable dmverity
- -p PRODUCT, --product PRODUCT
- build a specified product with
- {product_name}@{company}, eg: ipcamera@hisilcon
- -f, --full full code compilation
- ```
+The process to build OpenHarmony is as follows:
- - If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the compilation. The **-f** option will delete all products to be compiled, which is equivalent to running **hb clean** and **hb build**.
- - You can run **hb build** _\{component\_name\}_ to compile product components separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
- - You can run **hb build -p ipcamera@hisilicon** to skip the setting step and compile the product directly.
- - You can run **hb build** in **device/device\_company/board** to select the kernel and start compilation based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
+- Parsing commands: Parse the name of the product to build and load related configurations.
+- Running GN: Configure toolchains and global options based on the parsed product name and compilation type.
+- Running Ninja: Start building and generate a product distribution.
- 4. **hb clean**
+## Limitations and Constraints
- Clear the compilation result of the product in the **out** directory, and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean** _xxx_**/out/**_xxx_.
+- You must download the source code using method 3 described in [Source Code Acquisition](../get-code/source-code-acquisition.md).
+- The build environment must be Ubuntu 18.04 or later.
+- You must install the software package required for build.
+ The installation command is as follows:
```
- hb clean
- usage: hb clean [-h] [out_path]
-
- positional arguments:
- out_path clean a specified path.
-
- optional arguments:
- -h, --help show this help message and exit
+ sudo apt-get install binutils git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4
```
-## Limitations and Constraints
-
-Ensure that the development environment has GN and Ninja, Python 3.7.4 and later, and hb commands. You must download the complete code before you start.
-
diff --git a/en/device-dev/subsystems/development-guidelines-5.md b/en/device-dev/subsystems/development-guidelines-4.md
similarity index 100%
rename from en/device-dev/subsystems/development-guidelines-5.md
rename to en/device-dev/subsystems/development-guidelines-4.md
diff --git a/en/device-dev/subsystems/development-guidelines-on-photographing.md b/en/device-dev/subsystems/development-guidelines-on-photographing.md
index 23f92734097a2c318c8701f8c30983b88100b7bc..d35bed7457c70bc19d6c66cdbca1267b7da37aec 100644
--- a/en/device-dev/subsystems/development-guidelines-on-photographing.md
+++ b/en/device-dev/subsystems/development-guidelines-on-photographing.md
@@ -385,6 +385,7 @@ None
Surface *surface = Surface::CreateSurface();
if (surface == nullptr) {
delete fc;
+ return;
}
surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
fc->AddSurface(*surface);
diff --git a/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md b/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md
deleted file mode 100644
index 91c4013935b5b3b8ce3cea7997dbeae25f7ac67d..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md
+++ /dev/null
@@ -1,264 +0,0 @@
-# Development Guidelines on Trusted Device Group Management
-
-- [When to Use](#section18502174174019)
-- [Available APIs](#section1633115419401)
-- [How to Develop](#section17516229192313)
-- [Debugging and Verification](#section427316292411)
-
-## When to Use
-
-When a distributed service needs to exploit the secure communication channel provided by the distributed virtual bus for different devices, it can use the trusted device group management component to create groups of trusted devices. Distributed applications can establish and use secure, trusted relationships between devices based on the authentication capabilities for devices using different HUAWEI IDs, such as PIN code, QR code, and OneHop, and the capabilities for grouped devices using the same HUAWEI ID. For a device on which you have not logged in using your HUAWEI ID, you can enter the PIN code or scan the QR code to obtain the connection and PIN code information of the device. Then you can create a group of trusted devices and add this device to the group. If other applications have created and shared their groups of trusted devices, or have logged in using the same HUAWEI ID as yours, you can call APIs to query and use the groups.
-
-## Available APIs
-
-The following tables list the innerkits APIs provided by trusted device group management. These APIs are intended for system applications only.
-
-**Table 1** Java APIs provided by trusted device group management
-
-
-
Function
-
-
Description
-
-
-
-
public static DeviceGroupManager getInstance(Abilityability, StringappID, IHichainGroupCallbackcallbackHandler)
-
-
Obtains a DeviceGroupManager instance and registers a listener.
-
-
-
int createGroup(String appId, String groupName, int groupType, String groupInfo)
-
-
Creates a group of trusted devices.
-
-
-
public int deleteGroup(String gourpId)
-
-
Deletes a group of trusted devices.
-
-
-
public String getLocalConnectInfo()
-
-
Obtains the network connection information of the local device.
-
-
-
int addMemberToGroup(String appId, long requestId, String addParams, String connectParams, int groupType)
-
-
Adds a member to a specified group.
-
-
-
int deleteMemberFromGroup(String appId, long requestId, String deleteParams, String connectParams)
-
-
Deletes a member from a specified group.
-
-
-
int cancelRequest(long requestId)
-
-
Cancels an ongoing request, for example, adding or deleting a member.
-
-
-
List<String> listJoinedGroups(int groupType)
-
-
Obtains a list of groups of a specified type to which the current device has been added.
Obtains information about all the groups that contain both the local device and the device with a specified ID.
-
-
-
-
-
-## How to Develop
-
-To develop trusted device group management, first obtain a management instance \(a callback to obtain group operation results is registered during the process\). Then you can use the instance to add or delete members, set a friend list for a group, and perform related query operations.
-
-**Scenario 1**: Create a group.
-
-```
-private HwDeviceGroupManager hwDeviceGroupManager;
-...
-private HichainGroupCallback groupCallbackByA = new HichainGroupCallback() {
- @Override public void onFinish(long requestId, GroupOperation operationCode, String returnData) {
-
- }
- @Override public void onError(long requestId, GroupOperation operationCode, int errorCode, String errorReturn) {
-
- }
- @Override public String onRequest(long requestId, GroupOperation operationCode, String reqParams) {
- JSONObject onRequestJson = generateConfirmation(REQUEST_ACCEPTED);
- return onRequestJson.toString();
- }
-};
-...
-Optional context = convertAbilityToContext(mAbility);
-Context ctxt = context.get();
-hwDeviceGroupManager = HwDeviceGroupManager.getInstance(ctxt, APP_ID, groupCallbackByA);
-int ret = hwDeviceGroupManager.createGroup(APP_ID, GROUP_NAME, GROUP_TYPE, GROUP_INFO);
-```
-
-1. Declare the private member variable of the **HwDeviceGroupManager** instance.
-
- ```
- private HwDeviceGroupManager hwDeviceGroupManager;
- ```
-
-2. Create a callback for group management operations.
-
- ```
- private HichainGroupCallback groupCallbackByA = new HichainGroupCallback();
- ```
-
-3. Obtain a **HwDeviceGroupManager** instance. \(In distributed scenarios, the same application on different devices must use the same **APP\_ID**.\)
-
- ```
- hwDeviceGroupManager = HwDeviceGroupManager.getInstance(ctxt, APP_ID, groupCallbackByA);
- ```
-
-4. Call the **createGroup** function to create a group. If **0** is returned, the creation request is submitted successfully.
-
- ```
- int ret = hwDeviceGroupManager.createGroup(APP_ID, GROUP_NAME, GROUP_TYPE, GROUP_INFO);
- ```
-
-5. After the group is created, **onFinish** is called. In this callback, the value of **operationCode** is **OperationCode.CREATE**, indicating a group creation operation. **returnData** is in JSON format and contains the **groupId** field, indicating the ID of the created group.
-
-**Scenario 2**: Add an authenticated device \(member\) to a group so that you can initiate trusted, encrypted connections to the device through the distributed virtual bus.
-
-```
-deviceGroupManager = DeviceGroupManager.getInstance(mAbility, APP_ID, hichainGroupCallback);
-private static final String CONN_PARAM ="{\"DEVICE_ID\":\"11111111\",\"WIFI_IP\":\"192.168.43.149\",\"WIFI_PORT\":\"30000\",\"BLE_MAC\":\"\"}";
-private static final String ADD_PARAM ="{\"groupId\":\"344C1C8B149\",\"groupName\":\"myGroup\",\"addId\":\"11111111\",\"isAdmin\":\"false\"}";
-private static final int GROUP_TYPE = 256;
-int result = deviceGroupManager.addMemberToGroup(APP_ID, reqId, ADD_PARAM, CONN_PARAM, GROUP_TYPE);
-```
-
-1. Obtain an **HwDeviceGroupManager** instance.
-
- ```
- deviceGroupManager = HwDeviceGroupManager.getInstance(mAbility, APP_ID, hichainGroupCallback);
- ```
-
-2. Set network connection parameters for the member to add \(in JSON format\), which are network parameters supported by the distributed virtual bus, such as **WIFI\_IP**, **WIFI\_PORT**, **BLR\_MAC**, and **DEVICE\_ID**. For details about the parameters, see the distributed virtual bus development guidelines.
-
- ```
- String CONN_PARAM ="{\"DEVICE_ID\":\"11111111\",\"WIFI_IP\":\"192.168.43.149\",\"WIFI_PORT\":\"30000\",\"BLE_MAC\":\"\"}";
- ```
-
-3. Set parameters for the member to add \(in JSON format\), including the group ID, name, and whether the member is an administrator. If the member is invited to add a group, the value of **isAdmin** is **true**; otherwise, the value of **isAdmin** is **false**.
-
- ```
- String ADD_PARAM ="{\"groupId\":\"344C1C8B149\",\"groupName\":\"myGroup\",\"addId\":\"11111111\",\"isAdmin\":\"false\"}";
- ```
-
-4. Set the type of the target group to **256**, indicating a P2P group.
-
- ```
- private static final int GROUP_TYPE = 256;
- ```
-
-5. Set **generateConfirmation** of the **onRequest** function in **HichainGroupCallback**. **PIN\_CODE** indicates the PIN code, which is input by users on the UI of the service. \(In a distributed communication, two devices must use the same PIN code.\)
-
- ```
- private JSONObject generateConfirmation(int confirmation) {
- JSONObject jsonObject = new JSONObject();
- try { jsonObject.put("pinCode", PIN_CODE);
- jsonObject.put("confirmation", confirmation);
- } catch (JSONException e) {
- LogUtil.error(TAG, "" + e.getMessage());
- }
- return jsonObject;
- }
- ```
-
-6. Call the **addMemberToGroup** function to add the member to the group.
-
- ```
- result = deviceGroupManager.addMemberToGroup(APP_ID, reqId, ADD_PARAM, CONN_PARAM, GROUP_TYPE);
- ```
-
-7. Check whether **HichainGroupCallback.onFinish** is called \(**operationCode** is **OperationCode.JOIN**\). If it is called, the member is added successfully.
-8. Call APIs of the distributed virtual bus to create secure sessions between devices.
-
-## Debugging and Verification
-
-1. Develop an application with OpenHarmony.
-
-2. Develop an application by following the development guidelines.
-
-3. Create a group. If the **onFinish** callback is invoked, the group is created successfully.
-
-4. Deploy the same application on two devices, A and B.
-
-5. Transmit the connection parameters of device B to device A through a QR code.
-
-6. In the application on device A, create group1 and call the API to add device B to group1. If **HichainGroupCallback.onFinish** is called, device B is successfully added to group1.
-
diff --git a/en/device-dev/subsystems/dfx-11.md b/en/device-dev/subsystems/dfx-7.md
similarity index 92%
rename from en/device-dev/subsystems/dfx-11.md
rename to en/device-dev/subsystems/dfx-7.md
index faf8b0d8fa8e4c39a1548d7a7e77b6eb6906bd95..b7bfac023a5bf84628ceb40723a9ed2e62dbb892 100644
--- a/en/device-dev/subsystems/dfx-11.md
+++ b/en/device-dev/subsystems/dfx-7.md
@@ -6,7 +6,7 @@
The DFX subsystem provides the following functions:
-- HiLog: Implements the logging function. It is applicable to Mini-System Devices \(reference memory ≥ 128 KB\), Small-System Devices \(reference memory ≥ 1 MB\), and Standard-System Devices \(reference memory ≥ 128 MB\).
+- HiLog: Implements the logging function. It is applicable to Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\) as well as Standard-System Devices \(reference memory ≥ 128 MB\).
- HiSysEvent: Implements system event logging. It is applicable to Standard-System Devices \(reference memory ≥ 128 MB\).
diff --git a/en/device-dev/subsystems/dfx.md b/en/device-dev/subsystems/dfx.md
index 241303cae97af3db18251e836e22ca628efba17c..c4ffcc54fdf46737c0b3d3363302d22e0990ab22 100644
--- a/en/device-dev/subsystems/dfx.md
+++ b/en/device-dev/subsystems/dfx.md
@@ -1,6 +1,6 @@
# DFX
-- **[DFX](dfx-11.md)**
+- **[DFX](dfx-7.md)**
- **[Development Guidelines on HiLog](development-guidelines-on-hilog.md)**
diff --git a/en/device-dev/subsystems/figures/build-process.jpg b/en/device-dev/subsystems/figures/build-process.jpg
index c8d58bc3d172524c78e3c45455622d081429529c..a48ea734509526b3ed0fe85b7c4a98b0a2a9c4f0 100644
Binary files a/en/device-dev/subsystems/figures/build-process.jpg and b/en/device-dev/subsystems/figures/build-process.jpg differ
diff --git a/en/device-dev/subsystems/figures/building-process.jpg b/en/device-dev/subsystems/figures/building-process.jpg
deleted file mode 100644
index c8d58bc3d172524c78e3c45455622d081429529c..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/figures/building-process.jpg and /dev/null differ
diff --git a/en/device-dev/subsystems/figures/ril-adapter.png b/en/device-dev/subsystems/figures/ril-adapter.png
deleted file mode 100644
index 51d8a0668a19b26071873247a5cf1f483d9044e5..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/figures/ril-adapter.png and /dev/null differ
diff --git "a/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png" "b/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png"
deleted file mode 100644
index fd53e705cde494b3b5a7a5e2c923a9b5ac07aa4f..0000000000000000000000000000000000000000
Binary files "a/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png" and /dev/null differ
diff --git "a/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png" "b/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png"
deleted file mode 100644
index 9b27f13794e395cb6b05ec588f96bc938288ec01..0000000000000000000000000000000000000000
Binary files "a/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png" and /dev/null differ
diff --git a/en/device-dev/subsystems/graphics-2.md b/en/device-dev/subsystems/graphics-1.md
similarity index 100%
rename from en/device-dev/subsystems/graphics-2.md
rename to en/device-dev/subsystems/graphics-1.md
diff --git a/en/device-dev/subsystems/graphics.md b/en/device-dev/subsystems/graphics.md
index 254f1e0fa0022f821ba9ecb5f8f88846a868bfe7..db3332445d4a69852fb1d709531774f719344cbe 100644
--- a/en/device-dev/subsystems/graphics.md
+++ b/en/device-dev/subsystems/graphics.md
@@ -1,6 +1,6 @@
# Graphics
-- **[Graphics](graphics-2.md)**
+- **[Graphics](graphics-1.md)**
- **[Development Guidelines on Container Components](development-guidelines-on-container-components.md)**
diff --git a/en/device-dev/subsystems/overview-2.md b/en/device-dev/subsystems/overview-2.md
new file mode 100644
index 0000000000000000000000000000000000000000..98b5b4ad048a507a0a4fe21297b86ca6b158995d
--- /dev/null
+++ b/en/device-dev/subsystems/overview-2.md
@@ -0,0 +1,81 @@
+# Overview
+
+- [Basic Concepts](#section967213571204)
+- [Encoding and Decoding](#section1582020483111)
+
+OpenHarmony multimedia services help you to develop for audio and video playback and recording.
+
+- The media playback module facilitates the development of audio and video playback, including media file and stream playback, volume control, and playback progress control.
+- The media recording module supports the development of audio and video recording and provides functions to set the size of captured video, encoding bit rate, encoder type, video frame rate, audio sampling rate, and output file format.
+
+## Basic Concepts
+
+It is considered good practice that you understand the following concepts before starting development:
+
+- Streaming media technology
+
+ The streaming media technology refers to a process to encode continuous video and audio data and store the data on a network server. A viewer can watch and listen to the video and audio during download with no need to wait for the completion of download.
+
+
+- Video frame rate
+
+ The frame rate is used to measure the number of displayed frames, which is the number of images transmitted per second. The more frames per second \(FPS\), the smoother the video.
+
+- Bit rate
+
+ Bit rate is the number of bits transmitted per unit of time. The commonly used unit is kbit/s.
+
+- Sampling rate
+
+ The sampling rate is the number of samples per second taken from continuous signals to form discrete signals. The unit is hertz \(Hz\).
+
+
+## Encoding and Decoding
+
+Available audio and video encoding and decoding capabilities vary depending on device types. The following table lists supported specifications for available development boards.
+
+**Table 1** Encoding and decoding specifications for different development boards
+
+
+
Device Type
+
+
Development Board
+
+
Decoding
+
+
Encoding
+
+
+
+
Cameras with a screen
+
+
Hi3516
+
+
Audio: The MPEG-4 AAC Profile (AAC LC), mono and dual channels, and the MPEG-4 (.mp4 and .m4a) container format are supported.
Video: The H.265 (HEVC) and H.264 (AVC) (for streams encoded using a chip of the same type) and the MPEG-4 (.mp4) container format are supported.
+
+
Audio: AAC-LC encoding, mono and dual channels, and the MPEG-4 (.mp4) container format are supported.
Video: H.264 and H.265 encoding and the MPEG-4 (.mp4) container format are supported.
+
+
+
Cameras without a screen
+
+
Hi3518
+
+
Audio: The MPEG-4 AAC Profile (AAC LC), mono and dual channels, and the MPEG-4 (.mp4 and .m4a) container format are supported.
Video: none
+
+
Audio: AAC-LC encoding, mono and dual channels, and the MPEG-4 (.mp4) container format are supported.
Video: H.264 and H.265 encoding and the MPEG-4 (.mp4) container format are supported.
+
+
+
WLAN connecting devices
+
+
Hi3861
+
+
N/A
+
+
N/A
+
+
+
+
+
+For details about the encoding and decoding specifications of Hi3516 and Hi3518, refer to their documentation.
+
diff --git a/en/device-dev/subsystems/overview-3.md b/en/device-dev/subsystems/overview-3.md
index 98b5b4ad048a507a0a4fe21297b86ca6b158995d..be32c8ebf46f3db9ab43c7a48fc0556250a04b7b 100644
--- a/en/device-dev/subsystems/overview-3.md
+++ b/en/device-dev/subsystems/overview-3.md
@@ -1,81 +1,148 @@
-# Overview
+# Overview
-- [Basic Concepts](#section967213571204)
-- [Encoding and Decoding](#section1582020483111)
+- [Basic Concepts](#section72601941194812)
+- [Ability Management Framework](#section14633111813374)
+- [Bundle Management Framework](#section1341146154412)
+- [Working Principles](#section94302021112717)
+- [Limitations and Constraints](#section89534912527)
-OpenHarmony multimedia services help you to develop for audio and video playback and recording.
+The application framework is provided by OpenHarmony for you to develop OpenHarmony applications. It consists of two modules: ability management framework \(also called the ability framework\) and bundle management framework.
-- The media playback module facilitates the development of audio and video playback, including media file and stream playback, volume control, and playback progress control.
-- The media recording module supports the development of audio and video recording and provides functions to set the size of captured video, encoding bit rate, encoder type, video frame rate, audio sampling rate, and output file format.
+## Basic Concepts
-## Basic Concepts
+This section describes some basic concepts for you to better understand the OpenHarmony application framework before you start development.
-It is considered good practice that you understand the following concepts before starting development:
+## Ability Management Framework
-- Streaming media technology
+The ability management framework manages running status of OpenHarmony applications.
- The streaming media technology refers to a process to encode continuous video and audio data and store the data on a network server. A viewer can watch and listen to the video and audio during download with no need to wait for the completion of download.
+**Figure 1** Architecture of the ability management framework
+
+- **Ability** is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of templates that you can use to create an **Ability** instance: Page and Service.
+ - An **Ability using the Page template** \(Page ability for short\) provides a UI for interacting with users.
-- Video frame rate
+ - An **Ability using the Service template** does not have a UI and is used for running background tasks.
- The frame rate is used to measure the number of displayed frames, which is the number of images transmitted per second. The more frames per second \(FPS\), the smoother the video.
-- Bit rate
- Bit rate is the number of bits transmitted per unit of time. The commonly used unit is kbit/s.
+- An **AbilitySlice** represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities.
-- Sampling rate
+ **Figure 2** Relationship between a Page ability and its ability slices
+ 
- The sampling rate is the number of samples per second taken from continuous signals to form discrete signals. The unit is hertz \(Hz\).
+- **Lifecycle** is a general term for all states of an ability, including **INITIAL**, **INACTIVE**, **ACTIVE**, and **BACKGROUND**.
+ **Figure 3** Lifecycle state transition of a Page ability
+
-## Encoding and Decoding
+ 
-Available audio and video encoding and decoding capabilities vary depending on device types. The following table lists supported specifications for available development boards.
+ - **OnStart\(\)**
+
+ This callback is invoked when the system first creates the Page ability. After this callback is executed, the Page ability enters the **INACTIVE** state. This callback is triggered only once in the entire lifecycle of each Page ability. You must override this callback and set the default ability slice to be displayed.
+
+ - **OnActive\(\)**
+
+ This callback is invoked when the Page ability in the **INACTIVE** state enters the foreground. After this callback is executed, the Page ability enters the **ACTIVE** state, in which it becomes interactive. The Page ability will stay in this state unless it loses focus upon a certain event, for example, when the user touches the Back button or navigates to another Page ability.
+
+ When such an event occurs, the Page ability returns to the **INACTIVE** state, and the system invokes the **OnInactive\(\)** callback. The Page ability may move to the **ACTIVE** state again, and the system will then invoke the **OnActive\(\)** callback again. You should implement both **OnActive\(\)** and **OnInactive\(\)** for a Page ability and use **OnActive\(\)** to obtain the resources released in **OnInactive\(\)**.
+
+ - **OnInactive\(\)**
+
+ This callback is invoked when the Page ability loses focus, and the Page ability then becomes **INACTIVE**. You can implement the behavior to perform after the Page ability loses focus.
+
+ - **OnBackground\(\)**
+
+ This callback is invoked based on the system resource status when the Page ability becomes invisible to the user. After this callback is executed, the Page ability enters the **BACKGROUND** state. You should release the resources that are no longer needed after the Page ability becomes invisible or perform time-consuming save operations in this callback.
+
+ - **OnForeground\(\)**
+
+ A Page ability in the **BACKGROUND** state still resides in memory. When the Page ability returns to the foreground \(for example, when the user navigates to this Page ability again\), the system first calls **OnForeground\(\)** to switch the Page ability to the **INACTIVE** state, and then calls **OnActive\(\)** to make it **ACTIVE**. You should use the **OnForeground\(\)** callback to reclaim the resources released in **OnBackground\(\)**. Currently, the **OnForeground\(\)** callback is unavailable to lite devices.
+
+ - **OnStop\(\)**
+
+ This callback is invoked when the system is destroying a Page ability due to one of the following possible causes:
+
+ - The user explicitly closes the Page ability using a system management feature, for example, the task manager.
+ - The user behavior, for example, exiting an application, triggers the **TerminateAbility\(\)** function on the Page ability.
+ - The system needs to temporarily destroy the Page ability and re-create it due to configuration changes.
+ - The system automatically destroys a Page ability in the **BACKGROUND** state due to resource management purposes.
+
+
+- **AbilityKit** is a development kit provided by the ability management framework. You can use this kit to develop applications based on the **Ability** component. There are two types of applications developed based on the **Ability** component: JS Ability developed using the JavaScript language and Native Ability developed using the C/C++ language. The JS application development framework encapsulates JavaScript UI components on the basis of the AbilityKit and is used to help you quickly develop JS Ability-based applications.
+- **AbilityLoader** is used to register and load **Ability** classes. After creating an **Ability** class, you should first call the registration API defined in **AbilityLoader** to register the **Ability** class name with the ability management framework so that this **Ability** can be instantiated when being started.
+
+- **AbilityManager** enables inter-process communication \(IPC\) between the AbilityKit and the Ability Manager Service.
+
+- **EventHandler** is provided by the AbilityKit to enable inter-thread communication between abilities.
+
+- The **Ability Manager Service** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. It consists of the following modules:
+
+ - The service startup module starts and registers the Ability Manager Service.
+ - The service interface management module manages external capabilities provided by the Ability Manager Service.
+ - The process management module starts and destroys processes where **Ability** instances are running, and maintains the process information.
+ - The ability stack management module maintains the presentation sequence of abilities in the stack.
+ - The lifecycle scheduling module changes an ability to a particular state based on the current operation of the system.
+ - The connection management module manages connections to Service abilities.
+
+- **AppSpawn** is a system service used to create the process for running an ability. This service has high permissions. It sets permissions for **Ability** instances and pre-loads some common modules to accelerate application startup.
+
+
+## Bundle Management Framework
+
+The bundle management framework is provided by OpenHarmony for you to manage application bundles.
+
+**Figure 4** Architecture of the bundle management framework
+
+
+- **BundleKit** includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners.
+- The **bundle scanning sub-module** parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage.
+- The **bundle installation sub-module** installs, uninstalls, and updates a bundle. The **bundle installation service** is an independent process that communicates with the Bundle Manager Service through IPC. It is used to create or delete installation directories and has high permissions.
+
+- The **bundle management sub-module** manages information related to application bundles and stores persistent bundle information.
+
+- The **bundle security management sub-module** verifies signatures, and grants and manages permissions.
+
+
+## Working Principles
+
+The Ability Manager Service and Bundle Manager Service are the core modules of the ability management framework and bundle management framework, respectively. The two system-level services are registered and discovered by using the system service framework SAMgr, and they are used by manage abilities and bundles for other processes. The Ability Manager Service and Bundle Manager Service are provided as open APIs in the AbilityKit and BundleKit.
+
+**Figure 5** Startup of the Ability Manager Service and Bundle Manager Service
+
+
+OpenHarmony applications can be installed and started after the two services are started.
+
+**Figure 6** Application startup process
+
+
+The home screen is the first OpenHarmony application started by the Ability Manager Service. After the home screen is started, the user can touch any installed OpenHarmony application on the home screen to start the particular application. The figure above shows the interaction process of starting an installed application from the home screen.
+
+As shown in the figure, the Ability Manager Service is responsible for displaying or hiding an ability, and the Bundle Manager Service is responsible for storing and querying ability information.
+
+## Limitations and Constraints
+
+- Language version
+
+ - C++ 11 or later
+
+
+- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities.
+
+ - Cortex-M RAM and ROM
+
+ - RAM: greater than 20 KB \(recommended\)
+
+ - ROM: greater than 300 KB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
+
+
+ - Cortex-A RAM and ROM
+
+ - RAM: greater than 2 MB \(recommended\)
+
+ - ROM: greater than 2 MB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
-**Table 1** Encoding and decoding specifications for different development boards
-
-
Device Type
-
-
Development Board
-
-
Decoding
-
-
Encoding
-
-
-
-
Cameras with a screen
-
-
Hi3516
-
-
Audio: The MPEG-4 AAC Profile (AAC LC), mono and dual channels, and the MPEG-4 (.mp4 and .m4a) container format are supported.
Video: The H.265 (HEVC) and H.264 (AVC) (for streams encoded using a chip of the same type) and the MPEG-4 (.mp4) container format are supported.
-
-
Audio: AAC-LC encoding, mono and dual channels, and the MPEG-4 (.mp4) container format are supported.
Video: H.264 and H.265 encoding and the MPEG-4 (.mp4) container format are supported.
-
-
-
Cameras without a screen
-
-
Hi3518
-
-
Audio: The MPEG-4 AAC Profile (AAC LC), mono and dual channels, and the MPEG-4 (.mp4 and .m4a) container format are supported.
Video: none
-
-
Audio: AAC-LC encoding, mono and dual channels, and the MPEG-4 (.mp4) container format are supported.
Video: H.264 and H.265 encoding and the MPEG-4 (.mp4) container format are supported.
-
-
-
WLAN connecting devices
-
-
Hi3861
-
-
N/A
-
-
N/A
-
-
-
-
-For details about the encoding and decoding specifications of Hi3516 and Hi3518, refer to their documentation.
diff --git a/en/device-dev/subsystems/overview-4.md b/en/device-dev/subsystems/overview-4.md
deleted file mode 100644
index be32c8ebf46f3db9ab43c7a48fc0556250a04b7b..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/overview-4.md
+++ /dev/null
@@ -1,148 +0,0 @@
-# Overview
-
-- [Basic Concepts](#section72601941194812)
-- [Ability Management Framework](#section14633111813374)
-- [Bundle Management Framework](#section1341146154412)
-- [Working Principles](#section94302021112717)
-- [Limitations and Constraints](#section89534912527)
-
-The application framework is provided by OpenHarmony for you to develop OpenHarmony applications. It consists of two modules: ability management framework \(also called the ability framework\) and bundle management framework.
-
-## Basic Concepts
-
-This section describes some basic concepts for you to better understand the OpenHarmony application framework before you start development.
-
-## Ability Management Framework
-
-The ability management framework manages running status of OpenHarmony applications.
-
-**Figure 1** Architecture of the ability management framework
-
-
-- **Ability** is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of templates that you can use to create an **Ability** instance: Page and Service.
- - An **Ability using the Page template** \(Page ability for short\) provides a UI for interacting with users.
-
- - An **Ability using the Service template** does not have a UI and is used for running background tasks.
-
-
-
-- An **AbilitySlice** represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities.
-
- **Figure 2** Relationship between a Page ability and its ability slices
- 
-
-- **Lifecycle** is a general term for all states of an ability, including **INITIAL**, **INACTIVE**, **ACTIVE**, and **BACKGROUND**.
-
- **Figure 3** Lifecycle state transition of a Page ability
-
-
- 
-
- - **OnStart\(\)**
-
- This callback is invoked when the system first creates the Page ability. After this callback is executed, the Page ability enters the **INACTIVE** state. This callback is triggered only once in the entire lifecycle of each Page ability. You must override this callback and set the default ability slice to be displayed.
-
- - **OnActive\(\)**
-
- This callback is invoked when the Page ability in the **INACTIVE** state enters the foreground. After this callback is executed, the Page ability enters the **ACTIVE** state, in which it becomes interactive. The Page ability will stay in this state unless it loses focus upon a certain event, for example, when the user touches the Back button or navigates to another Page ability.
-
- When such an event occurs, the Page ability returns to the **INACTIVE** state, and the system invokes the **OnInactive\(\)** callback. The Page ability may move to the **ACTIVE** state again, and the system will then invoke the **OnActive\(\)** callback again. You should implement both **OnActive\(\)** and **OnInactive\(\)** for a Page ability and use **OnActive\(\)** to obtain the resources released in **OnInactive\(\)**.
-
- - **OnInactive\(\)**
-
- This callback is invoked when the Page ability loses focus, and the Page ability then becomes **INACTIVE**. You can implement the behavior to perform after the Page ability loses focus.
-
- - **OnBackground\(\)**
-
- This callback is invoked based on the system resource status when the Page ability becomes invisible to the user. After this callback is executed, the Page ability enters the **BACKGROUND** state. You should release the resources that are no longer needed after the Page ability becomes invisible or perform time-consuming save operations in this callback.
-
- - **OnForeground\(\)**
-
- A Page ability in the **BACKGROUND** state still resides in memory. When the Page ability returns to the foreground \(for example, when the user navigates to this Page ability again\), the system first calls **OnForeground\(\)** to switch the Page ability to the **INACTIVE** state, and then calls **OnActive\(\)** to make it **ACTIVE**. You should use the **OnForeground\(\)** callback to reclaim the resources released in **OnBackground\(\)**. Currently, the **OnForeground\(\)** callback is unavailable to lite devices.
-
- - **OnStop\(\)**
-
- This callback is invoked when the system is destroying a Page ability due to one of the following possible causes:
-
- - The user explicitly closes the Page ability using a system management feature, for example, the task manager.
- - The user behavior, for example, exiting an application, triggers the **TerminateAbility\(\)** function on the Page ability.
- - The system needs to temporarily destroy the Page ability and re-create it due to configuration changes.
- - The system automatically destroys a Page ability in the **BACKGROUND** state due to resource management purposes.
-
-
-- **AbilityKit** is a development kit provided by the ability management framework. You can use this kit to develop applications based on the **Ability** component. There are two types of applications developed based on the **Ability** component: JS Ability developed using the JavaScript language and Native Ability developed using the C/C++ language. The JS application development framework encapsulates JavaScript UI components on the basis of the AbilityKit and is used to help you quickly develop JS Ability-based applications.
-- **AbilityLoader** is used to register and load **Ability** classes. After creating an **Ability** class, you should first call the registration API defined in **AbilityLoader** to register the **Ability** class name with the ability management framework so that this **Ability** can be instantiated when being started.
-
-- **AbilityManager** enables inter-process communication \(IPC\) between the AbilityKit and the Ability Manager Service.
-
-- **EventHandler** is provided by the AbilityKit to enable inter-thread communication between abilities.
-
-- The **Ability Manager Service** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. It consists of the following modules:
-
- - The service startup module starts and registers the Ability Manager Service.
- - The service interface management module manages external capabilities provided by the Ability Manager Service.
- - The process management module starts and destroys processes where **Ability** instances are running, and maintains the process information.
- - The ability stack management module maintains the presentation sequence of abilities in the stack.
- - The lifecycle scheduling module changes an ability to a particular state based on the current operation of the system.
- - The connection management module manages connections to Service abilities.
-
-- **AppSpawn** is a system service used to create the process for running an ability. This service has high permissions. It sets permissions for **Ability** instances and pre-loads some common modules to accelerate application startup.
-
-
-## Bundle Management Framework
-
-The bundle management framework is provided by OpenHarmony for you to manage application bundles.
-
-**Figure 4** Architecture of the bundle management framework
-
-
-- **BundleKit** includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners.
-- The **bundle scanning sub-module** parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage.
-- The **bundle installation sub-module** installs, uninstalls, and updates a bundle. The **bundle installation service** is an independent process that communicates with the Bundle Manager Service through IPC. It is used to create or delete installation directories and has high permissions.
-
-- The **bundle management sub-module** manages information related to application bundles and stores persistent bundle information.
-
-- The **bundle security management sub-module** verifies signatures, and grants and manages permissions.
-
-
-## Working Principles
-
-The Ability Manager Service and Bundle Manager Service are the core modules of the ability management framework and bundle management framework, respectively. The two system-level services are registered and discovered by using the system service framework SAMgr, and they are used by manage abilities and bundles for other processes. The Ability Manager Service and Bundle Manager Service are provided as open APIs in the AbilityKit and BundleKit.
-
-**Figure 5** Startup of the Ability Manager Service and Bundle Manager Service
-
-
-OpenHarmony applications can be installed and started after the two services are started.
-
-**Figure 6** Application startup process
-
-
-The home screen is the first OpenHarmony application started by the Ability Manager Service. After the home screen is started, the user can touch any installed OpenHarmony application on the home screen to start the particular application. The figure above shows the interaction process of starting an installed application from the home screen.
-
-As shown in the figure, the Ability Manager Service is responsible for displaying or hiding an ability, and the Bundle Manager Service is responsible for storing and querying ability information.
-
-## Limitations and Constraints
-
-- Language version
-
- - C++ 11 or later
-
-
-- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities.
-
- - Cortex-M RAM and ROM
-
- - RAM: greater than 20 KB \(recommended\)
-
- - ROM: greater than 300 KB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
-
-
- - Cortex-A RAM and ROM
-
- - RAM: greater than 2 MB \(recommended\)
-
- - ROM: greater than 2 MB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
-
-
-
-
diff --git a/en/device-dev/subsystems/overview-9.md b/en/device-dev/subsystems/overview-5.md
similarity index 100%
rename from en/device-dev/subsystems/overview-9.md
rename to en/device-dev/subsystems/overview-5.md
diff --git a/en/device-dev/subsystems/overview.md b/en/device-dev/subsystems/overview.md
index af871180f3042797494129e8a9a80e36e62a1ca7..dd3d44a6a412a87dad271137b77557eb4e7171dd 100644
--- a/en/device-dev/subsystems/overview.md
+++ b/en/device-dev/subsystems/overview.md
@@ -90,7 +90,7 @@ It is considered good practice that you understand the following concepts before
Similarly, you can create a surface, implement consumer logic for it, and transfer it to the **Camera** instance. For example, transmit video streams over the network or save captured frame data as an image file.
- The graphics module also obtains stream resources from the camera module through surfaces. For details, see development guidelines on [Graphic](graphics-2.md).
+ The graphics module also obtains stream resources from the camera module through surfaces. For details, see development guidelines on [Graphic](graphics-1.md).
- Camera running process
1. Creating a camera
diff --git a/en/device-dev/subsystems/plug-in.md b/en/device-dev/subsystems/plug-in.md
index 2a743f9dc6982779298802ff108d40fd27f0c5c6..70c27a3f371bb5214c842cece220807addaed08b 100644
--- a/en/device-dev/subsystems/plug-in.md
+++ b/en/device-dev/subsystems/plug-in.md
@@ -117,6 +117,8 @@ Algorithm plug-in APIs including **Prepare**, **SyncProcess**, **AsyncProcess
+For the data structure of **ConfigInfo**, **ClientInfo**, **AlgorithmInfo**, and **DataInfo**, see [Table 2](sdk.md#table22154317482) in the SDK development guidelines.
+
The **Request** and **Response** classes define the requests and responses used for communication between the AI engine server and algorithm plug-ins. A request encapsulates the request content and input data of the caller. The plug-in returns the calculation result to the AI engine server through a response.
[Table 3](#table16273647125120) describes the attributes of the **Request** class.
diff --git a/en/device-dev/subsystems/sdk.md b/en/device-dev/subsystems/sdk.md
index 5cc0b855635d383e046ae6c117a8d28428406da3..119cbc1e84f7f4c04e58f682a535759ddff30b6f 100644
--- a/en/device-dev/subsystems/sdk.md
+++ b/en/device-dev/subsystems/sdk.md
@@ -126,8 +126,6 @@ The function of the SDK header file is implemented by mapping SDK API calls to c
long long clientVersion: Indicates client version number. This parameter is not used currently.
int clientId: Indicates the client ID.
int sessionId: Indicates the session ID.
-
uid_t serverUid: Indicates the server UID.
-
uid_t clientUid: Indicates the client UID.
int extendLen: Indicates the length of the extended information (extendMsg).
unsigned char *extendMsg: Indicates the body of the extended information.
diff --git a/en/device-dev/subsystems/security.md b/en/device-dev/subsystems/security.md
index e69ec0072cf44c6314e688ce37d3a25bbe8df412..adc524ff7a08f0600470efb08bee7a096364f240 100644
--- a/en/device-dev/subsystems/security.md
+++ b/en/device-dev/subsystems/security.md
@@ -1,6 +1,6 @@
# Security
-- **[Overview](overview-9.md)**
+- **[Overview](overview-5.md)**
- **[Development Guidelines on Application Signature Verification](development-guidelines-on-application-signature-verification.md)**
@@ -8,6 +8,4 @@
- **[Development Guidelines on IPC Authentication](development-guidelines-on-ipc-authentication.md)**
-- **[Development Guidelines on Trusted Device Group Management](development-guidelines-on-trusted-device-group-management.md)**
-
diff --git a/en/device-dev/subsystems/startup-10.md b/en/device-dev/subsystems/startup-6.md
similarity index 100%
rename from en/device-dev/subsystems/startup-10.md
rename to en/device-dev/subsystems/startup-6.md
diff --git a/en/device-dev/subsystems/startup.md b/en/device-dev/subsystems/startup.md
index 5a2025350a8b09b4a2afd74af17e2dc4894efa53..7f8f4f3e5e9b0dfcc87ea25c5cdd6378c04e8d1a 100644
--- a/en/device-dev/subsystems/startup.md
+++ b/en/device-dev/subsystems/startup.md
@@ -1,6 +1,6 @@
# Startup
-- **[Startup](startup-10.md)**
+- **[Startup](startup-6.md)**
- **[init Module](init-module.md)**
diff --git a/en/device-dev/subsystems/xts.md b/en/device-dev/subsystems/xts.md
index 24396f880e05a6ed78dfcb41c8a78660ad469317..c4957d70f0ebf8fb52cf3a662ba9f75eecb5d834 100644
--- a/en/device-dev/subsystems/xts.md
+++ b/en/device-dev/subsystems/xts.md
@@ -456,6 +456,7 @@ The HCPPTest framework is enhanced and adapted based on the open-source framewor
]
cflags = [ "-Wno-error" ]
}
+
```
4. Add build options to the **BUILD.gn** file in the **acts** directory.
diff --git a/en/readme.md b/en/readme.md
index 6f5507767fb638dc4a82b16d8c40da15bc4bf0af..ef5b8c15a2391147b29899652fc8eea697efe8a6 100644
--- a/en/readme.md
+++ b/en/readme.md
@@ -1,77 +1,81 @@
-# WELCOME TO OPENHARMONY
+# Overview
+
This project stores OpenHarmony documentation, including the quick start guide, development guides, and API reference. We appreciate your contribution to the OpenHarmony documentation.
-## Motivation
-Traditional OSs are limited to a specific type of device, while OpenHarmony provides distributed features that are compatible with a wide range of different devices. The first version supports devices with 128 KB to 128 MB of memory. Join us as we keep updating OpenHarmony versions.
-For device developers, OpenHarmony utilizes a component-based design to tailor its features to better suit specific devices, based on each device's capabilities and service characteristics. OpenHarmony can run on devices with limited resources and wearables with hundreds of KB of memory, as well as more powerful devices, such as smart home cameras and dashcams with hundreds of MB of memory.
-
-[中文版本](../zh-cn/readme.md)
-
-## Device Development - Documentation Directory Structure
-- [Overview](device-dev/quick-start/overview.md)
-- [Getting Started](device-dev/quick-start/Readme-EN.md)
-- [Source Code Acquisition/Tool Acquisition](device-dev/get-code/Readme-EN.md)
-- [Kernel Usage Guidelines](device-dev/kernel/Readme-EN.md)
-- [Driver Usage Guidelines](device-dev/driver/Readme-EN.md)
-- [Subsystem Development Guidelines](device-dev/subsystems/Readme-EN.md)
- - [Compilation and Building](device-dev/subsystems/compilation-and-building.md)
- - [Distributed Remote Startup](device-dev/subsystems/distributed-remote-startup.md)
- - [Graphics](device-dev/subsystems/graphics.md)
- - [Multimedia](device-dev/subsystems/multimedia.md)
- - [Utils](device-dev/subsystems/utils.md)
- - [AI Framework](device-dev/subsystems/ai-framework.md)
- - [Sensors](device-dev/subsystems/sensors.md)
- - [Application Framework](device-dev/subsystems/application-framework.md)
- - [OTA Upgrade](device-dev/subsystems/ota-upgrade.md)
- - [Security](device-dev/subsystems/security.md)
- - [Startup](device-dev/subsystems/startup.md)
- - [Testing](device-dev/subsystems/testing.md)
- - [DFX](device-dev/subsystems/dfx.md)
- - [R&D Tools](device-dev/subsystems/r-d-tools.md)
- - [X Test Suite](device-dev/subsystems/xts.md)
-- [Bundle Development Guidelines](device-dev/bundles/Readme-EN.md)
-- [Third-Party Library Porting Guide](device-dev/porting/Readme-EN.md)
-- [Device Development Guidelines](device-dev/guide/Readme-EN.md)
- - [WLAN-connected Products](device-dev/guide/wlan-connected-products.md)
- - [Cameras Without a Screen](device-dev/guide/cameras-without-a-screen.md)
- - [Cameras with a Screen](device-dev/guide/cameras-with-a-screen.md)
- - [Visual Application Development](device-dev/guide/visual-application-development.md)
- - [Development Example for Clock Apps](device-dev/guide/development-example-for-clock-apps.md)
- - [Development Example for Platform Drivers](device-dev/guide/development-example-for-platform-drivers.md)
- - [Development Example for Peripheral Drivers](device-dev/guide/development-example-for-peripheral-drivers.md)
-- [Privacy and Security](device-dev/security/Readme-EN.md)
-- [Glossary](device-dev/glossary/glossary.md)
-
-# Application Development - Documentation Directory Structure
-
-- [Getting Started](application-dev/quick-start/getting-started.md)
-- [UI](application-dev/ui/Readme-EN.md)
-- [Media](application-dev/media/Readme-EN.md)
-- [Connectivity](application-dev/connectivity/Readme-EN.md)
-- [JS Reference](application-dev/js-reference/Readme-EN.md)
-
-## Start Contributing
-
-OpenHarmony is an open-source community and encourages everyone in the community to submit patches directly to the project. You can contribute either to the code or documentation.
-- [Contributing to the Code](contribute/contributing-code.md)
-- [Contributing to the Documentation](contribute/documentation-contribution.md)
-
-For more details on how to contribute, see [Contributing Documents](contribute).
-## Get Source Code and Tools
-To download the source code and tools required for the project, click the following links:
-- [Source Code Acquisition](device-dev/get-code/source-code-acquisition.md)
-- [Tool Acquisition](device-dev/get-code/tool-acquisition.md)
-
-## Where to Turn for Help
-You can subscribe to the mailing list to get constant updates on new features, released road maps, and community activities. For how to subscribe to the mailing list or get any other support, see [Communication in Community](https://gitee.com/openharmony/docs/tree/master/contribute/communication-in-community.md).
-
-## Code of Conduct
-OpenHarmony is committed to providing a welcoming and inspiring community for all. In order to maintain a collaborative environment, we recommend you read and follow the community [Code of Conduct](https://gitee.com/openharmony/docs/blob/master/contribute/code-of-conduct.md).
-
-## Contributors & Acknowledgements
-A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to participate in this exciting journey, and we're grateful for your time, passion, and efforts!
-
-## Release
-In order to provide new features and bug fixes, the community constantly updates code and provides new releases.
-
-See [OpenHarmony Release Notes](release-notes/OpenHarmony-Release-Notes.md).
\ No newline at end of file
+## Contents
+
+- [OpenHarmony Overview](OpenHarmony-Overview.md)
+- Mini and Small System Development Guidelines \(Reference Memory < 128 MB\)
+ - Device development
+ - **overview**: [device development overview](device-dev/overview.md)
+ - **quick-start**: [quick start guide](device-dev/quick-start/Readme-EN.md) \(covering environment setup, source code acquisition, build, and burning\)
+ - Basic development capabilities
+ - **Kernel**: [lite kernel](device-dev/kernel/kernel-for-mini-and-small-systems.md)
+ - **Drivers**: [drivers](device-dev/driver/Readme-EN.md)
+ - **Subsystems**: [subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\)
+ - **Security**: [privacy and security](device-dev/security/Readme-EN.md)
+
+ - **guide**: [guidelines](device-dev/guide/Readme-EN.md)
+ - [WLAN-connected products](device-dev/guide/wlan-connected-products.md) \(LED peripheral control and third-party SDK integration\)
+ - [Screenless cameras](device-dev/guide/cameras-without-a-screen.md) \(camera control\)
+ - [Cameras with a screen](device-dev/guide/cameras-with-a-screen.md) \(screen and camera control, visual application development\)
+
+ - **porting**: [porting adaptation](device-dev/porting/Readme-EN.md)
+ - [Third-Party SoC Porting Guide](device-dev/porting/third-party-soc-porting-guide.md)
+ - [Third-Party Library Porting Guide](device-dev/porting/third-party-library-porting-guide.md)
+
+ - **bundles**: [bundle development](device-dev/bundles/Readme-EN.md)
+ - [Development Specifications](device-dev/bundles/development-specifications.md)
+ - [Development Guidelines](device-dev/bundles/development-guidelines.md)
+ - [HPM User Guide](device-dev/bundles/hpm-user-guide.md)
+
+- Standard System Development Guidelines \(Reference Memory ≥ 128 MB\)
+ - Device development
+ - **overview**: [device development overview](device-dev/overview.md)
+ - **quick-start**: [quick start guide](device-dev/quick-start/Readme-EN.md) \(covering environment setup, source code acquisition, build, and burning\)
+ - Basic development capabilities
+ - **Kernel**: [Linux kernel](device-dev/kernel/Readme-EN.md)
+ - **Drivers**: [drivers](device-dev/driver/Readme-EN.md)
+ - **Subsystems**: [subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\)
+ - **Security**: [privacy and security](device-dev/security/Readme-EN.md)
+
+ - **guide**: [guidelines](device-dev/guide/Readme-EN.md)
+ - [Clock apps](device-dev/guide/development-example-for-clock-apps.md)
+ - [Platform drivers](device-dev/guide/development-example-for-platform-drivers.md)
+ - [Peripheral drivers](device-dev/guide/development-example-for-peripheral-drivers.md)
+
+ - **porting**: [porting adaptation](device-dev/porting/Readme-EN.md)
+ - [Third-Party SoC Porting Guide](device-dev/porting/third-party-soc-porting-guide.md)
+ - [Third-Party Library Porting Guide](device-dev/porting/third-party-library-porting-guide.md)
+
+ - **bundles**: [bundle development](device-dev/bundles/Readme-EN.md)
+ - [Development Specifications](device-dev/bundles/development-specifications.md)
+ - [Development Guidelines](device-dev/bundles/development-guidelines.md)
+ - [HPM User Guide](device-dev/bundles/hpm-user-guide.md)
+
+
+- App development
+ - **Overview**: [app development overview](application-dev/application-dev-guide.md)
+ - **quick-start**: [quick start guide](application-dev/quick-start/Readme-EN.md)
+ - **ui**: [UI](application-dev/ui/Readme-EN.md)
+ - **media**: [media](application-dev/media/Readme-EN.md)
+ - **connectivity**: [networks and connectivity](application-dev/connectivity/Readme-EN.md)
+ - **js-reference**: [JS reference](application-dev/js-reference/Readme-EN.md)
+- **glossary**: [glossary](device-dev/glossary/glossary.md)
+
+## Version Change History
+
+For details, see [Release Notes](release-notes/OpenHarmony-Release-Notes.md).
+
+## Third-Party Open-Source Software and License Notice
+
+None.
+
+## How to Contribute
+
+A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to [participate](contribute/contribution.md) in this exciting journey, and we're grateful for your time, passion, and efforts!
+
+You can evaluate available documents, make simple modifications, provide feedback on document quality, and contribute your original content. For details, see [Documentation Contribution](contribute/documentation-contribution.md).
+
+Excellent contributors will be awarded and the contributions will be publicized in the developer community.
+
diff --git a/zh-cn/device-dev/driver/GPIO.md b/zh-cn/device-dev/driver/GPIO.md
index afffef57ab689bd2220b0cc24b3323089b0e2d52..a5ce55f5d682843ec65e9c5247d2efc832053855 100755
--- a/zh-cn/device-dev/driver/GPIO.md
+++ b/zh-cn/device-dev/driver/GPIO.md
@@ -1,9 +1,560 @@
-# GPIO
+# GPIO
-- **[GPIO概述](GPIO概述.md)**
+- [概述](#section1635911016188)
+ - [接口说明](#section17715915181611)
-- **[GPIO使用指导](GPIO使用指导.md)**
+- [使用指导](#section259614242196)
+ - [使用流程](#section103477714216)
+ - [确定GPIO管脚号](#section370083272117)
+ - [使用API操作GPIO管脚](#section13604050132118)
-- **[GPIO使用实例](GPIO使用实例.md)**
+- [使用实例](#section25941262111)
+## 概述
+
+GPIO(General-purpose input/output)即通用型输入输出。通常,GPIO控制器通过分组的方式管理所有GPIO管脚,每组GPIO有一个或多个寄存器与之关联,通过读写寄存器完成对GPIO管脚的操作。
+
+GPIO接口定义了操作GPIO管脚的标准方法集合,包括:
+
+- 设置管脚方向: 方向可以是输入或者输出\(暂不支持高阻态\)
+
+- 读写管脚电平值: 电平值可以是低电平或高电平
+- 设置管脚中断服务函数:设置一个管脚的中断响应函数,以及中断触发方式
+- 使能和禁止管脚中断:禁止或使能管脚中断
+
+### 接口说明
+
+**表 1** GPIO驱动API接口功能介绍
+
+
+