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\);
|
->![](../public_sys-resources/icon-note.gif) **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.
+>![](../public_sys-resources/icon-note.gif) **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
|
->![](../public_sys-resources/icon-note.gif) **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.
+>![](../public_sys-resources/icon-note.gif) **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
![](figures/independent-service-mode.png "independent-service-mode-11")
## 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.
-
- >![](../public_sys-resources/icon-note.gif) **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
![](figures/spi-controller-device-connection.png "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.
->![](../public_sys-resources/icon-note.gif) **NOTE:**
+>![](../public_sys-resources/icon-note.gif) **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
![](figures/process-of-using-an-spi-device.png "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
![](figures/independent-service-mode.png "SPI-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.
- >![](../public_sys-resources/icon-note.gif) **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
|
---|
|
---|
|
|
|
|
|
|
|
---|
|
---|
|
---|
|
|
|
|
|
|
|
|
|
|