未验证 提交 5f9d4b89 编写于 作者: O openharmony_ci 提交者: Gitee

!1622 PR989已完成,请审核

Merge pull request !1622 from Annie_wang/PR989
......@@ -10,25 +10,35 @@
- [Platform Driver Development](driver-develop.md)
- [ADC](driver-platform-adc-develop.md)
- [GPIO](driver-platform-gpio-develop.md)
- [HDMI](driver-platform-hdmi-develop.md)
- [I2C](driver-platform-i2c-develop.md)
- [I3C](driver-platform-i3c-develop.md)
- [MIPI CSI](driver-platform-mipicsi-develop.md)
- [MIPI DSI](driver-platform-mipidsi-develop.md)
- [MMC](driver-platform-mmc-develop.md)
- [PIN](driver-platform-pin-develop.md)
- [PWM](driver-platform-pwm-develop.md)
- [Regulator](driver-platform-regulator-develop.md)
- [RTC](driver-platform-rtc-develop.md)
- [SDIO](driver-platform-sdio-develop.md)
- [SPI](driver-platform-spi-develop.md)
- [UART](driver-platform-uart-develop.md)
- [Watchdog](driver-platform-watchdog-develop.md)
- [Platform Driver Usage](driver-platform.md)
- [ADC](driver-platform-adc-des.md)
- [GPIO](driver-platform-gpio-des.md)
- [HDMI](driver-platform-hdmi-des.md)
- [I2C](driver-platform-i2c-des.md)
- [MIPI DSI](driver-platform-mipidsi-develop.md)
- [I3C](driver-platform-i3c-des.md)
- [MIPI CSI](driver-platform-mipicsi-des.md)
- [MIPI DSI](driver-platform-mipidsi-des.md)
- [PWM](driver-platform-pwm-des.md)
- [Regulator](driver-platform-regulator-des.md)
- [RTC](driver-platform-rtc-des.md)
- [SDIO](driver-platform-sdio-des.md)
- [SPI](driver-platform-spi-des.md)
- [UART](driver-platform-uart-des.md)
- [Watchdog](driver-platform-watchdog-des.md)
- [Watchdog](driver-platform-watchdog-des.md)
- [Peripheral Driver Usage](driver-peripherals.md)
- [LCD](driver-peripherals-lcd-des.md)
- [Touchscreen](driver-peripherals-touch-des.md)
......
......@@ -4,9 +4,15 @@
- **[GPIO](driver-platform-gpio-develop.md)**
- **[HDMI](driver-platform-hdmi-develop.md)**
- **[I2C](driver-platform-i2c-develop.md)**
- **[MIPI-DSI](driver-platform-mipidsi-develop.md)**
- **[I3C](driver-platform-i3c-develop.md)**
- **[MIPI CSI](driver-platform-mipicsi-develop.md)**
- **[MIPI DSI](driver-platform-mipidsi-develop.md)**
- **[MMC](driver-platform-mmc-develop.md)**
......
# ADC<a name="1"></a>
## Overview<a name="section1"></a>
- An analog-to-digital converter (ADC) is a device that converts analog signals into digital signals.
- The ADC APIs provide a set of common functions for ADC data transfer, including:
- Opening or closing an ADC device
- Obtaining the analog-to-digital (AD) conversion result
**Figure 1** ADC physical connection<a name="fig1"></a>
![](figures/ADC_physical_connection.png "ADC_physical_connection")
## Available APIs<a name="section2"></a>
**Table 1** APIs of the ADC driver
<a name="table1"></a>
<table><thead align="left"><tr><th class="cellrowborder" valign="top" width="18.63%"><p>Category</p>
</th>
<th class="cellrowborder" valign="top" width="28.03%"><p>API</p>
</th>
<th class="cellrowborder" valign="top" width="53.339999999999996%"><p>Description</p>
</th>
</tr>
</thead>
<tbody><tr><td class="cellrowborder" bgcolor="#ffffff" rowspan="2" valign="top" width="18.63%"><p>Managing ADC devices</p>
</td>
<td class="cellrowborder" valign="top" width="28.03%"><p>AdcOpen</p>
</td>
<td class="cellrowborder" valign="top" width="53.339999999999996%">Opens an ADC device.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top"><p>AdcClose</p>
</td>
<td valign="top"><p>Closes an ADC device.</p>
</td>
</tr>
<tr><td class="cellrowborder" bgcolor="#ffffff" valign="top" width="18.63%"><p>Obtaining the conversion result</p>
</td>
<td class="cellrowborder" valign="top" width="28.03%"><p>AdcRead</p>
</td>
<td class="cellrowborder" valign="top" width="53.339999999999996%"><p>Reads the AD conversion result.</p>
</td>
</tr>
</table>
## Usage Guidelines<a name="section3"></a>
### How to Use<a name="section4"></a>
[Figure 2](#fig2) shows how an ADC device works.
**Figure 2** How ADC works<a name="fig2"></a>
![](figures/ADC_flowchart.png "ADC_flowchart")
### Opening an ADC Device<a name="section5"></a>
Call **AdcOpen** to open an ADC device.
```c
DevHandle AdcOpen(int16_t number);
```
**Table 2** Description of AdcOpen
<a name="table2"></a>
<table><thead align="left"><tr><th class="cellrowborder" valign="top" width="20.66%"><p> Parameter</strong></p>
</th>
<th class="cellrowborder" valign="top" width="79.34%"><p><strong>Description</strong></p>
</th>
</tr>
</thead>
<tbody><tr><td class="cellrowborder" valign="top" width="20.66%"><p>number</p>
</td>
<td class="cellrowborder" valign="top" width="79.34%"><p>ADC device number.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="20.66%"><p><strong>Return Value</strong></p>
</td>
<td class="cellrowborder" valign="top" width="79.34%"><p><strong>Description</strong></p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="20.66%"><p>NULL</p>
</td>
<td class="cellrowborder" valign="top" width="79.34%"><p>Failed to open the ADC device.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="20.66%"><p>Device handle</p>
</td>
<td class="cellrowborder" valign="top" width="79.34%"><p>Handle of the ADC device opened.</p>
</td>
</tr>
</tbody>
</table>
For example, open device 1 of the two ADCs (numbered 0 and 1) in the system.
```c
DevHandle adcHandle = NULL; /* ADC device handle /
/* Open the ADC device. */
adcHandle = AdcOpen(1);
if (adcHandle == NULL) {
HDF_LOGE("AdcOpen: failed\n");
return;
}
```
### Obtaining the AD Conversion Result<a name="section6"></a>
```c
int32_t AdcRead(DevHandle handle, uint32_t channel, uint32_t *val);
```
**Table 3** Description of AdcRead
<a name="table3"></a>
<table><thead align="left"><tr><th class="cellrowborder" valign="top" width="50%"><p><strong> Parameter</strong></p>
</th>
<th class="cellrowborder" valign="top" width="50%"><p><strong>Description</strong></p>
</th>
</tr>
</thead>
<tbody><tr><td class="cellrowborder" valign="top" width="50%"><p>handle</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>ADC device handle.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p>channel</p>
</td>
<td class="cellrowborder"valign="top" width="50%"><p>ADC device channel number.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p>val</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>AD conversion result.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p><strong>Return Value</strong></p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p><strong>Description</strong></p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p>0</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>The operation is successful.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p>Negative number</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>Failed to obtain the AC conversion result.</p>
</td>
</tr>
</tbody>
</table>
### Closing an ADC Device<a name="section7"></a>
Call **AdcClose** to close the ADC device after the ADC communication is complete.
```c
void AdcClose(DevHandle handle);
```
**Table 4** Description of AdcClose
<a name="table4"></a>
<table><thead align="left"><tr><th class="cellrowborder" valign="top" width="50%"><p> Parameter</p>
</th>
<th class="cellrowborder" valign="top" width="50%"><p>Description</p>
</th>
</tr>
</thead>
<tbody><tr><td class="cellrowborder" valign="top" width="50%"><p>handle</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>ADC device handle.</p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p><strong>Return Value</strong></p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p><strong>Description</strong></p>
</td>
</tr>
<tr><td class="cellrowborder" valign="top" width="50%"><p>None</p>
</td>
<td class="cellrowborder" valign="top" width="50%"><p>No value is returned if the ADC device is closed.</p>
</td>
</tr>
</tbody>
</table>
Example:
```c
AdcClose(adcHandle); /* Close the ADC device. */
```
## Example<a name="section8"></a>
This following example shows how to use ADC APIs to manage an ADC device on a Hi3516D V300 development board.
The basic hardware information is as follows:
- SoC: hi3516dv300
- The potentiometer is connected to channel 1 of ADC device 0.
Perform continuous read operations on the ADC device to check whether the ADC is functioning.
Example:
```c
#include "adc_if.h" /* Header file for ADC APIs */
#include "hdf_log.h" /* Header file for log APIs */
/* Define device 0, channel 1. */
#define ADC_DEVICE_NUM 0
#define ADC_CHANNEL_NUM 1
/* Main entry of ADC routines. */
static int32_t TestCaseAdc(void)
{
int32_t i;
int32_t ret;
DevHandle adcHandle;
uint32_t Readbuf[30] = {0};
/* Open the ADC device. */
adcHandle = AdcOpen(ADC_DEVICE_NUM);
if (adcHandle == NULL) {
HDF_LOGE("%s: Open ADC%u fail!", __func__, ADC_DEVICE_NUM);
return -1;
}
/* Perform 30 times of AD conversions continuously and read the conversion results. */
for (i = 0; i < 30; i++) {
ret = AdcRead(adcHandle, ADC_CHANNEL_NUM, &Readbuf[i]);
if (ret != HDF_SUCCESS) {
HDF_LOGE("%s: tp ADC write reg fail!:%d", __func__, ret);
AdcClose(adcHandle);
return -1;
}
}
HDF_LOGI("%s: ADC read successful!", __func__);
/* Close the ADC device. */
AdcClose(adcHandle);
return 0;
}
```
# ADC<a name="EN-US_TOPIC_0000001153677754"></a>
## Overview<a name="section268031773165048"></a>
The analog-to-digital converter \(ADC\) is a device that converts analog signals into digital signals. In the Hardware Driver Foundation \(HDF\) framework, the ADC module uses the unified service mode for API adaptation. In this mode, a device service is used as the ADC 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 ADC 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<a name="fig14423182615525"></a>
![](figures/unified-service-mode.png "unified-service-mode")
## How to Develop<a name="section100579767165048"></a>
The ADC 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.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- \(Optional\) Add the **adc\_config.hcs** file.
3. Instantiate the ADC controller object.
- Initialize **AdcDevice**.
- Instantiate **AdcMethod** in the **AdcDevice** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [AdcMethod](#section1618135285210) and [Table 1](#table1943202316536).
4. Debug the driver.
- \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the signal collection is successful.
![](figures/unified-service-mode.png "ADC-unified-service-mode")
## Available APIs<a name="section752964871810"></a>
### AdcMethod<a name="section1618135285210"></a>
......@@ -94,6 +71,30 @@ struct AdcMethod {
</tbody>
</table>
## How to Develop<a name="section100579767165048"></a>
The ADC 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.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- \(Optional\) Add the **adc\_config.hcs** file.
3. Instantiate the ADC controller object.
- Initialize **AdcDevice**.
- Instantiate **AdcMethod** in the **AdcDevice** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [AdcMethod](#section1618135285210) and [Table 1](#table1943202316536).
4. Debug the driver.
- \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the signal collection is successful.
## Development Example<a name="section1745221471165048"></a>
The following uses **adc\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
......
# GPIO<a name="EN-US_TOPIC_0000001153555758"></a>
- [Overview](#section1826197354103451)
- [Available APIs](#section752964871810)
- [How to Develop](#section731175315103451)
- [Development Example](#section800425816103451)
## Overview<a name="section1826197354103451"></a>
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.
......
此差异已折叠。
此差异已折叠。
# I2C<a name="EN-US_TOPIC_0000001206171515"></a>
- [Overview](#section5361140416)
- [Available APIs](#section545869122317)
- [Usage Guidelines](#section1695201514281)
- [How to Use](#section1338373417288)
- [Opening an I2C Controller](#section13751110132914)
- [Performing I2C Communication](#section9202183372916)
- [Closing an I2C Controller](#section19481164133018)
- [Usage Example](#section5302202015300)
## Overview<a name="section5361140416"></a>
- The Inter-Integrated Circuit \(I2C\) is a simple, bidirectional, and synchronous serial bus that uses merely two wires.
......
# I2C<a name="EN-US_TOPIC_0000001153579420"></a>
- [Overview](#section2040078630114257)
- [How to Develop](#section1085786591114257)
- [I2cMethod and I2cLockMethod](#section1683458184518)
- [Development Example](#section1773332551114257)
## Overview<a name="section2040078630114257"></a>
......@@ -13,31 +9,9 @@ The Inter-Integrated Circuit \(I2C\) bus is a simple and bidirectional two-wire
**Figure 1** Unified service mode<a name="fig17640124912440"></a>
![](figures/unified-service-mode.png "unified-service-mode-8")
## How to Develop<a name="section1085786591114257"></a>
## Available APIs<a name="section752964871810"></a>
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.
2. Configure attribute files.
- 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**.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [I2cMethod and I2cLockMethod](#section1683458184518) and [Table 1](#table10549174014611).
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.
### I2cMethod and I2cLockMethod<a name="section1683458184518"></a>
I2cMethod and I2cLockMethod
```
struct I2cMethod {
......@@ -78,6 +52,32 @@ struct I2cLockMethod {// Lock mechanism operation structure
</tbody>
</table>
## How to Develop<a name="section1085786591114257"></a>
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.
2. Configure attribute files.
- 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**.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [I2cMethod and I2cLockMethod](#section1683458184518) and [Table 1](#table10549174014611).
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.
## Development Example<a name="section1773332551114257"></a>
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.
......
此差异已折叠。
此差异已折叠。
# MIPI DSI<a name="EN-US_TOPIC_0000001160971534"></a>
- [Overview](#section16806142183217)
- [Available APIs](#section12720125432316)
- [Usage Guidelines](#section037231715335)
- [How to Use](#section49299119344)
- [Obtaining a MIPI DSI Device Handle](#section5126155683811)
- [Setting MIPI DSI Configuration Parameters](#section201164274344)
- [Sending/Receiving the Pointer to a Command](#section199401342173415)
- [Releasing the MIPI DSI Device Handle](#section161011610357)
- [Usage Example](#section17470126123520)
## Overview<a name="section16806142183217"></a>
- 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<a name="EN-US_TOPIC_0000001199825369"></a>
- [Overview](#section1266787503161538)
- [How to Develop](#section545182932161538)
- [MipiDsiCntlrMethod](#section10711202141617)
- [Development Example](#section1167576616161538)
## Overview<a name="section1266787503161538"></a>
......@@ -13,31 +8,9 @@ The Display Serial Interface \(DSI\) is a specification developed by the Mobile
**Figure 1** Service-free mode<a name="fig207610236189"></a>
![](figures/service-free-mode.png "service-free-mode")
## How to Develop<a name="section545182932161538"></a>
The MIPI DSI module adaptation involves the following steps:
## Available APIs<a name="section752964871810"></a>
1. Instantiate the driver entry.
- 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.
3. Instantiate the MIPI DSI controller object.
- Initialize **MipiDsiCntlr**.
- Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [MipiDsiCntlrMethod](#section10711202141617) and [Table 1](#table218771071713).
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.
### MipiDsiCntlrMethod<a name="section10711202141617"></a>
MipiDsiCntlrMethod
```
struct MipiDsiCntlrMethod {// Member functions of the core layer structure
......@@ -127,6 +100,31 @@ struct MipiDsiCntlrMethod {// Member functions of the core layer structure
</tbody>
</table>
## How to Develop<a name="section545182932161538"></a>
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.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [MipiDsiCntlrMethod](#section10711202141617) and [Table 1](#table218771071713).
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.
## Development Example<a name="section1167576616161538"></a>
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.
......
# MMC<a name="EN-US_TOPIC_0000001153669000"></a>
- [Overview](#section1846388309162704)
- [How to Develop](#section1617495117162704)
- [MmcCntlrOps](#section6203107192915)
- [Development Example](#section1220893490162704)
## Overview<a name="section1846388309162704"></a>
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.
......@@ -13,31 +7,9 @@ In the Hardware Driver Foundation \(HDF\) framework, the MultiMedia Card \(MMC\)
**Figure 1** Independent service mode<a name="fig19517114132810"></a>
![](figures/independent-service-mode.png "independent-service-mode")
## How to Develop<a name="section1617495117162704"></a>
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.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [MmcCntlrOps](#section6203107192915) and [Table 1](#table99129433019).
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.
## Available APIs<a name="section752964871810"></a>
### MmcCntlrOps<a name="section6203107192915"></a>
MmcCntlrOps
```
struct MmcCntlrOps {
......@@ -219,6 +191,30 @@ struct MmcCntlrOps {
</tbody>
</table>
## How to Develop<a name="section1617495117162704"></a>
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.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [MmcCntlrOps](#section6203107192915) and [Table 1](#table99129433019).
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.
## Development Example<a name="section1220893490162704"></a>
The following uses **himci.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
......
# PWM<a name="title_PWM_des"></a>
- [Overview](#section1_PWM_des)
- [PwmConfig Structure](#section1.1_PWM_des)
- [Available APIs](#section2_PWM_des)
- [Usage Guidelines](#section3_PWM_des)
- [How to Use](#section3.1_PWM_des)
- [Opening a PWM Device Handle](#section3.2_PWM_des)
- [Closing a PWM Device Handle](#section3.3_PWM_des)
- [Enabling a PWM Device](#section3.4_PWM_des)
- [Disabling a PWM Device](#section3.5_PWM_des)
- [Setting the PWM Period](#section3.6_PWM_des)
- [Setting the PWM Signal ON-State Time](#section3.7_PWM_des)
- [Setting the PWM Polarity](#section3.8_PWM_des)
- [Setting PWM Device Parameters](#section3.9_PWM_des)
- [Obtaining PWM Device Parameters](#section3.10_PWM_des)
- [Usage Example](#section3_PWM_des)
## Overview <a name="section1_PWM_des"></a>
Pulse width modulation (PWM) is a method used to digitally encode analog signal levels and convert them into pulses. It can be used for motor control and backlight brightness adjustment.
......
# PWM<a name="EN-US_TOPIC_0000001199714793"></a>
- [Overview](#section1591602238164144)
- [How to Develop](#section967396342164144)
- [PwmMethod](#section14560119104318)
- [Development Example](#section1883877829164144)
## Overview<a name="section1591602238164144"></a>
In the Hardware Driver Foundation \(HDF\) framework, the Pulse Width Modulator \(PWM\) 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.
......@@ -13,31 +7,9 @@ In the Hardware Driver Foundation \(HDF\) framework, the Pulse Width Modulator \
**Figure 1** Independent service mode<a name="fig983655084219"></a>
![](figures/independent-service-mode.png "independent-service-mode-10")
## How to Develop<a name="section967396342164144"></a>
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 framework.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [PwmMethod](#section14560119104318) and [Table 1](#table11173154124311).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
## Available APIs<a name="section752964871810"></a>
### PwmMethod<a name="section14560119104318"></a>
PwmMethod
```
struct PwmMethod {
......@@ -91,6 +63,30 @@ struct PwmMethod {
</tbody>
</table>
## How to Develop<a name="section967396342164144"></a>
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 framework.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [PwmMethod](#section14560119104318) and [Table 1](#table11173154124311).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
## Development Example<a name="section1883877829164144"></a>
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.
......
# RTC<a name="EN-US_TOPIC_0000001206373007"></a>
- [Overview](#section104842041574)
- [Available APIs](#section20331159102519)
- [Usage Guidelines](#section20636145604113)
- [How to Use](#section16919828134215)
- [Creating an RTC Device Handle](#section1131212144310)
- [Releasing the RTC Device Handle](#section10744117144314)
- [Registering RtcAlarmCallback](#section14839440184320)
- [Performing RTC-related Operations](#section161927578433)
- [Usage Example](#section1186111020456)
## Overview<a name="section104842041574"></a>
The real-time clock \(RTC\) driver provides precise real time for the operating system \(OS\). If the OS is powered off, the RTC driver continues to keep track of the system time using an external battery.
......
......@@ -13,31 +13,9 @@ In the Hardware Driver Foundation \(HDF\) framework, the real-time clock \(RTC\)
**Figure 1** Independent service mode<a name="fig6742142611299"></a>
![](figures/independent-service-mode.png "independent-service-mode-11")
## How to Develop<a name="section1784450860142407"></a>
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 framework.
2. Configure attribute files.
- 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 [RtcMethod](#section13652132473017) and [Table 1](#table12929217311).
## Available APIs<a name="section752964871810"></a>
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the RTC control status and response to interrupts.
### RtcMethod<a name="section13652132473017"></a>
RtcMethod
```
struct RtcMethod {
......@@ -206,6 +184,30 @@ struct RtcMethod {
</tbody>
</table>
## How to Develop<a name="section1784450860142407"></a>
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 framework.
2. Configure attribute files.
- 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 [RtcMethod](#section13652132473017) and [Table 1](#table12929217311).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the RTC control status and response to interrupts.
## Development Example<a name="section1594883301142407"></a>
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.
......
# SDIO<a name="EN-US_TOPIC_0000001160653028"></a>
- [Overview](#section1155271783811)
- [Available APIs](#section12601496259)
- [Usage Guidelines](#section1878939192515)
- [How to Use](#section1490685512255)
- [Opening an SDIO Controller](#section10782428132616)
- [Claiming a Host Exclusively](#section11263172312715)
- [Enabling the SDIO Device](#section17861486271)
- [Claiming an SDIO IRQ](#section521213262286)
- [Performing SDIO Communication](#section85661522153420)
- [Releasing the SDIO IRQ](#section1683449352)
- [Disabling the SDIO Device](#section15379324143611)
- [Releasing the Exclusively Claimed Host](#section536018263713)
- [Closing an SDIO Controller](#section4752739183716)
- [Usage Example](#section376910122382)
## Overview<a name="section1155271783811"></a>
- Secure Digital Input/Output \(SDIO\) is a peripheral interface evolved from the Secure Digital \(SD\) memory card interface. The SDIO interface is compatible with SD memory cards and can be connected to devices that support the SDIO interface.
......
# SDIO<a name="EN-US_TOPIC_0000001199682295"></a>
- [Overview](#section1347805272150053)
- [How to Develop](#section581179475150053)
- [SdioDeviceOps](#section482911395315)
- [Development Example](#section2112250242150053)
## Overview<a name="section1347805272150053"></a>
......@@ -13,31 +8,9 @@ A Secure Digital Input Output \(SDIO\) card is an extension of the SD specificat
**Figure 1** Independent service mode<a name="fig124181331222"></a>
![](figures/independent-service-mode.png "independent-service-mode-12")
## How to Develop<a name="section581179475150053"></a>
The SDIO 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.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- \(Optional\) Add the **sdio\_config.hcs** file.
3. Instantiate the SDIO controller object.
- Initialize **SdioDevice**.
- Instantiate **SdioDeviceOps** in the **SdioDevice** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [SdioDeviceOps](#section482911395315) and [Table 1](#table878215448417).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the SDIO control status and response to interrupts.
## Available APIs<a name="section752964871810"></a>
### SdioDeviceOps<a name="section482911395315"></a>
SdioDeviceOps
```
// Function template
......@@ -300,6 +273,30 @@ struct SdioDeviceOps {
>- **irqCap**: specifies the interrupt request \(IRQ\) capabilities.
>- **\(void \*\)data**
## How to Develop<a name="section581179475150053"></a>
The SDIO 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.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- \(Optional\) Add the **sdio\_config.hcs** file.
3. Instantiate the SDIO controller object.
- Initialize **SdioDevice**.
- Instantiate **SdioDeviceOps** in the **SdioDevice** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [SdioDeviceOps](#section482911395315) and [Table 1](#table878215448417).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the SDIO control status and response to interrupts.
## Development Example<a name="section2112250242150053"></a>
The following uses **sdio\_adapter.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
......
# SPI<a name="EN-US_TOPIC_0000001206171293"></a>
- [Overview](#section193356154511)
- [Available APIs](#section1325964832615)
- [Usage Guidelines](#section71363452477)
- [How to Use](#section32846814820)
- [Obtaining an SPI Device Handle](#section1927265711481)
- [Obtaining SPI Device Configuration Parameters](#section541133418493)
- [Setting SPI Device Configuration Parameters](#section7870106145010)
- [Performing SPI Communication](#section13324155195013)
- [Destroying the SPI Device Handle](#section19661632135117)
- [Usage Example](#section06541058155120)
## Overview<a name="section193356154511"></a>
- Serial Peripheral Interface \(SPI\) is a serial bus specification used for high-speed, full-duplex, and synchronous communication.
......
# SPI<a name="EN-US_TOPIC_0000001199690327"></a>
- [Overview](#section84922229152909)
- [Available APIs](#section752964871810)
- [How to Develop](#section799667984152909)
- [Development Example](#section956157227152909)
## Overview<a name="section84922229152909"></a>
......
# UART<a name="EN-US_TOPIC_0000001160652800"></a>
- [Overview](#section833012453535)
- [Available APIs](#section1928742202715)
- [Usage Guidelines](#section12779050105412)
- [How to Use](#section1858116395510)
- [Obtaining a UART Device Handle](#section124512065617)
- [Setting the UART Baud Rate](#section86881004579)
- [Obtaining the UART Baud Rate](#section897032965712)
- [Setting the UART Device Attributes](#section129141884588)
- [Obtaining UART Device Attributes](#section18689637165812)
- [Setting the UART Transmission Mode](#section72713435918)
- [Writing Data of a Specified Length into a UART Device](#section128001736155919)
- [Reading Data of a Specified Length from a UART Device](#section92851601604)
- [Destroying the UART Device Handle](#section1477410521406)
- [Usage Example](#section35404241311)
## Overview<a name="section833012453535"></a>
- 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.
......
......@@ -13,31 +13,9 @@ In the Hardware Driver Foundation \(HDF\) framework, the Universal Asynchronous
**Figure 1** Independent service mode<a name="fig1474518243468"></a>
![](figures/independent-service-mode.png "independent-service-mode-14")
## How to Develop<a name="section944397404154520"></a>
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 framework.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [UartHostMethod](#section192316441461) and [Table 1](#table22862114719).
## Available APIs<a name="section752964871810"></a>
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the UART control status and response to interrupts.
### UartHostMethod<a name="section192316441461"></a>
UartHostMethod
```
struct UartHostMethod {
......@@ -190,6 +168,30 @@ struct UartHostMethod {
</tbody>
</table>
## How to Develop<a name="section944397404154520"></a>
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 framework.
2. Configure attribute files.
- 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.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [UartHostMethod](#section192316441461) and [Table 1](#table22862114719).
4. Debug the driver.
- \(Optional\) For new drivers, verify the basic functions, such as the UART control status and response to interrupts.
## Development Example<a name="section774610224154520"></a>
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.
......
# Watchdog<a name="EN-US_TOPIC_0000001206372825"></a>
- [Overview](#section14918241977)
- [Available APIs](#section1180575010271)
- [Usage Guidelines](#section10103184312813)
- [How to Use](#section10181195910815)
- [Opening a Watchdog](#section66089201107)
- [Obtaining the Watchdog Status](#section786624341011)
- [Setting the Timeout Duration](#section182386137111)
- [Obtaining the Timeout Duration](#section1883310371114)
- [Starting a Watchdog](#section82501405123)
- [Feeding a Watchdog](#section3547530101211)
- [Stopping a Watchdog](#section944595841217)
- [Closing a Watchdog](#section96561824121311)
- [Usage Example](#section1724514523135)
## Overview<a name="section14918241977"></a>
A watchdog, also called a watchdog timer, is a hardware timing device. If an error occurs in the main program of the system and fails to reset the watchdog timer, the watchdog timer sends a reset signal to restore the system to a normal state.
......
# Watchdog<a name="EN-US_TOPIC_0000001199821009"></a>
- [Overview](#section1315827527160117)
- [How to Develop](#section477974542160117)
- [WatchdogMethod](#section220331929)
- [Development Example](#section1832270347160117)
## Overview<a name="section1315827527160117"></a>
......@@ -13,31 +8,9 @@ In the Hardware Driver Foundation \(HDF\) framework, the Watchdog \(also called
**Figure 1** Independent service mode<a name="fig61584136211"></a>
![](figures/independent-service-mode.png "independent-service-mode-15")
## How to Develop<a name="section477974542160117"></a>
The Watchdog module adaptation involves the following steps:
## Available APIs<a name="section1180575010271"></a>
1. Instantiate the driver entry.
- 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 **watchdog\_config.hcs** file.
3. Instantiate the Watchdog controller object.
- Initialize **WatchdogCntlr**.
- Instantiate **WatchdogMethod** in the **WatchdogCntlr** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [WatchdogMethod](#section220331929) and [Table 1](#table1370451732).
4. Debug the driver.
- \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the watchdog timer is successfully set.
### WatchdogMethod<a name="section220331929"></a>
WatchdogMethod
```
struct WatchdogMethod {
......@@ -137,6 +110,31 @@ struct WatchdogMethod {
</tbody>
</table>
## How to Develop<a name="section477974542160117"></a>
The Watchdog 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.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- \(Optional\) Add the **watchdog\_config.hcs** file.
3. Instantiate the Watchdog controller object.
- Initialize **WatchdogCntlr**.
- Instantiate **WatchdogMethod** in the **WatchdogCntlr** object.
>![](../public_sys-resources/icon-note.gif) **NOTE:**
>For details, see [WatchdogMethod](#section220331929) and [Table 1](#table1370451732).
4. Debug the driver.
- \(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the watchdog timer is successfully set.
## Development Example<a name="section1832270347160117"></a>
The following uses **watchdog\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
......
# Platform Driver Usage<a name="EN-US_TOPIC_0000001111199424"></a>
# Driver Platform Usage<a name="en-us_TOPIC_0000001111199424"></a>
- **[ADC](driver-platform-adc-des.md)**
- **[GPIO](driver-platform-gpio-des.md)**
- **[HDMI](driver-platform-hdmi-des.md)**
- **[I2C](driver-platform-i2c-des.md)**
- **[I3C](driver-platform-i3c-des.md)**
- **[MIPI CSI](driver-platform-mipicsi-des.md)**
- **[MIPI DSI](driver-platform-mipidsi-des.md)**
- **[PWM](driver-platform-pwm-des.md)**
- **[RTC](driver-platform-rtc-des.md)**
- **[SDIO](driver-platform-sdio-des.md)**
......@@ -13,9 +25,3 @@
- **[UART](driver-platform-uart-des.md)**
- **[Watchdog](driver-platform-watchdog-des.md)**
- **[MIPI DSI](driver-platform-mipidsi-des.md)**
- **[PWM](driver-platform-pwm-des.md)**
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册