@@ -74,6 +74,36 @@ Unregisters the listener for completion of component layout or drawing.
| type | string | Yes | Type of the listener. The value must be **'layout'** or **'draw'**.<br>**'layout'**: completion of component layout.<br>**'draw'**: completion of component drawing.|
| callback | void | No | Callback to unregister. If this parameter is not specified, all callbacks of the specified type are unregistered.|
### on
on(type: 'draw', callback: () => void): void
Registers a listener for completion of component drawing.
| type | string | Yes | Type of the listener. The value must be **'layout'** or **'draw'**.<br>**'layout'**: completion of component layout.<br>**'draw'**: completion of component drawing.|
| callback | void | Yes | Callback invoked upon completion of component layout or drawing. |
### off
off(type: 'draw', callback?: () => void): void
Unregisters the listener for completion of component drawing.
| type | string | Yes | Type of the listener. The value must be **'layout'** or **'draw'**.<br>**'layout'**: completion of component layout.<br>**'draw'**: completion of component drawing.|
| callback | void | No | Callback to unregister. If this parameter is not specified, all callbacks of the specified type are unregistered.|
| option | [number,number,number,number,number,number,number,number,number,number,number,number,number,number,number,number] | Yes | A number array whose length is 16 (4 x 4). For details, see **Description of a 4 x 4 matrix**.<br>Default value:<br>[1, 0, 0, 0,<br>0, 1, 0, 0,<br>0, 0, 1, 0,<br>0, 0, 0, 1] |
| option | [number,number,number,number,<br>number,number,number,number,<br>number,number,number,number,<br>number,number,number,number] | Yes | A number array whose length is 16 (4 x 4). For details, see **Description of a 4 x 4 matrix**.<br>Default value:<br>[1, 0, 0, 0,<br>0, 1, 0, 0,<br>0, 0, 1, 0,<br>0, 0, 0, 1] |
@@ -46,7 +46,7 @@ The environment configuration is as follows:
<sn></sn><!-- sn: device SN list. SNs are separated using semicolons (;). All local devices are used when the SN is empty. The device with the specified SN will be used if the SN is not empty. -->
</device>
<!-- L0 device configuration -->
<!-- Mini-system device configuration -->
<devicetype="com"label="wifiiot"><!-- type: device connection mode. com indicates the serial port connection mode. label indicates the device type, for example, wifiot. -->
<serial><!-- serial: serial port definition. -->
<com></com><!-- com: serial port of the local connection, for example, COM20. -->
...
...
@@ -63,7 +63,7 @@ The environment configuration is as follows:
</serial>
</device>
<!-- L1 device local connection configuration -->
<!-- Small-system device local connection configuration -->
<devicetype="com"label="ipcamera">
<serial>
<com></com>
...
...
@@ -75,7 +75,7 @@ The environment configuration is as follows:
</serial>
</device>
<!-- L1 device remote connection configuration. Multiple connections can be configured. -->
<!-- Small-system device remote connection configuration. Multiple connections can be configured. -->
If the AT command serial port is the same as the log output serial port, the serial ports can be set to the same port. That is, in the **user_config** file, the COM port whose **type** is **cmd** and the COM port whose **type** is **deploy** can be set to the same port, for example, **COM18**.


The following is an example of the modified **user_config.xml** file:
The COM port whose **type** is **cmd** corresponds to the AT command serial port on the board. The port is used to send commands to the device. In the example, the **ChA(COM20)** serial port is used.


IP camera devices have two connection modes. One is to connect through the local serial port, and the other is to connect through the IP address of the local area network.
@@ -34,7 +34,7 @@ The following describes how to start and run the light module driver on an RK356
### When to Use
Light control is widely used in daily life. For example, a light is blinking when a mobile phone receives an SMS message or has low battery level, and a light changes its colors based on the device charging status. These actions are implemented by calling the APIs provided by the light driver model.
Light control is widely used in daily life. For example, a light is blinking when a mobile device receives an SMS message or has low battery level, and a light changes its colors based on the device charging status. These actions are implemented by calling the APIs provided by the light driver model.
## Setting Up the Development Environment<a name="section1912530122716"></a>
## Setting Up the Development Environment
Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/software_install-0000001053582415).
Download and configure DevEco Studio. For details, see [DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/software_install-0000001053582415).
## Creating a Project<a name="section1456035192720"></a>
## Creating a Project
1. Open the project wizard using either of the following methods:
- If no project is open, select **Create HarmonyOS Project** on the welcome page.
- If a project is already open, go to **File**\>**New**\>**New Project** on the menu bar.
1. Open the DevEco Studio project wizard using either of the following methods:
- If no project is open, select **Create Project** on the welcome page.
- If a project is already open, choose **File**\>**New**\>**Create Project** on the menu bar.
2.Choose the **Smart Vision** for **Device** and **Empty Feature Ability** for **Template**.
2.Select the **Empty Ability** template under **Application** and click **Next**.

