Skip to content

D
Docs

OpenHarmony / Docs
大约 1 年 前同步成功

通知 159
Star 292
Fork 28
D
Docs
未验证 提交 bc99d0e6 编写于 作者: O openharmony_ci 提交者： Gitee
浏览文件
操作

!5181 【翻译完成】#I57QRA 

Merge pull request !5181 from Annie_wang/PR3940A
上级 d34e6236 3050c119
展开全部 隐藏空白更改
内联 并排
Showing with 727 addition and 1054 deletion
en/device-dev/driver/driver-platform-gpio-develop.md
浏览文件 @ bc99d0e6
......@@ -28,7 +28,7 @@ struct GpioMethod {
int32_t (*unsetIrq)(struct GpioCntlr *cntlr, uint16_t local);
int32_t (*enableIrq)(struct GpioCntlr *cntlr, uint16_t local);
int32_t (*disableIrq)(struct GpioCntlr *cntlr, uint16_t local);
}
};
```
**Table 1** Description of the callback functions in GpioMethod
......@@ -63,7 +63,7 @@ The GPIO module adaptation involves the following steps:
- Initialize **GpioCntlr**.
- Instantiate **GpioMethod** in the **GpioCntlr** object.
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**<br/> For details about the callbacks in **GpioMethod**, see [Available APIs](#available-apis).
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**<br/> For details about the functions in **GpioMethod**, see [Available APIs](#available-apis).
4. Debug the driver.
......@@ -72,7 +72,7 @@ The GPIO module adaptation involves the following steps:
## Development Example
The following uses **gpio_hi35xx.c** as an example to present the information to be provided by the vendor for implementing device functions.
The following uses **gpio_hi35xx.c** as an example to present the information required for implementing device functions.
1. Instantiate the driver entry.
......@@ -143,7 +143,7 @@ The following uses **gpio_hi35xx.c** as an example to present the information to
3. Initialize the **GpioCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Init** and **Release**) to instantiate **GpioMethod** in **GpioCntlr** (so that the underlying driver functions can be called).
- Defining a custom structure
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **gpio_config.hcs** file to initialize the members in the custom structure and passes important parameters, such as the GPIO group number and the number of pins, to the **GpioCntlr** object at the core layer.
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **gpio_config.hcs** file to initialize the members in the custom structure and pass important parameters, such as the GPIO group number and the number of pins, to the **GpioCntlr** object at the core layer.
```
......
en/device-dev/driver/driver-platform-hdmi-develop.md
浏览文件 @ bc99d0e6
......@@ -235,7 +235,7 @@ The HDMI module adaptation involves the following steps:
> ![](../public_sys-resources/icon-note.gif) **NOTE**
>
>
> To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **hdmi_config.hcs** file to initialize the members in the custom structure and passes important parameters, such as the device number and bus number, to the **HdmiCntlr** object at the core layer.
> To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **hdmi_config.hcs** file to initialize the members in the custom structure and pass important parameters, such as the device number and bus number, to the **HdmiCntlr** object at the core layer.
```c
struct HdmiAdapterHost {
......
en/device-dev/driver/driver-platform-mipicsi-des.md
浏览文件 @ bc99d0e6
# MIPI CSI<a name="title_MIPI_CSIDes"></a>
# MIPI CSI
## Overview<a name="section1_MIPI_CSIDes"></a>
## 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. As the second release, the MIPI CSI-2 consists of the application layer, protocol layer, and physical layer. It supports a maximum of four-lane data transmission and a single-lane transmission rate of 1 Gbit/s.
The physical layer supports the high speed (HS) and low power (LP) modes. Using low-voltage differential signaling (LVDS), the HS mode delivers 80 Mbit/s to 1 Gbit/s transmission speed but high power consumption. The unidirectional LP mode provides lower power consumption but lower transmission speed (< 10 Mbit/s). The blend of the two modes ensures high-speed transmission of massive data (such as images) and minimized power consumption when less data is transmitted.
The physical layer supports the high speed (HS) and low speed (LS) modes. Using low-voltage differential signaling (LVDS), the HS mode delivers 80 Mbit/s to 1 Gbit/s transmission speed but high power consumption. The unidirectional LS mode provides lower power consumption but lower transmission speed (< 10 Mbit/s). The blend of the two modes ensures high-speed transmission of massive data (such as images) and minimized power consumption when less data is transmitted.
The figure below shows a simplified CSI. The D-PHY transmits data by using one pair of source-synchronized differential clocks and one to four pairs of differential data lanes. Data is transmitted in Double Data Rate (DDR) mode, that is, data is transmitted on both the rising and falling edges of the clock.
**Figure 1** CSI TX and RX interfaces<a name="fig1_MIPI_CSIDes"></a>
![](figures/CSI_TX-RX_interface.png)
**Figure 1** CSI TX and RX interfaces
![](figures/CSI_TX-RX_interface.png)
### ComboDevAttr Structure<a name="section1.1_MIPI_CSIDes"></a>
### ComboDevAttr Structure
**Table 1** ComboDevAttr structure
......@@ -26,7 +27,7 @@ The figure below shows a simplified CSI. The D-PHY transmits data by using one p
| MIPIAttr | Attributes of the MIPI device. |
| lvdsAttr | Attributes of the LVDS, sub-LVDS, or HiSPi device. |
### ExtDataType Structure<a name="section1.2_MIPI_CSIDes"></a>
### ExtDataType Structure
**Table 2** ExtDataType structure
......@@ -39,33 +40,34 @@ The figure below shows a simplified CSI. The D-PHY transmits data by using one p
| extDataBitWidth | Bit depth of an image. |
| extDataType | Pointer to the YUV, raw data format, and bit depth.|
### Available APIs<a name="section1.3_MIPI_CSIDes"></a>
### Available APIs
**Table 3** MIPI CSI APIs
<a name="table3_MIPI_CSIDes"></a>
| Category| API|
| Category| API|
| -------- | -------- |
| Opening or closing the MIPI CSI controller operation handle| **MipiCsiOpen**: opens the MIPI CSI controller operation handle.<br>**MipiCsiClose**: closes the MIPI CSI controller operation handle.|
| Setting MIPI CSI parameters| **MipiCsiSetComboDevAttr**: sets parameters of the MIPI, CMOS, or LVDS camera to the controller. The parameters include the working mode, image area, image depth, data rate, and physical channel.<br>**MipiCsiSetExtDataType** (optional): sets the YUV and RAW data formats and bit depths.<br>**MipiCsiSetHsMode**: sets the MIPI RX lane distribution. Set the mode based on the hardware connection.<br>**MipiCsiSetPhyCmvmode**: sets the common-mode voltage (CMV) mode.|
| Resetting a sensor or deasserting the reset of a sensor| **MipiCsiResetSensor**: resets a sensor.<br>**MipiCsiUnresetSensor**: deasserts the reset of a sensor.|
| Resetting the MIPI RX or deasserting the reset of the MIPI RX| **MipiCsiResetRx**: resets the MIPI&amp;nbsp;RX. The value of **enSnsType** varies depending on the value of **s32WorkingViNum**.<br>**MipiCsiUnresetRx**: deasserts the reset on the MIPI&amp;nbsp;RX.|
| Enabling or disabling the MIPI clock| **MipiCsiEnableClock**: enables the MIPI clock. The **enSnsType** passed by the upper-layer function during electrophoresis determines whether MIPI or LVDS is used.<br>**MipiCsiDisableClock**: disables the MIPI clock.|
| Enabling or disabling the MIPI sensor clock| **MipiCsiEnableSensorClock**: enables the MIPI sensor clock.<br>**MipiCsiDisableSensorClock**: disables the MIPI sensor clock.|
| Opening or closing the MIPI CSI controller operation handle| **MipiCsiOpen**: opens the MIPI CSI controller operation handle.<br>**MipiCsiClose**: closes the MIPI CSI controller operation handle.|
| Setting MIPI CSI attributes | **MipiCsiSetComboDevAttr**: sets attributes of the MIPI, CMOS, or LVDS camera to the controller. The attributes include the working mode, image area, image depth, data rate, and physical channel.<br>**MipiCsiSetExtDataType** (optional): sets the YUV and RAW data formats and bit depths.<br>**MipiCsiSetHsMode**: sets the MIPI RX lane distribution. Set the mode based on the hardware connection.<br>**MipiCsiSetPhyCmvmode**: sets the common-mode voltage (CMV) mode. |
| Resetting a sensor or deasserting the reset of a sensor| **MipiCsiResetSensor**: resets a sensor.<br>**MipiCsiUnresetSensor**: deasserts the reset of a sensor.|
| Resetting the MIPI RX or deasserting the reset of the MIPI RX| **MipiCsiResetRx**: resets the MIPI&amp;nbsp;RX. The value of **enSnsType** varies depending on the value of **s32WorkingViNum**.<br>**MipiCsiUnresetRx**: deasserts the reset on the MIPI&amp;nbsp;RX.|
| Enabling or disabling the MIPI clock| **MipiCsiEnableClock**: enables the MIPI clock. The **enSnsType** passed by the upper-layer function during electrophoresis determines whether MIPI or LVDS is used.<br>**MipiCsiDisableClock**: disables the MIPI clock.|
| Enabling or disabling the MIPI sensor clock| **MipiCsiEnableSensorClock**: enables the MIPI sensor clock.<br>**MipiCsiDisableSensorClock**: disables the MIPI sensor clock.|
## Usage Guidelines<a name="section2_MIPI_CSIDes"></a>
## Usage Guidelines
### How to Use<a name="section2.1_MIPI_CSIDes"></a>
### How to Use
The figure below illustrates how to use the APIs.
The figure below illustrates the general development process.
**Figure 2** Using MIPI CSI driver APIs
![](figures/using-MIPI-CSI-process.png)
### Opening the MIPI CSI Controller Operation Handle<a name="section2.2_MIPI_CSIDes"></a>
### Opening a MIPI CSI Controller Operation Handle
Before starting MIPI CSI communication, call **MipiCsiOpen** to open the MIPI CSI device handle. This function returns the MIPI CSI device handle with the specified lane ID.
......@@ -81,10 +83,10 @@ DevHandle MipiCsiOpen(uint8_t id);
| ---------- | ----------------------------------------------- |
| id | MIPI CSI lane ID. |
| **Return Value**| **Description** |
| NULL | The operation fails. |
| Device handle | MIPI CSI device handle with the specified lane ID. The data type is **DevHandle**.|
| NULL | The operation failed. |
| Device handle | The operation is successful. The MIPI CSI device handle with the specified lane ID is returned. The data type is **DevHandle**. |
For example, open the controller operation handle for MIPI CSI lane 0:
For example, open the controller operation handle of MIPI CSI lane 0:
```c
DevHandle mipiCsiHandle = NULL; /* Device handle */
......@@ -98,9 +100,9 @@ if (MipiCsiHandle == NULL) {
}
```
### Setting MIPI CSI Parameters<a name="section2.3_MIPI_CSIDes"></a>
### Setting MIPI CSI Attributes
- Set MIPI CSI parameters.
- Set MIPI CSI attributes.
```c
int32_t MipiCsiSetComboDevAttr(DevHandle handle, ComboDevAttr *pAttr);
......@@ -116,7 +118,7 @@ if (MipiCsiHandle == NULL) {
| pAttr | Pointer to the MIPI CSI structure.|
| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -155,7 +157,7 @@ if (MipiCsiHandle == NULL) {
| dataType | Pointer to the YUV, raw data format, and bit depth.|
| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -195,7 +197,7 @@ if (MipiCsiHandle == NULL) {
| laneDivideMode | Lane mode. |
| **Return Value** | **Description**|
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -228,7 +230,7 @@ if (MipiCsiHandle == NULL) {
| devno | Device number. |
| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -247,7 +249,7 @@ if (MipiCsiHandle == NULL) {
}
```
### Resetting a Sensor or Deasserting the Reset of a Sensor<a name="section2.4_MIPI_CSIDes"></a>
### Resetting a Sensor or Deasserting the Reset of a Sensor
- Reset a sensor.
......@@ -262,10 +264,10 @@ if (MipiCsiHandle == NULL) {
| Parameter | Description |
| -------------- | ------------------------------------------------ |
| handle | Controller operation handle. |
| snsResetSource | Sensor's reset signal cable number, which is called reset source of the sensor in software.|
| snsResetSource | Sensor's reset signal cable number, which is called "sensor reset source" in software. |
| **Return Value** | **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -294,10 +296,10 @@ if (MipiCsiHandle == NULL) {
| Parameter | Description |
| -------------- | ------------------------------------------------ |
| handle | Controller operation handle. |
| snsResetSource | Sensor's reset signal cable number, which is called reset source of the sensor in software.|
| snsResetSource | Sensor's reset signal cable number, which is called "sensor reset source" in software. |
| **Return Value** | **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -313,7 +315,7 @@ if (MipiCsiHandle == NULL) {
}
```
### Resetting the MIPI RX or Deasserting the Reset of the MIPI RX<a name="section2.5_MIPI_CSIDes"></a>
### Resetting the MIPI RX or Deasserting the Reset of the MIPI RX
- Reset the MIPI RX.
......@@ -331,7 +333,7 @@ if (MipiCsiHandle == NULL) {
| comboDev | MIPI RX or LVDS channel number.|
| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -363,7 +365,7 @@ if (MipiCsiHandle == NULL) {
| comboDev | MIPI RX or LVDS channel number.|
| **Return Value**| **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -379,7 +381,7 @@ if (MipiCsiHandle == NULL) {
}
```
### Enabling or Disabling the MIPI Clock<a name="section2.6_MIPI_CSIDes"></a>
### Enabling or Disabling the MIPI Clock
- Enable the MIPI clock.
......@@ -397,7 +399,7 @@ if (MipiCsiHandle == NULL) {
| comboDev | Channel number. |
| **Return Value**| **Description**|
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -429,7 +431,7 @@ if (MipiCsiHandle == NULL) {
| comboDev | Channel number. |
| **Return Value**| **Description**|
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -445,7 +447,7 @@ if (MipiCsiHandle == NULL) {
}
```
### Enabling or Disabling the MIPI Sensor Clock<a name="section2.7_MIPI_CSIDes"></a>
### Enabling or Disabling the MIPI Sensor Clock
- Enable the MIPI sensor clock.
......@@ -463,7 +465,7 @@ if (MipiCsiHandle == NULL) {
| snsClkSource | Sensor's clock signal cable number, which is called clock source of the sensor in software.|
| **Return Value** | **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -495,7 +497,7 @@ if (MipiCsiHandle == NULL) {
| snsClkSource | Sensor's clock signal cable number, which is called clock source of the sensor in software.|
| **Return Value** | **Description** |
| 0 | The operation is successful. |
| Negative value | The operation fails. |
| Negative value | The operation failed. |
```c
int32_t ret;
......@@ -511,9 +513,9 @@ if (MipiCsiHandle == NULL) {
}
```
### Closing a MIPI CSI Controller Operation Handle<a name="section2.8_MIPI_CSIDes"></a>
### Closing a MIPI CSI Controller Operation Handle
After the MIPI CSI communication, close the MIPI CSI controller handle by calling the following function:
Call **MipiCsiClose()** to close the MIPI CSI controller handle after the MIPI CSI communication is complete.
```c
void MipiCsiClose(DevHandle handle);
......@@ -533,7 +535,7 @@ This function releases the resources requested by **MipiCsiOpen**.
MipiCsiClose(MIPIHandle); /* Close the operation handle of the MIPI CSI controller. */
```
## Development Example<a name="section3_MIPI_CSIDes"></a>
## Example
The sample code is as follows:
......
en/device-dev/driver/driver-platform-rtc-develop.md
浏览文件 @ bc99d0e6
......@@ -3,7 +3,7 @@
## Overview
The real-time clock (RTC) is a real-time clock device in the operating system. In the HDF, the RTC uses the independent service mode for API adaptation. In this mode, each device independently publishes a service to process external access requests. When receiving an access request, the HDF DeviceManager extracts parameters from the request to call the internal APIs of the target device. In the independent service mode, the HDF DeviceManager provides service management capabilities. However, you need to configure a node for each device to increase memory resources.
The real-time clock (RTC) is a real-time clock device in the operating system. In the Hardware Driver Foundation (HDF), the RTC uses the independent service mode for API adaptation. In this mode, each device independently publishes a service to process external access requests. When receiving an access request, the HDF DeviceManager extracts parameters from the request to call the internal APIs of the target device. In the independent service mode, the HDF DeviceManager provides service management capabilities. However, you need to configure a node for each device to increase memory resources.
**Figure 1** Independent service mode
......@@ -14,7 +14,7 @@ The real-time clock (RTC) is a real-time clock device in the operating system. I
**RtcMethod**:
```
struct RtcMethod {
int32_t (*ReadTime)(struct RtcHost *host, struct RtcTime *time);
......@@ -64,7 +64,7 @@ The RTC module adaptation involves the following steps:
- Initialize **RtcHost**.
- Instantiate **RtcMethod** in the **RtcHost** object.
> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**<br>
> For details about the functions in **RtcMethod**, see [API APIs](#available-apis).
> For details about the functions in **RtcMethod**, see [Available APIs](#available-apis).
4. Debug the driver.
(Optional) For new drivers, verify the basic functions, such as the RTC status control and response to interrupts.
......@@ -72,13 +72,13 @@ The RTC module adaptation involves the following steps:
## Development Example
The following uses **rtc_hi35xx.c** as an example to present the information to be provided by the vendor to implement device functions.
The following uses **rtc_hi35xx.c** as an example to present the information required for implementing device functions.
1. Instantiate the driver entry.<br/>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, 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.
RTC driver entry example:
```
struct HdfDriverEntry g_rtcDriverEntry = {
.moduleVersion = 1,
......@@ -91,11 +91,14 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
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.
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 for each controller.
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 for each controller.
- **device_info.hcs** configuration example
```
root {
device_info {
......@@ -117,7 +120,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
- **rtc_config.hcs** configuration example
```
root {
platform {
......@@ -136,16 +139,16 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
lock3Addr = 0xff;
}
}
}
}
}
```
```
3. Initialize the **RtcHost** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Bind**, **Init** and **Release**) to instantiate **RtcMethod** in **RtcHost** (so that the underlying driver functions can be called).
- Defining a custom structure
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **rtc_config.hcs** file to initialize the members in the custom structure.
```
struct RtcConfigInfo {
uint32_t spiBaseAddr; // Used for address mapping.
......@@ -171,7 +174,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
```
- Instantiating **RtcMethod** in **RtcHost** (other members are initialized by **Init**)
```
// Example in rtc_hi35xx.c: instantiate the hook.
static struct RtcMethod g_method = {
......@@ -214,7 +217,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
Binds the **HdfDeviceObject** object and **RtcHost**.
```
static int32_t HiRtcBind(struct HdfDeviceObject *device)
{
......@@ -242,7 +245,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
Initializes the custom structure object and **RtcHost**.
```
static int32_t HiRtcInit(struct HdfDeviceObject *device)
{
......@@ -284,7 +287,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information to
Releases the memory and deletes the controller. This function assigns values to the **Release** function 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. 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)
{
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或