Parameter
@@ -159,7 +159,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
int32\_t GpioRead\(uint16\_t gpio, uint16\_t \*val\);
- **Table 3** Description of GpioRead
+ **Table 3** Description of GpioRead
Parameter
@@ -199,7 +199,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
int32\_t GpioWrite\(uint16\_t gpio, uint16\_t val\);
- **Table 4** Description of GpioWrite
+ **Table 4** Description of GpioWrite
Parameter
@@ -269,7 +269,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
int32\_t GpioSetIrq\(uint16\_t gpio, uint16\_t mode, GpioIrqFunc func, void \*arg\);
- **Table 5** Description of GpioSetIrq
+ **Table 5** Description of GpioSetIrq
Parameter
@@ -316,13 +316,13 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
|
> **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.
+ >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
+ **Table 6** Description of GpioUnSetIrq
Parameter
@@ -357,7 +357,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
int32\_t GpioEnableIrq\(uint16\_t gpio\);
- **Table 7** Description of GpioEnableIrq
+ **Table 7** Description of GpioEnableIrq
Parameter
@@ -395,7 +395,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll
int32\_t GpioDisableIrq\(uint16\_t gpio\);
- **Table 8** Description of GpioDisableIrq
+ **Table 8** Description of GpioDisableIrq
Parameter
@@ -545,5 +545,4 @@ static int32_t TestCaseGpioIrqEdge(void)
(void)GpioUnSetIrq(gpio);
return (g_irqCnt > 0) ? HDF_SUCCESS : HDF_FAILURE;
}
-```
-
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-gpio-develop.md b/en/device-dev/driver/driver-platform-gpio-develop.md
index 2851ea6e4d09546309d6bd6f8767a2cbcf9cf6e0..7b14fa0201ec5c172854a1bcbeac6bdd6d5937b7 100644
--- a/en/device-dev/driver/driver-platform-gpio-develop.md
+++ b/en/device-dev/driver/driver-platform-gpio-develop.md
@@ -2,9 +2,9 @@
## Overview
-In the Hardware Driver Foundation \(HDF\) framework, the general-purpose input/output \(GPIO\) module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
+In the Hardware Driver Foundation \(HDF\) framework, the general-purpose input/output \(GPIO\) module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
-**Figure 1** Service-free mode
+**Figure 1** Service-free mode
## Available APIs
@@ -26,7 +26,7 @@ struct GpioMethod {
int32_t (*disableIrq)(struct GpioCntlr *cntlr, uint16_t local);
}
```
-**Table 1** Callbacks for the members in the GpioMethod structure
+**Table 1** Callbacks for the members in the GpioMethod structure
Callback
@@ -152,32 +152,30 @@ The GPIO controller manages all pins by group. The related parameters are descri
The GPIO module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **gpio\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **gpio\_config.hcs** file.
3. Instantiate the GPIO controller object.
- - Initialize **GpioCntlr**.
- - Instantiate **GpioMethod** in the **GpioCntlr** object.
+ - Initialize **GpioCntlr**.
+ - Instantiate **GpioMethod** in the **GpioCntlr** object.
- > **NOTE:**
- >For details, see [Available APIs](#section752964871810).
-
+ For details, see [Available APIs](#section752964871810).
-4. Debug the driver.
- - \(Optional\) For new drivers, verify the basic functions, such as the GPIO control status and response to interrupts.
+4. \(Optional\) Debug the driver.
+ For new drivers, verify the basic functions, such as the GPIO control status and response to interrupts.
## Development Example
-The following uses **gpio\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **gpio\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
- GPIO driver entry reference
@@ -193,11 +191,11 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
HDF_INIT(g_gpioDriverEntry);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **gpio\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **GpioCntlr** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **gpio\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **GpioCntlr** members at the core layer.
- In this example, there is only one GPIO controller. If there are multiple GPIO controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **gpio\_config** file.
+ In this example, there is only one GPIO controller. If there are multiple GPIO controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **gpio\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -220,7 +218,7 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
}
```
- - **gpio\_config.hcs** configuration reference
+ - **gpio\_config.hcs** configuration reference
```
root {
@@ -240,10 +238,10 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
}
```
-3. Initialize the **GpioCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **GpioMethod** \(used to call underlying functions of the driver\) in **GpioCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **GpioCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **GpioMethod** \(used to call underlying functions of the driver\) in **GpioCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **gpio\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the index and the number of pins, are also passed to the **GpioCntlr** object at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **gpio\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the index and the number of pins, are also passed to the **GpioCntlr** object at the core layer.
```
struct Pl061GpioCntlr {
@@ -279,7 +277,7 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
};
```
- - Instantiate the callback function structure **GpioMethod** in **GpioCntlr**. Other members are initialized by using the **Init** function.
+ - Instantiate the callback function structure **GpioMethod** in **GpioCntlr**. Other members are initialized by using the **Init** function.
```
// The members of the GpioMethod structure are all callbacks. Vendors need to implement the corresponding functions according to [Table 1](#table151341544111).
@@ -304,13 +302,13 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
- **Table 2** Init function description
+ **Table 2** Init function description
Status (Value)
@@ -354,7 +352,7 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
Function description:
- Initializes the custom structure object and **GpioCntlr**, calls the **GpioCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
+ Initializes the custom structure object and **GpioCntlr**, calls the **GpioCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
```
static int32_t Pl061GpioInit(struct HdfDeviceObject *device)
@@ -392,7 +390,7 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -400,7 +398,7 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
@@ -421,8 +419,4 @@ The following uses **gpio\_hi35xx.c** as an example to present the contents th
OsalIoUnmap((void *)pl061->regBase);// (Mandatory) Remove the address mapping.
pl061->regBase = NULL;
}
- ```
-
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-hdmi-des.md b/en/device-dev/driver/driver-platform-hdmi-des.md
index aed0b9264778f64ea67de43989a793f18f1be811..16927b0fff02c7bc751393f49816ca231c8434cb 100644
--- a/en/device-dev/driver/driver-platform-hdmi-des.md
+++ b/en/device-dev/driver/driver-platform-hdmi-des.md
@@ -5,15 +5,15 @@
### HDMI
-- High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display.
-- HDMI works in master/slave mode and usually has a source and a sink.
-- The HDMI APIs provide a set of common functions for HDMI transmission, including:
+High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display.
+HDMI works in primary/secondary mode and usually has a source and a sink.
+The HDMI APIs provide a set of common functions for HDMI transmission, including:
- - Opening and closing an HDMI controller
- - Starting and stopping HDMI transmission
- - Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute
- - Reading the raw Extended Display Identification Data (EDID) from a sink
- - Registering and unregistering a callback for HDMI hot plug detect (HPD).
+- Opening and closing an HDMI controller
+- Starting and stopping HDMI transmission
+- Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute
+- Reading the raw Extended Display Identification Data (EDID) from a sink
+- Registering and unregistering a callback for HDMI hot plug detect (HPD).
### Basic Concepts
@@ -88,7 +88,7 @@ DevHandle HdmiOpen(int16_t number);
| Parameter | Description |
| ---------- | -------------------- |
| number | HDMI controller ID. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| NULL | Failed to open the HDMI controller. |
| Controller handle| Handle of the opened HDMI controller.|
@@ -117,7 +117,7 @@ int32_t HdmiRegisterHpdCallbackFunc(DevHandle handle, struct HdmiHpdCallbackInfo
| ---------- | ------------------ |
| handle | HDMI controller handle. |
| callback | Pointer to the callback to be invoked to return the HPD result.|
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation failed. |
@@ -165,7 +165,7 @@ int32_t HdmiReadSinkEdid(DevHandle handle, uint8_t *buffer, uint32_t len);
| handle | HDMI controller handle. |
| buffer | Pointer to the data buffer. |
| len | Data length. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| Positive integer | Raw EDID read.|
| Negative number or 0 | Failed to read the EDID. |
@@ -194,7 +194,7 @@ int32_t HdmiSetAudioAttribute(DevHandle handle, struct HdmiAudioAttr *attr);
| ------ | -------------- |
| handle | HDMI controller handle.|
| attr | Pointer to the audio attributes. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation failed. |
@@ -295,7 +295,7 @@ int32_t HdmiAvmuteSet(DevHandle handle, bool enable);
| ---------- | ----------------- |
| handle | HDMI controller handle. |
| enable | Whether to enable the AV mute feature.|
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation failed. |
@@ -615,4 +615,4 @@ static int32_t TestCaseHdmi(void)
return 0;
}
-```
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-hdmi-develop.md b/en/device-dev/driver/driver-platform-hdmi-develop.md
index 56e47fa0bf12ad68ace3f8460e4ed0a5c687f569..81597bf7b61d98dce8a3ed210aaffe06e3782298 100644
--- a/en/device-dev/driver/driver-platform-hdmi-develop.md
+++ b/en/device-dev/driver/driver-platform-hdmi-develop.md
@@ -40,7 +40,7 @@ Currently, the HDMI module supports only the kernels (LiteOS) of mini and small
HDMI features high transmission rate, wide transmission bandwidth, high compatibility, and can transmit uncompressed audio and video signals. Compared with the traditional full analog interface, HDMI simplifies connection between devices and provides HDMI-specific intelligent features, which are ideal for high-quality audio and video transmission of small-sized devices.
### Available APIs
- **HdmiCntlrOps**:
+ **HdmiCntlrOps**:
```c
struct HdmiCntlrOps {
@@ -149,7 +149,7 @@ The HDMI module adaptation involves the following steps:
.Bind = HdmiAdapterBind,
.Init = HdmiAdapterInit,
.Release = HdmiAdapterRelease,
- .moduleName = "adapter_hdmi_driver",// (mandatory) The value must be the same as that in the .hcs file.
+ .moduleName = "adapter_hdmi_driver",// (Mandatory) The value must be the same as that in the .hcs file.
};
HDF_INIT(g_hdmiDriverEntry); // Call HDF_INIT to register the driver entry with the HDF.
```
@@ -315,11 +315,11 @@ The HDMI module adaptation involves the following steps:
- **Bind()** function
- **Input parameter**:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ **Input parameter**:
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
- **Return value**:
- **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** definition in the **/drivers/framework/include/utils/hdf\_base.h file**.)
+ **Return value**:
+ **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** definition in the **/drivers/framework/include/utils/hdf\_base.h file**.)
| State | Description |
|:-|:-|
@@ -330,7 +330,7 @@ The HDMI module adaptation involves the following steps:
|HDF_SUCCESS |Transmission successful.|
|HDF_FAILURE |Transmission failed.|
- **Function description**:
+ **Function description**:
Initializes the custom structure object **HdmiAdapterHost** and **HdmiCntlr**, and calls the **HdmiCntlrAdd** function to add the HDMI controller to the core layer.
The **HdmiCntlr**, **HdmiAdapterHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully.
@@ -374,13 +374,13 @@ The HDMI module adaptation involves the following steps:
- **Init()** function
- **Input parameter**:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ **Input parameter**:
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
- **Return value**:
+ **Return value**:
HDF_STATUS
- **Function description**:
+ **Function description**:
Implements the **HdmiAdapterInit** function.
@@ -393,13 +393,13 @@ The HDMI module adaptation involves the following steps:
- **Release()** function
- **Input parameter**:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ **Input parameter**:
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
- **Return value**:
+ **Return value**:
–
- **Function description**:
+ **Function description**:
Releases the memory and deletes the controller. This function assigns a value to the **Release()** API in the driver entry structure. If the HDF fails to call the **Init()** function to initialize the driver, the **Release()** function can be called to release driver resources.
```c
diff --git a/en/device-dev/driver/driver-platform-i2c-develop.md b/en/device-dev/driver/driver-platform-i2c-develop.md
index c5dddbd42ffdf3234046dfca56689dd44eeb15c5..95242cdf55c1b6201eca088b009b9773dedccde8 100644
--- a/en/device-dev/driver/driver-platform-i2c-develop.md
+++ b/en/device-dev/driver/driver-platform-i2c-develop.md
@@ -6,7 +6,7 @@
The Inter-Integrated Circuit \(I2C\) bus is a simple and bidirectional two-wire synchronous serial bus developed by Philips. In the Hardware Driver Foundation (HDF) framework, the I2C module uses the unified service mode for API adaptation. In this mode, a device service is used as the I2C manager to handle external access requests in a unified manner, which is reflected in the configuration file. The unified service mode applies to the scenario where there are many device objects of the same type, for example, when the I2C module has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services.
-**Figure 1** Unified service mode
+**Figure 1** Unified service mode
## Available APIs
@@ -23,7 +23,7 @@ struct I2cLockMethod {// Lock mechanism operation structure
};
```
-**Table 1** Callbacks for the members in the I2cMethod structure
+**Table 1** Callbacks for the members in the I2cMethod structure
Callback
@@ -57,41 +57,39 @@ struct I2cLockMethod {// Lock mechanism operation structure
The I2C module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **i2c\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **i2c\_config.hcs** file.
3. Instantiate the I2C controller object.
- - Initialize **I2cCntlr**.
- - Instantiate **I2cMethod** and **I2cLockMethod** in **I2cCntlr**.
+ - Initialize **I2cCntlr**.
+ - Instantiate **I2cMethod** and **I2cLockMethod** in **I2cCntlr**.
- > **NOTE**
+ For details, see [Available APIs](#available-apis).
+
+4. \(Optional\) Debug the driver.
- >For details, see [Available APIs](#available-apis).
-
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
+ For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
## Development Example
-The following uses **i2c\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **i2c\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
- I2C driver entry reference
Many devices may be connected to the I2C module. Therefore, in the HDF framework, a manager object is created for the I2C, and a manager service is launched to handle external access requests in a unified manner. When a user wants to open a device, the user obtains the manager service first. Then, the manager service locates the target device based on the parameters specified by the user.
- The driver of the I2C manager is implemented by the core layer. Vendors do not need to pay attention to the implementation of this part. However, when they implement the **Init** function, the **I2cCntlrAdd** function of the core layer must be called to implement the corresponding features.
+ The driver of the I2C manager is implemented by the core layer. Vendors do not need to pay attention to the implementation of this part. However, when they implement the **Init** function, the **I2cCntlrAdd** function of the core layer must be called to implement the corresponding features.
```
struct HdfDriverEntry g_i2cDriverEntry = {
@@ -113,11 +111,11 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
HDF_INIT(g_i2cManagerEntry);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **i2c\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or value ranges of the **I2cCntlr** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **i2c\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or value ranges of the **I2cCntlr** members at the core layer.
- In the unified service mode, the first device node in the **device\_info** file must be the I2C manager. [Table 2](#table96651915911) lists settings of its parameters.
+ In the unified service mode, the first device node in the **device\_info** file must be the I2C manager. [Table 2](#table96651915911) lists settings of its parameters.
- **Table 2** Settings of the I2C manager
+ **Table 2** Settings of the I2C manager
Member
@@ -149,9 +147,9 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
|
|---|
- Configure I2C controller information from the second node. This node specifies a type of I2C controllers rather than an I2C controller. The **busID** and **reg\_pbase** parameters distinguish controllers, which can be seen in the **i2c\_config** file.
+ Configure I2C controller information from the second node. This node specifies a type of I2C controllers rather than an I2C controller. The **busID** and **reg\_pbase** parameters distinguish controllers, which can be seen in the **i2c\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -180,7 +178,7 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
}
```
- - **i2c\_config.hcs** configuration reference
+ - **i2c\_config.hcs** configuration reference
```
root {
@@ -208,10 +206,10 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
}
```
-3. Initialize the **I2cCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **I2cMethod** \(used to call underlying functions of the driver\) in **I2cCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **I2cCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **I2cMethod** \(used to call underlying functions of the driver\) in **I2cCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **i2c\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the **I2cCntlr** object at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **i2c\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the **I2cCntlr** object at the core layer.
```
// Vendor custom function structure
@@ -238,7 +236,7 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
};
```
- - Instantiate the member callback function structure **I2cMethod** in **I2cCntlr** and the lock callback function structure **I2cLockMethod**. Other members are initialized by using the **Init** function.
+ - Instantiate the member callback function structure **I2cMethod** in **I2cCntlr** and the lock callback function structure **I2cLockMethod**. Other members are initialized by using the **Init** function.
```
// Example in i2c_hi35xx.c
@@ -256,13 +254,13 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
- **Table 3** Input parameters and return values of the Init function
+ **Table 3** Input parameters and return values of the Init function
Status (Value)
@@ -306,7 +304,7 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
Function description:
- Initializes the custom structure object and **I2cCntlr**, calls the **I2cCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
+ Initializes the custom structure object and **I2cCntlr**, calls the **I2cCntlrAdd** function at the core layer, and connects to the VFS \(optional\).
```
static int32_t Hi35xxI2cInit(struct HdfDeviceObject *device)
@@ -358,7 +356,7 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -366,7 +364,7 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
```
static void Hi35xxI2cRelease(struct HdfDeviceObject *device)
@@ -394,7 +392,4 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
}
return;
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-i3c-develop.md b/en/device-dev/driver/driver-platform-i3c-develop.md
index e5b08e2067c5c2dd01c39b64dc7d1b4f48364fa1..d67a87a16021b40aaad68ef3f78736876ebc8bb4 100644
--- a/en/device-dev/driver/driver-platform-i3c-develop.md
+++ b/en/device-dev/driver/driver-platform-i3c-develop.md
@@ -24,7 +24,7 @@ The Improved Inter-Integrated Circuit (I3C) is a simple and cost-efficient bidir
};
```
- **Table 1** APIs for the members in the I3cMethod structure
+ **Table 1** APIs for the members in the I3cMethod structure
|Method|Input Parameter|Output Parameter|Return Value|Description|
|-|-|-|-|-|
@@ -52,7 +52,9 @@ The I3C module adaptation involves the following steps:
3. Instantiate the I3C controller object.
- Initialize **I3cCntlr**.
- - Instantiate **I3cMethod** in **I3cCntlr**. For details, see [Available APIs](#available-apis).
+ - Instantiate **I3cMethod** in **I3cCntlr**.
+
+ For details, see [Available APIs](#available-apis).
4. Register an interrupt handler.
Register an interrupt handler for the controller to implement the device hot-join and in-band interrupt (IBI) features.
@@ -197,7 +199,7 @@ The I3C module adaptation involves the following steps:
- **Init** function
> Input parameter:
- > **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ > **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
>
> Return value:
> **HDF_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** definition in the **/drivers/framework/include/utils/hdf\_base.h file**.)
@@ -410,4 +412,4 @@ The I3C module adaptation involves the following steps:
return HDF_SUCCESS;
}
- ```
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-mipicsi-develop.md b/en/device-dev/driver/driver-platform-mipicsi-develop.md
index 4c84061f5cf79be998c1ed5dca454b6376566abc..cacae8bec96acc1a2d8ba3630d671282eaf1276f 100644
--- a/en/device-dev/driver/driver-platform-mipicsi-develop.md
+++ b/en/device-dev/driver/driver-platform-mipicsi-develop.md
@@ -1,15 +1,10 @@
# MIPI CSI
-- [Overview](#section72226945170128)
-- [Available APIs](#section735525713405)
-- [How to Develop](#section378858277170128)
-- [Development Example](#section2049027816170128)
-
## Overview
Defined by the Mobile Industry Processor Interface \(MIPI\) Alliance, the Camera Serial Interface \(CSI\) is a specification that allows data to be transmitted from the camera to the host processor on mobile platforms. In the Hardware Driver Foundation \(HDF\), the MIPI CSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS that does not distinguish the user mode and the kernel mode. In the service-free mode, DevHandle \(a void pointer\) directly points to the kernel-mode address of the device object.
-**Figure 1** Service-free mode
+**Figure 1** Service-free mode
@@ -34,7 +29,7 @@ struct MipiCsiCntlrMethod {
};
```
-**Table 1** Callbacks for the members in the MipiCsiCntlrMethod structure
+**Table 1** Callbacks for the members in the MipiCsiCntlrMethod structure
Callback
@@ -202,35 +197,33 @@ struct MipiCsiCntlrMethod {
The MIPI CSI module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **mipicsi\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **mipicsi\_config.hcs** file.
3. Instantiate the MIPI CSI controller object.
- - Initialize **MipiCsiCntlr**.
- - Instantiate **MipiCsiCntlrMethod** in the **MipiCsiCntlr** object.
-
- > **NOTE:**
- >For details, see [Available APIs](#available-apis).
+ - Initialize **MipiCsiCntlr**.
+ - Instantiate **MipiCsiCntlrMethod** in the **MipiCsiCntlr** object.
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
+ For details, see [Available APIs](#available-apis).
+
+4. \(Optional\) Debug the driver.
+ For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
## Development Example
-The following uses **mipi\_rx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **mipi\_rx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Generally, you need to configure the device attributes in **busxx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiCsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
+1. Generally, you need to configure the device attributes in **busxx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiCsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
> **NOTE:**
- >In this example, the MIPI controller attributes are defined in the source file. If required, add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the** mipicsi\_config.hcs** file.
+ >In this example, the MIPI controller attributes are defined in the source file. If required, add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the** mipicsi\_config.hcs** file.
- **device\_info.hcs** configuration reference:
+ **device\_info.hcs** configuration reference:
```
root {
@@ -253,9 +246,9 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
}
```
-2. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+2. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, the HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit.
+ Generally, the HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit.
MIPI CSI driver entry reference:
@@ -269,11 +262,11 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
HDF_INIT(g_mipiCsiDriverEntry); // Call HDF_INIT to register the driver entry with the HDF.
```
-3. Initialize the **MipiCsiCntlr** object at the core layer, including initializing the vendor custom structure \(passing parameters and data\), instantiating **MipiCsiCntlrMethod** \(used to call underlying functions of the driver\) in **MipiCsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **MipiCsiCntlr** object at the core layer, including initializing the vendor custom structure \(passing parameters and data\), instantiating **MipiCsiCntlrMethod** \(used to call underlying functions of the driver\) in **MipiCsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference:
> **NOTE:**
- >To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI CSI attributes are defined in the source file. Therefore, the basic member structure is similar to that of **MipiCsiCntlr**.
+ >To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI CSI attributes are defined in the source file. Therefore, the basic member structure is similar to that of **MipiCsiCntlr**.
```
typedef struct {
@@ -328,7 +321,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
};
```
- - **\(Important\)** Instantiate the callback function structure **MipiCsiCntlrMethod** in **MipiCsiCntlr**. Other members are initialized by using the **Init** function.
+ - **\(Important\)** Instantiate the callback function structure **MipiCsiCntlrMethod** in **MipiCsiCntlr**. Other members are initialized by using the **Init** function.
```
static struct MipiCsiCntlrMethod g_method = {
@@ -351,11 +344,11 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **/drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **/drivers/framework/include/utils/hdf\_base.h** file.\)
Status (Value)
@@ -399,7 +392,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
Function description:
- Connects to the **MipiCsiCntlrMethod** instance, calls **MipiCsiRegisterCntlr**, and performs other vendor-defined initialization operations.
+ Connects to the **MipiCsiCntlrMethod** instance, calls **MipiCsiRegisterCntlr**, and performs other vendor-defined initialization operations.
```
static int32_t Hi35xxMipiCsiInit(struct HdfDeviceObject *device)
@@ -408,9 +401,9 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
HDF_LOGI("%s: enter!", __func__);
g_mipiCsi.priv = NULL; // g_mipiTx is a global variable defined.
- //static struct MipiCsiCntlr g_mipiCsi = {
- //.devNo = 0
- //};
+ // static struct MipiCsiCntlr g_mipiCsi = {
+ // .devNo = 0
+ // };
g_mipiCsi.ops = &g_method; // Connect to the MipiCsiCntlrMethod instance.
#ifdef CONFIG_HI_PROC_SHOW_SUPPORT
g_mipiCsi.debugs = &g_debugMethod;
@@ -468,7 +461,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -476,7 +469,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
static void Hi35xxMipiCsiRelease(struct HdfDeviceObject *device)
@@ -484,7 +477,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
struct MipiCsiCntlr *cntlr = NULL;
...
cntlr = MipiCsiCntlrFromDevice(device); // A forced conversion from HdfDeviceObject to MipiCsiCntlr is involved.
- //return (device == NULL) ? NULL : (struct MipiCsiCntlr *)device->service;
+ // return (device == NULL) ? NULL : (struct MipiCsiCntlr *)device->service;
...
OsalSpinDestroy(&cntlr->ctxLock);
@@ -497,7 +490,4 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
HDF_LOGI("%s: unload mipi csi driver success!", __func__);
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-mipidsi-des.md b/en/device-dev/driver/driver-platform-mipidsi-des.md
index c7cecdc8e1c4a9d2d661ea1d3a9f072cae36ff66..3845f8078cbba3d796b8a9061158eef306360aba 100644
--- a/en/device-dev/driver/driver-platform-mipidsi-des.md
+++ b/en/device-dev/driver/driver-platform-mipidsi-des.md
@@ -2,18 +2,18 @@
## 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.
+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.
+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
+ **Figure 1** DSI transmitting and receiving interface
## Available APIs
-**Table 1** APIs for MIPI DSI
+**Table 1** APIs for MIPI DSI
Capability
@@ -75,25 +75,25 @@
|
|---|
-> **NOTE:**
+> **NOTE**
>All functions described in this document can be called only in kernel space.
## Usage Guidelines
### How to Use
-[Figure 2](#fig129103491241) shows the process of using a MIPI DSI device.
+[Figure 2](#fig129103491241) shows the process of using a MIPI DSI device.
-**Figure 2** Process of using a MIPI DSI device
+**Figure 2** 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.
+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**
+**Table 2** Description of **MipiDsiOpen**
Parameter
@@ -125,7 +125,7 @@ DevHandle MipiDsiOpen\(uint8\_t id\);
|
|---|
-The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
+The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
```
DevHandle mipiDsiHandle = NULL; /* Device handle */
@@ -145,7 +145,7 @@ if (mipiDsiHandle == NULL) {
int32\_t MipiDsiSetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
-**Table 3** Description of **MipiDsiSetCfg**
+**Table 3** Description of **MipiDsiSetCfg**
Parameter
@@ -213,7 +213,7 @@ if (ret != 0) {
int32\_t MipiDsiGetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
-**Table 4** Description of **MipiDsiGetCfg**
+**Table 4** Description of **MipiDsiGetCfg**
Parameter
@@ -267,7 +267,7 @@ if (ret != HDF_SUCCESS) {
int32\_t MipiDsiTx\(PalHandle handle, struct DsiCmdDesc \*cmd\);
-**Table 5** Description of **MipiDsiTx**
+**Table 5** Description of **MipiDsiTx**
Parameter
@@ -335,7 +335,7 @@ HdfFree(cmd);
int32\_t MipiDsiRx\(DevHandle handle, struct DsiCmdDesc \*cmd, uint32\_t readLen, uint8\_t \*out\);
-**Table 6** Description of **MipiDsiRx**
+**Table 6** Description of **MipiDsiRx**
Parameter
@@ -417,9 +417,9 @@ After the MIPI DSI communication, release the MIPI DSI device handle by calling
void MipiDsiClose\(DevHandle handle\);
-This function releases the resources requested by **MipiDsiOpen**.
+This function releases the resources requested by **MipiDsiOpen**.
-**Table 7** Description of **MipiDsiClose**
+**Table 7** Description of **MipiDsiClose**
Parameter
@@ -536,5 +536,4 @@ void PalMipiDsiTestSample(void)
/* Release the MIPI DSI device handle. */
MipiDsiClose(handle);
}
-```
-
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-mipidsi-develop.md b/en/device-dev/driver/driver-platform-mipidsi-develop.md
index ceb69f730c2fe94c62bf1bff90cb05601d8a799b..d45115a8d733e8e12dd4f5a75222322bfe164ff5 100644
--- a/en/device-dev/driver/driver-platform-mipidsi-develop.md
+++ b/en/device-dev/driver/driver-platform-mipidsi-develop.md
@@ -3,9 +3,9 @@
## Overview
-The Display Serial Interface \(DSI\) is a specification developed by the Mobile Industry Processor Interface \(MIPI\) Alliance to reduce the cost of display controllers in mobile devices. In the Hardware Driver Foundation (HDF) framework, the MIPI DSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
+The Display Serial Interface \(DSI\) is a specification developed by the Mobile Industry Processor Interface \(MIPI\) Alliance to reduce the cost of display controllers in mobile devices. In the Hardware Driver Foundation (HDF) framework, the MIPI DSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** \(a void pointer\) directly points to the kernel-mode address of the device object.
-**Figure 1** Service-free mode
+**Figure 1** Service-free mode
## Available APIs
@@ -26,7 +26,7 @@ struct MipiDsiCntlrMethod {// Member functions of the core layer structure
};
```
-**Table 1** Callbacks for the members in the MipiDsiCntlrMethod structure
+**Table 1** Callbacks for the members in the MipiDsiCntlrMethod structure
Callback
@@ -105,36 +105,33 @@ struct MipiDsiCntlrMethod {// Member functions of the core layer structure
The MIPI DSI module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **mipidsi\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **mipidsi\_config.hcs** file.
3. Instantiate the MIPI DSI controller object.
- - Initialize **MipiDsiCntlr**.
- - Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
+ - Initialize **MipiDsiCntlr**.
+ - Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
- > **NOTE**
-
- >For details, see [Available APIs](#available-apis).
+ For details, see [Available APIs](#available-apis).
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
+4. \(Optional\) Debug the driver.
+ For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
## Development Example
-The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Generally, you need to configure the device attributes in **xx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiDsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
+1. Generally, you need to configure the device attributes in **xx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiDsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
- In this example, no additional attribute needs to be configured for the MIPI DSI controller. If required, you need to add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the **mipidsi\_config** file.
+ In this example, no additional attribute needs to be configured for the MIPI DSI controller. If required, you need to add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the **mipidsi\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -157,9 +154,9 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
}
```
-2. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+2. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
- MIPI DSI driver entry reference
@@ -173,10 +170,10 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
```
-3. Initialize the **MipiDsiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MipiDsiCntlrMethod** \(used to call underlying functions of the driver\) in **MipiDsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **MipiDsiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MipiDsiCntlrMethod** \(used to call underlying functions of the driver\) in **MipiDsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI DSI has no device attribute file. Therefore, the basic member structure is similar to that of **MipiDsiCntlr**.
+ To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI DSI has no device attribute file. Therefore, the basic member structure is similar to that of **MipiDsiCntlr**.
```
typedef struct {
@@ -202,7 +199,7 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
};
```
- - Instantiate the callback function structure **MipiDsiCntlrMethod** in **MipiDsiCntlr**. Other members are initialized by using the Init function.
+ - Instantiate the callback function structure **MipiDsiCntlrMethod** in **MipiDsiCntlr**. Other members are initialized by using the Init function.
```
static struct MipiDsiCntlrMethod g_method = {
@@ -218,11 +215,11 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
Status (Value)
@@ -266,16 +263,16 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
Function description:
- Connects to the **MipiDsiCntlrMethod** instance, calls **MipiDsiRegisterCntlr**, and performs other vendor-defined initialization operations.
+ Connects to the **MipiDsiCntlrMethod** instance, calls **MipiDsiRegisterCntlr**, and performs other vendor-defined initialization operations.
```
static int32_t Hi35xxMipiTxInit(struct HdfDeviceObject *device)
{
int32_t ret;
g_mipiTx.priv = NULL; // g_mipiTx is a global variable.
- //static struct MipiDsiCntlr g_mipiTx {
+ // static struct MipiDsiCntlr g_mipiTx {
// .devNo=0
- //};
+ // };
g_mipiTx.ops = &g_method;// Connect to the MipiDsiCntlrMethod instance.
ret = MipiDsiRegisterCntlr(&g_mipiTx, device);// (Mandatory) Call the function at the core layer and g_mipiTx to initialize global variables at the core layer.
...
@@ -308,7 +305,7 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -316,7 +313,7 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
static void Hi35xxMipiTxRelease(struct HdfDeviceObject *device)
@@ -331,7 +328,4 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
g_mipiTx.priv = NULL;
HDF_LOGI("%s: unload mipi_tx driver 1212!", __func__);
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-mmc-develop.md b/en/device-dev/driver/driver-platform-mmc-develop.md
index 7becfa6f2308da0b8e3143b0edc11c0e7d307bcd..ea96f25d1430391cd56df31738ac38f8410f542e 100644
--- a/en/device-dev/driver/driver-platform-mmc-develop.md
+++ b/en/device-dev/driver/driver-platform-mmc-develop.md
@@ -4,7 +4,7 @@
In the Hardware Driver Foundation \(HDF\) framework, the MultiMedia Card \(MMC\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
-**Figure 1** Independent service mode
+**Figure 1** Independent service mode
## Available APIs
@@ -31,7 +31,7 @@ struct MmcCntlrOps {
};
```
-**Table 1** Callbacks for the members in the MmcCntlrOps structure
+**Table 1** Callbacks for the members in the MmcCntlrOps structure
Callback
@@ -196,33 +196,30 @@ struct MmcCntlrOps {
The MMC module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **mmc\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **mmc\_config.hcs** file.
3. Instantiate the MMC controller object.
- - Initialize **MmcCntlr**.
- - Instantiate **MmcCntlrOps** in the **MmcCntlr** object.
+ - Initialize **MmcCntlr**.
+ - Instantiate **MmcCntlrOps** in the **MmcCntlr** object.
- > **NOTE**
+ For details, see [Available APIs](#available-apis).
- >For details, see [Available APIs](#available-apis).
-
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the mount operation and whether the device starts successfully.
+4. \(Optional\) Debug the driver.
+ For new drivers, verify basic functions, for example, verify the information returned after the mount operation and whether the device starts successfully.
## Development Example
-The following uses **himci.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **himci.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
- MMC driver entry reference
@@ -237,11 +234,11 @@ The following uses **himci.c** as an example to present the contents that need
HDF_INIT(g_mmcDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **mmc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **MmcCntlr** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **mmc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **MmcCntlr** members at the core layer.
- If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **mmc\_config** file.
+ If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **mmc\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -281,7 +278,7 @@ The following uses **himci.c** as an example to present the contents that need
}
```
- - **mmc\_config.hcs** configuration reference
+ - **mmc\_config.hcs** configuration reference
```
root {
@@ -334,10 +331,10 @@ The following uses **himci.c** as an example to present the contents that need
}
```
-3. Initialize the **MmcCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MmcCntlrOps** \(used to call underlying functions of the driver\) in **MmcCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **MmcCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MmcCntlrOps** \(used to call underlying functions of the driver\) in **MmcCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **mmc\_config.hcs** file are read by the HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values are also transferred to the objects at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **mmc\_config.hcs** file are read by the HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values are also transferred to the objects at the core layer.
```
struct HimciHost {
@@ -389,7 +386,7 @@ The following uses **himci.c** as an example to present the contents that need
};
```
- - Instantiate the callback function structure **MmcCntlrOps** in **MmcCntlr**. Other members are initialized by using the **Bind** function.
+ - Instantiate the callback function structure **MmcCntlrOps** in **MmcCntlr**. Other members are initialized by using the **Bind** function.
```
static struct MmcCntlrOps g_himciHostOps = {
@@ -415,11 +412,11 @@ The following uses **himci.c** as an example to present the contents that need
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
Status (Value)
@@ -463,7 +460,7 @@ The following uses **himci.c** as an example to present the contents that need
Function description:
- Initializes the custom structure **HimciHost** object and **MmcCntlr**, and calls the **MmcCntlrAdd** function at the core layer. **MmcCntlr**, **HimciHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully.
+ Initializes the custom structure **HimciHost** object and **MmcCntlr**, and calls the **MmcCntlrAdd** function at the core layer. **MmcCntlr**, **HimciHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully.
```
static int32_t HimciMmcBind(struct HdfDeviceObject *obj)
@@ -501,7 +498,7 @@ The following uses **himci.c** as an example to present the contents that need
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -531,7 +528,7 @@ The following uses **himci.c** as an example to present the contents that need
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -539,7 +536,7 @@ The following uses **himci.c** as an example to present the contents that need
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
static void HimciMmcRelease(struct HdfDeviceObject *obj)
@@ -550,7 +547,4 @@ The following uses **himci.c** as an example to present the contents that need
...
HimciDeleteHost((struct HimciHost *)cntlr->priv);// Memory release function customized by the vendor. A forced conversion from MmcCntlr to HimciHost is involved in the process.
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-pin-des.md b/en/device-dev/driver/driver-platform-pin-des.md
index 91e05c5f19e3d1ba81106fe17daee2cb56e04b9e..fe73cbd7cb9933bad74359070642bb26c5643c46 100644
--- a/en/device-dev/driver/driver-platform-pin-des.md
+++ b/en/device-dev/driver/driver-platform-pin-des.md
@@ -5,12 +5,12 @@
### Pin
-- The pin, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function.
-- The pin module defines a set of common methods for managing pins, including:
+The pin module, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function.
+The module defines a set of common methods for managing pins, including:
- Obtaining or releasing the pin description handle: The kernel compares the pin name passed in with the pin names of each controller in the linked list. If a match is found, a pin description handle is obtained. After the operation on the pin is complete, the pin description handle will be released.
- - Setting or obtaining the pull type of a pin: The pull type can be pull-up, pull-down, or floating.
- - Setting or obtaining the pull strength of a pin: You can set the pull strength as required.
- - Setting or obtaining the functions of a pin to implement pin multiplexing
+- Setting or obtaining the pull type of a pin: The pull type can be pull-up, pull-down, or floating.
+- Setting or obtaining the pull strength of a pin: You can set the pull strength as required.
+- Setting or obtaining the functions of a pin to implement pin multiplexing
### Basic Concepts
Pin, as a software concept, provides APIs for uniformly managing the pins from different SoC vendors, providing the pin multiplexing function, and configuring the electrical features of pins.
@@ -52,7 +52,7 @@ The table below describes the APIs of the pin module. For more details, see API
**Table 1** Pin driver APIs
-| **API** | **Description** |
+| **API** | **Description** |
| ------------------------------------------------------------ | ---------------- |
| DevHandle PinGet(const char *pinName); | Obtains the pin description handle.|
| void PinPut(DevHandle handle); | Releases the pin description handle.|
@@ -88,7 +88,7 @@ DevHandle PinGet(const char *pinName);
| Parameter | Description |
| ---------- | ----------------------- |
| pinName | Pointer to the pin name. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| NULL | Failed to obtain the pin description handle.|
| handle | Pin description handle obtained. |
@@ -120,7 +120,7 @@ int32_t PinSetPull(DevHandle handle, enum PinPullType pullType);
| ---------- | ----------------------- |
| handle | Pin description handle. |
| pullType | Pull type to set. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful.|
| Negative value | The operation fails.|
@@ -154,7 +154,7 @@ int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType);
| ---------- | ------------------------- |
| handle | Pin description handle. |
| pullType | Pointer to the pull type obtained.|
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
@@ -187,7 +187,7 @@ int32_t PinSetStrength(DevHandle handle, uint32_t strength);
| ---------- | ----------------------- |
| handle | Pin description handle. |
| strength | Pull strength to set. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful.|
| Negative value | The operation fails.|
@@ -221,7 +221,7 @@ int32_t PinGetStrength(DevHandle handle, uint32_t *strength);
| ---------- | ------------------------- |
| handle | Pin description handle. |
| strength | Pointer to the pull strength obtained.|
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
@@ -256,7 +256,7 @@ int32_t PinSetFunc(DevHandle handle, const char *funcName);
| ---------- | ------------------- |
| handle | Pin description handle. |
| funcName | Pointer to the pin function to set. |
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful.|
| Negative value | The operation fails.|
@@ -289,7 +289,7 @@ int32_t PinGetFunc(DevHandle handle, const char **funcName);
| ---------- | --------------------- |
| handle | Pin description handle. |
| funcName | Pointer to the function name obtained.|
-| **Return Value**| **Description** |
+| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
@@ -406,4 +406,4 @@ ERR:
/* Release the pin description handle. */
PinPut(handle);
return ret;
-}
+}
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-pwm-develop.md b/en/device-dev/driver/driver-platform-pwm-develop.md
index 269e990a8784782725bfbb054e5bdd6c8cd968b7..a208a9d5b9a65bea1129e6c0c04469d35e3645b2 100644
--- a/en/device-dev/driver/driver-platform-pwm-develop.md
+++ b/en/device-dev/driver/driver-platform-pwm-develop.md
@@ -19,7 +19,7 @@ struct PwmMethod {
};
```
-**Table 1** Callbacks for the members in the PwmMethod structure
+**Table 1** Callbacks for the members in the PwmMethod structure
Callback
@@ -68,33 +68,30 @@ struct PwmMethod {
The PWM module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **pwm\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **pwm\_config.hcs** file.
3. Instantiate the PWM controller object.
- - Initialize **PwmDev**.
- - Instantiate **PwmMethod** in the **PwmDev** object.
+ - Initialize **PwmDev**.
+ - Instantiate **PwmMethod** in the **PwmDev** object.
- > **NOTE**
+ For details, see [Available APIs](#available-apis).
- >For details, see [Available APIs](#available-apis).
-
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
+4. \(Optional\) Debug the driver.
+ For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
## Development Example
-The following uses **pwm\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **pwm\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
- PWM driver entry reference
@@ -110,8 +107,8 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
HDF_INIT(g_hdfPwm);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **pwm\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **PwmDev** members at the core layer. If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **pwm\_config** file.
- - **device\_info.hcs** configuration reference
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **pwm\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **PwmDev** members at the core layer. If there are multiple devices, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **pwm\_config** file.
+ - **device\_info.hcs** configuration reference
```
root {
@@ -143,7 +140,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
}
```
- - **pwm\_config.hcs** configuration reference
+ - **pwm\_config.hcs** configuration reference
```
root {
@@ -168,10 +165,10 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
}
```
-3. Initialize the **PwmDev** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **PwmMethod** \(used to call underlying functions of the driver\) in **PwmDev**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **PwmDev** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **PwmMethod** \(used to call underlying functions of the driver\) in **PwmDev**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **pwm\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **pwm\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
```
struct HiPwm {
@@ -208,7 +205,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
};
```
- - Instantiate the callback function structure **PwmMethod** in **PwmDev**. Other members are initialized by using the **Init** function.
+ - Instantiate the callback function structure **PwmMethod** in **PwmDev**. Other members are initialized by using the **Init** function.
```
// Example in pwm_hi35xx.c: fill the hook function
@@ -221,11 +218,11 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
Status (Value)
@@ -269,7 +266,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
Function description:
- Initializes the custom structure object and **PwmDev**, and calls the **PwmDeviceAdd** function at the core layer.
+ Initializes the custom structure object and **PwmDev**, and calls the **PwmDeviceAdd** function at the core layer.
```
// The bind function is empty. It can be combined with the init function or implement related operations based on the vendor's requirements.
@@ -320,7 +317,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -328,7 +325,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
```
static void HdfPwmRelease(struct HdfDeviceObject *obj)
@@ -340,7 +337,4 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents tha
PwmDeviceRemove(obj, &(hp->dev));// (Mandatory) Call the core layer functions to release PwmDev devices and services. A forced conversion from HiPwm to PwmDev is involved in the process.
HiPwmRemove(hp); //Release HiPwm.
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-regulator-develop.md b/en/device-dev/driver/driver-platform-regulator-develop.md
index 94fd1f76d09106a5698aa27b89503be6ab231a2d..960c3b88bfaf225ec1f911a22be8ffad0b25037b 100644
--- a/en/device-dev/driver/driver-platform-regulator-develop.md
+++ b/en/device-dev/driver/driver-platform-regulator-develop.md
@@ -266,13 +266,13 @@ The regulator module adaptation procedure is as follows:
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
Return value:
- **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.)
+ **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.)
- **Table 2** HDF\_STATUS
+ **Table 2** HDF\_STATUS
| State | Description |
| ---------------------- | -------------- |
@@ -319,11 +319,11 @@ The regulator module adaptation procedure is as follows:
}
```
- - **Release** function
+ - **Release** function
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration.
Return value:
@@ -341,8 +341,6 @@ The regulator module adaptation procedure is as follows:
}
```
-4. Debug the driver.
+4. (Optional) Debug the driver.
- (Optional) Verify the basic functions of the new driver, for example, whether the test cases are successful after the driver is loaded.
-
-
+ Verify the basic functions of the new driver, for example, whether the test cases are successful after the driver is loaded.
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-rtc-des.md b/en/device-dev/driver/driver-platform-rtc-des.md
index b124a0cd79fd3214479a155e54a3352e970e3315..529546787b0efa2a3f01185d27a0dfc416fcc208 100644
--- a/en/device-dev/driver/driver-platform-rtc-des.md
+++ b/en/device-dev/driver/driver-platform-rtc-des.md
@@ -6,7 +6,7 @@ The real-time clock \(RTC\) driver provides precise real time for the operating
## Available APIs
-**Table 1** APIs provided by the RTC driver
+**Table 1** APIs provided by the RTC driver
Capability
@@ -95,7 +95,7 @@ The real-time clock \(RTC\) driver provides precise real time for the operating
|
|---|
-> **NOTE:**
+> **NOTE**
>All functions provided in this document can be called only in kernel mode.
## Usage Guidelines
@@ -106,19 +106,19 @@ During the OS startup, the HDF loads the RTC driver based on the configuration f
[Figure 1](#fig1610020107333) illustrates the process of using an RTC device.
-**Figure 1** 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:**
+> **NOTE**
>Currently, only one RTC device is supported in the OS.
DevHandle RtcOpen\(void\);
-**Table 2** Description of RtcOpen
+**Table 2** Description of RtcOpen
Parameter
@@ -165,7 +165,7 @@ You can call the following function to release the RTC device handle, thereby re
void RtcClose\(DevHandle handle\);
-**Table 3** Description of RtcClose
+**Table 3** Description of RtcClose
Parameter
@@ -188,11 +188,11 @@ 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:
+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
+**Table 4** Description of RtcRegisterAlarmCallback
Parameter
@@ -234,7 +234,7 @@ int32\_t RtcRegisterAlarmCallback\(DevHandle handle, enum RtcAlarmIndex alarmInd
|
|---|
-The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
+The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
```
/* Register an RTC alarm callback. */
@@ -265,7 +265,7 @@ Call the following function to read time information from the RTC driver, includ
int32\_t RtcReadTime\(DevHandle handle, struct RtcTime \*time\);
-**Table 5** Description of RtcReadTime
+**Table 5** Description of RtcReadTime
Parameter
@@ -318,7 +318,7 @@ Call the following function to set the RTC time:
int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
-**Table 6** Description of RtcWriteTime
+**Table 6** Description of RtcWriteTime
Parameter
@@ -354,8 +354,8 @@ int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
|
-> **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.
+> **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;
@@ -382,7 +382,7 @@ 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
+**Table 7** Description of RtcReadAlarm
Parameter
@@ -440,7 +440,7 @@ 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
+**Table 8** Description of RtcWriteAlarm
Parameter
@@ -481,8 +481,8 @@ int32\_t RtcWriteAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct
|
-> **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.
+> **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;
@@ -505,11 +505,11 @@ if (ret != 0) {
- 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:
+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
+**Table 9** Description of RtcAlarmInterruptEnable
Parameter
@@ -566,7 +566,7 @@ Call the following function to read the frequency of the external crystal oscill
int32\_t RtcGetFreq\(DevHandle handle, uint32\_t \*freq\);
-**Table 10** Description of RtcGetFreq
+**Table 10** Description of RtcGetFreq
Parameter
@@ -619,7 +619,7 @@ Call the following function to set the frequency of the external crystal oscilla
int32\_t RtcSetFreq\(DevHandle handle, uint32\_t freq\);
-**Table 11** Description of RtcSetFreq
+**Table 11** Description of RtcSetFreq
Parameter
@@ -672,7 +672,7 @@ Call the following function to perform a reset on the RTC driver \(after the res
int32\_t RtcReset\(DevHandle handle\);
-**Table 12** Description of RtcReset
+**Table 12** Description of RtcReset
Parameter
@@ -719,7 +719,7 @@ Call the following function to read the configuration of a custom RTC register b
int32\_t RtcReadReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t \*value\);
-**Table 13** Description of RtcReadReg
+**Table 13** Description of RtcReadReg
Parameter
@@ -778,7 +778,7 @@ Call the following function to configure a register based on the specified regis
int32\_t RtcWriteReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t value\);
-**Table 14** Description of RtcWriteReg
+**Table 14** Description of RtcWriteReg
Parameter
@@ -838,7 +838,7 @@ 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.
+4. Call the **RtcClose** function to release the device handle and device resources.
Example:
@@ -926,5 +926,4 @@ void RtcTestSample(void)
/* Release the RTC device handle. */
RtcClose(handle);
}
-```
-
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-rtc-develop.md b/en/device-dev/driver/driver-platform-rtc-develop.md
index 20639f951acdbb5c97ec050fdc1f4712b579fe35..3b718858e351a38bc233e47bb871b1d490d62074 100644
--- a/en/device-dev/driver/driver-platform-rtc-develop.md
+++ b/en/device-dev/driver/driver-platform-rtc-develop.md
@@ -4,7 +4,7 @@
In the Hardware Driver Foundation \(HDF\) framework, the real-time clock \(RTC\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
-**Figure 1** Independent service mode
+**Figure 1** Independent service mode
## Available APIs
@@ -27,7 +27,7 @@ struct RtcMethod {
};
```
-**Table 1** Callbacks for the members in the RtcMethod structure
+**Table 1** Callbacks for the members in the RtcMethod structure
Callback
@@ -183,33 +183,31 @@ struct RtcMethod {
The RTC module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **rtc\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **rtc\_config.hcs** file.
3. Instantiate the RTC controller object.
- - Initialize **RtcHost**.
- - Instantiate **RtcMethod** in the **RtcHost** object.
-
- > **NOTE**
-
- >For details, see [Available APIs](#available-apis).
+ - Initialize **RtcHost**.
+ - Instantiate **RtcMethod** in the **RtcHost** object.
+ For details, see [Available APIs](#available-apis).
+
+4. \(Optional\) Debug the driver.
-4. Debug the driver.
- - \(Optional\) For new drivers, verify the basic functions, such as the RTC control status and response to interrupts.
+ For new drivers, verify the basic functions, such as the RTC control status and response to interrupts.
## Development Example
-The following uses **rtc\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **rtc\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
- RTC driver entry reference
@@ -225,11 +223,11 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
HDF_INIT(g_rtcDriverEntry);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **rtc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **RtcHost** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **rtc\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **RtcHost** members at the core layer.
- In this example, there is only one RTC controller. If there are multiple RTC controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **rtc\_config** file.
+ In this example, there is only one RTC controller. If there are multiple RTC controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **rtc\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -250,7 +248,7 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
}
```
- - **rtc\_config.hcs** configuration reference
+ - **rtc\_config.hcs** configuration reference
```
root {
@@ -274,10 +272,10 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
}
```
-3. Initialize the **RtcHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **RtcMethod** \(used to call underlying functions of the driver\) in **RtcHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **RtcHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **RtcMethod** \(used to call underlying functions of the driver\) in **RtcHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **rtc\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**.
+ To the driver, the custom structure carries parameters and data. The values in the **rtc\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**.
```
struct RtcConfigInfo {
@@ -303,7 +301,7 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
};
```
- - Instantiate the callback function structure **RtcMethod** in **RtcHost**. Other members are initialized by using the **Init** function.
+ - Instantiate the callback function structure **RtcMethod** in **RtcHost**. Other members are initialized by using the **Init** function.
```
// Example in rtc_hi35xx.c: instantiate the hook.
@@ -326,13 +324,13 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
- **Table 2** Input parameters and return values of the Bind function
+ **Table 2** Input parameters and return values of the Bind function
Status (Value)
@@ -376,7 +374,7 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
Function description:
- Associates the **HdfDeviceObject** object and **RtcHost**.
+ Associates the **HdfDeviceObject** object and **RtcHost**.
```
static int32_t HiRtcBind(struct HdfDeviceObject *device)
@@ -395,7 +393,7 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -403,7 +401,7 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
Function description:
- Initializes the custom structure object and **RtcHost**.
+ Initializes the custom structure object and **RtcHost**.
```
static int32_t HiRtcInit(struct HdfDeviceObject *device)
@@ -437,15 +435,15 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
–
- **Function description**:
+ **Function description**:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** or **Bind** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** or **Bind** function has the corresponding value assignment operations.
```
static void HiRtcRelease(struct HdfDeviceObject *device)
@@ -462,7 +460,4 @@ The following uses **rtc\_hi35xx.c** as an example to present the contents tha
}
RtcHostDestroy(host); // Release RtcHost.
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-spi-des.md b/en/device-dev/driver/driver-platform-spi-des.md
index 4388fdd99bec26e45ce91d29016fc5a2fba21f31..a8b35d2682b0f9c19afd362b9f84600b2c75cea6 100644
--- a/en/device-dev/driver/driver-platform-spi-des.md
+++ b/en/device-dev/driver/driver-platform-spi-des.md
@@ -2,46 +2,46 @@
## 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
+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](#fig89085710359) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
+[Figure 1](#fig89085710359) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
-**Figure 1** SPI controller/device connection
+**Figure 1** SPI controller/device connection
-- SPI communication is usually initiated by the SPI controller and is operated as follows:
+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.
+ - 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**.
+ - Customizing data reading or writing via **SpiMsg**.
- Obtaining and setting SPI device configuration parameters.
-> **NOTE:**
+> **NOTE**
>Currently, these functions are only applicable in the communication initiated by the SPI controller.
## Available APIs
-**Table 1** APIs for the SPI driver
+**Table 1** APIs for the SPI driver
Capability
@@ -106,16 +106,16 @@
[Figure 2](#fig1586912310348) shows the process of using an SPI device.
-**Figure 2** 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.
+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
+**Table 2** Description of SpiOpen
Parameter
@@ -146,7 +146,7 @@ DevHandle SpiOpen\(const struct SpiDevInfo \*info\);
|
-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**.
+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 */
@@ -168,7 +168,7 @@ After obtaining the SPI device handle, obtain the SPI device configuration param
int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-**Table 3** Description of SpiGetCfg
+**Table 3** Description of SpiGetCfg
Parameter
@@ -219,7 +219,7 @@ After obtaining the SPI device handle, set SPI device configuration parameters b
int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-**Table 4** Description of SpiSetCfg
+**Table 4** Description of SpiSetCfg
Parameter
@@ -276,7 +276,7 @@ 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
+**Table 5** Description of SpiWrite
Parameter
@@ -333,7 +333,7 @@ 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
+**Table 6** Description of SpiRead
Parameter
@@ -390,7 +390,7 @@ 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
+**Table 7** Description of SpiTransfer
Parameter
@@ -457,7 +457,7 @@ void SpiClose\(DevHandle handle\);
This function will release the resources previously obtained.
-**Table 8** Description of SpiClose
+**Table 8** Description of SpiClose
Parameter
@@ -545,5 +545,4 @@ err:
/* Destroy the SPI device handle. */
SpiClose(spiHandle);
}
-```
-
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-spi-develop.md b/en/device-dev/driver/driver-platform-spi-develop.md
index ca8873bd9c139a9c7d046cb6718aff17225b12d1..40ed76d02446262f32d8d6e55eba044eca88fd89 100644
--- a/en/device-dev/driver/driver-platform-spi-develop.md
+++ b/en/device-dev/driver/driver-platform-spi-develop.md
@@ -5,7 +5,7 @@
In the Hardware Driver Foundation \(HDF\), the Serial Peripheral Interface \(SPI\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
-**Figure 1** Independent service mode
+**Figure 1** Independent service mode
## Available APIs
@@ -21,7 +21,7 @@ struct SpiCntlrMethod {
int32_t (*Close)(struct SpiCntlr *cntlr);
};
```
-**Table 1** Callbacks for the members in the SpiCntlrMethod structure
+**Table 1** Callbacks for the members in the SpiCntlrMethod structure
Callback
@@ -91,32 +91,30 @@ struct SpiCntlrMethod {
The SPI module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **spi\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **spi\_config.hcs** file.
3. Instantiate the SPI controller object.
- - Initialize **SpiCntlr**.
- - Instantiate **SpiCntlrMethod** in the **SpiCntlr** object.
+ - Initialize **SpiCntlr**.
+ - Instantiate **SpiCntlrMethod** in the **SpiCntlr** object.
- > **NOTE**
+ For details, see [Available APIs](#section752964871810).
- >For details, see [Available APIs](#section752964871810).
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify the basic functions, such as the SPI control status and response to interrupts.
+ 4. \(Optional\) Debug the driver.
+ For new drivers, verify the basic functions, such as the SPI control status and response to interrupts.
## Development Example
-The following uses **spi\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **spi\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
- SPI driver entry reference
@@ -132,11 +130,11 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
HDF_INIT(g_hdfSpiDevice);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **spi\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **SpiCntlr** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **spi\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **SpiCntlr** members at the core layer.
- In this example, there is only one SPI controller. If there are multiple SPI controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **spi\_config** file.
+ In this example, there is only one SPI controller. If there are multiple SPI controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **spi\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -169,7 +167,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
}
```
- - **spi\_config.hcs** configuration reference
+ - **spi\_config.hcs** configuration reference
```
root {
@@ -218,10 +216,10 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
}
```
-3. Initialize the **SpiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **SpiCntlrMethod** \(used to call underlying functions of the driver\) in **SpiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **SpiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **SpiCntlrMethod** \(used to call underlying functions of the driver\) in **SpiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **spi\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the object at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **spi\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number and bus number, are also passed to the object at the core layer.
```
struct Pl022 {// Corresponds to parameters in .hcs.
@@ -264,7 +262,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
};
```
- - Instantiate the callback function structure **SpiCntlrMethod** in **SpiCntlr**. Other members are initialized by using the **Init** function.
+ - Instantiate the callback function structure **SpiCntlrMethod** in **SpiCntlr**. Other members are initialized by using the **Init** function.
```
// Example in spi_hi35xx.c: instantiate the hook.
@@ -281,7 +279,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -289,7 +287,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Function description:
- Associates the **SpiCntlr** object with **HdfDeviceObject**.
+ Associates the **SpiCntlr** object with **HdfDeviceObject**.
```
static int32_t HdfSpiDeviceBind(struct HdfDeviceObject *device)
@@ -317,13 +315,13 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **/drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **/drivers/framework/include/utils/hdf\_base.h** file.\)
- **Table 2** Input parameters and return values of the init function
+ **Table 2** Input parameters and return values of the init function
Status (Value)
@@ -367,7 +365,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Function description:
- Initializes the custom structure object and **SpiCntlr**.
+ Initializes the custom structure object and **SpiCntlr**.
```
static int32_t HdfSpiDeviceInit(struct HdfDeviceObject *device)
@@ -418,7 +416,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -426,7 +424,7 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
static void HdfSpiDeviceRelease(struct HdfDeviceObject *device)
@@ -441,8 +439,4 @@ The following uses **spi\_hi35xx.c** as an example to present the contents tha
}
SpiCntlrDestroy(cntlr); // Release the Pl022 object.
}
- ```
-
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-uart-des.md b/en/device-dev/driver/driver-platform-uart-des.md
index 0d8809f05bc3bd9a100142b07d46a8e014259915..37d4c34d6dbd91440b72f0b502d0b8439379ba14 100644
--- a/en/device-dev/driver/driver-platform-uart-des.md
+++ b/en/device-dev/driver/driver-platform-uart-des.md
@@ -2,27 +2,29 @@
## 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](#fig68294715408)\) or four wires \(as shown in [Figure 2](#fig179241542163112)\).
- - TX: TX pin of the transmitting UART. It is connected to the RX pin of the peer UART.
- - RX: RX pin of the receiving UART. It is connected to the TX pin of the peer UART.
- - RTS: Request to Send signal pin. It is connected to the CTS pin of the peer UART and is used to indicate whether the local UART is ready to receive data.
- - CTS: Clear to Send signal pin. It is connected to the RTS pin of the peer UART and is used to indicate whether the local UART is allowed to send data to the peer end.
-
- **Figure 1** 2-wire UART communication
+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](#fig68294715408)\) or four wires \(as shown in [Figure 2](#fig179241542163112)\).
+- TX: TX pin of the transmitting UART. It is connected to the RX pin of the peer UART.
+- RX: RX pin of the receiving UART. It is connected to the TX pin of the peer UART.
+- RTS: Request to Send signal pin. It is connected to the CTS pin of the peer UART and is used to indicate whether the local UART is ready to receive data.
+- CTS: Clear to Send signal pin. It is connected to the RTS pin of the peer UART and is used to indicate whether the local UART is allowed to send data to the peer end.
+
+ **Figure 1** 2-wire UART communication
- **Figure 2** 4-wire UART communication
+ **Figure 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.
+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.
+
## Available APIs
-**Table 1** APIs for the UART driver
+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.
+
+**Table 1** APIs for the UART driver
Capability
@@ -94,7 +96,7 @@
|
|---|
-> **NOTE:**
+> **NOTE**
>All functions provided in this document can be called only in kernel space.
## Usage Guidelines
@@ -103,16 +105,16 @@
[Figure 3](#fig99673244388) shows the process of using a UART device.
-**Figure 3** 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.
+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
+**Table 2** Description of UartOpen
Parameter
@@ -144,7 +146,7 @@ DevHandle UartOpen\(uint32\_t port\);
|
|---|
-The following example shows how to obtain a UART device handle based on the assumption that the UART port number is **3**:
+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 */
@@ -162,7 +164,7 @@ After obtaining the UART device handle, set the UART baud rate by calling the fo
int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
-**Table 3** Description of UartSetBaud
+**Table 3** Description of UartSetBaud
Parameter
@@ -199,7 +201,7 @@ int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
|
|---|
-The following example shows how to set the UART baud rate to **9600**:
+The following example shows how to set the UART baud rate to **9600**:
```
int32_t ret;
@@ -216,7 +218,7 @@ After setting the UART baud rate, obtain the current baud rate by calling the fo
int32\_t UartGetBaud\(DevHandle handle, uint32\_t \*baudRate\);
-**Table 4** Description of UartGetBaud
+**Table 4** Description of UartGetBaud
Parameter
@@ -271,7 +273,7 @@ Before performing UART communication, set the UART device attributes by calling
int32\_t UartSetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-**Table 5** Description of UartSetAttribute
+**Table 5** Description of UartSetAttribute
Parameter
@@ -333,7 +335,7 @@ After setting the UART device attributes, obtain the current device attributes b
int32\_t UartGetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-**Table 6** Description of UartGetAttribute
+**Table 6** Description of UartGetAttribute
Parameter
@@ -388,7 +390,7 @@ Before performing UART communication, set the UART transmission mode by calling
int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
-**Table 7** Description of UartSetTransMode
+**Table 7** Description of UartSetTransMode
Parameter
@@ -425,7 +427,7 @@ int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
|
|---|
-The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
+The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
```
int32_t ret;
@@ -442,7 +444,7 @@ 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
+**Table 8** Description of UartWrite
Parameter
@@ -502,7 +504,7 @@ 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
+**Table 9** Description of UartRead
Parameter
@@ -557,7 +559,7 @@ if (ret < 0) {
```
> **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.
+>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
@@ -567,7 +569,7 @@ void UartClose\(DevHandle handle\);
This function will release the resources previously obtained.
-**Table 10** Description of UartClose
+**Table 10** Description of UartClose
Parameter
@@ -655,5 +657,4 @@ _ERR:
/* Destroy the UART device handle. */
UartClose(handle);
}
-```
-
+```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-uart-develop.md b/en/device-dev/driver/driver-platform-uart-develop.md
index bc6d8273634db163254459755a4aceb46c3f4993..72437ef747458a429c96d215a989c8cf03badf1e 100644
--- a/en/device-dev/driver/driver-platform-uart-develop.md
+++ b/en/device-dev/driver/driver-platform-uart-develop.md
@@ -4,7 +4,7 @@
In the Hardware Driver Foundation \(HDF\), the Universal Asynchronous Receiver/Transmitter \(UART\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
-**Figure 1** Independent service mode
+**Figure 1** Independent service mode
## Available APIs
@@ -26,7 +26,7 @@ struct UartHostMethod {
};
```
-**Table 1** Callbacks for the members in the UartHostMethod structure
+**Table 1** Callbacks for the members in the UartHostMethod structure
Callback
@@ -167,33 +167,31 @@ struct UartHostMethod {
The UART module adaptation involves the following steps:
1. Instantiate the driver entry.
- - Instantiate the **HdfDriverEntry** structure.
- - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
+ - Instantiate the **HdfDriverEntry** structure.
+ - Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- - Add the **deviceNode** information to the **device\_info.hcs** file.
- - \(Optional\) Add the **uart\_config.hcs** file.
+ - Add the **deviceNode** information to the **device\_info.hcs** file.
+ - \(Optional\) Add the **uart\_config.hcs** file.
3. Instantiate the UART controller object.
- - Initialize **UartHost**.
- - Instantiate **UartHostMethod** in the **UartHost** object.
+ - Initialize **UartHost**.
+ - Instantiate **UartHostMethod** in the **UartHost** object.
- > **NOTE**
-
- >For details, see [Available APIs](#available-apis).
-
-
-4. Debug the driver.
- - \(Optional\) For new drivers, verify the basic functions, such as the UART control status and response to interrupts.
+ For details, see [Available APIs](#available-apis).
+
+4. \(Optional\) Debug the driver.
+
+ For new drivers, verify the basic functions, such as the UART control status and response to interrupts.
## Development Example
-The following uses **uart\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
+The following uses **uart\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
-1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
- Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
+ Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exit.
- UART driver entry reference
@@ -209,11 +207,11 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
HDF_INIT(g_hdfUartDevice);
```
-2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **uart\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **UartHost** members at the core layer.
+2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **uart\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **UartHost** members at the core layer.
- In this example, there is only one UART controller. If there are multiple UART controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **uart\_config** file.
+ In this example, there is only one UART controller. If there are multiple UART controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **uart\_config** file.
- - **device\_info.hcs** configuration reference
+ - **device\_info.hcs** configuration reference
```
root {
@@ -246,7 +244,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
}
```
- - **uart\_config.hcs** configuration reference
+ - **uart\_config.hcs** configuration reference
```
root {
@@ -278,10 +276,10 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
}
```
-3. Initialize the **UartHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **UartHostMethod** \(used to call underlying functions of the driver\) in **UartHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
+3. Initialize the **UartHost** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **UartHostMethod** \(used to call underlying functions of the driver\) in **UartHost**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
- Custom structure reference
- To the driver, the custom structure carries parameters and data. The values in the **uart\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
+ To the driver, the custom structure carries parameters and data. The values in the **uart\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
```
struct UartPl011Port {// Structure related to the API
@@ -314,7 +312,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
#define UART_FLG_RD_BLOCK (1 << 2)
RecvNotify recv; // Pointer to the function that receives serial port data
struct UartOps *ops; // Custom function pointer structure. For details, see device/hisilicon/drivers/uart/uart_pl011.c.
- void *private; // It stores the pointer to the start address of UartPl011Port for easy invocation.
+ void *private; // Pointer to the start address of UartPl011Port for easy invocation
};
// UartHost is the controller structure at the core layer. Its members are assigned with values by using the Init function.
@@ -328,7 +326,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
};
```
- - Instantiate the callback function structure **UartHostMethod** in **UartHost**. Other members are initialized by using the **Bind** function.
+ - Instantiate the callback function structure **UartHostMethod** in **UartHost**. Other members are initialized by using the **Bind** function.
```
// Example in pwm_hi35xx.c: instantiate the hook.
@@ -350,13 +348,13 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
- HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
+ HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
- **Table 2** Input parameters and return values of the Bind function
+ **Table 2** Input parameters and return values of the Bind function
Status (Value)
@@ -400,7 +398,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Function description:
- Initializes the custom structure object and **UartHost**.
+ Initializes the custom structure object and **UartHost**.
```
//uart_hi35xx.c
@@ -430,7 +428,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -438,7 +436,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Function description:
- Initializes the custom structure object and **UartHost**, calls the **artAddDev** function at the core layer, and connects to VFS.
+ Initializes the custom structure object and **UartHost**, calls the **artAddDev** function at the core layer, and connects to VFS.
```
int32_t HdfUartDeviceInit(struct HdfDeviceObject *device)
@@ -502,7 +500,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Input parameters:
- **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
+ **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
@@ -510,7 +508,7 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
Function description:
- Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
+ Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
```
void HdfUartDeviceRelease(struct HdfDeviceObject *device)
@@ -544,7 +542,4 @@ The following uses **uart\_hi35xx.c** as an example to present the contents th
(void)OsalMemFree(udd);// Release UartDriverData.
host->priv = NULL;
}
- ```
-
-
-
+ ```
\ No newline at end of file
diff --git a/en/device-dev/driver/driver-platform-watchdog-des.md b/en/device-dev/driver/driver-platform-watchdog-des.md
index e571e6fc34ab8a343e750310a84ac656025b9243..2a9b44765c44f637aa97b9c1aab8867da5ad12e6 100644
--- a/en/device-dev/driver/driver-platform-watchdog-des.md
+++ b/en/device-dev/driver/driver-platform-watchdog-des.md
@@ -6,7 +6,7 @@ A watchdog, also called a watchdog timer, is a hardware timing device. If an err
## Available APIs
-**Table 1** Watchdog APIs
+**Table 1** Watchdog APIs
Capability
@@ -70,7 +70,7 @@ A watchdog, also called a watchdog timer, is a hardware timing device. If an err
|
|---|
-> **NOTE:**
+> **NOTE**
>All watchdog functions provided in this document can be called only in kernel mode.
## Usage Guidelines
@@ -79,16 +79,16 @@ A watchdog, also called a watchdog timer, is a hardware timing device. If an err
[Figure 1](#fig430533913392) illustrates the process of using a watchdog.
-**Figure 1** 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.
+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
+**Table 2** Description of WatchdogOpen
Parameter
@@ -133,7 +133,7 @@ if (handle == NULL) {
int32\_t WatchdogGetStatus\(DevHandle handle, int32\_t \*status\);
-**Table 3** Description of WatchdogGetStatus
+**Table 3** Description of WatchdogGetStatus
Parameter
@@ -185,7 +185,7 @@ if (ret != 0) {
int32\_t WatchdogSetTimeout\(PalHandle \*handle, uint32\_t seconds\);
-**Table 4** Description of WatchdogSetTimeout
+**Table 4** Description of WatchdogSetTimeout
Parameter
@@ -237,7 +237,7 @@ if (ret != 0) {
int32\_t WatchdogGetTimeout\(PalHandle \*handle, uint32\_t \*seconds\);
-**Table 5** Description of WatchdogGetTimeout
+**Table 5** Description of WatchdogGetTimeout
Parameter
@@ -289,7 +289,7 @@ if (ret != 0) {
int32\_t WatchdogStart\(DevHandle handle\);
-**Table 6** Description of WatchdogStart
+**Table 6** Description of WatchdogStart
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|
|
|
|
|
|
|---|
|
|---|
|
|---|
|
|
|
|
|
|
|
|
|
|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|
|
|
|
|