3. Click **Next** and configure the project.
-**Project Name**: project name.
-**Package Name**: software package name. By default, this name will also be used as your application ID. Your application must have a unique ID to be released.
-**Save Location**: path for storing project files. The path cannot contain Chinese characters or spaces.
-**Compatible API Version**: compatible API version of the SDK.
4. Click **Finish**. DevEco Studio will automatically generate the sample code and resources that match your project type. Wait until the project is created.
3. Enter project information by retaining the default values, and click **Finish**.
For details about the parameters, see [DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides-V3/create_new_project-0000001053342414-V3).
After the project is created, DevEco Studio automatically starts project synchronization.
Create a platform driver in the source code directory **//device/vendor_name/soc_name/drivers**. If there is no repository for the vendor of your SoC, contact the [device SIG](https://gitee.com/openharmony/community/blob/master/sig/sig_devboard/sig_devboard.md) to create one.
Create a platform driver in the source code directory **//device/vendor\_name/soc\_name/drivers**. If there is no repository for the vendor of your SoC, contact the [device SIG](https://gitee.com/openharmony/community/blob/master/sig/sig_devboard/sig_devboard.md) to create one.
The recommended directory structure is as follows:
...
...
@@ -29,137 +31,141 @@ device
│ ├── board_name
```
The HDF creates driver models for all platform drivers. The main task of porting platform drivers is to inject instances into the models. You can find the definitions of these models in the source code directory **//drivers/framework/support/platform/include**.
The HDF creates driver models for all platform drivers. The main task of porting platform drivers is to inject instances into the models. You can find the definitions of these models in the source code directory **//drivers/hdf_core/framework/support/platform/include**.
The following uses the GPIO as an example to describe how to port the platform driver:
1. Create a GPIO driver.
Create the **soc\_name\_gpio.c** file in the source code directory **//device/vendor\_name/soc\_name/drivers/gpio**. The sample code is as follows:
```
#include "gpio_core.h"
// Define the GPIO structure if necessary.
struct SocNameGpioCntlr {
struct GpioCntlr cntlr; // Structure required by the HDF GPIO driver framework.
int myData; // The following information is required by the current driver.
};
// The Bind method is mainly used to release services in the HDF driver. As this method is not needed here, simply return a success message.
@@ -22,7 +22,7 @@ The following exemplifies how to burn an image to Hi3516DV300 using HiTool. You
1. Prepare the files to be burnt.
1. On the client platform, create a folder for storing the files to be burnt, for example, **D:\liteos** or **D:\linux**.
2. Save the burning configuration file and boot file to the new folder.
- For L1_LiteOS, the burning configuration file is **L1_3516_liteos.xml**, and the boot file is **[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)**.
- For the small system with the LiteOS kernel, the burning configuration file is **L1_3516_liteos.xml**, and the boot file is **[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)**.
You need to prepare the **L1_3516_liteos.xml** file on your own by applying the template below:
...
...
@@ -35,7 +35,7 @@ The following exemplifies how to burn an image to Hi3516DV300 using HiTool. You
- For L1_Linux, the burning configuration file is **L1_3516_linux.xml**, and the boot file is **[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)**.
- For the small system with the Linux kernel, the burning configuration file is **L1_3516_linux.xml**, and the boot file is **[u-boot-hi3516dv300.bin](https://gitee.com/openharmony/device_board_hisilicon/tree/master/hispark_taurus/uboot/out/boot)**.
You need to prepare the **L1_3516_linux.xml** file on your own by applying the template below:
...
...
@@ -53,8 +53,8 @@ The following exemplifies how to burn an image to Hi3516DV300 using HiTool. You
For the Hi3516 development board, the files required for burning of the mini system are as follows:
- L1_LiteOS: **OHOS_Image.bin**, **rootfs_vfat.img**, and **userfs_vfat.img**
- 1_Linux: **uImage_hi3516dv300_smp**, **rootfs_ext4.img**, **userfs_ext4.img**, and **userdata_ext4.img**
- Small system with the LiteOS kernel: **OHOS_Image.bin**, **rootfs_vfat.img**, and **userfs_vfat.img**
- Small system with the Linux kernel: **uImage_hi3516dv300_smp**, **rootfs_ext4.img**, **userfs_ext4.img**, and **userdata_ext4.img**
2. Burn the image files using HiTool.
1. Open HiTool.
...
...
@@ -77,7 +77,7 @@ The following exemplifies how to burn an image to Hi3516DV300 using HiTool. You
If **hisilicon \#** is displayed on the terminal tool page, the serial port of the development board is connected.
3. Copy the following startup parameters in the serial port terminal tool and press **Enter** to complete the setup.
- Startup parameters corresponding to L1_LiteOS:
- Startup parameters corresponding to the small system with the LiteOS kernel: