!7794 翻译完成 6343：文档规范性修改-porting

Merge pull request !7794 from ester.zhou/TR-6343

en/device-dev/porting/porting-chip-board-driver.md

-# Board-Level Driver Adaptation<a name="EN-US_TOPIC_0000001153683028"></a>
+# Board-Level Driver Adaptation
 
 To implement board-level driver adaptation, perform the following steps:
 
-1.  Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony.
+1. Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony.
 
-    The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel.
+   The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel.
 
-    If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs.
+   If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs.
 
-    Here is an OS interface defined by a product for creating a queue:
+   Here is an OS interface defined by a product for creating a queue:
 
-    ```
-    bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size)
-    ```
+   
+   ```
+   bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size)
+   ```
 
-    The CMSIS API used for creating a queue is as follows:
+   The CMSIS API used for creating a queue is as follows:
 
-    ```
-    osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr);
-    ```
+   
+   ```
+   osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr);
+   ```
 
-    The following example shows how to adapt the OS interface to the CMSIS API:
+   The following example shows how to adapt the OS interface to the CMSIS API:
 
-    ```
-    #include "CMSIS_os2.h"
-    osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr);
-    bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size)
-    {
-    	(*pp_handle) = osMessageQueueNew (msg_num, msg_size, NULL);
-    	if((*pp_handle) == NULL){
-    		return FALSE;
-    	}
-    	return TRUE;
-    }
-    ```
+   
+   ```
+   #include "CMSIS_os2.h"
+   osMessageQueueId_t osMessageQueueNew (uint32_t msg_count, uint32_t msg_size, const osMessageQueueAttr_t *attr);
+   bool osif_msg_queue_create(void **pp_handle, uint32_t msg_num, uint32_t msg_size)
+   {
+   	(*pp_handle) = osMessageQueueNew (msg_num, msg_size, NULL);
+   	if((*pp_handle) == NULL){
+   		return FALSE;
+   	}
+   	return TRUE;
+   }
+   ```
 
-2.  Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the  **device**  directory of OpenHarmony as required.
+2. Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the **device** directory of OpenHarmony as required.
 
-    After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods:
+   After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods:
 
-    -   Compile the SDK independently and link it to the OpenHarmony project in the binary format.
-    -   Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code.
+   -   Compile the SDK independently and link it to the OpenHarmony project in the binary format.
+   -   Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code.
 
-3.  Verify the basic functions of the SDK.
+3. Verify the basic functions of the SDK.
 

en/device-dev/porting/porting-chip-faqs.md

-# FAQs<a name="EN-US_TOPIC_0000001153683024"></a>
+# FAQs
 
-## How Do I Mount the Heap Memory to the Kernel?<a name="section965418378552"></a>
 
--   The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the  **target\_config.h**  file.
+## How Do I Mount the Heap Memory to the Kernel?
 
-**Table  1**  Macros for configuring the kernel heap memory
+The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the **target\_config.h** file.
 
-<a name="table04172020563"></a>
-<table><thead align="left"><tr id="row5462035616"><th class="cellrowborder" valign="top" width="39.12%" id="mcps1.2.3.1.1"><p id="p1456204569"><a name="p1456204569"></a><a name="p1456204569"></a>Macro</p>
-</th>
-<th class="cellrowborder" valign="top" width="60.88%" id="mcps1.2.3.1.2"><p id="p19502005618"><a name="p19502005618"></a><a name="p19502005618"></a>Description</p>
-</th>
-</tr>
-</thead>
-<tbody><tr id="row14522018560"><td class="cellrowborder" valign="top" width="39.12%" headers="mcps1.2.3.1.1 "><p id="p35112025620"><a name="p35112025620"></a><a name="p35112025620"></a>LOSCFG_SYS_EXTERNAL_HEAP</p>
-</td>
-<td class="cellrowborder" valign="top" width="60.88%" headers="mcps1.2.3.1.2 "><p id="p5127138175710"><a name="p5127138175710"></a><a name="p5127138175710"></a>Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is <strong id="b161891157141719"><a name="b161891157141719"></a><a name="b161891157141719"></a>0</strong> and indicates that the internal heap memory whose size is <strong id="b116218121820"><a name="b116218121820"></a><a name="b116218121820"></a>0x10000</strong> will be used. If you want to use the external heap memory, set this macro to <strong id="b2744657141814"><a name="b2744657141814"></a><a name="b2744657141814"></a>1</strong>.</p>
-</td>
-</tr>
-<tr id="row20514209567"><td class="cellrowborder" valign="top" width="39.12%" headers="mcps1.2.3.1.1 "><p id="p5532017563"><a name="p5532017563"></a><a name="p5532017563"></a>LOSCFG_SYS_HEAP_ADDR</p>
-</td>
-<td class="cellrowborder" valign="top" width="60.88%" headers="mcps1.2.3.1.2 "><p id="p65520125619"><a name="p65520125619"></a><a name="p65520125619"></a>Specifies the start address of the kernel heap memory.</p>
-</td>
-</tr>
-<tr id="row15302929115615"><td class="cellrowborder" valign="top" width="39.12%" headers="mcps1.2.3.1.1 "><p id="p113021529145612"><a name="p113021529145612"></a><a name="p113021529145612"></a>LOSCFG_SYS_HEAP_SIZE</p>
-</td>
-<td class="cellrowborder" valign="top" width="60.88%" headers="mcps1.2.3.1.2 "><p id="p1030252965619"><a name="p1030252965619"></a><a name="p1030252965619"></a>Specifies the size of the kernel heap memory, that is, size of the memory block specified by <strong id="b1611815991419"><a name="b1611815991419"></a><a name="b1611815991419"></a>LOSCFG_SYS_HEAP_ADDR</strong>.</p>
-</td>
-</tr>
-</tbody>
-</table>
+**Table  1**  Macros for configuring the kernel heap memory
 
--   Note:
+| Macro | Description |
+| -------- | -------- |
+| LOSCFG_SYS_EXTERNAL_HEAP | Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is **0** and indicates that the internal heap memory whose size is **0x10000** will be used. If you want to use the external heap memory, set this macro to **1**. |
+| LOSCFG_SYS_HEAP_ADDR | Specifies the start address of the kernel heap memory. |
+| LOSCFG_SYS_HEAP_SIZE | Specifies the size of the kernel heap memory, that is, size of the memory block specified by **LOSCFG_SYS_HEAP_ADDR**. |
 
-Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption.
 
+> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
+> Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption.

en/device-dev/porting/standard-system-porting-guide.md

@@ -87,7 +87,7 @@ After the build is complete, you can view the built image file in **//out/{*devi
 Now, you need to port the Linux kernel to enable it to run successfully.
 
 
-### 1. Adding a Kernel-built Subsystem to the SoC
+### Adding a Kernel-built Subsystem to the SoC
 
 Add the following subsystem configuration to the **//build/subsystem_config.json** file:
 
@@ -104,7 +104,7 @@ Add the following subsystem configuration to the **//build/subsystem_config.json
 Then, open the configuration file **//vendor/MyProductVendor/MyProduct/config.json** and add the new subsystem to the product.
 
 
-### 2. Building the Kernel
+### Building the Kernel
 
 The OpenHarmony source code provides the Linux kernel 4.19, which is archived in **//kernel/linux-4.19**. This section uses this kernel version as an example to describe how to build the kernel.
 
@@ -132,7 +132,7 @@ The expected build result described in the table below.
 | $root_build_dir/packages/phone/images/uboot | Bootloader image.|
 
 
-### 3. Verifying the Porting
+### Verifying the Porting
 
 Now start build, and check whether the kernel image is generated as expected.
 
@@ -166,7 +166,7 @@ Now start build, and check whether the kernel image is generated as expected.
 ## Porting the HDF Driver
 
 
-### 1. LCD
+### LCD
 
 This section describes how to port a Liquid Crystal Display (LCD) driver. The hardware driver framework (HDF) designs a driver model for the LCD. To support an LCD, you must compile a driver, generate a model instance in the driver, and register the instance.
 
@@ -220,7 +220,7 @@ root {
 For details about driver development, see [LCD](../driver/driver-peripherals-lcd-des.md).
 
 
-### 2. Touchscreen
+### Touchscreen
 
 This section describes how to port a touchscreen driver. The touchscreen driver is stored in the **//drivers/framework/model/input/driver/touchscreen** directory. To port a touchscreen driver, register a **ChipDevice** model instance.
 
@@ -280,7 +280,7 @@ Implement the following APIs in **ChipDevice**:
 For details about driver development, see [Touchscreen](../driver/driver-peripherals-touch-des.md).
 
 
-### 3. WLAN
+### WLAN
 
 The WLAN driver is divided into two parts. One of the parts manages WLAN devices, and the other part manages WLAN traffic. HDF WLAN provides abstraction for the two parts. Currently, only the WLAN with the SDIO interface is supported.