diff --git a/en/device-dev/device-dev-guide.md b/en/device-dev/device-dev-guide.md index 5bf3cede07eb781eb67807ab026423b786385033..95876cb7eca9332335c94647d35453322724ce1e 100644 --- a/en/device-dev/device-dev-guide.md +++ b/en/device-dev/device-dev-guide.md @@ -40,7 +40,7 @@ In addition, OpenHarmony provides a series of optional system components that ca | Basic capabilities | Using basic capabilities of
 OpenHarmony | - [Kernel for Mini Systems](kernel/kernel-mini-overview.md)
- [Kernel for Small Systems](kernel/kernel-small-overview.md)
- [Drivers](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-mini-lite.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md) | | Advanced development | Developing smart devices based
 on system capabilities | - [WLAN-connected Products](guide/device-wlan-led-control.md)
- [Cameras Without a Screen](guide/device-iotcamera-control-overview.md)
- [Cameras with a Screen](guide/device-camera-control-overview.md) | | Porting and adaptation | - Porting and adapting the 
OpenHarmony to an SoC
- Porting and adapting the
 OpenHarmony to a
 third-party library | - [Mini System SoC Porting Guide](porting/oem_transplant_chip_prepare_knows.md)
- [Small System SoC Porting Guide](porting/porting-smallchip-prepare-needs.md)
- [Third-Party Library Porting Guide for Mini and Small Systems](porting/porting-thirdparty-overview.md) | -| Contributing components | Contributing components
 to OpenHarmony | - [HPM Part Overview](bundles/hpm-part-about.md)
- [HPM Part Development](bundles/hpm-part-development.md)
- [HPM Part Reference](bundles/hpm-part-reference.md) | +| Contributing components | Contributing components
 to OpenHarmony | - [HPM Part Overview](hpm-part/hpm-part-about.md)
- [HPM Part Development](hpm-part/hpm-part-development.md)
- [HPM Part Reference](hpm-part/hpm-part-reference.md) | | Reference | Referring to development specifications | [FAQs](faqs/faqs-overview.md) | @@ -54,6 +54,6 @@ In addition, OpenHarmony provides a series of optional system components that ca | Basic capabilities | Using basic capabilities of OpenHarmony | - [Kernel for Standard Systems](kernel/kernel-standard-overview.md)
- [Drivers](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-standard-large.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md) | | Advanced development | Developing smart devices
 based on system capabilities | - [Development Guidelines on Clock Apps](guide/device-clock-guide.md)
- [Development Example for Platform Drivers](guide/device-driver-demo.md)
- [Development Example for Peripheral Drivers](guide/device-outerdriver-demo.md) | | Porting and adaptation | Porting and adapting the
 OpenHarmony to a third-party library | - [Standard System Porting Guide](porting/standard-system-porting-guide.md)
- [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting/porting-linux-kernel.md) | -| Contributing components | Contributing components
 to OpenHarmony | - [HPM Part Overview](bundles/hpm-part-about.md)
- [HPM Part Development](bundles/hpm-part-development.md)
- [HPM Part Reference](bundles/hpm-part-reference.md) | +| Contributing components | Contributing components
 to OpenHarmony | - [HPM Part Overview](hpm-part/hpm-part-about.md)
- [HPM Part Development](hpm-part/hpm-part-development.md)
- [HPM Part Reference](hpm-part/hpm-part-reference.md) | | Reference | Referring to development specifications | [FAQs](faqs/faqs-overview.md) diff --git a/en/device-dev/driver/Readme-EN.md b/en/device-dev/driver/Readme-EN.md index 19d359bc3a8282d77731b3f80d6d33f17f0f5667..5ca9c29d50b6d22048cf73195e43adb9ef3c0406 100644 --- a/en/device-dev/driver/Readme-EN.md +++ b/en/device-dev/driver/Readme-EN.md @@ -9,6 +9,7 @@ - [HDF Development Example](driver-hdf-sample.md) - [Platform Driver Development](driver-develop.md) - [ADC](driver-platform-adc-develop.md) + - [DAC](driver-platform-dac-develop.md) - [GPIO](driver-platform-gpio-develop.md) - [HDMI](driver-platform-hdmi-develop.md) - [I2C](driver-platform-i2c-develop.md) @@ -26,12 +27,14 @@ - [Watchdog](driver-platform-watchdog-develop.md) - [Platform Driver Usage](driver-platform.md) - [ADC](driver-platform-adc-des.md) + - [DAC](driver-platform-dac-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) + - [Pin](driver-platform-pin-des.md) - [PWM](driver-platform-pwm-des.md) - [Regulator](driver-platform-regulator-des.md) - [RTC](driver-platform-rtc-des.md) @@ -46,4 +49,6 @@ - [WLAN](driver-peripherals-external-des.md) - [Audio](driver-peripherals-audio-des.md) - [USB](driver-peripherals-usb-des.md) - - [Camera](driver-peripherals-camera-des.md) \ No newline at end of file + - [Camera](driver-peripherals-camera-des.md) + - [Vibrator](driver-peripherals-vibrator-des.md) + - [Light](driver-peripherals-light-des.md) \ No newline at end of file diff --git a/en/device-dev/driver/driver-develop.md b/en/device-dev/driver/driver-develop.md index e3effaeb8ea3bdfc1dd4276c188de0127ad20a83..b35b64a64ffb11c51d1ce56d98942de8d032b5a3 100644 --- a/en/device-dev/driver/driver-develop.md +++ b/en/device-dev/driver/driver-develop.md @@ -2,6 +2,8 @@ - **[ADC](driver-platform-adc-develop.md)** +- **[DAC](driver-platform-dac-develop.md)** + - **[GPIO](driver-platform-gpio-develop.md)** - **[HDMI](driver-platform-hdmi-develop.md)** diff --git a/en/device-dev/driver/driver-hdf-development.md b/en/device-dev/driver/driver-hdf-development.md index 7a8de47681cdd12fad3054fea8305b768fdd13e9..192e813d41a4733dab2f666fe08e48dc86eca748 100644 --- a/en/device-dev/driver/driver-hdf-development.md +++ b/en/device-dev/driver/driver-hdf-development.md @@ -1,227 +1,249 @@ -# Driver Development - -## Driver Model - -The HDF is designed based on the component-based driver model. This model allows refined driver management and normalizes driver development and deployment. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. [Figure 1](#fig3580184214210) shows the HDF driver model. - -**Figure 1** HDF driver model -![](figures/hdf-driver-model.png "hdf-driver-model") - -## How to Develop - -Driver development based on the HDF involves driver implementation and driver configuration. The development procedure is as follows: - -1. Implement a driver. - - To implement a driver, compile driver service code and register a driver entry. - - - Driver service code - - ``` - #include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver. - #include "hdf_log.h" // Header file that describes the log APIs provided by the HDF. - - #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used. - - // The driver service interface must be bound to the HDF for you to use the service capability. - int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject) - { - HDF_LOGD("Sample driver bind success"); - return 0; - } - - // Initialize the driver service. - int32_t HdfSampleDriverInit(struct HdfDeviceObject *deviceObject) - { - HDF_LOGD("Sample driver Init success"); - return 0; - } - - // Release the driver resources. - void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject) - { - HDF_LOGD("Sample driver release success"); - return; - } - ``` - - - Registering the driver entry with the HDF - - ``` - // Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). - struct HdfDriverEntry g_sampleDriverEntry = { - .moduleVersion = 1, - .moduleName = "sample_driver", - .Bind = HdfSampleDriverBind, - .Init = HdfSampleDriverInit, - .Release = HdfSampleDriverRelease, - }; - - // Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit. - HDF_INIT(g_sampleDriverEntry); - ``` +# Driver Development + + +## Driver Model + +The Hardware Driver Foundation (HDF) is designed based on the component-based driver model. This model allows refined driver management and standardize driver development and deployment. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. The figure below shows the HDF driver model. + + **Figure 1** HDF driver model + + ![](figures/hdf-driver-model.png) + + +## How to Development + +The HDF-based driver development involves driver implementation and driver configuration. The development procedure is as follows: + +1. Implement a driver. + To implement a driver, compile driver service code and register a driver entry. + + - Driver service code + + ``` + #include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver. + #include "hdf_log.h" // Header file that describes the log APIs provided by the HDF. + + #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used. + + // Service capabilities provided by the driver. Bind the service APIs to the HDF. + int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject) + { + HDF_LOGD("Sample driver bind success"); + return 0; + } + + // Initialize the driver service. + int32_t HdfSampleDriverInit(struct HdfDeviceObject *deviceObject) + { + HDF_LOGD("Sample driver Init success"); + return 0; + } + + // Release the driver resources. + void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject) + { + HDF_LOGD("Sample driver release success"); + return; + } + ``` + - Registering the driver entry with the HDF + + ``` + // Define a driver entry object. It must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). + struct HdfDriverEntry g_sampleDriverEntry = { + .moduleVersion = 1, + .moduleName = "sample_driver", + .Bind = HdfSampleDriverBind, + .Init = HdfSampleDriverInit, + .Release = HdfSampleDriverRelease, + }; + + // Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind() function first and then the Init() function. If the Init() function fails to be called, the HDF will call Release() to release the driver resources and exit the driver model. + HDF_INIT(g_sampleDriverEntry); + ``` 2. Build the driver. - - LiteOS - - Modify **makefile** and **BUILD.gn**: - - * makefile: - - Use the **makefile** template provided by the HDF to compile the driver code. - - ``` - include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk # Import the content predefined by the HDF. This operation is mandatory. - MODULE_NAME := # File to be generated. - LOCAL_INCLUDE: = # Header file directory of the driver. - LOCAL_SRCS : = # Source code file of the driver. - LOCAL_CFLAGS : = # Custom compilation options. - include $(HDF_DRIVER) # Import the makefile template to complete the compilation. - ``` - - Add the path of the generated file to **hdf_lite.mk** in the **drivers/adapter/khdf/liteos** directory to link the file to the kernel image. The following is an example: - - ``` - LITEOS_BASELIB += -lxxx # Static library generated by the link. - LIB_SUBDIRS += # Directory in which the driver code makefile is located. - ``` - - * BUILD.gn: - - Add **BUILD.gn**. The content of **BUILD.gn** is as follows: - - ``` - import("//build/lite/config/component/lite_component.gni") - import("//drivers/adapter/khdf/liteos/hdf.gni") - module_switch = defined(LOSCFG_DRIVERS_HDF_xxx) - module_name = "xxx" - hdf_driver(module_name) { - sources = [ + Modify **makefile** and **BUILD.gn**. + + - makefile: + Use the **makefile** template provided by the HDF to compile the driver code. + + + ``` + include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk # Import the content predefined by the HDF. This operation is mandatory. + MODULE_NAME := # File to be generated. + LOCAL_INCLUDE: = # Header file directory of the driver. + LOCAL_SRCS : = # Source code file of the driver. + LOCAL_CFLAGS : = # Custom compilation options. + include $(HDF_DRIVER) # Import the makefile template to complete the compilation. + ``` + + Add the path of the generated file to **hdf_lite.mk** in the **drivers/adapter/khdf/liteos** directory to link the file to the kernel image. The following is an example: + + + ``` + LITEOS_BASELIB += -lxxx # Static library generated by the link. + LIB_SUBDIRS += # Directory in which the driver code makefile is located. + ``` + + - **BUILD.gn**: + Add **BUILD.gn**. The content of **BUILD.gn** is as follows: + + + ``` + import("//build/lite/config/component/lite_component.gni") + import("//drivers/adapter/khdf/liteos/hdf.gni") + module_switch = defined(LOSCFG_DRIVERS_HDF_xxx) + module_name = "xxx" + hdf_driver(module_name) { + sources = [ "xxx/xxx/xxx.c", # Source code file of the driver - ] + ] public_configs = [ ":public" ] # Configuration applied to dependencies - } - config("public") {# Configuration of the dependencies - include_dirs = [ + } + config("public") {# Configuration of the dependencies + include_dirs = [ "xxx/xxx/xxx", # Directory of the dependency header file. - ] - } - ``` - - Add the directory where the **BUILD.gn** file of the driver is located to **/drivers/adapter/khdf/liteos/BUILD.gn**. - - ``` - group("liteos") { - public_deps = [ ":$module_name" ] - deps = [ - "xxx/xxx", # Directory where the BUILD.gn of the driver is located. It is a relative path to /drivers/adapter/khdf/liteos. - ] - } - ``` - + ] + } + ``` + + Add the directory where the **BUILD.gn** file of the driver is located to **/drivers/adapter/khdf/liteos/BUILD.gn**. + + + ``` + group("liteos") { + public_deps = [ ":$module_name" ] + deps = [ + "xxx/xxx", # Directory where the BUILD.gn of the driver is located. It is a relative path to /drivers/adapter/khdf/liteos. + ] + } + ``` - Linux - - To define the driver control macro, add the **Kconfig** file to the driver directory **xxx** and add the path of the **Kconfig** file to **drivers/adapter/khdf/linux/Kconfig**. - - ``` - source "drivers/hdf/khdf/xxx/Kconfig" # Kernel directory to which the HDF module is soft linked. - ``` - - Add the driver directory to **drivers/adapter/khdf/linux/Makefile**. - - ``` - obj-$(CONFIG_DRIVERS_HDF) += xxx/ - ``` - - Add a **Makefile** to the driver directory **xxx** and add code compiling rules of the driver to the **Makefile** file. - - ``` - obj-y += xxx.o - ``` - -3. Configure the driver. - - HDF Configuration Source (HCS) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](driver-hdf-manage.md). - - The driver configuration consists of the driver device description defined by the HDF and private driver configuration information. - - - (Mandatory) Driver device description - - The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device_info.hcs** defined by the HDF for drivers developed based on the HDF.The following is an example: - - ``` - root { - device_info { - match_attr = "hdf_manager"; - template host { // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted. - hostName = ""; - priority = 100; - template device { - template deviceNode { - policy = 0; - priority = 100; - preload = 0; - permission = 0664; - moduleName = ""; - serviceName = ""; - deviceMatchAttr = ""; - } - } - } - sample_host :: host{ - hostName = "host0"; // Host name. The host node is used to store a certain type of drivers. - priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random. - device_sample :: device { // Device node of sample - device0 :: deviceNode { // DeviceNode of the sample driver - policy = 1; // Driver service release policy. For details, see section Driver Service Management. - priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random. - preload = 0; // On-demand loading of the driver. For details, see "NOTE" at the end of this section. - permission = 0664; // Permission for the driver to create device nodes. - moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure. - serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique. - deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. - } - } - } - } - } - ``` - - - \(Optional\) Private configuration information of the driver - - If the driver has private configurations, you can add a driver configuration file to fill in the default configuration information of the driver. When loading the driver, the HDF obtains the information and saves it in the **property** of **HdfDeviceObject**, and transfers it to the driver using **Bind** and **Init** \(see [1](#li35182436435)\). The following is an example of the driver configuration information: - - ``` - root { - SampleDriverConfig { - sample_version = 1; - sample_bus = "I2C_0"; - match_attr = "sample_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs. - } - } - ``` - - After the configuration information is defined, you need to add the configuration file to the board-level configuration entry file **hdf.hcs**. \(You can use the DevEco to perform on-click configuration. For details, see the description about the driver development suite.\) The following is an example: - - ``` - #include "device_info/device_info.hcs" - #include "sample/sample_config.hcs" - ``` - - - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->On-demand loading and sequential loading are supported. The detailed usage is as follows: ->- On-demand loading -> ``` -> typedef enum { -> DEVICE_PRELOAD_ENABLE = 0, -> DEVICE_PRELOAD_ENABLE_STEP2, -> DEVICE_PRELOAD_DISABLE, -> DEVICE_PRELOAD_INVALID -> } DevicePreload; -> ``` -> If the **preload** field in the configuration file is set to **0** (DEVICE\_PRELOAD\_ENABLE), the driver is loaded by default during the system boot process. If **preload** is set to **1** (DEVICE\_PRELOAD\_ENABLE\_STEP2), the driver is loaded after a quick start is complete if the system supports quick start. If the system does not support quick start, the value **1** has the same meaning as DEVICE\_PRELOAD\_ENABLE. If **preload** is set to **2** (DEVICE\_PRELOAD\_DISABLE), the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service (for details, see [Driver Message Mechanism Management](driver-hdf-message-management.md)), the HDF attempts to dynamically load the driver if the driver service does not exist. ->- Sequential loading \(drivers must be loaded by default\) -> In the configuration file, the **priority** field \(the value is an integer ranging from 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority. + To define the driver control macro, add the **Kconfig** file to the driver directory **xxx** and add the path of the **Kconfig** file to **drivers/adapter/khdf/linux/Kconfig**. + + + ``` + source "drivers/hdf/khdf/xxx/Kconfig" # Kernel directory to which the HDF module is soft linked. + ``` + + Add the driver directory to **drivers/adapter/khdf/linux/Makefile**. + + + ``` + obj-$(CONFIG_DRIVERS_HDF) += xxx/ + ``` + + Add a **Makefile** to the driver directory **xxx** and add code compiling rules of the driver to the **Makefile** file. + + + ``` + obj-y += xxx.o + ``` + +3. Configure the driver. + HDF Configuration Source (HCS) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](../driver/driver-hdf-manage.md). + + The driver configuration consists of the driver device description defined by the HDF and the private driver configuration. + + - (Mandatory) Driver device description + The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device_info.hcs** defined by the HDF for drivers developed based on the HDF. The following is an example: + + + ``` + root { + device_info { + match_attr = "hdf_manager"; + template host { // Host template. If the node (for example, sample_host) uses the default values in the template, the values of the node fields can be omitted. + hostName = ""; + priority = 100; + uid = ""; // User ID (UID) of the user-mode process. By default, it is left empty, that is, set to the value defined for hostName, which indicates a common user. + gid = ""; // Group ID (GID) of the user-mode process. By default, it is left empty, that is, set to the value defined for hostName, which indicates a common user group. + caps = [""]]; // Linux capabilities of the user-mode process. It is left empty by default. Set this parameter based on service requirements. + template device { + template deviceNode { + policy = 0; + priority = 100; + preload = 0; + permission = 0664; + moduleName = ""; + serviceName = ""; + deviceMatchAttr = ""; + } + } + } + sample_host :: host{ + hostName = "host0"; // Host name. The host node is used to store a type of drivers. + priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random. + caps = ["DAC_OVERRIDE", "DAC_READ_SEARCH"]; // Linux capabilities of the user-mode process. + device_sample :: device { // Sample device node. + device0 :: deviceNode { // DeviceNode of the sample driver. + policy = 1; // Driver service release policy. For details, see the Driver Service Management. + priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random. + preload = 0; // On-demand loading of the driver. For details, see "NOTE" at the end of this section. + permission = 0664; // Permission for the driver to create a device node. + moduleName = "sample_driver"; // Driver name. The value of this field must be the same as that of moduleName in the HdfDriverEntry structure. + serviceName = "sample_service"; // Name of the service published by the driver. The service name must be unique. + deviceMatchAttr = "sample_config"; // Keyword for matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. + } + } + } + } + } + ``` + > ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**
+ + - **uid**, **gid**, and **caps** are startup configuration for user-mode drivers and do not need to be configured for kernel-mode drivers. + - According to the principle of least privilege for processes, **uid** and **gid** do not need to be configured for service modules. In the preceding example, **uid** and **gid** are left empty (granted with the common user rights) for sample_host. + - If you need to set **uid** and **gid** to **system** or **root** due to service requirements, contact security experts for review. + - The process UID is configured in **base/startup/init_lite/services/etc/passwd**, and the process GID is configured in **base/startup/init_lite/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init_lite/wikis). + - If CAP_DAC_OVERRIDE needs to be configured for a service module, set **caps = ["DAC_OVERRIDE"]** instead of **caps = ["CAP_DAC_OVERRIDE"]**. + + + + - (Optional) Private configuration information of the driver + If the driver has private configuration, you can add a driver configuration file to set default driver configuration. When loading the driver, the HDF obtains and saves the corresponding configuration in **property** of **HdfDeviceObject**, and passes the configuration to the driver through **Bind()** and **Init()** (see step 1). The following is an example of the driver configuration: + + + ``` + root { + SampleDriverConfig { + sample_version = 1; + sample_bus = "I2C_0"; + match_attr = "sample_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs. + } + } + ``` + + After the configuration, add the configuration file to the board-level configuration entry file **hdf.hcs**. (You can use DevEco to perform on-click configuration. For details, see the description about the driver development suite.) The following is an example: + + + ``` + #include "device_info/device_info.hcs" + #include "sample/sample_config.hcs" + ``` + + +> ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**
+> Drivers can be loaded on demand or in sequence. +> +> - On-demand loading +> +> ``` +> typedef enum { +> DEVICE_PRELOAD_ENABLE = 0, +> DEVICE_PRELOAD_ENABLE_STEP2, +> DEVICE_PRELOAD_DISABLE, +> DEVICE_PRELOAD_INVALID +> } DevicePreload; +> ``` +> +> If **preload** in the configuration file is set to **0** (**DEVICE_PRELOAD_ENABLE**), the driver is loaded by default during the system boot process. +> +> If **preload** is set to **1** (**DEVICE\_PRELOAD\_ENABLE\_STEP2**), the driver is loaded after a quick start is complete if the system supports quick start. If the system does not support quick start, the value **1** has the same meaning as **DEVICE\_PRELOAD\_ENABLE**. +> +> If **preload** is set to **2** (**DEVICE\_PRELOAD\_DISABLE**), the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service (for details, see [Driver Message Mechanism Management](driver-hdf-message-management.md)), the HDF attempts to dynamically load the driver if the driver service does not exist. +> +> - Sequential loading (drivers must be loaded by default) +> In the configuration file, the **priority** field \(value range: 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority. diff --git a/en/device-dev/driver/driver-peripherals-audio-des.md b/en/device-dev/driver/driver-peripherals-audio-des.md index 09e81e82172012608dee4e3711f77345db5be608..6f66786fe60ddf8f603022b3bb9e49054605df4f 100644 --- a/en/device-dev/driver/driver-peripherals-audio-des.md +++ b/en/device-dev/driver/driver-peripherals-audio-des.md @@ -1,6 +1,7 @@ # Audio -# Audio Driver Overview + +## Audio Driver Overview A multimedia system is an indispensable part in Internet of Things (IoT) devices. Audio is an important module of the multimedia system, and building an audio driver model is particularly important in device development. @@ -8,9 +9,10 @@ This document describes the audio driver architecture and functional modules and -# Audio Driver Architecture +## Audio Driver Architecture The audio driver architecture is implemented based on the [HDF](https://device.harmonyos.com/en/docs/documentation/guide/driver-hdf-overview-0000001051715456). The audio driver architecture is as follows: + ![](figures/Audio_architecture.png) The driver architecture consists of the following: @@ -21,14 +23,14 @@ The driver architecture consists of the following: - Audio Stream Dispatch: dispatches the data from the Audio Interface Lib to the driver layer. - Card Manager: manages multiple audio adapters. Each audio adapter consists of the digital audio interface (DAI), platform, codec, accessory, DSP, and Smart Audio Power Manager (SAPM) modules. -- Platform Drivers: implement driver adaptation. +- Platform Drivers: driver adaptation layer. - SAPM: optimizes the power consumption policy of the ADM. -# Audio Driver Development +## Audio Driver Development The following uses the Hi3516D V300 as an example to describe how to develop drivers based on the audio driver architecture. -## Audio ADM Architecture +### Audio ADM Architecture The audio driver provides the **hdf_audio_render**, **hdf_audio_capture**, and **hdf_audio_control** services for the HDI layer. The driver service nodes in the **dev** directory of the development board are as follows: ```c @@ -43,10 +45,10 @@ crw-rw---- 1 system system 248, 7 1970-01-01 00:00 hdf_audio_render // Aud The audio adapters have the following driver services: hdf\_audio\_codec\_dev0 -- **dma\_service\_0**: direct memory access (DMA) service -- **dai_service**: CPU DAI service +- **dma\_service\_0**: direct memory access (DMA) service +- **dai_service**: CPU DAI service - **codec\_service\_0**: codec service (built-in codec) -- **dsp\_service\_0**: DSP service (optional) +- **dsp\_service\_0**: DSP service (optional) hdf\_audio\_codec\_dev1 - **dma\_service\_0**: DMA service @@ -54,7 +56,7 @@ hdf\_audio\_codec\_dev1 - **codec\_service\_1**: accessory service (SmartPA) - **dsp\_service\_0**: DSP service (optional) -### Startup Process +#### Startup Process ![](figures/ADM_startup_flowchart.png) @@ -68,8 +70,10 @@ hdf\_audio\_codec\_dev1 5. The initialized audio devices are added to the cardManager linked list. -### Playback Process +#### Playback Process + ![=](figures/ADM_playback_flowchart.png) + 1. The Audio Interface Lib sends the **Render Open** instruction to the Audio Stream Dispatch service. The Audio Stream Dispatch service calls the API of each module to deliver the instruction. 2. The Audio Interface Lib sends a path select instruction to the Control Dispatch service. The Control Dispatch service calls the DAI API to set the path. @@ -84,52 +88,52 @@ hdf\_audio\_codec\_dev1 7. The Audio Interface Lib sends the **Render Close** instruction to the Audio Stream Dispatch service. The Audio Stream Dispatch service calls the **Platform AudioRenderClose** API to release resources. -### Control Process +#### Control Process ![](figures/ADM_control_flowchart.png) 1. When the volume needs to be adjusted, the Audio Interface Lib sends an instruction for obtaining the volume range to the Control Dispatch service. The Control Dispatch service parses the instruction and calls **get()** of the codec module to obtain the volume range. 2. The Audio Interface Lib sends an instruction for setting the volume to the Control Dispatch service. The Control Dispatch service parses the instruction and calls **Set()** of the codec module to set the volume. -## Audio Driver Development Procedure +### Audio Driver Development Procedure -### Development on an Adapted Platform +#### Development on an Adapted Platform The following figure shows the process for developing the codec or accessory (SmartPA) driver on a chip platform (Hi3516D V300) to which the ADM has adapted. -![](figures/development_flowchart_1.png) +![](figures/audio_development_flowchart_1.png) -1. Add register information to the private HDF configuration source (HCS) of the codec or SmartPA based on the chip description. +- Add register information to the private HDF configuration source (HCS) of the codec or SmartPA based on the chip description. - If the workflow of the newly added codec or SmartPA is the same as that of the existing codec or SmartPA, you do not need to implement the operation function set or configure the compilation file for the newly added codec or SmartPA. +- If the workflow of the newly added codec or SmartPA is the same as that of the existing codec or SmartPA, you do not need to implement the operation function set or configure the compilation file for the newly added codec or SmartPA. -2. Perform build, debugging, and testing. +- Perform build, debugging, and testing. -### Development on a New Platform +#### Development on a New Platform The following figure shows the driver development process if the ADM has not adapted to the platform. -![](figures/development_flowchart_2.png) +![](figures/audio_development_flowchart_2.png) The codec (optional), DAI, DMA, DSP (optional), and SmartPA (optional) modules of the audio adapter need to be adapted to the new platform. -1. Add register information of each module driver to the private configuration file of the respective module according to the chip description. +- Add register information of each module driver to the private configuration file of the respective module according to the chip description. -2. Implement the operation function set of each module. +- Implement the operation function set of each module. -3. Modify the compilation file of the audio module. +- Modify the compilation file of the audio module. -4. Perform build, debugging, and testing. +- Perform build, debugging, and testing. -# Audio Driver Development Examples +## Audio Driver Development Examples Code path: **drivers/peripheral/audio** The following uses Hi3516D V300 as an example to describe how to develop the audio codec driver, accessory driver, DAI driver, and platform driver. -## Codec Driver Development Example +### Codec Driver Development Example Code path: **drivers/peripheral/audio/chipsets/hi3516dv300/codec** The major steps for developing the codec driver are as follows: @@ -138,7 +142,7 @@ The major steps for developing the codec driver are as follows: 3. Register and bind the codec instance to the HDF. 4. Configure the HCS and makefile. -### Filling in Codec Data Structures +#### Filling in Codec Data Structures Fill in the following data structures for the codec module: @@ -166,9 +170,9 @@ struct DaiData g_codecDaiData = { }; ``` -### Initializing the Codec Device and Codec DAI Device +#### Initializing codecDevice and codecDai -**CODECDeviceInit** sets audio input/audio output (AIAO), initializes registers, inserts **g_audioControls** into the controller linked list, initializes the power management, and selects a path. +**CODECDeviceInit** sets audio input/audio output (AIAO), initializes registers, inserts **g_audioControls** into the control linked list, initializes the power management, and selects a path. ```c int32_t CodecDeviceInit(struct AudioCard *audioCard, struct CodecDevice *codec) @@ -183,7 +187,7 @@ int32_t CodecDeviceInit(struct AudioCard *audioCard, struct CodecDevice *codec) /* Initialize the codec registers of the Hi3516 platform. */ CodecRegDefaultInit(codec->devData->regCfgGroup); ... - /* Insert g_audioControls of the Hi3516 platform to the controller linked list. */ + /* Insert g_audioControls of the Hi3516 platform to the controller linked list.*/ AudioAddControls(audioCard, codec->devData->controls, codec->devData->numControls); ... /* Load the codec of the Hi3516 platform to the SAPM. */ @@ -214,7 +218,7 @@ int32_t CodecDaiDeviceInit(struct AudioCard *card, const struct DaiDevice *devic } ``` -### Implementing the Codec Operation Function Set +#### Implementing the Codec Operation Function Set The codec module is encapsulated with the **read()** and **write()** functions of the read and write registers at the operating system abstraction layer (OSAL). @@ -267,7 +271,7 @@ int32_t CodecDaiHwParams(const struct AudioCard *card, const struct AudioPcmHwPa } ``` -### Registering and Binding Codec to HDF +#### Registering and Binding Codec to HDF This process depends on the driver implementation mode of the HDF. For details, see [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf.md). @@ -299,7 +303,7 @@ static int32_t CodecDriverBind(struct HdfDeviceObject *device) } ``` -**CodecDriverInit** obtains the codec service name and private register configuration, and inserts them into the linked list by using **AudioRegisterCodec**. +**CodecDriverInit** obtains the **codecService** name and private register configuration, and inserts them into the linked list by using **AudioRegisterCodec**. ```c static int32_t CodecDriverInit(struct HdfDeviceObject *device) @@ -325,7 +329,7 @@ static void CodecDriverRelease(struct HdfDeviceObject *device) } ``` -### Configuring HCS +#### Configuring HCS Configure the driver node, loading sequence, and service name in the .hcs file. For details about the HCS syntax, see [Driver Configuration Management](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf-manage.md) in the HDF. @@ -339,7 +343,7 @@ Path of the small-system configuration file: **Configuring Codec Device Information in device_info.hcs** -Add codec node configuration. Modify **moduleName** in the configuration file. The value must be the same as **moduleName** in the **HdfDriverEntry** structure. Generally, the value should present the hardware platform, for example, **moduleName = "CODEC_HI3516"**. +Add codec node configuration. Modify **moduleName** in the configuration file. The value must be the same as **moduleName** in the **HdfDriverEntry** structure. Generally, the value should present the hardware platform. For example, moduleName = "CODEC_HI3516". The code snippet is as follows: @@ -366,7 +370,7 @@ The code snippet is as follows: ```c root { - platfrom { + platform { ... controller_0x120c1001 :: card_controller { // Set the private data attribute name, which must be the same as deviceMatchAttr in device_info.hcs. @@ -425,11 +429,11 @@ iface 6: AIAO device ``` -**ctrlParamsSeqConfig**: control functionality register configuration. The sequence of the configuration items is the same as that in **controlsConfig**, indicating the register configuration corresponding to a functionality. +**ctrlParamsSeqConfig**: control function register configuration. The **item** sequence corresponds to the **item** sequence in **controlsConfig**, indicating the register configuration corresponding to a function. ```c root { - platfrom { + platform { template codec_controller { match_attr = ""; serviceName = ""; @@ -496,7 +500,7 @@ iface 0x20, 0x20, 16, 16, 0x0, 0xF, 0x1F, 0, 0, //"Mic Left Gain" 0x20, 0x20, 24, 24, 0x0, 0xF, 0x1F, 0, 0, // "Mic Right Gain" 0x2000, 0x2000, 16, 16, 0x0, 0x7, 0x7, 0, 0, // "Render Channel Mode" - 0x1000, 0x1000, 16, 16, 0x0, 0x7, 0x7, 0, 0 // "Capture Channel Mode" + 0x1000, 0x1000, 16, 16, 0x0, 0x7, 0x7, 0, 0 //"Capture Channel Mode" ]; /* After the upper layer delivers parameters, write audio-related data to registers. @@ -607,7 +611,7 @@ int32_t CodecDeviceInit(struct AudioCard *audioCard, struct CodecDevice *codec) -## Accessory Driver Development Example +### Accessory Driver Development Example Code path: **drivers/peripheral/audio/chipsets/tfa9879/accessory** SmartPA is a type of accessory driver. The SmartPA development procedure is similar to the codec development procedure. @@ -616,13 +620,13 @@ SmartPA is a type of accessory driver. The SmartPA development procedure is simi 3. Register and bind the accessory instance to the HDF. 4. Configure the HCS and makefile. -### Filling in Accessory Data Structures +#### Filling in Accessory Data Structures Fill in the following data structures for the accessory module: - **g_tfa9879Data**: operation function set of the accessory device. It contains the configuration in the .hcs file, and defines and maps the functions for initializing the accessory device and reading and writing registers. -- **g_tfa9879DaiDeviceOps**: data set of the accessory device DAI. It defines and maps the operation set of the accessory device DAI. +- **g_tfa9879DaiDeviceOps**: data set of the DAI of the accessory device. It defines and maps the operation set of the accessory device DAI. - **g_tfa9879DaiData**: data set of the DAI of the accessory device. It defines and maps the driver name, initialization, and operation set of the data access interface of the accessory device. @@ -645,7 +649,7 @@ struct DaiData g_tfa9879DaiData = { }; ``` -### Initializing the Accessory Device and Accessory DAI Device +#### Initializing accessoryDevice and accessoryDai As the entry function for device initialization, **Tfa9879DeviceInit** sets the address of the SmartPA I2C device, obtains configuration data, initializes (including resets) the device registers, and adds the control functionality to the controller linked list. The current demo also includes the initialization of the registers related to the Hi3516D V300 device, such as initialization of GPIO pins. @@ -696,7 +700,7 @@ int32_t AccessoryI2cReadWrite(struct AudioAddrConfig *regAttr, uint16_t rwFlag) } ``` -### Implementing the Accessory Operation Function Set +#### Implementing the Accessory Operation Function Set The callbacks **AccessoryDeviceRegRead** and **AccessoryDeviceRegWrite** invoke **AccessoryI2cReadWrite** to read and write the control register values. @@ -759,7 +763,7 @@ int32_t Tfa9879DaiHwParams(const struct AudioCard *card, const struct AudioPcmHw (void)card; ... // Set the sampling rate. - ret = AcessoryDeviceFrequencyParse(param->rate, &frequency); + ret = AccessoryDeviceFrequencyParse(param->rate, &frequency); ... // Set the bit width. ret = Tfa9879FormatParse(param->format, &bitWidth); @@ -773,7 +777,7 @@ int32_t Tfa9879DaiHwParams(const struct AudioCard *card, const struct AudioPcmHw } ``` -### Registering and Binding Accessory to HDF +#### Registering and Binding Accessory to HDF This process depends on the driver implementation mode of the HDF. For details, see [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf.md). @@ -814,13 +818,13 @@ struct HdfDriverEntry g_tfa9879DriverEntry = { HDF_INIT(g_tfa9879DriverEntry); ``` -### Configuring HCS +#### Configuring HCS For details about the configuration process, see [Configuring HCS](#section4115) in **Codec Driver Development Example**. -## Platform Driver Development Example +### Platform Driver Development Example Code path: **drivers/peripheral/audio/chipsets/hi3516dv300/soc** In audio driver development, the Platform module is configured to adapt to the DMA driver. The major steps for developing the platform driver are as follows: @@ -829,7 +833,7 @@ In audio driver development, the Platform module is configured to adapt to the D 3. Register and bind the platform instance to the HDF. 4. Configure the HCS and makefile. -### Filling in Platform Data Structures +#### Filling in Platform Data Structures Fill in the following structures for the platform module: @@ -857,7 +861,7 @@ struct PlatformData g_platformData = { }; ``` -### Initializing the DMA Device +#### Initializing dmaDevice **AudioDmaDeviceInit** initializes the DMA device, including setting the Hi3516 AIAO module. @@ -877,7 +881,7 @@ int32_t AudioDmaDeviceInit(const struct AudioCard *card, const struct PlatformDe } ``` -### Implementing the DMA Operation Function Set +#### Implementing the DMA Operation Function Set The DMA device operation function set includes the encapsulation of DMA common APIs. If the common APIs cannot meet development requirements, you can implement new DMA callbacks. @@ -894,7 +898,7 @@ int32_t Hi3516DmaResume(const struct PlatformData *data); int32_t Hi3516DmaPointer(struct PlatformData *data, uint32_t *pointer); ``` -### Registering and Binding Platform to HDF +#### Registering and Binding Platform to HDF This process depends on the driver implementation mode of the HDF. For details, see [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf.md). @@ -938,13 +942,13 @@ struct HdfDriverEntry g_platformDriverEntry = { HDF_INIT(g_platformDriverEntry); ``` -### Configuring HCS +#### Configuring HCS For details about the configuration process, see [Configuring HCS](#section4115) in **Codec Driver Development Example**. -## DAI Driver Development Example +### DAI Driver Development Example Code path: **drivers/peripheral/audio/chipsets/hi3516dv300/soc** The major steps for developing the DAI driver are as follows: @@ -953,7 +957,7 @@ The major steps for developing the DAI driver are as follows: 3. Register and bind the DAI instance to the HDF. 4. Configure the HCS and makefile. -### Filling in DAI Data Structures +#### Filling in DAI Data Structures Fill in the following structures for the DAI module: @@ -976,7 +980,7 @@ struct DaiData g_daiData = { }; ``` -### Initializing the DAI Device +#### Initializing daiDevice **DaiDeviceInit** initializes DAI configuration and adds the information to the controller linked list. @@ -999,7 +1003,7 @@ int32_t DaiDeviceInit(struct AudioCard *audioCard, const struct DaiDevice *dai) } ``` -### Implementing the DAI Operation Function Set +#### Implementing the DAI Operation Function Set **AudioDeviceReadReg** and **AudioDeviceWriteReg** are not used on the Hi3516 and are reserved. @@ -1058,7 +1062,7 @@ int32_t DaiStartup(const struct AudioCard *card, const struct DaiDevice *device) } ``` -### Registering and Binding DAI to HDF +#### Registering and Binding DAI to HDF This process depends on the driver implementation mode of the HDF. For details, see [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf.md). @@ -1114,13 +1118,13 @@ struct HdfDriverEntry g_daiDriverEntry = { HDF_INIT(g_daiDriverEntry); ``` -### Configuring HCS +#### Configuring HCS For details about the configuration process, see [Configuring HCS](#section4115) in **Codec Driver Development Example**. -## Adding Compilation Configuration to Makefile +### Adding Compilation Configuration to Makefile Add the newly added files to the **Makefile** file to link them to the kernel image. @@ -1161,11 +1165,11 @@ $(KHDF_AUDIO_HI3516DV300_DIR)/soc/src/hi3516_dma_adapter.c -## Source Code Structure and Directory +### Source Code Structure and Directory The development example implements the functions in the header file of the driver interface. The following uses Hi3516 as an example to describe the directory structure. -Path of the driver implementation sample code: **drivers/peripheral/audio/chipsets** +Path of the driver implementation sample code: **drivers\peripheral\audio\chipsets\** ``` ├── hi3516dv300 @@ -1241,10 +1245,15 @@ vendor/hisilicon/hispark_taurus/ -# HAL-based Development Procedure and Example +## HAL-based Development Procedure and Example +The Hardware Abstraction Layer (HAL) provides the following functions: + +1. Provides audio HDIs for audio services to implement basic audio features on applications. +2. Provides standard interfaces for device developers to comply with the HDI adapter standards. This promises a healthy evolution of the ecosystem. + Code path: **drivers/peripheral/audio/hal** -## Development Procedure +### Development procedure ![](figures/HAL_flowchart.png) @@ -1266,7 +1275,7 @@ Code path: **drivers/peripheral/audio/hal** 3. manager->UnloadAdapter(); -## Development Example +### Development Example ```c #include @@ -1354,6 +1363,6 @@ static void *hal_main() -# Summary +## Summary -This document provides all the key adaptations involved in the driver development based on the audio driver architecture. It elaborates how to adapt the audio driver and use HDI APIs. You can easily develop your audio drivers based on the chip you use by referring to this document. +This document provides all the key adaptations involved in the audio driver development. It elaborates how to adapt the audio driver and use HDI APIs. You can conduct development based on the chip you use. After reading this document, you will be able to master the audio driver development based on the HDF framework. diff --git a/en/device-dev/driver/driver-peripherals-camera-des.md b/en/device-dev/driver/driver-peripherals-camera-des.md index cca003d566f83eaca6bb53af314ff22676de6495..51667b52f5d0f509c409ed0cba529a31ec5249d7 100644 --- a/en/device-dev/driver/driver-peripherals-camera-des.md +++ b/en/device-dev/driver/driver-peripherals-camera-des.md @@ -1,670 +1,739 @@ -# Camera +# Camera -## Overview - -The OpenHarmony camera driver model implements the camera hardware driver interface \(HDI\) and the camera pipeline model to manage camera devices. +## Overview +### Camera +The OpenHarmony camera driver model implements the camera hardware device interface (HDI) and the camera pipeline model to manage camera devices. The camera driver model consists of the following layers: -- HDI implementation layer: implements standard southbound interfaces of OpenHarmony cameras. ++ HDI implementation layer: implements standard ohos (OpenHarmony operating system) APIs for cameras. ++ Framework layer: connects to the HDI implementation layer for control instruction and stream transfer, establishes data channels, and manages camera devices. ++ Device adaptation layer: shields the differences between underlying chips and OSs for multi-platform adaptation. -- Framework layer: connects to the HDI implementation layer for control instruction and stream transfer, establishes data channels, and manages camera devices. +### Working Principles -- Adaptation layer: shields the differences between bottom-layer chips and OSs for multi-platform adaptation. +The camera module is used to initialize services and devices, set up data channels, and configure, create, deliver, and capture streams. The figure below illustrates camera driver model. +**Figure 1** HDF-based camera driver model -**Figure 1** Architecture of the camera driver model -![](figures/camera-driver-model-architecture.png "camera-driver-model-architecture") +![](figures/camera-driver-model-architecture.png) -1. The CameraDeviceHost process is created during system startup. The process enumerates underlying devices, creates a **DeviceManager** instance that manages the device tree, an object for each underlying device, and a **CameraHost** instance, and registers the **CameraHost** instance with the UHDF service. Through this service, the upper layer can obtain the CameraDeviceHost process at the bottom layer to operate the underlying devices. Note that the **DeviceManager** instance can also be created by using the configuration table. +1. When the system starts, the camera_host process is created. The process enumerates underlying devices, creates a **DeviceManager** instance that manages the device tree, an object for each underlying device, and a **CameraHost** instance, and registers the **CameraHost** instance with the UHDF service. Through the UHDF service, the camera service can obtain the underlying **CameraDeviceHost** services to operate the hardware devices. Note that the **DeviceManager** instance can also be created by using the configuration table. -2. The Camera Service obtains the **CameraHost** instance through the CameraDeviceHost service. The **CameraHost** instance can be used to obtain the bottom-layer camera capabilities, turn on the flashlight, call the **Open\(\)** interface to start the camera and create a connection, create a **DeviceManager** instance \(powering on the bottom-layer hardware modules\), and create a **CameraDevice** instance \(providing the device control interface for the upper layer\). When the **CameraDevice** instance is created, each submodule of PipelineCore is instantiated. Among the submodules, StreamPiplineCore is responsible for creating pipelines, and MetaQueueManager is responsible for reporting metadata. +2. The Camera Service obtains the **CameraHost** instance through the CameraDeviceHost service. The **CameraHost** instance can be used to obtain the bottom-layer camera capabilities, turn on the flashlight, call the **Open()** interface to start the camera and create a connection, create a **DeviceManager** instance (powering on the bottom-layer hardware modules), and create a **CameraDevice** instance (providing the device control interface for the upper layer). When the **CameraDevice** instance is created, each submodule of PipelineCore is instantiated. Among the submodules, StreamPipelineCore is responsible for creating pipelines, and MetaQueueManager is responsible for reporting metadata. -3. The Camera Service configures the stream and creates a **Stream** instance through the **CameraDevice** instance at the bottom layer. The StreamPipelineStrategy module creates the node connection mode of the corresponding stream by using the mode issued by the upper layer and querying the configuration table. The StreamPipelineBuilder module creates a node and returns the pipeline to the StreamPipelineDispatcher module through the connection. The StreamPipelineDispatcher module provides unified pipeline invoking management. +3. The Camera Service configures stream and creates a **Stream** class through the CameraDevice module. The StreamPipelineStrategy module creates the node connection mode of the corresponding stream by using the mode issued by the upper layer and querying the configuration table. The StreamPipelineBuilder module creates a node and returns the pipeline to the StreamPipelineDispatcher module through the connection. The StreamPipelineDispatcher module dispatches pipelines. -4. The Camera Service controls the stream operations through the **Stream** instance. The **AttachBufferQueue\(\)** interface is used to deliver the buffer queue requested from the display module to the bottom layer. The CameraDeviceDriverModel manages the buffer. After the **Capture\(\)** interface is called to deliver commands, the bottom layer transfers the buffer to the upper layer. The Image Signal Processor \(ISP\) node obtains a specified number of buffers from the buffer queue and delivers the buffers to the bottom-layer ISP hardware. After filling the buffers, the ISP hardware transfers the buffers to the CameraDeviceDriverModel. The CameraDeviceDriverModel fills the created pipeline with the received buffers by using a loop thread. Each node processes the pipeline data and transfers the data to the upper layer by using a callback. At the same time, the buffers are freed for reuse. +4. The Camera Service controls the stream operations through the **Stream** instance. The **AttachBufferQueue()** interface is used to deliver the buffer queue requested from the display module to the bottom layer. The CameraDeviceDriverModel manages the buffer. After the **Capture()** interface is called to deliver commands, the bottom layer transfers the buffer to the upper layer. The Image Signal Processor (ISP) node obtains a specified number of buffers from the buffer queue and delivers the buffers to the bottom-layer ISP hardware. After filling the buffers, the ISP hardware transfers the buffers to the CameraDeviceDriverModel. The CameraDeviceDriverModel fills the created pipeline with the received buffers by using a loop thread. Each node processes the pipeline data and transfers the data to the upper layer by using a callback. At the same time, the buffers are freed for reuse. -5. The Camera Service delivers the photographing command through the **Capture\(\)** interface. The **ChangeToOfflineStream\(\)** interface is used to query the position of the photographing buffer. If the ISP hardware has output an image and sent the image data to the IPP node, the common photographing streams can be converted into offline streams. Otherwise, the close process is executed. The **ChangeToOfflineStream\(\)** interface transfers **StreamInfo** to enable the offline stream to obtain the stream information of the common stream, confirms the node connection mode of the offline stream based on the configuration table, and creates the node connection of the offline stream. If the node connection has been created, the interface releases the node required by the non-offline stream through **CloseCamera\(\)**. It then waits for the buffer to return from the bottom-layer pipeline to the upper layer and then releases the pipeline resources. +5. The Camera Service delivers the photographing command through the **Capture()** interface. The **ChangeToOfflineStream()** interface is used to query the position of the photographing buffer. If the ISP hardware has output an image and sent the image data to the IPP node, the common photographing streams can be converted into offline streams. Otherwise, the close process is executed. The **ChangeToOfflineStream()** interface transfers **StreamInfo** to enable the offline stream to obtain the stream information of the common stream, confirms the node connection mode of the offline stream based on the configuration table, and creates the node connection of the offline stream. If the node connection has been created, the interface releases the node required by the non-offline stream through **CloseCamera()**. It then waits for the buffer to return from the bottom-layer pipeline to the upper layer and then releases the pipeline resources. -6. The Camera Service sends the **CaptureSetting** parameter to the CameraDeviceDriverModel through the **UpdateSettings\(\)** interface of the **CameraDevice** instance. The CameraDeviceDriverModel forwards the parameter to each node through the StreamPipelineDispatcher module. The **CaptureSetting** parameter carried in the **StartStreamingCapture\(\)** and **Capture\(\)** interfaces is forwarded to the node to which the stream belongs through the StreamPipelineDispatcher module. +6. The Camera Service sends the **CaptureSetting** parameter to the CameraDeviceDriverModel through the **UpdateSettings()** interface of the **CameraDevice** instance. The CameraDeviceDriverModel forwards the parameter to each node through the StreamPipelineDispatcher module. The **CaptureSetting** parameter carried in **StartStreamingCapture()** and **Capture()** is forwarded to the node to which the stream belongs through the StreamPipelineDispatcher module. -7. The Camera Service controls underlying metadata reporting through the **EnableResult\(\)** and **DisableResult\(\)** interfaces. If the bottom-layer metadata needs to be reported, the pipeline creates a buffer queue in the CameraDeviceDriverModel to collect and transfer metadata, queries the configuration table based on the StreamPipelineStrategy module, and creates and connects to the specified node through the StreamPipelineBuilder module. The MetaQueueManager module delivers the buffer to the bottom layer, and the bottom-layer node fills in data. The MetaQueueManager module then invokes the upper-layer callback to transfer the data to the upper layer. +7. The Camera Service controls underlying metadata reporting through the **EnableResult()** and **DisableResult()** interfaces. If the underlying metadata needs to be reported, the pipeline creates a buffer queue in the CameraDeviceDriverModel to collect and transfer metadata, queries the configuration table based on the StreamPipelineStrategy module, and creates and connects to the specified node through the StreamPipelineBuilder module. The MetaQueueManager module delivers the buffer to the bottom layer, and the bottom-layer node fills in data. The MetaQueueManager module then invokes the upper-layer callback to transfer the data to the upper layer. -8. The Camera Service calls the **Close\(\)** interface of the **CameraDevice** class, and the **CameraDevice** instance calls the corresponding DeviceManager module to power off each hardware. If an offline stream exists in the subpipeline of the IPP node, the offline stream must be reserved until the execution is complete. +8. The Camera Service calls the **Close()** interface of the **CameraDevice** class, and the **CameraDevice** instance calls the corresponding DeviceManager module to power off each hardware. If an offline stream exists in the subpipeline of the IPP node, the offline stream must be reserved until the execution is complete. -9. To implement dynamic frame control, a CollectBuffer thread is started in the StreamOperator. The CollectBuffer thread obtains a buffer from the buffer queue of each stream. If the frame rate of a stream needs to be controlled \(1/n of the sensor output frame rate\), the CollectBuffer thread can control the buffer packaging of each frame as required, and determine whether to collect the buffer of the stream. For example, if the output frame rate of the sensor is 120 fps and the preview stream frame rate is 30 fps, the CollectBuffer thread collects the buffer of the preview stream every 4 fps. +9. To implement dynamic frame control, a CollectBuffer thread is started in the StreamOperator. The CollectBuffer thread obtains a buffer from the buffer queue of each stream. If the frame rate of a stream needs to be controlled (1/n of the sensor output frame rate), the CollectBuffer thread can control the buffer packaging of each frame as required, and determine whether to collect the buffer of the stream. For example, if the output frame rate of the sensor is 120 fps and the preview stream frame rate is 30 fps, the CollectBuffer thread collects the buffer of the preview stream every 4 fps. + -## Development Guidelines +## Development Guidelines -### Available APIs -For details about the HDI functionalities and the function passing rules, see "Available APIs" in [Camera](https://gitee.com/openharmony/drivers_peripheral/blob/master/camera/README_zh.md). +### When to Use -### How to Develop +The camera module encapsulates camera operations in camera preview, photographing, and video streams to facilitate camera hardware operations and improve development efficiency. -The following describes the main APIs of the camera driver model, including the APIs for registering and detecting cameras, creating, capturing, and destroying streams, and enabling and disabling devices. \(To clearly describe the implementation of main functionalities, some error judgment and log source code are not described here.\) +### Available APIs -1. Register a **CameraHost**. +- icamera_device.h - Define the **HdfDriverEntry** structure to define the method for initializing a **CameraHost**. + | API | Description | + | ------------------------------------------------------------ | ---------------------------- | + | CamRetCode GetStreamOperator(
const OHOS::sptr &callback,
OHOS::sptr &streamOperator) | Obtains the stream controller. | + | CamRetCode UpdateSettings(const std::shared_ptr &settingss) | Updates device control parameters. | + | CamRetCode SetResultMode(const ResultCallbackMode &mode) | Sets the result callback mode and function.| + | CamRetCode GetEnabledResults(std::vector &results) | Obtains the enabled ResultMeta. | + | CamRetCode EnableResult(const std::vector &results) | Enables specific ResultMeta. | + | CamRetCode DisableResult(const std::vector &results) | Disables specific ResultMeta. | + | void Close() | Closes the camera device. | - ``` - struct HdfDriverEntry g_cameraHostDriverEntry = { - .moduleVersion = 1, - .moduleName = "camera_service", - .Bind = HdfCameraHostDriverBind, - .Init = HdfCameraHostDriverInit, - .Release = HdfCameraHostDriverRelease, - }; - HDF_INIT(g_cameraHostDriverEntry); // Register the HdfDriverEntry structure with the HDF. - ``` +- icamera_device_callback.h -2. Initialize the **CameraHost**. + | API | Description | + | ------------------------------------------------------------ | ------------------------------------------------------------ | + | void OnError(ErrorType type, int32_t errorCode) | Called when an error occurs on the device to return error information. You need to implement this interface.| + | void OnResult(uint64_t timestamp, const std::shared_ptr &result) | Callback invoked to report metadata related to the camera device. | - **HdfCameraHostDriverBind** defined in the **HdfDriverEntry** structure provides the registration of **CameraServiceDispatch\(\)** and **CameraHostStubInstance\(\)**. **CameraServiceDispatch\(\)** is used to remotely call a method of the **CameraHost**, such as **OpenCamera\(\)** and **SetFlashlight\(\)**. **CameraHostStubInstance\(\)** is used to initialize the camera device, which is called during system startup. - ``` - int HdfCameraHostDriverBind(HdfDeviceObject *deviceObject) - { - HDF_LOGI("HdfCameraHostDriverBind enter!"); - if (deviceObject == nullptr) { - HDF_LOGE("HdfCameraHostDriverBind: HdfDeviceObject is NULL !"); - return HDF_FAILURE; - } - HdfCameraService *hdfCameraService = reinterpret_cast(OsalMemAlloc(sizeof(HdfCameraService))); - if (hdfCameraService == nullptr) { - HDF_LOGE("HdfCameraHostDriverBind OsalMemAlloc HdfCameraService failed!"); - return HDF_FAILURE; - } - hdfCameraService->ioservice.Dispatch = CameraServiceDispatch; // Used to call methods of the CameraHost. - hdfCameraService->ioservice.Open = nullptr; - hdfCameraService->ioservice.Release = nullptr; - hdfCameraService->instance = CameraHostStubInstance(); // Initialize the camera device. - deviceObject->service = &hdfCameraService->ioservice; - return HDF_SUCCESS; - } - ``` +- icamera_host.h - The following functions are the implementation of the methods of the **CameraHost**: + | API | Description | + | ------------------------------------------------------------ | ------------------------------ | + | CamRetCode SetCallback(const OHOS::sptr &callback) | Sets the **ICameraHostCallback** API. | + | CamRetCode GetCameraIds(std::vector\ &cameraIds) | Obtains the IDs of available camera devices.| + | CamRetCode GetCameraAbility(const std::string &cameraId,
std::shared_ptr &ability) | Obtains the abilities of a camera device. | + | CamRetCode OpenCamera(const std::string &cameraId,
const OHOS::sptr &callback,
OHOS::sptr &device) | Opens a camera. | + | CamRetCode SetFlashlight(const std::string &cameraId, bool &isEnable) | Turns on or off the flash. | - ``` - int32_t CameraHostStub::CameraHostServiceStubOnRemoteRequest(int cmdId, MessageParcel &data, - MessageParcel &reply, MessageOption &option) - { - switch(cmdId) { - case CMD_CAMERA_HOST_SET_CALLBACK: { - return CameraHostStubSetCallback(data, reply, option); - } - case CMD_CAMERA_HOST_GET_CAMERAID: { - return CameraHostStubGetCameraIds(data, reply, option); - } - case CMD_CAMERA_HOST_GET_CAMERA_ABILITY: { - return CameraHostStubGetCameraAbility(data, reply, option); - } - case CMD_CAMERA_HOST_OPEN_CAMERA: { - return CameraHostStubOpenCamera(data, reply, option); - } - case CMD_CAMERA_HOST_SET_FLASH_LIGHT: { - return CameraHostStubSetFlashlight(data, reply, option); - } - default: { - HDF_LOGE("%s: not support cmd %d", __func__, cmdId); - return HDF_ERR_INVALID_PARAM; - } - } - return HDF_SUCCESS; - } - ``` +- icamera_host_callback.h - **CameraHostStubInstance\(\)** finally calls **CameraHostImpl::Init\(\)** to obtain the physical camera and initialize the DeviceManager and PipelineCore modules. + | API | Description | + | ------------------------------------------------------------ | ---------------------- | + | void OnCameraStatus(const std::string &cameraId, CameraStatus status) | Reports camera status changes.| + | void OnFlashlightStatus(const std::string &cameraId, FlashlightStatus status) | Callback invoked to report the flash status changes. | -3. Obtain the **CamerHost**. +- ioffline_stream_operator.h - Call the **Get\(\)** interface to obtain the **CameraHost** from the **CameraService**. The **Get\(\)** interface is as follows: + | API | Description | + | ------------------------------------------------------------ | -------------- | + | CamRetCode CancelCapture(int captureId) | Cancels a capture request. | + | CamRetCode ReleaseStreams(const std::vector &streamIds) | Releases streams. | + | CamRetCode Release() | Releases all offline streams.| - ``` - sptr ICameraHost::Get(const char *serviceName) - { - do { - using namespace OHOS::HDI::ServiceManager::V1_0; - auto servMgr = IServiceManager::Get(); - if (servMgr == nullptr) { - HDF_LOGE("%s: IServiceManager failed!", __func__); - break; - } - auto remote = servMgr->GetService(serviceName); // Obtain the CameraHost based on serviceName. - if (remote != nullptr) { - sptr hostSptr = iface_cast(remote); // Return the CameraHostProxy object that contains methods such as OpenCamera() to the caller. - return hostSptr; - } - HDF_LOGE("%s: GetService failed! serviceName = %s", __func__, serviceName); - } while(false); - HDF_LOGE("%s: get %s failed!", __func__, serviceName); - return nullptr; - } - ``` +- istream_operator.h -4. Implement the **OpenCamera\(\)** interface. + | API | Description | + | ------------------------------------------------------------ | -------------------------------- | + | CamRetCode IsStreamsSupported(
OperationMode mode,
const std::shared_ptr\ &modeSetting,
const std::vector<std::shared_ptr<StreamInfo>> &info,
StreamSupportType &type) | Checks whether a stream can be added. | + | CamRetCode CreateStreams(const std::vector> &streamInfos) | Creates streams. | + | CamRetCode ReleaseStreams(const std::vector &streamIds) | Releases streams. | + | CamRetCode CommitStreams(OperationMode mode,
const std::shared_ptr &modeSetting) | Configure streams. | + | CamRetCode GetStreamAttributes(
std::vector> &attributes) | Obtain stream attributes. | + | CamRetCode AttachBufferQueue(int streamId, const OHOS::sptr\ &producer) | Attaches a producer handle to a stream. | + | CamRetCode DetachBufferQueue(int streamId) | Detaches a producer handle from a stream.| + | CamRetCode Capture(int captureId,
const std::shared_ptr &info, bool isStreaming) | Captures images. | + | CamRetCode CancelCapture(int captureId) | Cancels a capture. | + | CamRetCode ChangeToOfflineStream(const std::vector &streamIds,
OHOS::sptr &callback,
OHOS::sptr &offlineOperator) | Changes a stream into an offline stream. | - The **CameraHostProxy** class provides five interfaces: **SetCallback\(\)**, **GetCameraIds\(\)**, **GetCameraAbility\(\)**, **OpenCamera\(\)**, and **SetFlashlight\(\)**. The following describes **OpenCamera\(\)**. +- istream_operator_callback.h - The **OpenCamera\(\)** interface calls the remote **CameraHostStubOpenCamera\(\)** interface through the CMD\_CAMERA\_HOST\_OPEN\_CAMERA to obtain an **ICameraDevice** object. + | API | Description | + | ------------------------------------------------------------ | ---------------------------------------- | + | void OnCaptureStarted(int32_t captureId, const std::vector &streamIds) | Called when a capture starts. | + | void OnCaptureEnded(int32_t captureId,
const std::vector> &infos) | Called when a capture ends. | + | void OnCaptureError(int32_t captureId,
const std::vector> &infos) | Called when an error occurs during the capture.| + | void OnFrameShutter(int32_t captureId,
const std::vector &streamIds, uint64_t timestamp) | Called when a frame is captured. | - ``` - CamRetCode CameraHostProxy::OpenCamera(const std::string &cameraId, const OHOS::sptr &callback, OHOS::sptr &pDevice) - { - int32_t ret = Remote()->SendRequest(CMD_CAMERA_HOST_REMOTE_OPEN_CAMERA, data, reply, option); - if (ret != HDF_SUCCESS) { - HDF_LOGE("%{public}s: SendRequest failed, error code is %{public}d", __func__, ret); - return INVALID_ARGUMENT; - } - CamRetCode retCode = static_cast(reply.ReadInt32()); - bool flag = reply.ReadBool(); - if (flag) { - sptr remoteCameraDevice = reply.ReadRemoteObject(); - if (remoteCameraDevice == nullptr) { - HDF_LOGE("%{public}s: CameraHostProxy remoteCameraDevice is null", __func__); - } - pDevice = OHOS::iface_cast(remoteCameraDevice); - } - return retCode; - } - ``` +### How to Develop +To camera driver development procedure is as follows: - **Remote\(\)-\>SendRequest** calls **CameraHostServiceStubOnRemoteRequest\(\)**, enters the **CameraHostStubOpenCamera\(\)** interface based on **cmdId**, and finally calls **CameraHostImpl::OpenCamera\(\)** to obtain a **CameraDevice** and power on the camera hardware. +1. Register a **CameraHost**. + Define the **HdfDriverEntry** structure to define the method for initializing a **CameraHost**. ``` - CamRetCode CameraHostImpl::OpenCamera(const std::string &cameraId, const OHOS::sptr &callback, OHOS::sptr &device) - { - std::shared_ptr cameraDevice = std::static_pointer_cast(itr->second); - if (cameraDevice == nullptr) { - CAMERA_LOGE("camera device is null."); - return INSUFFICIENT_RESOURCES; - } - CamRetCode ret = cameraDevice->SetCallback(callback); - if (ret != NO_ERROR) { - CAMERA_LOGW("set camera device callback faild."); - return ret; - } - CameraHostConfig *config = CameraHostConfig::GetInstance(); - if (config == nullptr) { - return INVALID_ARGUMENT; - } - std::vector phyCameraIds; - RetCode rc = config->GetPhysicCameraIds(cameraId, phyCameraIds); - if (rc != RC_OK) { - CAMERA_LOGE("get physic cameraId failed."); - return DEVICE_ERROR; - } - if (CameraPowerUp(cameraId, phyCameraIds) != RC_OK) { // Power on the camera hardware. - CAMERA_LOGE("camera powerup failed."); - CameraPowerDown(phyCameraIds); - return DEVICE_ERROR; - } - - auto sptrDevice = deviceBackup_.find(cameraId); - if (sptrDevice == deviceBackup_.end()) { - deviceBackup_[cameraId] = cameraDevice.get(); - } - device = deviceBackup_[cameraId]; - cameraDevice->SetStatus(true); - return NO_ERROR; - } - ``` + struct HdfDriverEntry g_cameraHostDriverEntry = { + .moduleVersion = 1, + .moduleName = "camera_service", + .Bind = HdfCameraHostDriverBind, + .Init = HdfCameraHostDriverInit, + .Release = HdfCameraHostDriverRelease, + }; + HDF_INIT(g_cameraHostDriverEntry); // Register the HdfDriverEntry structure with the HDF. + ``` -5. Implement the **GetStreamOperator\(\)** interface. - - **CameraDeviceImpl** defines interfaces such as **GetStreamOperator\(\)**, **UpdateSettings\(\)**, **SetResultMode\(\)**, and **GetEnabledResult\(\)**. The following is an example of implementing the **GetStreamOperator\(\)** interface: - - ``` - CamRetCode CameraDeviceImpl::GetStreamOperator(const OHOS::sptr &callback, - OHOS::sptr &streamOperator) - { - if (callback == nullptr) { - CAMERA_LOGW("input callback is null."); - return INVALID_ARGUMENT; - } - spCameraDeciceCallback_ = callback; - if (spStreamOperator_ == nullptr) { - // Here, an spStreamOperator object is created and passed to the caller for stream operations. - spStreamOperator_ = new(std::nothrow) StreamOperatorImpl(spCameraDeciceCallback_, shared_from_this()); - if (spStreamOperator_ == nullptr) { - CAMERA_LOGW("create stream operator failed."); - return DEVICE_ERROR; - } - ismOperator_ = spStreamOperator_; - } - streamOperator = ismOperator_; - - spStreamOperator_->SetRequestCallback([this](){ - cameraDeciceCallback_->OnError(REQUEST_TIMEOUT, 0); - }); - } - ``` - -6. Create a stream. +2. Initialize the **CameraHost**. - Fill in the **StreamInfo** structure before creating a stream by calling **CreateStreams\(\)**. + **HdfCameraHostDriverBind** defined in the **HdfDriverEntry** structure provides the registration of **CameraServiceDispatch()** and **CameraHostStubInstance()**. **CameraServiceDispatch()** is used to remotely call a method of the **CameraHost**, such as **OpenCamera()** and **SetFlashlight()**. **CameraHostStubInstance()** is used to initialize the camera device, which is called during system startup. + + ``` + int HdfCameraHostDriverBind(HdfDeviceObject *deviceObject) + { + HDF_LOGI("HdfCameraHostDriverBind enter!"); + if (deviceObject == nullptr) { + HDF_LOGE("HdfCameraHostDriverBind: HdfDeviceObject is NULL !"); + return HDF_FAILURE; + } + HdfCameraService *hdfCameraService = reinterpret_cast(OsalMemAlloc(sizeof(HdfCameraService))); + if (hdfCameraService == nullptr) { + HDF_LOGE("HdfCameraHostDriverBind OsalMemAlloc HdfCameraService failed!"); + return HDF_FAILURE; + } + hdfCameraService->ioservice.Dispatch = CameraServiceDispatch; // Used to call methods of the CameraHost. + hdfCameraService->ioservice.Open = nullptr; + hdfCameraService->ioservice.Release = nullptr; + hdfCameraService->instance = CameraHostStubInstance(); // Initialize the camera device. + deviceObject->service = &hdfCameraService->ioservice; + return HDF_SUCCESS; + } + ``` + + The following functions are the implementation of the methods of the **CameraHost**: + + ``` + int32_t CameraHostStub::CameraHostServiceStubOnRemoteRequest(int cmdId, MessageParcel &data, + MessageParcel &reply, MessageOption &option) + { + switch(cmdId) { + case CMD_CAMERA_HOST_SET_CALLBACK: { + return CameraHostStubSetCallback(data, reply, option); + } + case CMD_CAMERA_HOST_GET_CAMERAID: { + return CameraHostStubGetCameraIds(data, reply, option); + } + case CMD_CAMERA_HOST_GET_CAMERA_ABILITY: { + return CameraHostStubGetCameraAbility(data, reply, option); + } + case CMD_CAMERA_HOST_OPEN_CAMERA: { + return CameraHostStubOpenCamera(data, reply, option); + } + case CMD_CAMERA_HOST_SET_FLASH_LIGHT: { + return CameraHostStubSetFlashlight(data, reply, option); + } + default: { + HDF_LOGE("%s: not support cmd %d", __func__, cmdId); + return HDF_ERR_INVALID_PARAM; + } + } + return HDF_SUCCESS; + } + ``` + + **CameraHostStubInstance()** finally calls **CameraHostImpl::Init()** to obtain the physical camera and initialize the DeviceManager and PipelineCore modules. + +3. Obtain the **CameraHost**. + + Call the **Get()** interface to obtain the **CameraHost** from the **CameraService**. The **Get()** interface is as follows: + + ``` + sptr ICameraHost::Get(const char *serviceName) + { + do { + using namespace OHOS::HDI::ServiceManager::V1_0; + auto servMgr = IServiceManager::Get(); + if (servMgr == nullptr) { + HDF_LOGE("%s: IServiceManager failed!", __func__); + break; + } + auto remote = servMgr->GetService(serviceName); // Obtain the CameraHost based on serviceName. + if (remote != nullptr) { + sptr hostSptr = iface_cast(remote); // Return the CameraHostProxy object that contains interfaces such as OpenCamera() to the caller. + return hostSptr; + } + HDF_LOGE("%s: GetService failed! serviceName = %s", __func__, serviceName); + } while(false); + HDF_LOGE("%s: get %s failed!", __func__, serviceName); + return nullptr; + } + ``` - ``` - using StreamInfo = struct _StreamInfo { - int streamId_; - int width_; // Stream width - int height_; // Stream height - int format_; // Stream format, for example, PIXEL_FMT_YCRCB_420_SP - int datasapce_; - StreamIntent intent_; // StreamIntent, for example, PREVIEW - bool tunneledMode_; - OHOS::sptr bufferQueue_; // The stream buffer queue can be created by using the streamCustomer->CreateProducer() interface. - int minFrameDuration_; - EncodeType encodeType_; - }; - ``` +4. Implement the **OpenCamera\(\)** interface. - The **CreateStreams\(\)** interface in the **StreamOperatorImpl** class is used to create a **StreamBase** instance, which can then be used to initialize operations such as **CreateBufferPool\(\)** by using the **init\(\)** method. + The **CameraHostProxy** class provides five interfaces: **SetCallback()**, **GetCameraIds()**, **GetCameraAbility()**, **OpenCamera()**, and **SetFlashlight()**. The following describes **OpenCamera()**. + The **OpenCamera()** interface calls the remote **CameraHostStubOpenCamera()** interface through the CMD_CAMERA_HOST_OPEN_CAMERA to obtain an **ICameraDevice** object. + + ``` + CamRetCode CameraHostProxy::OpenCamera(const std::string &cameraId, const OHOS::sptr &callback, OHOS::sptr &pDevice) + { + int32_t ret = Remote()->SendRequest(CMD_CAMERA_HOST_REMOTE_OPEN_CAMERA, data, reply, option); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%{public}s: SendRequest failed, error code is %{public}d", __func__, ret); + return INVALID_ARGUMENT; + } + CamRetCode retCode = static_cast(reply.ReadInt32()); + bool flag = reply.ReadBool(); + if (flag) { + sptr remoteCameraDevice = reply.ReadRemoteObject(); + if (remoteCameraDevice == nullptr) { + HDF_LOGE("%{public}s: CameraHostProxy remoteCameraDevice is null", __func__); + } + pDevice = OHOS::iface_cast(remoteCameraDevice); + } + return retCode; + } + ``` + + **Remote()->SendRequest** calls **CameraHostServiceStubOnRemoteRequest()**, enters the **CameraHostStubOpenCamera()** interface based on **cmdId**, and finally calls **CameraHostImpl::OpenCamera()** to obtain a **CameraDevice** and power on the camera hardware. + + ``` + CamRetCode CameraHostImpl::OpenCamera(const std::string &cameraId, const OHOS::sptr &callback, OHOS::sptr &device) + { + std::shared_ptr cameraDevice = std::static_pointer_cast(itr->second); + if (cameraDevice == nullptr) { + CAMERA_LOGE("camera device is null."); + return INSUFFICIENT_RESOURCES; + } + CamRetCode ret = cameraDevice->SetCallback(callback); + if (ret != NO_ERROR) { + CAMERA_LOGW("set camera device callback failed."); + return ret; + } + CameraHostConfig *config = CameraHostConfig::GetInstance(); + if (config == nullptr) { + return INVALID_ARGUMENT; + } + std::vector phyCameraIds; + RetCode rc = config->GetPhysicCameraIds(cameraId, phyCameraIds); + if (rc != RC_OK) { + CAMERA_LOGE("get physic cameraId failed."); + return DEVICE_ERROR; + } + if (CameraPowerUp(cameraId, phyCameraIds) != RC_OK) { // Power on the camera hardware. + CAMERA_LOGE("camera powerup failed."); + CameraPowerDown(phyCameraIds); + return DEVICE_ERROR; + } + + auto sptrDevice = deviceBackup_.find(cameraId); + if (sptrDevice == deviceBackup_.end()) { + deviceBackup_[cameraId] = cameraDevice.get(); + } + device = deviceBackup_[cameraId]; + cameraDevice->SetStatus(true); + return NO_ERROR; + } + ``` - ``` - RetCode StreamOperatorImpl::CreateStream(const std::shared_ptr& streamInfo) - { - static std::map typeMap = { - {PREVIEW, "PREVIEW"}, - {VIDEO, "VIDEO"}, - {STILL_CAPTURE, "STILL_CAPTURE"}, - {POST_VIEW, "POST_VIEW"}, {ANALYZE, "ANALYZE"}, - {CUSTOM, "CUSTOM"} - }; - - auto itr = typeMap.find(streamInfo->intent_); - if (itr == typeMap.end()) { - CAMERA_LOGE("do not support stream type. [type = %{public}d]", streamInfo->intent_); - return RC_ERROR; - } - std::shared_ptr stream = StreamFactory::Instance().CreateShared(itr->second); // Create a StreamBase instance. - RetCode rc = stream->Init(streamInfo); - return RC_OK; - } - ``` +5. Implement the **GetStreamOperator\(\)** interface. -7. Configure the stream. + **CameraDeviceImpl** defines interfaces such as **GetStreamOperator()**, **UpdateSettings()**, **SetResultMode()**, and **GetEnabledResult()**. The following is an example of implementing the **GetStreamOperator()** interface: + + ``` + CamRetCode CameraDeviceImpl::GetStreamOperator(const OHOS::sptr &callback, + OHOS::sptr &streamOperator) + { + if (callback == nullptr) { + CAMERA_LOGW("input callback is null."); + return INVALID_ARGUMENT; + } + spCameraDeviceCallback_ = callback; + if (spStreamOperator_ == nullptr) { + // Here, an spStreamOperator object is created and passed to the caller for stream operations. + spStreamOperator_ = new(std::nothrow) StreamOperatorImpl(spCameraDeviceCallback_, shared_from_this()); + if (spStreamOperator_ == nullptr) { + CAMERA_LOGW("create stream operator failed."); + return DEVICE_ERROR; + } + ismOperator_ = spStreamOperator_; + } + streamOperator = ismOperator_; + + spStreamOperator_->SetRequestCallback([this](){ + spCameraDeviceCallback_->OnError(REQUEST_TIMEOUT, 0); + }); + } + ``` - Use the **CommitStreams\(\)** method to configure the stream, including PipelineCore initialization and creation. It must be called after the stream is created. +6. Create a stream. - ``` - CamRetCode StreamOperatorImpl::CommitStreams(OperationMode mode, const std::shared_ptr& modeSetting) - { - auto cameraDevice = cameraDevice_.lock(); - if (cameraDevice == nullptr) { - CAMERA_LOGE("camera device closed."); - return CAMERA_CLOSED; - } - std::shared_ptr PipelineCore = - std::static_pointer_cast(cameraDevice)->GetPipelineCore(); - if (PipelineCore == nullptr) { + Fill in the **StreamInfo** structure before creating a stream by calling **CreateStreams()**. + + ``` + using StreamInfo = struct _StreamInfo { + int streamId_; + int width_; // Stream width + int height_; // Stream height + int format_; // Stream format, for example, PIXEL_FMT_YCRCB_420_SP + int dataSpace_; + StreamIntent intent_; // StreamIntent, for example, PREVIEW + bool tunneledMode_; + OHOS::sptr bufferQueue_; // The stream buffer queue can be created by using the streamCustomer->CreateProducer() interface. + int minFrameDuration_; + EncodeType encodeType_; + }; + ``` + + The **CreateStreams()** interface in the **StreamOperatorImpl** class is used to create a **StreamBase** instance, which can then be used to initialize operations such as **CreateBufferPool()** by using the **init()** interface. + + ``` + RetCode StreamOperatorImpl::CreateStream(const std::shared_ptr& streamInfo) + { + static std::map typeMap = { + {PREVIEW, "PREVIEW"}, + {VIDEO, "VIDEO"}, + {STILL_CAPTURE, "STILL_CAPTURE"}, + {POST_VIEW, "POST_VIEW"}, {ANALYZE, "ANALYZE"}, + {CUSTOM, "CUSTOM"} + }; + + auto itr = typeMap.find(streamInfo->intent_); + if (itr == typeMap.end()) { + CAMERA_LOGE("do not support stream type. [type = %{public}d]", streamInfo->intent_); + return RC_ERROR; + } + std::shared_ptr stream = StreamFactory::Instance().CreateShared(itr->second); // Create a StreamBase instance. + RetCode rc = stream->Init(streamInfo); + return RC_OK; + } + ``` + +7. Configure the stream. + + Use the **CommitStreams()** interface to configure the stream, including PipelineCore initialization and creation. It must be called after the stream is created. + + ``` + CamRetCode StreamOperatorImpl::CommitStreams(OperationMode mode, const std::shared_ptr& modeSetting) + { + auto cameraDevice = cameraDevice_.lock(); + if (cameraDevice == nullptr) { + CAMERA_LOGE("camera device closed."); + return CAMERA_CLOSED; + } + std::shared_ptr PipelineCore = + std::static_pointer_cast(cameraDevice)->GetPipelineCore(); + if (PipelineCore == nullptr) { CAMERA_LOGE("Failed to obtain PipelineCore."); - return CAMERA_CLOSED; - } - - streamPipeCore_ = PipelineCore->GetStreamPipelineCore(); - if (streamPipeCore_ == nullptr) { + return CAMERA_CLOSED; + } + + streamPipeCore_ = PipelineCore->GetStreamPipelineCore(); + if (streamPipeCore_ == nullptr) { CAMERA_LOGE("Failed to obtain the stream PipelineCore."); - return DEVICE_ERROR; - } - - RetCode rc = streamPipeCore_->Init(); // Initialize the PipelineCore. - if (rc != RC_OK) { + return DEVICE_ERROR; + } + + RetCode rc = streamPipeCore_->Init(); // Initialize the PipelineCore. + if (rc != RC_OK) { CAMERA_LOGE("Failed to initialize the stream PipelineCore."); - return DEVICE_ERROR; - } - rc = streamPipeCore_->CreatePipeline(mode); // Create a pipeline. - if (rc != RC_OK) { + return DEVICE_ERROR; + } + rc = streamPipeCore_->CreatePipeline(mode); // Create a pipeline. + if (rc != RC_OK) { CAMERA_LOGE("Failed to create pipeline."); - return INVALID_ARGUMENT; - } - return NO_ERROR; - } - ``` - -8. Capture images. - - Fill in the **CaptureInfo** structure before calling the **Capture\(\)** method. - - ``` - using CaptureInfo = struct _CaptureInfo { - std::vector streamIds_; // IDs of streams to be captured - std::shared_ptr captureSetting_; // Camera ability can be obtained through the GetCameraAbility() interface of CameraHost. - bool enableShutterCallback_; - }; - ``` - - Use the **Capture\(\)** interface in **StreamOperatorImpl** to call the **CreateCapture\(\)** interface to capture streams. - - ``` - CamRetCode StreamOperatorImpl::Capture(int captureId, const std::shared_ptr& captureInfo, bool isStreaming) - { - if (!ValidCaptureInfo(captureId, captureInfo)) { - CAMERA_LOGE("capture streamIds is empty. [captureId = %d]", captureId); - return INVALID_ARGUMENT; - } - std::shared_ptr cameraCapture = nullptr; - RetCode rc = CreateCapture(captureId, captureInfo, isStreaming, cameraCapture); - if (rc != RC_OK) { - CAMERA_LOGE("create capture is failed."); - return DEVICE_ERROR; - } - - { - std::unique_lock lock(captureMutex_); - camerCaptureMap_.insert(std::make_pair(captureId, cameraCapture)); - } - - rc = StartThread(); - if (rc != RC_OK) { - CAMERA_LOGE("preview start failed."); - return DEVICE_ERROR; - } - return NO_ERROR; - } - ``` - -9. Cancel the capture and release the offline stream. - - Use the **CancelCapture\(\)** interface in the **StreamOperatorImpl** class to cancel the stream capture based on **captureId**. - - ``` - CamRetCode StreamOperatorImpl::CancelCapture(int captureId) - { - auto itr = camerCaptureMap_.find(captureId); // Search for the CameraCapture object in the Map based on the captureId. - RetCode rc = itr->second->Cancel(); // Call the Cancel() interface in CameraCapture to cancel the stream capture. - std::unique_lock lock(captureMutex_); - camerCaptureMap_.erase(itr); // Erase the CameraCapture object. - return NO_ERROR; - } - ``` - - Use the **ReleaseStreams\(\)** interface in the **StreamOperatorImpl** class t release the streams created by using **CreateStream\(\)** and **CommitStreams\(\)** and destroy the pipeline. - - ``` - CamRetCode StreamOperatorImpl::ReleaseStreams(const std::vector& streamIds) - { - RetCode rc = DestroyStreamPipeline(streamIds); // Destroy the pipeline based on streamIds. - rc = DestroyHostStreamMgr(streamIds); - rc = DestroyStreams(streamIds); // Destroy the stream specified by streamIds. - return NO_ERROR; - } - ``` + return INVALID_ARGUMENT; + } + return NO_ERROR; + } + ``` + +8. Capture images. + + Fill in the **CaptureInfo** structure before calling the **Capture()** method. + + ``` + using CaptureInfo = struct _CaptureInfo { + std::vector streamIds_; // IDs of streams to be captured + std::shared_ptr captureSetting_; // Camera ability can be obtained through the GetCameraAbility() interface of CameraHost. + bool enableShutterCallback_; + }; + ``` + + Use the **Capture()** interface in **StreamOperatorImpl** to call the **CreateCapture()** interface to capture streams. + + ``` + CamRetCode StreamOperatorImpl::Capture(int captureId, const std::shared_ptr& captureInfo, bool isStreaming) + { + if (!ValidCaptureInfo(captureId, captureInfo)) { + CAMERA_LOGE("capture streamIds is empty. [captureId = %d]", captureId); + return INVALID_ARGUMENT; + } + std::shared_ptr cameraCapture = nullptr; + RetCode rc = CreateCapture(captureId, captureInfo, isStreaming, cameraCapture); + if (rc != RC_OK) { + CAMERA_LOGE("create capture is failed."); + return DEVICE_ERROR; + } + + { + std::unique_lock lock(captureMutex_); + camerCaptureMap_.insert(std::make_pair(captureId, cameraCapture)); + } + + rc = StartThread(); + if (rc != RC_OK) { + CAMERA_LOGE("preview start failed."); + return DEVICE_ERROR; + } + return NO_ERROR; + } + ``` + +9. Cancel the capture and release the offline stream. + + Use the **CancelCapture()** interface in the **StreamOperatorImpl** class to cancel the stream capture based on **captureId**. + + ``` + CamRetCode StreamOperatorImpl::CancelCapture(int captureId) + { + auto itr = camerCaptureMap_.find(captureId); // Search for the CameraCapture object in the Map based on the captureId. + RetCode rc = itr->second->Cancel(); // Call the Cancel() interface in CameraCapture to cancel the stream capture. + std::unique_lock lock(captureMutex_); + camerCaptureMap_.erase(itr); // Erase the CameraCapture object. + return NO_ERROR; + } + ``` + + Use the **ReleaseStreams()** interface in the **StreamOperatorImpl** class t release the streams created by using **CreateStream()** and **CommitStreams()** and destroy the pipeline. + + ``` + CamRetCode StreamOperatorImpl::ReleaseStreams(const std::vector& streamIds) + { + RetCode rc = DestroyStreamPipeline(streamIds); // Destroy the pipeline based on streamIds. + rc = DestroyHostStreamMgr(streamIds); + rc = DestroyStreams(streamIds); // Destroy the stream specified by streamIds. + return NO_ERROR; + } + ``` 10. Close the camera device. - - Use the **Close\(\)** interface in the **CameraDeviceImpl** class to close the camera device. This interface calls **PowerDown\(\)** in the **DeviceManager** to power off the device. - - -## Development Example - -There is a camera demo in the **/drivers/peripheral/camera/hal/init** directory. After system startup, the executable file **ohos\_camera\_demo** is generated in the **/system/bin** directory. This demo can implement basic camera capabilities such as preview and photographing. The following uses the demo as an example to describe how to use the HDI to implement the **PreviewOn\(\)** and **CaptureON\(\)** interfaces. - -1. Construct a Hos3516Demo object in the **main** function. This object contains methods for initializing the camera and starting, stopping, and releasing streams. The **mainDemo-\>InitSensors\(\)** function is used to initialize the **CameraHost**, and the **mainDemo-\>InitCameraDevice\(\)** function is used to initialize the **CameraDevice**. - - ``` - int main(int argc, char** argv) - { - RetCode rc = RC_OK; - auto mainDemo = std::make_shared(); - rc = mainDemo->InitSensors(); // Initialize the CameraHost. - if (rc == RC_ERROR) { - CAMERA_LOGE("main test: mainDemo->InitSensors() error\n"); - return -1; - } - - rc = mainDemo->InitCameraDevice(); // Initialize the CameraDevice. - if (rc == RC_ERROR) { - CAMERA_LOGE("main test: mainDemo->InitCameraDevice() error\n"); - return -1; - } - - rc = PreviewOn(0, mainDemo); // Configure and enable streams. - if (rc != RC_OK) { - CAMERA_LOGE("main test: PreviewOn() error demo exit"); - return -1; - } - - ManuList(mainDemo, argc, argv); // Print the menu to the console. - - return RC_OK; - } - ``` - - The function used to initialize the **CameraHost** is implemented as follows, where the HDI **ICameraHost::Get\(\)** is called to obtain the **demoCameraHost** and set the callback: - - ``` - RetCode Hos3516Demo::InitSensors() - { - demoCameraHost_ = ICameraHost::Get(DEMO_SERVICE_NAME); - if (demoCameraHost_ == nullptr) { - CAMERA_LOGE("demo test: ICameraHost::Get error"); - return RC_ERROR; - } - - hostCallback_ = new CameraHostCallback(); - rc = demoCameraHost_->SetCallback(hostCallback_); - return RC_OK; - } - ``` - - The implementation of the function for initializing the **CameraDevice** is as follows, where the **GetCameraIds\(cameraIds\_\)**, **GetCameraAbility\(cameraId, ability\_\)**, and **OpenCamera\(cameraIds\_.front\(\), callback, demoCameraDevice\_\)** interfaces are called to obtain the **demoCameraHost**. - - ``` - RetCode Hos3516Demo::InitCameraDevice() - { - (void)demoCameraHost_->GetCameraIds(cameraIds_); - const std::string cameraId = cameraIds_.front(); - demoCameraHost_->GetCameraAbility(cameraId, ability_); - - sptr callback = new CameraDeviceCallback(); - rc = demoCameraHost_->OpenCamera(cameraIds_.front(), callback, demoCameraDevice_); - return RC_OK; - } - ``` - -2. Implement the **PreviewOn\(\)** interface to configure streams, enable preview streams, and start stream capture. After this interface is called, the camera preview channel starts running. Two streams are enabled: preview stream and capture or video stream. Only the preview stream will be captured. - - ``` - static RetCode PreviewOn(int mode, const std::shared_ptr& mainDemo) - { - rc = mainDemo->StartPreviewStream(); // Configure the preview stream. - if (mode == 0) { - rc = mainDemo->StartCaptureStream(); // Configure the capture stream. - } else { - rc = mainDemo->StartVideoStream(); // Configure the video stream. - } - - rc = mainDemo->CaptureON(STREAM_ID_PREVIEW, CAPTURE_ID_PREVIEW, CAPTURE_PREVIEW); // Capture the preview stream. - return RC_OK; - } - ``` - - The **StartCaptureStream\(\)**, **StartVideoStream\(\)**, and **StartPreviewStream\(\)** interfaces call the **CreateStream\(\)** interface with different input parameters. - - ``` - RetCode Hos3516Demo::StartVideoStream() - { - RetCode rc = RC_OK; - if (isVideoOn_ == 0) { - isVideoOn_ = 1; - rc = CreateStream(STREAM_ID_VIDEO, streamCustomerVideo_, VIDEO); // To enable the preview stream or capture stream, change the input parameters. - } - return RC_OK; - } - ``` - - The **CreateStream\(\)** interface calls the HDI to configure and create a stream. Specifically, the interface first calls the HDI to obtain a **StreamOperation** object and then creates a **StreamInfo** object. Call **CreateStreams\(\)** and **CommitStreams\(\)** to create and configure a stream. - - ``` - RetCode Hos3516Demo::CreateStreams(const int streamIdSecond, StreamIntent intent) - { - std::vector> streamInfos; - std::vector>().swap(streamInfos); - GetStreamOpt(); // Obtain a StreamOperator object. - std::shared_ptr previewStreamInfo = std::make_shared(); - SetStreamInfo(previewStreamInfo, streamCustomerPreview_, STREAM_ID_PREVIEW, PREVIEW); // Fill in the StreamInfo. - if (previewStreamInfo->bufferQueue_ == nullptr) { - CAMERA_LOGE("demo test: CreateStream CreateProducer(); is nullptr\n"); - return RC_ERROR; - } - streamInfos.push_back(previewStreamInfo); - - std::shared_ptr secondStreamInfo = std::make_shared(); - if (streamIdSecond == STREAM_ID_CAPTURE) { - SetStreamInfo(secondStreamInfo, streamCustomerCapture_, STREAM_ID_CAPTURE, intent); - } else { - SetStreamInfo(secondStreamInfo, streamCustomerVideo_, STREAM_ID_VIDEO, intent); - } - if (secondStreamInfo->bufferQueue_ == nullptr) { - CAMERA_LOGE("demo test: CreateStreams CreateProducer() secondStreamInfo is nullptr\n"); - return RC_ERROR; - } - streamInfos.push_back(secondStreamInfo); - - rc = streamOperator_->CreateStreams(streamInfos); // Create a stream. - if (rc != Camera::NO_ERROR) { - CAMERA_LOGE("demo test: CreateStream CreateStreams error\n"); - return RC_ERROR; - } - - rc = streamOperator_->CommitStreams(Camera::NORMAL, ability_); // Commit the stream. - if (rc != Camera::NO_ERROR) { - CAMERA_LOGE("demo test: CreateStream CommitStreams error\n"); - std::vector streamIds = {STREAM_ID_PREVIEW, streamIdSecond}; - streamOperator_->ReleaseStreams(streamIds); - return RC_ERROR; - } - return RC_OK; - } - ``` - - The **CaptureON\(\)** interface calls the **Capture\(\)** method of **StreamOperator** to obtain camera data, rotate the buffer, and start a thread to receive data of the corresponding type. - - ``` - RetCode Hos3516Demo::CaptureON(const int streamId, const int captureId, CaptureMode mode) - { - The std::shared_ptr captureInfo = std::make_shared(); // Create and fill in CaptureInfo. - captureInfo->streamIds_ = {streamId}; - captureInfo->captureSetting_ = ability_; - captureInfo->enableShutterCallback_ = false; - - The int rc = streamOperator_->Capture(captureId, captureInfo, true); // The stream capture starts, and buffer recycling starts. - if (mode == CAPTURE_PREVIEW) { - streamCustomerPreview_->ReceiveFrameOn(nullptr); // Create a preview thread to receive the passed buffers. - } else if (mode == CAPTURE_SNAPSHOT) { - The streamCustomerCapture_->ReceiveFrameOn([this](void* addr, const uint32_t size) { // Create a capture thread to receive the passed buffers through the StoreImage callback. - StoreImage(addr, size); - }); - } else if (mode == CAPTURE_VIDEO) { - OpenVideoFile(); - streamCustomerVideo_->ReceiveFrameOn([this](void* addr, const uint32_t size) {// Create a video thread to receive the passed buffer by calling the StoreVideo callback. - StoreVideo(addr, size); - }); - } - return RC_OK; - } - ``` - -3. Implement the **ManuList\(\)** function to obtain characters from the console through the **fgets\(\)** interface. Different characters correspond to different capabilities provided by the demo, and the functionality menu is printed. - - ``` - static void ManuList(const std::shared_ptr& mainDemo, - const int argc, char** argv) - { - int idx, c; - int awb = 1; - constexpr char shortOptions[] = "h:cwvaqof:"; - c = getopt_long(argc, argv, shortOptions, longOptions, &idx); - while(1) { - switch (c) { - case 'h': - c = PutMenuAndGetChr(); // Print the menu. - break; - - case 'f': - FlashLightTest(mainDemo); // Test the flashlight capability. - c = PutMenuAndGetChr(); - break; - case 'o': - OfflineTest(mainDemo); // Test the offline capability. - c = PutMenuAndGetChr(); - break; - case 'c': - CaptureTest(mainDemo); // Test the capture capability. - c = PutMenuAndGetChr(); - break; - case 'w': // Test the AWB capability. - if (awb) { - mainDemo->SetAwbMode(OHOS_CAMERA_AWB_MODE_INCANDESCENT); - } else { - mainDemo->SetAwbMode(OHOS_CAMERA_AWB_MODE_OFF); - } - awb = !awb; - c = PutMenuAndGetChr(); - break; - case 'a': // Test the AE capability. - mainDemo->SetAeExpo(); - c = PutMenuAndGetChr(); - break; - case 'v': // Test the video capability. - VideoTest(mainDemo); - c = PutMenuAndGetChr(); - break; - case 'q': // Exit the demo. - PreviewOff(mainDemo); - mainDemo->QuitDemo(); - exit(EXIT_SUCCESS); - - default: - CAMERA_LOGE("main test: command error please retry input command"); - c = PutMenuAndGetChr(); - break; - } - } - } - ``` - - The **PutMenuAndGetChr\(\)** interface prints the menu of the demo and calls **fgets\(\)** to wait for commands from the console. - - ``` - static int PutMenuAndGetChr(void) - { - constexpr uint32_t inputCount = 50; - int c = 0; - char strs[inputCount]; - Usage(stdout); - CAMERA_LOGD("pls input command(input -q exit this app)\n"); - fgets(strs, inputCount, stdin); - - for (int i = 0; i < inputCount; i++) { - if (strs[i] != '-') { - c = strs[i]; - break; - } - } - return c; - } - ``` - - The console outputs the menu details as follows: - - ``` - "Options:\n" - "-h | --help Print this message\n" - "-o | --offline stream offline test\n" - "-c | --capture capture one picture\n" - "-w | --set WB Set white balance Cloudy\n" - "-v | --video capture Viedeo of 10s\n" - "-a | --Set AE Set Auto exposure\n" - "-f | --Set Flashlight Set flashlight ON 5s OFF\n" - "-q | --quit stop preview and quit this app\n"); - ``` - - Other capabilities in the demo are implemented by calling different HDIs, which are similar to **PreviewOn\(\)**. For details, see [ohos\_camera\_demo](https://gitee.com/openharmony/drivers_peripheral/tree/master/camera/hal/init). - - + Use the **Close()** interface in the **CameraDeviceImpl** class to close the camera device. This interface calls **PowerDown()** in the **DeviceManager** to power off the device. + +### Development Example + +There is a camera demo in the **/drivers/peripheral/camera/hal/init** directory. After system startup, the executable file **ohos_camera_demo** is generated in the **/vendor/bin** directory. This demo can implement basic camera capabilities such as preview and photographing. The following uses the demo as an example to describe how to use the HDI to write the **PreviewOn()** and **CaptureON()** instances. For details, see [ohos_camera_demo](https://gitee.com/openharmony/drivers_peripheral/tree/master/camera/hal/init). + +1. Construct a CameraDemo object in the **main** function. This object contains methods for initializing the camera and starting, stopping, and releasing streams. The **mainDemo->InitSensors()** function is used to initialize the **CameraHost**, and the **mainDemo->InitCameraDevice()** function is used to initialize the **CameraDevice**. + + ``` + int main(int argc, char** argv) + { + RetCode rc = RC_OK; + auto mainDemo = std::make_shared(); + rc = mainDemo->InitSensors(); // Initialize the CameraHost. + if (rc == RC_ERROR) { + CAMERA_LOGE("main test: mainDemo->InitSensors() error\n"); + return -1; + } + + rc = mainDemo->InitCameraDevice(); // Initialize the CameraDevice. + if (rc == RC_ERROR) { + CAMERA_LOGE("main test: mainDemo->InitCameraDevice() error\n"); + return -1; + } + + rc = PreviewOn(0, mainDemo); // Configure and enable streams. + if (rc != RC_OK) { + CAMERA_LOGE("main test: PreviewOn() error demo exit"); + return -1; + } + + ManuList(mainDemo, argc, argv); // Print the menu to the console. + + return RC_OK; + } + ``` + + The function used to initialize the **CameraHost** is implemented as follows, where the HDI **ICameraHost::Get()** is called to obtain the **demoCameraHost** and set the callback: + + ``` + RetCode CameraDemo::InitSensors() + { + demoCameraHost_ = ICameraHost::Get(DEMO_SERVICE_NAME); + if (demoCameraHost_ == nullptr) { + CAMERA_LOGE("demo test: ICameraHost::Get error"); + return RC_ERROR; + } + + hostCallback_ = new CameraHostCallback(); + rc = demoCameraHost_->SetCallback(hostCallback_); + return RC_OK; + } + ``` + + The implementation of the function for initializing the **CameraDevice** is as follows, where the **GetCameraIds(cameraIds_)**, **GetCameraAbility(cameraId, ability_)**, and **OpenCamera(cameraIds_.front(), callback, demoCameraDevice_)** interfaces are called to obtain the **demoCameraHost**. + + ``` + RetCode CameraDemo::InitCameraDevice() + { + (void)demoCameraHost_->GetCameraIds(cameraIds_); + const std::string cameraId = cameraIds_.front(); + demoCameraHost_->GetCameraAbility(cameraId, ability_); + + sptr callback = new CameraDeviceCallback(); + rc = demoCameraHost_->OpenCamera(cameraIds_.front(), callback, demoCameraDevice_); + return RC_OK; + } + ``` + +2. Implement the **PreviewOn()** interface to configure streams, enable preview streams, and start stream capture. After this interface is called, the camera preview channel starts running. Two streams are enabled: preview stream and capture or video stream. Only the preview stream will be captured. + + ``` + static RetCode PreviewOn(int mode, const std::shared_ptr& mainDemo) + { + rc = mainDemo->StartPreviewStream(); // Configure the preview stream. + if (mode == 0) { + rc = mainDemo->StartCaptureStream(); // Configure the capture stream. + } else { + rc = mainDemo->StartVideoStream(); // Configure the video stream. + } + + rc = mainDemo->CaptureON(STREAM_ID_PREVIEW, CAPTURE_ID_PREVIEW, CAPTURE_PREVIEW); // Capture the preview stream. + return RC_OK; + } + ``` + + The **StartCaptureStream()**, **StartVideoStream()**, and **StartPreviewStream()** interfaces call the **CreateStream()** interface with different input parameters. + + ``` + RetCode CameraDemo::StartVideoStream() + { + RetCode rc = RC_OK; + if (isVideoOn_ == 0) { + isVideoOn_ = 1; + rc = CreateStream(STREAM_ID_VIDEO, streamCustomerVideo_, VIDEO); // To enable the preview stream or capture stream, change the input parameters. + } + return RC_OK; + } + ``` + + The **CreateStream()** interface calls the HDI to configure and create a stream. Specifically, the interface first calls the HDI to obtain a **StreamOperation** object and then creates a **StreamInfo** object. Call **CreateStreams()** and **CommitStreams()** to create and configure a stream. + + ``` + RetCode CameraDemo::CreateStreams(const int streamIdSecond, StreamIntent intent) + { + std::vector> streamInfos; + std::vector>().swap(streamInfos); + GetStreamOpt(); // Obtain a StreamOperator object. + std::shared_ptr previewStreamInfo = std::make_shared(); + SetStreamInfo(previewStreamInfo, streamCustomerPreview_, STREAM_ID_PREVIEW, PREVIEW); // Fill in the StreamInfo. + if (previewStreamInfo->bufferQueue_ == nullptr) { + CAMERA_LOGE("demo test: CreateStream CreateProducer(); is nullptr\n"); + return RC_ERROR; + } + streamInfos.push_back(previewStreamInfo); + + std::shared_ptr secondStreamInfo = std::make_shared(); + if (streamIdSecond == STREAM_ID_CAPTURE) { + SetStreamInfo(secondStreamInfo, streamCustomerCapture_, STREAM_ID_CAPTURE, intent); + } else { + SetStreamInfo(secondStreamInfo, streamCustomerVideo_, STREAM_ID_VIDEO, intent); + } + + if (secondStreamInfo->bufferQueue_ == nullptr) { + CAMERA_LOGE("demo test: CreateStreams CreateProducer() secondStreamInfo is nullptr\n"); + return RC_ERROR; + } + streamInfos.push_back(secondStreamInfo); + + rc = streamOperator_->CreateStreams(streamInfos); // Create a stream. + if (rc != Camera::NO_ERROR) { + CAMERA_LOGE("demo test: CreateStream CreateStreams error\n"); + return RC_ERROR; + } + + rc = streamOperator_->CommitStreams(Camera::NORMAL, ability_); + if (rc != Camera::NO_ERROR) { + CAMERA_LOGE("demo test: CreateStream CommitStreams error\n"); + std::vector streamIds = {STREAM_ID_PREVIEW, streamIdSecond}; + streamOperator_->ReleaseStreams(streamIds); + return RC_ERROR; + } + return RC_OK; + } + ``` + + The **CaptureON()** interface calls the **Capture()** interface of **StreamOperator** to obtain camera data, rotate the buffer, and start a thread to receive data of the corresponding type. + + ``` + RetCode CameraDemo::CaptureON(const int streamId, const int captureId, CaptureMode mode) + { + std::shared_ptr captureInfo = std::make_shared(); // Create and fill in CaptureInfo. + captureInfo->streamIds_ = {streamId}; + captureInfo->captureSetting_ = ability_; + captureInfo->enableShutterCallback_ = false; + + int rc = streamOperator_->Capture(captureId, captureInfo, true);// The stream capture starts, and buffer recycling starts. + if (mode == CAPTURE_PREVIEW) { + streamCustomerPreview_->ReceiveFrameOn(nullptr); // Create a preview thread to receive the passed buffers. + } else if (mode == CAPTURE_SNAPSHOT) { + streamCustomerCapture_->ReceiveFrameOn([this](void* addr, const uint32_t size) { // Create a capture thread to receive the passed buffers through the StoreImage callback. + StoreImage(addr, size); + }); + } else if (mode == CAPTURE_VIDEO) { + OpenVideoFile(); + streamCustomerVideo_->ReceiveFrameOn([this](void* addr, const uint32_t size) {// Create a video thread to receive the passed buffer by calling the StoreVideo callback. + StoreVideo(addr, size); + }); + } + return RC_OK; + } + ``` + +3. Implement the **ManuList()** function to obtain characters from the console through the **fgets()** interface. Different characters correspond to different capabilities provided by the demo, and the functionality menu is printed. + + ``` + static void ManuList(const std::shared_ptr& mainDemo, + const int argc, char** argv) + { + int idx, c; + int awb = 1; + constexpr char shortOptions[] = "h:cwvaqof:"; + c = getopt_long(argc, argv, shortOptions, longOptions, &idx); + while(1) { + switch (c) { + case 'h': + c = PutMenuAndGetChr(); // Print the menu. + break; + + case 'f': + FlashLightTest(mainDemo); // Test the flashlight capability. + c = PutMenuAndGetChr(); + break; + case 'o': + OfflineTest(mainDemo); // Test the offline capability. + c = PutMenuAndGetChr(); + break; + case 'c': + CaptureTest(mainDemo); // Test the capture capability. + c = PutMenuAndGetChr(); + break; + case 'w': // Test the AWB capability. + if (awb) { + mainDemo->SetAwbMode(OHOS_CAMERA_AWB_MODE_INCANDESCENT); + } else { + mainDemo->SetAwbMode(OHOS_CAMERA_AWB_MODE_OFF); + } + awb = !awb; + c = PutMenuAndGetChr(); + break; + case 'a': // Test the AE capability. + mainDemo->SetAeExpo(); + c = PutMenuAndGetChr(); + break; + case 'v': // Test the video capability. + VideoTest(mainDemo); + c = PutMenuAndGetChr(); + break; + case 'q': // Exit the demo. + PreviewOff(mainDemo); + mainDemo->QuitDemo(); + exit(EXIT_SUCCESS); + + default: + CAMERA_LOGE("main test: command error please retry input command"); + c = PutMenuAndGetChr(); + break; + } + } + } + ``` + + The **PutMenuAndGetChr()** interface prints the menu of the demo and calls **fgets()** to wait for commands from the console. + + ``` + static int PutMenuAndGetChr(void) + { + constexpr uint32_t inputCount = 50; + int c = 0; + char strs[inputCount]; + Usage(stdout); + CAMERA_LOGD("pls input command(input -q exit this app)\n"); + fgets(strs, inputCount, stdin); + + for (int i = 0; i < inputCount; i++) { + if (strs[i] != '-') { + c = strs[i]; + break; + } + } + return c; + } + ``` + + The console outputs the menu details as follows: + + ``` + "Options:\n" + "-h | --help Print this message\n" + "-o | --offline stream offline test\n" + "-c | --capture capture one picture\n" + "-w | --set WB Set white balance Cloudy\n" + "-v | --video capture Viedeo of 10s\n" + "-a | --Set AE Set Auto exposure\n" + "-f | --Set Flashlight Set flashlight ON 5s OFF\n" + "-q | --quit stop preview and quit this app\n"); + ``` + + diff --git a/en/device-dev/driver/driver-peripherals-lcd-des.md b/en/device-dev/driver/driver-peripherals-lcd-des.md index 0bed487f6cfde1253b21755f60d8ad9a8ee50e1d..1def774aeb36f20b380ba4296c22685e84d2a776 100644 --- a/en/device-dev/driver/driver-peripherals-lcd-des.md +++ b/en/device-dev/driver/driver-peripherals-lcd-des.md @@ -159,9 +159,9 @@ The following example shows code for developing an LCD driver: #define HORIZONTAL_BACK_PORCH 20 #define HORIZONTAL_FRONT_PORCH 20 #define HORIZONTAL_SYNC_WIDTH 10 -#define VERTIACL_BACK_PORCH 14 -#define VERTIACL_FRONT_PORCH 16 -#define VERTIACL_SYNC_WIDTH 2 +#define VERTICAL_BACK_PORCH 14 +#define VERTICAL_FRONT_PORCH 16 +#define VERTICAL_SYNC_WIDTH 2 #define FRAME_RATE 60 /* PanelInfo structure */ @@ -300,9 +300,9 @@ static struct PanelInfo g_panelInfo = { .hbp = HORIZONTAL_BACK_PORCH, /* horizontal back porch */ .hfp = HORIZONTAL_FRONT_PORCH, /* horizontal front porch */ .hsw = HORIZONTAL_SYNC_WIDTH, /* horizontal sync width */ - .vbp = VERTIACL_BACK_PORCH, /* vertiacl back porch */ - .vfp = VERTIACL_FRONT_PORCH, /* vertiacl front porch */ - .vsw = VERTIACL_SYNC_WIDTH, /* vertiacl sync width */ + .vbp = VERTICAL_BACK_PORCH, /* vertical back porch */ + .vfp = VERTICAL_FRONT_PORCH, /* vertical front porch */ + .vsw = VERTICAL_SYNC_WIDTH, /* vertical sync width */ .frameRate = FRAME_RATE, /* frame rate */ .intfType = MIPI_DSI, /* panel interface type */ .intfSync = OUTPUT_USER, /* output timming type */ diff --git a/en/device-dev/driver/driver-peripherals-light-des.md b/en/device-dev/driver/driver-peripherals-light-des.md index d5ef04a5f6ed548c6e9a576090c3612fed97cb4c..09fdb3d7f638f9c16b273345132b89c423a63e06 100644 --- a/en/device-dev/driver/driver-peripherals-light-des.md +++ b/en/device-dev/driver/driver-peripherals-light-des.md @@ -148,7 +148,7 @@ The light driver model provides APIs to obtain information about all the lights HdfWorkDestroy(&drvData->work); HdfWorkQueueDestroy(&drvData->workQueue); (void)OsalMutexDestroy(&drvData->mutex); - (void)OsalMemFree(drvData); + OsalMemFree(drvData); g_lightDrvData = NULL; } ``` diff --git a/en/device-dev/driver/driver-peripherals-sensor-des.md b/en/device-dev/driver/driver-peripherals-sensor-des.md index 4f7eef84c1b304ae3208ff8e752b88f84256f3ab..63a01ac73bacbd3ae69bf8afbe131e1926472170 100644 --- a/en/device-dev/driver/driver-peripherals-sensor-des.md +++ b/en/device-dev/driver/driver-peripherals-sensor-des.md @@ -1,5 +1,5 @@ # Sensor - + ## Overview @@ -7,7 +7,8 @@ The sensor driver model masks the sensor hardware differences and provides interfaces for the upper-layer sensor service to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data changes, and setting sensor options. The model is developed on the Hardware Driver Foundation (HDF), Operating System Abstraction Layer (OSAL), and platform driver interfaces (such as the I2C, SPI, and UART buses). It provides functionalities such as cross-OS migration and differentiated device configurations. The figure below shows the architecture of the sensor driver model. -**Figure 1** Sensor driver model +**Figure 1** Sensor driver model + ![Sensor driver model](figures/sensor_driver_model.png) ### Basic Concepts @@ -44,12 +45,12 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen ### When to Use - Data provided by the gravity and gyroscope sensors denotes the tilt and rotation of the device, which helps your application improve user experience in games. -- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This can further reduce power consumption. +- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This prevents the screen from being accidentally touched and further reduces power consumption. - Data provided by the barometric pressure sensor helps your application accurately determine the altitude of the device. - Data provided by the ambient light sensor helps your device automatically adjust its backlight. - Data provided by the Hall effect sensor implements the smart cover mode of your device. When the smart cover is closed, a small window is opened on the phone to reduce power consumption. -### Available APIs +### Available APIs The sensor driver model offers the following APIs: @@ -61,7 +62,7 @@ The sensor driver model offers the following APIs: The sensor driver model provides APIs for the hardware service to make sensor service development easier. See the table below. -**Table 1** APIs for the members in the PinCntlrMethod structure +**Table 1** APIs of the sensor driver model | API| Description| | ----- | -------- | @@ -111,9 +112,9 @@ The sensor driver model also provides certain driver development APIs that need | void ReadSensorData(void) | Reads sensor data.| -For details about the interface implementation, see [How to Develop](#section7893102915819). +For details about the interface implementation, see "How to Develop" below. -### How to Develop +### How to Develop 1. Develop the acceleration sensor abstract driver. Specifically, implement the **Bind**, **Init**, **Release**, and **Dispatch** functions. - Implement the entry function for the acceleration sensor. @@ -513,12 +514,11 @@ For details about the interface implementation, see [How to Develop](#section789 >![](../public_sys-resources/icon-note.gif) **NOTE** > ->- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see [Table 2](#table1156812588320). -> ->- You need to implement the following functions: certain sensor operation interfaces (listed in [Table 3](#table1083014911336)) and sensor chipset HCS configuration. -> - You also need to verify basic driver functions. +>- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see Table 2. +>- You need to implement the following functions: certain sensor operation interfaces (listed in Table 3) and sensor chipset HCS configuration. +>- You also need to verify basic driver functions. -### Commissioning and Verifying +### How to Verify After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. Use the developer self-test platform as the test environment. @@ -545,7 +545,7 @@ void HdfSensorTest::SetUpTestCase() { g_sensorDev = NewSensorInterfaceInstance(); if (g_sensorDev == nullptr) { - printf("test sensorHdi get Module instace failed\n\r"); + printf("test sensorHdi get Module instance failed\n\r"); } } /* Release case resources. */ diff --git a/en/device-dev/driver/driver-platform-dac-des.md b/en/device-dev/driver/driver-platform-dac-des.md new file mode 100644 index 0000000000000000000000000000000000000000..9088d3b689710fa711c014d07bb00a11d8779f11 --- /dev/null +++ b/en/device-dev/driver/driver-platform-dac-des.md @@ -0,0 +1,211 @@ +# DAC + + +## Overview + +### DAC + +A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics. + +The DAC APIs provide a set of methods for DAC data transfer, including: + +- Opening or closing a DAC device +- Setting the target digital-to-analog (DA) value + + +### Basic Concepts + +The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies. + +- Resolution + + The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution. + +- Conversion precision + + Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused. + +- Conversion speed + + The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed. + + The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages. + + The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number. + +### Working Principles + +In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode. + +The DAC module is divided into the following layers: +- The interface layer provides APIs for opening or closing a device and writing data. +- The core layer provides the capabilities of binding, initializing, and releasing devices. +- The adaptation layer implements other functions. + +![](../public_sys-resources/icon-note.gif)NOTE
The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer. + +**Figure 1** Unified service mode + +![](figures/unified-service-mode.png "DAC-unified-service-mode") + +### Constraints + + Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines + +### When to Use + + The DAC module converts digital signals into analog signals in the form of current, voltage, or charge. It is mainly used in audio devices. Audio players and headsets use the DAC module as the digital-to-analog conversion channels. + +### Available APIs + +The table below describes the APIs of the DAC module. For more details, see API Reference. + +**Table 1** DAC driver APIs + +| API | Description | +| :------------------------------------------------------------| :------------ | +| DevHandle DacOpen(uint32_t number) | Opens a DAC device. | +| void DacClose(DevHandle handle) | Closes a DAC device. | +| int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val) | Sets the target DA value. | + +### How to Develop + +The figure below illustrates the process of using a DAC device. + +**Figure 2** Process of using a DAC device + +![](figures/process-of-using-DAC.png "Process of using a DAC") + +#### Opening a DAC Device + +Call **DacOpen()** to open a DAC device before performing the DA conversion. + +``` +DevHandle DacOpen(uint32_t number); +``` + +**Table 2** Description of DacOpen + +| **Parameter** | Description | +| ---------- | ----------------- | +| number | DAC device number. | +| **Return Value**| **Description** | +| NULL | Failed to open the DAC device. | +| Device handle | Handle of the DAC device opened.| + + + +Open device 1 of the two ADC devices (numbered 0 and 1) in the system. + +``` +DevHandle dacHandle = NULL; /* DAC device handle / + +/* Open the DAC device. */ +dacHandle = DacOpen(1); +if (dacHandle == NULL) { + HDF_LOGE("DacOpen: failed\n"); + return; +} +``` + +#### Setting the Target DA Value + +``` +int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val); +``` + +**Table 3** Description of DacWrite + + +| **Parameter** | Description | +| ---------- | -------------- | +| handle | DAC device handle. | +| channel | DAC channel number. | +| val | DA value to set. | +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | + +``` +/* Write the target DA value through the DAC_CHANNEL_NUM channel. */ + ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret); + DacClose(dacHandle); + return -1; + } +``` + +#### Closing a DAC Device + +After the DAC communication is complete, call **DacClose()** to close the DAC device. +``` +void DacClose(DevHandle handle); +``` + +**Table 4** Description of DacClose + + +| **Parameter** | Description | +| ---------- | -------------- | +| handle | DAC device handle. | +| **Return Value**| **Description**| +| void | - | + + + +Example: + +``` +DacClose(dacHandle); /* Close the DAC device. */ +``` + +## Development Example + +The procedure is as follows: + +1. Open the DAC device based on the device number and obtain the device handle. +2. Set the DA value. If the operation fails, close the device handle. +3. Close the DAC device handle if the access to the DAC is complete. + +You can obtain the operation result by printing the log information based on the **val**. + +``` +#include "hdmi_if.h" /* Header file for DAC APIs */ +#include "hdf_log.h" /* Header file for log APIs */ + +/* Define device 0, channel 1. */ +#define DAC_DEVICE_NUM 0 +#define DAC_CHANNEL_NUM 1 + +/* Main entry of DAC routines. */ +static int32_t TestCaseDac(void) +{ + // Set the target DA value. + uint32_t val = 2; + int32_t ret; + DevHandle dacHandle; + + /* Open the DAC device. */ + dacHandle = DacOpen(DAC_DEVICE_NUM); + if (dacHandle == NULL) { + HDF_LOGE("%s: Open DAC%u fail!", __func__, DAC_DEVICE_NUM); + return -1; + } + + /* Write data. */ + ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret); + DacClose(dacHandle); + return -1; + } + + /* Close the DAC device. */ + DacClose(dacHandle); + + return 0; +} +``` diff --git a/en/device-dev/driver/driver-platform-dac-develop.md b/en/device-dev/driver/driver-platform-dac-develop.md new file mode 100644 index 0000000000000000000000000000000000000000..11585ba1168c289a2963112996f36391b97eec5e --- /dev/null +++ b/en/device-dev/driver/driver-platform-dac-develop.md @@ -0,0 +1,470 @@ +# DAC + + +## Overview + +### DAC + +A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics. + +### Basic Concepts + +The DAC module supports development of digital-to-analog conversion. The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies. + +- Resolution + + The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution. + +- Conversion precision + + Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused. + +- Conversion speed + + The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed. + + The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages. + + The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number. + +### Working Principles + +In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode. + +The DAC module is divided into the following layers: +- The interface layer provides APIs for opening or closing a device and writing data. +- The core layer provides the capabilities of binding, initializing, and releasing devices. +- The adaptation layer implements other functions. + +![](../public_sys-resources/icon-note.gif)NOTE
The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer. + +**Figure 1** Unified service mode + +![](figures/unified-service-mode.png "DAC unified service mode") + + + + + +### Constraints + + Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines + +### When to Use + +The DAC module is used for digital-to-analog conversion, audio output, and motor control. The DAC driver is used when the digital signals input by the DAC module are converted into analog signals to output. + +### Available APIs + +The **DacMethod** is used to call the DAC driver functions. + +**DacMethod** definition: + +``` +struct DacMethod { + // Hook used to write data. + int32_t (*write)(struct DacDevice *device, uint32_t channel, uint32_t val); + // Hook used to start a DAC device. + int32_t (*start)(struct DacDevice *device); + // Hook used to stop a DAC device + int32_t (*stop)(struct DacDevice *device); +}; +``` + +**Table 1** Description of the DacMethod structure + + + +| Function| Input Parameter | Output Parameter| Return Value | Description | +| -------- | ------------------------------------------------------------ | ---- | ------------------ | -------------- | +| write | **device**: pointer to the DAC controller at the core layer.
**channel**: channel ID, which is of the uint32_t type.
val: data to write, which is of the uint32_t type.| - | HDF_STATUS| Writes the target digit-to-analog (DA) value.| +| start | **device**: pointer to the DAC controller at the core layer. | - | HDF_STATUS| Starts a DAC device. | +| stop | **device**: pointer to the DAC controller at the core layer. | - | HDF_STATUS| Stops a device. | + + + +### How to Develop + +The DAC module adaptation procedure is as follows: + +- Instantiate the driver entry. +- Configure attribute files. +- Instantiate the APIs of the core layer. +- Debug the driver. + +1. Instantiate the driver entry. + + 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 are collected to form a segment address space similar to an array for the upper layer to invoke. + + Generally, the HDF calls the **Init()** function to load the driver. If **Init()** fails to be called, the HDF calls **Release()** to release driver resources and exit. + + ``` + static struct HdfDriverEntry g_dacDriverEntry = { + .moduleVersion = 1, + .Init = VirtualDacInit, + .Release = VirtualDacRelease, + .moduleName = "virtual_dac_driver",// (Mandatory) The value must be the same as that in the .hcs file. + }; + HDF_INIT(g_dacDriverEntry); // Call HDF_INIT to register the driver entry with the HDF. + ``` + +2. Configure attribute files. + + - Add the device node description to the **vendor/hisilicon/hispark_taurus/hdf_config/device_info/device_info.hcs** file. + + The device attribute values are closely related to the driver implementation and the default values or restriction ranges of the **DacDevice** members at the core layer, for example, the number of device channels and the maximum transmission speed. + + In the unified service mode, the first device node in the **device_info.hcs** file must be the DAC manager. The parameters must be set as follows: + + | Member | Value | + | --------------- | ------------------------------------------------------------ | + | policy | **0**, which indicates that no service is published.| + | priority | Driver startup priority. The value range is 0 to 200. A larger value indicates a lower priority. If the priorities are the same, the device loading sequence is not ensured.| + | permission | Driver permission.| + | moduleName | The value is **HDF_PLATFORM_DAC_MANAGER**.| + | serviceName | The value is **HDF_PLATFORM_DAC_MANAGER**.| + | deviceMatchAttr | Reserved.| + + Configure DAC controller information from the second node. This node specifies a type of DAC controllers rather than a specific DAC controller. In this example, there is only one DAC device. If there are multiple DAC devices, you need to add the **deviceNode** information to the **device_info** file and add the corresponding device attributes to the **dac_config** file. + + **device_info.hcs** configuration reference + + ``` + root { + device_dac :: device { + // device0 is the DAC manager. + device0 :: deviceNode { + policy = 0; + priority = 52; + permission = 0644; + serviceName = "HDF_PLATFORM_DAC_MANAGER"; + moduleName = "HDF_PLATFORM_DAC_MANAGER"; + } + } + // dac_virtual is the DAC controller. + dac_virtual :: deviceNode { + policy = 0; + priority = 56; + permission = 0644; + moduleName = "virtual_dac_driver"; // (Mandatory) Driver name, which must be the same as moduleName in the driver entry. + serviceName = "VIRTUAL_DAC_DRIVER"; // (Mandatory) Unique name of the service published by the driver. + deviceMatchAttr = "virtual_dac"; // (Mandatory) Controller private data, which must be same as that of the corresponding controller in dac_config.hcs. + } + } + ``` + + - Configure the **dac_test_config.hcs** file. + Add a file, for example, **vendor/vendor_hisilicon/hispark_taurus/hdf_config/hdf_test/dac_test_config.hcs** and configure driver parameters. + + ``` + root { + platform { + dac_config { + match_attr = "virtual_dac"; // (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs. + template dac_device { + deviceNum = 0; // Device number. + validChannel = 0x1; // Valid channel 1. + rate = 20000; // Transmission speed. + } + device_0 :: dac_device { + deviceNum = 0; // Device number. + validChannel = 0x2; // Valid channel 2. + } + } + } + } + ``` + +3. Instantiate the APIs of the core layer. + + - Initialize the **DacDevice** object. + + Initialize the **DacDevice** member in the **VirtualDacParseAndInit** function. + + ``` + // Custom structure of the virtual driver + struct VirtualDacDevice { + // DAC device structure + struct DacDevice device; + // DAC device number + uint32_t deviceNum; + // Valid channel + uint32_t validChannel; + // DAC rate + uint32_t rate; + }; + // Parse and initialize the **DacDevice** object of the core layer. + static int32_t VirtualDacParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node) + { + // Define the return values. + int32_t ret; + // Virtual pointer to the DAC device + struct VirtualDacDevice *virtual = NULL; + (void)device; + // Allocate space for the virtual pointer. + virtual = (struct VirtualDacDevice *)OsalMemCalloc(sizeof(*virtual)); + if (virtual == NULL) { + // If the value is null, return an error code. + HDF_LOGE("%s: Malloc virtual fail!", __func__); + return HDF_ERR_MALLOC_FAIL; + } + // Read the configuration of the attribute file. + ret = VirtualDacReadDrs(virtual, node); + if (ret != HDF_SUCCESS) { + // Failed to read the file. + HDF_LOGE("%s: Read drs fail! ret:%d", __func__, ret); + // Release the virtual space. + OsalMemFree(virtual); + // Set the pointer to 0. + virtual = NULL; + return ret; + } + // Initialize the virtual pointer. + VirtualDacDeviceInit(virtual); + // Initialize the priv object in DacDevice. + virtual->device.priv = (void *)node; + // Initialize the devNum object in DacDevice. + virtual->device.devNum = virtual->deviceNum; + // Initialize the ops object in DacDevice. + virtual->device.ops = &g_method; + // Add a DAC device. + ret = DacDeviceAdd(&virtual->device); + if (ret != HDF_SUCCESS) { + // Failed to add the device. + HDF_LOGE("%s: add Dac controller failed! ret = %d", __func__, ret); + // Release the virtual space. + OsalMemFree(virtual); + // Set the virtual pointer to null. + virtual = NULL; + return ret; + } + + return HDF_SUCCESS; + } + ``` + + + + - Custom structure reference + + The custom structure holds parameters and data for the driver. Define the custom structure based on the function parameters of the device. The HDF reads the values in the **dac_config.hcs** file using the **DacTestReadConfig()** function and initializes the structure members using **DeviceResourceIface()**. Some important values, such as the device number and bus number, are also passed to the **DacDevice** object at the core layer. + + ``` + struct VirtualDacDevice { + struct DacDevice device;// (Mandatory) Control object at the core layer. For details, see the description below. + uint32_t deviceNum; // (Mandatory) Device number. + uint32_t validChannel; // (Mandatory) Valid channel. + uint32_t rate; // (Mandatory) Sampling rate. + }; + + // DacDevice is the core layer controller structure. Its members are assigned with values in the Init() function. + struct DacDevice { + const struct DacMethod *ops; + OsalSpinlock spin; // Spinlock. + uint32_t devNum; // Device number. + uint32_t chanNum; // Device channel number. + const struct DacLockMethod *lockOps; + void *priv; + }; + ``` + + - Instantiate the **DacDevice** in **DacMethod**. + + + The **VirtualDacWrite**, **VirtualDacStop**, and **VirtualDacStart** functions are instantiated in **dac_virtual.c**. + + ``` + static const struct DacMethod g_method = { + .write = VirtualDacWrite, // Write data to a DAC device. + .stop = VirtualDacStop, // Stop a DAC device. + .start = VirtualDacStart, // Start a DAC device. + }; + ``` + + ![](../public_sys-resources/icon-note.gif) **NOTE**
+ For details about **DacMethod**, see [Available APIs](#section752964871810). + + + - **Init** function + + Input parameters: + + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information. + + Return value: + + HDF_STATUS (The table below lists some status. For details about other status, see HDF_STATUS in the /drivers/framework/include/utils/hdf_base.h file.) + + | State | Description | + | ---------------------- | -------------- | + | HDF_ERR_INVALID_OBJECT | Invalid controller object.| + | HDF_ERR_INVALID_PARAM | Invalid parameter. | + | HDF_ERR_MALLOC_FAIL | Failed to allocate memory. | + | HDF_ERR_IO | I/O error. | + | HDF_SUCCESS | Transmission successful. | + | HDF_FAILURE | Transmission failed. | + + Function description: + + Initializes the custom structure object and **DacDevice**, and calls the **AdcDeviceAdd** function at the core layer. + + ``` + static int32_t VirtualDacParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node) + { + // Define return value parameters. + int32_t ret; + // Pointer to the DAC device. + struct VirtualDacDevice *virtual = NULL; + (void)device; + // Allocate memory of the specified size. + virtual = (struct VirtualDacDevice *)OsalMemCalloc(sizeof(*virtual)); + if (virtual == NULL) { + // Failed to allocate memory. + HDF_LOGE("%s: Malloc virtual fail!", __func__); + return HDF_ERR_MALLOC_FAIL; + } + // Read the node parameters in the .hcs file. + ret = VirtualDacReadDrs(virtual, node); + if (ret != HDF_SUCCESS) { + // Failed to read the node data. + HDF_LOGE("%s: Read drs fail! ret:%d", __func__, ret); + goto __ERR__; + } + // Initialize the DAC device pointer. + VirtualDacDeviceInit(virtual); + // Pass private node data. + virtual->device.priv = (void *)node; + // Pass the device number. + virtual->device.devNum = virtual->deviceNum; + // Pass the method. + virtual->device.ops = &g_method; + // Add a DAC device. + ret = DacDeviceAdd(&virtual->device); + if (ret != HDF_SUCCESS) { + // Failed to add the DAC device. + HDF_LOGE("%s: add Dac controller failed! ret = %d", __func__, ret); + goto __ERR__; + } + // The DAC device is added. + return HDF_SUCCESS; + __ERR__: + // If the pointer is null + if (virtual != NULL) { + // Release the memory. + OsalMemFree(virtual); + // Set the pointer to null. + virtual = NULL; + } + + return ret; + } + + static int32_t VirtualDacInit(struct HdfDeviceObject *device) + { + // Define return value parameters. + int32_t ret; + // Child node of the device structure + const struct DeviceResourceNode *childNode = NULL; + // Check the input parameter pointer. + if (device == NULL || device->property == NULL) { + // The input parameter pointer is null. + HDF_LOGE("%s: device or property is NULL", __func__); + return HDF_ERR_INVALID_OBJECT; + } + // The input parameter pointer is not null. + ret = HDF_SUCCESS; + DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { + // Parse the child node. + ret = VirtualDacParseAndInit(device, childNode); + if (ret != HDF_SUCCESS) { + // Failed to parse the child node. + break; + } + } + // The child node is parsed. + return ret; + } + ``` + + - **Release** function + + Input parameters: + + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information. + + Return value + + This function returns no value. + + Function description: + + Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. 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 VirtualDacRemoveByNode(const struct DeviceResourceNode *node) + { + // Define return value parameters. + int32_t ret; + // Define the DAC device number. + int16_t devNum; + // Pointer of the DacDevice structure. + struct DacDevice *device = NULL; + // Pointer of the VirtualDacDevice structure. + struct VirtualDacDevice *virtual = NULL; + // Pointer of the DeviceResourceIface structure. + struct DeviceResourceIface *drsOps = NULL; + // Obtain device resources through the instance entry. + drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE); + // Check the input parameter pointer. + if (drsOps == NULL || drsOps->GetUint32 == NULL) { + // The pointer is null. + HDF_LOGE("%s: invalid drs ops fail!", __func__); + return; + } + // Obtain data of the devNum node. + ret = drsOps->GetUint16(node, "devNum", (uint16_t *)&devNum, 0); + if (ret != HDF_SUCCESS) { + // Failed to obtain node data. + HDF_LOGE("%s: read devNum fail!", __func__); + return; + } + // Obtain the DAC device number. + device = DacDeviceGet(devNum); + // Check whether the DAC device number and data are null. + if (device != NULL && device->priv == node) { + // Release the DAC device number if the device data is null. + DacDevicePut(device); + // Remove the DAC device number. + DacDeviceRemove(device); + virtual = (struct VirtualDacDevice *)device; + // Release the virtual pointer. + OsalMemFree(virtual); + } + return; + } + + static void VirtualDacRelease(struct HdfDeviceObject *device) + { + // Define the child node structure pointer of the DeviceResourceNode. + const struct DeviceResourceNode *childNode = NULL; + // Check whether the input parameter pointer is null. + if (device == NULL || device->property == NULL) { + // The input parameter pointer is null. + HDF_LOGE("%s: device or property is NULL", __func__); + return; + } + + DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { + // Remove the DAC through the node. + VirtualDacRemoveByNode(childNode); + } + } + ``` + +4. Debug the driver. + + (Optional) Verify the basic functions of the new driver, for example, whether the test cases are successful after the driver is loaded. + + diff --git a/en/device-dev/driver/driver-platform-hdmi-des.md b/en/device-dev/driver/driver-platform-hdmi-des.md index fde9530405b55cc883e2020e90a1583c862aa60b..aed0b9264778f64ea67de43989a793f18f1be811 100644 --- a/en/device-dev/driver/driver-platform-hdmi-des.md +++ b/en/device-dev/driver/driver-platform-hdmi-des.md @@ -1,128 +1,81 @@ -# HDMI +# HDMI -## Overview -High-Definition Multimedia Interface (HDMI) is an audio/video transmission protocol released by Hitachi, Panasonic, Philips, Silicon Image, Sony, Thomson, and Toshiba. +## Overview -HDMI works in master/slave mode and usually has a source and a sink. +### HDMI -The HDMI APIs provide a set of common functions for HDMI transmission, including: +- High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display. +- HDMI works in master/slave mode and usually has a source and a sink. +- The HDMI APIs provide a set of common functions for HDMI transmission, including: -- Opening and closing an HDMI controller -- Starting and stopping HDMI transmission -- Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute -- Reading the raw Extended Display Identification Data (EDID) from a sink -- Registering and unregistering a callback for HDMI hot plug detect (HPD) + - Opening and closing an HDMI controller + - Starting and stopping HDMI transmission + - Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute + - Reading the raw Extended Display Identification Data (EDID) from a sink + - Registering and unregistering a callback for HDMI hot plug detect (HPD). -[Figure 1](#fig1) shows the HDMI physical connection. +### Basic Concepts - **Figure 1** HDMI physical connection +HDMI is an audio and video transmission protocol released by Hitachi, Panasonic, Philips, Silicon Image, Sony, Thomson, and Toshiba. The transmission process complies with the Transition-minimized Differential Signaling (TMDS). - ![](figures/HDMI_physical_connection.png "HDMI_physical_connection") +- TMDS is used to transmit audio, video, and various auxiliary data. +- Display data channel (DDC) allows the TX and RX ends to obtain the sending and receiving capabilities. However, the HDMI only needs to unidirectionally obtain the capabilities of the RX end (display). +- Consumer Electronics Control (CEC) enables interaction between the HDMI TX and RX devices. +- Fixed rate link (FRL) allows the maximum TMDS bandwidth to be increased from 18 Gbit/s to 48 Gbit/s. +- High-bandwidth Digital Content Protection (HDCP) prevents copying of digital audio and video content being transmitted across devices. +- Extended Display Identification Data (EDID), usually stored in the display firmware, provides the vendor information, EDID version, maximum image size, color settings, vendor pre-settings, frequency range limit, display name, and serial number. -## Available APIs +### Working Principles + +The HDMI source end provides +5 V and GND for DDC and CEC communication. Through the DDC, the source end obtains the sink end parameters, such as the RX capabilities. The CEC is optional. It is used to synchronize the control signals between the source and sink ends to improve user experience. There are four TMDS channels between the HDMI source and sink ends. The TMDS clock channel provides clock signals for TMDS, and the other three channels transmit audio, video, and auxiliary data. HPD is the hot plug detect port. When the sink end is connected, the source end responds by using an interrupt program. + +The figure below shows the HDMI physical connection. + +**Figure 1** HDMI physical connection + +![](figures/HDMI_physical_connection.png "HDMI_physical_connection") + +### Constraints + +Currently, the HDMI module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines + +### When to Use + +HDMI features high transmission rate, wide transmission bandwidth, high compatibility, and can transmit uncompressed audio and video signals. Compared with the traditional full analog interface, HDMI simplifies connection between devices and provides HDMI-specific intelligent features, which are ideal for high-quality audio and video transmission of small-sized devices. + +### Available APIs **Table 1** HDMI driver APIs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Category

-

API

-

Description

-

Managing HDMI controllers

-

HdmiOpen

-		Opens an HDMI controller.

-

HdmiClose

-

Closes an HDMI controller.

-

Starting or stopping HDMI transmission

-

HdmiStart

-		Starts HDMI transmission.

-

HdmiStop

-

Stops HDMI transmission.

-

Setting an HDMI controller

-

HdmiAvmuteSet

-		Sets the AV mute feature.

-

HdmiDeepColorSet

-

Sets the color depth.

-

HdmiDeepColorGet

-

Obtains the color depth.

-

HdmiSetVideoAttribute

-

Sets video attributes.

-

HdmiSetAudioAttribute

-

Sets audio attributes.

-

HdmiSetHdrAttribute

-

Sets HDR attributes.

-

Reading EDID

-

HdmiReadSinkEdid

-		Reads the raw EDID from a sink.

-

Registering or unregistering a callback for HDMI HPD

-

HdmiRegisterHpdCallbackFunc

-		Registers a callback for HDMI HPD.

-

HdmiUnregisterHpdCallbackFunc

-

Unregisters the callback for HDMI HPD.

-
- -## Usage Guidelines - -### How to Use - -[Figure 2](#fig2) shows how HDMI works. - -**Figure 2** How HDMI works + +| API | Description | +| ----------------------------- | -------------------------- | +| HdmiOpen | Opens an HDMI controller. | +| HdmiClose | Closes an HDMI controller. | +| HdmiStart | Starts HDMI transmission. | +| HdmiStop | Stops HDMI transmission. | +| HdmiAvmuteSet | Sets the AV mute feature. | +| HdmiDeepColorSet | Sets the color depth. | +| HdmiDeepColorGet | Obtains the color depth. | +| HdmiSetVideoAttribute | Sets video attributes. | +| HdmiSetAudioAttribute | Sets audio attributes. | +| HdmiSetHdrAttribute | Sets HDR attributes. | +| HdmiReadSinkEdid | Reads the raw EDID from a sink. | +| HdmiRegisterHpdCallbackFunc | Registers a callback for HDMI HPD.| +| HdmiUnregisterHpdCallbackFunc | Unregisters a callback for HDMI HPD.| + +### How to Develop + +The figure below illustrates the process of using an HDMI device. + +**Figure 2** Process of using an HDMI device ![](figures/HDMI_usage_flowchart.png "HDMI_usage_flowchart") -### Opening an HDMI Controller +#### Opening an HDMI Controller Before HDMI communication, call **HdmiOpen** to open an HDMI controller. @@ -132,38 +85,14 @@ DevHandle HdmiOpen(int16_t number); **Table 2** Description of HdmiOpen - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

number

-

HDMI controller ID.

-

Return Value

-

Description

-

NULL

-

Failed to open the HDMI controller.

-

Controller handle

-

Handle of the HDMI controller opened.

-
- -For example, the system has two HDMI controllers, numbered 0 and 1. Open controller 0. +| Parameter | Description | +| ---------- | -------------------- | +| number | HDMI controller ID. | +| **Return Value**| **Description** | +| NULL | Failed to open the HDMI controller. | +| Controller handle| Handle of the opened HDMI controller.| + +Example: Open controller 0 of the two HDMI controllers (numbered 0 and 1) in the system. ```c DevHandle hdmiHandle = NULL; /* HDMI controller handle / @@ -176,7 +105,7 @@ if (hdmiHandle == NULL) { } ``` -### Registering a Callback for HPD +#### Registering a Callback for HPD ```c int32_t HdmiRegisterHpdCallbackFunc(DevHandle handle, struct HdmiHpdCallbackInfo *callback); @@ -184,41 +113,13 @@ int32_t HdmiRegisterHpdCallbackFunc(DevHandle handle, struct HdmiHpdCallbackInfo **Table 3** Description of HdmiRegisterHpdCallbackFunc - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

callback

-

Pointer to the callback to be invoked to return the HPD result.

-

Return Value

-

Description

-

0

-

The callback is registered successfully.

-

Negative number

-

Failed to register the callback.

-
+| Parameter | Description | +| ---------- | ------------------ | +| handle | HDMI controller handle. | +| callback | Pointer to the callback to be invoked to return the HPD result.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of registering a callback for HPD: @@ -227,30 +128,31 @@ The following is an example of registering a callback for HPD: static void HdmiHpdHandle(void *data, bool hpd) { if (data == NULL) { - HDF_LOGE("priv data is NULL"); - return; -} - + HDF_LOGE("priv data is NULL"); + return; + } if (hpd == true) { HDF_LOGD("HdmiHpdHandle: hot plug"); /* Add related processing if required. */ } else { - HDF_LOGD("HdmiHpdHandle: hot unplog"); + HDF_LOGD("HdmiHpdHandle: hot unplug"); /* Add related processing if required. */ } } - /* Example of registering a callback for HPD */ - struct HdmiHpdCallbackInfo info = {0}; - info.data = handle; - info.callbackFunc = HdmiHpdHandle; - ret = HdmiRegisterHpdCallbackFunc(hdmiHandle, info); - if (ret != 0) { - HDF_LOGE("HdmiRegisterHpdCallbackFunc: Register failed."); - } +/* Example of registering a callback for HPD */ +··· +struct HdmiHpdCallbackInfo info = {0}; +info.data = handle; +info.callbackFunc = HdmiHpdHandle; +ret = HdmiRegisterHpdCallbackFunc(hdmiHandle, info); +if (ret != 0) { + HDF_LOGE("HdmiRegisterHpdCallbackFunc: Register failed."); +} +··· ``` -### Reading the RAW EDID +#### Reading the Raw EDID ```c int32_t HdmiReadSinkEdid(DevHandle handle, uint8_t *buffer, uint32_t len); @@ -258,46 +160,14 @@ int32_t HdmiReadSinkEdid(DevHandle handle, uint8_t *buffer, uint32_t len); **Table 4** Description of HdmiReadSinkEdid - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

buffer

-

Pointer to the data buffer.

-

len

-

Data length.

-

Return Value

-

Description

-

Positive integer

-

Raw EDID read.

-

Negative number or **0**

-

Failed to read the EDID.

-
+| Parameter | Description | +| ---------- | ---------------------- | +| handle | HDMI controller handle. | +| buffer | Pointer to the data buffer. | +| len | Data length. | +| **Return Value**| **Description** | +| Positive integer | Raw EDID read.| +| Negative number or 0 | Failed to read the EDID. | The following is an example of reading the raw EDID from a sink: @@ -311,8 +181,6 @@ if (len <= 0) { } ``` -### Setting Video, Audio, and HDR Attributes - #### Setting Audio Attributes ```c @@ -321,41 +189,14 @@ int32_t HdmiSetAudioAttribute(DevHandle handle, struct HdmiAudioAttr *attr); **Table 5** Description of HdmiSetAudioAttribute - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

attr

-

Pointer to the audio attributes.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ------ | -------------- | +| handle | HDMI controller handle.| +| attr | Pointer to the audio attributes. | +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of setting audio attributes: @@ -382,41 +223,14 @@ int32_t HdmiSetVideoAttribute(DevHandle handle, struct HdmiVideoAttr *attr); **Table 6** Description of HdmiSetVideoAttribute - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

attr

-

Pointer to the video attributes.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| attr | Pointer to the video attributes. | +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of setting video attributes: @@ -442,41 +256,14 @@ int32_t HdmiSetHdrAttribute(DevHandle handle, struct HdmiHdrAttr *attr); **Table 7** Description of HdmiSetHdrAttribute - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

attr

-

Pointer to the HDR attributes.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| attr | Pinter to the HDR attributes. | +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of setting HDR attributes: @@ -495,8 +282,6 @@ if (ret != 0) { } ``` -### Setting Other Attributes - #### Setting HDMI AV Mute ```c @@ -505,41 +290,14 @@ int32_t HdmiAvmuteSet(DevHandle handle, bool enable); **Table 8** Description of HdmiAvmuteSet - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

enable

-

Whether the AV mute feature is enabled. -

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | ----------------- | +| handle | HDMI controller handle. | +| enable | Whether to enable the AV mute feature.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of setting AV mute: @@ -560,41 +318,14 @@ int32_t HdmiDeepColorSet(DevHandle handle, enum HdmiDeepColor color); **Table 9** Description of HdmiDeepColorSet - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

color

-

Color depth to set.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| color | Color depth to set. | +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of setting the color depth: @@ -615,41 +346,14 @@ int32_t HdmiDeepColorGet(DevHandle handle, enum HdmiDeepColor *color); **Table 10** Description of HdmiDeepColorGet - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

color

-

Pointer to the color depth.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| color | Pointer to the color depth. | +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of obtaining the color depth: @@ -663,7 +367,7 @@ if (ret != 0) { } ``` -### Starting HDMI Transmission +#### Starting HDMI Transmission ```c int32_t HdmiStart(DevHandle handle); @@ -671,36 +375,13 @@ int32_t HdmiStart(DevHandle handle); **Table 11** Description of HdmiStart - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of starting HDMI transmission: @@ -713,7 +394,7 @@ if (ret != 0) { } ``` -### Stopping HDMI Transmission +#### Stopping HDMI Transmission ```c int32_t HdmiStop(DevHandle handle); @@ -721,36 +402,13 @@ int32_t HdmiStop(DevHandle handle); **Table 12** Description of HdmiStop - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of stopping HDMI transmission: @@ -763,7 +421,7 @@ if (ret != 0) { } ``` -### Unregistering the Callback for HPD +#### Unregistering the Callback for HPD ```c int32_t HdmiUnregisterHpdCallbackFunc(DevHandle handle); @@ -771,36 +429,13 @@ int32_t HdmiUnregisterHpdCallbackFunc(DevHandle handle); **Table 13** Description of HdmiUnregisterHpdCallbackFunc - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-

Return Value

-

Description

-

0

-

The operation is successful.

-

Negative number

-

The operation failed.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| +| **Return Value**| **Description**| +| 0 | The operation is successful. | +| Negative value | The operation failed. | The following is an example of unregistering the callback for HPD: @@ -813,7 +448,7 @@ if (ret != 0) { } ``` -### Closing an HDMI Controller +#### Closing an HDMI Controller ```c void HdmiClose(DevHandle handle); @@ -821,21 +456,10 @@ void HdmiClose(DevHandle handle); **Table 14** Description of HdmiClose - - - - - - - - - - -

Parameter

-

Description

-

handle

-

HDMI controller handle.

-
+ +| Parameter | Description | +| ---------- | -------------- | +| handle | HDMI controller handle.| The following is an example of closing an HDMI controller: @@ -843,7 +467,7 @@ The following is an example of closing an HDMI controller: HdmiClose(hdmiHandle); ``` -## Example +### Development Example This following example shows how to use HDMI APIs to manage an HDMI device on a Hi3516D V300 development board. @@ -873,7 +497,7 @@ static void HdmiHpdHandle(void *data, bool hpd) HDF_LOGD("HdmiHpdHandle: hot plug"); /* Add related processing if required. */ } else { - HDF_LOGD("HdmiHpdHandle: hot unplog"); + HDF_LOGD("HdmiHpdHandle: hot unplug"); /* Add related processing if required. */ } } diff --git a/en/device-dev/driver/driver-platform-hdmi-develop.md b/en/device-dev/driver/driver-platform-hdmi-develop.md index 0b384358d886aaca37f28251ca2c61d6f11bc64d..56e47fa0bf12ad68ace3f8460e4ed0a5c687f569 100644 --- a/en/device-dev/driver/driver-platform-hdmi-develop.md +++ b/en/device-dev/driver/driver-platform-hdmi-develop.md @@ -1,119 +1,145 @@ # HDMI -## Overview +## Overview -High-Definition Multimedia Interface (HDMI) is an audio/video transmission protocol released by Hitachi, Panasonic, Philips, Silicon Image, Sony, Thomson, and Toshiba. It is used to transmit audio or video data from an audio or video source device, such as a DVD player or STB, to a sink device, such as a TV or monitor. The transmission process complies with the Transition Minimized Differential Signaling (TMDS) protocol. +### HDMI + +High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display. + +### Basic Concepts + +HDMI is an audio and video transmission protocol released by Hitachi, Panasonic, Philips, Silicon Image, Sony, Thomson, and Toshiba. The transmission process complies with the Transition Minimized Differential Signaling (TMDS) protocol. + +- TMDS is used to transmit audio, video, and various auxiliary data. + +- Display data channel (DDC) allows the TX and RX ends to obtain the sending and receiving capabilities. However, the HDMI only needs to unidirectionally obtain the capabilities of the RX end (display). + +- Consumer Electronics Control (CEC) enables interaction between the HDMI TX and RX devices. + +- Fixed rate link (FRL) allows the maximum TMDS bandwidth to be increased from 18 Gbit/s to 48 Gbit/s. +- High-bandwidth Digital Content Protection (HDCP) prevents copying of digital audio and video content being transmitted across devices. + + +### Working Principles In the HDF, the HDMI module uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to process external access requests. After receiving an access request, 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 node for each device, which increases the memory usage. - **Figure 1** Independent service mode + **Figure 1** Independent service mode ![image1](figures/independent-service-mode.png) -## Available APIs +### Constraints - **HdmiCntlrOps**: - ```c - struct HdmiCntlrOps { - void (*hardWareInit)(struct HdmiCntlr *cntlr); - void (*hardWareStatusGet)(struct HdmiCntlr *cntlr, struct HdmiHardwareStatus *status); - void (*controllerReset)(struct HdmiCntlr *cntlr); - bool (*hotPlugStateGet)(struct HdmiCntlr *cntlr); - bool (*hotPlugInterruptStateGet)(struct HdmiCntlr *cntlr); - void (*lowPowerSet)(struct HdmiCntlr *cntlr, bool enable); - void (*tmdsModeSet)(struct HdmiCntlr *cntlr, enum HdmiTmdsModeType mode); - int32_t (*tmdsConfigSet)(struct HdmiCntlr *cntlr, struct HdmiTmdsConfig mode); - void (*infoFrameEnable)(struct HdmiCntlr *cntlr, enum HdmiPacketType infoFrameType, bool enable); - int32_t (*infoFrameSend)(struct HdmiCntlr *cntlr, enum HdmiPacketType infoFrameType, uint8_t *data, uint32_t len); - int32_t (*infoFrameDataSet)(struct HdmiCntlr *cntlr, uint32_t type, uint8_t *data, uint32_t len); - int32_t (*cecMsgSend)(struct HdmiCntlr *cntlr, struct HdmiCecMsg *msg); - void (*audioPathEnable)(struct HdmiCntlr *cntlr, bool enable); - void (*audioPathSet)(struct HdmiCntlr *cntlr, struct HdmiAudioConfigInfo *config); - void (*phyOutputEnable)(struct HdmiCntlr *cntlr, bool enable); - void (*phyOutputSet)(struct HdmiCntlr *cntlr, struct HdmiPhyCfg *cfg); - void (*blackDataSet)(struct HdmiCntlr *cntlr, bool enable); - void (*videoMuteEnable)(struct HdmiCntlr *cntlr, bool enable); - void (*videoPathSet)(struct HdmiCntlr *cntlr, struct HdmiVideoAttr *attr); - void (*audioMuteEnable)(struct HdmiCntlr *cntlr, bool enable); - void (*avmuteSet)(struct HdmiCntlr *cntlr, bool enable); - int32_t (*ddcTransfer)(struct HdmiCntlr *cntlr, struct HdmiDdcCfg *ddcCfg); - bool (*scdcSourceScrambleGet)(struct HdmiCntlr *cntlr); - int32_t (*scdcSourceScrambleSet)(struct HdmiCntlr *cntlr, bool enable); - void (*frlSet)(struct HdmiCntlr *cntlr); - int32_t (*frlEnable)(struct HdmiCntlr *cntlr, bool enable); - int32_t (*audioNctsSet)(struct HdmiCntlr *cntlr, struct HdmiFrlAudioNctsConfig *cfg); - void (*frlTrainingConfigSet)(struct HdmiCntlr *cntlr, struct HdmiFrlTrainConfig *cfg); - void (*frlTrainingStart)(struct HdmiCntlr *cntlr); - void (*frlGetTriningRslt)(struct HdmiCntlr *cntlr, struct HdmiFrlTrainRslt *rslt); - void (*hdcpRegInit)(struct HdmiCntlr *cntlr); - int32_t (*hdcpGenerateAksvAndAn)(struct HdmiCntlr *cntlr); - int32_t (*hdcpOptReg)(struct HdmiCntlr *cntlr, enum HdmiHdcpRegOptType type, uint8_t *data, uint32_t len); - void (*hdrTimerSet)(struct HdmiCntlr *cntlr, struct HdmiHdrTimerConfig *config); - }; - ``` +Currently, the HDMI module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines +### Use Cases + +HDMI features high transmission rate, wide transmission bandwidth, high compatibility, and can transmit uncompressed audio and video signals. Compared with the traditional full analog interface, HDMI simplifies connection between devices and provides HDMI-specific intelligent features, which are ideal for high-quality audio and video transmission of small-sized devices. + +### Available APIs + **HdmiCntlrOps**: +```c +struct HdmiCntlrOps { + void (*hardWareInit)(struct HdmiCntlr *cntlr); + void (*hardWareStatusGet)(struct HdmiCntlr *cntlr, struct HdmiHardwareStatus *status); + void (*controllerReset)(struct HdmiCntlr *cntlr); + bool (*hotPlugStateGet)(struct HdmiCntlr *cntlr); + bool (*hotPlugInterruptStateGet)(struct HdmiCntlr *cntlr); + void (*lowPowerSet)(struct HdmiCntlr *cntlr, bool enable); + void (*tmdsModeSet)(struct HdmiCntlr *cntlr, enum HdmiTmdsModeType mode); + int32_t (*tmdsConfigSet)(struct HdmiCntlr *cntlr, struct HdmiTmdsConfig mode); + void (*infoFrameEnable)(struct HdmiCntlr *cntlr, enum HdmiPacketType infoFrameType, bool enable); + int32_t (*infoFrameSend)(struct HdmiCntlr *cntlr, enum HdmiPacketType infoFrameType, uint8_t *data, uint32_t len); + int32_t (*infoFrameDataSet)(struct HdmiCntlr *cntlr, uint32_t type, uint8_t *data, uint32_t len); + int32_t (*cecMsgSend)(struct HdmiCntlr *cntlr, struct HdmiCecMsg *msg); + void (*audioPathEnable)(struct HdmiCntlr *cntlr, bool enable); + void (*audioPathSet)(struct HdmiCntlr *cntlr, struct HdmiAudioConfigInfo *config); + void (*phyOutputEnable)(struct HdmiCntlr *cntlr, bool enable); + void (*phyOutputSet)(struct HdmiCntlr *cntlr, struct HdmiPhyCfg *cfg); + void (*blackDataSet)(struct HdmiCntlr *cntlr, bool enable); + void (*videoMuteEnable)(struct HdmiCntlr *cntlr, bool enable); + void (*videoPathSet)(struct HdmiCntlr *cntlr, struct HdmiVideoAttr *attr); + void (*audioMuteEnable)(struct HdmiCntlr *cntlr, bool enable); + void (*avmuteSet)(struct HdmiCntlr *cntlr, bool enable); + int32_t (*ddcTransfer)(struct HdmiCntlr *cntlr, struct HdmiDdcCfg *ddcCfg); + bool (*scdcSourceScrambleGet)(struct HdmiCntlr *cntlr); + int32_t (*scdcSourceScrambleSet)(struct HdmiCntlr *cntlr, bool enable); + void (*frlSet)(struct HdmiCntlr *cntlr); + int32_t (*frlEnable)(struct HdmiCntlr *cntlr, bool enable); + int32_t (*audioNctsSet)(struct HdmiCntlr *cntlr, struct HdmiFrlAudioNctsConfig *cfg); + void (*frlTrainingConfigSet)(struct HdmiCntlr *cntlr, struct HdmiFrlTrainConfig *cfg); + void (*frlTrainingStart)(struct HdmiCntlr *cntlr); + void (*frlGetTriningRslt)(struct HdmiCntlr *cntlr, struct HdmiFrlTrainRslt *rslt); + void (*hdcpRegInit)(struct HdmiCntlr *cntlr); + int32_t (*hdcpGenerateAksvAndAn)(struct HdmiCntlr *cntlr); + int32_t (*hdcpOptReg)(struct HdmiCntlr *cntlr, enum HdmiHdcpRegOptType type, uint8_t *data, uint32_t len); + void (*hdrTimerSet)(struct HdmiCntlr *cntlr, struct HdmiHdrTimerConfig *config); +}; +``` + +**Table 1** Description of the HdmiCntlrOps structure + +| Function | Input Parameter | Output Parameter | Return Value | Description | +| ------------------------ | ------------------------------------------------------------ | -------------------------------------- | ------------------ | -------------------------------------------------- | +| hardWareInit | **cntlr**: structure pointer to an HDMI controller at the core layer.| –| –| Initializes the HDMI hardware.| +| hardWareStatusGet | **cntlr**: structure pointer to an HDMI controller at the core layer.
| **status**: pointer to the HDMI hardware status.| –| Obtains the HDMI hardware status. | +| controllerReset | **cntlr**: structure pointer to an HDMI controller at the core layer.| – | –| Resets an HDMI controller. | +| hotPlugStateGet | **cntlr**: structure pointer to an HDMI controller at the core layer. | – | **bool**: HDMI hot-plug status.| Obtains the HDMI hot-plug status. | +| hotPlugInterruptStateGet | **cntlr**: structure pointer to an HDMI controller at the core layer. | – | **bool**: HDMI hot-plug interrupt status.| Obtains the HDMI hot-plug interrupt status. | +| lowPowerSet | **cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable low power consumption.| – | –| Enables or disables low power consumption.| +| tmdsModeSet | **cntlr**: structure pointer to an HDMI controller at the core layer.
**mode**: TMDS mode.| – | –| Sets the TMDS mode. | +|tmdsConfigSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**mode**: TMDS parameters.|–|HDF_STATUS|Sets TMDS parameters.| +|infoFrameEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**infoFrameType**: packet type.
**enable**: whether to enable infoFrame.|–|–|Enables or disables infoFrame.| +|infoFrameSend|**cntlr**: structure pointer to an HDMI controller at the core layer.
**infoFrameType**: packet type.
**data**: pointer to infoFrame data.
**len**: data length.|–|HDF_STATUS|Sends an infoFrame.| +|cecMsgSend|**cntlr**: structure pointer to an HDMI controller at the core layer.
**msg**: pointer to the CEC message|–|HDF_STATUS|Sends a CEC message.| +|audioPathEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the audio path.|–|–|Enables or disables the audio path.| +|audioPathSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**config**: pointer to the audio path configuration.|–|–|Sets the audio path.| +|phyOutputEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the physical layer output.|–|–|Enables or disables the physical layer output.| +|phyOutputSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the physical layer configuration.|–|–|Sets the physical layer information.| +|blackDataSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the black screen.|–|–|Sets the black screen.| +|videoMuteEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the video mute feature.|–|–|Enables or disables the video mute feature.| +|videoPathSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**attr**: pointer to the video path configuration.|–|–|Sets the video path.| +|audioMuteEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the audio mute feature.|–|–|Enables or disables the audio mute feature.| +|avmuteSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the AV mute feature.|–|–|Enables or disables the AV mute feature.| +|ddcTransfer|**cntlr**: structure pointer to an HDMI controller at the core layer.
**ddcCfg**: pointer to the DDC configuration.|**ddcCfg**: DDC configuration.|HDF_STATUS|Reads and writes data through the DDC.| +|scdcSourceScrambleGet|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|Scrambling status of the source.|Obtains the scrambling status of the source.| +|scdcSourceScrambleSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the scrambling for the source.|–|HDF_STATUS|Enables or disable scrambling for the source.| +|frlEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the FRL.|–|HDF_STATUS|Enables or disables the FRL.| +|audioNctsSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the N/CTS configuration.|–|HDF_STATUS|Sets the audio N/CTS information.| +|frlTrainingConfigSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the FRL training configuration.|–|–|Sets FRL training information.| +|frlTrainingStart|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|–|Starts FRL training.| +|frlGetTriningRslt|**cntlr**: structure pointer to an HDMI controller at the core layer.|**rslt**: FRL training result.|–|Obtains the FRL training result.| +|hdcpRegInit|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|–|Initializes registers related to the High-bandwidth Digital Content Protection (HDCP) process.| +|hdcpGenerateAksvAndAn|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|HDF_STATUS|Generates the **Aksv** and **An** in the HDCP process.| +|hdcpOptReg|**cntlr**: structure pointer to an HDMI controller at the core layer.
**type**: operation type.
**data**: register data.
**len**: data length.|**data**: register data.|HDF_STATUS|Reads or writes the registers during the HDCP process.| +|hdrTimerSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**config**: pointer to the timer configuration|–|–|Sets the HDR-related timer.| -**Table 1** APIs for the members in the HdmiCntlrOps structure - | Method| Input Parameter| Output Parameter| Return Value| Description| - | ------------------------ | ------------------------------------------------------------ | -------------------------------------- | ------------------ | -------------------------------------------------- | - | hardWareInit | **cntlr**: structure pointer to an HDMI controller at the core layer.| –| –| Initializes HDMI hardware.| - | hardWareStatusGet | **cntlr**: structure pointer to an HDMI controller at the core layer.
| **status**: pointer to the HDMI hardware status.| –| Obtains the HDMI hardware status.| - | controllerReset | **cntlr**: structure pointer to an HDMI controller at the core layer.| –| –| Resets an HDMI controller.| - | hotPlugStateGet | **cntlr**: structure pointer to an HDMI controller at the core layer.| –| **bool**: HDMI hot-plug status.| Obtains the HDMI hot-plug status.| - | hotPlugInterruptStateGet | **cntlr**: structure pointer to an HDMI controller at the core layer.| –| **bool**: HDMI hot-plug interrupt status.| Obtains the HDMI hot-plug interrupt status.| - | lowPowerSet | **cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable low power consumption.| –| –| Enables or disables low power consumption.| - | tmdsModeSet | **cntlr**: structure pointer to an HDMI controller at the core layer.
**mode**: TMDS mode.| –| –| Sets the TMDS mode. | - |tmdsConfigSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**mode**: TMDS parameters.|–|HDF_STATUS|Sets TMDS parameters.| - |infoFrameEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**infoFrameType**: packet type.
**enable**: whether to enable infoFrame.|–|–|Enables or disables infoFrame.| - |infoFrameSend|**cntlr**: structure pointer to an HDMI controller at the core layer.
**infoFrameType**: packet type.
**data**: pointer to infoFrame data.
**len**: data length.|–|HDF_STATUS|Sends an infoFrame.| - |cecMsgSend|**cntlr**: structure pointer to an HDMI controller at the core layer.
**msg**: pointer to the Consumer Electronics Control (CEC) message.|–|HDF_STATUS|Sends a CEC message.| - |audioPathEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the audio path.|–|–|Enables or disables the audio path.| - |audioPathSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**config**: pointer to the audio path configuration.|–|–|Sets the audio path.| - |phyOutputEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the physical layer output.|–|–|Enables or disables the physical layer output.| - |phyOutputSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the physical layer configuration.|–|–|Sets the physical layer information.| - |blackDataSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the black screen.|–|–|Sets the black screen.| - |videoMuteEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the video mute feature.|–|–|Enables or disables the video mute feature.| - |videoPathSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**attr**: pointer to the video path configuration.|–|–|Sets the video path.| - |audioMuteEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the audio mute feature.|–|–|Enables or disables the audio mute feature.| - |avmuteSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the AV mute feature.|–|–|Enables or disables the AV mute feature.| - |ddcTransfer|**cntlr**: structure pointer to an HDMI controller at the core layer.
**ddcCfg**: pointer to the display data channel (DDC) configuration.|**ddcCfg**: DDC configuration.|HDF_STATUS|Reads and writes data through the DDC.| - |scdcSourceScrambleGet|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|Scrambling status of the source.|Obtains the scrambling status of the source.| - |scdcSourceScrambleSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable scrambling for the source.|–|HDF_STATUS|Enables or disable scrambling for the source.| - |frlEnable|**cntlr**: structure pointer to an HDMI controller at the core layer.
**enable**: whether to enable the fixed rate link (FRL).|–|HDF_STATUS|Enables or disables the FRL.| - |audioNctsSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the N/CTS configuration.|–|HDF_STATUS|Sets the audio N/CTS information.| - |frlTrainingConfigSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**cfg**: pointer to the FRL training configuration.|–|–|Sets FRL training information.| - |frlTrainingStart|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|–|Starts FRL training.| - |frlGetTriningRslt|**cntlr**: structure pointer to an HDMI controller at the core layer.|**rslt**: FRL training result.|–|Obtains the FRL training result.| - |hdcpRegInit|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|–|Initializes registers related to the High-bandwidth Digital Content Protection (HDCP) process.| - |hdcpGenerateAksvAndAn|**cntlr**: structure pointer to an HDMI controller at the core layer.|–|HDF_STATUS|Generates the **Aksv** and **An** in the HDCP process.| - |hdcpOptReg|**cntlr**: structure pointer to an HDMI controller at the core layer.
**type**: operation type.
**data**: pointer to the register data.
**len**: data length.|**data**: register data.|HDF_STATUS|Reads or writes the registers in the HDCP process.| - |hdrTimerSet|**cntlr**: structure pointer to an HDMI controller at the core layer.
**config**: pointer to the timer configuration.|–|–|Sets the HDR-related timer.| - - -## How to Develop + +### How to Develop The HDMI module adaptation involves the following steps: -1. Instantiate the driver entry. +- Instantiate the driver entry. - Instantiate the **HdfDriverEntry** structure. - Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF. -2. Configure attribute files. +- Configure attribute files. - Add the **deviceNode** information to the **device_info.hcs** file. - (Optional) Add the **hdmi_config.hcs** file. -3. Instantiate the HDMI controller object. +- Instantiate the HDMI controller object. - Initialize **HdmiCntlr**. - - Instantiate **HdmiCntlrOps** in **HdmiCntlr**. For details, see [Available APIs](#available_apis). - + - Instantiate **HdmiCntlrOps** in **HdmiCntlr**. -## Development Example +1. Instantiate the driver entry. -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 are collected to form a segment address space similar to an array for the upper layer to invoke. + The driver entry must be a global variable of the **HdfDriverEntry** type (which is 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, the HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit. + Generally, the HDF calls the **Bind()** function and then the **Init()** function to load a driver. If **Init()** fails to be called, the HDF calls **Release()** to release driver resources and exit. HDMI driver entry reference: @@ -128,7 +154,9 @@ The HDMI module adaptation involves the following steps: HDF_INIT(g_hdmiDriverEntry); // Call HDF_INIT to register the driver entry with the HDF. ``` -2. Add **deviceNode** to the **device_info.hcs** file, and configure the device attributes in the **hdmi\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or restriction ranges of the **HdmiCntlr** members at the core layer. +2. Configure attribute files. + + Add **deviceNode** to the **device_info.hcs** file, and configure the device attributes in the **hdmi\_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the driver implementation and the default values or restriction ranges of the **HdmiCntlr** members at the core layer. Configure HDMI controller information from the first node. This node specifies a type of HDMI controllers rather than a specific HDMI controller. In this example, there is only one HDMI controller. If there are multiple HDMI controllers, you need to add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **hdmi\_config** file. @@ -200,14 +228,15 @@ The HDMI module adaptation involves the following steps: } ``` -3. Initialize the **HdmiCntlr** object at the core layer, including initializing the vendor custom structure (passing parameters and data) and instantiating the **HdmiCntlrOps** (used to call the underlying functions of the driver). The **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**) must be implemented in this step. - - - Custom structure reference: - - > ![](../public_sys-resources/icon-note.gif) **NOTE** - > +3. Instantiate the **HdmiCntlr** object. + + Initialize the **HdmiCntlr** object at the core layer, including initializing the vendor custom structure (passing parameters and data) and instantiating the **HdmiCntlrOps** (used to call the underlying functions of the driver). The **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**) must be implemented in this step. + + - Custom structure reference + + > ![](../public_sys-resources/icon-note.gif) **NOTE**
> To the driver, the custom structure carries parameters and data. The values in the **hdmi_config.hcs** file are read by the HDF, and structure members are initialized by **DeviceResourceIface**. Some important values (such as the device number and bus number) are also passed to the **HdmiCntlr** object at the core layer. - + ```c struct HdmiAdapterHost { struct HdmiCntlr *cntlr; // (Mandatory) Control object at the core layer. The details are as follows: @@ -216,8 +245,8 @@ The HDMI module adaptation involves the following steps: uint32_t regSize; // (Mandatory) Register bit width. uint32_t irqNum; // (Mandatory) IRQ number. }; - - /* HdmiCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function. */ + + /* HdmiCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init() function. */ struct HdmiCntlr { struct IDeviceIoService service; struct HdfDeviceObject *hdfDevObj; @@ -242,9 +271,9 @@ The HDMI module adaptation involves the following steps: void *priv; }; ``` - - - **(Important)** Instantiate the callback structure **HdmiCntlrOps** in **HdmiCntlr**. - + + - Instantiate **HdmiCntlrOps** in **HdmiCntlr**. + ```c static struct HdmiCntlrOps g_hdmiAdapterHostOps = { .hardWareInit = HdmiAdapterHardWareInit, @@ -283,29 +312,29 @@ The HDMI module adaptation involves the following steps: .hdrTimerSet = HdmiAdapterHdrTimerSet, }; ``` - - - **Bind** function - - > Input parameter: - > **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - > - > Return value: - > **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** definition in the **/drivers/framework/include/utils/hdf\_base.h file**.) - - |State|Description| + + - **Bind()** function + + **Input parameter**: + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. + + **Return value**: + **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** definition in the **/drivers/framework/include/utils/hdf\_base.h file**.) + + | State | Description | |:-|:-| |HDF_ERR_INVALID_OBJECT|Invalid controller object.| - |HDF_ERR_INVALID_PARAM |Invalid parameter.| - |HDF_ERR_MALLOC_FAIL |Failed to allocate memory.| + |HDF_ERR_INVALID_PARAM|Invalid parameter.| + |HDF_ERR_MALLOC_FAIL |Memory allocation failed.| |HDF_ERR_IO |I/O error.| |HDF_SUCCESS |Transmission successful.| |HDF_FAILURE |Transmission failed.| - - > Function description: - > Initializes the custom structure object **HdmiAdapterHost** and **HdmiCntlr**, and calls the **HdmiCntlrAdd** function to add the HDMI controller to the core layer. - > - > The **HdmiCntlr**, **HdmiAdapterHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully. - + + **Function description**: + Initializes the custom structure object **HdmiAdapterHost** and **HdmiCntlr**, and calls the **HdmiCntlrAdd** function to add the HDMI controller to the core layer. + + The **HdmiCntlr**, **HdmiAdapterHost**, and **HdfDeviceObject** assign values with each other so that other functions can be converted successfully. + ```c static int32_t HdmiAdapterBind(struct HdfDeviceObject *obj) { @@ -342,45 +371,47 @@ The HDMI module adaptation involves the following steps: return ret; } ``` - - - **Init** function - - >Input parameter: - >**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - > - >Return value: - >HDF_STATUS - > - >Function description: - > - >Implements the **HdmiAdapterInit** function. - + + - **Init()** function + + **Input parameter**: + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. + + **Return value**: + HDF_STATUS + + **Function description**: + + Implements the **HdmiAdapterInit** function. + ```c static int32_t HdmiAdapterInit(struct HdfDeviceObject *obj) { return HDF_SUCCESS; } ``` - - - **Release** function - - > Input parameter: - > **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - > - > Return value: - > – - > - > Function description: - > Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. - + + - **Release()** function + + **Input parameter**: + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. + + **Return value**: + – + + **Function description**: + Releases the memory and deletes the controller. This function assigns a value to the **Release()** API in the driver entry structure. If the HDF fails to call the **Init()** function to initialize the driver, the **Release()** function can be called to release driver resources. + ```c static void HdmiAdapterRelease(struct HdfDeviceObject *obj) { struct HdmiCntlr *cntlr = NULL; ... - cntlr = (struct MmcCntlr *)obj->service;// Forcibly convert HdfDeviceObject to HdmiCntlr by using service. For details about the value assignment, see the Bind function. + cntlr = (struct MmcCntlr *)obj->service;// Forcibly convert HdfDeviceObject to HdmiCntlr by using service. For details about the value assignment, see the Bind() function. ... HimciDeleteHost((struct HimciAdapterHost *)cntlr->priv);// Memory release function customized by the vendor. A forced conversion from HdmiCntlr to HimciAdapterHost is involved in the process. } ``` - > All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations. + + > ![](../public_sys-resources/icon-note.gif) **NOTE**
+ > All forced conversion operations for obtaining the corresponding object can be successful only when the **Init()** function has the corresponding value assignment operations. diff --git a/en/device-dev/driver/driver-platform-i3c-des.md b/en/device-dev/driver/driver-platform-i3c-des.md index 23c5074fd467b179dd648f2371f7fa0880af4c7b..555bc6eaebf26723f4481f129ccecd37fc696589 100644 --- a/en/device-dev/driver/driver-platform-i3c-des.md +++ b/en/device-dev/driver/driver-platform-i3c-des.md @@ -225,7 +225,7 @@ if (ret != 2) { } ``` ->![](./public_sys-resources/icon-caution.gif) **Caution** +>![](../public_sys-resources/icon-caution.gif) **Caution** > >- The device address in the **I3cMsg** structure does not contain the read/write flag bit. The read/write information is passed by the read/write control bit in the member variable **flags**. >- The **I3cTransfer()** function does not limit the number of message structures or the length of data in each message structure. The I3C controller determines these two limits. diff --git a/en/device-dev/driver/driver-platform-i3c-develop.md b/en/device-dev/driver/driver-platform-i3c-develop.md index c47b24c2987e02659db151cfdf0307d6afad4d01..e21de4f0cc61b257bf87c4171622e44b5dd37e50 100644 --- a/en/device-dev/driver/driver-platform-i3c-develop.md +++ b/en/device-dev/driver/driver-platform-i3c-develop.md @@ -164,9 +164,9 @@ The I3C module adaptation involves the following steps: ```c struct VirtualI3cCntlr { - struct AdcDevice device;// (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr. + struct I3cCntlr cntlr; // (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr. volatile unsigned char *regBase;// (Mandatory) Register base address. - uint32_t regBasePhy; // (Mandatory) Physical base address of the register. + uint32_t regBasePhy; // (Mandatory) Physical base address of the register. uint32_t regSize; // (Mandatory) Bit width of the register. uint16_t busId; // (Mandatory) Device number. uint16_t busMode; diff --git a/en/device-dev/driver/driver-platform-pin-des.md b/en/device-dev/driver/driver-platform-pin-des.md new file mode 100644 index 0000000000000000000000000000000000000000..91e05c5f19e3d1ba81106fe17daee2cb56e04b9e --- /dev/null +++ b/en/device-dev/driver/driver-platform-pin-des.md @@ -0,0 +1,409 @@ +# Pin + + +## Overview + +### Pin + +- The pin, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function. +- The pin module defines a set of common methods for managing pins, including: + - Obtaining or releasing the pin description handle: The kernel compares the pin name passed in with the pin names of each controller in the linked list. If a match is found, a pin description handle is obtained. After the operation on the pin is complete, the pin description handle will be released. + - Setting or obtaining the pull type of a pin: The pull type can be pull-up, pull-down, or floating. + - Setting or obtaining the pull strength of a pin: You can set the pull strength as required. + - Setting or obtaining the functions of a pin to implement pin multiplexing + +### Basic Concepts +Pin, as a software concept, provides APIs for uniformly managing the pins from different SoC vendors, providing the pin multiplexing function, and configuring the electrical features of pins. + +- SoC + + An SOC is a chip that integrates microprocessors, analog IP cores, digital IP cores, and memory for specific purposes. + +- Pin multiplexing + + When the number of pins of a chip cannot handle the increasing connection requests, you can set the software registers to make the pins to work in different states. + +### Working Principles + +In the HDF, the pin module does not support the user mode and therefore does not need to publish services. It uses the service-free mode in interface adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS that does not distinguish the user mode and the kernel mode. The **DevHandle**, a void pointer, directly points to the kernel mode address of the device object. + +The pin module is divided into the following layers: +- Interface layer: provides APIs for obtaining a pin, setting or obtaining the pull type, pull strength, and functions of a pin, and releasing a pin. +- Core layer: provides the capabilities of matching pin resources and adding, removing, and managing pin controllers. The core layer interacts with the adaptation layer by using hooks. +- Adaptation layer: instantiates hooks to implement specific functions. + +**Figure 1** Service-free mode +![](figures/service-free-mode.png "pin service-free mode") + +### Constraints + + Currently, the pin module supports only the kernels (LiteOS) of mini and small systems. + + ## Usage Guidelines + + ### When to Use + + The pin module is a software concept and is used to manage pin resources. You can set the functions, pull type, and pull strength of pins to implement pin multiplexing. + +### Available APIs + +The table below describes the APIs of the pin module. For more details, see API Reference. + +**Table 1** Pin driver APIs + + +| **API** | **Description** | +| ------------------------------------------------------------ | ---------------- | +| DevHandle PinGet(const char *pinName); | Obtains the pin description handle.| +| void PinPut(DevHandle handle); | Releases the pin description handle.| +| int32_t PinSetPull(DevHandle handle, enum PinPullType pullType); | Sets the pull type of a pin.| +| int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType); | Obtains the pull type of a pin.| +| int32_t PinSetStrength(DevHandle handle, uint32_t strength); | Sets the pull strength of a pin.| +| int32_t PinGetStrength(DevHandle handle, uint32_t *strength); | Obtains the pull strength of a pin.| +| int32_t PinSetFunc(DevHandle handle, const char *funcName); | Sets the pin function. | +| int32_t PinGetFunc(DevHandle handle, const char **funcName); | Obtains the pin functions. | + +>![](../public_sys-resources/icon-note.gif) **NOTE**
+>All APIs described in this document can be called only in the kernel space. + +### How to Develop + +The figure below shows the process. + + **Figure 2** Process of using the pin module +![](figures/process-of-using-pin.png "Process of using the pin module") + +#### Obtaining the Pin Description Handle + +Before performing an operation on a pin, call **PinGet** to obtain the pin description handle. This API returns the pin description handle that matches the input pin name. + +``` +DevHandle PinGet(const char *pinName); +``` + +**Table 2** Description of PinGet + + + +| Parameter | Description | +| ---------- | ----------------------- | +| pinName | Pointer to the pin name. | +| **Return Value**| **Description** | +| NULL | Failed to obtain the pin description handle.| +| handle | Pin description handle obtained. | + +Example: Obtain the handle of P18. + +``` +DevHandle handle = NULL; /* Pin description handle */ +char pinName = "P18"; /* Pin name. */ +handle = PinGet(pinName); +if (handle == NULL) { + HDF_LOGE("PinGet: get handle failed!\n"); + return; +} +``` + +#### Setting the Pull Type of a Pin + +Call **PinSetPull** to set the pull type of a pin. + +``` +int32_t PinSetPull(DevHandle handle, enum PinPullType pullType); +``` + +**Table 3** Description of PinSetPull + + + +| Parameter | Description | +| ---------- | ----------------------- | +| handle | Pin description handle. | +| pullType | Pull type to set. | +| **Return Value**| **Description** | +| 0 | The operation is successful.| +| Negative value | The operation fails.| + +Example: Set the pull type to pull-up. + +``` +int32_t ret; +enum PinPullType pullTypeNum; +/* Set the pull type of a pin. */ +pullTypeNum = 1; +ret = PinSetPull(handle, pullTypeNum); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetPull: failed, ret %d\n", ret); + return ret; +} +``` + +#### Obtaining the Pull Type of a Pin + +Call **PinGetPull** to obtain the pull type of a pin. + +``` +int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType); +``` + +**Table 4** Description of PinGetPull + + + +| Parameter | Description | +| ---------- | ------------------------- | +| handle | Pin description handle. | +| pullType | Pointer to the pull type obtained.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation fails. | + +Example: Obtain the pull type of a pin. + +``` +int32_t ret; +enum PinPullType pullTypeNum; +/* Obtain the pull type of a pin. */ +ret = PinGetPull(handle, &pullTypeNum); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetPull: failed, ret %d\n", ret); + return ret; +} +``` + +#### Setting the Pull Strength of a Pin + +Call **PinSetStrength** to set the pull type of a pin. + +``` +int32_t PinSetStrength(DevHandle handle, uint32_t strength); +``` + +**Table 5** Description of PinSetStrength + + + +| Parameter | Description | +| ---------- | ----------------------- | +| handle | Pin description handle. | +| strength | Pull strength to set. | +| **Return Value**| **Description** | +| 0 | The operation is successful.| +| Negative value | The operation fails.| + +Example: Set the pull strength of the pin to 2. + +``` +int32_t ret; +uint32_t strengthNum; +/* Set the pull strength of the pin. */ +strengthNum = 2; +ret = PinSetStrength(handle, strengthNum); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetStrength: failed, ret %d\n", ret); + return ret; +} +``` + +#### Obtaining the Pull Strength of a Pin + +Call **PinGetStrength** to obtain the pull strength set. + +``` +int32_t PinGetStrength(DevHandle handle, uint32_t *strength); +``` + +**Table 6** Description of PinGetStrength + + + +| Parameter | Description | +| ---------- | ------------------------- | +| handle | Pin description handle. | +| strength | Pointer to the pull strength obtained.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation fails. | + +Example: Obtain the pull strength of a pin. + +``` +int32_t ret; +uint32_t strengthNum; +/* Obtain the pull strength of the pin. */ +ret = PinGetStrength(handle, &strengthNum); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetStrength: failed, ret %d\n", ret); + return ret; +} +``` + +#### Setting the Pin Function + +The pin function refers to the pin multiplexing function. The function of each pin is different. For details about the pin functions, see [pin_config.hcs](https://gitee.com/openharmony/device_soc_hisilicon/blob/master/hi3516dv300/sdk_liteos/hdf_config/pin/pin_config.hcs). + +Call **PinSetFunc** to set the pin function. + +``` +int32_t PinSetFunc(DevHandle handle, const char *funcName); +``` + +**Table 7** Description of PinSetFunc + + + +| Parameter | Description | +| ---------- | ------------------- | +| handle | Pin description handle. | +| funcName | Pointer to the pin function to set. | +| **Return Value**| **Description** | +| 0 | The operation is successful.| +| Negative value | The operation fails.| + +Example: Set the pin function to LSADC_CH1 (ADC channel 1). + +``` +int32_t ret; +char funcName = "LSADC_CH1"; +/* Sets the pin function. */ +ret = PinSetFunc(handle, funcName); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetFunc: failed, ret %d\n", ret); + return ret; +} +``` + +#### Obtaining the Pin Function + +Call **PinGetFunc** to obtain the pin function set. + +``` +int32_t PinGetFunc(DevHandle handle, const char **funcName); +``` + +**Table 8** Description of PinGetFunc + + + +| Parameter | Description | +| ---------- | --------------------- | +| handle | Pin description handle. | +| funcName | Pointer to the function name obtained.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative value | The operation fails. | + +Example: Obtain the pin function. + +``` +int32_t ret; +char *funcName; +/* Obtain the pin function. */ +ret = PinGetFunc(handle,&funcName); +if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetFunc: failed, ret %d\n", ret); + return ret; +} +``` + +#### Releasing a Pin Description Handle + +After the operations on a pin are complete, call **PinPut** to release the pin description handle. + +``` +void PinPut(DevHandle handle); +``` + +**Table 9** Description of PinPut + + + +| Parameter | Description | +| ---------- | -------------- | +| handle | Pin description handle. | +| **Return Value**| **Description**| +| NA | No value is returned. | + +Example: Release a pin description handle. + +``` +PinPut(handle); +``` + +## Development Example + +The procedure is as follows: +1. Pass in the pin name to obtain the pin description handle. +2. Set the pull type of the pin. If the operation fails, release the pin description handle. +3. Obtain the pull type of the pin. If the operation fails, release the pin description handle. +4. Set the pull strength of the pin. If the operation fails, release the pin description handle. +5. Obtain the pin pull strength. If the operation fails, release the pin description handle. +5. Set the pin function. If the operation fails, release the pin description handle. +6. Obtain the pin function. If the operation fails, release the pin description handle. +7. Release the pin description handle if no operation needs to be performed on the pin. + +``` +#include "hdf_log.h" /* Header file for log APIs */ +#include "pin_if.h" /* Header file for standard pin APIs */ + +int32_t PinTestSample(void) +{ + int32_t ret; + uint32_t strengthNum; + enum PinPullType pullTypeNum; + char pinName; + char *funName; + DevHandle handle = NULL; + + /* Pin name. Set it to the actual pin name. */ + pinName = "P18"; + /* Obtain the pin description handle. */ + handle = PinGet(pinName); + if (handle == NULL) { + HDF_LOGE("PinGet: failed!\n"); + return; + } + /* Set the pull type to pull-up for the pin. */ + pullTypeNum = 1; + ret = PinSetPull(handle, pullTypeNum); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetPull: failed, ret %d\n", ret); + goto ERR; + } + /* Obtain the pull type of the pin. */ + ret = PinGetPull(handle, &pullTypeNum); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetPull: failed, ret %d\n", ret); + goto ERR; + } + /* Set the pull strength of the pin to 2. */ + strengthNum = 2; + ret = PinSetStrength(handle, strengthNum); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetStrength: failed, ret %d\n", ret); + goto ERR; + } + /* Obtain the pull strength of the pin. */ + ret = PinGetStrength(handle, &strengthNum); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetStrength: failed, ret %d\n", ret); + goto ERR; + } + /* Set the pin function to LSADC_CH1. */ + funName = "LSADC_CH1"; + ret = PinSetFunc(handle, funName); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinSetFunc: failed, ret %d\n", ret); + goto ERR; + } + /* Obtain the pin function. */ + ret = PinGetFunc(handle, &funcName); + if (ret != HDF_SUCCESS) { + HDF_LOGE("PinGetFunc: failed, ret %d\n", ret); + goto ERR; + } +ERR: + /* Release the pin description handle. */ + PinPut(handle); + return ret; +} diff --git a/en/device-dev/driver/driver-platform-pin-develop.md b/en/device-dev/driver/driver-platform-pin-develop.md index 06f511e5ce281c67aeda127375de1f02f12153b9..76e2634ed9ac9e5da8012b9cec9a87c1c75b0b19 100644 --- a/en/device-dev/driver/driver-platform-pin-develop.md +++ b/en/device-dev/driver/driver-platform-pin-develop.md @@ -1,16 +1,51 @@ -# Pin +# Pin -## Overview +## Overview -The pin module controls the states and functionalities of system pins. In the Hardware Driver Foundation (HDF), the pin module uses the service-free mode for API adaptation. The service-free mode applies to 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. +### Pin +The pin, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function. -Figure 1 Service-free mode -![image1](figures/service-free-mode.png "service-free-mode") +### Basic Concepts -## Available APIs +Pin, as a software concept, provides APIs for uniformly managing the pins from different SoC vendors, providing the pin multiplexing function, and configuring the electrical features of pins. -**PinCntlrMethod**: +- SoC + + An SOC is a chip that integrates microprocessors, analog IP cores, digital IP cores, and memory for specific purposes. + +- Pin multiplexing + + When the number of pins of a chip cannot handle the increasing connection requests, you can set the software registers to make the pins to work in different states. + +### Working Principles + +In the HDF, the pin module does not support the user mode and therefore does not need to publish services. It uses the service-free mode in interface adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS that does not distinguish the user mode and the kernel mode. The **DevHandle**, a void pointer, directly points to the kernel mode address of the device object. + +The pin module is divided into the following layers: + +- Interface layer: provides APIs for obtaining a pin, setting or obtaining the pull type, pull strength, and functions of a pin, and releasing a pin. +- Core layer: provides the capabilities of matching pin resources and adding, removing, and managing pin controllers. The core layer interacts with the adaptation layer by using hooks. +- Adaptation layer: instantiates hooks to implement specific functions. + +**Figure 1** Service-free mode + +![](figures/service-free-mode.png) + +### Constraints + +Currently, the pin module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines + +### When to Use + +The pin module is used to manage pin resources. When the devices from SoC vendors interconnect with the HDF, the pin driver needs to be adapted. + +### Available APIs + +The **PinCntlrMethod** APIs are used to call the functions of the pin driver. +**PinCntlrMethod** definition: ```c struct PinCntlrMethod { @@ -25,290 +60,370 @@ struct PinCntlrMethod { **Table 1** APIs for the members in the PinCntlrMethod structure -| API | Input Parameter | Return Value| Description| -| ------------ | ------------------------------------------- | ------ | ---- | -| SetPinPull | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**pullType**: pull type of the pin. It is an enum constant.|HDF_STATUS|Sets the pull type of a pin.| -| GetPinPull | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**pullType**: pointer to the pull type of the pin.| HDF_STATUS| Obtains the pull type of a pin.| -| SetPinStrength | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**strength**: pull strength of the pin. It is a uint32_t variable.| HDF_STATUS| Sets the pull strength of a pin.| -| GetPinStrength | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**strength**: pointer to the pull strength of the pin.| HDF_STATUS| Obtains the pull strength of a pin.| -| SetPinFunc | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**funcName**: char pointer to the pin functionality.| HDF_STATUS| Sets the pin functionality.| -| GetPinFunc | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**funcName**: char double pointer to the pin functionality.| HDF_STATUS| Obtains the pin functionalities.| +| API | Input Parameter | Output Parameter | Return Value| Description| +| ------------ | ------------------------------------------- | ------ | ---- | ---- | +| SetPinPull | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**pullType**: pull type of the pin. It is an enum constant.| -|HDF_STATUS|Sets the pull type of a pin.| +| GetPinPull | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.| **pullType**: pointer to the pull type of the pin.| HDF_STATUS| Obtains the pull type of a pin.| +| SetPinStrength | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**strength**: pull strength of the pin. It is a uint32_t variable.| -| HDF_STATUS| Sets the pull strength of a pin.| +| GetPinStrength | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.| **strength**: pointer to the pull strength of the pin.| HDF_STATUS| Obtains the pull strength of a pin.| +| SetPinFunc | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.
**funcName**: char pointer to the pin function.| -| HDF_STATUS| Sets the pin function.| +| GetPinFunc | **cntlr**: structure pointer to the pin controller at the core layer.
**index**: pin index, which is a uint32_t variable.| **funcName**: char double pointer to the pin function.| HDF_STATUS| Obtains the pin function.| + +### How to Develop -## How to Develop +The pin module adaptation procedure is as follows: -The pin module adaptation involves the following steps: +- Instantiate the driver entry. +- Configure attribute files. +- Instantiate the core layer APIs. +- Debug the driver. 1. Instantiate the driver entry. - + - Instantiate the **HdfDriverEntry** structure. + 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**. + - Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF. - -2. Configure attribute files. + Generally, the HDF calls the **Init()** function to load the driver. If **Init()** fails to be called, the HDF calls **Release()** to release driver resources and exit. - - Add the **deviceNode** information to the **device_info.hcs** file. - - (Optional) Add the **pin_config.hcs** file. + ```c + static struct HdfDriverEntry g_hi35xxPinDriverEntry = { + .moduleVersion = 1, + .Bind = Hi35xxPinBind, + .Init = Hi35xxPinInit, + .Release = Hi35xxPinRelease, + .moduleName = "hi35xx_pin_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file. + }; + HDF_INIT(g_hi35xxPinDriverEntry);// Call HDF_INIT to register the driver entry with the HDF. + ``` + +2. Configure attribute files. + - Add the device node description to the **vendor/hisilicon/hispark_taurus/hdf_config/device_info/device_info.hcs** file. + ```c + root { + device_info { + platform :: host { + hostName = "platform_host"; + priority = 50; + device_pin :: device { + device0:: deviceNode { // Set an HDF device node for each pin controller. + policy = 0; // 2: visible in user mode; 1: visible in kernel mode; 0: no service required. + priority = 10; // Driver startup priority. + permission = 0644; // Permission to create device nodes for the driver. + /* (Mandatory) Driver name, which must be the same as the moduleName in the driver entry. */ + moduleName = "hi35xx_pin_driver"; + /* (Mandatory) Set the controller private data, which must be same as that in pin_config.hcs. */ + deviceMatchAttr = "hisilicon_hi35xx_pin_0"; + } + device1 :: deviceNode { + policy = 0; + priority = 10; + permission = 0644; + moduleName = "hi35xx_pin_driver"; + deviceMatchAttr = "hisilicon_hi35xx_pin_1"; + } + ...... + } + } + } + } + ``` + - Add the **pin_config.hcs** file. + Configure the device attributes in the **device/soc/hisilicon/hi3516dv300/sdk_liteos/hdf_config/pin/pin_config.hcs** file. The parameters are set as follows: + ```c + root { + platform { + pin_config_hi35xx { + template pin_controller { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by device nodes. + number = 0; // (Mandatory) Controller ID. + regStartBasePhy = 0; // (Mandatory) Start physical base address of the register. + regSize = 0; // (Mandatory) Register bit width. + PinCount = 0; // (Mandatory) Number of pins. + match_attr = ""; + template pin_desc { + pinName = ""; // (Mandatory) Name of the pin. + init = 0; // (Mandatory) Default value of the register. + F0 = ""; // (Mandatory) Function 0. + F1 = ""; // Function 1. + F2 = ""; // Function 2. + F3 = ""; // Function 3. + F4 = ""; // Function 4. + F5 = ""; // Function 5. + } + } + controller_0 :: pin_controller { + number = 0; + regStartBasePhy = 0x10FF0000; + regSize = 0x48; + pinCount = 18; + match_attr = "hisilicon_hi35xx_pin_0"; + T1 :: pin_desc { + pinName = "T1"; + init = 0x0600; + F0 = "EMMC_CLK"; + F1 = "SFC_CLK"; + F2 = "SFC_BOOT_MODE"; + } + ...... // Correspond to the pins of the pin controller. Add pins according to actual situation. + } + ...// Each pin controller corresponds to a controller node. If there are multiple pin controllers, add the corresponding controller nodes one by one. + } + } + } + ``` 3. Instantiate the pin controller object. - - Initialize the **PinCntlr** object. - - - Instantiate **PinCntlrMethod** in the **PinCntlr** object. - - >![](../public_sys-resources/icon-note.gif) **NOTE** + Call **Hi35xxPinCntlrInit** to initialize the **PinCntlr** members. + + ```c + struct Hi35xxPinDesc { + // Pin name. + const char *pinName; + // Initial value. + uint32_t init; + // Index of the pin. + uint32_t index; + // Pull type of the pin. + int32_t pullType; + // Pull strength of the pin. + int32_t strength; + // Array of pin function names. + const char *func[HI35XX_PIN_FUNC_MAX]; + }; - >For details, see [Available APIs](#section2_PINDevelop). - -4. Debug the driver. - - - (Optional) Verify basic functionalities of new drivers. For example, verify the information returned when the driver is loaded and whether data is successfully transmitted. + struct Hi35xxPinCntlr { + // Pin controller. + struct PinCntlr cntlr; + // Pointer to the pin description structure. + struct Hi35xxPinDesc *desc; + // Register mapping address. + volatile unsigned char *regBase; + // ID of the pin controller. + uint16_t number; + // Start address of the register physical base addresses. + uint32_t regStartBasePhy; + // Register bit width. + uint32_t regSize; + // Number of pins. + uint32_t pinCount; + }; + + // PinCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init() function. + struct PinCntlr { + struct IDeviceIoService service; + struct HdfDeviceObject *device; + struct PinCntlrMethod *method; + struct DListHead node; // Node in the linked list. + OsalSpinlock spin; // Spinlock. + uint16_t number; // ID of the pin controller. + uint16_t pinCount; // Number of pins. + struct PinDesc *pins; + void *priv; // Private data. + }; + + // Initialize PinCntlr. + static int32_t Hi35xxPinCntlrInit(struct HdfDeviceObject *device, struct Hi35xxPinCntlr *hi35xx) + { + struct DeviceResourceIface *drsOps = NULL; + int32_t ret; + // Read the pin controller attributes from the .hcs file. + drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE); + if (drsOps == NULL || drsOps->GetUint32 == NULL || drsOps->GetUint16 == NULL) { + HDF_LOGE("%s: invalid drs ops fail!", __func__); + return HDF_FAILURE; + } + ret = drsOps->GetUint16(device->property, "number", &hi35xx->number, 0); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read number failed", __func__); + return ret; + } + + ret = drsOps->GetUint32(device->property, "regStartBasePhy", &hi35xx->regStartBasePhy, 0); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read regStartBasePhy failed", __func__); + return ret; + } + ret = drsOps->GetUint32(device->property, "regSize", &hi35xx->regSize, 0); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read regSize failed", __func__); + return ret; + } + ret = drsOps->GetUint32(device->property, "pinCount", &hi35xx->pinCount, 0); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read pinCount failed", __func__); + return ret; + } + // Assign the values read to the members of the pin controller to initialize the pin controller. + hi35xx->cntlr.pinCount = hi35xx->pinCount; + hi35xx->cntlr.number = hi35xx->number; + hi35xx->regBase = OsalIoRemap(hi35xx->regStartBasePhy, hi35xx->regSize); // Pin controller mapping. + if (hi35xx->regBase == NULL) { + HDF_LOGE("%s: remap Pin base failed", __func__); + return HDF_ERR_IO; + } + hi35xx->desc = (struct Hi35xxPinDesc *)OsalMemCalloc(sizeof(struct Hi35xxPinDesc) * hi35xx->pinCount); + hi35xx->cntlr.pins = (struct PinDesc *)OsalMemCalloc(sizeof(struct PinDesc) * hi35xx->pinCount); + return HDF_SUCCESS; + } + ``` -## Development Example + - Instantiate the callback structure **PinCntlrMethod** in **PinCntlr**. Other members are initialized by using the **Init()** function. -The following uses **pin_hi35xx.c** as an example to present the content to be provided by the vendor to implement device functionalities. + ```c + // The members of the PinCntlrMethod structure are all callbacks. Vendors need to implement the corresponding functions according to Table 1. + static struct PinCntlrMethod g_method = { + .SetPinPull = Hi35xxPinSetPull, // Set the pull type. + .GetPinPull = Hi35xxPinGetPull, // Obtains the pull type. + .SetPinStrength = Hi35xxPinSetStrength, // Set the pull strength. + .GetPinStrength = Hi35xxPinGetStrength, // Obtains the pull strength. + .SetPinFunc = Hi35xxPinSetFunc, // Set the pin functions. + .GetPinFunc = Hi35xxPinGetFunc, // Obtain the pin 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 are collected to form a segment address space similar to an array for the upper layer to invoke. + - **Init()** function - Generally, the HDF calls the **Bind** function and then the **Init** function to load the driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit. + Input parameters: + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information. - Pin driver entry reference: + Return value: + **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.) + + | **State** | **Description** | + | ---------------------- | -------------- | + | HDF_ERR_INVALID_OBJECT | Invalid controller object.| + | HDF_ERR_MALLOC_FAIL | Failed to allocate memory. | + | HDF_ERR_INVALID_PARAM | Invalid parameter. | + | HDF_ERR_IO | I/O error. | + | HDF_SUCCESS | Initialization successful. | + | HDF_FAILURE | Initialization failed. | + + Function description: + Initializes the custom structure object and **PinCntlr** members, and connects to the pin controller by calling the **PinCntlrAdd()** function. + + ```c + static int32_t Hi35xxPinReadFunc(struct Hi35xxPinDesc *desc, const struct DeviceResourceNode *node, struct DeviceResourceIface *drsOps) + { + int32_t ret; + uint32_t funcNum = 0; + // Read the pin function names of the pin controller child nodes from the .hcs file. + ret = drsOps->GetString(node, "F0", &desc->func[funcNum], "NULL"); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read F0 failed", __func__); + return ret; + } - ```c - static struct HdfDriverEntry g_hi35xxPinDriverEntry = { - .moduleVersion = 1, - .Bind = Hi35xxPinBind, - .Init = Hi35xxPinInit, - .Release = Hi35xxPinRelease, - .moduleName = "hi35xx_pin_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file. - }; - // Call HDF_INIT to register the driver entry with the HDF. - HDF_INIT(g_hi35xxPinDriverEntry); - ``` + funcNum++; + ret = drsOps->GetString(node, "F1", &desc->func[funcNum], "NULL"); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read F1 failed", __func__); + return ret; + } -2. Add **deviceNode** to the **device\_info.hcs** file, and set the device attributes in the **pin\_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 **PinCntlr** members at the core layer. - - >![](../public_sys-resources/icon-note.gif) **NOTE** - >If there are multiple devices, add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **pin\_config** file. - - - **device\_info.hcs** reference: - - ```c - root { - device_info { - platform :: host { - hostName = "platform_host"; - priority = 50; - device_pin :: device { - device0:: deviceNode { // Set an HDF device node for each pin controller. - policy = 0; // 2: visible in user mode; 1: visible in kernel mode; 0: no service required. - priority = 10; // Driver startup priority. - permission = 0644; // Permission to create device nodes for the driver. - /* (Mandatory) Driver name, which must be the same as the moduleName in the driver entry. */ - moduleName = "hi35xx_Pin_driver"; - /* (Mandatory) Set the controller private data, which must be same as that in Pin_config.hcs. */ - deviceMatchAttr = "hisilicon_hi35xx_Pin_0"; - } - device1 :: deviceNode { - policy = 0; - priority = 10; - permission = 0644; - moduleName = "hi35xx_Pin_driver"; - deviceMatchAttr = "hisilicon_hi35xx_Pin_1"; - } - ... - } - } - } - } - ``` - - - **Pin\_config.hcs** reference: - - ```c - root { - platform { - Pin_config_hi35xx { - template Pin_controller { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by device nodes. - number = 0; // (Mandatory) Controller ID. - regStartBasePhy = 0; // (Mandatory) Start physical base address of the register. - regSize = 0; // (Mandatory) Register bit width. - PinCount = 0; // (Mandatory) Number of pins. - match_attr = ""; - template Pin_desc { - PinName = ""; // (Mandatory) Pin name. - init = 0; // (Mandatory) Default value of the register. - F0 = ""; // (Mandatory) Functionality 0. - F1 = ""; // Functionality 1. - F2 = ""; // Functionality 2. - F3 = ""; // Functionality 3. - F4 = ""; // Functionality 4. - F5 = ""; // Functionality 5. - } - } - controller_0 :: Pin_controller { - number = 0; - regStartBasePhy = 0x10FF0000; - regSize = 0x48; - PinCount = 18; - match_attr = "hisilicon_hi35xx_Pin_0"; - T1 :: Pin_desc { - PinName = "T1"; - init = 0x0600; - F0 = "EMMC_CLK"; - F1 = "SFC_CLK"; - F2 = "SFC_BOOT_MODE"; - } - ... - } - ...// Each pin controller corresponds to a controller node. If there are multiple pin controllers, add the corresponding controller nodes one by one. - } - } - } - ``` - -3. Initialize the **PinCntlr** object at the core layer, including initializing the vendor custom structure (passing parameters and data), instantiating **PinCntlrMethod** (used to call underlying functions of the driver) in **PinCntlr**, and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**). - - - Initializing the vendor custom structure - - The **PinCntlr** structure holds parameters and data for the driver. The HDF obtains the values in **pin\_config.hcs** using **DeviceResourceIface**. - - ```c - // PinCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function. - struct PinCntlr { - struct IDeviceIoService service; - struct HdfDeviceObject *device; - struct PinCntlrMethod *method; - struct DListHead node; - OsalSPinlock sPin; - uint16_t number; - uint16_t PinCount; - struct PinDesc *Pins; - void *priv; - }; - - struct PinDesc { - const char *PinName; // Pointer to the pin name. - void *priv; - }; - ``` - - - Instantiating **PinCntlrMethod** (other members are initialized by **Init**) - - ```c - // Example of Pin_hi35xx.c: Instantiate the hook. - static struct PinCntlrMethod g_method = { - .SetPinPull = Hi35xxPinSetPull, - .GetPinPull = Hi35xxPinGetPull, - .SetPinStrength = Hi35xxPinSetStrength, - .GetPinStrength = Hi35xxPinGetStrength, - .SetPinFunc = Hi35xxPinSetFunc, - .GetPinFunc = Hi35xxPinGetFunc, - }; - ``` - - - **Init** function - - Input parameters: - - **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - - Return value: - - **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.) - - **Table 2** HDF\_STATUS - - - - - - - - - - - - - - - - - - - - - - - - -

State

-

Description

-

HDF_ERR_INVALID_OBJECT

-

Invalid controller object

-

HDF_ERR_MALLOC_FAIL

-

Failed to allocate memory

-

HDF_ERR_INVALID_PARAM

-

Invalid parameter

-

HDF_ERR_IO

-

I/O error

-

HDF_SUCCESS

-

Initialization successful

-

HDF_FAILURE

-

Initialization failed

-
- - Function description: - - Initializes the custom structure and **PinCntlr** members, and connects to the pin controller by calling the **PinCntlrAdd** function at the core layer. + funcNum++; + ...... + return HDF_SUCCESS; + } + + static int32_t Hi35xxPinParsePinNode(const struct DeviceResourceNode *node, struct Hi35xxPinCntlr *hi35xx, int32_t index) + { + int32_t ret; + struct DeviceResourceIface *drsOps = NULL; + // Read the pin attributes of the pin controller child nodes from the .hcs file. + drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE); + if (drsOps == NULL || drsOps->GetUint32 == NULL || drsOps->GetString == NULL) { + HDF_LOGE("%s: invalid drs ops fail!", __func__); + return HDF_FAILURE; + } + ret = drsOps->GetString(node, "pinName", &hi35xx->desc[index].pinName, "NULL"); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read pinName failed", __func__); + return ret; + } + ...... + ret = Hi35xxPinReadFunc(&hi35xx->desc[index], node, drsOps); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s:Pin read Func failed", __func__); + return ret; + } + hi35xx->cntlr.pins[index].pinName = hi35xx->desc[index].pinName; + hi35xx->cntlr.pins[index].priv = (void *)node; + ...... + return HDF_SUCCESS; + } - ```c static int32_t Hi35xxPinInit(struct HdfDeviceObject *device) { - ... + ...... struct Hi35xxPinCntlr *hi35xx = NULL; - ... - ret = Hi35xxPinCntlrInit(device, hi35xx); // Obtain .hcs information. - ... - DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { - ret = Hi35xxPinParsePinNode(childNode, hi35xx, index); // (Mandatory) The implementation is as follows: - ... + ...... + ret = Hi35xxPinCntlrInit(device, hi35xx); // Initialize the pin controller. + ...... + DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { // Traverses each child node of the pin controller. + ret = Hi35xxPinParsePinNode(childNode, hi35xx, index); // Parsing the child nodes. + ...... } - - hi35xx->cntlr.method = &g_method; // Instantiate OPS. + + hi35xx->cntlr.method = &g_method; // Instantiate method. ret = PinCntlrAdd(&hi35xx->cntlr); // Connect to the controller. - ... - } - - static int32_t Hi35xxPinParsePinNode(const struct DeviceResourceNode *node, - struct Hi35xxPinCntlr *hi35xx, - int32_t index) - { - ... - hi35xx->cntlr.Pins[index].PinName = hi35xx->desc[index].PinName; // Instantiate PinName. - hi35xx->cntlr.Pins[index].priv = (void *)node; // Instantiate nodes. - ... + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: add Pin cntlr: failed", __func__); + ret = HDF_FAILURE; + } + return HDF_SUCCESS; } + ``` - - - **Release** function + - **Release()** function Input parameters: - **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information. + Return value: - + – - + Function description: - - Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. + + Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init()** function to initialize the driver, the **Release()** function can be called to release driver resources. ```c static void Hi35xxPinRelease(struct HdfDeviceObject *device) { - struct PinCntlr *cntlr = NULL; - ... - PinCntlrRemove(cntlr);// (Mandatory) Call the function at the core layer to release pin controller devices and services. - ... + int32_t ret; + uint16_t number; + struct PinCntlr *cntlr = NULL; + struct Hi35xxPinCntlr *hi35xx = NULL; + struct DeviceResourceIface *drsOps = NULL; + + if (device == NULL || device->property == NULL) { + HDF_LOGE("%s: device or property is null", __func__); + return; + } + // Read the pin controller ID from the .hcs file. + drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE); + if (drsOps == NULL || drsOps->GetUint32 == NULL || drsOps->GetString == NULL) { + HDF_LOGE("%s: invalid drs ops", __func__); + return; + } + ret = drsOps->GetUint16(device->property, "number", &number, 0); + if (ret != HDF_SUCCESS) { + HDF_LOGE("%s: read cntlr number failed", __func__); + return; + } + + cntlr = PinCntlrGetByNumber(number); // Obtain the pin controller based on the controller ID. + PinCntlrRemove(cntlr); + hi35xx = (struct Hi35xxPinCntlr *)cntlr; + if (hi35xx != NULL) { + if (hi35xx->regBase != NULL) { + OsalIoUnmap((void *)hi35xx->regBase); + } + OsalMemFree(hi35xx); + } } ``` +4. Debug the driver. + (Optional) Verify basic functionalities of new drivers. For example, verify the information returned when the driver is loaded and whether data is successfully transmitted. diff --git a/en/device-dev/driver/driver-platform-pwm-des.md b/en/device-dev/driver/driver-platform-pwm-des.md index ca50d1809e7989eccb7ffe85c173c899ab08de59..c87a2deeb1ef03fbd2f1c309bc04cfbf539d69bc 100644 --- a/en/device-dev/driver/driver-platform-pwm-des.md +++ b/en/device-dev/driver/driver-platform-pwm-des.md @@ -1,134 +1,82 @@ -# PWM +# PWM -## Overview -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. +## Overview + +Pulse width modulation (PWM) is a technology that digitally encodes analog signal levels and converts them into pulses. It can be used for motor control and backlight brightness adjustment. + + The PWM APIs provide a set of functions for operating a PWM device, including those for: +- Opening or closing a PWM device handle -The PWM APIs provide a set of functions for operating a PWM device, including those for: -- Obtaining and releasing a PWM device handle - Setting the PWM period, signal ON-state time, and polarity + - Enabling and disabling a PWM device + - Obtaining and setting PWM parameters -### PwmConfig Structure - -**Table 1** PwmConfig structure - - - -| Parameter| Description| -| -------- | ------------------------------------------------------------ | -| duty | Time that a signal is in the ON state, in ns.| -| period | Time for a signal to complete an on-and-off cycle, in ns.| -| number | Number of square waves to generate. A positive value indicates the number of square waves to generate. The value 0 means to generate square waves repeatedly.| -| polarity | PWM signal polarity, which can be **PWM\_NORMAL\_POLARITY** or **PWM\_INVERTED\_POLARITY**.| -| status | PWM device status, which can be enabled or disabled.| - -## Available APIs - -**Table 2** PWM device APIs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CategoryAPIDescription
Operating PWM handlesPwmOpenOpens the handle of a PWM device.
PwmCloseCloses the handle of a PWM device.
Enabling or disabling PWMPwmEnableEnables a PWM device.
PwmDisableDisables a PWM device.
Performing PWM configurationPwmSetPeriodSets the PWM period.
PwmSetDutySets the signal ON-state time.
PwmSetPolaritySets the PWM signal polarity.
Setting or obtaining the PWM configurationPwmSetConfigSets PWM device parameters.
PwmGetConfigObtains PWM device parameters.
- - - ->![](W:\doc\docs\en\device-dev\public_sys-resources\icon-note.gif) **NOTE:** ->The PWM module can be used in kernel mode but not in user mode. - -## Usage Guidelines - -### How to Use - -During the OS startup process, the driver management module loads the PWM driver based on the configuration file. Then, the PWM driver detects the PWM device and initializes the driver. - -[Figure 1](#fig1_PWM_des) shows the general process of using the PWM module. - -**Figure 1** Process of using the PWM module +### PwmConfig Structure + + **Table 1** PwmConfig structure + +| Parameter| Description| +| -------- | -------- | +| duty | Time that a signal is in the ON state, in ns.| +| period | Time for a signal to complete an on-and-off cycle, in ns.| +| number | Number of square waves to generate.
- Positive value: indicates the number of square waves to generate.
- **0**: indicates that square waves are generated continuously.| +| polarity | PWM signal polarity, which can be positive or reverse.| +| status | PWM device status, which can be enabled or disabled.| + + +## Available APIs + + **Table 2** PWM driver APIs + +| Category| Description| +| -------- | -------- | +| Operating PWM handles| - **PwmOpen**: opens the device handle of a PWM device.
- **PwmClose**: closes the device handle of a PWM device.| +| Enabling or disabling PWM| - **PwmEnable**: enables a PWM device.
- **PwmDisable**: disables a PWM device.| +| Setting PWM| - **PwmSetPeriod**: sets the PWM period.
- **PwmSetDuty**: sets the signal ON-state time.
- **PwmSetPolarity**: sets the PWM signal polarity.| +| Setting or obtaining PWM configuration| - **PwmSetConfig**: sets PWM device parameters.
- **PwmGetConfig**: obtains PWM device parameters.| + +> ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**
+> All APIs described in this document can be called only in the kernel space. + + +## Usage Guidelines + + +### How to Use + +The figure below shows the general process of using the PWM. + + **Figure 1** Process of using the PWM module ![](figures/process-of-using-PWM.png) -### Opening a PWM Device Handle + +### Opening a PWM Device Handle Before performing operations on a PWM device, call **PwmOpen** to open the device handle. -```c + +``` DevHandle PwmOpen(uint32_t num); ``` -**Table 3** PwmOpen - - + **Table 3** Description of PwmOpen -| Parameter| Description| -| ---------- | ----------------------- | -| num | PWM device number.| -| **Return Value** | **Description**| +| **Parameter**| **Description**| +| -------- | -------- | +| num | PWM device number. | +| **Return Value** | **Description** | | handle | Handle of the PWM device obtained.| -| NULL | The operation fails.| +| NULL | The operation fails. | + +Example: Open the device handle of PWM device 0. -```c +``` uint32_t num = 0; /* PWM device number. */ DevHandle handle = NULL; @@ -139,48 +87,49 @@ if (handle == NULL) { } ``` -### Closing a PWM Device Handle -Close a PWM device to release resources. +### Closing a PWM Device Handle -```c -void PwmClose(DevHandle handle); -``` +Call **PwmClose()** to close a PWM device handle to release resources. -**Table 4** PwmClose - +``` +voidPwmClose(DevHandle handle); +``` -| Parameter| Description| -| ------ | ----------- | -| handle | PWM device handle to close.| + **Table 4** Description of PwmClose +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle to close. | -```c + +``` /* Close a PWM device handle. */ PwmClose(handle); ``` -### Enabling a PWM Device -Enable a PWM device. +### Enabling a PWM Device -```c +Call **PwmEnable()** to enable a PWM device. + + +``` int32_t PwmEnable(DevHandle handle); ``` -**Table 5** PwmEnable + **Table 5** Description of PwmEnable - - -| Parameter| Description| -| ---------- | -------------- | -| handle | PWM device handle.| +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle. | | **Return Value** | **Description** | -| 0 | The operation is successful.| -| Negative number| The operation fails.| +| 0 | The operation is successful. | +| Negative number | The operation fails. | + -```c +``` int32_t ret; /* Enable a PWM device. */ @@ -190,26 +139,27 @@ if (ret != 0) { } ``` -### Disabling a PWM Device -Disable a PWM device. +### Disabling a PWM Device + +Call **PwmDisable()** to disable a PWM device. -```c + +``` int32_t PwmDisable(DevHandle handle); ``` -**Table 6** PwmDisable + **Table 6** Description of PwmDisable - - -| Parameter| Description| -| ---------- | -------------- | -| handle | PWM device handle.| +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle. | | **Return Value** | **Description** | -| 0 | The operation is successful.| -| Negative number| The operation fails.| +| 0 | The operation is successful. | +| Negative number | The operation fails. | + -```c +``` int32_t ret; /* Disable a PWM device. */ @@ -219,27 +169,28 @@ if (ret != 0) { } ``` -### Setting the PWM Period -Set the PWM period. +### Setting the PWM Period + +Call **PwmSetPeriod()** to set the PWM period. + -```c +``` int32_t PwmSetPeriod(DevHandle handle, uint32_t period); ``` -**Table 7** PwmSetPeriod - - + **Table 7** Description of PwmSetPeriod -| Parameter| Description| -| ---------- | ------------------------ | -| handle | PWM device handle.| +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle. | | period | PWM period to set, in ns.| -| **Return Value**| **Description**| -| 0 | The operation is successful.| -| Negative number| The operation fails.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative number | The operation fails. | -```c + +``` int32_t ret; /* Set the PWM period to 50000000 ns.*/ @@ -248,27 +199,29 @@ if (ret != 0) { /* Error handling. */ } ``` -### Setting the PWM Signal ON-State Time -Set the time that the PWM signal is in the ON state. -```c +### Setting the PWM Signal ON-State Time + +Call **PwmSetDuty()** to set the time that the PWM signal is in the ON state. + + +``` int32_t PwmSetDuty(DevHandle handle, uint32_t duty); ``` -**Table 8** PwmSetDuty - - + **Table 8** Description of PwmSetDuty -| Parameter| Description| -| ---------- | ---------------------------- | -| handle | PWM device handle.| +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle. | | duty | Time that the signal is in the ON state, in ns.| -| **Return Value**| **Description**| -| 0 | The operation is successful.| -| Negative number| The operation fails.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative number | The operation fails. | -```c + +``` int32_t ret; /* Set the signal ON-state time to 25000000 ns. */ @@ -277,27 +230,29 @@ if (ret != 0) { /* Error handling. */ } ``` -### Setting the PWM Polarity -Set the signal polarity for a PWM device. -```c +### Setting the PWM Signal Polarity + +Call **PwmSetPolarity()** to set the signal polarity for a PWM device. + + +``` int32_t PwmSetPolarity(DevHandle handle, uint8_t polarity); ``` -**Table 9** PwmSetPolarity - - + **Table 9** Description of PwmSetPolarity -| Parameter| Description| -| ---------- | ------------------- | -| handle | PWM device handle.| +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle. | | polarity | Polarity to set, which can be **PWM\_NORMAL\_POLARITY** or **PWM\_INVERTED\_POLARITY**.| -| **Return Value**| **Description**| -| 0 | The operation is successful.| -| Negative number| The operation fails.| +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative number | The operation fails. | -```c + +``` int32_t ret; /* Set the PWM polarity to PWM_INVERTED_POLARITY. */ @@ -308,34 +263,34 @@ if (ret != 0) { ``` -### Setting PWM Device Parameters +### Setting PWM Device Parameters -Set PWM device parameters. +Call **PwmSetConfig()** to set PWM device parameters. -```c + +``` int32_t PwmSetConfig(DevHandle handle, struct PwmConfig *config); ``` -**Table 10** PwmSetConfig + **Table 10** Description of PwmSetConfig - +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle to close. | +| \*config | Pointer to PWM parameters. | +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative number | The operation fails. | -| Parameter| Description| -| ---------- | -------------- | -| handle | PWM device handle.| -| *config | Pointer to PWM parameters.| -| **Return Value**| **Description**| -| 0 | The operation is successful.| -| Negative number| The operation fails.| -```c +``` int32_t ret; struct PwmConfig pcfg; -pcfg.duty = 25000000; /* Set the signal ON-state time to 25000000 ns. */ -pcfg.period = 50000000; /* Set the PWM period to 50000000 ns. */ -pcfg.number = 0; /* Generate square waves repeatedly. */ +pcfg.duty = 25000000; /* Set the signal ON-state time to 25000000 ns. */ +pcfg.period = 50000000; /* Set the PWM period to 50000000 ns. */ +pcfg.number = 0; /* Generate square waves repeatedly. */ pcfg.polarity = PWM_INVERTED_POLARITY; /* Set the PWM polarity to PWM_INVERTED_POLARITY. */ -pcfg.status = PWM_ENABLE_STATUS; /* Set the running status to Enabled. */ +pcfg.status = PWM_ENABLE_STATUS; /* Set the running status to Enabled. */ /* Set PWM device parameters. */ ret = PwmSetConfig(handle, &pcfg); @@ -344,27 +299,28 @@ if (ret != 0) { } ``` -### Obtaining PWM Device Parameters -Obtain PWM device parameters. +### Obtaining PWM Device Parameters + +Call **PwmGetConfig()** to obtain PWM device parameters. -```c + +``` int32_t PwmGetConfig(DevHandle handle, struct PwmConfig *config); ``` -**Table 11** PwmGetConfig + **Table 11** Description of PwmGetConfig - +| **Parameter**| **Description**| +| -------- | -------- | +| handle | PWM device handle to close. | +| \*config | Pointer to PWM parameters. | +| **Return Value**| **Description** | +| 0 | The operation is successful. | +| Negative number | The operation fails. | -| Parameter| Description| -| ---------- | -------------- | -| handle | PWM device handle.| -| *config | Pointer to PWM parameters.| -| **Return Value**| **Description**| -| 0 | The operation is successful.| -| Negative number| The operation fails.| -```c +``` int32_t ret; struct PwmConfig pcfg; @@ -375,10 +331,12 @@ if (ret != 0) { } ``` -## Usage Example + +## Development Example The following example shows how to use the APIs to implement a PWM driver and manage the PWM device. + ``` void PwmTestSample(void) { @@ -387,12 +345,12 @@ void PwmTestSample(void) DevHandle handle = NULL; struct PwmConfig pcfg; - pcfg.duty = 20000000; /* Set the signal ON-state time to 20000000 ns. */ - pcfg.period = 40000000; /* Set the PWM period to 40000000 ns. */ - pcfg.number = 100; /* Generate 100 square waves. */ + pcfg.duty = 20000000; /* Set the signal ON-state time to 20000000 ns. */ + pcfg.period = 40000000; /* Set the PWM period to 40000000 ns. */ + pcfg.number = 100; /* Generate 100 square waves. */ pcfg.polarity = PWM_NORMAL_POLARITY; /* Set the polarity to PWM_NORMAL_POLARITY. */ pcfg.status = PWM_ENABLE_STATUS; /* Set the running status to Enabled. */ - + /* Enter the PWM device number. */ num = 1; @@ -423,14 +381,14 @@ void PwmTestSample(void) HDF_LOGE("PwmSetPolarity: failed, ret %d\n", ret); goto _ERR; } - + /* Obtain PWM device parameters. */ ret = PwmGetConfig(handle, &pcfg); if (ret != 0) { HDF_LOGE("PwmGetConfig: failed, ret %d\n", ret); goto _ERR; } - + /* Enable the PWM device. */ ret = PwmEnable(handle); if (ret != 0) { @@ -451,7 +409,7 @@ void PwmTestSample(void) HDF_LOGE("PwmDisable: failed, ret %d\n", ret); goto _ERR; } - + _ERR: /* Close the PWM device handle. */ PwmClose(handle); diff --git a/en/device-dev/driver/driver-platform-regulator-des.md b/en/device-dev/driver/driver-platform-regulator-des.md index 27ecccbefa5d7eff9984c5b72b1c8e5bdaa5382c..0131dae05046bd67c73b0cd625e9cf203f79b6d5 100644 --- a/en/device-dev/driver/driver-platform-regulator-des.md +++ b/en/device-dev/driver/driver-platform-regulator-des.md @@ -1,113 +1,105 @@ -# Regulator +# Regulator -## Overview + +## Overview + +### Regulator The regulator module controls the voltage and current supplies of some devices in the system. In an embedded system (especially a mobile phone), it is important to control the power consumption, which directly affects the battery endurance. You can use a regulator to shut down the power supply to an idle module in the system or reduce the voltage and current for the module. +The regulator APIs provide a set of methods for managing a regulator, including those for: -- The regulator APIs provide a set of functions for managing a regulator, including those for: - - Opening or closing a regulator device handle - - Setting the output voltage and current for a regulator - - Enabling or disabling a regulator - - Obtaining the voltage, current, and status of a regulator - -## Available APIs - -**Table 1** Regulator APIs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CategoryAPIDescription
Operating a regulator device handleRegulatorOpenOpens a regulator device handle.
RegulatorCloseCloses a regulator device handle.
Enabling or disable a regulatorRegulatorEnableEnables a regulator.
RegulatorDisableDisables a regulator.
RegulatorForceDisableForcibly disables a regulator.
Setting or obtaining the output voltageRegulatorSetVoltageSets the output voltage for a regulator.
RegulatorGetVoltageObtains the output voltage of a regulator.
Setting or obtaining the output currentRegulatorSetCurrentSets the output current for a regulator.
RegulatorGetCurrentObtains the output current of a regulator.
Querying the regulator statusRegulatorGetStatusObtains the regulator status.
- ->![](../public_sys-resources/icon-note.gif) **NOTE** ->The regulator module can be used in kernel mode but not in user mode. - -## Usage Guidelines - -### How to Use +- Opening or closing a regulator device handle +- Setting the output voltage and current for a regulator +- Enabling or disabling a regulator +- Obtaining the voltage, current, and status of a regulator -During the OS startup process, the driver management module loads the regulator driver based on the configuration file. Then, the regulator driver detects the regulator devices and initializes the driver. -The figure below shows the process of using a regulator. +### Basic Concepts + +- Calibrator + + Software used to maintain stable output voltage when the output load is different from the input voltage. + +- Consumer + + The devices served by the regulator are called consumers. Consumers are classified into the following: + + * Static consumer: Only the power needs to be turned on or off for this type of consumers. The voltage and current do not need to be changed. Generally, the consumers are set in the bootloader, firmware, and kernel board phases. + * Dynamic consumer: The voltage and current need to be changed based on operation requirements for this type of consumers. + +- Power Management IC (PMIC) + + Power management chipset provides efficient, reliable, and safe voltage regulation. + + +### Working Principles + +In the Hardware Driver Foundation (HDF), the regulator module uses the unified service mode for API adaptation. In this mode, a device service is used as the regulator 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 regulator has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and more memory resources will be consumed by services. + +The regulator module is divided into the following layers: + +- The interface layer provides APIs for opening or closing a device and writing data. +- The core layer provides the capabilities of binding, initializing, and releasing devices. +- The adaptation layer implements other functions. + +![](../public_sys-resources/icon-note.gif)NOTE
The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer. + +**Figure 1** Unified service mode + +![image1](figures/unified-service-mode.png) + +### Constraints -**Figure 1** Process of using a regulator +Currently, the regulator module supports only the kernels (LiteOS) of mini and small systems. +## Development Guidelines + +### When to Use + +Regulators are used to: + +- Control the voltage/current supplies of some devices in the system. +- Manage regulated power supplies. + +### Available APIs + +**Table 1** Regulator module APIs + +| API | Description | +| --------------------- | ------------------------- | +| RegulatorOpen | Opens the regulator device handle.| +| RegulatorClose | Closes the regulator device handle.| +| RegulatorEnable | Enables a regulator. | +| RegulatorDisable | Disables a regulator. | +| RegulatorForceDisable | Forcibly disables a regulator. | +| RegulatorSetVoltage | Sets the regulator output voltage. | +| RegulatorGetVoltage | Obtains the regulator output voltage. | +| RegulatorSetCurrent | Sets the regulator output current. | +| RegulatorGetCurrent | Obtains the regulator output current. | +| RegulatorGetStatus | Obtains the regulator status. | + + + +### How to Develop + +During the OS startup process, the driver management module loads the regulator driver based on the configuration file. Then, the regulator driver detects the regulator devices and initializes the driver. + +The figure below illustrates the process of using a regulator. + +**Figure 2** Process of using a regulator ![](figures/process-of-using-regulator.png) -### Opening a Regulator Device Handle +#### Opening a Regulator Device Handle Before operating a regulator, call **RegulatorOpen** to open the device handle of the regulator. This function returns the device handle of the regulator. -```c +``` DevHandle RegulatorOpen(const char *name); ``` **Table 2** Description of RegulatorOpen - - | **Parameter** | **Description** | | ---------- | ----------------------------- | | name | Name of the target regulator. | @@ -116,8 +108,9 @@ DevHandle RegulatorOpen(const char *name); | NULL | The operation fails. | -```c -/* Regulator name. */ + +``` +/* Regulator device name */ const char *name = "regulator_virtual_1"; DevHandle handle = NULL; @@ -128,48 +121,45 @@ if (handle == NULL) { } ``` -### Closing a Regulator Device Handle +#### Closing a Regulator Device Handle Call **RegulatorClose** to close the regulator device handle to release resources. -```c +``` void RegulatorClose(DevHandle handle); ``` **Table 3** Description of RegulatorClose - - | **Parameter** | **Description** | | ------ | ----------------- | -| handle | Regulator device handle to close.| +| handle | Device handle of the target regulator.| - -```c +``` /* Close the regulator device handle. */ RegulatorClose(handle); ``` -### Enabling a Regulator +#### Enabling a Regulator -Call **RegulatorEnable** to enable a regulator. +Call **RegulatorEnable()** to enable a regulator. -```c +``` int32_t RegulatorEnable(DevHandle handle); ``` **Table 4** Description of RegulatorEnable - - | **Parameter** | **Description** | | ---------- | ----------------- | -| handle | Device handle of the regulator to enable.| +| handle | Device handle of the target regulator.| | **Return Value**| **Description** | | 0 | The operation is successful. | | Negative value | The operation fails. | -```c + + +``` int32_t ret; /* Enable the regulator. */ @@ -179,26 +169,24 @@ if (ret != 0) { } ``` -### Disabling a Regulator +#### Disabling a Regulator -Call **RegulatorDisable** to disable a regulator. The operation will fail if the regulator status is set to always on or if a child node of the regulator is not disabled. +Call **RegulatorDisable()** to disable a regulator. The operation will fail if the regulator status is set to always on or a child node of the regulator is not disabled. -```c +``` int32_t RegulatorDisable(DevHandle handle); ``` **Table 5** Description of RegulatorDisable - - | **Parameter** | **Description** | | ---------- | ----------------- | -| handle | Device handle of the regulator to disable.| +| handle | Device handle of the target regulator.| | **Return Value**| **Description** | | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; /* Disable the regulator. */ @@ -208,46 +196,44 @@ if (ret != 0) { } ``` -### Forcibly Disabling a Regulator +#### Forcibly Disabling a Regulator -Call **RegulatorForceDisable** to forcibly disable a regulator. The regulator will be disabled event if its status is set to always on or its child node is still enabled. +Call **RegulatorForceDisable()** to forcibly disable a regulator. The regulator will be disabled even if its status is set to always on or its child node is still enabled. -```c +``` int32_t RegulatorForceDisable(DevHandle handle); ``` **Table 6** Description of RegulatorForceDisable - | **Parameter** | **Description** | | ---------- | ----------------- | | handle | Device handle of the target regulator.| | **Return Value**| **Description** | -| 0 | The operation is successful. | -| Negative value | The operation fails. | +| 0 | The operation is successful. | +| Negative value | The operation fails. | -```c +``` int32_t ret; -/* Forcibly disable the regulator. */ +/* Forcibly disable the regulator. /* ret = RegulatorForceDisable(handle); if (ret != 0) { /* Error handling. */ } ``` -### Setting the Output Voltage Range for a Regulator + +#### Setting the Output Voltage Range Call **RegulatorSetVoltage** to set the output voltage range for a regulator. -```c +``` int32_t RegulatorSetVoltage(DevHandle handle, uint32_t minUv, uint32_t maxUv); ``` **Table 7** Description of RegulatorSetVoltage - - | **Parameter** | **Description** | | ---------- | ----------------- | | handle | Device handle of the target regulator.| @@ -257,28 +243,28 @@ int32_t RegulatorSetVoltage(DevHandle handle, uint32_t minUv, uint32_t maxUv); | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; -int32_t minUv = 0; // Set the minimum voltage to 0 µV. -int32_t maxUv = 20000; // Set the maximum voltage to 20000 µV. +int32_t minUv = 0; // The minimum voltage is 0 µV. +int32_t maxUv = 20000; // The maximum voltage is 20000 µV. -/* Set the output voltage range for the regulator. */ +/* Set the output voltage range of the regulator. */ ret = RegulatorSetVoltage(handle, minUv, maxUv); if (ret != 0) { /* Error handling. */ } ``` -### Obtaining Regulator Voltage Information -Call **RegulatorGetVoltage** to obtain voltage information of a regulator. +#### Obtaining the Regulator Voltage + +Call **RegulatorGetVoltage()** to obtain the regulator voltage. -```c +``` int32_t RegulatorGetVoltage(DevHandle handle, uint32_t *voltage); ``` **Table 8** Description of RegulatorGetVoltage - | **Parameter** | **Description** | | ---------- | ----------------- | @@ -288,30 +274,27 @@ int32_t RegulatorGetVoltage(DevHandle handle, uint32_t *voltage); | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; uint32_t voltage; -/* Obtain the regulator voltage information. */ +/* Obtain the regulator voltage. */ ret = RegulatorGetVoltage(handle, &voltage); if (ret != 0) { /* Error handling. */ } ``` +#### Setting the Output Current Range -### Setting the Output Current Range for a Regulator - -Call **RegulatorSetCurrent** to set the output current range for a regulator. +Call **RegulatorSetCurrent()** to set the output current range of the regulator. -```c +``` int32_t RegulatorSetCurrent(DevHandle handle, uint32_t minUa, uint32_t maxUa); ``` **Table 9** Description of RegulatorSetCurrent - - | **Parameter** | **Description** | | ---------- | ----------------- | | handle | Device handle of the target regulator.| @@ -321,30 +304,28 @@ int32_t RegulatorSetCurrent(DevHandle handle, uint32_t minUa, uint32_t maxUa); | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; -int32_t minUa = 0; // Set the minimum current to 0 μA. -int32_t maxUa = 200; // Set the maximum current to 200 μA. +int32_t minUa = 0; // The minimum current is 0 μA. +int32_t maxUa = 200; // The maximum current is 200 μA. -/* Set the output current range for the regulator. */ +/* Set the output current range of the regulator. */ ret = RegulatorSetCurrent(handle, minUa, maxUa); if (ret != 0) { /* Error handling. */ } ``` -### Obtaining Regulator Current Information +#### Obtaining the Regulator Current -Call **RegulatorGetCurrent** to obtain current information of a regulator. +Call **RegulatorGetCurrent()** to obtain the current of the regulator. -```c +``` int32_t RegulatorGetCurrent(DevHandle handle, uint32_t *regCurrent); ``` **Table 10** Description of RegulatorGetCurrent - - | **Parameter** | **Description** | | ----------- | ----------------- | | handle | Device handle of the target regulator.| @@ -353,28 +334,27 @@ int32_t RegulatorGetCurrent(DevHandle handle, uint32_t *regCurrent); | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; uint32_t regCurrent; -/* Obtain the regulator current information. */ +/* Obtain the current of the regulator. */ ret = RegulatorGetCurrent(handle, ®Current); if (ret != 0) { /* Error handling. */ } ``` -### Obtaining Regulator Status -Call **RegulatorGetStatus** to obtain the regulator status. +#### Obtaining the Regulator Status + +Call **RegulatorGetStatus()** to obtain the regulator status. -```c +``` int32_t RegulatorGetStatus(DevHandle handle, uint32_t *status); ``` **Table 11** Description of RegulatorGetStatus - - | **Parameter** | **Description** | | ---------- | ----------------- | | handle | Device handle of the target regulator.| @@ -383,7 +363,7 @@ int32_t RegulatorGetStatus(DevHandle handle, uint32_t *status); | 0 | The operation is successful. | | Negative value | The operation fails. | -```c +``` int32_t ret; uint32_t status; @@ -394,16 +374,18 @@ if (ret != 0) { } ``` -## Development Example + + +## Development Example The following is an example of using a regulator. -```c +``` void RegulatorTestSample(void) { int32_t ret; - /* Regulator name. */ + /* Regulator device name */ const char *name = "regulator_virtual_1"; DevHandle handle = NULL; @@ -421,10 +403,10 @@ void RegulatorTestSample(void) goto _ERR; } - int32_t minUv = 0; // Set the minimum voltage to 0 µV. - int32_t maxUv = 20000; // Set the maximum voltage to 20000 µV. + int32_t minUv = 0; // The minimum voltage is 0 µV. + int32_t maxUv = 20000; // The maximum voltage is 20000 µV. - /* Set the output voltage range for the regulator. */ + /* Set the output voltage range of the regulator. */ ret = RegulatorSetVoltage(handle, minUv, maxUv); if (ret != 0) { HDF_LOGE("RegulatorSetVoltage: failed, ret %d\n", ret); @@ -433,7 +415,7 @@ void RegulatorTestSample(void) uint32_t voltage; - /* Obtain the regulator voltage information. */ + /* Obtain the regulator voltage. */ ret = RegulatorGetVoltage(handle, &voltage); if (ret != 0) { HDF_LOGE("RegulatorGetVoltage: failed, ret %d\n", ret); diff --git a/en/device-dev/driver/driver-platform-regulator-develop.md b/en/device-dev/driver/driver-platform-regulator-develop.md index 18b1721f9a81bc86f3ea9987f66ae6cb03ff87a0..94fd1f76d09106a5698aa27b89503be6ab231a2d 100644 --- a/en/device-dev/driver/driver-platform-regulator-develop.md +++ b/en/device-dev/driver/driver-platform-regulator-develop.md @@ -1,18 +1,51 @@ -# Regulator +# Regulator -## Overview +## Overview -The regulator module controls the voltage and current supplies of some devices in the system. In the Hardware Driver Foundation (HDF), the regulator module uses the unified service mode for API adaptation. In this mode, a device service is used as the regulator 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 regulator has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and more memory resources will be consumed by services. +### Regulator + +The regulator module controls the voltage and current supplies of some devices in the system. + +### Basic Concepts + +The regulator module controls the voltage and current supplies of some devices in the system. In an embedded system (especially a mobile phone), it is important to control the power consumption, which directly affects the battery endurance. You can use a regulator to shut down the power supply to an idle module in the system or reduce the voltage and current for the module. + +### Working Principles + +In the Hardware Driver Foundation (HDF), the regulator module uses the unified service mode for API adaptation. In this mode, a device service is used as the regulator 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 regulator has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and more memory resources will be consumed by services. + +The regulator module is divided into the following layers: + +- The interface layer provides APIs for opening or closing a device and writing data. +- The core layer provides the capabilities of binding, initializing, and releasing devices. +- The adaptation layer implements other functions. + +![](../public_sys-resources/icon-note.gif)NOTE
The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer. **Figure 1** Unified service mode + ![image1](figures/unified-service-mode.png) -## Available APIs + + +### Constraints + +Currently, the regulator module supports only the kernels (LiteOS) of mini and small systems. + +## Development Guidelines + +### When to Use + +The regulator module controls the voltage and current supplies of some devices in the system. + +### Available APIs + +The functions in **RegulatorMethod** are used to call the corresponding regulator driver functions: **RegulatorMethod** structure: -```c +``` struct RegulatorMethod { int32_t (*open)(struct RegulatorNode *node); int32_t (*close)(struct RegulatorNode *node); @@ -28,87 +61,80 @@ struct RegulatorMethod { }; ``` -**Table 1** APIs for the members in the RegulatorMethod structure +**Table 1** Description of the RegulatorMethod structure -| Method | Input Parameter | Return Value| Description| -| ------------ | ------------------------------------------- | ------ | ---- | -| open | **node**: structure pointer to the regulator node at the core layer.|HDF_STATUS|Opens a device.| -| close | **node**: structure pointer to the regulator node at the core layer.| HDF_STATUS| Closes a device.| -| release | **node**: structure pointer to the regulator node at the core layer.| HDF_STATUS| Releases a device handle.| -| enable | **node**: structure pointer to the regulator node at the core layer.| HDF_STATUS| Enables a device.| -| disable | **node**: structure pointer to the regulator node at the core layer.| HDF_STATUS| Disables a device.| -| forceDisable | **node**: structure pointer to the regulator node at the core layer.| HDF_STATUS| Forcibly disables a device.| + +| Method | Input Parameter | Return Value | Description | +| ------------ | ------------------------------------------------------------ | ------------------ | ---------------- | +| open | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Opens a device. | +| close | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Closes a device. | +| release | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Releases a device handle. | +| enable | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Enabling a Regulator | +| disable | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Disabling a Regulator | +| forceDisable | **node**: structure pointer to the regulator node at the core layer. | HDF_STATUS| Forcibly Disabling a Regulator | | setVoltage | **node**: structure pointer to the regulator node at the core layer.
**minUv**: minimum voltage to set. It is a uint32_t variable.
**maxUv**: maximum voltage to set. It is a uint32_t variable.| HDF_STATUS| Sets the output voltage range.| -| getVoltage | **node**: structure pointer to the regulator node at the core layer.
**voltage**: pointer to the output voltage value.| HDF_STATUS| Obtains the voltage.| +| getVoltage | **node**: structure pointer to the regulator node at the core layer.
**voltage**: pointer to the output voltage value.| HDF_STATUS| Obtains the voltage. | | setCurrent | **node**: structure pointer to the regulator node at the core layer.
**minUa**: minimum current to set. It is a uint32_t variable.
**maxUa**: maximum current to set. It is a uint32_t variable.| HDF_STATUS| Sets the output current range.| -| getCurrent | **node**: structure pointer to the regulator node at the core layer.
**regCurrent**: pointer to the output current, which is of the uint32_t type.| HDF_STATUS| Obtains the current.| -| getStatus | **node**: structure pointer to the regulator node at the core layer.
**status**: pointer to the output status, which is of the uint32_t type.| HDF_STATUS| Obtains the device status.| - -## How to Develop - -The regulator 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. - -2. Configure attribute files. +| getCurrent | **node**: structure pointer to the regulator node at the core layer.
**regCurrent**: pointer to the output current, which is of the uint32_t type.| HDF_STATUS| Obtains the current. | +| getStatus | **node**: structure pointer to the regulator node at the core layer.
**status**: pointer to the output status, which is of the uint32_t type.| HDF_STATUS| Obtains the device status. | - - Add the **deviceNode** information to the **device_info.hcs** file. - - (Optional) Add the **regulator_config.hcs** file. +### How to Develop -3. Instantiate the regulator controller object. - - - Initialize **RegulatorNode** members. - - - Instantiate **RegulatorMethod**. - - >![](../public_sys-resources/icon-note.gif) **NOTE** - - >For details, see [Available APIs](#availableapis). - -4. Debug the driver. - - (Optional) Verify basic functionalities of new drivers. For example, verify the information returned when the driver is loaded and whether data is successfully transmitted. +The regulator module adaptation procedure is as follows: -## Development Example +- Instantiate the driver entry. +- Configure attribute files. +- Instantiate the core layer APIs. +- Debug the driver. -The following uses **regulator_virtual.c** as an example to present the content to be provided by the vendor to implement device functionalities. +1. Instantiate the driver entry. -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 are collected to form a segment address space similar to an array for the upper layer to invoke. + 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 are collected to form a segment address space similar to an array for the upper layer to invoke. + + Generally, the HDF calls the **Init()** function to load the driver. If **Init()** fails to be called, the HDF calls **Release** to release driver resources and exit. + + ``` + struct HdfDriverEntry g_regulatorDriverEntry = { + .moduleVersion = 1, + .moduleName = "virtual_regulator_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file. + .Init = VirtualRegulatorInit, + .Release = VirtualRegulatorRelease, + }; + // Call HDF_INIT to register the driver entry with the HDF framework. + HDF_INIT(g_regulatorDriverEntry); + ``` + +2. Configure attribute files. - Generally, the HDF calls the **Bind** function and then the **Init** function to load the driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit. + - Add the device node description to the **vendor/hisilicon/hispark_taurus/hdf_config/device_info/device_info.hcs** file. - Regulator driver entry reference: + 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 **RegulatorNode** members at the core layer. - ```c - struct HdfDriverEntry g_regulatorDriverEntry = { - .moduleVersion = 1, - .moduleName = "virtual_regulator_driver",// (Mandatory) The value must be the same as that of moduleName in the .hcs file. - .Init = VirtualRegulatorInit, - .Release = VirtualRegulatorRelease, - }; - // Call HDF_INIT to register the driver entry with the HDF framework. - HDF_INIT(g_regulatorDriverEntry); - ``` + In the unified service mode, the first device node in the **device_info.hcs** file must be the regulator manager. The parameters must be set as follows: -2. Add **deviceNode** to the **device\_info.hcs** file, and set the device attributes in the **regulator\_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 **RegulatorNode** members at the core layer. + | Member | Value | + | --------------- | ------------------------------------------------------------ | + | policy | **0**, which indicates that no service is published. | + | priority | Driver startup priority. The value range is 0 to 200. A larger value indicates a lower priority. If the priorities are the same, the device loading sequence is not ensured.| + | permission | Driver permission. | + | moduleName | The value is **HDF_PLATFORM_REGULATOR_MANAGER**. | + | serviceName | The value is **HDF_PLATFORM_REGULATOR_MANAGER**. | + | deviceMatchAttr | Reserved. | - >![](W:\doc\docs\en\device-dev\public_sys-resources\icon-note.gif) **NOTE** - >If there are multiple devices, add the **deviceNode** information to the **device\_info** file and add the corresponding device attributes to the **regulator\_config** file. + Configure regulator controller information from the second node. This node specifies a type of regulator controllers rather than a specific regulator controller. In this example, there is only one regulator device. If there are multiple regulator devices, you need to add the **deviceNode** information to the **device_info** file and add the corresponding device attributes to the **regulator\_config** file. - - **device\_info.hcs** reference: + - **device_info.hcs** configuration reference - ```c - root { + ``` + root { device_info { platform :: host { hostName = "platform_host"; priority = 50; device_regulator :: device { device0 :: deviceNode { // Configure an HDF device node for each regulator controller. - policy = 1; // 2: visible in user mode; 1: visible in kernel mode; 0: no service required. - priority = 50; // Driver startup priority. + policy = 1; // 2: visible in user mode; 1: visible in kernel mode; 0: no service required. + priority = 50; // Driver startup priority. permission = 0644; // Permission to create device nodes of the driver. /* (Mandatory) Driver name, which must be the same as the moduleName in the driver entry. */ moduleName = "HDF_PLATFORM_REGULATOR_MANAGER"; @@ -126,211 +152,197 @@ The following uses **regulator_virtual.c** as an example to present the content } } } - } - ``` - - - **regulator\_config.hcs** reference: - - ```c - root { - platform { - regulator_config { - match_attr = "linux_regulator_adapter"; - template regulator_controller { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by device nodes. - device_num = 1; - name = ""; - devName = "regulator_adapter_consumer01"; - supplyName = ""; - mode = 1; - minUv = 0; - maxUv = 20000; - minUa = 0; - maxUa = 0; - } - controller_0x130d0000 :: regulator_controller { - device_num = 1; - name = "regulator_adapter_1"; - devName = "regulator_adapter_consumer01"; - supplyName = "virtual-regulator-hdf-adapter"; - mode = 1; - minUv = 1000; - maxUv = 50000; - minUa = 0; - maxUa = 0; - } - /* Each regulator controller corresponds to a controller node. If there are multiple regulator controllers, add the corresponding controller nodes one by one.*/ - controller_0x130d0001 :: regulator_controller { - device_num = 1; - name = "regulator_adapter_2"; - devName = "regulator_adapter_consumer01"; - supplyName = "virtual2-regulator-hdf-adapter"; - mode = 2; - minUv = 0; - maxUv = 0; - minUa = 1000; - maxUa = 50000; - } - } - } - } - ``` - -3. Initialize the **RegulatorNode** object at the core layer, including initializing the vendor custom structure (passing parameters and data), instantiating **RegulatorMethod** (used to call underlying functions of the driver) in **PinCntlr**, and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**). - - - Initializing the vendor custom structure - - The **RegulatorNode** structure holds parameters and data for the driver. The HDF obtains the values in **regulator\_config.hcs** using **DeviceResourceIface**. - - ```c - // RegulatorNode is the controller structure at the core layer. Its members are assigned with values by using the Init function. - struct RegulatorNode { - struct RegulatorDesc regulatorInfo; - struct DListHead node; - struct RegulatorMethod *ops; - void *priv; - struct OsalMutex lock; - }; - - struct RegulatorDesc { - const char *name; /* Regulator name. */ - const char *parentName; /* Regulator parent node name. */ - struct RegulatorConstraints constraints; /* Regulator constraint information. */ - uint32_t minUv; /* Minimum output voltage. */ - uint32_t maxUv; /* Maximum output voltage. */ - uint32_t minUa; /* Minimum output current. */ - uint32_t maxUa; /* Maximum output current. */ - uint32_t status; /* Regulator status, which can be on or off. */ - int useCount; - int consumerRegNums; /* Number of regulator consumers. */ - RegulatorStatusChangecb cb; /* Variable used to notify the regulator status changes. */ - }; - - struct RegulatorConstraints { - uint8_t alwaysOn; /* Whether the regulator is always on. */ - uint8_t mode; /* Voltage or current. */ - uint32_t minUv; /* Minimum output voltage allowed. */ - uint32_t maxUv; /* Maximum output voltage allowed. */ - uint32_t minUa; /* Minimum output current allowed. */ - uint32_t maxUa; /* Maximum output current allowed. */ - }; - ``` - - - Instantiating **RegulatorMethod** (other members are initialized by **Init**) - - ```c - // Example of regulator_virtual.c: Instantiate the hook. - static struct RegulatorMethod g_method = { - .enable = VirtualRegulatorEnable, - .disable = VirtualRegulatorDisable, - .setVoltage = VirtualRegulatorSetVoltage, - .getVoltage = VirtualRegulatorGetVoltage, - .setCurrent = VirtualRegulatorSetCurrent, - .getCurrent = VirtualRegulatorGetCurrent, - .getStatus = VirtualRegulatorGetStatus, - }; - ``` - - - **Init** function - - Input parameters: - - **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - - Return value: - - **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.) - - **Table 2** HDF\_STATUS - - - - - - - - - - - - - - - - - - - - - - - - -

State

-

Description

-

HDF_ERR_INVALID_OBJECT

-

Invalid controller object.

-

HDF_ERR_MALLOC_FAIL

-

Failed to allocate memory.

-

HDF_ERR_INVALID_PARAM

-

Invalid parameter.

-

HDF_ERR_IO

-

I/O error.

-

HDF_SUCCESS

-

Initialization successful.

-

HDF_FAILURE

-

Initialization failed.

-
- Function description: - Initializes the custom structure and **RegulatorNode** members, and adds the regulator controller by calling the **RegulatorNodeAdd** function at the core layer. - - ```c - static int32_t VirtualRegulatorInit(struct HdfDeviceObject *device) - { - int32_t ret; - const struct DeviceResourceNode *childNode = NULL; - ... - DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { - ret = VirtualRegulatorParseAndInit(device, childNode);// (Mandatory) The implementation is as follows: - ... - } - ... - } - - static int32_t VirtualRegulatorParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node) - { - int32_t ret; - struct RegulatorNode *regNode = NULL; - (void)device; - - regNode = (struct RegulatorNode *)OsalMemCalloc(sizeof(*regNode));// Load the .hcs file. - ... - ret = VirtualRegulatorReadHcs(regNode, node);// Read .hcs information. - ... - regNode->priv = (void *)node; // Instantiate the node. - regNode->ops = &g_method; // Instantiate OPS. - - ret = RegulatorNodeAdd(regNode); // Add the node. - ... - } - - - - **Release** function - - Input parameters: - - **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. - - Return value: - - – - - Function description: - - Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. - + } + ``` + + - **regulator\_config.hcs** reference: + + ``` + root { + platform { + regulator_config { + match_attr = "linux_regulator_adapter"; + template regulator_controller { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by device nodes. + device_num = 1; + name = ""; + devName = "regulator_adapter_consumer01"; + supplyName = ""; + mode = 1; + minUv = 0; + maxUv = 20000; + minUa = 0; + maxUa = 0; + } + controller_0x130d0000 :: regulator_controller { + device_num = 1; + name = "regulator_adapter_1"; + devName = "regulator_adapter_consumer01"; + supplyName = "virtual-regulator-hdf-adapter"; + mode = 1; + minUv = 1000; + maxUv = 50000; + minUa = 0; + maxUa = 0; + } + /* Each regulator controller corresponds to a controller node. If there are multiple regulator controllers, add the corresponding controller nodes one by one.*/ + controller_0x130d0001 :: regulator_controller { + device_num = 1; + name = "regulator_adapter_2"; + devName = "regulator_adapter_consumer01"; + supplyName = "virtual2-regulator-hdf-adapter"; + mode = 2; + minUv = 0; + maxUv = 0; + minUa = 1000; + maxUa = 50000; + } + } + } + } + ``` + +3. Instantiate the APIs of the core layer. + + - Initialize the **RegulatorNode** object at the core layer, including initializing the vendor custom structure (passing parameters and data), instantiating **RegulatorMethod** (used to call underlying functions of the driver) in **PinCntlr**, and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**). + + - Initializing the vendor custom structure + + The **RegulatorNode** structure holds parameters and data for the driver. The HDF obtains the values in **regulator\_config.hcs** using **DeviceResourceIface**. + + ``` + // RegulatorNode is the controller structure at the core layer. Its members are assigned with values by using the Init function. + struct RegulatorNode { + struct RegulatorDesc regulatorInfo; + struct DListHead node; + struct RegulatorMethod *ops; + void *priv; + struct OsalMutex lock; + }; + + struct RegulatorDesc { + const char *name; /* Regulator name. */ + const char *parentName; /* Regulator parent node name. */ + struct RegulatorConstraints constraints; /* Regulator constraint information. */ + uint32_t minUv; /* Minimum output voltage. */ + uint32_t maxUv; /* Maximum output voltage. */ + uint32_t minUa; /* Minimum output current. */ + uint32_t maxUa; /* Maximum output current. */ + uint32_t status; /* Regulator status, which can be on or off. */ + int useCount; + int consumerRegNums; /* Number of regulator consumers. */ + RegulatorStatusChangecb cb; /* Variable used to notify the regulator status changes. */ + }; + + struct RegulatorConstraints { + uint8_t alwaysOn; /* Whether the regulator is always on. */ + uint8_t mode; /* Voltage or current. */ + uint32_t minUv; /* Minimum output voltage allowed. */ + uint32_t maxUv; /* Maximum output voltage allowed. */ + uint32_t minUa; /* Minimum output current allowed. */ + uint32_t maxUa; /* Maximum output current allowed. */ + }; + ``` + + + + - Instantiating **RegulatorMethod** (other members are initialized by **Init**) + + ```c + // Example of regulator_virtual.c: Instantiate the hook. + static struct RegulatorMethod g_method = { + .enable = VirtualRegulatorEnable, + .disable = VirtualRegulatorDisable, + .setVoltage = VirtualRegulatorSetVoltage, + .getVoltage = VirtualRegulatorGetVoltage, + .setCurrent = VirtualRegulatorSetCurrent, + .getCurrent = VirtualRegulatorGetCurrent, + .getStatus = VirtualRegulatorGetStatus, + }; + ``` + + + + - **Init** function + + Input parameters: + + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. + + Return value: + + **HDF\_STATUS** (The following table lists some states. For more details, see **HDF\_STATUS** in **/drivers/framework/include/utils/hdf\_base.h**.) + + **Table 2** HDF\_STATUS + + | State | Description | + | ---------------------- | -------------- | + | HDF_ERR_INVALID_OBJECT | Invalid controller object.| + | HDF_ERR_MALLOC_FAIL | Failed to allocate memory. | + | HDF_ERR_INVALID_PARAM | Invalid parameter. | + | HDF_ERR_IO | I/O error. | + | HDF_SUCCESS | Initialization successful. | + | HDF_FAILURE | Initialization failed. | + + Function description: + + Initializes the custom structure and **RegulatorNode** members, and adds the regulator controller by calling the **RegulatorNodeAdd** function at the core layer. + + + ```c + static int32_t VirtualRegulatorInit(struct HdfDeviceObject *device) + { + int32_t ret; + const struct DeviceResourceNode *childNode = NULL; + ... + DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) { + ret = VirtualRegulatorParseAndInit(device, childNode);// (Mandatory) The implementation is as follows: + ... + } + ... + } + + static int32_t VirtualRegulatorParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node) + { + int32_t ret; + struct RegulatorNode *regNode = NULL; + (void)device; + + regNode = (struct RegulatorNode *)OsalMemCalloc(sizeof(*regNode));// Load the .hcs file. + ... + ret = VirtualRegulatorReadHcs(regNode, node);// Read .hcs information. + ... + regNode->priv = (void *)node; // Instantiate the node. + regNode->ops = &g_method; // Instantiate OPS. + + ret = RegulatorNodeAdd(regNode); // Add the node. + ... + } + ``` + + - **Release** function + + Input parameters: + + **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration. + + Return value: + + – + + Function description: + + Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init()** function to initialize the driver, the **Release()** function can be called to release driver resources. + ```c static void VirtualRegulatorRelease(struct HdfDeviceObject *device) { ... RegulatorNodeRemoveAll();// (Mandatory) Call the function at the core layer to release regulator controller devices and services. } + ``` + +4. Debug the driver. + + (Optional) Verify the basic functions of the new driver, for example, whether the test cases are successful after the driver is loaded. + + diff --git a/en/device-dev/driver/driver-platform.md b/en/device-dev/driver/driver-platform.md index 6001bec2a5a8ba9ece5ec83141b85987e9ccd543..3a41a94032a8661dc459dd8bda1a6956b87c567d 100644 --- a/en/device-dev/driver/driver-platform.md +++ b/en/device-dev/driver/driver-platform.md @@ -2,6 +2,8 @@ - **[ADC](driver-platform-adc-des.md)** +- **[DAC](driver-platform-dac-des.md)** + - **[GPIO](driver-platform-gpio-des.md)** - **[HDMI](driver-platform-hdmi-des.md)** @@ -14,6 +16,8 @@ - **[MIPI DSI](driver-platform-mipidsi-des.md)** +- **[Pin](driver-platform-pin-des.md)** + - **[PWM](driver-platform-pwm-des.md)** - **[RTC](driver-platform-rtc-des.md)** diff --git a/en/device-dev/driver/figures/ADM_control_flowchart.png b/en/device-dev/driver/figures/ADM_control_flowchart.png index 5f0b075983cb6cea46c33e15c9abbeeb0ea7bdd0..22bb3efec06976c56ffac38f1fae9b128951d817 100644 Binary files a/en/device-dev/driver/figures/ADM_control_flowchart.png and b/en/device-dev/driver/figures/ADM_control_flowchart.png differ diff --git a/en/device-dev/driver/figures/ADM_playback_flowchart.png b/en/device-dev/driver/figures/ADM_playback_flowchart.png index ceed4237ad2033c06db504165a3f5fd75fbd46c2..1863ab056a1e0f9a9e344b14005cfd09e645bc5d 100644 Binary files a/en/device-dev/driver/figures/ADM_playback_flowchart.png and b/en/device-dev/driver/figures/ADM_playback_flowchart.png differ diff --git a/en/device-dev/driver/figures/ADM_startup_flowchart.png b/en/device-dev/driver/figures/ADM_startup_flowchart.png index db07e421198faf154f30682c63e2b7b361ae3cf6..cf921d8db2ed82bd5e46628fd34bb0066262213f 100644 Binary files a/en/device-dev/driver/figures/ADM_startup_flowchart.png and b/en/device-dev/driver/figures/ADM_startup_flowchart.png differ diff --git a/en/device-dev/driver/figures/Audio_architecture.png b/en/device-dev/driver/figures/Audio_architecture.png index 19c24f59eed43828f00f4bbff012b0e087fb927a..a419414b829274b2163f9a7581dc201ae33c28c9 100644 Binary files a/en/device-dev/driver/figures/Audio_architecture.png and b/en/device-dev/driver/figures/Audio_architecture.png differ diff --git a/en/device-dev/driver/figures/HAL_flowchart.png b/en/device-dev/driver/figures/HAL_flowchart.png index f477dbceaf5c76b29d3c40f3912e00dbdb617e86..edf3571475b3c61e4141f72634c72a93c818a0e9 100644 Binary files a/en/device-dev/driver/figures/HAL_flowchart.png and b/en/device-dev/driver/figures/HAL_flowchart.png differ diff --git a/en/device-dev/driver/figures/audio_development_flowchart_1.png b/en/device-dev/driver/figures/audio_development_flowchart_1.png new file mode 100644 index 0000000000000000000000000000000000000000..55e738ca04394030d07308a58a3327e08264c30d Binary files /dev/null and b/en/device-dev/driver/figures/audio_development_flowchart_1.png differ diff --git a/en/device-dev/driver/figures/audio_development_flowchart_2.png b/en/device-dev/driver/figures/audio_development_flowchart_2.png new file mode 100644 index 0000000000000000000000000000000000000000..b3d369dae4e221b0651c2de1c93b78e85fdf3bc8 Binary files /dev/null and b/en/device-dev/driver/figures/audio_development_flowchart_2.png differ diff --git a/en/device-dev/driver/figures/camera-driver-model-architecture.png b/en/device-dev/driver/figures/camera-driver-model-architecture.png index 772356a3efede5b1b8b45b27270ed79fcf9e9d01..1a4fa27e98e5bb4568be1399b57da3b987ee4fbf 100644 Binary files a/en/device-dev/driver/figures/camera-driver-model-architecture.png and b/en/device-dev/driver/figures/camera-driver-model-architecture.png differ diff --git a/en/device-dev/driver/figures/development_flowchart_1.png b/en/device-dev/driver/figures/development_flowchart_1.png deleted file mode 100644 index 16c6571b586b28f19ca8db4626c65fb3fcb65c1a..0000000000000000000000000000000000000000 Binary files a/en/device-dev/driver/figures/development_flowchart_1.png and /dev/null differ diff --git a/en/device-dev/driver/figures/development_flowchart_2.png b/en/device-dev/driver/figures/development_flowchart_2.png deleted file mode 100644 index bd820389e4e5f5e8ee39e3d5208513c20a64d494..0000000000000000000000000000000000000000 Binary files a/en/device-dev/driver/figures/development_flowchart_2.png and /dev/null differ diff --git a/en/device-dev/driver/figures/independent-service-mode.png b/en/device-dev/driver/figures/independent-service-mode.png index c1457af7a0512dbd08436c3dd9d24654c200b85a..18aa5b9a3eba056449451df1a947dbfc955ff2ba 100644 Binary files a/en/device-dev/driver/figures/independent-service-mode.png and b/en/device-dev/driver/figures/independent-service-mode.png differ diff --git a/en/device-dev/driver/figures/process-of-using-DAC.png b/en/device-dev/driver/figures/process-of-using-DAC.png new file mode 100644 index 0000000000000000000000000000000000000000..7a62db53a3683922d4033ae4cde5e29d3d50fa22 Binary files /dev/null and b/en/device-dev/driver/figures/process-of-using-DAC.png differ diff --git a/en/device-dev/driver/figures/process-of-using-pin.png b/en/device-dev/driver/figures/process-of-using-pin.png new file mode 100644 index 0000000000000000000000000000000000000000..99ffa63309566dcdb8a71e4dff92e6791a0bfe6b Binary files /dev/null and b/en/device-dev/driver/figures/process-of-using-pin.png differ diff --git a/en/device-dev/driver/figures/service-free-mode.png b/en/device-dev/driver/figures/service-free-mode.png index b6e5bd670bfa33120969b239d7564cff888a8fc3..99ae0d286999397706fc4d6efa79ac6ba9651848 100644 Binary files a/en/device-dev/driver/figures/service-free-mode.png and b/en/device-dev/driver/figures/service-free-mode.png differ diff --git a/en/device-dev/driver/figures/unified-service-mode.png b/en/device-dev/driver/figures/unified-service-mode.png index 6e922299f648f02da320ed101119f1a1698bc609..fc024f6e999c5e453e23392cb1163bc26f0669fc 100644 Binary files a/en/device-dev/driver/figures/unified-service-mode.png and b/en/device-dev/driver/figures/unified-service-mode.png differ diff --git a/en/device-dev/get-code/Readme-EN.md b/en/device-dev/get-code/Readme-EN.md index 5f5dacc4a6cefdf06912a3046c6350a95ff40c5c..c9774a3987b5b7db5cb445dad70bb8ca742a5729 100644 --- a/en/device-dev/get-code/Readme-EN.md +++ b/en/device-dev/get-code/Readme-EN.md @@ -1,7 +1,7 @@ # Source Code Acquisition -- [Source Code Acquisition](sourcecode-acquire.md) -- [Tool Acquisition](gettools.md) - - [Docker Environment](gettools-acquire.md) - - [IDE](gettools-ide.md) - +- [Obtaining Source Code](sourcecode-acquire.md) +- Obtaining Tools + - [Overview](gettools-overview.md) + - [Docker Environments](gettools-acquire.md) + - [IDE](gettools-ide.md) diff --git a/en/device-dev/get-code/figure/hpm-page.png b/en/device-dev/get-code/figure/hpm-page.png index 7302e20d86e44d331d79e3aa15e58ded5b860088..00d07cde7f61182497bc615d0fcb95db71241e04 100644 Binary files a/en/device-dev/get-code/figure/hpm-page.png and b/en/device-dev/get-code/figure/hpm-page.png differ diff --git a/en/device-dev/get-code/gettools-acquire.md b/en/device-dev/get-code/gettools-acquire.md index 15c242defe4dddc26856e1a8132ff1e5c0df07f8..c47f2c8f37a7704e2d74539d80dc9e47489ace04 100644 --- a/en/device-dev/get-code/gettools-acquire.md +++ b/en/device-dev/get-code/gettools-acquire.md @@ -166,7 +166,7 @@ Files generated during building are stored in the **out/{device_name}/** direc ## HPM-based Docker Environment -**docker\_dist** is a template component in the [HPM](https://hpm.harmonyos.com/#/en/home) system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and [hpm-cli](../bundles/hpm-part-development.md) development environments, perform the following steps to access the Docker environment: +**docker\_dist** is a template component in the [HPM](https://hpm.harmonyos.com/#/en/home) system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and hpm-cli development environments, perform the following steps to access the Docker environment: ### Setting Up the Docker Environment diff --git a/en/device-dev/get-code/gettools-ide.md b/en/device-dev/get-code/gettools-ide.md index fe65c0b2faf9b9191d4c76a20f3edaa22c2bde54..66424495ac87c5d28098358d41a6db7644ff2743 100644 --- a/en/device-dev/get-code/gettools-ide.md +++ b/en/device-dev/get-code/gettools-ide.md @@ -1,14 +1,11 @@ -# IDE +# IDE -## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\) +## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\) HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE\) provided to develop applications for OpenHarmony devices. It allows on-demand customization of OpenHarmony components, code editing, building, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see [HUAWEI DevEco Device Tool](https://device.harmonyos.com/en/ide) and [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905). -The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below. -![](figure/evolution-roadmap.png) +## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\) -## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\) - -HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio) and [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). +HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio) and [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-deveco-studio-overview-0000001263280421). diff --git a/en/device-dev/get-code/gettools-overview.md b/en/device-dev/get-code/gettools-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..9b0e63ba4face13990aaefa6b4e512825fd5c7a0 --- /dev/null +++ b/en/device-dev/get-code/gettools-overview.md @@ -0,0 +1,10 @@ +# Overview + +To streamline your device development process, OpenHarmony provides the useful tools listed below. + +**Table 1** Tools for device development + +| Tool | Description | Related Resources| +| ---- | ------ | ------ | +| DevEco Device Tool | A one-stop integrated development environment (IDE) provided for developers of OpenHarmony-powered smart devices. It allows on-demand component customization, as well as code editing, compilation, burning, and debugging. The tool supports C and C++ languages and can be installed in Visual Studio Code as a plug-in.| [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/documentation/guide/service_introduction-0000001050166905)| +| Docker | A containerization platform used to build and containerize applications. The Docker environments in OpenHarmony encapsulate compilation toolchains for different OpenHarmony variants, so you can start your building straightaway without having to install the compilation toolchain on your own.| [Docker Environment](gettools-acquire.md)| diff --git a/en/device-dev/get-code/sourcecode-acquire.md b/en/device-dev/get-code/sourcecode-acquire.md index 4561cc2511ddf645fb2b4e5a533d85ef6bf93f83..217270c5bdfa93b12dd1b9f52e64add2053d1015 100644 --- a/en/device-dev/get-code/sourcecode-acquire.md +++ b/en/device-dev/get-code/sourcecode-acquire.md @@ -4,16 +4,16 @@ OpenHarmony is an open-source project launched by the OpenAtom Foundation. The purpose of this project is to build an open, distributed operating system \(OS\) framework for smart IoT devices in the full-scenario, full-connectivity, and full-intelligence era. -The open-source code repositories are available at [https://openharmony.gitee.com](https://openharmony.gitee.com). +The open-source code repositories are available at [https://openharmony.gitee.com](https://openharmony.gitee.com). ## Overview of Source Code Acquisition You can use any of the following methods to acquire the OpenHarmony source code: -- **Method 1**: Acquire the source code from the Gitee code repository. You can use the **repo** or **git** tool to download the latest code from the code repository. -- **Method 2**: Acquire the source code from [DevEco Marketplace](https://repo.harmonyos.com/#/en/home). Visit [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), search for your desired open-source distribution, and download the bundle list \(or customize bundles and download the bundle list\). Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC. +- **Method 1**: Acquire the source code from the Gitee code repository. You can use the **repo** or **git** tool to download the latest code from the code repository. +- **Method 2**: Acquire the source code from [DevEco Marketplace](https://repo.harmonyos.com/#/en/home). Visit [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), search for your desired open-source distribution, and download the bundle list \(or customize bundles and download the bundle list\). Then use the **hpm-cli** tool to download and install the bundles and compilation toolchain on your local PC. - **Method 3**: Download the compressed file of a distribution from a mirror site. This method provides a fast download speed, so you can also use this method for obtaining the source code of an earlier version. -- **Method 4**: Acquire the source code from the GitHub image repository. You can use the **repo** or **git** tool to download the latest code from the code repository. +- **Method 4**: Acquire the source code from the GitHub image repository. You can use the **repo** or **git** tool to download the latest code from the code repository. ## Method 1: Acquiring Source Code from the Gitee Code Repository @@ -34,7 +34,7 @@ You can use any of the following methods to acquire the OpenHarmony source code: 1. Register your account with Gitee. 2. Register an SSH public key for access to Gitee. -3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. +3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. ``` git config --global user.name "yourname" @@ -42,10 +42,10 @@ You can use any of the following methods to acquire the OpenHarmony source code: git config --global credential.helper store ``` -4. Run the following commands to install the **repo** tool: +4. Run the following commands to install the **repo** tool: ``` - curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. chmod a+x /usr/local/bin/repo pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests ``` @@ -53,14 +53,13 @@ You can use any of the following methods to acquire the OpenHarmony source code: ### How to Use -**Obtaining the Source Code for Mini/Small/Standard Systems** ->![](../public_sys-resources/icon-note.gif) **NOTE:** +>![](../public_sys-resources/icon-note.gif) **NOTE** >Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. - **Obtaining OpenHarmony master code** - Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) ``` repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify @@ -68,7 +67,7 @@ You can use any of the following methods to acquire the OpenHarmony source code: repo forall -c 'git lfs pull' ``` - Method 2: Use the **repo** tool to download the source code over HTTPS. + Method 2: Use the **repo** tool to download the source code over HTTPS. ``` repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify @@ -78,26 +77,26 @@ You can use any of the following methods to acquire the OpenHarmony source code: - **Obtaining OpenHarmony release code** - For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). ## Method 2: Acquiring Source Code from DevEco Marketplace ### When to Use -If OpenHarmony is new to you, sample solutions are helpful to your development. You can obtain an open-source distribution from [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), or customize a distribution by adding or deleting bundles of an open-source distribution. Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC. +If OpenHarmony is new to you, sample solutions are helpful to your development. You can obtain an open-source distribution from [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), or customize a distribution by adding or deleting bundles of an open-source distribution. Then use the **hpm-cli** tool to download and install the bundles and compilation toolchain on your local PC. ### Prerequisites -You must install **Node.js** and HPM on your local PC. The installation procedure is as follows: +You must install **Node.js** and HPM on your local PC. The installation procedure is as follows: -1. Install **Node.js**. +1. Install **Node.js**. - Download **Node.js** from its official website and install it on your local PC. + Download **Node.js** from its official website and install it on your local PC. - The [Node.js](https://nodejs.org/) version must be 12.x \(including npm 6.14.4\) or later. An LTS version is recommended. + The [Node.js](https://nodejs.org/) version must be 12.x \(including npm 6.14.4\) or later. An LTS version is recommended. -2. Install the hpm-cli tool using **npm** delivered with **Node.js**. +2. Install the **hpm-cli** tool using **npm** delivered with **Node.js**. Open the CMD window and run the following command: @@ -121,54 +120,54 @@ You must install **Node.js** and HPM on your local PC. The installation proced ### How to Use 1. Search for distributions. - 1. Access [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), and click **Equipment Bundle**. - 2. Enter a keyword, for example, **camera**, in the search box, and click the search icon. All matched distributions will be displayed on the **Open Source Distribution** page. - 3. Specify filter criteria, such as the category, OS, kernel, and board, to further filter the distributions. + 1. Access [DevEco Marketplace](https://repo.harmonyos.com/#/en/home), and click **Equipment Bundle**. Then go to the **Open Source Distribution** page. + 2. Enter a keyword \(for example: **camera**\) in the search box. All matched distributions are found. + 3. Specify filter criteria, such as the bundle type \(for example: **Board support** or **Kernel support**\), to further filter the distributions. 4. Find your desired distribution and click it to view details. - **Figure 1** HPM page + **Figure 1** HPM page ![](figure/hpm-page.png "hpm-page") 2. Learn more about the distribution. - 1. Read the information about the distribution to learn its application scenarios, features, bundles, usage, and customization methods, as shown in the following figure. - 2. Click **Download** to download the distribution to your local PC. - 3. Click **Custom** to add or delete bundles of the distribution. + 1. Read carefully the information about the distribution to learn its application scenarios, features, bundles, usage, and customization methods, as shown in the following figure. + 2. Click **Download** if you want to download the distribution to your local PC. + 3. Click **Custom** if you want to add or delete bundles of the distribution. - **Figure 2** Example distribution - ![](figure/example-distribution.png "example-distribution") + **Figure 2** Example distribution + ![](figure/example-distribution.png "example-distribution") 3. Customize bundles. - 1. Access the **Custom solution** page, as shown in the following figure. - 2. Set the toggle switch next to a specific optional bundle to delete it from the distribution, or click **Add bundle** to add new bundles. + 1. Access the **Custom solution** page, as shown in the following figure. + 2. Set the toggle switch next to a specific optional bundle to delete it from the distribution, or click **Add bundle** to add new bundles. 3. Enter the basic information about your project, including the bundle name, version, and description, on the right pane. - 4. Click **Download**. The system then generates the OpenHarmony code structure file \(for example, **my\_cust\_dist.zip**\) and saves it to your local PC. + 4. Click **Download**. The system generates the OpenHarmony code structure file \(for example, **my\_cust\_dist.zip**\) and saves it to your local PC. - **Figure 3** Customizing bundles + **Figure 3** Customizing bundles ![](figure/customizing-bundles.png "customizing-bundles") 4. Install bundles. - 1. Decompress the downloaded code structure file using CMD on Windows \(or shell in Linux\). - 2. In the generated directory, run the **hpm install** command to download and install bundles. If the **Install successful** message is displayed, the command has been executed successfully. - 3. The downloaded bundles will be stored in the **ohos\_bundles** folder under the project directory. \(The source code of some bundles will be copied to a specified directory after the bundles are installed.\) + 1. Decompress the downloaded code structure file using CMD on Windows (or shell in Linux). + 2. In the generated directory, run the **hpm install** command to download and install bundles. If the **Install successful** message is displayed, the command has been executed successfully. + 3. Obtain the bundles. The downloaded bundles are stored in the **ohos\_bundles** folder under the project directory. \(The source code of some bundles will be copied to a specified directory after the bundles are installed.\) ## Method 3: Acquiring Source Code from a Mirror Site To ensure the download performance, you are advised to download the source code or the corresponding solution from the image library of the respective site listed in the table below. -The table below provides only the sites for downloading the latest OpenHarmony master and LTS code. For details about how to obtain the source code of earlier versions, see the [Release-Notes](../../release-notes/Readme.md). +The table below provides only the sites for downloading the latest OpenHarmony LTS code. For details about how to obtain the source code of earlier versions, see the [Release-Notes](../../release-notes/Readme.md). -**Table 1** Sites for acquiring source code +**Table 1** Sites for acquiring source code - -

LTS Code

+ - - - @@ -235,85 +234,85 @@ The table below provides only the sites for downloading the latest OpenHarmony m - - - - - - - - - - - - - - - - - - - - - - - - - - - -

LTS Code

Version Information

+

Version Information

Site

+

Site

SHA-256 Verification Code

+

SHA-256 Verification Code

-

Master Code

+

Latest Release Code

Version Information

+

Version Information

Site

+

Site

SHA-256 Verification Code

+

SHA-256 Verification Code

Full code base (for mini, small, and standard systems)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

Hi3516 standard system solution (binary)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

RK3568 standard system solution (binary)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

Hi3861 solution (binary)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

Hi3516 solution-LiteOS (binary)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

Hi3516 solution-Linux (binary)

3.1 Beta

+

3.1 Release

Download

+

Download

Download

+

Download

RELEASE-NOTES

3.1 Beta

+

3.1 Release

Download

+

Download

-

Compiler Toolchain

+

Compiler Toolchain

Version Information

+

Version Information

Site

+

Site

SHA-256 Verification Code

+

SHA-256 Verification Code

Compiler toolchain

@@ -328,9 +327,12 @@ The table below provides only the sites for downloading the latest OpenHarmony m
-## Method 4: Acquiring Source Code from the GitHub Image Repository \(at 23:00 UTC Every Day\) +## Method 4: Acquiring Source Code from the GitHub Image Repository -Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to GitHub. For details, see [Adding a new SSH key to your GitHub account](https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).\) +>![](../public_sys-resources/icon-note.gif) **NOTE** +> The image repository is synchronized at 23:00 (UTC +8:00) every day. + +Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to GitHub. For details, see [Adding a new SSH key to your GitHub account](https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).\) ``` repo init -u git@github.com:openharmony/manifest.git -b master --no-repo-verify @@ -338,7 +340,7 @@ repo sync -c repo forall -c 'git lfs pull' ``` -Method 2: Use the **repo** tool to download the source code over HTTPS. +Method 2: Use the **repo** tool to download the source code over HTTPS. ``` repo init -u https://github.com/openharmony/manifest.git -b master --no-repo-verify @@ -350,7 +352,7 @@ repo forall -c 'git lfs pull' The following table describes the OpenHarmony source code directories. -**Table 2** Source code directories +**Table 2** Source code directories - -

Name

@@ -371,7 +373,7 @@ The following table describes the OpenHarmony source code directories.

build

Bundle-based compilation, building, and configuration scripts

+

Bundle-based compilation, build, and configuration scripts

docs

@@ -401,7 +403,7 @@ The following table describes the OpenHarmony source code directories.

prebuilts

Compiler and tool chain subsystem

+

Compiler and toolchain subsystem

test

@@ -431,4 +433,3 @@ The following table describes the OpenHarmony source code directories.
- diff --git a/en/device-dev/bundles/Readme-EN.md b/en/device-dev/hpm-part/Readme-EN.md similarity index 92% rename from en/device-dev/bundles/Readme-EN.md rename to en/device-dev/hpm-part/Readme-EN.md index 3dd1fea2823e1f25a09b0233a632a61f028fb216..4a2f172c3c5d6917d2890edfbdeea401b72285e3 100644 --- a/en/device-dev/bundles/Readme-EN.md +++ b/en/device-dev/hpm-part/Readme-EN.md @@ -1,4 +1,4 @@ -# Bundles +# HPM Part - [HPM Part Overview](hpm-part-about.md) - [HPM Part Development](hpm-part-development.md) diff --git a/en/device-dev/bundles/figures/en-us_image_0000001195369804.png b/en/device-dev/hpm-part/figures/en-us_image_0000001195369804.png similarity index 100% rename from en/device-dev/bundles/figures/en-us_image_0000001195369804.png rename to en/device-dev/hpm-part/figures/en-us_image_0000001195369804.png diff --git a/en/device-dev/bundles/figures/en-us_image_0000001217486680.png b/en/device-dev/hpm-part/figures/en-us_image_0000001217486680.png similarity index 100% rename from en/device-dev/bundles/figures/en-us_image_0000001217486680.png rename to en/device-dev/hpm-part/figures/en-us_image_0000001217486680.png diff --git a/en/device-dev/bundles/figures/en-us_image_0000001240409717.png b/en/device-dev/hpm-part/figures/en-us_image_0000001240409717.png similarity index 100% rename from en/device-dev/bundles/figures/en-us_image_0000001240409717.png rename to en/device-dev/hpm-part/figures/en-us_image_0000001240409717.png diff --git a/en/device-dev/bundles/figures/en-us_image_0000001262166533.png b/en/device-dev/hpm-part/figures/en-us_image_0000001262166533.png similarity index 100% rename from en/device-dev/bundles/figures/en-us_image_0000001262166533.png rename to en/device-dev/hpm-part/figures/en-us_image_0000001262166533.png diff --git a/en/device-dev/bundles/hpm-part-about.md b/en/device-dev/hpm-part/hpm-part-about.md similarity index 100% rename from en/device-dev/bundles/hpm-part-about.md rename to en/device-dev/hpm-part/hpm-part-about.md diff --git a/en/device-dev/bundles/hpm-part-development.md b/en/device-dev/hpm-part/hpm-part-development.md similarity index 100% rename from en/device-dev/bundles/hpm-part-development.md rename to en/device-dev/hpm-part/hpm-part-development.md diff --git a/en/device-dev/bundles/hpm-part-reference.md b/en/device-dev/hpm-part/hpm-part-reference.md similarity index 94% rename from en/device-dev/bundles/hpm-part-reference.md rename to en/device-dev/hpm-part/hpm-part-reference.md index 758dc8cea9eb0196c5cd90a4a63c5b0ec1441e24..1df7f05079cae2c7eb05efb377bec8e88d722de7 100644 --- a/en/device-dev/bundles/hpm-part-reference.md +++ b/en/device-dev/hpm-part/hpm-part-reference.md @@ -157,22 +157,22 @@ You can use the hpm-cli tool to manage the lifecycle of an HPM Part. The followi | -------- | -------- | -------- | | Querying version information| **hpm -V** or **hpm --version**| Displays the version of the hpm-cli tool.| | Querying help information| **hpm -h** or **hpm --version**| Displays the command list and help information.| -| hpm -h | Displays command help information.| +|| hpm -h | Displays command help information.| | Creating a project| hpm init bundle | Creates an HPM Part project.| -| hpm init -t template | Creates a scaffolding project from a template.| +|| hpm init -t template | Creates a scaffolding project from a template.| | Installing HPM Parts| **hpm install** or **hpm i**| Installs dependent HPM Parts in the bundle.json file.| -| hpm install bundle\@version | Installs HPM Parts of a specified version.| +|| hpm install bundle\@version | Installs HPM Parts of a specified version.| | Uninstalling HPM Parts| hpm uninstall bundle | Uninstalls dependent HPM Parts.| -| **hpm remove** or **hpm rm bundlename**| Uninstalls dependent HPM Parts.| +|| **hpm remove** or **hpm rm bundlename**| Uninstalls dependent HPM Parts.| | Viewing information| **hpm list** or **hpm ls**| Displays the dependency tree of the HPM part.| -| hpm dependencies | Generates the dependency relationship data of the HPM Part. (This command is also integrated in the **hpm ui** command. After you run the hpm ui command, a hpm UI is displayed with the dependencies.)| +|| hpm dependencies | Generates the dependency relationship data of the HPM Part. (This command is also integrated in the **hpm ui** command. After you run the hpm ui command, a hpm UI is displayed with the dependencies.)| | Searching for HPM Parts| hpm search name | Searches for HPM Parts. **--json** is used to specify the search result in JSON format, and **-type** is used to set the target type, which can be **part**, **distribution**, or **code-segment**.| | Setting HPM configuration items| hpm config set key value | Sets configuration items, such as the server address and network proxy.| -| hpm config delete key | Deletes configurations.| +|| hpm config delete key | Deletes configurations.| | Updating HPM Part versions| hpm update | Updates the versions of dependent HPM Parts.| -| hpm check-update | Checks whether version updates are available to dependent HPM Parts.| +|| hpm check-update | Checks whether version updates are available to dependent HPM Parts.| | Building| hpm build | Builds an HPM Part.| -| hpm dist | Builds a distribution. The build depends on the **dist** script in **scripts** of **bundle.json**.| +|| hpm dist | Builds a distribution. The build depends on the **dist** script in **scripts** of **bundle.json**.| | Packing | hpm pack | Packs dependencies of local HPM Parts.| | Burning| hpm run flash | Burns the firmware. The firmware burning depends on the **flash** script in **scripts** of **bundle.json**.| | Publishing| hpm publish | Publishes an HPM Part, which must be unique in the repository and has a unique version. (An account is required for login.)| @@ -242,7 +242,7 @@ HPM Part dependencies (including indirect dependencies) can be displayed by runn ``` $ hpm list +--demo@1.0.0 -| +--@huawei/media@1.0.2 +| +--@example/media@1.0.2 | +--@demo/sport_hi3518ev300_liteos_a@1.0.0 | | +--@demo/app@4.0.1 | | | +--@demo/build@4.0.1 diff --git a/en/device-dev/bundles/public_sys-resources/icon-caution.gif b/en/device-dev/hpm-part/public_sys-resources/icon-caution.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-caution.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-caution.gif diff --git a/en/device-dev/bundles/public_sys-resources/icon-danger.gif b/en/device-dev/hpm-part/public_sys-resources/icon-danger.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-danger.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-danger.gif diff --git a/en/device-dev/bundles/public_sys-resources/icon-note.gif b/en/device-dev/hpm-part/public_sys-resources/icon-note.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-note.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-note.gif diff --git a/en/device-dev/bundles/public_sys-resources/icon-notice.gif b/en/device-dev/hpm-part/public_sys-resources/icon-notice.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-notice.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-notice.gif diff --git a/en/device-dev/bundles/public_sys-resources/icon-tip.gif b/en/device-dev/hpm-part/public_sys-resources/icon-tip.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-tip.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-tip.gif diff --git a/en/device-dev/bundles/public_sys-resources/icon-warning.gif b/en/device-dev/hpm-part/public_sys-resources/icon-warning.gif similarity index 100% rename from en/device-dev/bundles/public_sys-resources/icon-warning.gif rename to en/device-dev/hpm-part/public_sys-resources/icon-warning.gif diff --git a/en/device-dev/kernel/Readme-EN.md b/en/device-dev/kernel/Readme-EN.md index 767d2dec0d26babadafbd99c08c9fa1dbdaf4ad1..87197a93f35151ec462438d991ac14185da1115d 100644 --- a/en/device-dev/kernel/Readme-EN.md +++ b/en/device-dev/kernel/Readme-EN.md @@ -172,5 +172,10 @@ - [Kernel for Standard Systems](kernel-standard.md) - [Linux Kernel Overview](kernel-standard-overview.md) - - [Applying Patches on OpenHarmony Development Boards](kernel-standard-patch.md) - - [Guidelines for Building the Linux Kernel](kernel-standard-build.md) \ No newline at end of file + - [Applying Patches on Development Boards](kernel-standard-patch.md) + - [Compiling and Building the Linux Kernel](kernel-standard-build.md) + - [Enhanced Kernel Features](kernel-standard-enhanced-features.md) + - [Enhanced SWAP](kernel-standard-mm-eswap.md) + - [Task Scheduling](kernel-standard-sched.md) + - [Related Thread Group](kernel-standard-sched-rtg.md) + - [Lightweight CPU Isolation](kernel-standard-sched-cpuisolation.md) \ No newline at end of file diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md b/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md index 999d74f2353796b4c9473efcd2c67843f041555b..acd6995c267e242844ddb63a5f0cf847a0cb69ce 100644 --- a/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md @@ -1,16 +1,5 @@ # Queue -- [Basic Concepts](#section5747112216469) -- [Working Principles](#section1582619446311) - - [Queue Control Block](#section1648304614720) - - [Working Principles](#section15384012164811) - -- [Available APIs](#section158501652121514) -- [How to Develop](#section783435801510) -- [Development Example](#section460018317164) - - [Example Description](#section2148236125814) - - [Sample Code](#section121451047155716) - - [Verification](#section2742182082117) ## Basic Concepts @@ -19,7 +8,7 @@ A queue, also called a message queue, is a data structure used for communication Tasks can read messages from a queue. When the queue has no messages, the tasks are suspended. When the queue has a new message, the suspended tasks are woken up and process the new message. Tasks can also write messages to the queue. When the queue is full, the write task is suspended. When there is an available message node in the queue, the suspended write task is woken up and writes a message. -You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. +You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. An asynchronous processing mechanism is provided to allow messages in a queue not to be processed immediately. In addition, queues can be used to buffer messages and implement asynchronous task communication. Queues have the following features: @@ -64,12 +53,12 @@ Each queue control block contains information about the queue status. ### Working Principles - The queue ID is returned if a queue is created successfully. -- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. -- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. -- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is** 0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. -- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. +- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. +- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. +- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is **0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. +- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. -**Figure 1** Reading and writing data in a queue +**Figure 1** Reading and writing data in a queue ![](figures/reading-and-writing-data-in-a-queue.png "reading-and-writing-data-in-a-queue") The preceding figure illustrates how to write data to the tail node only. Writing data to the head node is similar. @@ -143,20 +132,20 @@ The preceding figure illustrates how to write data to the tail node only. Writin ## How to Develop -1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. -2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. -3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. -4. Call **LOS\_QueueInfoGet** to obtain queue information. -5. Call **LOS\_QueueDelete** to delete the queue. +1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. +2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. +3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. +4. Call **LOS\_QueueInfoGet** to obtain queue information. +5. Call **LOS\_QueueDelete** to delete the queue. >![](../public_sys-resources/icon-note.gif) **NOTE:** >- The maximum number of queues supported by the system is the total number of queue resources of the system, not the number of queue resources available to users. For example, if the system software timer occupies one more queue resource, the number of queue resources available to users decreases by one. >- The input parameters queue name and flags passed when a queue is created are reserved for future use. ->- The input parameter **timeOut** in the queue interface function is relative time. ->- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. ->- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. ->- If the input parameter bufferSize in **LOS\_QueueReadCopy** is less than the actual length of the message, the message will be truncated. ->- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. +>- The input parameter **timeOut** in the queue interface function is relative time. +>- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. +>- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. +>- If the input parameter **bufferSize** in **LOS\_QueueReadCopy** is less than the length of the message, the message will be truncated. +>- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. ## Development Example @@ -164,11 +153,11 @@ The preceding figure illustrates how to write data to the tail node only. Writin Create a queue and two tasks. Enable task 1 to call the queue write API to send messages, and enable task 2 to receive messages by calling the queue read API. -1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. -2. Create a message queue by calling **LOS\_QueueCreate**. -3. Enable messages to be sent in task 1 by calling **SendEntry**. -4. Enable messages to be received in task 2 by calling **RecvEntry**. -5. Call **LOS\_QueueDelete** to delete the queue. +1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. +2. Create a message queue by calling **LOS\_QueueCreate**. +3. Enable messages to be sent in task 1 by calling **SendEntry**. +4. Enable messages to be received in task 2 by calling **RecvEntry**. +5. Call **LOS\_QueueDelete** to delete the queue. ### Sample Code diff --git a/en/device-dev/kernel/kernel-small-basic-trans-queue.md b/en/device-dev/kernel/kernel-small-basic-trans-queue.md index c917ed6d2fb79df1bd7efbbc9c6cb6aff1e0c0f5..f266c92e27c7768a53610842f8fc0d3e2ba2699d 100644 --- a/en/device-dev/kernel/kernel-small-basic-trans-queue.md +++ b/en/device-dev/kernel/kernel-small-basic-trans-queue.md @@ -1,19 +1,5 @@ # Queue -- [Basic Concepts](#section81171363232) -- [Working Principles](#section1074515132316) - - [Queue Control Block](#section194431851201315) - - [Working Principles](#section89875741418) - -- [Development Guidelines](#section827981242419) - - [Available APIs](#section19327151642413) - - [How to Develop](#section1390154210243) - -- [Development Example](#section27132341285) - - [Example Description](#section197311443141017) - - [Sample Code](#section972214490107) - - [Verification](#section19287165416106) - ## Basic Concepts @@ -21,7 +7,7 @@ A queue, also called a message queue, is a data structure used for communication Tasks can read messages from a queue. When the queue has no messages, the tasks are suspended. When the queue has a new message, the suspended tasks are woken up and process the new message. Tasks can also write messages to the queue. When the queue is full, the write task is suspended. When there is an available message node in the queue, the suspended write task is woken up and writes a message. -You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. +You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. An asynchronous processing mechanism is provided to allow messages in a queue not to be processed immediately. In addition, queues can be used to buffer messages and implement asynchronous task communication. Queues have the following features: @@ -63,12 +49,12 @@ Each queue control block contains information about the queue status. ### Working Principles - The queue ID is returned if a queue is created successfully. -- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. -- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. -- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is** 0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. -- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. +- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. +- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. +- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is** 0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. +- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. -**Figure 1** Reading and writing data in a queue +**Figure 1** Reading and writing data in a queue ![](figures/reading-and-writing-data-in-a-queue-3.png "reading-and-writing-data-in-a-queue-3") The preceding figure illustrates how to write data to the tail node only. Writing data to the head node is similar. @@ -144,20 +130,20 @@ The preceding figure illustrates how to write data to the tail node only. Writin ### How to Develop -1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. -2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. -3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. -4. Call **LOS\_QueueInfoGet** to obtain queue information. -5. Call **LOS\_QueueDelete** to delete a queue. +1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. +2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. +3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. +4. Call **LOS\_QueueInfoGet** to obtain queue information. +5. Call **LOS\_QueueDelete** to delete a queue. >![](../public_sys-resources/icon-note.gif) **NOTE:** >- The maximum number of queues supported by the system is the total number of queue resources of the system, not the number of queue resources available to users. For example, if the system software timer occupies one more queue resource, the number of queue resources available to users decreases by one. >- The input parameters queue name and flags passed when a queue is created are reserved for future use. ->- The input parameter **timeOut** in the queue interface function is relative time. ->- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. ->- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. ->- If the input parameter bufferSize in **LOS\_QueueRead**and**LOS\_QueueReadCopy** is less than the actual length of the message, the message will be truncated. ->- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. +>- The input parameter **timeOut** in the queue interface function is relative time. +>- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. +>- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. +>- If the input parameter **bufferSize** in **LOS\_QueueRead** and **LOS\_QueueReadCopy** is less than the length of the message, the message will be truncated. +>- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. ## Development Example @@ -165,11 +151,11 @@ The preceding figure illustrates how to write data to the tail node only. Writin Create a queue and two tasks. Enable task 1 to call the queue write API to send messages, and enable task 2 to receive messages by calling the queue read API. -1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. -2. Create a message queue by calling **LOS\_QueueCreate**. -3. Enable messages to be sent in task 1 by calling **SendEntry**. -4. Enable messages to be received in task 2 by calling **RecvEntry**. -5. Call **LOS\_QueueDelete** to delete a queue. +1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. +2. Create a message queue by calling **LOS\_QueueCreate**. +3. Enable messages to be sent in task 1 by calling **SendEntry**. +4. Enable messages to be received in task 2 by calling **RecvEntry**. +5. Call **LOS\_QueueDelete** to delete a queue. ### Sample Code diff --git a/en/device-dev/kernel/kernel-standard-build.md b/en/device-dev/kernel/kernel-standard-build.md index cdb6f59c83576f431fa3d1096d7267300ee8a93d..579ebeb72bfb2a37699a5eb684601114afb2331d 100644 --- a/en/device-dev/kernel/kernel-standard-build.md +++ b/en/device-dev/kernel/kernel-standard-build.md @@ -1,4 +1,4 @@ -# Guidelines for Compiling and Building the Linux Kernel +# Compiling and Building the Linux Kernel - [Example 1](#section19369206113115) diff --git a/en/device-dev/kernel/kernel-standard-enhanced-features.md b/en/device-dev/kernel/kernel-standard-enhanced-features.md new file mode 100644 index 0000000000000000000000000000000000000000..d59562723a89cf53bd8dd1bb73cc5bc39235e1ae --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-enhanced-features.md @@ -0,0 +1,4 @@ +# Enhanced Kernel Features + +- **[Memory Management](kernel-standard-mm.md)** +- **[Task Scheduling](kernel-standard-sched.md)** diff --git a/en/device-dev/kernel/kernel-standard-mm-eswap.md b/en/device-dev/kernel/kernel-standard-mm-eswap.md new file mode 100644 index 0000000000000000000000000000000000000000..f623c62ab1685c4926b1dca19493de62ae07ee49 --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-mm-eswap.md @@ -0,0 +1,252 @@ +# Enhanced SWAP + + +## Basic Concepts + +Enhanced Swap (ESwap) allows a custom partition to serve as a swap partition and uses a resident process zswapd to encrypt and swap the anonymous pages compressed by [zram](https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html) to the ESwap partition. In this way, a block of memory can be completely released to ensure the available memory (Memavailable) waterline. In addition to this reclaiming mechanism, the entire memory framework is enhanced to improve the reclaiming efficiency of anonymous pages and file pages and streamline the reclaiming ratio of these two types of pages to prevent refaults caused by excessive reclamation. + + +## Configuring zram and ESwap + +### Enabling ESwap +1. Enable related configuration items and dependencies. + + To enable ESwap, you need to enable the corresponding configuration items and dependencies during kernel compilation. The configuration items related to ESwap are as follows: + + ``` + CONFIG_HYPERHOLD=y + CONFIG_HYPERHOLD_DEBUG=y + CONFIG_HYPERHOLD_ZSWAPD=y + CONFIG_HYPERHOLD_FILE_LRU=y + CONFIG_HYPERHOLD_MEMCG=y + CONFIG_ZRAM_GROUP=y + CONFIG_ZRAM_GROUP_DEBUG=y + CONFIG_ZLIST_DEBUG=y + CONFIG_ZRAM_GROUP_WRITEBACK=y + ``` + + Enable the following dependencies: + + ``` + CONFIG_MEMCG=y + CONFIG_SWAP=y + CONFIG_ZSMALLOC=y + CONFIG_ZRAM=y + ``` + +2. Create an ESwap device. + + You can use any block device as the ESwap device. In this example, create the **hpdisk** file and mount it to the loop6 device. + + ```Bash + // Run the dd command to create the hpdisk file for ESwap. In this example, the file size is 512 MB. Set the file size based on service requirements. + dd if=/dev/random of=/data/hpdisk bs=4096 count=131072 + // Associate the hpdisk file created with the ESwap device. + losetup /dev/block/loop6 hpdisk + ``` + +3. Configure ESwap. + + Bind the device created in 2 as the ESwap device. + + ```Bash + echo /dev/block/loop6 > /proc/sys/kernel/hyperhold/device + ``` + + By default, ESwap encrypts the data swapped out. If the ESwap device created in step 2 supports inline encryption, you can disable the ESwap software encryption function. + + ```Bash + // Check whether hardware-based encryption is supported and enabled. If not, do not perform this operation. + echo 0 > /proc/sys/kernel/hyperhold/soft_crypt + ``` + + > ![icon-caution.gif](../public_sys-resources/icon-caution.gif)**CAUTION**
+ > For security purposes, all swapped content must be encrypted. If the ESwap device created does not support inline encryption or the inline encryption macro is not enabled during compilation, ESwap cannot be enabled after software encryption is disabled. + +4. Enable ESwap. + + After ESwap is enabled, the preceding configuration cannot be modified. + + ```Bash + echo enable > /proc/sys/kernel/hyperhold/enable + ``` + + +> ![icon-note.gif](../public_sys-resources/icon-note.gif)**NOTE**
+> Enable ESwap before zram is enabled. If ESwap is not used, you can enable zram only. If a device does not have the storage device for swap-out or have the corresponding storage partition created, you can enable ZRAM to reclaim memory using **zswapd**. + +### Enabling zram + +1. Initialize zram. + + Configure the interaction between zram and ESwap and set the zram size. + + ```Bash + // Enable the swap-in and swap-out functions from zram to ESwap. Perform this step before setting the zram size. + echo readwrite > /sys/block/zram0/group + // Set the zram size. In this example, the zram size is set to 512 MB. + echo 512M > /sys/block/zram0/disksize + ``` + + > ![icon-note.gif](../public_sys-resources/icon-note.gif)**NOTE**
+ > The parameters and functions of **/sys/block/zram0/group** are as follows: + > + > - **disable**: disables the function. + > - **readonly**: only records the cgroup information of the data but not swap it out. + > - **readwrite**: enables swap-in and swap-out from zram to ESwap. + +2. Enable zram. + + Use the zram device as the swap partition. + + ```Bash + mkswap /dev/block/zram0 + swapon /dev/block/zram0 + ``` + + +### Disabling ESwap and zram + +1. Disable ESwap. + + ```Bash + echo disable > /proc/sys/kernel/hyperhold/enable + Or + echo force_disable > /proc/sys/kernel/hyperhold/enable + ``` + + > ![icon-note.gif](../public_sys-resources/icon-note.gif)**NOTE**
+ > The difference of the two commands is as follows: + > + > - **disable**: If there is no data in the ESwap partition, disable ESwap. Otherwise, changes ESwap to read-only mode. + > - **force_disable**: If there is no data in the ESwap partition, disable ESwap. Otherwise, changes ESwap to read-only mode and disable ESwap until all data in the ESWAP partition is read. + +2. Disable zram and zram group. + + ```Bash + // If swapon is executed, run swapoff first. + swapoff /dev/block/zram0 + echo 1 > /sys/block/zram0/reset + ``` + + +## ESwap APIs + +ESwap provides APIs to control swap-in and swap-out policies and record the current status. These APIs are located in the directory to which memcg is mounted, for example, `/dev/memcg/`. + +| Category| API| Description| +| -------- | -------- | -------- | +| Control| [avail_buffers](#avail_buffers) | Sets the buffer range.| +| | [zswapd_single_memcg_param](#zswapd_single_memcg_param) | Sets memcg configuration.| +| | [zram_wm_ratio](#zram_wm_ratio) | Sets the zram swap-out waterline.| +| Status| [zswapd_pressure_show](#zswapd_pressure_show) | Records the current buffer and refault.| +| | [stat](#stat) | Checks the real-time status of ESwap.| +| | [zswapd_vmstat_show](#zswapd_vmstat_show) | Records events during the zswapd running.| + +> ![icon-caution.gif](../public_sys-resources/icon-caution.gif)**CAUTION**
+> Only **avail_buffers** proactively wakes up zswapd because the buffer waterline is adjusted. Other control APIs do not proactively wake up zswapd, but their configuration takes effect only after zswapd is woken up. + +The APIs are described as follows: + +### avail_buffers + +The **avail_buffers** API sets the buffer range [min_avail_buffers, high_avail_buffers]. When the current buffer is less than the value of **min_avail_buffers**, zswapd will be woken up to reclaim anonymous pages. The expected amount of memory to reclaim is the difference between the value of **high_avail_buffers** and the current system buffer value. In fact, less memory is reclaimed due to reasons such as reclamation failure. +The parameters include the following: +- **avail_buffers** indicates the expected buffer value. +- **free_swap_threshold** indicates the threshold of the free capacity of the swap partition. After zswapd is woken up to reclaim memory, press events, such as medium press and critical press, will be recorded based on the current system status and the settings of these two parameters. +You can proactively adjust the values to trigger zswapd reclamation. +Example: +`echo 1000 950 1050 0 > /dev/memcg/memory.avail_buffers` + +Default value: + +``` + avail_buffers: 0 + min_avail_buffers: 0 + high_avail_buffers: 0 + free_swap_threshold: 0 +``` + +Limit: + +0<=min_avail_buffers<=avail_buffers<=high_avail_buffers + +0<=free_swap_threashold + +The values are all integers. + +### zswapd_single_memcg_param + +The **zswapd_single_memcg_param** API sets the memcg configuration. The parameters include the following: +- **score** indicates the current memcg reclamation priority. +- **ub_mem2zram_ratio** indicates the memory compression ratio to zram. +- **ub_zram2ufs_ratio** indicates the ratio of zram to ESwap. +- **refault_threshold** indicates the refault threshold. +You can modify the parameters to control zram compression and ESwap. +Example: +`echo 60 10 50 > memory.zswapd_single_memcg_param` + +Default value: + +``` + memcg score: 300 + memcg ub_mem2zram_ratio: 60 + memcg ub_zram2ufs_ratio: 10 + memcg refault_threshold: 50 +``` + +Limit: + +0<=ub_mem2zram_ratio<=100 + +0<=ub_zram2ufs_ratio<=100 + +0<=refault_threshold<=100 + +The values are all integers. + +### zram_wm_ratio + +The **zram_wm_ratio** API sets the zram swap-out waterline. When the size of the compressed anonymous page in the zram partition is greater than the total size of zram multiplied by **zram_wm_ratio**, the page is swapped out to the ESwap partition. The swap is performed after zswapd is woken up by the buffer waterline. The system defaults the value **0** as **37**. You can change the value as required. +Example: +`echo 30 > /dev/memcg/memory.zram_wm_ratio` + +Default value: + +``` + zram_wm_ratio: 0 +``` + +Limit: + +0<=zram_wm_ratio<=100 + +The value is an integer. + +### zswapd_pressure_show + +The **zswapd_pressure_show** API records the zswapd status. **buffer_size** indicates the current buffer size of the system, and **recent_refault** indicates the number of refaults occurred. + + +### stat + +In addition to **memcg.stat**, the **stat** API is added with **Anon**, **File**, **zram**, and **Eswap** to monitor ESwap in real time. + + +### zswapd_vmstat_show + +The **zswapd_vmstat_show** API records events occurred during the zswapd running. + + +## Triggering zswapd + +You can check the current buffer value by running `cat /dev/memcg/memory.zswapd_pressure_show`. For example, if the current buffer value is 1200, you can adjust the buffer range to wake up zswapd. + +```Bash +echo 1300 1250 1350 0 > /dev/memcg/memory.avail_buffers +``` + + +## ESwap Size + +Set zram and ESwap partition sizes based on service requirements and hardware features. For the rk3568 board whose RAM is 2 GB, the zram and ESwap partitions are set to 512 MB. diff --git a/en/device-dev/kernel/kernel-standard-mm.md b/en/device-dev/kernel/kernel-standard-mm.md new file mode 100644 index 0000000000000000000000000000000000000000..8009b6337a658386a89982efbfa662cefa341b14 --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-mm.md @@ -0,0 +1,3 @@ +# Memory Management + +- **[Enhanced Swap] (kernel-standard-mm-eswap.md)** diff --git a/en/device-dev/kernel/kernel-standard-patch.md b/en/device-dev/kernel/kernel-standard-patch.md index 2b9dcfa3b6e1a22b8b1baaaac8c2a594f2a6a731..029de25eb881cacd4556235bc4c067b7f15b27ae 100644 --- a/en/device-dev/kernel/kernel-standard-patch.md +++ b/en/device-dev/kernel/kernel-standard-patch.md @@ -1,4 +1,4 @@ -# Guidelines for Using Patches on OpenHarmony Development Boards +# Applying Patches on Development Boards 1. Apply the HDF patches. diff --git a/en/device-dev/kernel/kernel-standard-sched-cpuisolation.md b/en/device-dev/kernel/kernel-standard-sched-cpuisolation.md new file mode 100644 index 0000000000000000000000000000000000000000..57546a8fb965afd962f0a8f56fcf13a2049b2377 --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-sched-cpuisolation.md @@ -0,0 +1,38 @@ +# Lightweight CPU Isolation + + +## Basic Concepts + +Lightweight CPU isolation enables dynamic CPU isolation based on the system load and user configuration. The kernel migrates the tasks and interrupts from the isolated CPU to other CPUs for execution. The isolated CPU enters the idle state, which reduces the power consumption. In addition, user-mode configuration and query APIs are provided for better system optimization. + + +## Configuration + +### Enabling Lightweight CPU Isolation +Enable related configuration items and dependencies. + +To enable lightweight CPU isolation, you need to enable the corresponding configuration items and dependencies during kernel compilation. The related configuration items are as follows: + +``` +CONFIG_CPU_ISOLATION_OPT=y +CONFIG_SCHED_CORE_CTRL=y +``` + +Enable the following dependencies: + +``` +CONFIG_SMP=y +CONFIG_SCHED_WALT=y +``` +## Available APIs + +APIs are provided to set the number of isolated CPU cores and record the current status. Configurations can be performed based on CPU clusters. These APIs are located in the first CPU device directory of each CPU cluster, for example, `/sys/devices/system/cpu/cpu0/core_ctl`. + +| Category| API | Description | +| ---- | ------------ | ---------------------------------------- | +| Control API| enable | Enables or disables the lightweight CPU isolation. The value **1** means enable, and **0** means disable. | +| | min_cpus | Sets the minimum number of active (not isolated) CPUs. | +| | max_cpus | Sets the maximum number of active (not isolated) CPUs. The maximum value is the number of CPUs in a CPU cluster.| +| Status API| active_cpus | Obtains the number of active (not isolated) CPUs. | +| | need_cpus | Obtains the number of CPUs to de-isolate. | +| | global_state | Records the status of all CPU clusters in the system, including the CPU isolation status, online status, and load information.| diff --git a/en/device-dev/kernel/kernel-standard-sched-rtg.md b/en/device-dev/kernel/kernel-standard-sched-rtg.md new file mode 100644 index 0000000000000000000000000000000000000000..534cdcdab06c04c6f3abce5e29766411e4c819cc --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-sched-rtg.md @@ -0,0 +1,61 @@ +# Related Thread Group + + +## Basic Concepts + +The Related Thread Group (RTG) provides optimized scheduling of a group of important threads. The load of an RTG can be collected and predicted separately and the preferred CPU cluster can be set to allow the important threads to run on the optimal CPU and the kernel to select a proper CPU frequency based on the group loads. + + +## Configuration + +### Enabling RTG +To enable RTG, you need to enable the related configuration items and dependencies during kernel compilation. The related configuration items are as follows: + +``` +CONFIG_SCHED_RTG=y +CONFIG_SCHED_RTG_DEBUG=y +CONFIG_SCHED_RTG_FRAME=y +CONFIG_SCHED_RTG_RT_THREAD_LIMIT=y +``` + +Enable the following dependencies: + +``` +CONFIG_SCHED_WALT=y +``` +### Adding a Process or Thread to an RTG + +By default, 20 RTGs are created in the kernel. The group with ID of 1 is reserved and cannot be added with any process or thread. + +```Bash +// Add a process to an RTG. +echo 2 > /proc//sched_group_id +// Remove a process from an RTG. The group with ID of 0 is not an RTG. +echo 0 > /proc//sched_group_id +``` +### Obtaining RTG Information + +The RTG information includes group ID, preferred CPU cluster ID, and thread information. + + ```Bash +cat /proc/sched_rtg_debug +// The following information is displayed: +RTG_ID : 2 // RTG ID. +RTG_INTERVAL : UPDATE:8ms\#INVALID:4294ms // CPU frequency modulation interval and valid load duration. +RTG_CLUSTER : -1 // CPU cluster ID. The value **-1** means that the preferred cluster is not set. +RTG_THREADS: 0/1 // Total number of threads in the group. +STATE COMM PID PRIO CPU // Thread information, including the status, name, PID, priority, and CPU ID. +--------------------------------------------------------- + S bash 436 120 1(0-3) + ``` + +## Available APIs + +The RTG provides the device node and ioctl APIs for querying and configuring group information. The device node is in `/dev/sched_rtg_ctrl`. + +| Device Node | request | Description | +| ------------------- | ------------------- | ------------------- | +| /dev/sched_rtg_ctrl | CMD_ID_SET_RTG | Creates an RTG, and adds, updates, or deletes threads in the group. | +| | CMD_ID_SET_CONFIG | Configures global group attributes, for example, the maximum number of real-time RTGs.| +| | CMD_ID_SET_RTG_ATTR | Configures specified group attributes, for example, the thread priority. | +| | CMD_ID_SET_MIN_UTIL | Sets the minimum utilization of an RTG. | diff --git a/en/device-dev/kernel/kernel-standard-sched.md b/en/device-dev/kernel/kernel-standard-sched.md new file mode 100644 index 0000000000000000000000000000000000000000..cfaca68261652d3af810a293d353b871e87d8a1f --- /dev/null +++ b/en/device-dev/kernel/kernel-standard-sched.md @@ -0,0 +1,4 @@ +# Task Scheduling + +- **[Related Thread Group](kernel-standard-sched-rtg.md)** +- **[Lightweight CPU Isolation](kernel-standard-sched-cpuisolation.md)** diff --git a/en/device-dev/kernel/kernel-standard.md b/en/device-dev/kernel/kernel-standard.md index d9e58952f07091e156ef66e64ad2dac2a8b279e8..9f1780d5b146732cfc018c90703a47c72ae05173 100644 --- a/en/device-dev/kernel/kernel-standard.md +++ b/en/device-dev/kernel/kernel-standard.md @@ -1,9 +1,10 @@ # Kernel for Standard Systems -- **[Linux Kernel Overview](kernel-standard-overview.md)** -- **[Guidelines for Using Patches on OpenHarmony Development Boards](kernel-standard-patch.md)** +- **[Linux Kernel Overview](kernel-standard-overview.md)** -- **[Guidelines for Compiling and Building the Linux Kernel](kernel-standard-build.md)** +- **[Applying Patches on Development Boards](kernel-standard-patch.md)** +- **[Compiling and Building the Linux Kernel](kernel-standard-build.md)** +- **[Enhanced Kernel Features] (kernel-standard-enhanced-features.md)** diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md index 2c6b4ea35cbe2dcc575afbb5e16513a1ad6d6a31..238773053ceba4a917225ceaa56b61272fe503d6 100644 --- a/en/device-dev/porting/Readme-EN.md +++ b/en/device-dev/porting/Readme-EN.md @@ -56,4 +56,11 @@ The download steps for other resources are the same as those in the mainline ver - [Third-Party Library Porting Guide for Mini and Small Systems](porting-thirdparty.md) - [Overview](porting-thirdparty-overview.md) - [Porting a Library Built Using CMake](porting-thirdparty-cmake.md) - - [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) \ No newline at end of file + - [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) + +## SoC Porting Cases + +- [Mini System SoC Porting Cases](porting-minichip-cases.md) + - [Mini-System Devices with Screens — Bestechnic SoC Porting Case](porting-bes2600w-on-minisystem-display-demo.md) + - [Combo Solution – ASR Chip Porting Case](porting-asr582x-combo-demo.md) + diff --git a/en/device-dev/porting/figure/asr5822s_select.png b/en/device-dev/porting/figure/asr5822s_select.png new file mode 100644 index 0000000000000000000000000000000000000000..98f06026b478f6a12877019bd72e8c35a4c72f8a Binary files /dev/null and b/en/device-dev/porting/figure/asr5822s_select.png differ diff --git a/en/device-dev/porting/figure/asr582x_ohos_config.png b/en/device-dev/porting/figure/asr582x_ohos_config.png new file mode 100644 index 0000000000000000000000000000000000000000..02a3bd390030db5153ee6c54f3725fffd84488fa Binary files /dev/null and b/en/device-dev/porting/figure/asr582x_ohos_config.png differ diff --git a/en/device-dev/porting/figure/bes2600_board_make_menuconfig.png b/en/device-dev/porting/figure/bes2600_board_make_menuconfig.png new file mode 100644 index 0000000000000000000000000000000000000000..4269a1c86e1662fb4ddd54cd85ab5608bf3e6202 Binary files /dev/null and b/en/device-dev/porting/figure/bes2600_board_make_menuconfig.png differ diff --git a/en/device-dev/porting/figure/bes2600_hb_env.png b/en/device-dev/porting/figure/bes2600_hb_env.png new file mode 100644 index 0000000000000000000000000000000000000000..10fa486ec6f56f490a19d5021cb7b309b372ddb9 Binary files /dev/null and b/en/device-dev/porting/figure/bes2600_hb_env.png differ diff --git a/en/device-dev/porting/figure/bes2600_hb_set.png b/en/device-dev/porting/figure/bes2600_hb_set.png new file mode 100644 index 0000000000000000000000000000000000000000..6cadca71b5dac5a945c16754085631dab3f9a626 Binary files /dev/null and b/en/device-dev/porting/figure/bes2600_hb_set.png differ diff --git a/en/device-dev/porting/figure/bes2600_newlib_make_menuconfig.png b/en/device-dev/porting/figure/bes2600_newlib_make_menuconfig.png new file mode 100644 index 0000000000000000000000000000000000000000..2b844544b987abcb8346e56a27098ff150707705 Binary files /dev/null and b/en/device-dev/porting/figure/bes2600_newlib_make_menuconfig.png differ diff --git a/en/device-dev/porting/porting-asr582x-combo-demo.md b/en/device-dev/porting/porting-asr582x-combo-demo.md new file mode 100644 index 0000000000000000000000000000000000000000..c038ad065c7ec4aa36e2ae830a9e0f44ddbbb5c3 --- /dev/null +++ b/en/device-dev/porting/porting-asr582x-combo-demo.md @@ -0,0 +1,681 @@ + + +# Combo Solution – ASR Chip Porting Case + +The IoT combo solution (Wi-Fi+BLE) is developed based on the OpenHarmony LiteOS-M kernel. This document exemplifies how to port code of the DEV.WIFI.A development board powered by the ASR582X chip. + +## Compilation and Porting + +### Directory Planning + +In the directory structure of this solution, the board vendor code is decoupled from the SoC vendor code. + +``` +device +├── board --- Board vendor directory +│ └── lango --- Board vendor: Lango +│ └── dev_wifi_a --- Board name: DEV.WIFI.A +└── soc --- SoC vendor directory + └── asrmicro --- SoC vendor: ASR + └── asr582x --- SoC series: ASR582X +``` + +The planned product demo directory is as follows: + +``` +vendor +└── asrmicro --- Vendor of the product demo. + ├── wifi_demo --- Product demo name. + └── xts_demo --- Product name. +``` + +### Product Definition + +The following uses `vendor/asrmicro/wifi_demo` as an example to describe the kernel, board, and subsystem used by the product. The kernel, board model, and board vendor need to be planned in advance, which are involved in the precompilation instruction (`hb set`). The information entered here corresponds to the planned directory. Example: + +``` +{ + "product_name": "wifi_demo", --- Product name. + "type": "mini", --- System type: mini. + "version": "3.0", --- System version: 3.0 + "device_company": "lango", --- Board vendor: Lango. + "board": "dev_wifi_a", --- Board name: dev_wifi_a. + "kernel_type": "liteos_m", --- Kernel type: liteos_m. + "kernel_version": "3.0.0", --- Kernel version: 3.0.0. + "subsystems": [] --- Subsystem. +} +``` +**device_company** and **board** are used to associate the **//device/board// directory**. + +### Board Configuration + +In this example, the `device/board/lango/dev_wifi_a` directory is used. Place the **config.gni** file in the **liteos_m** directory. This configuration file is used to describe the board information, including the CPU, toolchain, kernel, and compile flags. Sample code: + +``` +# Kernel type +kernel_type = "liteos_m" + +# Kernel version +kernel_version = "3.0.0" + +# Board CPU Type +board_cpu = "cortex-m4" + +# Toolchain. Here, arm-none-eabi is used. +board_toolchain = "arm-none-eabi" + +# Toolchain path. You can use the system path by entering "", or a custom path. +board_toolchain_path = rebase_path("//device/soc/asrmicro/gcc/gcc-arm-none-eabi/Linux64/bin") + +# Board-specific compilation parameters +board_cflags = [] + +# Board-specific link parameters +board_ld_flags = [] + +# Board-specific header file +board_include_dirs = [] +``` + +### Precompiling + +After the product directory, product definition, and board settings are correctly configured, run the precompilation command `hb set` in the project root directory. Then you can find the related product in the displayed list. + +![ohos_config.json](figures/asr582x_ohos_config.png) + +After selecting a product, press **Enter**. The `ohos_config.json` file is automatically generated in the root directory. Information about the product to be compiled is listed here. + + +## Kernel Porting + +### Kconfig Adaptation + +During the compilation of `//kernel/liteos_m`, you need to use the `Kconfig` file for indexing in the corresponding board and SoC directory. + +`Kconfig` in the board directory, for example, `//device/board/lango`: +``` +├── dev_wifi_a --- dev_wifi_a board configuration +│ ├── Kconfig.liteos_m.board --- Board configuration options +│ ├── Kconfig.liteos_m.defconfig.board --- Default configuration of the board +│   └── liteos_m +│ └── config.gni --- Board configuration file +├── Kconfig.liteos_m.boards --- Boards configuration of the board vendor +└── Kconfig.liteos_m.defconfig.boards --- Default boards configuration of the board vendor +``` + +In `dev_wifi_a/Kconfig.liteos_m.board`, **BOARD_DEV_WIFI_A** can be selected only when **SOC_ASR5822S** is selected. + +``` +config BOARD_DEV_WIFI_A + bool "select board DEV_WIFI_A" + depends on SOC_ASR5822S +``` + +`Kconfig` in the SoC directory, for example, `//device/soc/asrmicro`: + +``` +├── asr582x --- ASR582X series +│ ├── Kconfig.liteos_m.defconfig.asr5822s --- Default configuration of the ASR5822S chip +│ ├── Kconfig.liteos_m.defconfig.series --- Default configuration of the ASR582X series +│ ├── Kconfig.liteos_m.series --- Configuration of the ASR582X series +│ └── Kconfig.liteos_m.soc --- ASR582X chip configuration +├── Kconfig.liteos_m.defconfig --- SoC default configuration +├── Kconfig.liteos_m.series --- Series configuration +└── Kconfig.liteos_m.soc --- SoC configuration +``` + +In **asr582x/Kconfig.liteos_m.series**: + +``` +config SOC_SERIES_ASR582X + bool "ASR582X Series" + select ARM + select SOC_COMPANY_ASRMICRO --- Select SOC_COMPANY_ASRMICRO. + select CPU_CORTEX_M4 + help + Enable support for ASR582X series +``` + +**SOC_ASR5822S** can be selected in **asr582x/Kconfig.liteos_m.soc** only when **SOC_SERIES_ASR582X** is selected. + +``` +choice + prompt "ASR582X series SoC" + depends on SOC_SERIES_ASR582X + +config SOC_ASR5822S --- Select SOC_ASR5822S. + bool "SoC ASR5822S" + +endchoice +``` + +To compile the board BOARD_DEV_WIFI_A, you need to select **SOC_COMPANY_ASRMICRO**, **SOC_SERIES_ASR582X**, and **SOC_ASR5822S**. You can do so by running `make menuconfig` in `kernel/liteos_m`. + +![asr5822s_select.json](figures/asr5822s_select.png) + +The configurations are saved in `//vendor/asrmicro/wifi_demo/kernel_configs/debug.config` by default. You can directly modify the configurations in **debug.config**. + +``` +LOSCFG_BOARD_DEV_WIFI_A=y +LOSCFG_SOC_COMPANY_ASRMICRO=y +LOSCFG_SOC_SERIES_ASR582X=y +LOSCFG_SOC_ASR5822S=y +``` + +### Modular Compilation + +The compilation of `Board` and `SoC` adopts the modular compilation method, starting from `kernel/liteos_m/BUILD.gn` and increasing by level. The adaptation process of this solution is as follows: + +1. Create the **BUILD.gn** file in `//device/board/lango` and add the following content to the file: + + ``` + if (ohos_kernel_type == "liteos_m") { + import("//kernel/liteos_m/liteos.gni") + module_name = get_path_info(rebase_path("."), "name") + module_group(module_name) { + modules = [ + "dev_wifi_a", --- Board module + "hcs", --- Module corresponding to the hcs file + ] + } + } + ``` + + In the preceding **BUILD.gn** file, **dev_wifi_a** and **hcs** are the module names organized by directory level. + +2. In `//device/soc/asrmicro`, use the same method to create the **BUILD.gn** file and add the following content to the file: + + ``` + if (ohos_kernel_type == "liteos_m") { + import("//kernel/liteos_m/liteos.gni") + module_name = get_path_info(rebase_path("."), "name") + module_group(module_name) { + modules = [ + "asr582x", + ] + } + } + ``` + +3. In the `//device/soc/asrmicro` module at each level, add the **BUILD.gn** file and compile the module. The following uses `//device/soc/asrmicro/asr582x/liteos_m/sdk/startup/BUILD.gn` as an example: + + ``` + import("//kernel/liteos_m/liteos.gni") + + config("public") { + include_dirs = [ "." ] --- Common header file + } + + kernel_module("asr_startup") { --- Module for compilation + sources = [ --- Source file for compilation + "startup.c", + "board.c", + "startup_cm4.S", + ] + + include_dirs = [ --- Header files used in the include + "...", + ] + } + ``` + +4. To organize links and some compilation options, the following parameters are set in **config("public")** in `//device/soc/asrmicro/asr582x/liteos_m/sdk/config/BUILD.gn`: + + ``` + config("public") { + include_dirs = [] --- Common header file + ldflags = [] --- Link parameters, including the ld file + libs = [] --- Link library + defines = [] --- Definition + ``` + + ![](../public_sys-resources/icon-note.gif) **NOTE** + It is recommended that common parameter options and header files not be repeatedly filled in all components. + +5. To organize some product applications, this solution adds **list** to the **config.json** file of the vendor. The following uses `//vendor/asrmicro/wifi_demo/config.json` as an example to describe how to add **list** to the **config.json** file: + ``` + "tests_list": [ --- demo list + { + "enable": "true", --- list switch + "test_modules": [ + "example", --- OS basic demo + "wifi_test" --- Wi-Fi demo + ] + } + ] + ``` + + The demo is managed as a module. To enable or disable a demo, add or delete items in **tests_list**.**tests_list** can be directly read in GN. You need to add the following content to `//device/board/lango/dev_wifi_a/liteos_m/config.gni`: + + ``` + product_conf = read_file("${product_path}/config.json", "json") + product_name = product_conf.product_name + tests_list = product_conf.tests_list + ``` + + After reading the **list**, you can add related component libraries to the corresponding link options. Add the following content to `//device/soc/asrmicro/asr582x/liteos_m/sdk/config/BUILD.gn`: + + ``` + foreach(test_item, tests_list) { + test_enable = test_item.enable + if(test_enable == "true") + { + foreach(test_module, test_item.test_modules) { + ldflags += [ "-l${test_module}" ] + } + } + } + ``` + +### C Library Adaptation + +To ensure that the entire system does not distinguish the user mode and kernel mode, the upper-layer components and kernel share the same musl-based C library. This solution uses the musl C library. For details about the third-party library, see `//third_party/musl/porting/liteos_m/kernel/BUILD.gn`. + +In addition, the kernel modifies and adapts the code for malloc. For details about the adaptation file, see `//kernel/liteos_m/kal/libc/musl/porting/src/malloc.c`. + +In this solution, printf-related APIs are implemented using open-source code. For details about the adaptation file, see `//device/soc/asrmicro/asr582x/liteos_m/sdk/drivers/platform/system/printf-stdarg.c`. + +The **wrap** links of the printf-related APIs need to be added to the `//device/board/lango/dev_wifi_a/liteos_m/config.gni` file so that these APIs can be invoked. + +``` +board_ld_flags += [ + "-Wl,--wrap=printf", + "-Wl,--wrap=sprintf", + "-Wl,--wrap=snprintf", + "-Wl,--wrap=vprintf", + "-Wl,--wrap=vsprintf", + "-Wl,--wrap=vsnprintf", +] +``` +### Shell Adaptation + +To facilitate debugging, this solution integrates the shell component of the kernel. You can select **Enable Shell** in **Debug** of **make menuconfig** or enter **LOSCFG_SHELL=y** in the `//vendor/asrmicro/wifi_demo/kernel_configs/debug.config` file. +The shell component needs to be initialized. For details, see `device/soc/asrmicro/asr582x/liteos_m/sdk/startup/board.c`. + +``` +ret = LosShellInit(); +if (ret != LOS_OK) { + printf("LosShellInit failed! ERROR: 0x%x\n", ret); +} +ret = OsShellInit(); +if (ret != LOS_OK) { + printf("OsShellInit failed! ERROR: 0x%x\n", ret); +} +``` + +After initialization, each shell command needs to be registered, for example, `vendor/asrmicro/wifi_demo/tests/wifi/wifi_app.c`: + +``` +osCmdReg(CMD_TYPE_STD, "wifi_open", 0, (CMD_CBK_FUNC)ap_conn_func); --- Connect to the AP. Input parameters can be carried. +osCmdReg(CMD_TYPE_EX, "wifi_close", 0, (CMD_CBK_FUNC)ap_close_func); --- Disconnect from the AP. +``` + +### Kernel Boot Adaptation + +After the board enters the **main** function, it is initialized. After that, interrupts are registered, and then the kernel is initialized and scheduled. +For details about interrupt registration, see `//device/soc/asrmicro/asr582x/liteos_m/sdk/startup/board.c`. + +``` +ArchHwiCreate(UART1_IRQn,configLIBRARY_NORMAL_INTERRUPT_PRIORITY,0,UART1_IRQHandler,0); --- UART interrupt +ArchHwiCreate(GPIO_IRQn,configLIBRARY_NORMAL_INTERRUPT_PRIORITY,0,GPIO_IRQHandler,0); --- GPIO interrupt +``` + +The following is an example of kernel initialization: +``` +osStatus_t ret = osKernelInitialize(); --- Kernel initialization + +if(ret == osOK) +{ + threadId = osThreadNew((osThreadFunc_t)sys_init,NULL,&g_main_task); --- Create the init thread. + + if(threadId!=NULL) + { + osKernelStart(); --- Thread scheduling + } +} +``` + +In `sys_init`, you need to initialize the Openharmony system components. + +``` +... +DeviceManagerStart(); --- Initialize HDF. + +OHOS_SystemInit(); --- Initialize Openharmony system components. +.... +``` + +### HDF Framework Adaptation + +HDF provides a set of unified APIs for applications to access hardware, simplifying application development. To add the HDF component, you need to add it to `//vendor/asrmicro/wifi_demo/kernel_configs/debug.config`: + +``` +LOSCFG_DRIVERS_HDF=y +LOSCFG_DRIVERS_HDF_PLATFORM=y +``` + +In addition, you need to add the hardware configuration description file of the corresponding development board to `board`. The file is stored in `//device/board/lango/hcs`. This example takes the GPIO and UART as an example. The porting process is as follows: + +#### GPIO Adaptation + +1. The chip driver adaptation file is stored in the `//drivers/adapter/platform` directory. Add the `gpio_asr.c` and `gpio_asr.h` files to the `gpio` directory, and add the compilation conditions of the new driver file to `BUILD.gn`. + + ``` + if (defined(LOSCFG_SOC_COMPANY_ASRMICRO)) { + sources += [ "gpio_asr.c" ] + } + ``` + +2. The driver description file in `gpio_asr.c` is as follows: + + ``` + struct HdfDriverEntry g_GpioDriverEntry = { + .moduleVersion = 1, + .moduleName = "ASR_GPIO_MODULE_HDF", + .Init = GpioDriverInit, + .Release = GpioDriverRelease, + }; + HDF_INIT(g_GpioDriverEntry); + ``` + +3. Add the GPIO hardware description file `gpio.hcs` to `//device/board/lango/hcs`. The mapped GPIO0 controls the programmable LED on the board. GPIO1 corresponds to the user key. The HCS content is as follows: + + ``` + root { + platform { + gpio_config { + match_attr = "gpio_config"; + pin = [0, 1]; + // led3: GPIO9 + // user key: GPIO7 + realPin = [9, 7]; + config = [5, 1]; + pinNum = 2; + } + } + } + ``` + +4. The configuration information of `gpio.hcs` is loaded in GpioDriverInit, and the corresponding GPIO pins are initialized. The application layer needs only the following simple code to control LED indicators and read key information: + + ``` + int32_t GpioKeyIrqFunc(uint16_t gpio, void *data) + { + printf("user key %d pressed\n", gpio); + } + GpioSetIrq(1, OSAL_IRQF_TRIGGER_FALLING, GpioKeyIrqFunc, NULL); + + GpioWrite(0, 0); + lega_rtos_delay_milliseconds(1000); + GpioWrite(0, 1); + ``` + +#### UART Adaptation + +1. The chip driver adaptation file is stored in the `//drivers/adapter/platform` directory. Add the `uart_asr.c` and `uart_asr.h` files to the `uart` directory, and add the compilation conditions of the new driver file to `BUILD.gn`. + + ``` + if (defined(LOSCFG_SOC_COMPANY_ASRMICRO)) { + sources += [ "uart_asr.c" ] + } + ``` + +2. The driver description file in `uart_asr.c` is as follows: + + ``` + struct HdfDriverEntry g_hdfUartDevice = { + .moduleVersion = 1, + .moduleName = "HDF_PLATFORM_UART", + .Bind = HdfUartDeviceBind, + .Init = HdfUartDeviceInit, + .Release = HdfUartDeviceRelease, + }; + + HDF_INIT(g_hdfUartDevice); + ``` + +3. Add the GPIO hardware description file `uart.hcs` to `//device/board/lango/hcs`. The HCS content is as follows: + + ``` + controller_uart0 :: uart_controller { + match_attr = "asr582x_uart_0"; + port = 0; /* UART_ID_0 */ + + pin_tx_pin = 0; /* IO_PIN_10 */ + pin_tx_mux = 25; /* IO_MUX_2 */ + + pin_rx_pin = 1; /* IO_PIN_11 */ + pin_rx_mux = 25; /* IO_MUX_2 */ + tx_rx = 3; /* TX_RX MODE */ + } + ``` + +4. The configuration information of `gpio.hcs` is loaded in `HdfUartDeviceInit`, and the corresponding serial port pins are initialized. The code for testing the serial port at the application layer is as follows: + + ``` + DevHandle uart_handle = UartOpen(0); + UartSetBaud(uart_handle, 115200); + ... + attr.dataBits = UART_ATTR_DATABIT_8; + attr.parity = UART_ATTR_PARITY_NONE; + attr.stopBits = UART_ATTR_STOPBIT_1; + ret = UartSetAttribute(uart_handle, &attr); + ret = UartWrite(uart_handle, send_data, strlen(send_data)); + ret = UartRead(uart_handle, recv_data, sizeof(recv_data) - 1); + ... + ``` + +## OpenHarmony Component Porting + +The compilation option entry of the subsystem is in the `config.json` file of the corresponding product. The following uses `//vendor/asrmicro/wifi_demo/config.json` as an example. + +### LWIP component + +The source code of the lwIP component is stored in `//third_party/lwip`. The kernel in Openharmony is customized in `//kernel/liteos_m/components/net/lwip-2.1`, including the redefinition of some interfaces and structures. + +For details about the porting process, see [lwIP Module Adaptation](https://gitee.com/openharmony/docs/blob/master/en/device-dev/porting/porting-chip-board-lwip.md). + +In this example, the path for setting lwip in the `config.json` file is as follows: + + ``` + "subsystem": "kernel", + "components": [ + { + "component": "liteos_m", + "features": [ + "ohos_kernel_liteos_m_lwip_path = \"//device/soc/asrmicro/asr582x/liteos_m/components/net/lwip-2.1\"" + ] + } + ] + ``` + +Enable lwIP compilation in the `kernel_config/debug.config` file. + +``` +LOSCFG_NET_LWIP=y +``` + +### Security Component + +For the security component, enable the corresponding options in `config.json`. In this example, mbedtls (`//third_party/mbedtls`) in the third-party library is used as the encryption module. The options are as follows: + +``` +"subsystem": "security", +"components": [ + { "component": "huks", "features": + [ + ... + "ohos_security_huks_mbedtls_porting_path = \"//device/soc/asrmicro/asr582x/liteos_m/components/mbedtls\"" + ] + } +] +``` + +In the preceding directory, you need to configure mbedtls. For details, see `config/config_liteos_m.h`. Note that if the RNG capability of mbedtls is used (for example, the dsoftbus component is used in `//foundation/communication/dsoftbus/adapter/common/mbedtls/softbus_adapter_crypto.c`), the entropy source for generating random numbers must be specified. In this example, the hardware random number capability of the ASR582X is used. You need to enable the following macro: + +``` +#define MBEDTLS_ENTROPY_HARDWARE_ALT +``` + +After this macro is enabled, the `entropy_hardware_alt` interface needs to be implemented. For details, see `library/entropy_hardware_alt.c`. + +### wifi_lite Component + +The options of the wifi_lite component are as follows: + +``` +"subsystem": "communication", +"components": [ + { "component": "wifi_lite", "features":[] } + ] +``` + +Wi-Fi-related functions are implemented in `//device/soc/asrmicro/asr582x/liteos_m/sdk/hal/src/wifi_adapter.c`. + +This example also provides a demo that uses the `wifi_lite` interfaces. For details, see `//vendor/asrmicro/wifi_demo/tests/wifi/wifi_app.c`. The following two connection test commands are provided: + +Table 1 ASR Wi-Fi connection commands + +| Command | Parameter | Description | +|------------|--------|--------| +| wifi_open | sta [SSID] [KEY] | Connection routing command, for example, `wifi_open sta ASR_AP test123456`.| +| wifi_close | N/A | Command for disconnecting a connection. | + +### XTS component + +To adapt the XTS component, for example, `//vendor/asrmicro/xts_demo/config.json`, add the following component options: + +``` +"subsystem": "xts", +"components": [ + { "component": "xts_acts", "features": + [ + "enable_ohos_test_xts_acts_use_thirdparty_lwip = true" + ] + }, + { "component": "xts_tools", "features":[] } +] +``` + +The XTS function is also organized using `list`. You can add or delete modules in the `config.json` file by referring to [Modular Compilation]. + +``` +"xts_list": [ + { + "enable": "true", + "xts_modules": [ + "ActsKvStoreTest", + "ActsDfxFuncTest", + "ActsHieventLiteTest", + "ActsSamgrTest", + "ActsParameterTest", + "ActsWifiServiceTest", + "ActsWifiIotTest", + "ActsBootstrapTest" + ] + } +], +``` + +### dsoftbus component + +The dsoftbus component provides the discovery, connection, networking, and transmission capabilities between devices. This solution uses the DSoftBus capability between Wi-Fi devices as an example. + +Dependent components: lwIP, security, and wifi_lite. + +Prerequisites: The device is connected to a router, and all networking devices are in the same LAN. + +The options of the dsoftbus component are as follows: + +``` +"subsystem": "communication", +"components": [ + { "component": "dsoftbus", "features":[] } + ] +``` + +The dsoftbus test demo is provided in `//vendor/asrmicro/wifi_demo`. To enable this function, modify `//vendor/asrmicro/wifi_demo/tests/BUILD.gn`. + +``` +declare_args() { + asr_dsoftbus_test = true --- Enable dsoftbus demo compilation. +} +``` + +Add the dsoftbus_test module to the `//vendor/asrmicro/wifi_demo/config.json` file. + +``` +"tests_list": [ + { + "enable": "true", + "test_modules": [ + "wifi_test", + "dsoftbus_test" --- Enable the dsoftbus_test module. + ] + } +] +``` + +For details about the startup interface of the dsoftbus component, see `//vendor/asrmicro/wifi_demo/tests/dsoftbus/dsoftbus_app.c`. + +``` +InitSoftBusServer(); +``` + +At least 80 KB RAM needs to be reserved for the running of the DSoftBus component. If the resources are insufficient, other parts such as the lwIP component can be tailored. +`//kernel_liteos_m/blob/master/components/net/lwip-2.1/porting/include/lwip/lwipopts.h`: + +``` +#define TCPIP_THREAD_STACKSIZE 0x2000 --- Reduce the size of the TCP/IP task stack. +``` + +The `-fPIC` compilation option is added to the `communication_dsoftbus` repository. In this way, the compiler generates position-independent code and uses relative addresses. However, the LiteOS-M core uses a static library, which is not recommended. +You are advised to manually comment out the `-fPIC` compilation option in the following files: +`//foundation/communication/dsoftbus/core/common/BUILD.gn` +`//foundation/communication/dsoftbus/core/frame/BUILD.gn` +`//foundation/communication/dsoftbus/sdk/BUILD.gn` +`//foundation/communication/dsoftbus/components/nstackx_mini/nstackx_ctrl/BUILD.gn` + +The DSoftBus networking requires device authentication. In the R&D phase, you can skip the authentication and focus on the networking and transmission capabilities. You need to replace the `HandleReceiveDeviceId` function in the `//foundation/communication/dsoftbus/core/authentication/src/auth_manager.c` file with the following implementation: + +``` +void HandleReceiveDeviceId(AuthManager *auth, uint8_t *data) +{ + uint8_t tempKey[SESSION_KEY_LENGTH] = {0}; + if (auth == NULL || data == NULL) { + SoftBusLog(SOFTBUS_LOG_AUTH, SOFTBUS_LOG_ERROR, "invalid parameter"); + return; + } + if (AuthUnpackDeviceInfo(auth, data) != SOFTBUS_OK) { + SoftBusLog(SOFTBUS_LOG_AUTH, SOFTBUS_LOG_ERROR, "AuthUnpackDeviceInfo failed"); + AuthHandleFail(auth, SOFTBUS_AUTH_UNPACK_DEVID_FAILED); + return; + } + if (auth->side == SERVER_SIDE_FLAG) { + if (EventInLooper(auth->authId) != SOFTBUS_OK) { + SoftBusLog(SOFTBUS_LOG_AUTH, SOFTBUS_LOG_ERROR, "auth EventInLooper failed"); + AuthHandleFail(auth, SOFTBUS_MALLOC_ERR); + return; + } + if (AuthSyncDeviceUuid(auth) != SOFTBUS_OK) { + AuthHandleFail(auth, SOFTBUS_AUTH_SYNC_DEVID_FAILED); + } + (void)memset_s(tempKey, SESSION_KEY_LENGTH, 1, SESSION_KEY_LENGTH); + AuthOnSessionKeyReturned(auth->authId, tempKey, SESSION_KEY_LENGTH); + return; + } + //VerifyDeviceDevLvl(auth); --- Comment out the authentication process. + (void)memset_s(tempKey, SESSION_KEY_LENGTH, 1, SESSION_KEY_LENGTH); + AuthOnSessionKeyReturned(auth->authId, tempKey, SESSION_KEY_LENGTH); +} +``` + +After correct configuration, compilation, and burning, the device uses the wifi_open command to connect to the router. After the connection is successful, the device automatically performs networking. + + +The adaptation process of other components is similar to that of other vendors. + +## To-do + +- Adding BLE support +- Diversifying Wi-Fi test commands diff --git a/en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md b/en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md new file mode 100644 index 0000000000000000000000000000000000000000..651407e8a549870d39f555ed9f7e614fe26d3488 --- /dev/null +++ b/en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md @@ -0,0 +1,1479 @@ + + +# Mini-System Devices with Screens — Bestechnic SoC Porting Case + +This document exemplifies the porting procedure for a development board on a mini-system device with a screen – an intelligent switch panel. It uses the BES multi-modal V200Z-R development board powered by the Bestechnic BES2600W SoC as an example. Components such as `ace_engine_lite`, `graphic_ui`, `aafwk_lite`, `appexecfwk_lite`, and `HDF` are adapted based on the OpenHarmony LiteOS-M kernel. This example uses the board-SoC separation solution as the porting architecture, the Newlib C or Musl C library as the toolchain, and GN and Kconfig graphical configuration for LiteOS-M kernel compilation. + +## Compilation and Building + +### Directory Planning + +This example uses an improved SoC porting architecture. The original SoC adaptation directory is as follows: + +``` +device +└── +    └── +``` + +This adaptation directory has a downside: To use the Hi3861 SoC on the BearPi-HM Nano or HiSpark Pegasus development board, you need to place a copy of the code in the directory of both development boards. To solve this problem, the board vendor is decoupled from the SoC vendor in this example, by following the board-SoC decoupling design ideas. The SoC adaptation directory used in this example is as follows: + +``` +device +├── board --- Board vendor directory +│ └── fnlink --- Board vendor name: Fn-Link +│ └── v200zr --- Board name: v200zr +└── soc --- SoC vendor directory + └── bestechnic --- SoC vendor: Bestechnic + └── bes2600 --- SoC Series: The bes2600 series includes bes2600w. +``` + +The planned product demo directory is as follows: + +``` +vendor +└── bestechnic --- Vendor of the product demo. + └── display_demo --- Product demo name. +``` + +### Precompilation Adaptation + +Before porting, you need to perform precompilation adaptation. + +To do so, use the `hb set` command to set environment variables such as the root directory, board directory, product directory, and board company name of the entire project. + +The specific procedure is as follows: + +1. Add the `config.json` file to the `vendor/bestechnic/display_demo` directory to describe the board and kernel information used by the product demo. The following is an example of the description: + +``` +{ + "product_name": "display_demo", --- Product name to display in the hb set drop-down list. + Type of the "type": "mini", --- Build system type, which can mini, small, or standard. + Version of the "version": "3.0", --- Build system version, which can be 1.0, 2.0, or 3.0. + "device_company": "fnlink", --- Board vendor name, which is used to find the /device/board/fnlink directory during compilation. + "board": "v200zr", --- Board name, which is used to find the /device/board/fnlink/v200zr directory during compilation. + "kernel_type": "liteos_m", --- Kernel type. OpenHarmony supports multiple kernels, and one board may be adapted to multiple kernels. Therefore, you need to specify a kernel for compilation. + "kernel_version": "3.0.0", --- Kernel version. A board may be adapted to multiple Linux kernel versions. Therefore, you need to specify a kernel version for compilation. + "subsystems": [ ] --- Subsystem to be compiled and built. +} +``` + +2. Add the `config.gni` file to the `device/board/fnlink/v200zr/liteos_m` directory to describe the board and kernel used in the product demo. The following is an example of the description: + +``` +# Kernel type, e.g. "linux", "liteos_a", "liteos_m". +kernel_type = "liteos_m" --- Kernel type, which corresponds to kernel_type in the config.json file. + +# Kernel version. +kernel_version = "3.0.0" --- Kernel version, which corresponds to kernel_version in the config.json file. +``` + +3. Verify the `hb set` configuration: + + Run the `hb set` command, enter the project root directory, and press `Enter`. The `hb` command traverses all `config.json` files in the `//vendor//` directory and provides product compilation options. In the `config.json` file, `product_name` indicates the product name, `device_company` and `board` are used to locate the `//device/board//` directory and find the matching `/config.gni` file. If multiple file matches are found, it indicates that the board has been adapted to multiple kernels. In this case, `kernel_type` and `kernel_version` in the `config.json` file can be used to uniquely match the `config.gni` file and thereby determine the board with which kernel needs to be compiled and adapted. If the information shown below is displayed, the `hb set` configuration is correct. + + ![hb set](figure/bes2600_hb_set.png) + +​ You can run the `hb env` command to view the selected precompilation environment variables. + +![hb env](figure/bes2600_hb_env.png) + +Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D). + +## Kernel Porting + +To port the kernel, you need to complete the LiteOS-M Kconfig adaptation, GN compilation and building, and minimum adaptation for kernel startup. + +### LiteOS-M Kconfig Adaptation + +Run the `make menuconfig` command in the `//kernel/liteos_m` directory to select compilation configuration options. In the `Makefile` file, the `hb env` result is converted into environment variables, that is, `PRODUCT_PATH`, `DEVICE_PATH`, and `BOARD_COMPANY`. The sample code is as follows: + +``` +$(foreach line,$(shell hb env | sed 's/\[OHOS INFO\]/ohos/g;s/ /_/g;s/:_/=/g' || true),$(eval $(line))) +ifneq ($(ohos_kernel),liteos_m) +$(error The selected product ($(ohos_product)) is not a liteos_m kernel type product) +endif +--- Convert each line of hb env to a variable. For example, convert [OHOS INFO] device company: fnlink to ohos_device_company=fnlink. + +... + +ifeq ($(BOARD_COMPANY),) +BOARD_COMPANY:=$(ohos_device_company) +endif +... +export BOARD_COMPANY +--- Convert ohos_device_company to the BOARD_COMPANY environment variable. +``` + +Use the exported environment variables in the `//kernel/liteos_m/Kconfig` file. `Kconfiglib` uses `ulfalizer` to develop the Python-based version. In the [source code](https://github.com/ulfalizer/Kconfiglib), as drscribed in [function description](https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/kconfig/kconfiglib.py), the keyword `orsource` is used. In this keyword, `o` indicates `optional`, that is, the file is optional. `r` indicates `relative`, that is, the path of the file relative to the current file. + +``` +config SOC_COMPANY + string "SoC company name to locate soc build path" + help + This option specifies the SoC company name, used to locate the build path for soc. This option is set by the + SoC's Kconfig file, and should be exactly the same with SoC company path, and the user should generally avoid + modifying it via the menu configuration. + +orsource "../../device/board/*/Kconfig.liteos_m.shields" --- Load the configurations of all extension boards. To allow the extension boards provided by board vendor A to be used by board vendor B, the asterisk (*) instead of BOARD_COMPANY is used. As OpenHarmony supports the multi-kernel design, the Kconfig file uses liteos_m as the suffix. During board adaptation, the actual kernel name can be used as the suffix for extension during kernel adaptation. + +orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.defconfig.boards" --- Load all predefined board configurations of BOARD_COMPANY. + +choice + prompt "Board Selection" + +The orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.boards" --- Provide a list of available boards. + +endchoice + +orsource "../../device/soc/*/Kconfig.liteos_m.defconfig" --- Load the default configuration definitions of all SoCs. + +choice + prompt "SoC Series Selection" + +orsource "../../device/soc/*/Kconfig.liteos_m.series" --- Provide a list of available SoC series. + +endchoice + +orsource "../../device/soc/*/Kconfig.liteos_m.soc" --- Load all SoC configurations. +``` + +According to the `//kernel/liteos_m/Kconfig` file, the following `Kconfig` files need to be added to the `//device/board/fnlink` directory for adaptation: + +``` +. +├── v200zr --- Configuration of the v200zr +│ ├── Kconfig.liteos_m.board --- Configuration options of the v200zr board +│ ├── Kconfig.liteos_m.defconfig.board --- Default configuration items of the v200zr board +│   └── liteos_m +│   └── config.gni +├── Kconfig.liteos_m.boards --- Board configuration of Fn-Link +├── Kconfig.liteos_m.defconfig.boards --- Default board configuration of Fn-Link +├── Kconfig.liteos_m.shields --- Extension board configuration of Fn-Link +└── shields --- Extension board directory of Fn-Link + ├── v200zr-t0 --- Expansion board v200zr-t0 of Fn-Link + │   ├── Kconfig.liteos_m.defconfig.shield --- Default configuration of the expansion board v200zr-t0 + │   └── Kconfig.liteos_m.shield --- Configuration of the expansion board v200zr-t0 + ├── v200zr-t1 + │   ├── Kconfig.liteos_m.defconfig.shield + │   └── Kconfig.liteos_m.shield + └── Kconfig.liteos_m.shields +``` + +In `v200zr/Kconfig.liteos_m.board`, you need to set the board configuration options and the dependent `SoC` as follows: + +``` +config BOARD_v200zr + bool "select board v200zr" + depends on SOC_BES2600W --- The v200zr board uses the bes2600w SoC. Therefore, the v200zr board configuration options are available only when the bes2600w SoC is selected. +``` + +In `v200zr/Kconfig.liteos_m.defconfig.board`, the default name of `BOARD` is defined as `"v200zr"`. + +``` +if BOARD_v200zr +config BOARD + string --- No content is defined for string. Therefore, it is not visible to users. + default "v200zr" + +endif # BOARD_v200zr +``` + +According to the `//kernel/liteos_m/Kconfig` file, the following `Kconfig` files need to be added to the `//device/soc/bestechnic` directory for adaptation: + +``` +. +├── bes2600 --- bes2600 SoC series +│   ├── Kconfig.liteos_m.defconfig.bes2600w --- Configuration of the bes2600w SoC series provided by Bestechnic +│   ├── Kconfig.liteos_m.defconfig.series --- Default configuration of the bes2600 provided by Bestechnic +│   ├── Kconfig.liteos_m.series --- Configuration of the bes2600 SoC series provided by Bestechnic +│   └── Kconfig.liteos_m.soc --- Configuration of the bes2600 SoC provided by Bestechnic +├── Kconfig.liteos_m.defconfig --- Default SoC configuration of Bestechnic +├── Kconfig.liteos_m.series --- Configuration of the SoC series provided by Bestechnic +└── Kconfig.liteos_m.soc --- Configuration of the SoC provided by Bestechnic +``` + +In the `bes2600/Kconfig.liteos_m.series` file, configure the `bes2600 SoC series` and SoC architecture as follows: + +``` +config SOC_SERIES_BES2600 --- bes2600 SoC series configuration options + bool "Bestechnic 2600 Series" + select ARM --- When bes2600 is selected, the ARM architecture is selected by default. + select SOC_COMPANY_BESTECHNIC --- When bes2600 is selected, bestechnic is selected by default. The driver depends on the macro configuration. You can select the configuration to compile the driver of the corresponding vendor. + select CPU_CORTEX_M33 --- When bes2600 is selected, cortex-m33 CPU is selected by default. + help + Enable support for Bestechnic 2600 series +``` + +In the `bes2600/Kconfig.liteos_m.soc` file, provide the number of specific SoCs under the `bes2600 SoC series` as follows: + +``` +choice + prompt "Bestechnic 2600 series SoC" + depends on SOC_SERIES_BES2600 --- The following configuration options are displayed only when bes2600 Series is selected: + +config SOC_BES2600W --- Add the bes2600w SoC configuration option. + bool "SoC BES2600w" + +endchoice +``` + +In the `bes2600/Kconfig.liteos_m.defconfig.series` file, provide the following configuration that is used by default when the bes2600 SoC series is selected: + +``` +if SOC_SERIES_BES2600 --- The following default configuration options are added only when the bes2600 series is selected: + +rsource "Kconfig.liteos_m.defconfig.bes2600w" --- Add the default configuration that is used by default when bes2600 SoC series is selected. + +config SOC_SERIES --- Add the configuration that is used by default when SOC_SERIES is selected: + string + default "bes2600" + +endif +``` + +When the configuration is complete, set the `defconfig` storage path of `make menuconfig` based on the `kernel/liteos_m/Makefile` file. + +``` +ifeq ($(TEE:1=y),y) +tee = _tee +endif +ifeq ($(RELEASE:1=y),y) +CONFIG ?= $(PRODUCT_PATH)/kernel_configs/release$(tee).config +else +CONFIG ?= $(PRODUCT_PATH)/kernel_configs/debug$(tee).config --- The configuration file is saved in $(CONFIG) and is defined by the product. +endif + +... + +update_config menuconfig: + $(HIDE)test -f "$(CONFIG)" && cp -v "$(CONFIG)" .config && menuconfig $(args) && savedefconfig --out "$(CONFIG)" +``` + +In this example, the configuration file of `defconfig` is saved in `$(PRODUCT_PATH)/kernel_configs/debug.config`. It is empty by default upon creation. The directory and file structure of the product is as follows: + +``` +. +└── display_demo + ├── config.json + └── kernel_configs + └── debug.config +``` + +When the configuration is complete, run the `make menuconfig` command in the `kernel/liteos_m` directory to select `SoC Series`/`SoC`/`Board`. + +![board make menuconfig](figure/bes2600_board_make_menuconfig.png) + +The result is automatically saved in `$(PRODUCT_PATH)/kernel_configs/debug.config` and will be exported when `make menuconfig` is executed. + +### GN Build Adaptation + +The graphical configuration result of `Kconfig` generated in the previous step can be used as the input of GN build to determine whether to build different modules. In addition, to solve the problem of arbitrary use of `include` during GN build, modular compilation is used for kernel compilation, streamlining the entire compilation logic. For details, see *LiteOS-M Kernel BUILD.gn Compilation Guide*. + +In the `kernel/liteos_m/BUILD.gn` file, the compilation entrances of `Board` and `SoC` are specified as `//device/board/fnlink` and `//device/soc/bestechnic`. + +``` +deps += [ "//device/board/$device_company" ] +deps += [ "//device/soc/$LOSCFG_SOC_COMPANY" ] +``` + +Add the following content to `//device/board/fnlink/BUILD.gn`: + +``` +if (ohos_kernel_type == "liteos_m") { --- In the multi-kernel design, macros need to be used to isolate the adapted LiteOS-M kernel. + import("//kernel/liteos_m/liteos.gni") --- Import the kernel GN template. + module_name = get_path_info(rebase_path("."), "name") --- Dynamically obtain the current directory and use it as the module name, eliminating the need for manual synchronization between the directory and module name. + module_group(module_name) { --- Use the module_group template. + modules = [ --- Add the modules to be built. + ] + } +} +``` + +Modify the `//device/soc/bestechnic/BUILD.gn` file in a similar manner. + +### Kernel Boot Adaptation + +The system boot process consists of three phases: + +| Phase | Partitioning Planning | Description | +| --------- | ------------------------ | ----------------------------- | +| BOOT1 | [0, 0x10000] | The firmware is started. | +| BOOT2 | [0x2C010000, 0x2C020000] | The OTA update starts.| +| RTOS_MAIN | [0x2C080000, 0x2C860000] | The kernel is started. | + +In the third phase where the kernel is started, the file to be adapted is saved in `//device/soc/bestechnic/bes2600/liteos_m/sdk/bsp/rtos/liteos/liteos_m/board.c`. + +The general idea of kernel boot adaptation is as follows: + +1. `os_vector_init` is used to initialize interrupt vectors and interrupt processing functions. +2. `osKernelInitialize` is used to initialize the kernel. +3. The `board_main` thread is created to initialize the chip platform. +4. The kernel starts up and schedules the `osKernelStart` thread. + +This section describes step 3 in detail. Other steps involve invoking of kernel functions and are not described here. + +In step 3, before starting `OHOS_SystemInit`, `board_main` needs to complete the necessary actions as follows: + +``` +... + if(!ret) { + ... + OhosSystemAdapterHooks(); --- Configure the hook during system boot and complete the printing and driver initialization before OHOS_SystemInit is started. + ... + OHOS_SystemInit(); --- Start the OpenHarmony service and initialize components. + } +.... +``` + +The `OhosSystemAdapterHooks` function is in the `device/soc/bestechnic/bes2600/liteos_m/components/utils/src/hm_sys.c` file, as shown below: + +``` +int OhosSystemAdapterHooks(void) +{ + init_trace_system(); --- Initialize the printing function. + DeviceManagerStart(); --- Call the DeviceManagerStart function to initialize the HDF driver. This process is implemented by calling the driver configuration file hdf.hcs in the board code and implementing the drivers source code. + return 0; +} + +``` + +### littlefs File System Porting + + The `V200Z-R` development board uses the `Nor Flash` that supports `XIP` and has a maximum size of `32 MB`. The `example` file system can be used. During the adaptation, place the file system configuration file in the specified path. The file system image is then automatically generated based on the configuration and packaged into the burning package. + +1. Specify the directory for storing the file system `config.json` by using `flash_partition_dir`. + +``` + "flash_partition_dir": "fs" --- Store the file system configuration file in the vendor/bestechnic/display_demo/fs directory. +``` + +2. Place the following items in the `vendor/bestechnic/display_demo/fs` directory: + + - `wifi_Download_cfg.yaml`: configuration file for image burning. The partitions can be adjusted as required. + - `/data/data`: The first /`data` is the root directory to mount. The second `data` is the `data` directory in the root directory. You can place the configuration file in the second `data` directory or in any directory at the same level. During packaging, the whole root directory is packaged. + +3. Set the following items in the `config.json` file based on the `wifi_Download_cfg.yaml` file: + + - `fs_src`: name under which the file system is mounted. + - `fs_name`: name of the generated file system. + - `block_size`: size of the read data block. Set it to `4K` alignment and do not change the value. + - `fs_size`: size of the generated file system. + - `burn_name`: size of the burnt `bin` name. + - `enable`: whether to generate the file system. + +4. In the `//device/soc/bestechnic/bes2600/liteos_m/components/hdf_config/hdf.hcs` file, configure the start address for burning the file system, size of the file system, and size of the read data block (`block_size`). The reference configuration is as follows: + +``` + misc { + fs_config { + example_config { + match_attr = "littlefs_config"; + mount_points = ["/data"]; + partitions = [10]; + block_size = [4096]; + block_count = [1024]; + } + } + storage_config { + flash_config { + match_attr = "flash_config"; + partitions = [10]; + owner = [0]; + description = ["littlefs"]; + start_addr = [0xB60000]; + length = [0x400000]; + options = [3]; + } + } + } +``` + +In `device/soc/bestechnic/bes2600/liteos_m/components/fs/fs_init.c`, load data through `hdf` and read and write to `flash` as follows: + +``` +static int32_t FsDriverInit(struct HdfDeviceObject *object) +{ + if (object == NULL) { + return HDF_FAILURE; + } + if (object->property) { + if (FsGetResource(fs, object->property) != HDF_SUCCESS) { + HDF_LOGE("%s: FsGetResource failed", __func__); + return HDF_FAILURE; + } + } + for (int i = 0; i < sizeof(fs) / sizeof(fs[0]); i++) { + if (fs[i].mount_point == NULL) + continue; + + fs[i].lfs_cfg.read = littlefs_block_read; + fs[i].lfs_cfg.prog = littlefs_block_write; + fs[i].lfs_cfg.erase = littlefs_block_erase; + fs[i].lfs_cfg.sync = littlefs_block_sync; + + fs[i].lfs_cfg.read_size = 256; + fs[i].lfs_cfg.prog_size = 256; + fs[i].lfs_cfg.cache_size = 256; + fs[i].lfs_cfg.lookahead_size = 16; + fs[i].lfs_cfg.block_cycles = 1000; + + int ret = mount(NULL, fs[i].mount_point, "littlefs", 0, &fs[i].lfs_cfg); + HDF_LOGI("%s: mount fs on '%s' %s\n", __func__, fs[i].mount_point, (ret == 0) ? "succeed" : "failed"); + } + return HDF_SUCCESS; +} +``` + + + +### C Library Adaptation + +In the mini system, adapting the C library is a complex process. For details, see *Solution to Smooth Switchover Between musl and newlib for LiteOS-M Kernel*. The toolchain uses the `newlib` C library of the [gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2](https://gitee.com/link?target=https%3A%2F%2Fdeveloper.arm.com%2F-%2Fmedia%2FFiles%2Fdownloads%2Fgnu-rm%2F10.3-2021.10%2Fgcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2). In light of this, the `newlib` C library is used for system porting. Select `newlib` in `make menuconfig` of the kernel, as shown below. + +![image-20211212191013553](figure/bes2600_newlib_make_menuconfig.png) + +#### malloc Adaptation + +For details, see [The Red Hat newlib C Library-malloc](https://sourceware.org/newlib/libc.html#malloc). You can use either of the following methods to implement malloc adaptation: + +- Implement the `_sbrk_r` function. In this method, the memory allocation function in `newlib` is used. + +- Implement `_malloc_r`, `_realloc_r`, `_reallocf_r`, `_free_r`, `_memalign_r`, and `_malloc_usable_size_r`. In this method, the memory allocation function in the kernel can be used. + +To facilitate memory allocation algorithm optimization and fault locating based on services, the latter method is used in this example. + +First, as the symbols of the functions in the second method already exist in `newlib`, you need to use the `wrap` link option of `gcc` to replace these function symbols with the kernel implementation code in `//kernel/liteos_m/kal/libc/newlib/porting/src/malloc.c`. + +Then, add the `wrap` link option of these functions to `//device/board/fnlink/v200zr/liteos_m/config.gni`. + +``` +board_ld_flags += [ + "-Wl,--wrap=_malloc_r", + "-Wl,--wrap=_realloc_r", + "-Wl,--wrap=_reallocf_r", + "-Wl,--wrap=_free_r", + "-Wl,--wrap=_memalign_r", + "-Wl,--wrap=_malloc_usable_size_r", +] +``` + +#### vsprintf and Related Adaptation + +Implement `vprintf`, `vfprintf`, `printf`, `snprintf`, and `sprintf`. For details, see [vfprintf](https://sourceware.org/newlib/libc.html#vfprintf). + +Similar to `malloc` adaptation, the implementation of these functions must be provided first, that is, `//device/soc/bestechnic/bes2600/liteos_m/components/utils/src/printf.c`. In this example, the friendly implementation of the open-source protocol is used. Different from `malloc` adaptation, this function is provided by the SoC vendor. This is because the implementation size varies in terms of printing based on the project requirements, and therefore the kernel cannot provide a unified implementation. + +Then, add the `wrap` link option of these functions to `//device/board/fnlink/v200zr/liteos_m/config.gni`. + +``` +board_ld_flags += [ + "-Wl,--wrap=printf", + "-Wl,--wrap=sprintf", + "-Wl,--wrap=snprintf", + "-Wl,--wrap=vsnprintf", + "-Wl,--wrap=vprintf", +] +``` + +#### open and Related Adaptation + +The adaptation is implemented by the kernel and does not need attention from the SoC. The kernel file `//kernel/liteos_m/kal/libc/newlib/porting/src/fs.c` has been adapted to the `_read`, `_write`, and other related functions of `newlib`, as shown below. + +``` +... +ssize_t _read(int fd, void *buf, size_t nbyte) +{ + return LOS_Read(fd, buf, nbyte); +} + +ssize_t _write(int fd, const void *buf, size_t nbyte) +{ + return LOS_Write(fd, buf, nbyte); +} + +off_t _lseek(int fd, off_t offset, int whence) +{ + return LOS_Lseek(fd, offset, whence); +} +... +``` + +## Board-Level OS Porting + +### Driver Porting + +#### Porting the HDF Driver for the SoC Platform + +Driver adaptation files are stored in `drivers/adapter/platform`, including `gpio`, `i2c`, `pwm`, `spi`, `uart`, and `watchdog`, which are loaded using the `HDF` mechanism. This section uses `gpio` as an example. + +##### GPIO Driver Adaptation + +The `gpio` driver adaptation requires building adaptation and source code adaptation. + +The `//drivers/adapter/platform/gpio/BUILD.gn` file describes the building adaptation of the `gpio` driver, as shown below: + +``` +module_switch = defined(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO) --- If the GPIO configuration switch of the HDF is enabled, the following is built: +module_name = get_path_info(rebase_path("."), "name") + +hdf_driver(module_name) { + sources = [] + if (defined(LOSCFG_SOC_COMPANY_BESTECHNIC)) { --- If the Bestechnic SoC configuration switch is enabled, the Bestechnic GPIO driver is built. + sources += [ "gpio_bes.c" ] + } + + include_dirs = [ "." ] +} +``` + +The `//drivers/adapter/platform/gpio/gpio_bes.c` file describes the source code adaptation of the Bestechnic GPIO driver. +First, load the basic driver adaptation framework based on OpenHarmony `HDF`, as shown below: + +``` +struct HdfDriverEntry g_GpioDriverEntry = { + .moduleVersion = 1, + .moduleName = "BES_GPIO_MODULE_HDF", + .Bind = GpioDriverBind, + .Init = GpioDriverInit, + .Release = GpioDriverRelease, +}; +HDF_INIT(g_GpioDriverEntry); --- Load the GPIO driver through HDF_INIT. +``` + +Then, obtain the `hcs` parameter for initialization as follows: + +``` +static int32_t GpioDriverInit(struct HdfDeviceObject *device) +{ + int32_t ret; + struct GpioCntlr *gpioCntlr = NULL; + + if (device == NULL) { + HDF_LOGE("%s: device is NULL", __func__); + return HDF_ERR_INVALID_PARAM; + } + + gpioCntlr = GpioCntlrFromDevice(device); --- Obtain the GPIO configuration. + if (gpioCntlr == NULL) { + ... +``` + + + +#### Porting the HDF Drivers of Peripheral Components on the Board + +Peripheral components are connected to the board through the `SoC` bus. In this example, the peripheral component is a display, whose driver adaptation code is stored in the `//device/board/fnlink/drivers/liteos_m` directory. + +##### Display Driver Adaptation + +The display driver adaptation process is similar to the `SoC` driver adaptation process. In the `//device/board/fnlink/drivers/liteos_m/display/BUILD.gn` file, load the driver module based on the `hdf_driver` template, as shown below: + +``` +module_name = get_path_info(rebase_path("."), "name") +hdf_driver(module_name) { + sources = [ + "zzw395.c", + ] + include_dirs = [ + "//drivers/peripheral/display/interfaces/include", + ... + ] +} +``` + +In the `//device/board/fnlink/drivers/liteos_m/display/zzw395.c` file, load the display driver based on HDF, as shown below: + +``` +static struct HdfDriverEntry g_ZZW395DriverEntry = { + .moduleVersion = 1, + .moduleName = "HDF_PANEL_ZZW395", + .Bind = PanelDriverBind, + .Init = PanelDriverInit, + .Release = PanelDriverRelease, +}; + +HDF_INIT(g_ZZW395DriverEntry); +``` + +Configure the driver parameters based on `hcs`, which are loaded during `PanelDriverInit` initialization. The sample code is as follows: + +``` +static int32_t PanelDriverInit(struct HdfDeviceObject *object) +{ + if (object == NULL) { + return HDF_FAILURE; + } + HDF_LOGD("%s entry !!!", __func__); + if (object->property) { + if (PanelGetResource(&priv, object->property) != HDF_SUCCESS) { + HDF_LOGE("%s: PanelGetResource failed", __func__); + return HDF_FAILURE; + } + } +... +``` + +### Adapting OpenHarmony Subsystems + +The adaptation of OpenHarmony subsystems consists of two parts: + +- Add the target subsystem and component to the `config.json` file so that the component can be included in the compilation by the compilation system. +- Perform hardware adaptation or optional software adaptation for the `HAL` layer APIs of the component. + +#### Communication Subsystem Adaptation + +##### wifi_lite Component Adaptation + +Add the `wifi_lite` component of the `communication` subsystem to the `config.json` file. + +``` + { + "subsystem": "communication", + "components": [ + { + "component": "wifi_lite", + "optional": "true" + } + ] + }, +``` + +The `wifi_lite` component is described in the `//build/lite/components/communication.json` file as follows: + +``` + { + "component": "wifi_lite", +... + "targets": [ + "//foundation/communication/wifi_lite:wifi" --- wifi_lite in the compilation targets + ], +... + }, + +``` + +In the `//foundation/communication/wifi_lite/BUILD.gn` file, describe the path of the API header file to be adapted as follows: + +``` +config("include") { + include_dirs = [ "interfaces/wifiservice" ] --- The wifi_lite component provides the header file but not the implementation. Therefore, it exposes the adaptation directory to the hardware vendor for adaptation. The vendor provides the Wi-Fi protocol stack source code for implementation. +} + +group("wifi") { + public_configs = [ ":include" ] +} +``` + +In this example, Wi-Fi is provided by `SoC`. Therefore, the Wi-Fi adaptation source code is stored in the `//device/soc/bestechnic/hals/communication/wifi_lite/wifiservice` directory of `SoC`, which contains `wifi_device.c` and `wifi_hotspot.c` to adapt to `wifi_device.h` and `wifi_hotspot.h`, respectively. The sample code is as follows: + +``` +... +WifiErrorCode Scan(void) --- Wi-Fi hotspot scanning function in wifi_device.c, which is used to adapt to the Scan function in wifi_device.h. +{ + WifiErrorCode ret = ERROR_WIFI_BUSY; + + + if (IsWifiActive() != WIFI_STA_ACTIVE) + return ERROR_WIFI_IFACE_INVALID; + + if (g_HalHmosWifiInfo.scan_state == SCAN_REQUEST || + g_HalHmosWifiInfo.scan_state == SCAN_TRIGGER) + return ERROR_WIFI_BUSY; + + HalHmosWifiLock(); + ret = ((HalHmosSendEvent(HMOS_ON_WIFI_SCAN_STATE_CHANGED, NULL) == 0) ? WIFI_SUCCESS : ERROR_WIFI_BUSY); + HalHmosWifiUnLock(); + + return ret; +} +... +int GetSignalLevel(int rssi, int band) --- Function in wifi_hotspot.c for obtaining Wi-Fi hotspot parameters, which is used to adapt to the GetSignalLevel function in wifi_hotspot.h. +{ + if (band == HOTSPOT_BAND_TYPE_2G) { + if (rssi >= RSSI_LEVEL_4_2_G) + return RSSI_LEVEL_4; + if (rssi >= RSSI_LEVEL_3_2_G) + return RSSI_LEVEL_3; + if (rssi >= RSSI_LEVEL_2_2_G) + return RSSI_LEVEL_2; + if (rssi >= RSSI_LEVEL_1_2_G) + return RSSI_LEVEL_1; + } + + if (band == HOTSPOT_BAND_TYPE_5G) { + if (rssi >= RSSI_LEVEL_4_5_G) + return RSSI_LEVEL_4; + if (rssi >= RSSI_LEVEL_3_5_G) + return RSSI_LEVEL_3; + if (rssi >= RSSI_LEVEL_2_5_G) + return RSSI_LEVEL_2; + if (rssi >= RSSI_LEVEL_1_5_G) + return RSSI_LEVEL_1; + } + return ERROR_WIFI_INVALID_ARGS; +} +``` + +##### lwIP Component Adaptation + +By default, `lwip` is configured in the `LiteOS-M kernel` directory. Therefore, you can include the `lwip` directory in the `kernel` component for compilation. The sample code is as follows: + +``` + { + "subsystem": "kernel", + "components": [ + { + "component": "liteos_m", + "features": [ + "ohos_kernel_liteos_m_lwip_path = \"//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1\"" --- Specify the SoC vendor directory for compilation. + ] + } + ] + }, +``` + +The `//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/BUILD.gn` file describes the compilation of `lwip` as follows: + +``` +import("//kernel/liteos_m/liteos.gni") +import("$LITEOSTHIRDPARTY/lwip/lwip.gni") +import("$LITEOSTOPDIR/components/net/lwip-2.1/lwip_porting.gni") + +module_switch = defined(LOSCFG_NET_LWIP_SACK) +module_name = "lwip" +kernel_module(module_name) { + sources = LWIP_PORTING_FILES + LWIPNOAPPSFILES - + [ "$LWIPDIR/api/sockets.c" ] + [ "porting/src/ethernetif.c" ] --- Add the ethernetif.c file to adapt to the initialization of the Ethernet adapter. + defines = [ "LITEOS_LWIP=1" ] + defines += [ "CHECKSUM_BY_HARDWARE=1" ] +} + +config("public") { + defines = [ "_BSD_SOURCE=1" ] + include_dirs = + [ "porting/include" ] + LWIP_PORTING_INCLUDE_DIRS + LWIP_INCLUDE_DIRS +} + +``` + +In the `//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/porting/include/lwip/lwipopts.h` file, retain the original `lwip` configuration, on which the software bus depends, and add the following hardware adaptation options: + +``` +#ifndef _PORTING_LWIPOPTS_H_ +#define _PORTING_LWIPOPTS_H_ + +#include_next "lwip/lwipopts.h" --- Retain the original configuration. + +#define LWIP_NETIF_STATUS_CALLBACK 1 +#define LWIP_CHECKSUM_ON_COPY 0 +#define CHECKSUM_GEN_UDP 0 --- Add hardware adaptation options. + +#endif /* _PORTING_LWIPOPTS_H_ */ + +``` + +In the `//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/porting/src/ethernetif.c` file, add the adaptation to the initialization of the Ethernet adapter as follows: + +``` +err_t +ethernetif_init(struct netif *netif) +{ +... +#ifdef CHECKSUM_BY_HARDWARE + eth_hw_checksum_init(); +#endif +... + netif->linkoutput = low_level_output; + + netif->drv_send = liteos_low_level_output; + netif->hwaddr_len = NETIF_MAX_HWADDR_LEN; + low_level_init(netif); + driverif_init(netif); + return ERR_OK; +... +} +``` + +##### dsoftbus Component Adaptation + +Add the `dsoftbus` component to the `config.json` file as follows: + +``` +{ + "component": "dsoftbus", + "features": [ + "softbus_adapter_config = \"//vendor/bestechnic/mini_distributed_music_player/dsoftbus_lite_config\"" + ] +}, +``` + +The `dsoftbus` component provides the `softbus_adapter_config` configuration option in the `//foundation/communication/dsoftbus/dsoftbus.gni` file for configuration during porting. The configuration specifies the path for DSoftBus porting adaptation. + +In this example, `softbus_adapter_config` is set to `//vendor/bestechnic/mini_distributed_music_player/dsoftbus_lite_config`. The structure of this path is as follows: + +``` +. +├── feature_config --- DSoftBus configuration, for example, whether to enable self-discovery. +│   └── mini +│   └── config.gni +└── spec_config --- DSoftBus configuration, for example, the DSoftBus log level. + ├── softbus_config_adapter.c + ├── softbus_config_adapter.h + └── softbus_config_type.h +``` + +The following configuration items are defined in the `config.gni` file: + +| Item | Description | +| ------------------------------------------ | ------------------------ | +| dsoftbus_standard_feature_disc_ble | Whether to enable BLE discovery. | +| dsoftbus_standard_feature_disc_coap | Whether to enable CoAP discovery. | +| dsoftbus_standard_feature_conn_tcp | Whether to enable TCP connection. | +| dsoftbus_standard_feature_conn_br | Whether to enable BR connection. | +| dsoftbus_standard_feature_conn_ble | Whether to enable BLE connection. | +| dsoftbus_standard_feature_conn_p2p | Whether to enable P2P connection. | +| dsoftbus_standard_feature_trans_udp | Whether to enable UDP transmission. | +| dsoftbus_standard_feature_trans_udp_stream | Whether to enable the UDP transport stream. | +| dsoftbus_standard_feature_trans_udp_file | Whether to enable UDP file transfer. | +| dsoftbus_standard_feature_ip_auth | Whether to enable transmission channel authentication.| +| dsoftbus_standard_feature_auth_account | Whether to enable account-based authentication.| +| dsoftbus_standard_feature_qos | Whether to enable QoS. | + +The following configuration items are defined in the `softbus_config_adapter.c` file: + +| Item | Description | +| ------------------------------------ | ----------------------------- | +| SOFTBUS_INT_MAX_BYTES_LENGTH | SendBytes: maximum number of bytes that can be sent. | +| SOFTBUS_INT_MAX_MESSAGE_LENGTH | SendMessage: maximum length of a message that can be sent.| +| SOFTBUS_INT_CONN_BR_MAX_DATA_LENGTH | Maximum volume of data received over Bluetooth. | +| SOFTBUS_INT_CONN_RFCOM_SEND_MAX_LEN | Maximum volume of data sent over Bluetooth. | +| SOFTBUS_INT_ADAPTER_LOG_LEVEL | Log level. | +| SOFTBUS_STR_STORAGE_DIRECTORY | Storage directory. | + +After DSoftBus is configured, it is not started by default. Therefore, you need to invoke the `InitSoftBusServer` function through the startup framework as follows: + +``` +static void DSoftBus(void) +{ + osThreadAttr_t attr; + attr.name = "dsoftbus task"; + attr.attr_bits = 0U; + attr.cb_mem = NULL; + attr.cb_size = 0U; + attr.stack_mem = NULL; + attr.stack_size = 65536; + attr.priority = 24; + + extern void InitSoftBusServer(void); + if (osThreadNew((osThreadFunc_t) InitSoftBusServer, NULL, &attr) == NULL) { + printf("Falied to create WifiSTATask!\n"); + } +} + +APP_FEATURE_INIT(DSoftBus); +``` + +##### RPC Component Adaptation + +Add the following `rpc` configuration to the `config.json` file: + +``` +{ + "component": "rpc" +}, +``` + +Similarly, for the `rpc` component, you need to invoke the `StartDBinderService` function through the startup framework. The running of this function depends on the `IP` address obtained by the host. Therefore, invoke this function in the callback of the IP address change event registered by the lwIP protocol stack as follows: + +``` +static void RpcServerWifiDHCPSucCB(struct netif *netif, netif_nsc_reason_t reason, + const netif_ext_callback_args_t *args) +{ + (void) args; + if (netif == NULL) { + printf("%s %d, error: input netif is NULL!\n", __FUNCTION__, __LINE__); + return; + } + if (reason == LWIP_NSC_IPSTATUS_CHANGE) { + if (netif_is_up(netif) && !ip_addr_isany(&netif->ip_addr)) { + printf("%s %d, start rpc server!\n", __FUNCTION__, __LINE__); + StartDBinderService(); + } + } +} + +static void WifiDHCPRpcServerCB(void) +{ + NETIF_DECLARE_EXT_CALLBACK(WifiReadyRpcServerCallback); + netif_add_ext_callback(&WifiReadyRpcServerCallback, RpcServerWifiDHCPSucCB); +} + +APP_FEATURE_INIT(WifiDHCPRpcServerCB); +``` + +#### Startup Subsystem Adaptation + +For the `startup` subsystem, adapt the `bootstrap_lite` and `syspara_lite` components. Add the corresponding configuration items to the `vendor/bestechnic_bak/display_demo/config.json` file, as shown below: + +``` +{ + "subsystem": "startup", + "components": [ + { + "component": "bootstrap_lite" --- bootstrap_lite component + }, + { + "component": "syspara_lite", --- syspara_lite component + "features": [ + "enable_ohos_startup_syspara_lite_use_posix_file_api = true" + ] + } + ] +}, +``` + +When adapting the `bootstrap_lite` component, you need to add the following code snippet to the `//device/soc/bestechnic/bes2600/liteos_m/sdk/bsp/out/best2600w_liteos/_best2001.lds` file: + +``` + __zinitcall_bsp_start = .; + KEEP (*(.zinitcall.bsp0.init)) + KEEP (*(.zinitcall.bsp1.init)) + KEEP (*(.zinitcall.bsp2.init)) + KEEP (*(.zinitcall.bsp3.init)) + KEEP (*(.zinitcall.bsp4.init)) + __zinitcall_bsp_end = .; + __zinitcall_device_start = .; + KEEP (*(.zinitcall.device0.init)) + KEEP (*(.zinitcall.device1.init)) + KEEP (*(.zinitcall.device2.init)) + KEEP (*(.zinitcall.device3.init)) + KEEP (*(.zinitcall.device4.init)) + __zinitcall_device_end = .; + __zinitcall_core_start = .; + KEEP (*(.zinitcall.core0.init)) + KEEP (*(.zinitcall.core1.init)) + KEEP (*(.zinitcall.core2.init)) + KEEP (*(.zinitcall.core3.init)) + KEEP (*(.zinitcall.core4.init)) + __zinitcall_core_end = .; + __zinitcall_sys_service_start = .; + KEEP (*(.zinitcall.sys.service0.init)) + KEEP (*(.zinitcall.sys.service1.init)) + KEEP (*(.zinitcall.sys.service2.init)) + KEEP (*(.zinitcall.sys.service3.init)) + KEEP (*(.zinitcall.sys.service4.init)) + __zinitcall_sys_service_end = .; + __zinitcall_sys_feature_start = .; + KEEP (*(.zinitcall.sys.feature0.init)) + KEEP (*(.zinitcall.sys.feature1.init)) + KEEP (*(.zinitcall.sys.feature2.init)) + KEEP (*(.zinitcall.sys.feature3.init)) + KEEP (*(.zinitcall.sys.feature4.init)) + __zinitcall_sys_feature_end = .; + __zinitcall_run_start = .; + KEEP (*(.zinitcall.run0.init)) + KEEP (*(.zinitcall.run1.init)) + KEEP (*(.zinitcall.run2.init)) + KEEP (*(.zinitcall.run3.init)) + KEEP (*(.zinitcall.run4.init)) + __zinitcall_run_end = .; + __zinitcall_app_service_start = .; + KEEP (*(.zinitcall.app.service0.init)) + KEEP (*(.zinitcall.app.service1.init)) + KEEP (*(.zinitcall.app.service2.init)) + KEEP (*(.zinitcall.app.service3.init)) + KEEP (*(.zinitcall.app.service4.init)) + __zinitcall_app_service_end = .; + __zinitcall_app_feature_start = .; + KEEP (*(.zinitcall.app.feature0.init)) + KEEP (*(.zinitcall.app.feature1.init)) + KEEP (*(.zinitcall.app.feature2.init)) + KEEP (*(.zinitcall.app.feature3.init)) + KEEP (*(.zinitcall.app.feature4.init)) + __zinitcall_app_feature_end = .; + __zinitcall_test_start = .; + KEEP (*(.zinitcall.test0.init)) + KEEP (*(.zinitcall.test1.init)) + KEEP (*(.zinitcall.test2.init)) + KEEP (*(.zinitcall.test3.init)) + KEEP (*(.zinitcall.test4.init)) + __zinitcall_test_end = .; + __zinitcall_exit_start = .; + KEEP (*(.zinitcall.exit0.init)) + KEEP (*(.zinitcall.exit1.init)) + KEEP (*(.zinitcall.exit2.init)) + KEEP (*(.zinitcall.exit3.init)) + KEEP (*(.zinitcall.exit4.init)) + __zinitcall_exit_end = .; +``` + +The added code snippet is for storing the external APIs provided by `bootstrap_init`, which are injected. For details about the APIs, see `//utils/native/lite/include/ohos_init.h`. The following table lists the main macros for automatic service initialization. + +| API | Description | +| ---------------------- | -------------------------------- | +| SYS_SERVICE_INIT(func) | Entry for initializing and starting a core system service.| +| SYS_FEATURE_INIT(func) | Entry for initializing and starting a core system feature.| +| APP_SERVICE_INIT(func) | Entry for initializing and starting an application-layer service. | +| APP_FEATURE_INIT(func) | Entry for initializing and starting an application-layer feature. | + +![](../public_sys-resources/icon-note.gif) **NOTE**
+ You need to add a forcible link to the` lib` file generated by building the previous loaded components. + +​ If the `bootstrap_lite` component is configured in the `vendor/bestechnic/display_demo/config.json` file, as shown below: + +``` + { + "subsystem": "startup", + "components": [ + { + "component": "bootstrap_lite" + }, + ... + ] + }, +``` + +​ The `bootstrap_lite` component will compile the `//base/startup/bootstrap_lite/services/source/bootstrap_service.c` file. In this file, inject the `Init` function symbol to `__zinitcall_sys_service_start` and `__zinitcall_sys_service_end` through `SYS_SERVICE_INIT`. Because the `Init` function is not explicitly called, it needs to be forcibly linked to the final image. The sample code is as follows: + +``` +static void Init(void) +{ + static Bootstrap bootstrap; + bootstrap.GetName = GetName; + bootstrap.Initialize = Initialize; + bootstrap.MessageHandle = MessageHandle; + bootstrap.GetTaskConfig = GetTaskConfig; + bootstrap.flag = FALSE; + SAMGR_GetInstance()->RegisterService((Service *)&bootstrap); +} +SYS_SERVICE_INIT(Init); --- Once SYS (SYS_INIT) is started, the generated library needs to be forcibly linked. +``` + +​ In the `//base/startup/bootstrap_lite/services/source/BUILD.gn` file, the save path of `libbootstrap.a` is set to `out/v200zr/display_demo/libs` as follows: + +``` +static_library("bootstrap") { + sources = [ + "bootstrap_service.c", + "system_init.c", + ] + .... +``` + +​ In this case, you need to add `bootstrap` under `force_link_libs` in `vendor/bestechnic/display_demo/config.json`, as shown below: + +``` + "bin_list": [ + { + "elf_name": "wifiiot", + "bsp_target_name": "best2600w_liteos", + "signature": "false", + "burn_name": "rtos_main", + "enable": "true", + "force_link_libs": [ + "bootstrap", --- Forcibly link to libbootstrap.a. + ... + ] + }, +``` + + + +When the `syspara_lite` component is adapted, system parameters are written to a file for persistent storage. In the mini system, file operation APIs include `POSIX` and `HalFiles`. + +For access to the file system in the kernel, use the `POSIX` API, which means you need to add `enable_ohos_startup_syspara_lite_use_posix_file_api = true` to the `features` field. + +If you are using the `HalFiles` API, no modification is required. + +During adaptation of the `GetSerial` API, no `Serial Number` is written to the development board, which is different from the case in the production line. Therefore, you need to assign an attribute to uniquely identify the development board. In this example, the Wi-Fi MAC address is used. + +``` +#define ETH_ALEN 6 +#define MAC_BITS 4 +#define MAC_HIGH_MASK 0xf0 +#define MAC_LOW_MASK 0x0f +#define HEX_A 0xa +#define CHAR_NUM_OFFSET 0x30 +#define CHAR_CAPITAL_OFFSET 0x37 +#define STR_END_FLAG '\0' + +typedef unsigned char u8; + +static char serialNumber[2*ETH_ALEN + 1]; --- The last character is used as the end character '\0'. + + +static char Hex2Char(u8 hex) +{ + if (hex < HEX_A) { + return hex + CHAR_NUM_OFFSET; --- Convert the value 0 to char '0'. + } else { + return hex + CHAR_CAPITAL_OFFSET; --- Convert the value 0xa to char 'A'. + } +} + +const char* HalGetSerial(void) +{ + char macAddr[ETH_ALEN]; + // as devboard has no production serial number, we just + // use wifi mac address as device serial number. + if (serialNumber[0] == STR_END_FLAG) { --- The MAC address is obtained only when the API is invoked for the first time. + extern int bwifi_get_own_mac(u8 *addr); + bwifi_get_own_mac(macAddr); --- Obtain the MAC address. + int j = 0; + for (int i = 0; i < ETH_ALEN; i++) { + u8 lowFour, highFour; + highFour = (macAddr[i] & MAC_HIGH_MASK) >> MAC_BITS; + serialNumber[j] = Hex2Char(highFour); + j++; + lowFour = macAddr[i] & MAC_LOW_MASK; + serialNumber[j] = Hex2Char(lowFour); + j++; + } --- Convert the MAC address to the serial number. + } + return serialNumber; +} +``` + +#### DFX Subsystem Adaptation + +To adapt the DFX subsystem, you need to add the `hilog_lite` component in the `config.json` file. + +``` +{ + "subsystem": "hiviewdfx", + "components": [ + { + "component": "hilog_lite", + "optional": "true" + } + ] +}, +``` + +Register the log output implementation function in `//device/soc/bestechnic/bes2600/liteos_m/components/utils/src/hm_sys.c`. + +``` +boolean HilogProc_Impl(const HiLogContent *hilogContent, uint32 len) +{ + char tempOutStr[LOG_FMT_MAX_LEN] = {0}; + if (LogContentFmt(tempOutStr, sizeof(tempOutStr), hilogContent) > 0) { + printf(tempOutStr); + } + return TRUE; +} + +HiviewRegisterHilogProc(HilogProc_Impl); +``` + +#### distributedschedule Subsystem Adaptation + +To adapt the `distributedschedule` subsystem, you need to add the `samgr_lite` component in the `config.json` file, as shown below: + +``` +{ + "subsystem": "distributedschedule", + "components": [ + { + "component": "samgr_lite", + "features": [ + "config_ohos_distributedschedule_samgr_lite_shared_task_size = 4096" + ] + } + ] +}, +``` + +In the mini system, the default size of the shared task stack for `samgr_lite` is `0x800`. To avoid stack overflow, adjust the size to `0x1000`. + +#### Security Subsystem Adaptation + +To adapt the `security` subsystem, you need to add the `huks/deviceauth_lite` component in the `config.json` file, as shown below: + +``` + { + "subsystem": "security", + "components": [ + { + "component": "huks", + "features": [ + "huks_use_lite_storage = true", + "huks_use_hardware_root_key = true", + "huks_config_file = \"hks_config_lite.h\"", + "huks_key_store_path = \"/data/\"", + "ohos_security_huks_mbedtls_porting_path = \"//device/soc/bestechnic/hals/mbedtls\"" + ] + }, + { + "component": "deviceauth_lite", + "features": [ + "deviceauth_storage_path = \"/data/\"", + "deviceauth_hichain_thread_stack_size = 9472" + ] + } + ] + } +``` + +During `huks` component adaptation, set `huks_key_store_path` to the path for storing the key and `ohos_security_huks_mbedtls_porting_path` to the directory for `mbedtls` adaptation, so that the chip can adapt `mbedtls` to hardware random numbers. + +During `deviceauth_lite` component adaptation, set `deviceauth_storage_path` to the path for storing device authentication information and `deviceauth_hichain_thread_stack_size` to the thread stack size. + +#### Multimedia Subsystem Adaptation + +To adapt the multimedia subsystem, you need to add the `histreamer` component in the `config.json` file, as shown below: + +``` +{ + "subsystem": "multimedia", + "components": [ + { + "component": "histreamer", + "features": [ + "multimedia_histreamer_enable_plugin_hdi_adapter = true", + "multimedia_histreamer_enable_plugin_minimp3_adapter = true", + "multimedia_histreamer_enable_plugin_ffmpeg_adapter = false", + "config_ohos_multimedia_histreamer_stack_size = 65536" + ] + } + ] +}, +``` + +The configuration items of the `histreamer` component are described as follows: + +| Item | Description | +| --------------------------------------------------- | ------------------------------- | +| multimedia_histreamer_enable_plugin_hdi_adapter | Whether to enable histreamer to connect to the HDMI interface.| +| multimedia_histreamer_enable_plugin_minimp3_adapter | Whether to enable the plug-in to adapt to miniMP3. | +| multimedia_histreamer_enable_plugin_ffmpeg_adapter | Whether to enable the plug-in to adapt to FFmpeg. | +| config_ohos_multimedia_histreamer_stack_size | Size of the histreamer stack. | + +#### utils Subsystem Adaptation + +To adapt the `utils` subsystem, you need to add the `kv_store`, `js_builtin`, `timer_task`, and `kal_timer` components in the `config.json` file, as shown below: + +``` +{ + "subsystem": "utils", + "components": [ + { + "component": "kv_store", + "features": [ + "enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true" + ] + }, + { + "component": "js_builtin" + }, + { + "component": "timer_task" + }, + { + "component": "kal_timer", + } + ] +}, +``` + +Similar to that in the `syspara_lite` component, the key-value pair is written to a file during adaptation of the `kv_store` component. In the mini system, file operation APIs include `POSIX` and `HalFiles`. For access to the file system in the kernel, use the `POSIX` API, which means that you need to add `enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true` to the `features` field. If you are using the `HalFiles` API, no modification is required. + +#### Graphics Subsystem Adaptation + +To adapt the `graphic` subsystem, you need to add the `graphic_utils` component in the `config.json` file, as shown below: + +``` + "components": [ + { + "component": "graphic_utils", + "features": [ + "enable_ohos_graphic_utils_product_config = true" + ] + }, + { + "component": "ui" + } + ] + } +``` + +For details about `graphic` configuration, see `//vendor/bestechnic/display_demo/graphic_config/product_graphic_lite_config.h`. + +For details about `graphic` adaptation, see `//device/soc/bestechnic/bes2600/liteos_m/components/ui`, . The main functions are as follows: + +- `display_device`: instantiates `BaseGfxEngine`. +- `touch_input`: instantiates `PointerInputDevice`. +- `UiMainTask`: initializes the font engine and executes rendering tasks. + +Layers of the `graphic` subsystem: + +``` +aafwk_lite + appexecfwk_lite (AAFWK + APPEXECFWK) + | +ace_engine_lite + jerryscript + i18n_lite + resmgr_lite + utils/native/lite/... (ACE and JS engines and their dependencies) + | +graphic_ui + graphic_utils (Graphic framework) + | +giflib + libjpeg + libpng + qrcodegen + freetype... (Third-party graphics library) +``` + +For details about the graphic application demo, see the `//vendor/bestechnic/display_demo/tests/app.cpp` file, as shown below: + +``` +/* ui app entry */ +void RunApp() +{ +#ifdef UI_TEST + AnimatorDemoStart(); --- native ui demo +#elif defined(ABILITY_TEST) + StartJSApp(); --- js demo +#endif +} + +void AppEntry(void) +{ + UiMain(); +} + +APP_FEATURE_INIT(AppEntry); +``` + +#### ACE Subsystem Adaptation + +To adapt the ACE subsystem, you need to add the `ace_engine_lite` component in the `config.json` file, as shown below: + + { + "subsystem": "ace", + "components": [ + { + "component": "ace_engine_lite", + "features": [ + "enable_ohos_ace_engine_lite_product_config = true" + ] + } + ] + }, + +For details about the `ace_engine_lite` configuration, see `//vendor/bestechnic/display_demo/ace_lite_config/product_acelite_config.h`. + +The `ace_lite` application is developed in JavaScript. The detailed procedure is as follows: + +1. Use DevEco Studio to compile a JavaScript application. For details, see [Lite Wearable Development Specifications](https://developer.harmonyos.com/en/docs/documentation/doc-references/lite-wearable-file-0000001176751380). +2. Use the Previewer feature to preview the application and obtain the JS package `entry\.preview\intermediates\res\debug\lite\assets\js\default`. +3. Place the JS package to the corresponding file system path `vendor/bestechnic/display_demo/fs/data/data/js`, as shown below: + +``` +├── app.js +├── common +├── i18n +├── manifest.json +└── pages +``` + +4. Start building to generate the system image. Burn the system image the development board, and the system will load and start the `ace` application from `app.js`. + +#### aafwk Subsystem Adaptation + +To adapt the `aafwk` subsystem, you need to add the `aafwk_lite` component in the `config.json` file, as shown below: + +``` + { + "subsystem": "aafwk", + "components": [ + { + "component": "aafwk_lite", + "features": [ + "enable_ohos_appexecfwk_feature_ability = true", --- Enable the FA to support the graphics capability. + "config_ohos_aafwk_ams_task_size = 4096" --- Configure the size of the aafwk stack. + ] + } + ] + }, +``` + +For details about the `aafwk_lite` use cases, see the `vendor/bestechnic/display_demo/tests/ability` directory, which includes the `launcher` and `js app` applications. The function invocation process of the applications is described as follows: + +1. `launcher` application: Use `InstallLauncher` to install the `native ui` application, whose `BundleName` is `"com.example.launcher"`. After `AbilityMgrSliteFeature` is started, `AbilityMgrHandler::StartLauncher()` is invoked to start the `launcher` application. + +2. `StartJSApp` application: Use `StartAbility` to start any `Want` and pass `want data` to `JS_APP_PATH`, + `SetWantData(&want, JS_APP_PATH, strlen(JS_APP_PATH) + 1)`. + +#### appexecfwk Subsystem Adaptation + +To adapt the `appexecfwk` subsystem, you need to add the `appexecfwk_lite` component in the `config.json` file, as shown below: + +``` + { + "subsystem": "appexecfwk", + "components": [ + { + "component": "appexecfwk_lite" + } + ] + }, +``` + +## Compatibility Test + +### Product Compatibility Specifications + +For details about product compatibility specifications, see [Introduction to Product Compatibility SIG](https://gitee.com/openharmony-sig/compatibility/tree/master). + +### XTS Test Cases + +For details about the `XTS` test cases, see [XTS](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-xts-guide.md). To adapt the `XTS` subsystem, you need to add the `xts_acts`/`xts_tools` component in the `config.json` file, as shown below: + + { + "subsystem": "xts", + "components": [ + { "component": "xts_acts", "features": + [ + "config_ohos_xts_acts_utils_lite_kv_store_data_path = \"/data\"", + "enable_ohos_test_xts_acts_use_thirdparty_lwip = true" + ] + }, + { "component": "xts_tools", "features":[] } + ] + } + +Where: + +- `config_ohos_xts_acts_utils_lite_kv_store_data_path` is the name of the root directory to which the file system is mounted. +- `enable_ohos_test_xts_acts_use_thirdparty_lwip` indicates whether to use the source code in the `thirdparty/lwip` directory. The value `true` means to use the source code in the `thirdparty/lwip` directory, and `false` means the opposite. + +After the execution is complete, `xx Tests xx Failures xx Ignored` is displayed, as shown below: + +``` +... +[16:53:43:438]../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:793:testKvStoreMaxSize004:PASS +[16:53:43:438]+-------------------------------------------+ +[16:53:43:438] +[16:53:43:438]----------------------- +[16:53:43:438]32 Tests 0 Failures 0 Ignored +[16:53:43:438]OK +[16:53:43:439]All the test suites finished! +``` + +### Report Submission + +Save the preceding `XTS` test result as a test report and upload it to the OpenHarmony compatibility test website. This is a prerequisite for synchronizing the code from the `sig` repository to the `master` repository. The procedure is as follows: + +Step 1: Compress the `XTS` test report into a `zip` file. + +Step 2: Generate the SHA checksum of the test report. In this example, the SHA checksum is generated by uploading the `zip` file to the [SHA checksum online generator](https://tool.lmeee.com/jiami/filehash). + +Step 3: Go to the `OpenHarmony` [compatibility test website](https://www.openharmony.cn/old/#/Compatibility_test) and upload the report. + + - Set `API Level` to the `"sdkApiLevel"` value in the report. + - Set `OS` to the `"OS Version"` value in the report. + +## Coming Soon + +The following aspects will be added in the future: + +- Bluetooth +- `bms` package installation +- Verifying `bytecode` for running `JS` +- Distributed capabilities: `dms` and `dm` +- Example of a distributed music player diff --git a/en/device-dev/porting/porting-minichip-cases.md b/en/device-dev/porting/porting-minichip-cases.md new file mode 100644 index 0000000000000000000000000000000000000000..1b550e80b5b3864eaf47157b8306d64086411d0e --- /dev/null +++ b/en/device-dev/porting/porting-minichip-cases.md @@ -0,0 +1,4 @@ +# Mini System SoC Porting Cases + +- **[Mini-System Devices with Screens — Bestechnic SoC Porting Case](porting-bes2600w-on-minisystem-display-demo.md)** +- **[Combo Solution – ASR Chip Porting Case](porting-asr582x-combo-demo.md)** diff --git a/en/device-dev/porting/porting.md b/en/device-dev/porting/porting.md index d890f8bf9efeeff3cdbc17d1aec53751395fa4bf..3e5a13a8b792dd17e16dd6dda9d957dc043c767f 100644 --- a/en/device-dev/porting/porting.md +++ b/en/device-dev/porting/porting.md @@ -1,11 +1,8 @@ # Porting -- **[Third-Party Library Porting Guide](porting-thirdparty.md)** - - **[Mini System SoC Porting Guide](porting-minichip.md)** - - **[Small System SoC Porting Guide](porting-smallchip.md)** - -- **[Standard System Porting Guide](standard-system-porting-guide.md)** +- **[Standard System Porting Guide](standard-system-porting-guide.md)** +- **[Third-Party Library Porting Guide for Mini and Small Systems](porting-thirdparty.md)** diff --git a/en/device-dev/porting/public_sys-resources/icon-caution.gif b/en/device-dev/porting/public_sys-resources/icon-caution.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-caution.gif differ diff --git a/en/device-dev/porting/public_sys-resources/icon-danger.gif b/en/device-dev/porting/public_sys-resources/icon-danger.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-danger.gif differ diff --git a/en/device-dev/porting/public_sys-resources/icon-note.gif b/en/device-dev/porting/public_sys-resources/icon-note.gif new file mode 100644 index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-note.gif differ diff --git a/en/device-dev/porting/public_sys-resources/icon-notice.gif b/en/device-dev/porting/public_sys-resources/icon-notice.gif new file mode 100644 index 0000000000000000000000000000000000000000..86024f61b691400bea99e5b1f506d9d9aef36e27 Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-notice.gif differ diff --git a/en/device-dev/porting/public_sys-resources/icon-tip.gif b/en/device-dev/porting/public_sys-resources/icon-tip.gif new file mode 100644 index 0000000000000000000000000000000000000000..93aa72053b510e456b149f36a0972703ea9999b7 Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-tip.gif differ diff --git a/en/device-dev/porting/public_sys-resources/icon-warning.gif b/en/device-dev/porting/public_sys-resources/icon-warning.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/porting/public_sys-resources/icon-warning.gif differ diff --git a/en/device-dev/quick-start/Readme-EN.md b/en/device-dev/quick-start/Readme-EN.md index 857374e4c22402f600baa2ee7b78935c1577f728..0efb4c35dffce1b8d80785002855b0a70c2671d1 100644 --- a/en/device-dev/quick-start/Readme-EN.md +++ b/en/device-dev/quick-start/Readme-EN.md @@ -1,36 +1,47 @@ -# Getting Started - -- [Mini and Small Systems](quickstart-lite.md) - - [Overview](quickstart-lite-overview.md) - - [Introduction](quickstart-lite-introduction.md) - - [Hi3861 Development Board](quickstart-lite-introduction-hi3861.md) - - [Hi3516 Development Board](quickstart-lite-introduction-hi3516.md) - - [Hi3518 Development Board](quickstart-lite-introduction-hi3518.md) - - [Environment Setup](quickstart-lite-env-setup.md) - - [Overview](quickstart-lite-env-setup-overview.md) - - [Setting Up Windows Development Environment](quickstart-lite-env-setup-windows.md) - - [Setting Up Ubuntu Development Environment](quickstart-lite-env-setup-linux.md) - - [FAQs](quickstart-lite-env-setup-faqs.md) - - [How to Develop](quickstart-lite-steps.md) - - [Hi3861](quickstart-lite-steps-hi3861.md) - - [Setting Up the Environment](quickstart-lite-steps-hi3861-setting.md) - - [Setting Up WLAN Connection](quickstart-lite-steps-hi3861-connection.md) - - [Running a Hello World Program](quickstart-lite-steps-hi3861-running.md) - - [FAQs](quickstart-lite-steps-hi3861-faqs.md) - - [Hi3516](quickstart-lite-steps-hi3516.md) - - [Setting Up the Environment](quickstart-lite-steps-hi3516-setting.md) - - [Running a Hello OHOS Program](quickstart-lite-steps-hi3516-running.md) - - [Developing a Driver](quickstart-lite-steps-hi3516-program.md) - - [FAQs](quickstart-lite-steps-hi3516-faqs.md) - - [Hi3518](quickstart-lite-steps-hi3518.md) - - [Setting Up the Environment](quickstart-lite-steps-hi3518-setting.md) - - [Running a Hello OHOS Program](quickstart-lite-steps-hi3518-running.md) - - [FAQs](quickstart-lite-steps-hi3518-faqs.md) -- [Standard System](quickstart-standard.md) - - [Introduction](quickstart-standard-overview.md) - - [Setting Up Windows Development Environment](quickstart-standard-windows-environment.md) - - [Setting Up Ubuntu Development Environment in Docker Mode](quickstart-standard-docker-environment.md) - - [Setting Up Ubuntu Development Environment with Installation Package](quickstart-standard-package-environment.md) - - [Burning Images](quickstart-standard-burn.md) - - [Running an Image](quickstart-standard-running.md) - - [FAQs](quickstart-standard-faqs.md) \ No newline at end of file +# Getting Started +- Getting Started for Mini and Small Systems + - [Mini and Small System Overview](quickstart-ide-lite-overview.md) + - Environment Preparation + - [Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-lite-env-setup-win-ubuntu.md) + - [Obtaining Source Code](quickstart-ide-lite-sourcecode-acquire.md) + - [Creating a Source Code Project](quickstart-ide-lite-create-project.md) + - Running a Hello World Program + - Hi3861 Development Board + - [Writing a Hello World Program](quickstart-ide-lite-steps-hi3861-application-framework.md) + - [Building](quickstart-ide-lite-steps-hi3861-building.md) + - [Burning](quickstart-ide-lite-steps-hi3861-burn.md) + - [Networking](quickstart-ide-lite-steps-hi3861-netconfig.md) + - [Debugging and Verification](quickstart-ide-lite-steps-hi3861-debug.md) + - [Running](quickstart-ide-lite-steps-hi3816-running.md) + - Hi3516 Development Board + - [Writing a Hello World Program](quickstart-ide-lite-steps-hi3516-application-framework.md) + - [Building](quickstart-ide-lite-steps-hi3516-building.md) + - [Burning](quickstart-ide-lite-steps-hi3516-burn.md) + - [Running](quickstart-ide-lite-steps-hi3516-running.md) + - Appendix + - Introduction to Development Boards + - [Introduction to the Hi3861 Development Board](quickstart-ide-lite-introduction-hi3861.md) + - [Introduction to the Hi3516 Development Board](quickstart-ide-lite-introduction-hi3516.md) + - [Getting Started with Mini and Small Systems (Installation Package Mode)](quickstart-lite-package-directory.md) +- Getting Started for Standard System + - [Standard System Overview](quickstart-ide-standard-overview.md) + - Environment Preparation + - [Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-standard-env-setup-win-ubuntu.md) + - [Obtaining Source Code](quickstart-ide-standard-sourcecode-acquire.md) + - [Creating a Source Code Project](quickstart-ide-standard-create-project.md) + - Running a Hello World Program + - Hi3516 Development Board + - [Writing a Hello World Program](quickstart-ide-standard-running-hi3516-create.md) + - [Building](quickstart-ide-standard-running-hi3516-build.md) + - [Burning](quickstart-ide-standard-running-hi3516-burning.md) + - [Running](quickstart-ide-standard-running-hi3516-running.md) + - RK3568 Development Board + - [Writing a Hello World Program](quickstart-ide-standard-running-rk3568-create.md) + - [Building](quickstart-ide-standard-running-rk3568-build.md) + - [Burning](quickstart-ide-standard-running-rk3568-burning.md) + - [Running](quickstart-ide-standard-running-rk3568-running.md) + - Appendix + - Introduction to Development Boards + - [Introduction to the Hi3516 Development Board](quickstart-ide-standard-board-introduction-hi3516.md) + - [Introduction to the RK3568 Development Board](quickstart-ide-standard-board-introduction-rk3568.md) + - [Getting Started for Standard System (Installation Package Mode)](quickstart-standard-package-directory.md) diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334.png b/en/device-dev/quick-start/figures/2021-01-27_170334.png deleted file mode 100644 index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/2021-01-27_170334.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/appearance-of-hi3861-wlan-module.png b/en/device-dev/quick-start/figures/appearance-of-hi3861-wlan-module.png deleted file mode 100644 index ed771826a71507b493cccdd35f58865769b40220..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/appearance-of-hi3861-wlan-module.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/appearance-of-the-hi3861-mother-board.png b/en/device-dev/quick-start/figures/appearance-of-the-hi3861-mother-board.png deleted file mode 100644 index f58498fb620fb55c909c3ba5ae2f259470da0093..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/appearance-of-the-hi3861-mother-board.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/button.png b/en/device-dev/quick-start/figures/button.png deleted file mode 100644 index 686385e096a24ec1906169d2b11f75030c386b9f..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/button.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png b/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png deleted file mode 100644 index 0a54838f89062fd67328ef76e4a1cf770c6aee13..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/deveco-device-tool-install-sucessful.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/directory-for-storing-the-generated-files.png b/en/device-dev/quick-start/figures/directory-for-storing-the-generated-files.png deleted file mode 100644 index f354b2d27ce06bd5af6a8702c0894bf5c50a97bb..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/directory-for-storing-the-generated-files.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/download-zlib.png b/en/device-dev/quick-start/figures/download-zlib.png deleted file mode 100644 index 3b7f6f4766c54f6ca1e0057fc8f869785cc63e56..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/download-zlib.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png b/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png new file mode 100644 index 0000000000000000000000000000000000000000..c5548cb227bd024b49aa3adba0a20869581448e8 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001114129426.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001135394334.png b/en/device-dev/quick-start/figures/en-us_image_0000001135394334.png new file mode 100644 index 0000000000000000000000000000000000000000..27fe1d133a31b275a2788cab1f5b37dd3450a7df Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001135394334.png differ diff --git a/en/device-dev/quick-start/figures/hi3516-burning-succeeded-net.png b/en/device-dev/quick-start/figures/en-us_image_0000001160649343.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516-burning-succeeded-net.png rename to en/device-dev/quick-start/figures/en-us_image_0000001160649343.png diff --git a/en/device-dev/quick-start/figures/monitor.png b/en/device-dev/quick-start/figures/en-us_image_0000001164506870.png similarity index 100% rename from en/device-dev/quick-start/figures/monitor.png rename to en/device-dev/quick-start/figures/en-us_image_0000001164506870.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001171426014.png b/en/device-dev/quick-start/figures/en-us_image_0000001171426014.png new file mode 100644 index 0000000000000000000000000000000000000000..0a03074ea251b2e2b94ae8370a7d7fb01757f21d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001171426014.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001193920448.png b/en/device-dev/quick-start/figures/en-us_image_0000001193920448.png new file mode 100644 index 0000000000000000000000000000000000000000..378084aa4b6a467f549a6c97bde39c7720d6b427 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001193920448.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001193983334.png b/en/device-dev/quick-start/figures/en-us_image_0000001193983334.png new file mode 100644 index 0000000000000000000000000000000000000000..216476f79ed241c3b77d7d2d688cb6fcdc1d8423 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001193983334.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001194080414.png b/en/device-dev/quick-start/figures/en-us_image_0000001194080414.png new file mode 100644 index 0000000000000000000000000000000000000000..014bd33ebc03f13666ece9abfd3636658cead3fc Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001194080414.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001194504874.png b/en/device-dev/quick-start/figures/en-us_image_0000001194504874.png new file mode 100644 index 0000000000000000000000000000000000000000..fdd12932d3777bd30a208e539a78ede6384cce19 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001194504874.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001194821710.png b/en/device-dev/quick-start/figures/en-us_image_0000001194821710.png new file mode 100644 index 0000000000000000000000000000000000000000..17d64a31a527a2b7453cc8490655609bd338ad7c Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001194821710.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001194984912.png b/en/device-dev/quick-start/figures/en-us_image_0000001194984912.png new file mode 100644 index 0000000000000000000000000000000000000000..3c8dca4d0e669c502404754a2685b5877513dda0 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001194984912.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001198466090.png b/en/device-dev/quick-start/figures/en-us_image_0000001198466090.png new file mode 100644 index 0000000000000000000000000000000000000000..84d42fffbd87d0e719c69b6deda9e6c5e2b2db13 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001198466090.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001198566364.png b/en/device-dev/quick-start/figures/en-us_image_0000001198566364.png new file mode 100644 index 0000000000000000000000000000000000000000..1ba77b7feaca23043e71171824cdead7c4f8f108 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001198566364.png differ diff --git a/en/device-dev/quick-start/figures/hi3518-reboot-success.png b/en/device-dev/quick-start/figures/en-us_image_0000001198626874.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3518-reboot-success.png rename to en/device-dev/quick-start/figures/en-us_image_0000001198626874.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001198722374.png b/en/device-dev/quick-start/figures/en-us_image_0000001198722374.png new file mode 100644 index 0000000000000000000000000000000000000000..c6507f28b980b84c65102aa844e93f806cb490a9 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001198722374.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001198889702.png b/en/device-dev/quick-start/figures/en-us_image_0000001198889702.png new file mode 100644 index 0000000000000000000000000000000000000000..07914f4f34921b06819ceb49cf63366dcc7f8502 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001198889702.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001198943768.png b/en/device-dev/quick-start/figures/en-us_image_0000001198943768.png new file mode 100644 index 0000000000000000000000000000000000000000..5a709092da504fbb090ad8d44938e435712bc0eb Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001198943768.png differ diff --git a/en/device-dev/quick-start/figures/bootloader.png b/en/device-dev/quick-start/figures/en-us_image_0000001209906547.png similarity index 100% rename from en/device-dev/quick-start/figures/bootloader.png rename to en/device-dev/quick-start/figures/en-us_image_0000001209906547.png diff --git a/en/device-dev/quick-start/figures/reset_success.png b/en/device-dev/quick-start/figures/en-us_image_0000001210385161.png similarity index 100% rename from en/device-dev/quick-start/figures/reset_success.png rename to en/device-dev/quick-start/figures/en-us_image_0000001210385161.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215342695.png b/en/device-dev/quick-start/figures/en-us_image_0000001215342695.png deleted file mode 100644 index fb2db198cc61ed10136f0e3382deed352300a62b..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001215342695.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215720398.png b/en/device-dev/quick-start/figures/en-us_image_0000001215720398.png new file mode 100644 index 0000000000000000000000000000000000000000..7d3cfad060738e0802619fc90017db774b6c0949 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215720398.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215737140.png b/en/device-dev/quick-start/figures/en-us_image_0000001215737140.png new file mode 100644 index 0000000000000000000000000000000000000000..393d6f7fbedfc3ad5556fd1ab23f5ee093a4d90f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215737140.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215743910.png b/en/device-dev/quick-start/figures/en-us_image_0000001215743910.png new file mode 100644 index 0000000000000000000000000000000000000000..2abb1d54a0ca92661418c44ea7b8338ede0c56ed Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215743910.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215878922.png b/en/device-dev/quick-start/figures/en-us_image_0000001215878922.png new file mode 100644 index 0000000000000000000000000000000000000000..8fa9d13fe838efe888dee5e645fdb9cbd67d84df Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215878922.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215879750.png b/en/device-dev/quick-start/figures/en-us_image_0000001215879750.png new file mode 100644 index 0000000000000000000000000000000000000000..9d2abb322f686beae3152cb08cf6ddf44da85052 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215879750.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001215897530.png b/en/device-dev/quick-start/figures/en-us_image_0000001215897530.png new file mode 100644 index 0000000000000000000000000000000000000000..72dd27e9a926f6148201ce09cf66fdf52a8f58e0 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001215897530.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001216274840.png b/en/device-dev/quick-start/figures/en-us_image_0000001216274840.png new file mode 100644 index 0000000000000000000000000000000000000000..c1816c41bceaeeca5385b6353ef94576db30d84a Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001216274840.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001216440138.png b/en/device-dev/quick-start/figures/en-us_image_0000001216440138.png new file mode 100644 index 0000000000000000000000000000000000000000..119b63f736e3146a4c29ef39b6ba3f9ee590e578 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001216440138.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001216516128.png b/en/device-dev/quick-start/figures/en-us_image_0000001216516128.png new file mode 100644 index 0000000000000000000000000000000000000000..c1816c41bceaeeca5385b6353ef94576db30d84a Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001216516128.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001216761476.png b/en/device-dev/quick-start/figures/en-us_image_0000001216761476.png new file mode 100644 index 0000000000000000000000000000000000000000..5d40e2fd4d1c8e51acfa232dff98bc0c7643f79f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001216761476.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001220852754.png b/en/device-dev/quick-start/figures/en-us_image_0000001220852754.png new file mode 100644 index 0000000000000000000000000000000000000000..c3013a3f9bd3951e53e1f0848c12700024c5f5e8 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001220852754.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221012766.png b/en/device-dev/quick-start/figures/en-us_image_0000001221012766.png new file mode 100644 index 0000000000000000000000000000000000000000..8d6c2de3aeeda000f6b0258f53de71e147ce5b27 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221012766.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221025048.png b/en/device-dev/quick-start/figures/en-us_image_0000001221025048.png new file mode 100644 index 0000000000000000000000000000000000000000..f17d2dd5dbc86b98a659218ed4a5e3a69409ae54 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221025048.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221036768.png b/en/device-dev/quick-start/figures/en-us_image_0000001221036768.png new file mode 100644 index 0000000000000000000000000000000000000000..369ec62f556fad6d1eee65d79c68cd1904dd9f43 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221036768.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221172710.png b/en/device-dev/quick-start/figures/en-us_image_0000001221172710.png new file mode 100644 index 0000000000000000000000000000000000000000..29b22463c375704734e6925861551aa27ec7b295 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221172710.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221344980.png b/en/device-dev/quick-start/figures/en-us_image_0000001221344980.png new file mode 100644 index 0000000000000000000000000000000000000000..7bf0acc41746926462ab3c352f143f90f2e65358 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221344980.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001221356692.png b/en/device-dev/quick-start/figures/en-us_image_0000001221356692.png new file mode 100644 index 0000000000000000000000000000000000000000..8f5ee977c68bce18bed83887191ddf870df7d8e9 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001221356692.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001222361042.png b/en/device-dev/quick-start/figures/en-us_image_0000001222361042.png new file mode 100644 index 0000000000000000000000000000000000000000..b9214e26adb933752fad2b983effb4cc655d2b84 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001222361042.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001223190441.png b/en/device-dev/quick-start/figures/en-us_image_0000001223190441.png new file mode 100644 index 0000000000000000000000000000000000000000..63d053122f3c7beaa990f63431ccb16692562535 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001223190441.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001224173270.png b/en/device-dev/quick-start/figures/en-us_image_0000001224173270.png new file mode 100644 index 0000000000000000000000000000000000000000..32669a1101e812fe29604d57a086ebc137dddf21 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001224173270.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001225760456.png b/en/device-dev/quick-start/figures/en-us_image_0000001225760456.png new file mode 100644 index 0000000000000000000000000000000000000000..9e249959cad7e68b535f8732b44e20db9f6db2fc Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001225760456.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226034634.png b/en/device-dev/quick-start/figures/en-us_image_0000001226034634.png new file mode 100644 index 0000000000000000000000000000000000000000..ae7a0816ce444713af16d9d7b89a06b9689410ce Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226034634.png differ diff --git a/en/device-dev/quick-start/figures/start-the-system.png b/en/device-dev/quick-start/figures/en-us_image_0000001226602238.png similarity index 100% rename from en/device-dev/quick-start/figures/start-the-system.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226602238.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226602250.png b/en/device-dev/quick-start/figures/en-us_image_0000001226602250.png new file mode 100644 index 0000000000000000000000000000000000000000..504da23ba456a9c377525e22c4630361286b5dd7 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226602250.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226602394.png b/en/device-dev/quick-start/figures/en-us_image_0000001226602394.png new file mode 100644 index 0000000000000000000000000000000000000000..8baa9c7c75625c18979d30ab52b2a0f64e0e8349 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226602394.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226602398.png b/en/device-dev/quick-start/figures/en-us_image_0000001226602398.png new file mode 100644 index 0000000000000000000000000000000000000000..f1aa2e319290cf3700a49391c3f078092a80821e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226602398.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226602406.jpg b/en/device-dev/quick-start/figures/en-us_image_0000001226602406.jpg new file mode 100644 index 0000000000000000000000000000000000000000..31c5a26705cd1da6cf9cb6f3bb356994e4ecc22e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226602406.jpg differ diff --git a/en/device-dev/quick-start/figures/11.png b/en/device-dev/quick-start/figures/en-us_image_0000001226602414.png similarity index 100% rename from en/device-dev/quick-start/figures/11.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226602414.png diff --git a/en/device-dev/quick-start/figures/wadrecvcb-function.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634668.png similarity index 100% rename from en/device-dev/quick-start/figures/wadrecvcb-function.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226634668.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226634676.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634676.png new file mode 100644 index 0000000000000000000000000000000000000000..8e5d4ef459d18833a50cd30e40e75f9e54bca5d0 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226634676.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226634692.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634692.png new file mode 100644 index 0000000000000000000000000000000000000000..870a320df8000f7416eb0b7c7447ea347f27adf1 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226634692.png differ diff --git a/en/device-dev/quick-start/figures/opening-the-deveco-serial-port.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634700.png similarity index 100% rename from en/device-dev/quick-start/figures/opening-the-deveco-serial-port.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226634700.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226634716.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634716.png new file mode 100644 index 0000000000000000000000000000000000000000..9e53432ce41e67ee3e93e96d78262a6ace41d383 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226634716.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226634728.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634728.png new file mode 100644 index 0000000000000000000000000000000000000000..0eee1bbff2e54816d6be05f7f3972a83f615884d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226634728.png differ diff --git a/en/device-dev/quick-start/figures/hi3516-network-and-firewall-setting.png b/en/device-dev/quick-start/figures/en-us_image_0000001226634732.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516-network-and-firewall-setting.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226634732.png diff --git a/en/device-dev/quick-start/figures/save-the-parameter-settings.png b/en/device-dev/quick-start/figures/en-us_image_0000001226762210.png similarity index 100% rename from en/device-dev/quick-start/figures/save-the-parameter-settings.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226762210.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226762222.jpg b/en/device-dev/quick-start/figures/en-us_image_0000001226762222.jpg new file mode 100644 index 0000000000000000000000000000000000000000..31c5a26705cd1da6cf9cb6f3bb356994e4ecc22e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226762222.jpg differ diff --git a/en/device-dev/quick-start/figures/open-the-serial-port-tool.png b/en/device-dev/quick-start/figures/en-us_image_0000001226762374.png similarity index 100% rename from en/device-dev/quick-start/figures/open-the-serial-port-tool.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226762374.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226762378.png b/en/device-dev/quick-start/figures/en-us_image_0000001226762378.png new file mode 100644 index 0000000000000000000000000000000000000000..5006140f00ec1195d04297cdeb26ad935fb9f0e5 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226762378.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226764302.png b/en/device-dev/quick-start/figures/en-us_image_0000001226764302.png new file mode 100644 index 0000000000000000000000000000000000000000..2867669fa29196d144506268bd3480863933afd5 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226764302.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226794644.png b/en/device-dev/quick-start/figures/en-us_image_0000001226794644.png new file mode 100644 index 0000000000000000000000000000000000000000..e674bafb0adaa4c0ff8efaf297ee52bab3165212 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226794644.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226794660.png b/en/device-dev/quick-start/figures/en-us_image_0000001226794660.png new file mode 100644 index 0000000000000000000000000000000000000000..5a60f341dac04501a0b937422688e588de0965fd Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226794660.png differ diff --git a/en/device-dev/quick-start/figures/hi3861-functions.png b/en/device-dev/quick-start/figures/en-us_image_0000001226794688.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3861-functions.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226794688.png diff --git a/en/device-dev/quick-start/figures/download-the-source-code.png b/en/device-dev/quick-start/figures/en-us_image_0000001226794696.png similarity index 100% rename from en/device-dev/quick-start/figures/download-the-source-code.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226794696.png diff --git a/en/device-dev/quick-start/figures/successful-resetting-of-the-wlan-module.png b/en/device-dev/quick-start/figures/en-us_image_0000001226794704.png similarity index 100% rename from en/device-dev/quick-start/figures/successful-resetting-of-the-wlan-module.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226794704.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226922154.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922154.png new file mode 100644 index 0000000000000000000000000000000000000000..f1aa2e319290cf3700a49391c3f078092a80821e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226922154.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226922302.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922302.png new file mode 100644 index 0000000000000000000000000000000000000000..7e136511b44f7b758ed4830ab20e58905a7cf241 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226922302.png differ diff --git a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-0.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922306.png similarity index 100% rename from en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-0.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226922306.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226922310.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922310.png new file mode 100644 index 0000000000000000000000000000000000000000..504da23ba456a9c377525e22c4630361286b5dd7 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226922310.png differ diff --git a/en/device-dev/quick-start/figures/hi3516d-v300-front-view-1.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922318.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516d-v300-front-view-1.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226922318.png diff --git a/en/device-dev/quick-start/figures/hi3518-reason-no-python-soft-link.png b/en/device-dev/quick-start/figures/en-us_image_0000001226922322.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3518-reason-no-python-soft-link.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226922322.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001226954644.png b/en/device-dev/quick-start/figures/en-us_image_0000001226954644.png new file mode 100644 index 0000000000000000000000000000000000000000..cfa0ceb21f5a11d459b93721f512309c9d6da2ac Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001226954644.png differ diff --git a/en/device-dev/quick-start/figures/successful-networking-of-the-wlan-module.png b/en/device-dev/quick-start/figures/en-us_image_0000001226954648.png similarity index 100% rename from en/device-dev/quick-start/figures/successful-networking-of-the-wlan-module.png rename to en/device-dev/quick-start/figures/en-us_image_0000001226954648.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227082162.png b/en/device-dev/quick-start/figures/en-us_image_0000001227082162.png new file mode 100644 index 0000000000000000000000000000000000000000..6d350e5d4db03fecc5c1b8055b01cdf73667ed36 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227082162.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227082182.png b/en/device-dev/quick-start/figures/en-us_image_0000001227082182.png new file mode 100644 index 0000000000000000000000000000000000000000..8f2852d937ea497b344d490494c0b937b728a64d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227082182.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227082334.png b/en/device-dev/quick-start/figures/en-us_image_0000001227082334.png new file mode 100644 index 0000000000000000000000000000000000000000..527fe8b9836daf35c8300e0e84bdb2ca390f85a5 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227082334.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227114584.png b/en/device-dev/quick-start/figures/en-us_image_0000001227114584.png new file mode 100644 index 0000000000000000000000000000000000000000..67e50038e79cf0f7c2a6bd79b48c63b7557179a4 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227114584.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227114612.png b/en/device-dev/quick-start/figures/en-us_image_0000001227114612.png new file mode 100644 index 0000000000000000000000000000000000000000..ebf4f8eba03720edddfb9ef8eb38bd5f71126f2a Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227114612.png differ diff --git a/en/device-dev/quick-start/figures/hi3518-solution-set-python-soft-link.png b/en/device-dev/quick-start/figures/en-us_image_0000001227114636.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3518-solution-set-python-soft-link.png rename to en/device-dev/quick-start/figures/en-us_image_0000001227114636.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227114640.png b/en/device-dev/quick-start/figures/en-us_image_0000001227114640.png new file mode 100644 index 0000000000000000000000000000000000000000..ff9105c313d5755f140920bbfc2399e3ccb5e2f5 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227114640.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227114644.png b/en/device-dev/quick-start/figures/en-us_image_0000001227114644.png new file mode 100644 index 0000000000000000000000000000000000000000..8c6ec0adb87f693519f0e3b00b3aa7053f3e23ae Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227114644.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227277128.png b/en/device-dev/quick-start/figures/en-us_image_0000001227277128.png new file mode 100644 index 0000000000000000000000000000000000000000..fd2a5588e6576449bcb9ec1f92a12649dcd6c5d0 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227277128.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227549226.png b/en/device-dev/quick-start/figures/en-us_image_0000001227549226.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227549226.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227711014.png b/en/device-dev/quick-start/figures/en-us_image_0000001227711014.png new file mode 100644 index 0000000000000000000000000000000000000000..7cc145edaa4ec883d4090febcf38fec14b35b46f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227711014.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227711882.png b/en/device-dev/quick-start/figures/en-us_image_0000001227711882.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227711882.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227712350.png b/en/device-dev/quick-start/figures/en-us_image_0000001227712350.png new file mode 100644 index 0000000000000000000000000000000000000000..0e1bebbb79fd4281b41173171d4a96fb0e84c166 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227712350.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001227757036.png b/en/device-dev/quick-start/figures/en-us_image_0000001227757036.png new file mode 100644 index 0000000000000000000000000000000000000000..c354bdb69c0293fd19cb71905f828fca1fe7d09c Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001227757036.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001237801283.png b/en/device-dev/quick-start/figures/en-us_image_0000001237801283.png new file mode 100644 index 0000000000000000000000000000000000000000..e9127be45474fa5d254a8444bc96d34ec8798108 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001237801283.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001238760373.png b/en/device-dev/quick-start/figures/en-us_image_0000001238760373.png new file mode 100644 index 0000000000000000000000000000000000000000..97111fcc9b48ba155466930d3dc00a6f45c13b8b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001238760373.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001238880335.png b/en/device-dev/quick-start/figures/en-us_image_0000001238880335.png new file mode 100644 index 0000000000000000000000000000000000000000..63a15bf3fbf9cd40422878607655443f6addc335 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001238880335.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239080359.png b/en/device-dev/quick-start/figures/en-us_image_0000001239080359.png new file mode 100644 index 0000000000000000000000000000000000000000..3160087388750499cbfcb6d12979fd9d7a33e410 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239080359.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239221905.png b/en/device-dev/quick-start/figures/en-us_image_0000001239221905.png new file mode 100644 index 0000000000000000000000000000000000000000..04a5b8220042d6025e1866c51796f75dd9cb55f1 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239221905.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239275843.png b/en/device-dev/quick-start/figures/en-us_image_0000001239275843.png new file mode 100644 index 0000000000000000000000000000000000000000..b9b0c15345138b5d784e027330b650e16b97ee4e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239275843.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239634067.png b/en/device-dev/quick-start/figures/en-us_image_0000001239634067.png new file mode 100644 index 0000000000000000000000000000000000000000..e6bc8d9c83c45f71ad7ea181903503a9c8d4eb3b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239634067.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239650137.png b/en/device-dev/quick-start/figures/en-us_image_0000001239650137.png new file mode 100644 index 0000000000000000000000000000000000000000..204894213329c4de1edf74d869c1bfd8e8e78d04 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239650137.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001239661509.png b/en/device-dev/quick-start/figures/en-us_image_0000001239661509.png new file mode 100644 index 0000000000000000000000000000000000000000..c3f10040538814eccbecf2ef37d472d59743e08f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001239661509.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001243290907.png b/en/device-dev/quick-start/figures/en-us_image_0000001243290907.png new file mode 100644 index 0000000000000000000000000000000000000000..764643ce134811551984284ed5ec6b60943f8ea4 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001243290907.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001243641075.png b/en/device-dev/quick-start/figures/en-us_image_0000001243641075.png new file mode 100644 index 0000000000000000000000000000000000000000..579d6e190d4824cb866f90f2f3e72c4493aa6f4c Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001243641075.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001243704061.png b/en/device-dev/quick-start/figures/en-us_image_0000001243704061.png new file mode 100644 index 0000000000000000000000000000000000000000..c93b7b610138e91c0b6b171cb515f540163e731b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001243704061.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001260519729.png b/en/device-dev/quick-start/figures/en-us_image_0000001260519729.png new file mode 100644 index 0000000000000000000000000000000000000000..b34a869072221246762fe4bf430b74a2e601792e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001260519729.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001260919759.png b/en/device-dev/quick-start/figures/en-us_image_0000001260919759.png new file mode 100644 index 0000000000000000000000000000000000000000..4faf554e6df1789b66a1fdc1017423497dbf5362 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001260919759.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001261315939.png b/en/device-dev/quick-start/figures/en-us_image_0000001261315939.png new file mode 100644 index 0000000000000000000000000000000000000000..1c6100e34e0d37e937742da452fe9ff6fbf9dab2 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001261315939.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001261395999.png b/en/device-dev/quick-start/figures/en-us_image_0000001261395999.png new file mode 100644 index 0000000000000000000000000000000000000000..349188d5e1a6e11772c88615dc00deffc8dd39b7 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001261395999.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001261515989.png b/en/device-dev/quick-start/figures/en-us_image_0000001261515989.png new file mode 100644 index 0000000000000000000000000000000000000000..aa41b99e1141cb361782dce26180fc118fd86442 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001261515989.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265492885.png b/en/device-dev/quick-start/figures/en-us_image_0000001265492885.png new file mode 100644 index 0000000000000000000000000000000000000000..7cc6ca102383151b5b67447332e73fc16c5ef85e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265492885.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265505181.png b/en/device-dev/quick-start/figures/en-us_image_0000001265505181.png new file mode 100644 index 0000000000000000000000000000000000000000..eff6401bb39152c2d02b7f17e557b1cd5dbb0e87 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265505181.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265516901.png b/en/device-dev/quick-start/figures/en-us_image_0000001265516901.png new file mode 100644 index 0000000000000000000000000000000000000000..93be7d7b91882bc5d372fe465a0d3a8b2972371f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265516901.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265652869.png b/en/device-dev/quick-start/figures/en-us_image_0000001265652869.png new file mode 100644 index 0000000000000000000000000000000000000000..4c1ce174731a8e20b62d119cbe1728e9a8394176 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265652869.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265665157.png b/en/device-dev/quick-start/figures/en-us_image_0000001265665157.png new file mode 100644 index 0000000000000000000000000000000000000000..0a574b8ee51edd1f4049e5ca6821a9347a45c2de Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265665157.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265676877.png b/en/device-dev/quick-start/figures/en-us_image_0000001265676877.png new file mode 100644 index 0000000000000000000000000000000000000000..a87d8c651147e1b7cb1f3d60513a6b3139540399 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265676877.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265772913.png b/en/device-dev/quick-start/figures/en-us_image_0000001265772913.png new file mode 100644 index 0000000000000000000000000000000000000000..659d732a4d044cfa4dacb84c5ec96bfc6b29707e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265772913.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265785209.png b/en/device-dev/quick-start/figures/en-us_image_0000001265785209.png new file mode 100644 index 0000000000000000000000000000000000000000..0e5a65d7765d8bc936ca9a2d7db12f3adeffd831 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265785209.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265945173.png b/en/device-dev/quick-start/figures/en-us_image_0000001265945173.png new file mode 100644 index 0000000000000000000000000000000000000000..f2447dd8f49268594e781e1c68751b209e01894c Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265945173.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001265956897.png b/en/device-dev/quick-start/figures/en-us_image_0000001265956897.png new file mode 100644 index 0000000000000000000000000000000000000000..671c269d4f497fe7bda04bb2e21d3ede4f474399 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001265956897.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001267231481.png b/en/device-dev/quick-start/figures/en-us_image_0000001267231481.png new file mode 100644 index 0000000000000000000000000000000000000000..f931e2cfba06791a3891248c5d8e6a9f0e86bf0e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001267231481.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001268653461.png b/en/device-dev/quick-start/figures/en-us_image_0000001268653461.png new file mode 100644 index 0000000000000000000000000000000000000000..90cf63342d2ebaf5ae348117f19f713247a5b554 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001268653461.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001270076961.png b/en/device-dev/quick-start/figures/en-us_image_0000001270076961.png new file mode 100644 index 0000000000000000000000000000000000000000..97d98319b294e132d43cd4f75a2cc8031995b99f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001270076961.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001270356233.png b/en/device-dev/quick-start/figures/en-us_image_0000001270356233.png new file mode 100644 index 0000000000000000000000000000000000000000..d45442dd53b2c38c44b91dede158abec7e1bf231 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001270356233.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271202289.gif b/en/device-dev/quick-start/figures/en-us_image_0000001271202289.gif new file mode 100644 index 0000000000000000000000000000000000000000..52b3511bd7ec50a86e9b348aecfb1704dae36188 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271202289.gif differ diff --git a/en/device-dev/quick-start/figures/hi3516-firewall-and-network-protection.png b/en/device-dev/quick-start/figures/en-us_image_0000001271202457.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516-firewall-and-network-protection.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271202457.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271202461.png b/en/device-dev/quick-start/figures/en-us_image_0000001271202461.png new file mode 100644 index 0000000000000000000000000000000000000000..0eee1bbff2e54816d6be05f7f3972a83f615884d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271202461.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271202465.png b/en/device-dev/quick-start/figures/en-us_image_0000001271202465.png new file mode 100644 index 0000000000000000000000000000000000000000..f1aa2e319290cf3700a49391c3f078092a80821e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271202465.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271202469.png b/en/device-dev/quick-start/figures/en-us_image_0000001271202469.png new file mode 100644 index 0000000000000000000000000000000000000000..0c1f60638087d0fe56127f2f842244355afad85f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271202469.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271202473.png b/en/device-dev/quick-start/figures/en-us_image_0000001271202473.png new file mode 100644 index 0000000000000000000000000000000000000000..cfa0ceb21f5a11d459b93721f512309c9d6da2ac Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271202473.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234705.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234705.png new file mode 100644 index 0000000000000000000000000000000000000000..bc935a8970e39629d2c93f6b92f96c5fa7d1a49b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234705.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234717.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234717.png new file mode 100644 index 0000000000000000000000000000000000000000..d5cc1dc9d10c2346630068c18dfc1bcbe6b54583 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234717.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234729.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234729.png new file mode 100644 index 0000000000000000000000000000000000000000..7de3c25e7ef2abc8d85d8bc945249f571f6bf0c3 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234729.png differ diff --git a/en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png b/en/device-dev/quick-start/figures/en-us_image_0000001271234749.png similarity index 100% rename from en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png rename to en/device-dev/quick-start/figures/en-us_image_0000001271234749.png diff --git a/en/device-dev/quick-start/figures/login-serial-port.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234753.png similarity index 100% rename from en/device-dev/quick-start/figures/login-serial-port.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271234753.png diff --git a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234757.png similarity index 100% rename from en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271234757.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234761.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234761.png new file mode 100644 index 0000000000000000000000000000000000000000..0c1f60638087d0fe56127f2f842244355afad85f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234761.png differ diff --git a/en/device-dev/quick-start/figures/hi3516-selecting-the-visual-studio-code-application.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234765.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516-selecting-the-visual-studio-code-application.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271234765.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234769.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234769.png new file mode 100644 index 0000000000000000000000000000000000000000..308f6c185e07f54a894f9d9c2eec95bb7639a516 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234769.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271234773.png b/en/device-dev/quick-start/figures/en-us_image_0000001271234773.png new file mode 100644 index 0000000000000000000000000000000000000000..e53a724993830b5d0e6e1e9871d99dfc99c55f11 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271234773.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271237241.png b/en/device-dev/quick-start/figures/en-us_image_0000001271237241.png new file mode 100644 index 0000000000000000000000000000000000000000..caa9309b7f069597073ffa593a7fbc6820b4b2e9 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271237241.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271322277.png b/en/device-dev/quick-start/figures/en-us_image_0000001271322277.png new file mode 100644 index 0000000000000000000000000000000000000000..f1aa2e319290cf3700a49391c3f078092a80821e Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271322277.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271322293.png b/en/device-dev/quick-start/figures/en-us_image_0000001271322293.png new file mode 100644 index 0000000000000000000000000000000000000000..fbc455e8f974deef17dad14b8e2e79f8ee2ac62b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271322293.png differ diff --git a/en/device-dev/quick-start/figures/setenv-bootargs.png b/en/device-dev/quick-start/figures/en-us_image_0000001271322437.png similarity index 100% rename from en/device-dev/quick-start/figures/setenv-bootargs.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271322437.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271354693.png b/en/device-dev/quick-start/figures/en-us_image_0000001271354693.png new file mode 100644 index 0000000000000000000000000000000000000000..02f74a108d5223682d57dc2e18aaefc3d31e6518 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271354693.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271354733.png b/en/device-dev/quick-start/figures/en-us_image_0000001271354733.png new file mode 100644 index 0000000000000000000000000000000000000000..a8037d1ebc95a3c9383d87678981b3ae5ccc8144 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271354733.png differ diff --git a/en/device-dev/quick-start/figures/reason-for-not-finding-python.png b/en/device-dev/quick-start/figures/en-us_image_0000001271354745.png similarity index 100% rename from en/device-dev/quick-start/figures/reason-for-not-finding-python.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271354745.png diff --git a/en/device-dev/quick-start/figures/hi3518-network-and-firewall-setting.png b/en/device-dev/quick-start/figures/en-us_image_0000001271354749.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3518-network-and-firewall-setting.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271354749.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271442261.png b/en/device-dev/quick-start/figures/en-us_image_0000001271442261.png new file mode 100644 index 0000000000000000000000000000000000000000..4e14740a2906da609abea693b77a2680fa7054a2 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271442261.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271442265.gif b/en/device-dev/quick-start/figures/en-us_image_0000001271442265.gif new file mode 100644 index 0000000000000000000000000000000000000000..52b3511bd7ec50a86e9b348aecfb1704dae36188 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271442265.gif differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271448821.png b/en/device-dev/quick-start/figures/en-us_image_0000001271448821.png new file mode 100644 index 0000000000000000000000000000000000000000..53cbcb8b0d0c30cb289b746d20b6c73927019d1a Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271448821.png differ diff --git a/en/device-dev/quick-start/figures/download-six.png b/en/device-dev/quick-start/figures/en-us_image_0000001271474573.png similarity index 100% rename from en/device-dev/quick-start/figures/download-six.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271474573.png diff --git a/en/device-dev/quick-start/figures/hi3516-allowing-the-visual-studio-code-application-to-access-the-network.png b/en/device-dev/quick-start/figures/en-us_image_0000001271474585.png similarity index 100% rename from en/device-dev/quick-start/figures/hi3516-allowing-the-visual-studio-code-application-to-access-the-network.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271474585.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271477045.png b/en/device-dev/quick-start/figures/en-us_image_0000001271477045.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271477045.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271532317.png b/en/device-dev/quick-start/figures/en-us_image_0000001271532317.png new file mode 100644 index 0000000000000000000000000000000000000000..ad87d810ad5c3ea136c05c8cb36096c3250ca91c Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271532317.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562257.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562257.png new file mode 100644 index 0000000000000000000000000000000000000000..60dbc4c0b3c082cff092d8c02081e062251af03b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562257.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562269.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562269.png new file mode 100644 index 0000000000000000000000000000000000000000..802cce4e760102043f177cb2fa71e8bd16539ba1 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562269.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562277.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562277.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562277.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562433.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562433.png new file mode 100644 index 0000000000000000000000000000000000000000..e828c808f0fae09773a8408647a9e5386e4d6c21 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562433.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562437.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562437.png new file mode 100644 index 0000000000000000000000000000000000000000..47231369bbeb827e70a8720b7a3d03ac58fad0c3 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562437.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271562449.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562449.png new file mode 100644 index 0000000000000000000000000000000000000000..208a4fbace342514f59f0000c4d50f5dc9321f0f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271562449.png differ diff --git a/en/device-dev/quick-start/figures/solution-add-soft-link.png b/en/device-dev/quick-start/figures/en-us_image_0000001271562453.png similarity index 100% rename from en/device-dev/quick-start/figures/solution-add-soft-link.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271562453.png diff --git a/en/device-dev/quick-start/figures/reboot_success.png b/en/device-dev/quick-start/figures/en-us_image_0000001271594709.png similarity index 100% rename from en/device-dev/quick-start/figures/reboot_success.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271594709.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271594733.png b/en/device-dev/quick-start/figures/en-us_image_0000001271594733.png new file mode 100644 index 0000000000000000000000000000000000000000..9d3bdbfe1eac9dc532496a7785e8caf99c41780b Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271594733.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271594749.png b/en/device-dev/quick-start/figures/en-us_image_0000001271594749.png new file mode 100644 index 0000000000000000000000000000000000000000..edb1711f3c1fa906940d8cbb8d8fcdeb2badd2b6 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271594749.png differ diff --git a/en/device-dev/quick-start/figures/download-ecdsa.png b/en/device-dev/quick-start/figures/en-us_image_0000001271594753.png similarity index 100% rename from en/device-dev/quick-start/figures/download-ecdsa.png rename to en/device-dev/quick-start/figures/en-us_image_0000001271594753.png diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271594765.png b/en/device-dev/quick-start/figures/en-us_image_0000001271594765.png new file mode 100644 index 0000000000000000000000000000000000000000..208a4fbace342514f59f0000c4d50f5dc9321f0f Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271594765.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271791385.png b/en/device-dev/quick-start/figures/en-us_image_0000001271791385.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271791385.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001271912277.png b/en/device-dev/quick-start/figures/en-us_image_0000001271912277.png new file mode 100644 index 0000000000000000000000000000000000000000..53cbcb8b0d0c30cb289b746d20b6c73927019d1a Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001271912277.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001272032361.png b/en/device-dev/quick-start/figures/en-us_image_0000001272032361.png new file mode 100644 index 0000000000000000000000000000000000000000..c55a6ddd1aa319adfa05987ff3f5c79231e7208d Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001272032361.png differ diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001272109325.png b/en/device-dev/quick-start/figures/en-us_image_0000001272109325.png new file mode 100644 index 0000000000000000000000000000000000000000..caa9309b7f069597073ffa593a7fbc6820b4b2e9 Binary files /dev/null and b/en/device-dev/quick-start/figures/en-us_image_0000001272109325.png differ diff --git a/en/device-dev/quick-start/figures/erase-u-boot.png b/en/device-dev/quick-start/figures/erase-u-boot.png deleted file mode 100644 index 7d6dc91c5762822a67a439fe9cf26c8650c4a469..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/erase-u-boot.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png b/en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png deleted file mode 100644 index 25308b9cab52a166955e70ada35c3191d90dd64c..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png b/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png deleted file mode 100644 index 216265660cd0364189cd438da8b7e2600a7a5099..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-logo.png b/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-logo.png deleted file mode 100644 index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-logo.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png deleted file mode 100644 index 937a17d71744d81d509543594b094939e8a89070..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-deveco-device-tool-setting.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-hardware-connections.png b/en/device-dev/quick-start/figures/hi3516-hardware-connections.png deleted file mode 100644 index fcc5050822e05cfb73bd887aa61cd7d4a60ac5ad..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-hardware-connections.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-record-the-serial-port-number.png b/en/device-dev/quick-start/figures/hi3516-record-the-serial-port-number.png deleted file mode 100644 index 09f33e3992c0c1d78713eea949e4b9a19f5802ec..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-record-the-serial-port-number.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-restart-the-development-board.png b/en/device-dev/quick-start/figures/hi3516-restart-the-development-board.png deleted file mode 100644 index 281958fe76a787acc5d0b98f5ea248fa5abf2405..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-restart-the-development-board.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-settings.png b/en/device-dev/quick-start/figures/hi3516-settings.png deleted file mode 100644 index 11b1a4e59f83b7ee80b38bf25b0790a830c4ab92..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-settings.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-upload-options.png b/en/device-dev/quick-start/figures/hi3516-upload-options.png deleted file mode 100644 index 7d9768119778aeee7d0b927879c0da2bcdc4821a..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-upload-options.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png b/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png deleted file mode 100644 index fb2db198cc61ed10136f0e3382deed352300a62b..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516-upload-start-burning.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3516d-v300-front-view.png b/en/device-dev/quick-start/figures/hi3516d-v300-front-view.png deleted file mode 100644 index 104d678519e65bbbc8ce84fbceb53210d826ba6d..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3516d-v300-front-view.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-allowing-the-visual-studio-code-application-to-access-the-network.png b/en/device-dev/quick-start/figures/hi3518-allowing-the-visual-studio-code-application-to-access-the-network.png deleted file mode 100644 index 13d77ce93c78ac07039c8f09741db1db1d05a124..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-allowing-the-visual-studio-code-application-to-access-the-network.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-bootloader.png b/en/device-dev/quick-start/figures/hi3518-bootloader.png deleted file mode 100644 index 2d67376af75fa7693ed16299de75255c08178c14..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-bootloader.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-burning-succeeded.png b/en/device-dev/quick-start/figures/hi3518-burning-succeeded.png deleted file mode 100644 index 42b7ef6678b4415c855cd93ddff6936a807b42b8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-burning-succeeded.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png deleted file mode 100644 index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-logo.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png deleted file mode 100644 index a7cdfed371fa65d05faec7651d89145ad5a24a96..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-deveco-device-tool-setting.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-error-for-not-finding-python.png b/en/device-dev/quick-start/figures/hi3518-error-for-not-finding-python.png deleted file mode 100644 index 1b002b247b704150040e90ecb149d782ba8db3a8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-error-for-not-finding-python.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-firewall-and-network-protection.png b/en/device-dev/quick-start/figures/hi3518-firewall-and-network-protection.png deleted file mode 100644 index 82faf7d05d2a40e9deae2649a1f59fccea67bdc2..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-firewall-and-network-protection.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-hardware-connections.png b/en/device-dev/quick-start/figures/hi3518-hardware-connections.png deleted file mode 100644 index b5dfc506b818515555959aa29a297185d816ff0b..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-hardware-connections.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-monitor.png b/en/device-dev/quick-start/figures/hi3518-monitor.png deleted file mode 100644 index d287df0c64ca5e2ffc27aa1acd820cdf0e6b40c6..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-monitor.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-record-the-serial-port-number.png b/en/device-dev/quick-start/figures/hi3518-record-the-serial-port-number.png deleted file mode 100644 index 09f33e3992c0c1d78713eea949e4b9a19f5802ec..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-record-the-serial-port-number.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-reset-success.png b/en/device-dev/quick-start/figures/hi3518-reset-success.png deleted file mode 100644 index 8e3d4e7d2a36e2b880f592ec88b01b6c4bef07cc..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-reset-success.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-restart-the-development-board.png b/en/device-dev/quick-start/figures/hi3518-restart-the-development-board.png deleted file mode 100644 index a277db68618d87bb7f95565eb890760405d654e2..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-restart-the-development-board.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-selecting-the-visual-studio-code-application.png b/en/device-dev/quick-start/figures/hi3518-selecting-the-visual-studio-code-application.png deleted file mode 100644 index 81812f492838b439ea507d4afb763ff751c0a467..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-selecting-the-visual-studio-code-application.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-settings.png b/en/device-dev/quick-start/figures/hi3518-settings.png deleted file mode 100644 index be9e1743f8664bd064e3b0c556f31ca5cc963464..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-settings.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518-upload.png b/en/device-dev/quick-start/figures/hi3518-upload.png deleted file mode 100644 index 7bd316dfd5a64c873682bf865a79ec1f2354cc40..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518-upload.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518e-v300-front-view.png b/en/device-dev/quick-start/figures/hi3518e-v300-front-view.png deleted file mode 100644 index 0aab3ea83b2e7ab17f9d67cfe9aea6f5b226183d..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518e-v300-front-view.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3518e-v300-rear-view.png b/en/device-dev/quick-start/figures/hi3518e-v300-rear-view.png deleted file mode 100644 index 861e468e6a6275c14bc37c14d5d1d447aabc041a..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3518e-v300-rear-view.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-burning-succeeded.png b/en/device-dev/quick-start/figures/hi3861-burning-succeeded.png deleted file mode 100644 index 3628f3f4778012a577d4ee28c703669eb5533594..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-burning-succeeded.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png b/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png deleted file mode 100644 index 512ee4ff2e053da12259a2f9d3163df75cb41a52..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-deveco-device-tool-setting.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-hardware-connections.png b/en/device-dev/quick-start/figures/hi3861-hardware-connections.png deleted file mode 100644 index 22717eff5b2344229a230d2d4fb1aa7f0dd489bb..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-hardware-connections.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-record-the-serial-port-number.png b/en/device-dev/quick-start/figures/hi3861-record-the-serial-port-number.png deleted file mode 100644 index 43496f076a463ec6fbf320b358a32505284ff40f..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-record-the-serial-port-number.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-restart-the-development-board.png b/en/device-dev/quick-start/figures/hi3861-restart-the-development-board.png deleted file mode 100644 index e6b632288105421a07bd4f8d542293deb0d35fd2..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-restart-the-development-board.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hi3861-upload.png b/en/device-dev/quick-start/figures/hi3861-upload.png deleted file mode 100644 index 8dde7632636856203030c2abf0867f03abaafcba..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hi3861-upload.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/hisilicon-arm-linux.png b/en/device-dev/quick-start/figures/hisilicon-arm-linux.png deleted file mode 100644 index 114a8e1c31ab1a58ece6b0d1e00d673256b42b2b..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/hisilicon-arm-linux.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/ip-address-information-3.png b/en/device-dev/quick-start/figures/ip-address-information-3.png deleted file mode 100644 index 72dd05e3ae1eb91156df98cb1915b6264b3bbe5a..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/ip-address-information-3.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/ip-address-information.png b/en/device-dev/quick-start/figures/ip-address-information.png deleted file mode 100644 index 72dd05e3ae1eb91156df98cb1915b6264b3bbe5a..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/ip-address-information.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/options.png b/en/device-dev/quick-start/figures/options.png deleted file mode 100644 index 0bf756d8a9fea4865c8b65b7dadc4463e2346ab7..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/options.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/press-any-key-to-enter-the-system.gif b/en/device-dev/quick-start/figures/press-any-key-to-enter-the-system.gif deleted file mode 100644 index 5e0e2bec9e8ce82561047fe7d5f000e0d2c4f962..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/press-any-key-to-enter-the-system.gif and /dev/null differ diff --git a/en/device-dev/quick-start/figures/reason-no-python-soft-link.png b/en/device-dev/quick-start/figures/reason-no-python-soft-link.png deleted file mode 100644 index b6bc36af5339ea5a4f67640e69836965b3776e17..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/reason-no-python-soft-link.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/running-commands-on-the-terminal-panel.png b/en/device-dev/quick-start/figures/running-commands-on-the-terminal-panel.png deleted file mode 100644 index 3f5fa2829949e59d498da9dd5ff1f48fa0647cf1..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/running-commands-on-the-terminal-panel.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/selecting-the-target-build-version.png b/en/device-dev/quick-start/figures/selecting-the-target-build-version.png deleted file mode 100644 index 91f3fa22153f501e308fab46f92f2e95995f1917..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/selecting-the-target-build-version.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/serial-port-connection.png b/en/device-dev/quick-start/figures/serial-port-connection.png deleted file mode 100644 index 063a5ff561d4a29f48744c3133724eb6b45e8a47..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/serial-port-connection.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png b/en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png deleted file mode 100644 index ad4fd618860ca9f79e9bdc39436c3b2f9cdb72de..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/serial-port-entry.png b/en/device-dev/quick-start/figures/serial-port-entry.png deleted file mode 100644 index 43496f076a463ec6fbf320b358a32505284ff40f..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/serial-port-entry.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/snap28.png b/en/device-dev/quick-start/figures/snap28.png deleted file mode 100644 index 2dcc6878e24dc6aa415fcbea24a8c4878aad5242..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/snap28.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/snap33.png b/en/device-dev/quick-start/figures/snap33.png deleted file mode 100644 index e0dc22d338e23ca54b973597bf9f94ae4fd08a42..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/snap33.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/snap34.png b/en/device-dev/quick-start/figures/snap34.png deleted file mode 100644 index a0c66f66fa6e77e545cc6ac3db2d6cf10f646387..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/snap34.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/snap8.png b/en/device-dev/quick-start/figures/snap8.png deleted file mode 100644 index 157f5e2d0f5b33f998560f7e85efb49d6786786c..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/snap8.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/solution.png b/en/device-dev/quick-start/figures/solution.png deleted file mode 100644 index 9284df45bb1415d84f0325df85b4eb5c223281e8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/solution.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/starting-the-ide-terminal-tool.png b/en/device-dev/quick-start/figures/starting-the-ide-terminal-tool.png deleted file mode 100644 index 791dfeae272070b7e285ea3070ebd3b1e9100eb5..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/starting-the-ide-terminal-tool.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/successful-building.png b/en/device-dev/quick-start/figures/successful-building.png deleted file mode 100644 index f3a76a6922315fe595ae4214331ce322766b3b48..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/successful-building.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png b/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png deleted file mode 100644 index 6a85551cd30c8c0576c138d86dc66ddf73dccb44..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/symptom-for-not-finding-python.png b/en/device-dev/quick-start/figures/symptom-for-not-finding-python.png deleted file mode 100644 index 1b002b247b704150040e90ecb149d782ba8db3a8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/symptom-for-not-finding-python.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/system-startup.png b/en/device-dev/quick-start/figures/system-startup.png deleted file mode 100644 index 105e9a83292ff333cafb813ecd6647dd256a9443..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/system-startup.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/terminal-list.png b/en/device-dev/quick-start/figures/terminal-list.png deleted file mode 100644 index a680547b305cccb4d8ea6cae3cbf2d046b841ff8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/terminal-list.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/terminal-panel.png b/en/device-dev/quick-start/figures/terminal-panel.png deleted file mode 100644 index 360114c797c42340cdeadcb566a7d90651cd12de..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/terminal-panel.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/u-boot-erased-successfully.png b/en/device-dev/quick-start/figures/u-boot-erased-successfully.png deleted file mode 100644 index 7a35899cc5cebff68372d97bb76906b6e90b3ba7..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/u-boot-erased-successfully.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/upload-options-2.png b/en/device-dev/quick-start/figures/upload-options-2.png deleted file mode 100644 index bfb378217e99536cf076deecfb0f0677cb51eef8..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/upload-options-2.png and /dev/null differ diff --git a/en/device-dev/quick-start/figures/upload-options.png b/en/device-dev/quick-start/figures/upload-options.png deleted file mode 100644 index 0b0d0cf88b9a78e6beea45e74b7633fa8c3ce523..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figures/upload-options.png and /dev/null differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-caution.gif b/en/device-dev/quick-start/public_sys-resources/icon-caution.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-caution.gif differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-danger.gif b/en/device-dev/quick-start/public_sys-resources/icon-danger.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-danger.gif differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-note.gif b/en/device-dev/quick-start/public_sys-resources/icon-note.gif new file mode 100644 index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-note.gif differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-notice.gif b/en/device-dev/quick-start/public_sys-resources/icon-notice.gif new file mode 100644 index 0000000000000000000000000000000000000000..86024f61b691400bea99e5b1f506d9d9aef36e27 Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-notice.gif differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-tip.gif b/en/device-dev/quick-start/public_sys-resources/icon-tip.gif new file mode 100644 index 0000000000000000000000000000000000000000..93aa72053b510e456b149f36a0972703ea9999b7 Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-tip.gif differ diff --git a/en/device-dev/quick-start/public_sys-resources/icon-warning.gif b/en/device-dev/quick-start/public_sys-resources/icon-warning.gif new file mode 100644 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/en/device-dev/quick-start/public_sys-resources/icon-warning.gif differ diff --git a/en/device-dev/quick-start/quickstart-docker-lite.md b/en/device-dev/quick-start/quickstart-docker-lite.md new file mode 100644 index 0000000000000000000000000000000000000000..b0dedbd30e13ea886381add1820506fdf9e0d2d3 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-docker-lite.md @@ -0,0 +1,13 @@ +# Getting Started with Mini and Small Systems (Installation Package Mode) + + + +- **[Mini and Small System Overview](quickstart-lite-overview.md)** + +- **[Environment Preparation](quickstart-lite-env-setup.md)** + +- **[Running a Hello World Program](quickstart-lite-steps.md)** + +- **[FAQs](quickstart-lite-env-setup-faqs.md)** + +- **[Appendix](quickstart-lite-appendix.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-appendix.md b/en/device-dev/quick-start/quickstart-ide-lite-appendix.md new file mode 100644 index 0000000000000000000000000000000000000000..0f1cbeb874d3e95c5e15881892b3c09bd1e9facc --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-appendix.md @@ -0,0 +1,5 @@ +# Appendix + + + +- **[Introduction to Development Boards](quickstart-ide-lite-board-introduction.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-board-introduction.md b/en/device-dev/quick-start/quickstart-ide-lite-board-introduction.md new file mode 100644 index 0000000000000000000000000000000000000000..9ebaa5683f1a0102675883058586145478e04f1e --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-board-introduction.md @@ -0,0 +1,7 @@ +# Introduction to Development Boards + + + +- **[Introduction to the Hi3861 Development Board](quickstart-ide-lite-introduction-hi3861.md)** + +- **[Introduction to the Hi3516 Development Board](quickstart-ide-lite-introduction-hi3516.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-create-project.md b/en/device-dev/quick-start/quickstart-ide-lite-create-project.md new file mode 100644 index 0000000000000000000000000000000000000000..9227e669b4d34ca5453d2e392a3bc64604e055f5 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-create-project.md @@ -0,0 +1,35 @@ +# Creating a Source Code Project + + +After [setting up the Windows+Ubuntu hybrid development environment](../quick-start/quickstart-ide-lite-env-setup-win-ubuntu.md) and [obtaining source code](../quick-start/quickstart-ide-lite-sourcecode-acquire.md), perform the following steps to create a source code project in Windows: + + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the source code directory to be imported and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001271477045](figures/en-us_image_0000001271477045.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. The following figure uses **wifiiot_hispark_pegasus** as an example. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - Set **Product** to **wifiiot_hispark_pegasus** for the Hi3861 development board. + > + > - Set **Product** to **ipcamera_hispark_taurus** for the Hi3516D V300 development board. + + ![en-us_image_0000001271237241](figures/en-us_image_0000001271237241.png) + +6. Click **Open** to open the project or source code. diff --git a/en/device-dev/quick-start/quickstart-ide-lite-env-setup-win-ubuntu.md b/en/device-dev/quick-start/quickstart-ide-lite-env-setup-win-ubuntu.md new file mode 100644 index 0000000000000000000000000000000000000000..8c482fb6e0fe688c52e6dcca1dfeda2ed9a53380 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-env-setup-win-ubuntu.md @@ -0,0 +1,204 @@ +# Setting Up the Windows+Ubuntu Hybrid Development Environment + + +In embedded development, Windows-based tools, such as Visual Studio Code, are widely used in code editing. Yet, as the source code of most development boards, such as Hi3861 and Hi3516, cannot be built in Windows, these development boards require the Ubuntu build environment. + + +In the Windows+Ubuntu hybrid build environment, you can enjoy the benefits of both DevEco Device Tool for Windows and DevEco Device Tool for Ubuntu (where Visual Studio Code is optional). + + +## System Requirements + +- Windows: Windows 10 (64-bit) + +- Ubuntu: Ubuntu 20.04 or later; recommended memory: 16 GB or higher. + +- User name: cannot contain Chinese characters + +- DevEco Device Tool: 3.0 Release + + +## Setting Up the Ubuntu Build Environment + +The setup procedure varies, depending on whether you need a GUI. If you need a GUI, you need to install Visual Studio Code. In this case, follow the instructions in [Setting Up the Ubuntu Development Environment](https://device.harmonyos.com/en/docs/documentation/guide/ide-install-ubuntu-0000001072959308). If you do not need a GUI, perform the steps below: + +1. Make sure the Ubuntu shell environment is **bash**. + 1. Run the following command and check whether the command output is **bash**. If the command output is not **bash**, go to step 2. + + ``` + ls -l /bin/sh + ``` + + ![en-us_image_0000001226764302](figures/en-us_image_0000001226764302.png) + + 2. Start the command-line tool, run the following command, enter your password, and select **No** to set **Ubuntu shell** to **bash**. + + ``` + sudo dpkg-reconfigure dash + ``` + + ![en-us_image_0000001243641075](figures/en-us_image_0000001243641075.png) + +2. Download the [DevEco Device Tool 3.0 Release Linux version](https://device.harmonyos.com/cn/ide#download). + +3. Decompress the DevEco Device Tool software package and assign permission on the folder obtained from the decompression. + + 1. Go to the directory where the DevEco Device Tool software package is stored and run the following command to decompress the software package. In the command, change **devicetool-linux-tool-3.0.0.400.zip** to the actual software package name. + + ``` + unzip devicetool-linux-tool-3.0.0.400.zip + ``` + + 2. Open the folder of the decompressed software package and run the following command to grant the execute permission on the installation file. In the command, change **devicetool-linux-tool-3.0.0.400.sh** to the actual installation file name. + + ``` + chmod u+x devicetool-linux-tool-3.0.0.400.sh + ``` + +4. Run the following command to install DevEco Device Tool, where **devicetool-linux-tool-3.0.0.400.sh** indicates the installation file name. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > During the installation, the setup wizard automatically checks whether Python 3.8 or 3.9 is installed. If Python 3.8 or 3.9 is not installed, the setup wizard displays the "Do you want to continue?" message; enter **Y** to allow the setup wizard to automatically install Python. + + + ``` + sudo ./devicetool-linux-tool-3.0.0.400.sh + ``` + + Wait until the "Deveco Device Tool successfully installed." message is displayed. + + ![en-us_image_0000001198722374](figures/en-us_image_0000001198722374.png) + + +## Setting Up Windows Development Environment + +To remotely access the Ubuntu environment through Windows and enjoy the benefits of DevEco Device Tool for Windows, you need to install DevEco Device Tool on Windows. + +1. Download the [DevEco Device Tool 3.0 Release](https://device.harmonyos.com/cn/ide#download) Windows edition. + +2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**. + +3. Set the installation path of DevEco Device Tool and click **Next**. You are advised to install DevEco Device Tool in a non-system drive. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If you have installed DevEco Device Tool 3.0 Beta2 or earlier, the earlier version will be uninstalled before you install a new version. If the following error message is displayed during the uninstallation, click **Ignore** to continue the installation. This error does not affect the installation of the new version. + > + > ![en-us_image_0000001239275843](figures/en-us_image_0000001239275843.png) + + ![en-us_image_0000001270076961](figures/en-us_image_0000001270076961.png) + +4. When prompted, select the tools to be automatically installed. + + 1. On the **VSCode installation confirm** page, select **Install VScode 1.62.2 automatically** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Visual Studio Code 1.62 or later has been installed, this step will be skipped. + + ![en-us_image_0000001237801283](figures/en-us_image_0000001237801283.png) + + 2. On the displayed **Python select page**, select **Download from Huawei mirror** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Python 3.8 or 3.9 has been installed, select **Use one of compatible on your PC**. + + ![en-us_image_0000001193983334](figures/en-us_image_0000001193983334.png) + +5. In the dialog box shown below, click **Next** to download and install the tools.. + + ![en-us_image_0000001239634067](figures/en-us_image_0000001239634067.png) + +6. Wait for the DevEco Device Tool setup wizard to automatically install DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard. + + ![en-us_image_0000001239650137](figures/en-us_image_0000001239650137.png) + +7. From Visual Studio Code, access the DevEco Device Tool page. Now you can conduct your development in DevEco Device Tool. + + ![en-us_image_0000001225760456](figures/en-us_image_0000001225760456.png) + + +## Configuring Windows to Remotely Access the Ubuntu Build Environment + + +### Installing the SSH Service and Obtaining the IP Address for Remote Access + +1. In Ubuntu, open the Terminal tool and run the following command to install the SSH service: + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the command fails to be executed and the system displays a message indicating that the openssh-server and openssh-client depend on different versions, install the openssh-client of the required version (for example, **sudo apt-get install openssh-client=1:8.2p1-4**) as prompted on the command-line interface (CLI) and run the command again to install the openssh-server. + + + ``` + sudo apt-get install openssh-server + ``` + +2. Run the following command to start the SSH service: + + ``` + sudo systemctl start ssh + ``` + +3. Run the following command to obtain the IP address of the current user for remote access to the Ubuntu environment from Windows: + + ``` + ifconfig + ``` + + ![en-us_image_0000001215737140](figures/en-us_image_0000001215737140.png) + + +### Installing Remote SSH + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001239080359](figures/en-us-cn_image_0000001239080359.png), and search for **remote-ssh** in the Extension Marketplace. + + ![en-us_image_0000001193920448](figures/en-us_image_0000001193920448.png) + +2. Click **Install** to install Remote-SSH. After the installation is successful, **Remote-SSH** is displayed on the **INSTALLED** list. + + ![en-us_image_0000001238880335](figures/en-us_image_0000001238880335.png) + + +### Remotely Connecting to the Ubuntu Environment + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001238760373](figures/en-us_image_0000001238760373.png), and click + on the **REMOTE EXOPLORER** page. + + ![en-us_image_0000001215878922](figures/en-us_image_0000001215878922.png) + +2. In the **Enter SSH Connection Command** text box, enter **ssh *username@ip_address***, where *ip_address* indicates the IP address of the remote computer to be connected and *username* indicates the account name used for logging in to the remote computer. + + ![en-us_image_0000001215879750](figures/en-us_image_0000001215879750.png) + +3. In the displayed dialog box, select the default first option as the SSH configuration file. + + ![en-us_image_0000001260519729](figures/en-us_image_0000001260519729.png) + +4. Under **SSH TARGETS**, find the remote computer and click ![en-us_image_0000001194080414](figures/en-us_image_0000001194080414.png) to start it. + + ![en-us_image_0000001215720398](figures/en-us_image_0000001215720398.png) + +5. In the displayed dialog box, select **Linux**, select **Continue**, and enter the password for logging in to the remote computer. + + ![en-us_image_0000001215897530](figures/en-us_image_0000001215897530.png) + + After the connection is successful, the plug-in is automatically installed in the .vscode-server folder on the remote computer. After the installation is complete, reload Visual Studio Code in Windows as prompted. Then you can develop, compile, and burn source code in DevEco Device Tool on Windows. + + +### Registering the Public Key for Accessing the Ubuntu Environment + +After the preceding operations are complete, you can remotely connect to the Ubuntu environment through Windows for development. However, you need to frequently enter the remote connection password. To eliminate this need, you can use the SSH public key. + +1. Open the Git bash CLI and run the following command to generate an SSH public key. During command execution, perform operations as prompted. Set **username** and **ip** to the user name and IP address you use for connecting to the Ubuntu system. + + ``` + ssh-keygen -t rsa + ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip + ``` + + ![en-us_image_0000001271532317](figures/en-us_image_0000001271532317.png) + +2. In Visual Studio Code, click the remote connection setting button and open the **config** file. + + ![en-us_image_0000001226034634](figures/en-us_image_0000001226034634.png) + +3. In the **config** file, add the SSK key file information, as shown below. Then save the file. + + ![en-us_image_0000001270356233](figures/en-us_image_0000001270356233.png) diff --git a/en/device-dev/quick-start/quickstart-ide-lite-env-setup.md b/en/device-dev/quick-start/quickstart-ide-lite-env-setup.md new file mode 100644 index 0000000000000000000000000000000000000000..a3722cf56712286e6bd5776e74b88470306f3261 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-env-setup.md @@ -0,0 +1,7 @@ +# Environment Preparation + + + +- **[Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-lite-env-setup-win-ubuntu.md)** + +- **[Obtaining Source Code](quickstart-ide-lite-sourcecode-acquire.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3516.md b/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..4c85bdc37bd008627762569ba55a7bf7275ecaf8 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3516.md @@ -0,0 +1,20 @@ +# Introduction to the Hi3516 Development Board + + +## Introduction + +Hi3516D V300 is a next-generation system on chip (SoC) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor (ISP), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. + + **Figure 1** Hi3516 front view + +![en-us_image_0000001271234717](figures/en-us_image_0000001271234717.png) + + +## Development Board Specifications + + **Table 1** Hi3516 specifications + +| Item| Description| +| -------- | -------- | +| Processor and internal memory| - Hi3516D V300 chip
- DDR3 1GB
- eMMC 4.5, 8 GB capacity| +| External components| - Ethernet port
- Audio and video
  - 1 voice input
  - 1 mono channel (AC_L) output, connected to a 3 W power amplifier (LM4871)
  - MicroHDMI (1-channel HDMI 1.4)
- Camera
  - Sensor IMX335
  - M12 lens, 4 mm focal length, and 1.8 aperture
- Display
  - LCD connector (2.35-inch)
  - LCD connector (5.5-inch)
- External components and ports
  - Memory card port
  - JTAG/I2S port
  - ADC port
  - Steering gear port
  - Grove connector
  - USB 2.0 (Type-C)
  - Three function keys, two user-defined keys, and one upgrade key
  - LED indicator, green or red| diff --git a/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3861.md b/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3861.md new file mode 100644 index 0000000000000000000000000000000000000000..fa6235602d1b4e080b703ff85a6651cc3bd19105 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-introduction-hi3861.md @@ -0,0 +1,68 @@ +# Introduction to the Hi3861 Development Board + + +## Introduction + +Hi3861 is a 2 x 5 cm development board. It is a 2.4 GHz WLAN SoC chip that highly integrates the IEEE 802.11b/g/n baseband and radio frequency (RF) circuit. It supports OpenHarmony and provides an open and easy-to-use development and debugging environment. + + **Figure 1** Hi3861 development board + + ![en-us_image_0000001226634692](figures/en-us_image_0000001226634692.png) + +The Hi3861 development board can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board. + + **Figure 2** Hi3861 mother board + +![en-us_image_0000001226794660](figures/en-us_image_0000001226794660.png) + +- The RF circuit includes modules such as the power amplifier (PA), low noise amplifier (LNA), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer. + +- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing (OFDM) technology and is backward compatible with the direct sequence spread spectrum (DSSS) and complementary code keying (CCK) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol. + +- The Hi3861 chip integrates the high-performance 32-bit microprocessor, hardware security engine, and various peripheral interfaces. The peripheral interfaces include the Synchronous Peripheral Interface (SPI), Universal Asynchronous Receiver & Transmitter (UART), the Inter-Integrated Circuit (I2C), Pulse Width Modulation (PWM), General Purpose Input/Output (GPIO) interface, and Analog to Digital Converter (ADC). The Hi3861 chip also supports the high-speed Secure Digital Input/Output (SDIO) 2.0 interface, with a maximum clock frequency of 50 MHz. This chip has a built-in static random access memory (SRAM) and flash memory, so that programs can run independently or run from a flash drive. + +- The Hi3861 chip applies to Internet of Things (IoT) devices such as smart home appliances. + + **Figure 3** Functional block diagram of Hi3861 + + ![en-us_image_0000001271234729](figures/en-us_image_0000001271234729.png) + + +## Resources and Constraints + +The resources of the Hi3861 development board are limited. The entire board has a 2 MB flash memory and 352 KB RAM. When writing service code, pay attention to the resource usage efficiency. + + +## Development Board Specifications + + **Table 1** Hi3861 specifications + +| Item| Description| +| -------- | -------- | +| General specifications| - 1 x 1 2.4 GHz frequency band (ch1–ch14)
- PHY supports IEEE 802.11b/g/n.
- MAC supports IEEE802.11d/e/h/i/k/v/w.
- Built-in PA and LNA; integrated TX/RX switch and Balun
- Support for STA and AP modes. When functioning as an AP, it supports a maximum of 6 STAs.
- Support for WFA WPA/WPA2 personal and WPS2.0.
- 2/3/4-line PTA solution that coexists with BT/BLE chips.
- Input voltage range: 2.3 V to 3.6 V
- I/O power voltage: 1.8 V or 3.3 V.
- RF self-calibration
- Low power consumption:
  - Ultra Deep Sleep mode: 5 μA@3.3 V
  - DTIM1: 1.5 mA \@3.3V
  - DTIM3: 0.8 mA \@3.3V| +| PHY features| - Supports all data rates of the IEEE802.11b/g/n single antenna.
- Supported maximum rate: 72.2 Mbps\@HT20 MCS7
- 20 MHz standard bandwidth and 5 MHz/10 MHz narrow bandwidth.
-  STBC.
- Short-GI.| +| MAC features| - A-MPDU and A-MSDU.
- Blk-ACK.
- QoS to meet the quality requirements of different services.| +| CPU subsystem| -  High-performance 32-bit microprocessor with a maximum working frequency of 160 MHz.
- Embedded SRAM of 352 KB; ROM of 288 KB
- Embedded 2 MB flash memory| +| Peripheral ports| - One SDIO interface, two SPI interfaces, two I2C interfaces, three UART interfaces, 15 GPIO interfaces, seven ADC inputs, six PWM interfaces, and one I2S interface (Note: These interfaces are all multiplexed.)
- Frequency of the external main crystal: 40 MHz or 24 MHz| +| Others| - Package: QFN-32, 5 mm x 5 mm
- Working temperature: -40°C to +85°C| + + +## OpenHarmony Key Features + +OpenHarmony provides a wide array of available capabilities based on the Hi3861 platform. The following table describes the available key components. + + **Table 2** Key components of OpenHarmony + +| Component| Capability| +| -------- | -------- | +| WLAN| Provides the WLAN service capability. For example, connecting to or disconnecting from a station or hotspot, and querying the status of a station or hotspot.| +| IoT controller| Provides the capability of operating peripherals, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM and flash memory.| +| DSoftBus| Provides the capabilities of device discovery and data transmission in the distributed network.| +| hichainsdk| Provides the capability of securely transferring data between devices when they are interconnected.| +| huks| Provides capabilities of key management, encryption, and decryption.| +| System service management| Provides a unified OpenHarmony service development framework based on the service-oriented architecture.| +| Boot| Provides the entry identifier for starting a system service. When the system service management is started, the function identified by bootstrap is called to start a system service.| +| System attribute| Provides capabilities of obtaining and setting system attributes.| +| Base library| Provides the common basic library capability, including file operations and KV storage management.| +| DFX | Provides the DFX capability, such as logging and printing.| +| XTS | Provides a set of OpenHarmony certification test suites.| diff --git a/en/device-dev/quick-start/quickstart-ide-lite-overview.md b/en/device-dev/quick-start/quickstart-ide-lite-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..0c8a543a8c9d0731f063ae7e4d14b4ee473a6e09 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-overview.md @@ -0,0 +1,40 @@ +# Mini and Small System Overview + + +## Introduction + +The OpenHarmony mini and small systems apply to devices with a reference memory greater than or equal to 128 KiB. This document helps you quickly get started with development of the OpenHarmony mini and small systems, from environment setup to "Hello World" program running. + +To accommodate different developer habits, OpenHarmony provides two modes for getting started with the standard system: + +- IDE mode: DevEco Device Tool is used for one-stop development, covering dependency installation, building, burning, and running. + +- Installation package mode: Dependency download and installation as well as building operations are performed using commands. Burning and running are performed in DevEco Device Tool. + OpenHarmony also provides the [Docker environment](../get-code/gettools-acquire.md), which can significantly simplify the environment configuration before compilation. You can build your source code in the Docker environment if you are more accustomed to using the installation package mode. + +This document exemplifies how to use the IDE mode. For details about the installation package mode, see [Getting Started with Mini and Small Systems (Installation Package Mode)](../quick-start/quickstart-lite-package-directory.md). + + +## Development Environment + +In the Windows+Ubuntu hybrid environment for OpenHarmony development: + +- Windows: used for source code development and burning. + +- Ubuntu: used for source code building. + +This document describes how to develop OpenHarmony in the Windows+Ubuntu environment. + + +## Development Boards + +In this document, two development board models are used as examples: Hi3861 and Hi3516D V300. For details about these development boards, see [Appendix](../quick-start/quickstart-ide-lite-board-introduction.md). You can purchase the development board as required. + + +## Development Process + +Below you can see the quick start process for the development of the mini and small systems. + + **Figure 1** Quick start process for the development of the mini and small systems + + ![en-us_image_0000001226634676](figures/en-us_image_0000001226634676.png) diff --git a/en/device-dev/quick-start/quickstart-ide-lite-sourcecode-acquire.md b/en/device-dev/quick-start/quickstart-ide-lite-sourcecode-acquire.md new file mode 100644 index 0000000000000000000000000000000000000000..f3fa19d7af0f3a2bec21a1dcf1116d5b005c4982 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-sourcecode-acquire.md @@ -0,0 +1,79 @@ +# Obtaining Source Code + + +In the Ubuntu environment, perform the following steps to obtain the OpenHarmony source code: + + +## Preparations + +1. Register your account with Gitee. + +2. Register an SSH public key for access to Gitee. + +3. Install the git client and git-lfs. + + Update the software source: + + ``` + sudo apt-get update + ``` + + Run the following command to install the tools: + + ``` + sudo apt-get install git git-lfs + ``` + +4. Configure user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +5. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +## Obtaining Source Code + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). + + +## Running prebuilts + + Go to the root directory of the source code and run the following script to install the compiler and binary tool: + +``` +bash build/prebuilts_download.sh +``` diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-application-framework.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-application-framework.md new file mode 100644 index 0000000000000000000000000000000000000000..798e092f3b6f5d0476c0adb12147d2f215f16e1c --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-application-framework.md @@ -0,0 +1,139 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + +The complete code directory is as follows: + + + +``` +applications/sample/hello +│── BUILD.gn +└── src + └── helloworld.c +``` + + +## How to Develop + +Perform the steps below in the source code directory: + +1. Create a directory and the program source code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program. + + + ``` + #include + + int main(int argc, char **argv) + { + printf("\n\n"); + printf("\n\t\tHello OHOS!\n"); + printf("\n\n\n"); + + return 0; + } + ``` + +2. Create a build file. + + Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + + ``` + import("//build/lite/config/component/lite_component.gni") + lite_component("hello-OHOS") { + features = [ ":helloworld" ] + } + executable("helloworld") { + output_name = "helloworld" + sources = [ "src/helloworld.c" ] + } + ``` + +3. Add a component. + + Modify the **build/lite/components/applications.json** file and add the configuration of **hello_world_app**. The following code snippet is a snippet of the **applications.json** file: The configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "components": [ + { + "component": "camera_sample_communication", + "description": "Communication related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/communication" + ], + "targets": [ + "//applications/sample/camera/communication:sample" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##start## + { + "component": "hello_world_app", + "description": "hello world samples.", + "optional": "true", + "dirs": [ + "applications/sample/hello" + ], + "targets": [ + "//applications/sample/hello:hello-OHOS" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##end## + { + "component": "camera_sample_app", + "description": "Camera related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/launcher", + "applications/sample/camera/cameraApp", + "applications/sample/camera/setting", + "applications/sample/camera/gallery", + "applications/sample/camera/media" + ], + ``` + +4. Modify the board configuration file. + + Modify the **vendor/hisilicon/hispark_taurus/config.json** file and add an entry of the **hello_world_app** component. The following code snippet is the configuration of the **applications** subsystem, the configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "subsystem": "applications", + "components": [ + { "component": "camera_sample_app", "features":[] }, + { "component": "camera_sample_ai", "features":[] }, + ##start## + { "component": "hello_world_app", "features":[] }, + ##end## + { "component": "camera_screensaver_app", "features":[] } + ] + }, + ``` diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-building.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-building.md new file mode 100644 index 0000000000000000000000000000000000000000..9d0404f86ff7a9608be8f4a901a44fd2e86cd55d --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-building.md @@ -0,0 +1,31 @@ +# Building + + +1. In **Projects**, click **Settings**. The Hi3516D V300 configuration page is displayed. + + ![en-us_image_0000001265492885](figures/en-us_image_0000001265492885.png) + +2. On the **toolchain** tab page, DevEco Device Tool automatically checks whether the dependent compilation toolchain is complete. If a message is displayed indicating that some tools are missing, click **SetUp** to automatically install the required tools. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the pip component fails to be installed, [change the Python](https://device.harmonyos.com/en/docs/documentation/guide/ide-set-python-source-0000001227639986) source and try again. + + ![en-us_image_0000001265652869](figures/en-us_image_0000001265652869.png) + + After the toolchain is automatically installed, the figure below is displayed. + + ![en-us_image_0000001220852754](figures/en-us_image_0000001220852754.png) + +3. On the **hi3516dv300** tab page, set **build_type**. The default value is **debug**. Click **Save** to save the settings. + + ![en-us_image_0000001221172710](figures/en-us_image_0000001221172710.png) + +4. Choose **PROJECT TASKS** > **hi3516dv300** > **Build** to start building. + + ![en-us_image_0000001265772913](figures/en-us_image_0000001265772913.png) + +5. Wait until **SUCCESS** is displayed in the **TERMINAL** window, indicating that the compilation is complete. + + ![en-us_image_0000001221012766](figures/en-us_image_0000001221012766.png) + + After the building is complete, go to the out directory of the project to view the generated files, which are needed in [burning](https://device.harmonyos.com/en/docs/documentation/guide/ide-hi3516-upload-0000001052148681). diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-burn.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-burn.md new file mode 100644 index 0000000000000000000000000000000000000000..2c23f4eec8a31da21b836de69b535b12ca8b9875 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-burn.md @@ -0,0 +1,70 @@ +# Burning + + +Hi3516D V300 supports burning through the USB port, network port, and serial port. This document describes how to burn source code through the USB port. The operations are performed in Windows. + + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3516D V300 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216516128](figures/en-us_image_0000001216516128.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/documentation/guide/hi3516_hi3518-drivers-0000001050743695). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198566364](figures/en-us_image_0000001198566364.png) + +5. On the **hi3516dv300** tab page, set the burning options. + + - **upload_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time. + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-usb**. + + ![en-us_image_0000001223190441](figures/en-us_image_0000001223190441.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **fastboot**, **kernel**, **rootfs**, and **userfs**. + + 1. On the **hi3516dv300_fastboot** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001198889702](figures/en-us_image_0000001198889702.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001243290907](figures/en-us_image_0000001243290907.png) + + 3. Follow the same procedure to modify the information about the **kernel**, **rootfs**, and **userfs** files. + +7. When you finish modifying, click **Save** on the top. + +8. Go to **hi3516dv300** > **Upload** to start burning. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If this is the first time you burn source code to the Hi3516D V300 or Hi3518E V300 board, the message "not find the Devices" may be displayed. In this case, follow the steps in [Installing the USB Port Driver on the Hi3516D V300 or Hi3518E V300 Development Board](https://device.harmonyos.com/en/docs/documentation/guide/usb_driver-0000001058690393) and start burning again. + + ![en-us_image_0000001267231481](figures/en-us_image_0000001267231481.png) + +9. When the following information is displayed in the Terminal window, press and hold the reset button, remove and insert the USB cable, and release the reset button to start burning. + + ![en-us_image_0000001114129426](figures/en-us_image_0000001114129426.png) + + If the following message is displayed, it indicates that the burning is successful. + + ![en-us_image_0000001160649343](figures/en-us_image_0000001160649343.png) + +10. When the burning is successful, perform the operations in Running an Image to start the system. diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-running.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-running.md new file mode 100644 index 0000000000000000000000000000000000000000..a12915d4e335fc2f520812f8ea988a126128ed4d --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516-running.md @@ -0,0 +1,51 @@ +# Running + + +## Starting the System + +After burning is completed, you need to configure the bootloader to run the OpenHarmony system. + +1. In the Hi3516D V300 task, click **Configure bootloader (Boot OS)** to configure the bootloader. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > The bootloader configuration in DevEco Device Tool has been adapted to Hi3516D V300. Therefore, no manual modification is needed. + + ![en-us_image_0000001226794644](figures/en-us_image_0000001226794644.png) + +2. When the message shown below is displayed, restart the development board. If "SUCCESS" is displayed, it indicates that the configuration is successful. + + ![en-us_image_0000001227114584](figures/en-us_image_0000001227114584.png) + +3. Click **Monitor** on the taskbar to start the serial port tool. + + ![en-us_image_0000001271234705](figures/en-us_image_0000001271234705.png) + +4. When the command output is displayed, press **Enter** until **OHOS #** is displayed, indicating that the system is started successfully. + + ![en-us_image_0000001271594709](figures/en-us_image_0000001271594709.png) + + +## Running a Hello World Program + +After the system is started, perform the following steps to run the Hello World program: + +1. Go to the **bin** directory on the startup page. + + ``` + cd bin + ``` + +2. Run the following command to run the **helloworld** program: + + ``` + ./helloworld + ``` + + If the message "Hello World!" is displayed, the program runs successfully. + + ![en-us_image_0000001271354693](figures/en-us_image_0000001271354693.png) + + +## Next + +Congratulations! You have finished all steps! Proceed to [develop a sample camera with a screen](https://gitee.com/openharmony/docs/blob/master/en/device-dev/guide/device-camera.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..30a1760dc180b69e062eb15d51e825422c246b46 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3516.md @@ -0,0 +1,11 @@ +# Hi3516 Development Board + + + +- **[Writing a Hello World Program](quickstart-ide-lite-steps-hi3516-application-framework.md)** + +- **[Building](quickstart-ide-lite-steps-hi3516-building.md)** + +- **[Burning](quickstart-ide-lite-steps-hi3516-burn.md)** + +- **[Running](quickstart-ide-lite-steps-hi3516-running.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3816-running.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3816-running.md new file mode 100644 index 0000000000000000000000000000000000000000..4628c9d700b307c2f9013f587688a1f288cf1a40 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3816-running.md @@ -0,0 +1,19 @@ +# Running + + +## Viewing Execution Result + +After the sample code is compiled, burnt, run, and debugged, restart the development board. If the following messages are displayed, the image is running correctly: + + +``` +ready to OS start +FileSystem mount ok. +wifi init success! +[DEMO] Hello world. +``` + + +## Next + +Congratulations! You have finished all steps! Proceed to [develop a sample WLAN product](https://gitee.com/openharmony/docs/blob/master/en/device-dev/guide/device-wlan.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-application-framework.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-application-framework.md new file mode 100644 index 0000000000000000000000000000000000000000..f3de1522e47257bf0b3f0a644b945c5cc629d87f --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-application-framework.md @@ -0,0 +1,141 @@ +# Writing a Hello World Program + + +The following exemplifies how to create a program by modifying the source code. The created program outputs the message "Hello world." Perform the steps below in the source code directory. + + +1. Determine the directory structure. + + Before compiling a service, you must create a directory (or a directory structure) in **./applications/sample/wifi-iot/app** to store source code files. + + For example, add the **my_first_app** service to the **app** directory, where **hello_world.c** is the service code and **BUILD.gn** is the compilation script. The directory structure is shown as follows: + + + ``` + . + └── applications + └── sample + └── wifi-iot + └── app + └── my_first_app + │── hello_world.c + └── BUILD.gn + ``` + +2. Write the service code. + + Create the **hello_world.c** file in **./applications/sample/wifi-iot/app/my_first_app**. Then, create the service entry function **HelloWorld** in **hello_world.c** and implement service logic. Call **SYS_RUN()** of OpenHarmony to start the service. (**SYS_RUN** is defined in the **ohos_init.h** file.) + + ``` + #include + #include "ohos_init.h" + #include "ohos_types.h" + + void HelloWorld(void) + { + printf("[DEMO] Hello world.\n"); + } + SYS_RUN(HelloWorld); + ``` + +3. Compile the **BUILD.gn** file for building services into a static library. + + Create the **BUILD.gn** file in **./applications/sample/wifi-iot/app/my_first_app** and configure the file as follows: + + The **BUILD.gn** file consists of three parts, including target, source file, and header file path. You need to fill in all of these parts. + + + ``` + static_library("myapp") { + sources = [ + "hello_world.c" + ] + include_dirs = [ + "//utils/native/lite/include" + ] + } + ``` + + - Specify the compilation result named **libmyapp.a** in **static_library**. You can fill in this part based on your need. + - Specify the .c file on which a file depends and its path in **sources**. The path that contains **//** represents an absolute path (the code root path). The path that does not contain **//** is a relative path. + - Specify the path of .h file on which **sources** depends in **include_dirs**. + +4. Add a component. + + Modify the **build/lite/components/applications.json** file and add the configuration of **hello_world_app**. The following code snippet is a snippet of the **applications.json** file: The configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "components": [ + { + "component": "camera_sample_communication", + "description": "Communication related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/communication" + ], + "targets": [ + "//applications/sample/camera/communication:sample" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##start## + { + "component": "hello_world_app", + "description": "hello world samples.", + "optional": "true", + "dirs": [ + "applications/sample/wifi-iot/app/my_first_app" + ], + "targets": [ + "//applications/sample/wifi-iot/app/my_first_app:myapp" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_m" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##end## + { + "component": "camera_sample_app", + "description": "Camera related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/launcher", + "applications/sample/camera/cameraApp", + "applications/sample/camera/setting", + "applications/sample/camera/gallery", + "applications/sample/camera/media" + ], + ``` + +5. Modify the board configuration file. + + Modify the **vendor/hisilicon/hispark_pegasus/config.json** file and add an entry of the **hello_world_app** component. The following code snippet is the configuration of the **applications** subsystem, the configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "subsystem": "applications", + "components": [ + ##start## + { "component": "hello_world_app", "features":[] }, + ##end## + { "component": "wifi_iot_sample_app", "features":[] } + ] + }, + ``` diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-building.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-building.md new file mode 100644 index 0000000000000000000000000000000000000000..ea80a251580ac5945ff9f02616ce4ff48e5e10ef --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-building.md @@ -0,0 +1,31 @@ +# Building + + +1. In **Projects**, click **Settings**. The Hi3861 configuration page is displayed. + + ![en-us_image_0000001265785209](figures/en-us_image_0000001265785209.png) + +2. On the **toolchain** tab page, DevEco Device Tool automatically checks whether the dependent compilation toolchain is complete. If a message is displayed indicating that some tools are missing, click **SetUp** to automatically install the required tools. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the pip component fails to be installed, [change the Python](https://device.harmonyos.com/en/docs/documentation/guide/ide-set-python-source-0000001227639986) source and try again. + + ![en-us_image_0000001221025048](figures/en-us_image_0000001221025048.png) + + After the toolchain is automatically installed, the figure below is displayed. + + ![en-us_image_0000001221344980](figures/en-us_image_0000001221344980.png) + +3. On the **hi3861** tab page, set **build_type**. The default value is **debug**. Click **Save** to save the settings. + + ![en-us_image_0000001265945173](figures/en-us_image_0000001265945173.png) + +4. Choose **PROJECT TASKS** > **hi3861** > **Build** to start building. + + ![en-us_image_0000001265505181](figures/en-us_image_0000001265505181.png) + +5. Wait until **SUCCESS** is displayed in the **TERMINAL** window, indicating that the compilation is complete. + + ![en-us_image_0000001265665157](figures/en-us_image_0000001265665157.png) + + After the building is complete, go to the out directory of the project to view the generated files, which are needed in [burning](https://device.harmonyos.com/en/docs/documentation/guide/ide-hi3861-upload-0000001051668683). diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-burn.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-burn.md new file mode 100644 index 0000000000000000000000000000000000000000..e80143299bf65cb4693d77413af5b60932011f37 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-burn.md @@ -0,0 +1,56 @@ +# Burning + + +Hi3861 V100 supports burning through the serial port. To burn source code through the serial port in Windows, perform the following steps: + + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3861 V100 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216274840](figures/en-us_image_0000001216274840.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on Hi3861 V100](https://device.harmonyos.com/en/docs/documentation/guide/hi3861-drivers-0000001058153433). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198943768](figures/en-us_image_0000001198943768.png) + +5. On the **hi3861** tab page, set the burning options. + + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-serial**. + - **upload_partitions**: Select the files to be burnt. **hi3861_app** is selected by default. + + ![en-us_image_0000001243704061](figures/en-us_image_0000001243704061.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. + + On the **hi3861_app** tab page, select **partition_bin** from **New Option**, and set the path of the file to be burnt. + + ![en-us_image_0000001260919759](figures/en-us_image_0000001260919759.png) + +7. When you finish modifying, click **Save** on the top. + +8. Click **Open** to open the project file. Then, choose **PROJECT TASKS** > **hi3861** > **Upload** to start burning. + + ![en-us_image_0000001216440138](figures/en-us_image_0000001216440138.png) + +9. When the following information is displayed, press the RST button on the development board to restart it. + + ![en-us_image_0000001198466090](figures/en-us_image_0000001198466090.png) + +10. Wait until the burning is complete. When the following message is displayed, the burning is successful. + + ![en-us_image_0000001216761476](figures/en-us_image_0000001216761476.png) diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-debug.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-debug.md new file mode 100644 index 0000000000000000000000000000000000000000..f0036404d538a2c5d1ed1d043c1220940a273411 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-debug.md @@ -0,0 +1,65 @@ +# Debugging and Verification + + +When the burning and networking are complete, you can use either of the following methods to debug and verify whether the source code has been burnt correctly: + + +1. Using printf to print logs + +2. Using ASM files to locate panic issues + + +As the example used here is simple, we use the printf method. The following describes the two methods in detail. + + +## printf + +Add the printf function to the code, which helps print data to the serial port. You can add log printing in key service paths or service exception locations, as shown in the following figure. + + +``` +void HelloWorld(void) +{ + printf("[DEMO] Hello world.\n"); +} +``` + + +## Using ASM Files to Locate Issues + + When the system exits abnormally, the call stack information about the abnormal exit is displayed on the serial port. Analyze the displayed information to troubleshoot and pinpoint issues. + +``` +=======KERNEL PANIC======= +**Call Stack* +Call Stack 0 -- 4860d8 addr:f784c +Call Stack 1 -- 47b2b2 addr:f788c +Call Stack 2 -- 3e562c addr:f789c +Call Stack 3 -- 4101de addr:f78ac +Call Stack 4 -- 3e5f32 addr:f78cc +Call Stack 5 -- 3f78c0 addr:f78ec +Call Stack 6 -- 3f5e24 addr:f78fc +Call Stack end*** +``` + +To analyze the call stack information, the **Hi3861_wifiiot_app.asm** file is required. This file records the symbol addresses of the functions in the code in the flash memory and the disassembly information. The ASM file is built and output together with the version software package and is stored in the **./out/wifiiot/** directory. + +1. Save the CallStack information to a .txt file for editing. (Optional) + +2. Open the asm file, search for the addresses in CallStack, and list the corresponding function names. Generally, you only need to find the functions matching the first several stacks to locate issues. + + ``` + Call Stack 0 -- 4860d8 addr:f784c -- WadRecvCB + Call Stack 1 -- 47b2b2 addr:f788c -- wal_sdp_process_rx_data + Call Stack 2 -- 3e562c addr:f789c + Call Stack 3 -- 4101de addr:f78ac + Call Stack 4 -- 3e5f32 addr:f78cc + Call Stack 5 -- 3f78c0 addr:f78ec + Call Stack 6 -- 3f5e24 addr:f78fc + ``` + +3. Based on the call stack information, we can conclude that an exception occurs in the **WadRecvCB** function. + + ![en-us_image_0000001226634668](figures/en-us_image_0000001226634668.png) + +4. Check and modify the code. diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-netconfig.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-netconfig.md new file mode 100644 index 0000000000000000000000000000000000000000..c055b891843794a6fb9d2d9aa1de9933951f344b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861-netconfig.md @@ -0,0 +1,39 @@ +# Networking + + +After completing compilation and burning, perform the following to connect the Hi3861 WLAN module to the Internet using AT commands. + + +1. Click the icon of **DevEco: Serial Monitor** at the bottom of DevEco Device Tool to keep the connection between the Windows workstation and the Hi3861 WLAN module. + + **Figure 1** Opening the DevEco Device Tool serial port + + ![en-us_image_0000001226634700](figures/en-us_image_0000001226634700.png) + +2. Reset the Hi3861 WLAN module. The message **ready to OS start** is displayed on the **TERMINAL** panel, indicating that the WLAN module is started successfully. + + **Figure 2** Successful resetting of the Hi3861 WLAN module + + ![en-us_image_0000001271594733](figures/en-us_image_0000001271594733.png) + +3. Run the following AT commands in sequence via the DevEco serial port terminal to start the STA mode, connect to the specified AP, and enable Dynamic Host Configuration Protocol (DHCP). + + ``` + AT+STARTSTA # Start the STA mode. + AT+SCAN # Scan for available APs. + AT+SCANRESULT # Display the scanning result. + AT+CONN="SSID",,2,"PASSWORD" # Connect to the specified AP. (SSID and PASSWORD represent the name and password of the hotspot to be connected, respectively.) + AT+STASTAT # View the connection result. + AT+DHCP=wlan0,1 # Request the IP address of wlan0 from the AP using DHCP. + ``` + +4. Check whether the Hi3861 WLAN module is properly connected to the gateway, as shown in the following figure. + + ``` + AT+IFCFG # View the IP address assigned to an interface of the module. + AT+PING=X.X.X.X # Check the connectivity between the module and the gateway. Replace X.X.X.X with the actual gateway address. + ``` + + **Figure 3** Successful networking of the Hi3861 WLAN module + + ![en-us_image_0000001227114612](figures/en-us_image_0000001227114612.png) diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861.md b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861.md new file mode 100644 index 0000000000000000000000000000000000000000..0c22b10cbab66b1c784ccbe56e239f77970add95 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps-hi3861.md @@ -0,0 +1,15 @@ +# Hi3861 Development Board + + + +- **[Writing a Hello World Program](quickstart-ide-lite-steps-hi3861-application-framework.md)** + +- **[Building](quickstart-ide-lite-steps-hi3861-building.md)** + +- **[Burning](quickstart-ide-lite-steps-hi3861-burn.md)** + +- **[Networking](quickstart-ide-lite-steps-hi3861-netconfig.md)** + +- **[Debugging and Verification](quickstart-ide-lite-steps-hi3861-debug.md)** + +- **[Running](quickstart-ide-lite-steps-hi3816-running.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite-steps.md b/en/device-dev/quick-start/quickstart-ide-lite-steps.md new file mode 100644 index 0000000000000000000000000000000000000000..65831aac645d6edc634eb405a6c1e15cfc55543c --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite-steps.md @@ -0,0 +1,7 @@ +# Running a Hello World Program + + + +- **[Hi3861 Development Board](quickstart-ide-lite-steps-hi3861.md)** + +- **[Hi3516 Development Board](quickstart-ide-lite-steps-hi3516.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-lite.md b/en/device-dev/quick-start/quickstart-ide-lite.md new file mode 100644 index 0000000000000000000000000000000000000000..8abb4f01ec14362054b6b196b48c159ce66fab92 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-lite.md @@ -0,0 +1,13 @@ +# Getting Started for Mini and Small Systems (IDE Mode) + + + +- **[Mini and Small System Overview](quickstart-ide-lite-overview.md)** + +- **[Environment Preparation](quickstart-ide-lite-env-setup.md)** + +- **[Creating a Source Code Project](quickstart-ide-lite-create-project.md)** + +- **[Running a Hello World Program](quickstart-ide-lite-steps.md)** + +- **[Appendix](quickstart-ide-lite-appendix.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-appendix.md b/en/device-dev/quick-start/quickstart-ide-standard-appendix.md new file mode 100644 index 0000000000000000000000000000000000000000..6df76026c9e35f243e192e909e2bfefd441c8a74 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-appendix.md @@ -0,0 +1,5 @@ +# Appendix + + + +- **[Introduction to Development Boards](quickstart-ide-standard-board-introduction.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-hi3516.md b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..250a2a496ed1f7e3aa84a564a3498fadedc5ad01 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-hi3516.md @@ -0,0 +1,20 @@ +# Introduction to the Hi3516 Development Board + + +## Overview + +Hi3516D V300 is a next-generation system on chip (SoC) designed for industry-dedicated smart HD IP cameras. It introduces a next-generation image signal processor (ISP), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. + + **Figure 1** Hi3516 front view + + ![en-us_image_0000001227082182](figures/en-us_image_0000001227082182.png) + + +## Development Board Specifications + + **Table 1** Hi3516 specifications + +| Item| Description| +| -------- | -------- | +| Processor and internal memory| - Hi3516D V300 chip
- DDR3 1GB
- eMMC 4.5, 8 GB capacity| +| External components| - Ethernet port
- Audio and video
  - 1 voice input
  - 1 mono channel (AC_L) output, connected to a 3 W power amplifier (LM4871)
  - MicroHDMI (1-channel HDMI 1.4)
- Camera
  - Sensor IMX335
  - M12 lens, 4 mm focal length, and 1.8 aperture
- Display
  - LCD connector (2.35-inch)
  - LCD connector (5.5-inch)
- External components and ports
  - Memory card port
  - JTAG/I2S port
  - ADC port
  - Steering gear port
  - Grove connector
  - USB 2.0 (Type-C)
  - Three function keys, two user-defined keys, and one upgrade key
  - LED indicator, green or red| diff --git a/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-rk3568.md b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-rk3568.md new file mode 100644 index 0000000000000000000000000000000000000000..6f74a5fa510bcea8b73cfff9cb70e29f50d6bf8f --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction-rk3568.md @@ -0,0 +1,41 @@ +# Introduction to the RK3568 Development Board + + +## Overview + +Bolstered by the Rockchip RK3568 chip, the RK3568 development board integrates a dual-core GPU and high-efficiency NPU. Its quad-core 64-bit Cortex-A55 processor uses the advanced 22 nm manufacturing process and is clocked at up to 2.0 GHz. The development board is packed with Bluetooth, Wi-Fi, audio, video, and camera features, with a wide range of expansion ports as well as video input and output ports. It comes with dual GE auto-sensing RJ45 ports, so it can be used in multi-connectivity products, such as NVRs and industrial gateways. + + **Figure 1** Front view of the RK3568 development board + + ![en-us_image_0000001271442261](figures/en-us_image_0000001271442261.png) + + **Figure 2** RK3568 rear view + + ![en-us_image_0000001271322293](figures/en-us_image_0000001271322293.png) + + +## Development Board Specifications + + **Table 1** RK3568 specifications + +| Item| Description| +| -------- | -------- | +| Display| - 1 x HDMI 2.0 (Type-A) port, supporting 4K/60 fps output
- 2 x MIPI, supporting 1920 x 1080\@60 fps output
-  1 x eDP, supporting 2K@60 fps output| +| Audio port| - 1×8ch I2S/TDM/PDM
- 1 x HDMI
- 1 x speaker output
- 1 x headset output
- 1 x microphone for onboard audio input| +| Ethernet port| 2 x GMAC (10/100/1000M)| +| Wireless connectivity| SDIO port, supporting Wi-Fi 6 5G/2.5 GHz and Bluetooth 4.2| +| Camera port| MIPI-CSI2, 1 x 4-lane/2x2-lane\@2.5 Gbps/lane| +| USB | - 2 x USB 2.0 Host, Type-A
- 1 x USB 3.0 Host, Type-A
- 1×USB3.0 OTG | +| PCIe | 1 x 2-lane PCIe 3.0 Connector (RC mode)| +| SATA | 1×SATA3.0 Connector | +| SDMMC | 1×Micro SD Card3.0 | +| Keys| - 1×Vol+/Recovery
- 1×Reset
- 1×Power
- 1×Vol-
- 1×Mute | +| Debugging port| 1 x Debugging serial port| +| RTC | 1 x RTC | +| IR | 1 x IR | +| Tri-color indicator| 3 x LED | +| G-sensor | 1 x G-sensor | +| Fan | 1 x fan | +| Expansion port| The 20-pin expansion ports include:
- 2 x ADC
-  2 x I2C
- 7 x GPIO (or 3 x GPIO + 4 x UART)
- 3 x VCC power (12 V, 3.3 V, and 5 V)| +| Mother board dimensions| 180mm×130mm | +| PCB| 4-laminate| diff --git a/en/device-dev/quick-start/quickstart-ide-standard-board-introduction.md b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction.md new file mode 100644 index 0000000000000000000000000000000000000000..a0ed1297124e19198467f2e0479f276a8622e052 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-board-introduction.md @@ -0,0 +1,7 @@ +# Introduction to Development Boards + + + +- **[Introduction to the Hi3516 Development Board](quickstart-ide-standard-board-introduction-hi3516.md)** + +- **[Introduction to the RK3568 Development Board](quickstart-ide-standard-board-introduction-rk3568.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-create-project.md b/en/device-dev/quick-start/quickstart-ide-standard-create-project.md new file mode 100644 index 0000000000000000000000000000000000000000..5e1e39d880cc945e06b35db0607bc8752838d4d1 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-create-project.md @@ -0,0 +1,35 @@ +# Creating a Source Code Project + + +After [setting up the Windows+Ubuntu hybrid development environment](../quick-start/quickstart-ide-standard-env-setup-win-ubuntu.md) and [obtaining source code](../quick-start/quickstart-ide-standard-sourcecode-acquire.md), perform the following steps to create a source code project in Windows: + + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the source code directory to be imported and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001271562277](figures/en-us_image_0000001271562277.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. The following figure uses **Hi3516DV300** as an example. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - Set **Product** to **Hi3516DV300** for the Hi3516D V300 development board. + > + > - Set **Product** to **rk3568** for the RK3568 development board. + + ![en-us_image_0000001271448821](figures/en-us_image_0000001271448821.png) + +6. Click **Open** to open the project or source code. diff --git a/en/device-dev/quick-start/quickstart-ide-standard-env-setup-win-ubuntu.md b/en/device-dev/quick-start/quickstart-ide-standard-env-setup-win-ubuntu.md new file mode 100644 index 0000000000000000000000000000000000000000..e394e476263d107815b0f6da6a02ad8f5a2b2353 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-env-setup-win-ubuntu.md @@ -0,0 +1,204 @@ +# Setting Up the Windows+Ubuntu Hybrid Development Environment + + +In embedded development, Windows-based tools, such as Visual Studio Code, are widely used in code editing. Yet, as the source code of most development boards, such as Hi3861 and Hi3516, cannot be built in Windows, these development boards require the Ubuntu build environment. + + +In the Windows+Ubuntu hybrid build environment, you can enjoy the benefits of both DevEco Device Tool for Windows and DevEco Device Tool for Ubuntu (where Visual Studio Code is optional). + + +## System Requirements + +- Windows: Windows 10 (64-bit) + +- Ubuntu: Ubuntu 20.04 or later; recommended memory: 16 GB or higher. + +- User name: cannot contain Chinese characters + +- DevEco Device Tool: 3.0 Release + + +## Setting Up the Ubuntu Build Environment + +The setup procedure varies, depending on whether you need a GUI. If you need a GUI, you need to install Visual Studio Code. In this case, follow the instructions in [Setting Up the Ubuntu Development Environment](https://device.harmonyos.com/en/docs/documentation/guide/ide-install-ubuntu-0000001072959308). If you do not need a GUI, perform the steps below: + +1. Make sure the Ubuntu shell environment is **bash**. + + 1. Run the following command and check whether the command output is **bash**. If the command output is not **bash**, go to step 2. + + ``` + ls -l /bin/sh + ``` + + ![en-us_image_0000001226764302](figures/en-us_image_0000001226764302.png) + + 2. Start the command-line tool, run the following command, enter your password, and select **No** to set **Ubuntu shell** to **bash**. + + ``` + sudo dpkg-reconfigure dash + ``` + + ![en-us_image_0000001243641075](figures/en-us_image_0000001243641075.png) + +2. Download the [DevEco Device Tool 3.0 Release Linux version](https://device.harmonyos.com/cn/ide#download). + +3. Decompress the DevEco Device Tool software package and assign permission on the folder obtained from the decompression. + + 1. Go to the directory where the DevEco Device Tool software package is stored and run the following command to decompress the software package. In the command, change **devicetool-linux-tool-3.0.0.400.zip** to the actual software package name. + + ``` + unzip devicetool-linux-tool-3.0.0.400.zip + ``` + 2. Open the folder of the decompressed software package and run the following command to grant the execute permission on the installation file. In the command, change **devicetool-linux-tool-3.0.0.400.sh** to the actual installation file name. + + ``` + chmod u+x devicetool-linux-tool-3.0.0.400.sh + ``` + +4. Run the following command to install DevEco Device Tool, where **devicetool-linux-tool-3.0.0.400.sh** indicates the installation file name. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > During the installation, the setup wizard automatically checks whether Python 3.8 or 3.9 is installed. If Python 3.8 or 3.9 is not installed, the setup wizard displays the "Do you want to continue?" message; enter **Y** to allow the setup wizard to automatically install Python. + + + ``` + sudo ./devicetool-linux-tool-3.0.0.400.sh + ``` + + Wait until the "Deveco Device Tool successfully installed." message is displayed. + + ![en-us_image_0000001198722374](figures/en-us_image_0000001198722374.png) + + +## Setting Up Windows Development Environment + +To remotely access the Ubuntu environment through Windows and enjoy the benefits of DevEco Device Tool for Windows, you need to install DevEco Device Tool on Windows. + +1. Download the [DevEco Device Tool 3.0 Release](https://device.harmonyos.com/cn/ide#download) Windows edition. + +2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**. + +3. Set the installation path of DevEco Device Tool and click **Next**. You are advised to install DevEco Device Tool in a non-system drive. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If you have installed DevEco Device Tool 3.0 Beta2 or earlier, the earlier version will be uninstalled before you install a new version. If the following error message is displayed during the uninstallation, click **Ignore** to continue the installation. This error does not affect the installation of the new version. + > + > ![en-us_image_0000001239275843](figures/en-us_image_0000001239275843.png) + + ![en-us_image_0000001270076961](figures/en-us_image_0000001270076961.png) + +4. When prompted, select the tools to be automatically installed. + + 1. On the **VSCode installation confirm** page, select **Install VScode 1.62.2 automatically** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Visual Studio Code 1.62 or later has been installed, this step will be skipped. + + ![en-us_image_0000001237801283](figures/en-us_image_0000001237801283.png) + + 2. On the displayed **Python select page**, select **Download from Huawei mirror** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Python 3.8 or 3.9 has been installed, select **Use one of compatible on your PC**. + + ![en-us_image_0000001193983334](figures/en-us_image_0000001193983334.png) + +5. In the dialog box shown below, click **Next** to download and install the tools.. + + ![en-us_image_0000001239634067](figures/en-us_image_0000001239634067.png) + +6. Wait for the DevEco Device Tool setup wizard to automatically install DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard. + + ![en-us_image_0000001239650137](figures/en-us_image_0000001239650137.png) + +7. From Visual Studio Code, access the DevEco Device Tool page. Now you can conduct your development in DevEco Device Tool. + + ![en-us_image_0000001225760456](figures/en-us_image_0000001225760456.png) + + +## Configuring Windows to Remotely Access the Ubuntu Build Environment + + +### Installing the SSH Service and Obtaining the IP Address for Remote Access + +1. In Ubuntu, open the Terminal tool and run the following command to install the SSH service: + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the command fails to be executed and the system displays a message indicating that the openssh-server and openssh-client depend on different versions, install the openssh-client of the required version (for example, **sudo apt-get install openssh-client=1:8.2p1-4**) as prompted on the command-line interface (CLI) and run the command again to install the openssh-server. + + + ``` + sudo apt-get install openssh-server + ``` + +2. Run the following command to start the SSH service: + + ``` + sudo systemctl start ssh + ``` + +3. Run the following command to obtain the IP address of the current user for remote access to the Ubuntu environment from Windows: + + ``` + ifconfig + ``` + + ![en-us_image_0000001215737140](figures/en-us_image_0000001215737140.png) + + +### Installing Remote SSH + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001239080359](figures/en-us-cn_image_0000001239080359.png), and search for **remote-ssh** in the Extension Marketplace. + + ![en-us_image_0000001193920448](figures/en-us_image_0000001193920448.png) + +2. Click **Install** to install Remote-SSH. After the installation is successful, **Remote-SSH** is displayed on the **INSTALLED** list. + + ![en-us_image_0000001238880335](figures/en-us_image_0000001238880335.png) + + +### Remotely Connecting to the Ubuntu Environment + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001238760373](figures/en-us_image_0000001238760373.png), and click + on the **REMOTE EXOPLORER** page. + + ![en-us_image_0000001215878922](figures/en-us_image_0000001215878922.png) + +2. In the **Enter SSH Connection Command** text box, enter **ssh *username@ip_address***, where *ip_address* indicates the IP address of the remote computer to be connected and *username* indicates the account name used for logging in to the remote computer. + + ![en-us_image_0000001215879750](figures/en-us_image_0000001215879750.png) + +3. In the displayed dialog box, select the default first option as the SSH configuration file. + + ![en-us_image_0000001260519729](figures/en-us_image_0000001260519729.png) + +4. Under **SSH TARGETS**, find the remote computer and click ![en-us_image_0000001194080414](figures/en-us_image_0000001194080414.png) to start it. + + ![en-us_image_0000001215720398](figures/en-us_image_0000001215720398.png) + +5. In the displayed dialog box, select **Linux**, select **Continue**, and enter the password for logging in to the remote computer. + + ![en-us_image_0000001215897530](figures/en-us_image_0000001215897530.png) + + After the connection is successful, the plug-in is automatically installed in the .vscode-server folder on the remote computer. After the installation is complete, reload Visual Studio Code in Windows as prompted. Then you can develop, compile, and burn source code in DevEco Device Tool on Windows. + + +### Registering the Public Key for Accessing the Ubuntu Environment + +After the preceding operations are complete, you can remotely connect to the Ubuntu environment through Windows for development. However, you need to frequently enter the remote connection password. To eliminate this need, you can use the SSH public key. + +1. Open the Git bash CLI and run the following command to generate an SSH public key. During command execution, perform operations as prompted. Set **username** and **ip** to the user name and IP address you use for connecting to the Ubuntu system. + + ``` + ssh-keygen -t rsa + ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip + ``` + + ![en-us_image_0000001271532317](figures/en-us_image_0000001271532317.png) + +2. In Visual Studio Code, click the remote connection setting button and open the **config** file. + + ![en-us_image_0000001226034634](figures/en-us_image_0000001226034634.png) + +3. In the **config** file, add the SSK key file information, as shown below. Then save the file. + + ![en-us_image_0000001270356233](figures/en-us_image_0000001270356233.png) diff --git a/en/device-dev/quick-start/quickstart-ide-standard-env-setup.md b/en/device-dev/quick-start/quickstart-ide-standard-env-setup.md new file mode 100644 index 0000000000000000000000000000000000000000..cb161ced75854ad67c97d548d0beb24bae637bfb --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-env-setup.md @@ -0,0 +1,7 @@ +# Environment Preparation + + + +- **[Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-standard-env-setup-win-ubuntu.md)** + +- **[Obtaining Source Code](quickstart-ide-standard-sourcecode-acquire.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-overview.md b/en/device-dev/quick-start/quickstart-ide-standard-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..c6a87ed86cf78b9c3f5bffadd84b838193f6f3f1 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-overview.md @@ -0,0 +1,40 @@ +# Standard System Overview + + +## Introduction + +The OpenHarmony standard system applies to devices with a reference memory greater than or equal to 128 MiB. This document helps you quickly get started for development of the OpenHarmony standard system, from environment setup to building, burning, and startup. + +To accommodate different developer habits, OpenHarmony provides two modes for getting started with the standard system: + +- IDE mode: DevEco Device Tool is used for one-stop development, covering dependency installation, building, burning, and running. + +- Installation package mode: Dependency download and installation as well as building operations are performed using commands. Burning and running are performed in DevEco Device Tool. + OpenHarmony also provides the [Docker environment](../get-code/gettools-acquire.md), which can significantly simplify the environment configuration before compilation. You can build your source code in the Docker environment if you are more accustomed to using the installation package mode. + +This document exemplifies how to use the IDE mode. For details about the installation package mode, see [Getting Started with Standard System (Installation Package Mode)](../quick-start/quickstart-standard-package-directory.md). + + +## Development Environment + +In the Windows+Ubuntu hybrid environment for OpenHarmony development: + +- Windows: used for source code development and burning. + +- Ubuntu: used for source code building. + +This document describes how to develop OpenHarmony in the Windows+Ubuntu environment. + + +## Development Boards + +In this document, two development board models are used as examples: Hi3516D V300 and RK3568. For details about these development boards, see [Appendix](../quick-start/quickstart-standard-board-introduction.md). You can purchase the development board as required. + + +## Development Process + +Below you can see the quick start process for the development of the standard system. + + **Figure 1** Quick start process for the development of the standard system + + ![en-us_image_0000001271562257](figures/en-us_image_0000001271562257.png) diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-build.md b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-build.md new file mode 100644 index 0000000000000000000000000000000000000000..3cd482ffc9081745cab02eb1c35af9af104b9b83 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-build.md @@ -0,0 +1,31 @@ +# Building + + +1. In **Projects**, click **Settings**. The Hi3516D V300 configuration page is displayed. + + ![en-us_image_0000001265492885](figures/en-us_image_0000001265492885.png) + +2. On the **toolchain** tab page, DevEco Device Tool automatically checks whether the dependent compilation toolchain is complete. If a message is displayed indicating that some tools are missing, click **SetUp** to automatically install the required tools. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the pip component fails to be installed, [change the Python](https://device.harmonyos.com/en/docs/documentation/guide/ide-set-python-source-0000001227639986) source and try again. + + ![en-us_image_0000001227277128](figures/en-us_image_0000001227277128.png) + + After the toolchain is automatically installed, the figure below is displayed. + + ![en-us_image_0000001227757036](figures/en-us_image_0000001227757036.png) + +3. On the **hi3516dv300** tab page, set **build_type**. The default value is **debug**. Click **Save** to save the settings. + + ![en-us_image_0000001221172710](figures/en-us_image_0000001221172710.png) + +4. Choose **PROJECT TASKS** > **hi3516dv300** > **Build** to start building. + + ![en-us_image_0000001265772913](figures/en-us_image_0000001265772913.png) + +5. Wait until **SUCCESS** is displayed in the **TERMINAL** window, indicating that the compilation is complete. + + ![en-us_image_0000001221012766](figures/en-us_image_0000001221012766.png) + + After the building is complete, go to the out directory of the project to view the generated files, which are needed in [burning](https://device.harmonyos.com/en/docs/documentation/guide/ide-hi3516-upload-0000001052148681). diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-burning.md b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..f618b545c42ac566bb5d5ae9a51c7c7337ee028a --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-burning.md @@ -0,0 +1,70 @@ +# Burning + + +To burn source code to Hi3516D V300 through the USB port in Windows, perform the following steps: + + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3516D V300 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216516128](figures/en-us_image_0000001216516128.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/documentation/guide/hi3516_hi3518-drivers-0000001050743695). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198566364](figures/en-us_image_0000001198566364.png) + +5. On the **hi3516dv300** tab page, set the burning options. + + - **upload_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time. + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-usb**. + + ![en-us_image_0000001223190441](figures/en-us_image_0000001223190441.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **fastboot**, **kernel**, **rootfs**, and **userfs**. + + 1. On the **hi3516dv300_fastboot** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001198889702](figures/en-us_image_0000001198889702.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001243290907](figures/en-us_image_0000001243290907.png) + + 3. Follow the same procedure to modify the information about the **kernel**, **rootfs**, and **userfs** files. + +7. When you finish modifying, click **Save** on the top. + +8. Go to **hi3516dv300** > **Upload** to start burning. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If this is the first time you burn source code to the Hi3516D V300 or Hi3518E V300 board, the message "not find the Devices" may be displayed. In this case, follow the steps in [Installing the USB Port Driver on the Hi3516D V300 or Hi3518E V300 Development Board](https://device.harmonyos.com/en/docs/documentation/guide/usb_driver-0000001058690393) and start burning again. + + ![en-us_image_0000001267231481](figures/en-us_image_0000001267231481.png) + +9. When the following information is displayed in the Terminal window, press and hold the reset button, remove and insert the USB cable, and release the reset button to start burning. + + ![en-us_image_0000001114129426](figures/en-us_image_0000001114129426.png) + + If the following message is displayed, it indicates that the burning is successful. + + ![en-us_image_0000001160649343](figures/en-us_image_0000001160649343.png) + +10. When the burning is successful, perform the operations in Running an Image to start the system. diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-create.md b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-create.md new file mode 100644 index 0000000000000000000000000000000000000000..652e16454a7fd5eeb31b5cb9e577b27f78eb112b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-create.md @@ -0,0 +1,162 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + +The complete code directory is as follows: + + +``` +applications/sample/hello +│── BUILD.gn +│── include +│ └── helloworld.h +│── src +│ └── helloworld.c +├── bundle.json +build +└── subsystem_config.json +productdefine/common +└── products + └── Hi3516DV300.json +``` + + +## How to Develop + +Perform the steps below in the source code directory: + + +1. Create a directory and write the service code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **World** to **OHOS**. Declare the string printing function **HelloPrint** in the **helloworld.h** file. You can use either C or C++ to develop a program. + + + ``` + #include + #include "helloworld.h" + + int main(int argc, char **argv) + { + HelloPrint(); + return 0; + } + + void HelloPrint() + { + printf("\n\n"); + printf("\n\t\tHello World!\n"); + printf("\n\n"); + } + ``` + + Add the header file **applications/sample/hello/include/helloworld.h**. The sample code is as follows: + + + ``` + #ifndef HELLOWORLD_H + #define HELLOWORLD_H + #ifdef __cplusplus + #if __cplusplus + extern "C" { + #endif + #endif + + void HelloPrint(); + + #ifdef __cplusplus + #if __cplusplus + } + #endif + #endif + #endif // HELLOWORLD_H + ``` + +2. Create a build file. + + 1. Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + ``` + import("//build/ohos.gni") # Import the build template. + ohos_executable("helloworld") {# Executable module. + sources = [ # Source code of the module. + "src/helloworld.c" + ] + include_dirs = [ # Directory of header file on which the module depends. + "include" + ] + cflags = [] + cflags_c = [] + cflags_cc = [] + ldflags = [] + configs = [] + deps =[] # Internal dependencies of a component. + part_name = "hello" # Component name. This parameter is mandatory. + install_enable = true # Whether to install the software by default. This parameter is optional. By default, the software is not installed. + } + ``` + 2. Create the **applications/sample/hello/bundle.json** file and add the description of the **sample** component. The content is as follows: + + ``` + { + "name": "@ohos/hello", + "description": "Hello world example.", + "version": "3.1", + "license": "Apache License 2.0", + "publishAs": "code-segment", + "segment": { + "destPath": "applications/sample/hello" + }, + "dirs": {}, + "scripts": {}, + "component": { + "name": "hello", + "subsystem": "sample", + "syscap": [], + "features": [], + "adapted_system_type": [ "mini", "small", "standard" ], + "rom": "10KB", + "ram": "10KB", + "deps": { + "components": [], + "third_party": [] + }, + "build": { + "sub_component": [ + "//applications/sample/hello:helloworld" + ], + "inner_kits": [], + "test": [] + } + } + } + ``` + + The **bundle.json** file consists of two parts. The first part describes the information about the subsystem to which the component belongs, and the second part defines the component building configuration. When adding a part, you need to specify the **sub_component** contained in the part. If there are interfaces provided for other components, describe them in **inner_kits**. If there are test cases, describe them in **test**. + +3. Modify the subsystem configuration file. + + Add the configuration of the new subsystem to the **build/subsystem_config.json** file. + + + ``` + "sample": { + "path": "applications/sample/hello", + "name": "sample" + }, + ``` + +4. Modify the product configuration file. + + In the productdefine\common\products\Hi3516DV300.json file, add the hello part after the existing part. + + + ``` + "usb:usb_manager_native":{}, + "applications:prebuilt_hap":{}, + "sample:hello":{}, + "wpa_supplicant-2.9:wpa_supplicant-2.9":{}, + ``` diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-running.md b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-running.md new file mode 100644 index 0000000000000000000000000000000000000000..a0e31a6a05ca740c4ad8c23e5c7ca3c60557076f --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516-running.md @@ -0,0 +1,57 @@ +# Running + + +## Starting the System + +After the burning is complete, perform the following steps to start the system: + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> This operation procedure is required only if this is the first time you burn an image for the standard system. + +1. In DevEco Device Tool, click **Monitor** to open the serial port tool. + + ![en-us_image_0000001227082162](figures/en-us_image_0000001227082162.png) + +2. Restart the development board. Before the autoboot countdown ends, press any key to enter the system. + + ![en-us_image_0000001271202289](figures/en-us_image_0000001271202289.gif) + +3. Run the following commands to set system boot parameters: + + ``` + setenv bootargs 'mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused rootdelay=10 hardware=Hi3516DV300 init=/init root=/dev/ram0 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),2M(misc),3307M(system),256M(vendor),-(userdata)'; + ``` + + + ``` + setenv bootcmd 'mmc read 0x0 0x82000000 0x800 0x4800; bootm 0x82000000' + ``` + + ![en-us_image_0000001271562269](figures/en-us_image_0000001271562269.png) + +4. Save the parameter settings. + + ``` + save + ``` + + ![en-us_image_0000001226762210](figures/en-us_image_0000001226762210.png) + +5. Restart the development board to start the system. + + ``` + reset + ``` + + ![en-us_image_0000001226602238](figures/en-us_image_0000001226602238.png) + + +## Running a Hello World Program + +After the system is started, start the serial port tool, run the **helloworld** command in any directory, and press **Enter**. If the message "Hello World!" is displayed, the program runs successfully. + +![en-us_image_0000001271322277](figures/en-us_image_0000001271322277.png) + +## Next + +Congratulations! You have finished all steps! Proceed to [develop a sample](../guide/device-clock-guide.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516.md b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..32080c7b30f6aae5e5c41f49f132408b2f949905 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-hi3516.md @@ -0,0 +1,11 @@ +# Hi3516 Development Board + + + +- **[Writing a Hello World Program](quickstart-ide-standard-running-hi3516-create.md)** + +- **[Building](quickstart-ide-standard-running-hi3516-build.md)** + +- **[Burning](quickstart-ide-standard-running-hi3516-burning.md)** + +- **[Running](quickstart-ide-standard-running-hi3516-running.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-build.md b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-build.md new file mode 100644 index 0000000000000000000000000000000000000000..d8ef1927a8532392f65b8c69790643b587bca3d4 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-build.md @@ -0,0 +1,31 @@ +# Building + + +1. In **Projects**, click **Settings**. The HH-SCDY200 configuration page is displayed. + + ![en-us_image_0000001221036768](figures/en-us_image_0000001221036768.png) + +2. On the **toolchain** tab page, DevEco Device Tool automatically checks whether the dependent compilation toolchain is complete. If a message is displayed indicating that some tools are missing, click **SetUp** to automatically install the required tools. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the pip component fails to be installed, [change the Python](https://device.harmonyos.com/en/docs/documentation/guide/ide-set-python-source-0000001227639986) source and try again. + + ![en-us_image_0000001221356692](figures/en-us_image_0000001221356692.png) + + After the toolchain is automatically installed, the figure below is displayed. + + ![en-us_image_0000001265676877](figures/en-us_image_0000001265676877.png) + +3. On the **hh_scdy200** tab page, set **build_type**. The default value is **debug**. Click **Save** to save the settings. + + ![en-us_image_0000001265956897](figures/en-us_image_0000001265956897.png) + +4. Choose **PROJECT TASKS** > **hi3861** > **Build** to start building. + + ![en-us_image_0000001265516901](figures/en-us_image_0000001265516901.png) + +5. Wait until **SUCCESS** is displayed in the **TERMINAL** window, indicating that the compilation is complete. + + ![en-us_image_0000001222361042](figures/en-us_image_0000001222361042.png) + + After the building is complete, go to the out directory of the project to view the generated files, which are needed in [burning](https://device.harmonyos.com/en/docs/documentation/guide/ide-rk3568-upload-0000001239220669). diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-burning.md b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..2448d3f546c6a94ec103611ed142bf781ad1f733 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-burning.md @@ -0,0 +1,55 @@ +# Burning + + +1. [Download](https://gitee.com/hihope_iot/docs/blob/master/HiHope_DAYU200/%E7%83%A7%E5%86%99%E5%B7%A5%E5%85%B7%E5%8F%8A%E6%8C%87%E5%8D%97/windows/DriverAssitant_v5.1.1.zip) **DriverInstall.exe**. Double-click **DriverInstall.exe** to open the installer. Then click the install button to install the USB driver as prompted. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the burning tool of an earlier version has been installed, uninstall it first. + +2. Connect the computer to the target development board through the USB port. + +3. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +4. In DevEco Device Tool, choose QUICK ACCESS > DevEco Home > Projects, and then click Settings. + + ![en-us_image_0000001239661509](figures/en-us_image_0000001239661509.png) + +5. On the **hh_scdy200** tab page, set the burning options. + + - **upload_partitions**: Select the files to be burnt. + - **upload_protocol**: Select the burning protocol **upgrade**. + + ![en-us_image_0000001194504874](figures/en-us_image_0000001194504874.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **loader**, **parameter**, **uboot**, **boot_linux**, **system**, **vendor**, and **userdata**. + + 1. On the **hh_scdy200_loader** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001224173270](figures/en-us_image_0000001224173270.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001268653461](figures/en-us_image_0000001268653461.png) + + 3. Follow the same procedure to modify the information about the **parameter**, **uboot**, **boot_linux**, **system**, **vendor**, and **userdata** files. + +7. When you finish modifying, click **Save** on the top. + +8. Click **Open** to open the project file. Click ![en-us_image_0000001239221905](figures/en-us_image_0000001239221905.png) to open DevEco Device Tool. Then, choose **PROJECT TASKS** > **hh_scdy200** > **Upload** to start burning. + + ![en-us_image_0000001194821710](figures/en-us_image_0000001194821710.png) + +9. Wait until the burning is complete. If the following message is displayed, the burning is successful. + + ![en-us_image_0000001194984912](figures/en-us_image_0000001194984912.png) diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-create.md b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-create.md new file mode 100644 index 0000000000000000000000000000000000000000..527fee8b3cb06cb90f6eca444cac2150d9b0fbb9 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-create.md @@ -0,0 +1,160 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + +The complete code directory is as follows: + + +``` +applications/sample/hello +│── BUILD.gn +│── include +│ └── helloworld.h +│── src +│ └── helloworld.c +├── bundle.json +build +└── subsystem_config.json +productdefine/common +└── products + └── rk3568.json +``` + + +## How to Develop + +Perform the steps below in the source code directory: + +1. Create a directory and write the service code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **World** to **OHOS**. Declare the string printing function **HelloPrint** in the **helloworld.h** file. You can use either C or C++ to develop a program. + + + ``` + #include + #include "helloworld.h" + + int main(int argc, char **argv) + { + HelloPrint(); + return 0; + } + + void HelloPrint() + { + printf("\n\n"); + printf("\n\t\tHello World!\n"); + printf("\n\n"); + } + ``` + + Add the header file **applications/sample/hello/include/helloworld.h**. The sample code is as follows: + + + ``` + #ifndef HELLOWORLD_H + #define HELLOWORLD_H + #ifdef __cplusplus + #if __cplusplus + extern "C" { + #endif + #endif + + void HelloPrint(); + + #ifdef __cplusplus + #if __cplusplus + } + #endif + #endif + #endif // HELLOWORLD_H + ``` + +2. Create a build file. + + 1. Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + ``` + import("//build/ohos.gni") # Import the build template. + ohos_executable("helloworld") {# Executable module. + sources = [ # Source code of the module. + "src/helloworld.c" + ] + include_dirs = [ # Directory of header file on which the module depends. + "include" + ] + cflags = [] + cflags_c = [] + cflags_cc = [] + ldflags = [] + configs = [] + deps =[] # Internal dependencies of a component. + part_name = "hello" # Component name. This parameter is mandatory. + install_enable = true # Whether to install the software by default. This parameter is optional. By default, the software is not installed. + } + ``` + 2. Create the **applications/sample/hello/bundle.json** file and add the description of the **sample** component. The content is as follows: + + ``` + { + "name": "@ohos/hello", + "description": "Hello world example.", + "version": "3.1", + "license": "Apache License 2.0", + "publishAs": "code-segment", + "segment": { + "destPath": "applications/sample/hello" + }, + "dirs": {}, + "scripts": {}, + "component": { + "name": "hello", + "subsystem": "sample", + "syscap": [], + "features": [], + "adapted_system_type": [ "mini", "small", "standard" ], + "rom": "10KB", + "ram": "10KB", + "deps": { + "components": [], + "third_party": [] + }, + "build": { + "sub_component": [ + "//applications/sample/hello:helloworld" + ], + "inner_kits": [], + "test": [] + } + } + } + ``` + + The **bundle.json** file consists of two parts. The first part describes the information about the subsystem to which the component belongs, and the second part defines the component building configuration. When adding a part, you need to specify the **sub_component** contained in the part. If there are interfaces provided for other components, describe them in **inner_kits**. If there are test cases, describe them in **test**. + +3. Modify the subsystem configuration file. + + Add the configuration of the new subsystem to the **build/subsystem_config.json** file. + + + ``` + "sample": { + "path": "applications/sample/hello", + "name": "sample" + }, + ``` + +4. Modify the product configuration file. + + In the productdefine\common\products\rk3568.json file, add the hello part after the existing part. + + ``` + "usb:usb_manager_native":{}, + "applications:prebuilt_hap":{}, + "sample:hello":{}, + "wpa_supplicant-2.9:wpa_supplicant-2.9":{}, + ``` diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-running.md b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-running.md new file mode 100644 index 0000000000000000000000000000000000000000..cf86116a18cf1c428dd4ad0bd8a8f29bd12f260a --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568-running.md @@ -0,0 +1,21 @@ +# Running + + +## Starting the System + +After the image is burnt and the development board is restarted, the system automatically starts. If the following page is displayed on the screen of the development board, the system is running properly. + + **Figure 1** System startup effect + + ![en-us_image_0000001226762222](figures/en-us_image_0000001226762222.jpg) + + +## Running a Hello World Program + +1. When the system is running, start the serial port tool (for example, PuTTY), set the baud rate to **1500000**, and connect to the device. + + ![en-us_image_0000001226602250](figures/en-us_image_0000001226602250.png) + +2. Enable the serial port, enter the **helloworld** command in any directory (for example, the root directory of the device) and press **Enter**. If the message "Hello World!" is displayed, the program runs successfully. + + ![en-us_image_0000001226922154](figures/en-us_image_0000001226922154.png) diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568.md b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568.md new file mode 100644 index 0000000000000000000000000000000000000000..8ffc858557242c87460d2476a3aa26f2649d9304 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running-rk3568.md @@ -0,0 +1,11 @@ +# RK3568 Development Board + + + +- **[Writing a Hello World Program](quickstart-ide-standard-running-rk3568-create.md)** + +- **[Building](quickstart-ide-standard-running-rk3568-build.md)** + +- **[Burning](quickstart-ide-standard-running-rk3568-burning.md)** + +- **[Running](quickstart-ide-standard-running-rk3568-running.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-running.md b/en/device-dev/quick-start/quickstart-ide-standard-running.md new file mode 100644 index 0000000000000000000000000000000000000000..2a3ff8023f3508de5314490099c7be73b44ba098 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-running.md @@ -0,0 +1,7 @@ +# Running a Hello World Program + + + +- **[Hi3516 Development Board](quickstart-ide-standard-running-hi3516.md)** + +- **[RK3568 Development Board](quickstart-ide-standard-running-rk3568.md)** diff --git a/en/device-dev/quick-start/quickstart-ide-standard-sourcecode-acquire.md b/en/device-dev/quick-start/quickstart-ide-standard-sourcecode-acquire.md new file mode 100644 index 0000000000000000000000000000000000000000..997e0ee227d706351e8b4c5c42d74e3858d86074 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-ide-standard-sourcecode-acquire.md @@ -0,0 +1,79 @@ +# Obtaining Source Code + + +In the Ubuntu environment, perform the following steps to obtain the OpenHarmony source code: + + +## Before You Start + +1. Register your account with Gitee. + +2. Register an SSH public key for access to Gitee. + +3. Install the git client and git-lfs. + + Update the software source: + + ``` + sudo apt-get update + ``` + + Run the following command to install the tools: + + ``` + sudo apt-get install git git-lfs + ``` + +4. Configure user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +5. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +## Obtaining Source Code + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). + + +## Running prebuilts + + Go to the root directory of the source code and run the following script to install the compiler and binary tool: + +``` +bash build/prebuilts_download.sh +``` diff --git a/en/device-dev/quick-start/quickstart-lite-appendix.md b/en/device-dev/quick-start/quickstart-lite-appendix.md new file mode 100644 index 0000000000000000000000000000000000000000..e63539f9355627c8da77419114f565b28fb908a1 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-appendix.md @@ -0,0 +1,7 @@ +# Appendix + + + +- **[Introduction to Development Boards](quickstart-lite-board-introduction.md)** + +- **[Reference](quickstart-lite-reference.md)** diff --git a/en/device-dev/quick-start/quickstart-lite-board-introduction.md b/en/device-dev/quick-start/quickstart-lite-board-introduction.md new file mode 100644 index 0000000000000000000000000000000000000000..30c06d28ebcb235c3677f625173e769ec8411c0b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-board-introduction.md @@ -0,0 +1,7 @@ +# Introduction to Development Boards + + + +- **[Introduction to the Hi3861 Development Board](quickstart-lite-introduction-hi3861.md)** + +- **[Introduction to the Hi3516 Development Board](quickstart-lite-introduction-hi3516.md)** diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md b/en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md index be5e42f8e68d01492dc887160e4643243d7562bd..ff4411ade6d31c0a3e283c532a25235a41c51561 100644 --- a/en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md +++ b/en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md @@ -1,106 +1,9 @@ -# FAQs +# FAQs -## What should I do if garbled characters and segmentation faults occur during hb installation? -- **Symptom** - Garbled characters and segmentation faults occur during the execution of the **python3 -m pip install --user ohos-build** command. - - -- **Possible Causes** - - pip is of an early version. - -- **Solutions** - - Upgrade pip. - - ``` - python3 -m pip install -U pip - ``` - - -## What should I do if the message "cannot import 'sysconfig' from 'distutils'" is displayed during hb installation? - -- **Symptom** - - The message "cannot import 'sysconfig' from 'distutils'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. - - -- **Possible Causes** - - The **distutils** module is unavailable. - -- **Solutions** - - Install **distutils**. - - ``` - sudo apt-get install python3.8-distutils - ``` - - -## What should I do if the message "module 'platform' has no attribute 'linux\_distribution'" is displayed during hb installation? - -- **Symptom** - - The message "module 'platform' has no attribute 'linux\_distribution'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. - - -- **Possible Causes** - - There is a compatibility issue of python3-pip. - -- **Solutions** - - Reinstall pip. - - ``` - sudo apt remove python3-pip - curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py - python get-pip.py - ``` - - -## What should I do if the message "Could not find a version that satisfies the requirement ohos-build" is displayed during hb installation? - -- **Symptom** - - The message "Could not find a version that satisfies the requirement ohos-build" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. - - -- **Possible Causes** - - The installation fails due to poor network connectivity. - -- **Solutions** - 1. Ensure that your computer has a good network connection. If the network connection is unstable, rectify the network fault and reinstall hb. - 2. If the network is functional, run the following commands to install hb by specifying a temporary PyPI source: - - ``` - python3 -m pip install -i https://pypi.tuna.tsinghua.edu.cn/simple ohos-build - ``` - - - -## What should I do if the message "ImportError: No module named apt\_pkg" is displayed during the execution of an unidentifiable command? - -- **Symptom** - - The message "ImportError: No module named apt\_pkg" is displayed when an unidentifiable command is executed on the Linux server. - - -- **Possible Causes** - - There is a compatibility issue of python3-apt. - -- **Solutions** - - Reinstall python3-apt. - - ``` - sudo apt-get remove python3-apt - sudo apt-get install python3-apt - ``` +- **[Fixing hb Installation Issues](quickstart-lite-faq-hb.md)** +- **[Fixing Compilation Issues](quickstart-lite-faq-compose.md)** +- **[Fixing Burning Issues](quickstart-lite-faq-burning.md)** diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup.md b/en/device-dev/quick-start/quickstart-lite-env-setup.md index d081b52d6f95bcfc5f8b79b5ae0e132560a575ab..fd013b163beb08a634b3f26569b21c42935d67ac 100644 --- a/en/device-dev/quick-start/quickstart-lite-env-setup.md +++ b/en/device-dev/quick-start/quickstart-lite-env-setup.md @@ -1,11 +1,417 @@ -# Environment Setup +# Setting Up Environments for the Mini and Small Systems -- **[Overview](quickstart-lite-env-setup-overview.md)** -- **[Setting Up Windows Development Environment](quickstart-lite-env-setup-windows.md)** +## System Requirements -- **[Setting Up Ubuntu Development Environment](quickstart-lite-env-setup-linux.md)** +- Windows: Windows 10 (64-bit) -- **[FAQs](quickstart-lite-env-setup-faqs.md)** +- Ubuntu: Ubuntu 18.04 or later; recommended memory: 16 GB or higher. +- User name: cannot contain Chinese characters +- DevEco Device Tool: 3.0 Release + + +## Installing Necessary Libraries and Tools + +To install the necessary libraries and tools, perform the following steps. + +On Ubuntu: + +1. Run the following **apt-get** command: + + ``` + sudo apt-get update && sudo apt-get install binutils binutils-dev git git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib gcc-arm-linux-gnueabi libc6-dev-i386 libc6-dev-amd64 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gnutls-bin python3.8 python3-pip ruby genext2fs device-tree-compiler make libffi-dev e2fsprogs pkg-config perl openssl libssl-dev libelf-dev libdwarf-dev u-boot-tools mtd-utils cpio doxygen liblz4-tool openjdk-8-jre gcc g++ texinfo dosfstools mtools default-jre default-jdk libncurses5 apt-utils wget scons python3.8-distutils tar rsync git-core libxml2-dev lib32z-dev grsync xxd libglib2.0-dev libpixman-1-dev kmod jfsutils reiserfsprogs xfsprogs squashfs-tools pcmciautils quota ppp libtinfo-dev libtinfo5 libncurses5-dev libncursesw5 libstdc++6 gcc-arm-none-eabi vim ssh locales + ``` + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, modify the preceding installation command based on the installation package name. Specifically: + > + > - Python 3.8 or a later version is required. This section uses Python 3.8 as an example. + > + > - Java 8 or later is required. This section uses Java 8 as an example. + +2. Set Python 3.8 as the default Python version. + + Check the location of Python 3.8: + + + ``` + which python3.8 + ``` + + Change python and python3 to python3.8. + + ``` + sudo update-alternatives --install /usr/bin/python python {python3.8 path} 1 #{Python3.8 path} is the location of Python 3.8 obtained in the previous step. + sudo update-alternatives --install /usr/bin/python3 python3 {python3.8 path} 1 #{Python3.8 path} is the location of Python 3.8 obtained in the previous step. + ``` + + +## Installing DevEco Device Tool + +To remotely access the Ubuntu environment through Windows to perform operations such as burning, you need to install DevEco Device Tool on both Windows and Ubuntu. + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> DevEco Device Tool is a one-stop integrated development environment (IDE) provided for developers of OpenHarmony-powered smart devices. It allows code editing, compiling, burning, and debugging. This document describes how to use DevEco Device Tool to remotely connect to the Ubuntu environment for burning and running. + + +### Installing DevEco Device Tool for Windows + +1. Download the [DevEco Device Tool 3.0 Release](https://device.harmonyos.com/cn/ide#download) Windows edition. + +2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**. + +3. Set the installation path of DevEco Device Tool and click **Next**. You are advised to install DevEco Device Tool in a non-system drive. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If you have installed DevEco Device Tool 3.0 Beta2 or earlier, the earlier version will be uninstalled before you install a new version. If the following error message is displayed during the uninstallation, click **Ignore** to continue the installation. This error does not affect the installation of the new version. + > + > ![en-us_image_0000001239275843](figures/en-us_image_0000001239275843.png) + + ![en-us_image_0000001270076961](figures/en-us_image_0000001270076961.png) + +4. When prompted, select the tools to be automatically installed. + + 1. On the **VSCode installation confirm** page, select **Install VScode 1.62.2 automatically** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Visual Studio Code 1.62 or later has been installed, this step will be skipped. + + ![en-us_image_0000001237801283](figures/en-us_image_0000001237801283.png) + + 2. On the displayed **Python select page**, select **Download from Huawei mirror** and click **Next**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Python 3.8 or 3.9 has been installed, select **Use one of compatible on your PC**. + + ![en-us_image_0000001193983334](figures/en-us_image_0000001193983334.png) + +5. In the dialog box shown below, click **Next** to download and install the tools.. + + ![en-us_image_0000001239634067](figures/en-us_image_0000001239634067.png) + +6. Wait for the DevEco Device Tool setup wizard to automatically install DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard. + + ![en-us_image_0000001239650137](figures/en-us_image_0000001239650137.png) + +7. From Visual Studio Code, access the DevEco Device Tool page. Now you can conduct your development in DevEco Device Tool. + + ![en-us_image_0000001225760456](figures/en-us_image_0000001225760456.png) + + +### Installing DevEco Device Tool for Ubuntu + +1. Make sure the Ubuntu shell environment is **bash**. + 1. Run the following command and check whether the command output is **bash**. If the command output is not **bash**, go to step 2. + + ``` + ls -l /bin/sh + ``` + + ![en-us_image_0000001226764302](figures/en-us_image_0000001226764302.png) + 2. Start the command-line tool, run the following command, enter your password, and select **No** to set **Ubuntu shell** to **bash**. + + ``` + sudo dpkg-reconfigure dash + ``` + + ![en-us_image_0000001243641075](figures/en-us_image_0000001243641075.png) + +2. Download the [DevEco Device Tool 3.0 Release Linux version](https://device.harmonyos.com/cn/ide#download). + +3. Decompress the DevEco Device Tool software package and assign permission on the folder obtained from the decompression. + + 1. Go to the directory where the DevEco Device Tool software package is stored and run the following command to decompress the software package. In the command, change **devicetool-linux-tool-3.0.0.400.zip** to the actual software package name. + + ``` + unzip devicetool-linux-tool-3.0.0.400.zip + ``` + 2. Open the folder of the decompressed software package and run the following command to grant the execute permission on the installation file. In the command, change **devicetool-linux-tool-3.0.0.400.sh** to the actual installation file name. + + ``` + chmod u+x devicetool-linux-tool-3.0.0.400.sh + ``` + +4. Run the following command to install DevEco Device Tool, where **devicetool-linux-tool-3.0.0.400.sh** indicates the installation file name. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > During the installation, the setup wizard automatically checks whether Python 3.8 or 3.9 is installed. If Python 3.8 or 3.9 is not installed, the setup wizard displays the "Do you want to continue?" message; enter **Y** to allow the setup wizard to automatically install Python. + + + ``` + sudo ./devicetool-linux-tool-3.0.0.400.sh + ``` + + Wait until the "Deveco Device Tool successfully installed." message is displayed. + + ![en-us_image_0000001198722374](figures/en-us_image_0000001198722374.png) + + +## Configuring Windows to Remotely Access the Ubuntu Build Environment + + +### Installing the SSH Service and Obtaining the IP Address for Remote Access + +1. In Ubuntu, open the Terminal tool and run the following command to install the SSH service: + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the command fails to be executed and the system displays a message indicating that the openssh-server and openssh-client depend on different versions, install the openssh-client of the required version (for example, **sudo apt-get install openssh-client=1:8.2p1-4**) as prompted on the command-line interface (CLI) and run the command again to install the openssh-server. + + + ``` + sudo apt-get install openssh-server + ``` + +2. Run the following command to start the SSH service: + + ``` + sudo systemctl start ssh + ``` + +3. Run the following command to obtain the IP address of the current user for remote access to the Ubuntu environment from Windows: + + ``` + ifconfig + ``` + + ![en-us_image_0000001215737140](figures/en-us_image_0000001215737140.png) + + +### Installing Remote SSH + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001239080359](figures/en-us-cn_image_0000001239080359.png), and search for **remote-ssh** in the Extension Marketplace. + + ![en-us_image_0000001193920448](figures/en-us_image_0000001193920448.png) + +2. Click **Install** to install Remote-SSH. After the installation is successful, **Remote-SSH** is displayed on the **INSTALLED** list. + + ![en-us_image_0000001238880335](figures/en-us_image_0000001238880335.png) + + +### Remotely Connecting to the Ubuntu Environment + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001238760373](figures/en-us_image_0000001238760373.png), and click + on the **REMOTE EXOPLORER** page. + + ![en-us_image_0000001215878922](figures/en-us_image_0000001215878922.png) + +2. In the **Enter SSH Connection Command** text box, enter **ssh *username@ip_address***, where *ip_address* indicates the IP address of the remote computer to be connected and *username* indicates the account name used for logging in to the remote computer. + + ![en-us_image_0000001215879750](figures/en-us_image_0000001215879750.png) + +3. In the displayed dialog box, select the default first option as the SSH configuration file. + + ![en-us_image_0000001260519729](figures/en-us_image_0000001260519729.png) + +4. Under **SSH TARGETS**, find the remote computer and click ![en-us_image_0000001194080414](figures/en-us_image_0000001194080414.png) to start it. + + ![en-us_image_0000001215720398](figures/en-us_image_0000001215720398.png) + +5. In the displayed dialog box, select **Linux**, select **Continue**, and enter the password for logging in to the remote computer. + + ![en-us_image_0000001215897530](figures/en-us_image_0000001215897530.png) + + After the connection is successful, the plug-in is automatically installed in the .vscode-server folder on the remote computer. After the installation is complete, reload Visual Studio Code in Windows as prompted. Then you can develop, compile, and burn source code in DevEco Device Tool on Windows. + + +### Registering the Public Key for Accessing the Ubuntu Environment + +After the preceding operations are complete, you can remotely connect to the Ubuntu environment through Windows for development. However, you need to frequently enter the remote connection password. To eliminate this need, you can use the SSH public key. + +1. Open the Git bash CLI and run the following command to generate an SSH public key. During command execution, perform operations as prompted. Set **username** and **ip** to the user name and IP address you use for connecting to the Ubuntu system. + + ``` + ssh-keygen -t rsa + ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip + ``` + + ![en-us_image_0000001271532317](figures/en-us_image_0000001271532317.png) + +2. In Visual Studio Code, click the remote connection setting button and open the **config** file. + + ![en-us_image_0000001226034634](figures/en-us_image_0000001226034634.png) + +3. In the **config** file, add the SSK key file information, as shown below. Then save the file. + + ![en-us_image_0000001270356233](figures/en-us_image_0000001270356233.png) + + +## Obtaining Source Code + +In the Ubuntu environment, perform the following steps to obtain the OpenHarmony source code: + + +### Preparations + +1. Register your account with Gitee. + +2. Register an SSH public key for access to Gitee. + +3. Install the git client and git-lfs. (Skip this step if these tools have been installed in Installing Required Libraries and Tools. ) + + Update the software source: + + ``` + sudo apt-get update + ``` + + Run the following command to install the tools: + + ``` + sudo apt-get install git git-lfs + ``` + +4. Configure user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +5. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +### Obtaining Source Code + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). + + +### Running prebuilts + + Go to the root directory of the source code and run the following script to install the compiler and binary tool: + +``` +bash build/prebuilts_download.sh +``` + + +## Installing the Compilation Tool + +For details about the functions of the OpenHarmony compilation and building module, see [Compilation and Building Guidelines](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-build.md). + +Perform the following steps in Ubuntu: + + +### Install hb. + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> To install a proxy, see [Configuring a Proxy](../quick-start/quickstart-lite-reference.md#configuring-a-proxy). + +1. Run the following command to install hb and update it to the latest version: + + ``` + pip3 install --user build/lite + ``` + +2. Set the environment variable. + + ``` + vim ~/.bashrc + ``` + + Copy the following command to the last line of the .bashrc file, save the file, and exit. + + ``` + export PATH=~/.local/bin:$PATH + ``` + + Update the environment variable. + + ``` + source ~/.bashrc + ``` + +3. Run the **hb -h** command in the source code directory. If the following information is displayed, the installation is successful: + + ``` + usage: hb + + OHOS build system + + positional arguments: + {build,set,env,clean} + build Build source code + set OHOS build settings + env Show OHOS build env + clean Clean output + + optional arguments: + -h, --help show this help message and exit + ``` + +> ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** +> - Run the following command to uninstall hb: +> +> ``` +> pip3 uninstall ohos-build +> ``` +> +> - If any issue occurs during the hb installation, see [FAQs](../quick-start/quickstart-lite-faq-hb.md) to troubleshoot. + + +### Install LLVM. This step is only required for OpenHarmony_v1.x. + +> ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** +> When downloading source code under the OpenHarmony_v1.x branches or tags, perform the operation procedure described in this section to install LLVM 9.0.0. +> +> When downloading source code under the Master or non-OpenHarmony_v1.x branches or tags, skip this section. hb will automatically download the latest version of LLVM. + +1. Start a Linux server. + +2. [Download LLVM](https://repo.huaweicloud.com/harmonyos/compiler/clang/9.0.0-36191/linux/llvm-linux-9.0.0-36191.tar) + +3. Decompress the LLVM installation package to **~/llvm**. + + ``` + tar -zxvf llvm.tar -C ~/ + ``` + +4. Set the environment variable. + + ``` + vim ~/.bashrc + ``` + + Copy the following command to the last line of the .bashrc file, save the file, and exit. + + + ``` + export PATH=~/llvm/bin:$PATH + ``` + +5. Validate the environment variable. + + ``` + source ~/.bashrc + ``` diff --git a/en/device-dev/quick-start/quickstart-lite-faq-burning.md b/en/device-dev/quick-start/quickstart-lite-faq-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..02fc1cfa341525b77efbe6391418ba52099b2525 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-faq-burning.md @@ -0,0 +1,142 @@ +# Fixing Burning Issues + + +## What should I do if Error: Opening COMxx: Access denied is displayed when I start burning + +- **Symptom** + + Error: Opening COMxx: Access denied is displayed after clicking Burn and selecting a serial port. + + **Figure 1** Failed to open the serial port + + ![en-us_image_0000001226634728](figures/en-us_image_0000001226634728.png) + +- **Possible Causes** + + The serial port is in use. + +- **Solution** + +1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel. + + **Figure 2** Checking whether the serial port is in use + + ![en-us_image_0000001226954644](figures/en-us_image_0000001226954644.png) + +2. Click the dustbin icon as shown below to disable the terminal using the serial port. + + **Figure 3** Disabling the terminal using the serial port + + ![en-us_image_0000001271234761](figures/en-us_image_0000001271234761.png) + +3. Click **Burn**, select the serial port, and start burning images again. + + **Figure 4** Restarting the burning task + + ![en-us_image_0000001271594765](figures/en-us_image_0000001271594765.png) + + +## What should I do when Windows-based PC failed to be connected to the board? + +- **Symptom** + + The file image cannot be obtained after clicking Burn and selecting a serial port. + + **Figure 5** Failed to obtain the file image due to network disconnection + + ![en-us_image_0000001271234757](figures/en-us_image_0000001271234757.png) + +- **Possible Causes** + + The board is disconnected from the Windows-based PC. + + Windows Firewall does not allow Visual Studio Code to access the network. + +- **Solution** + +1. Check whether the network cable is properly connected. + +2. Click **Windows Firewall**. + + **Figure 6** Network and firewall settings + + ![en-us_image_0000001226634732](figures/en-us_image_0000001226634732.png) + +3. Click **Firewall & network protection**, and on the displayed page, click **Allow an app through the firewall**. + + **Figure 7** Firewall & network protection + + ![en-us_image_0000001271354749](figures/en-us_image_0000001271354749.png) + +4. Select Visual Studio Code. + + **Figure 8** Selecting Visual Studio Code + + ![en-us_image_0000001271234765](figures/en-us_image_0000001271234765.png) + +5. Select the **Private** and **Public** network access rights for Visual Studio Code. + + **Figure 9** Allowing Visual Studio Code to access the network + + ![en-us_image_0000001271474585](figures/en-us_image_0000001271474585.png) + + +## What should I do when the image failed to be burnt? + +- **Symptom** + + The burning status is not displayed after clicking Burn and selecting a serial port. + +- **Possible Causes** + + The IDE is not restarted after the DevEco plug-in is installed. + +- **Solution** + + Restart the IDE. + + +## What should I do if no information is displayed through the serial port? (Hi3516) + +- **Symptom** + + The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**. + +- **Possible Cause 1** + + The serial port is connected incorrectly. + +- **Solution** + + Change the serial port number. + + Open Device Manager to check whether the serial port connected to the board is the same as the serial port connected to the terminal. If they are different, change the serial port number by following the instructions provided in " Error: Opening COMxx: Access denied". + +- **Possible Cause 2** + + The U-Boot of the board is damaged. + +- **Solution** + + Burn the U-Boot. + + If the fault persists after you perform the preceding operations, the U-Boot of the board may be damaged. You can burn the U-Boot by performing the following steps: + +1. Obtain the U-Boot file. + + > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** + > The U-Boot file of the two boards can be obtained from the following paths, respectively. + > + > Hi3516D V300: device\hisilicon\hispark_taurus\sdk_liteos\uboot\out\boot\u-boot-hi3516dv300.bin + > + > Hi3518E V300: device\hisilicon\hispark_aries\sdk_liteos\uboot\out\boot\u-boot-hi3518ev300.bin + +2. Burn the U-Boot file by following the procedures for burning a U-Boot file over USB. + + Select the U-Boot files of corresponding development boards for burning by referring to [Burning to Hi3516D V300](https://device.harmonyos.com/en/docs/documentation/guide/ide-hi3516-upload-0000001052148681)/[Burning to Hi3518E V300](https://device.harmonyos.com/en/docs/documentation/guide/ide-hi3518-upload-0000001057313128#section93591711580). + +3. Log in to the serial port after the burning is complete. + + **Figure 10** Information displayed through the serial port after the U-Boot file is burnt + + ![en-us_image_0000001271234753](figures/en-us_image_0000001271234753.png) diff --git a/en/device-dev/quick-start/quickstart-lite-faq-compose.md b/en/device-dev/quick-start/quickstart-lite-faq-compose.md new file mode 100644 index 0000000000000000000000000000000000000000..049a93c3df673f45143238fe84d54780cfc0329c --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-faq-compose.md @@ -0,0 +1,292 @@ +# Fixing Compilation Issues + + +## What should I do if the message "ImportError: No module named apt_pkg" is displayed during the execution of an unidentifiable command? + +- **Symptom** + + The message "ImportError: No module named apt_pkg" is displayed when an unidentifiable command is executed on the Linux server. + +- **Possible Causes** + + There is a compatibility issue of python3-apt. + +- **Solution** + + Reinstall python3-apt. + + + ``` + sudo apt-get remove python3-apt + sudo apt-get install python3-apt + ``` + + +## What should I do if the message indicating Python cannot be found is displayed during compilation and building? + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + -bash: /usr/bin/python: No such file or directory + ``` + +- **Possible Cause 1** + + Python is not installed. + +- **Solution** + + Run the following command to install Python. The following uses Python 3.8 as an example. + + + ``` + sudo apt-get install python3.8 + ``` + +- **Possible Cause 2** + + The soft link that points to the Python does not exist in the **usr/bin** directory. + + ![en-us_image_0000001271354745](figures/en-us_image_0000001271354745.png) + +- **Solution** + + Run the following commands to add a soft link: + + + ``` + # cd /usr/bin/ + # which python3 + # ln -s /usr/local/bin/python3 python + # python --version + ``` + + Example: + + ![en-us_image_0000001227114636](figures/en-us_image_0000001227114636.png) + + +## What should I do if the message indicating Python 3 cannot be found is displayed during compilation and building? + +- **Symptom** + + ![en-us_image_0000001227114640](figures/en-us_image_0000001227114640.png) + +- **Possible Causes** + + Python 3 is not installed. + +- **Solution** + + Run the following command to install Python 3: + + + ``` + sudo apt-get install python3.8 + ``` + + +## What should I do if the message "configure: error: no acceptable C compiler found in $PATH" is displayed during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + configure: error: no acceptable C compiler found in $PATH. See 'config.log' for more details + ``` + +- **Possible Causes** + + **gcc** is not installed. + +- **Solution** + + 1. Run the **apt-get install gcc** command to install **gcc** online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "-bash: make: command not found is displayed" during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + -bash: make: command not found + ``` + +- **Possible Causes** + + Make is not installed. + +- **Solution** + + 1. Run the **apt-get install make** command to install Make online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "No module named '_ctypes'" is displayed during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + ModuleNotFoundError: No module named '_ctypes' + ``` + +- **Possible Causes** + + **libffi** and **libffi-devel** are not installed. + +- **Solution** + + 1. Run the **apt-get install libffi* -y** command to install **libffi** and **libffi-devel** online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "No module named 'Crypto'" is displayed during the build process? + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + ModuleNotFoundError: No module named 'Crypto' + ``` + +- **Possible Causes** + + **Crypto** is not installed. + +- **Solution** + + Solution 1: Run the **pip3 install Crypto** command to install **Crypto** online. + + Method 2: Offline installation + + Download the source code from [PyPI](https://pypi.org/project/pycrypto/#files). + + ![en-us_image_0000001226794696](figures/en-us_image_0000001226794696.png) + + Save the source package to the Linux server, decompress the package, and run the **python3 setup.py install** command to install Crypto. + + After the preceding installation is complete, rebuild an environment. + + +## What should I do if the message "No module named 'ecdsa'" is displayed during the build process? (Hi3861) + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + ModuleNotFoundError: No module named 'ecdsa' + ``` + +- **Possible Causes** + + **ecdsa** is not installed. + +- **Solution** + + Solution 1: Run the **pip3 install ecdsa** command to install **ecdsa** online. + + Method 2: Offline installation + + Download the installation package from [PyPI](https://pypi.org/project/ecdsa/#files). + + ![en-us_image_0000001271594753](figures/en-us_image_0000001271594753.png) + + Save the installation package to the Linux server and run the **pip3 install ecdsa-0.15-py2.py3-none-any.whl** command to install ecdsa. + + After the preceding installation is complete, rebuild an environment. + + +## What should I do if the message "Could not find a version that satisfies the requirement six>=1.9.0" is displayed during the build process? (Hi3861) + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + Could not find a version that satisfies the requirement six>=1.9.0 + ``` + +- **Possible Causes** + + **six** is not installed. + +- **Solution** + + Solution 1: Run the **pip3 install six** command to install **six** online. + + Method 2: Offline installation + + Download the installation package from [PyPI](https://pypi.org/project/six/#files). + + ![en-us_image_0000001271474573](figures/en-us_image_0000001271474573.png) + + Save the source code to the Linux server and run the **pip3 install six-1.14.0-py2.py3-none-any.whl** command to install **six**. + + After the preceding installation is complete, rebuild an environment. + + +## What should I do if the message "cannot find -lgcc" is displayed during the build process? (Hi3861) + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + riscv32-unknown-elf-ld: cannot find -lgcc + ``` + +- **Possible Causes** + + The PATH is incorrectly written by **gcc_riscv32**. There is an extra slash (/). + + + ``` + ~/gcc_riscv32/bin/:/data/toolchain/ + ``` + +- **Solution** + + Modify the PATH by deleting the slash (/). + + + ``` + ~/gcc_riscv32/bin:/data/toolchain/ + ``` + + +## What should I do if an lsb_release error occurs during kconfiglib installation? (Hi3861) + +- **Symptom** + + The following error occurs during **kconfiglib** installation: + + + ``` + subprocess.CalledProcessError: Command '('lsb_release', '-a')' returned non-zero exit status 1. + ``` + +- **Possible Causes** + + The Python version matched with the **lsb_release** module is different from the current Python version. + +- **Solution** + + Run the **find / -name lsb_release** command, for example, **sudo rm -rf /usr/bin/lsb_release** to locate and delete **lsb_release**. diff --git a/en/device-dev/quick-start/quickstart-lite-faq-hb.md b/en/device-dev/quick-start/quickstart-lite-faq-hb.md new file mode 100644 index 0000000000000000000000000000000000000000..f70d8caa2fcad74a10961a3b4612ba5b82e390f4 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-faq-hb.md @@ -0,0 +1,71 @@ +# Fixing hb Installation Issues + + +## What should I do if garbled characters and segmentation faults occur during hb installation? + +- **Symptom** + Garbled characters and segmentation faults occur during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + pip is of an early version. + +- **Solution** + Upgrade pip. + + + ``` + python3 -m pip install -U pip + ``` + + +## What should I do if the message "cannot import 'sysconfig' from 'distutils'" is displayed during hb installation? + +- **Symptom** + The message "cannot import 'sysconfig' from 'distutils'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + The **distutils** module is unavailable. + +- **Solution** + Install distutils. + + + ``` + sudo apt-get install python3.8-distutils + ``` + + +## What should I do if the message "module 'platform' has no attribute 'linux_distribution'" is displayed during hb installation? + +- **Symptom** + The message "module 'platform' has no attribute 'linux_distribution'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + There is a compatibility issue of python3-pip. + +- **Solution** + Reinstall pip. + + + ``` + sudo apt remove python3-pip + curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py + python get-pip.py + ``` + + +## What should I do if the message "Could not find a version that satisfies the requirement ohos-build" is displayed during hb installation? + +- **Symptom** + The message "Could not find a version that satisfies the requirement ohos-build" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + The installation fails due to poor network connectivity. + +- **Solution** + 1. Ensure that your computer has a good network connection. If the network connection is unstable, rectify the network fault and reinstall hb. + 2. If the network is functional, run the following commands to install hb by specifying a temporary PyPI source: + + ``` + python3 -m pip install -i https://pypi.tuna.tsinghua.edu.cn/simple ohos-build + ``` diff --git a/en/device-dev/quick-start/quickstart-lite-ide-directory.md b/en/device-dev/quick-start/quickstart-lite-ide-directory.md new file mode 100644 index 0000000000000000000000000000000000000000..ba40d1a3798c96010c8ebd16a78d2ea9ed474013 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-ide-directory.md @@ -0,0 +1,25 @@ +## Getting Started with Mini and Small Systems (IDE Mode) +- [Mini and Small System Overview](quickstart-ide-lite-overview.md) + - Environment Preparation + - [Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-lite-env-setup-win-ubuntu.md) + - [Obtaining Source Code](quickstart-ide-lite-sourcecode-acquire.md) + - [Creating a Source Code Project](quickstart-ide-lite-create-project.md) + - Running a Hello World Program + - Hi3861 Development Board + - [Writing a Hello World Program](quickstart-ide-lite-steps-hi3861-application-framework.md) + - [Building](quickstart-ide-lite-steps-hi3861-building.md) + - [Burning](quickstart-ide-lite-steps-hi3861-burn.md) + - [Networking](quickstart-ide-lite-steps-hi3861-netconfig.md) + - [Debugging and Verification](quickstart-ide-lite-steps-hi3861-debug.md) + - [Running](quickstart-ide-lite-steps-hi3816-running.md) + - Hi3516 Development Board + - [Writing a Hello World Program](quickstart-ide-lite-steps-hi3516-application-framework.md) + - [Building](quickstart-ide-lite-steps-hi3516-building.md) + - [Burning](quickstart-ide-lite-steps-hi3516-burn.md) + - [Running](quickstart-ide-lite-steps-hi3516-running.md) + - Appendix + - Introduction to Development Boards + - [Introduction to the Hi3861 Development Board](quickstart-ide-lite-introduction-hi3861.md) + - [Introduction to the Hi3516 Development Board](quickstart-ide-lite-introduction-hi3516.md) + + - [Getting Started with Mini and Small Systems (Installation Package Mode)](quickstart-lite-package-directory.md) diff --git a/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md index 02efeb6e2d5d970a367e93388866d1025d360ac3..6d87304641a41e474ab7ba64a1d05bb52dc83a1b 100644 --- a/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md +++ b/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md @@ -1,37 +1,20 @@ -# Hi3516 Development Board - -## Introduction - -Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. - -**Figure 1** Hi3516D V300 front view -![](figures/hi3516d-v300-front-view.png "hi3516d-v300-front-view") - -## Development Board Specifications - -**Table 1** Specifications of the Hi3516 development board - - - - - - - - - - - - - -

Type

-

Specification

-

Processor and internal memory

-
  • Hi3516D V300
  • DDR3 1GB
  • 8 GB eMMC4.5
-

External components

-
  • Ethernet port
  • Audio and video
    • One voice input
    • One mono (AC_L) output, connected to a 3 W power amplifier (LM4871)
    • MicroHDMI (one HDMI 1.4)
    -
  • Camera
    • Sensor IMX335
    • M12 lens with a focal length of 4 mm and an aperture of 1.8
    -
  • Display
    • 2.35-inch LCD connector
    • 5.5-inch LCD connector
    -
  • External components and interfaces
    • microSD card interface
    • JTAG/I2S interface
    • ADC interface
    • Steer gear interface
    • Grove connector
    • USB2.0(Type C)
    • Three function keys: two custom keys and one update key
    • LED indicator (including green and red)
    -
-
+# Introduction to the Hi3516 Development Board + +## Overview + +Hi3516D V300 is a next-generation system on chip (SoC) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor (ISP), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. + + **Figure 1** Hi3516 front view + +![en-us_image_0000001227082182](figures/en-us_image_0000001227082182.png) + + +## Development Board Specifications + + **Table 1** Hi3516 specifications + +| Item| Description| +| -------- | -------- | +| Processor and internal memory| - Hi3516D V300 chip
- DDR3 1GB
- eMMC 4.5, 8 GB capacity| +| External components| - Ethernet port
- Audio and video
  - 1 voice input
  - 1 mono channel (AC_L) output, connected to a 3 W power amplifier (LM4871)
  - MicroHDMI (1-channel HDMI 1.4)
- Camera
  - Sensor IMX335
  - M12 lens, 4 mm focal length, and 1.8 aperture
- Display
  - LCD connector (2.35-inch)
  - LCD connector (5.5-inch)
- External components and ports
  - Memory card port
  - JTAG/I2S port
  - ADC port
  - Steering gear port
  - Grove connector
  - USB 2.0 (Type-C)
  - Three function keys, two user-defined keys, and one upgrade key
  - LED indicator, green or red| diff --git a/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md index 7c584129dc590dcd0613a56bc74cc2391842e63b..1801f9e585067605e051d92dc5f26ba7ff1adef1 100644 --- a/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md +++ b/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md @@ -1,146 +1,68 @@ -# Hi3861 Development Board - -## Introduction - -The Hi3861 WLAN module is a development board with 2 x 5 cm form factor. It contains a 2.4 GHz WLAN SoC that highly integrates the IEEE 802.11b/g/n baseband and radio frequency \(RF\) circuit. This module provides open and easy-to-use development and debugging environments for running OpenHarmony. - -**Figure 1** Appearance of Hi3861 WLAN module -![](figures/appearance-of-hi3861-wlan-module.png "appearance-of-hi3861-wlan-module") - -The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board. - -**Figure 2** Appearance of the Hi3861 mother board -![](figures/appearance-of-the-hi3861-mother-board.png "appearance-of-the-hi3861-mother-board") - -- The RF circuit includes modules such as the power amplifier \(PA\), low noise amplifier \(LNA\), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer. -- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing \(OFDM\) technology and is backward compatible with the direct sequence spread spectrum \(DSSS\) and complementary code keying \(CCK\) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol. -- The Hi3861 chip integrates the high-performance 32-bit microprocessor, hardware security engine, and various peripheral interfaces. The peripheral interfaces include the Synchronous Peripheral Interface \(SPI\), Universal Asynchronous Receiver & Transmitter \(UART\), the Inter Integrated Circuit \(I2C\), Pulse Width Modulation \(PWM\), General Purpose Input/Output \(GPIO\) interface, and Analog to Digital Converter \(ADC\). The Hi3861 chip also supports the high-speed Secure Digital Input/Output \(SDIO\) 2.0 interface, with a maximum clock frequency of 50 MHz. This chip has a built-in static random access memory \(SRAM\) and flash memory, so that programs can run independently or run from a flash drive. -- The Hi3861 chip applies to Internet of Things \(IoT\) devices such as smart home appliances. - - **Figure 3** Hi3861 functions - ![](figures/hi3861-functions.png "hi3861-functions") - - -## Resources and Constraints - -As the Hi3861 only offers 2 MB Flash and 352 KB RAM, use them efficiently when compiling code. - -## Development Board Specifications - -**Table 1** Hi3861 WLAN module specifications - - - - - - - - - - - - - - - - - - - - - - - - - -

Type

-

Description

-

General specifications

-
  • Operates over 1×1 2.4 GHz frequency band (ch1-ch14).
  • The physical layer (PHY) complies with the IEEE 802.11b/g/n protocol.
  • The media access control (MAC) layer complies with the IEEE802.11 d/e/h/i/k/v/w protocol.
-
  • Includes the built-in public address (PA) and local area network (LAN); integrates transmit-receive (Tx/Rx) switch and Balun.
  • Supports the station (STA) and access point (AP) modes. When the Hi3861 WLAN module functions as an AP, a maximum of six STAs are supported.
  • Supports WFA WPA, WFA WPA2 personal, and WPS2.0.
  • Supports three kinds of packet traffic arbiter (PTA) (2- , 3- , or 4-wire PTA), each of which coexists with the BT or BLE chip.
  • The input voltage ranges from 2.3 V to 3.6 V.
-
  • The input/output (I/O) power voltage can be 1.8 V or 3.3 V.
-
  • Supports self-calibration for RF hardware.
  • Performs with low power consumption:
    • Ultra deep sleep mode: 5 μA @ 3.3 V
    • DTIM1: 1.5 mA @ 3.3 V
    • DTIM3: 0.8 mA @ 3.3 V
    -
-

PHY features

-
  • Supports all data rates of the single antenna required by the IEEE802.11b/g/n protocol.
  • Supports a maximum rate of 72.2 Mbps@HT20 MCS7
  • Supports the standard bandwidth (20 MHz) and narrow bandwidth (5 MHz or 10 MHz).
  • Supports space-time block coding (STBC).
  • Supports short guard interval (Short-GI).
-

MAC features

-
  • Supports aggregate MAC service data unit (A-MPDU) and aggregate MAC protocol data unit (A-MSDU).
  • Supports block acknowledgment (Blk-ACK).
  • Supports quality of service (QoS), meeting customer's service requirements.
-

CPU subsystem

-
  • Integrates a high-performance 32-bit microprocessor with a maximum operating frequency of 160 MHz.
  • Includes built-in 352 KB SRAM and 288 KB ROM.
  • Includes a built-in 2 MB flash memory.
-

Peripheral interfaces

-
  • Include one SDIO interface, two SPI interfaces, two I2C interfaces, three UART interfaces, 15 GPIO interfaces, seven ADC inputs, six PWM interfaces, and one I2S interface (Note: These interfaces are all multiplexed.)
  • The frequency of the external primary crystal oscillator is 40 MHz or 24 MHz.
-

Other information

-
  • Package: QFN-32, 5 mm x 5 mm
  • Operating temperature: –40°C to +85°C
-
- -## Key Features - -OpenHarmony provides a series of available capabilities based on the Hi3861 platform. The following table describes the available key components. - -**Table 2** Key components - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Component

-

Description

-

wlan

-

Provides WLAN service, such as connecting to or disconnecting from a station or hotspot, and querying the state of a station or hotspot.

-

iot controller

-

Provides the capability of operating peripherals, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM and FLASH.

-

soft bus

-

Provides the capabilities of device discovery and data transmission in the distributed network.

-

hichainsdk

-

Provides the capability of securely transferring data between devices when they are interconnected.

-

huks

-

Provides capabilities of key management, encryption, and decryption.

-

system ability manager

-

Provides a unified OpenHarmony service development framework based on the service-oriented architecture.

-

bootstrap

-

Provides the entry identifier for starting a system service. When the system service management is started, the function identified by bootstrap is called to start a system service.

-

syspara

-

Provides capabilities of obtaining and setting system attributes.

-

utils

-

Provides basic and public capabilities, such as file operations and key-value (KV) storage management.

-

DFX

-

Provides the DFX capabilities, such as logging and printing.

-

XTS

-

Provides a set of OpenHarmony certification test suites.

-
+# Introduction to the Hi3861 Development Board + +## Overview + +Hi3861 is a 2 x 5 cm development board. It is a 2.4 GHz WLAN SoC chip that highly integrates the IEEE 802.11b/g/n baseband and radio frequency (RF) circuit. It supports OpenHarmony and provides an open and easy-to-use development and debugging environment. + + **Figure 1** Hi3861 development board + + ![en-us_image_0000001226634692](figures/en-us_image_0000001226634692.png) + +The Hi3861 development board can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board. + + **Figure 2** Hi3861 mother board + +![en-us_image_0000001226794660](figures/en-us_image_0000001226794660.png) + +- The RF circuit includes modules such as the power amplifier (PA), low noise amplifier (LNA), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer. + +- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing (OFDM) technology and is backward compatible with the direct sequence spread spectrum (DSSS) and complementary code keying (CCK) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol. + +- The Hi3861 chip integrates the high-performance 32-bit microprocessor, hardware security engine, and various peripheral interfaces. The peripheral interfaces include the Synchronous Peripheral Interface (SPI), Universal Asynchronous Receiver & Transmitter (UART), the Inter-Integrated Circuit (I2C), Pulse Width Modulation (PWM), General Purpose Input/Output (GPIO) interface, and Analog to Digital Converter (ADC). The Hi3861 chip also supports the high-speed Secure Digital Input/Output (SDIO) 2.0 interface, with a maximum clock frequency of 50 MHz. This chip has a built-in static random access memory (SRAM) and flash memory, so that programs can run independently or run from a flash drive. + +- The Hi3861 chip applies to Internet of Things (IoT) devices such as smart home appliances. + + **Figure 3** Functional block diagram of Hi3861 + + ![en-us_image_0000001226794688](figures/en-us_image_0000001226794688.png) + + +## Resources and Constraints + +The resources of the Hi3861 development board are limited. The entire board has a 2 MB flash memory and 352 KB RAM. When writing service code, pay attention to the resource usage efficiency. + + +## Development Board Specifications + + **Table 1** Hi3861 specifications + +| Item| Description| +| -------- | -------- | +| General specifications| - 1 x 1 2.4 GHz frequency band (ch1–ch14)
- PHY supports IEEE 802.11b/g/n.
- MAC supports IEEE802.11d/e/h/i/k/v/w.
- Built-in PA and LNA; integrated TX/RX switch and Balun
- Support for STA and AP modes. When functioning as an AP, it supports a maximum of 6 STAs.
- Support for WFA WPA/WPA2 personal and WPS2.0.
- 2/3/4-line PTA solution that coexists with BT/BLE chips.
- Input voltage range: 2.3 V to 3.6 V
- I/O power voltage: 1.8 V or 3.3 V.
- RF self-calibration
- Low power consumption:
  - Ultra Deep Sleep mode: 5 μA@3.3 V
  - DTIM1: 1.5 mA \@3.3V
  - DTIM3: 0.8 mA \@3.3V| +| PHY features| - Supports all data rates of the IEEE802.11b/g/n single antenna.
- Supported maximum rate: 72.2 Mbps\@HT20 MCS7
- 20 MHz standard bandwidth and 5 MHz/10 MHz narrow bandwidth.
-  STBC.
- Short-GI.| +| MAC features| - A-MPDU and A-MSDU.
- Blk-ACK.
- QoS to meet the quality requirements of different services.| +| CPU subsystem| -  High-performance 32-bit microprocessor with a maximum working frequency of 160 MHz.
- Embedded SRAM of 352 KB; ROM of 288 KB
- Embedded 2 MB flash memory| +| Peripheral ports| - One SDIO interface, two SPI interfaces, two I2C interfaces, three UART interfaces, 15 GPIO interfaces, seven ADC inputs, six PWM interfaces, and one I2S interface (Note: These interfaces are all multiplexed.)
- Frequency of the external main crystal: 40 MHz or 24 MHz| +| Others| - Package: QFN-32, 5 mm x 5 mm
- Working temperature: -40°C to +85°C| + + +## OpenHarmony Key Features + +OpenHarmony provides a wide array of available capabilities based on the Hi3861 platform. The following table describes the available key components. + + **Table 2** Key components of OpenHarmony + +| Component| Capability| +| -------- | -------- | +| WLAN| Provides the WLAN service capability. For example, connecting to or disconnecting from a station or hotspot, and querying the status of a station or hotspot.| +| IoT controller| Provides the capability of operating peripherals, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM and flash memory.| +| DSoftBus| Provides the capabilities of device discovery and data transmission in the distributed network.| +| hichainsdk| Provides the capability of securely transferring data between devices when they are interconnected.| +| huks| Provides capabilities of key management, encryption, and decryption.| +| System service management| Provides a unified OpenHarmony service development framework based on the service-oriented architecture.| +| Boot| Provides the entry identifier for starting a system service. When the system service management is started, the function identified by bootstrap is called to start a system service.| +| System attribute| Provides capabilities of obtaining and setting system attributes.| +| Base library| Provides the common basic library capability, including file operations and KV storage management.| +| DFX | Provides the DFX capability, such as logging and printing.| +| XTS | Provides a set of OpenHarmony certification test suites.| diff --git a/en/device-dev/quick-start/quickstart-lite-overview.md b/en/device-dev/quick-start/quickstart-lite-overview.md index 8a7a6ba8fdb2b61d099ce7b399c04efe6056f5d6..d3a580e6766caf3cb699088ffbb9d2f82575255b 100644 --- a/en/device-dev/quick-start/quickstart-lite-overview.md +++ b/en/device-dev/quick-start/quickstart-lite-overview.md @@ -1,6 +1,43 @@ -# Overview +# Mini and Small System Overview -The mini and small OpenHarmony systems are suitable for IoT devices with limited memory. This document describes the system development with three typical development boards: Hi3861 WLAN module, Hi3516D V300, and Hi3518E V300. -With this document, you will quickly get familiar with environment setup, build, burning, debugging, and simple app and driver development for mini and small systems. +## Introduction + +The OpenHarmony mini and small systems apply to devices with a reference memory greater than or equal to 128 KiB. This document helps you quickly get started for development of the OpenHarmony standard system, from environment setup to building, burning, and startup. + + +To accommodate different developer habits, OpenHarmony provides two modes for getting started with the standard system: + + +- IDE mode: DevEco Device Tool is used for one-stop development, covering dependency installation, building, burning, and running. + +- Installation package mode: Dependency download and installation as well as building operations are performed using commands. Burning and running are performed in DevEco Device Tool. OpenHarmony also provides the [Docker environment](../get-code/gettools-acquire.md), which can significantly simplify the environment configuration before compilation. You can build your source code in the Docker environment if you are more accustomed to using the installation package mode. + + +This document exemplifies how to use the installation package mode. For details about the IDE mode, see [Getting Started with Mini and Small Systems (IDE Mode)](../quick-start/quickstart-lite-ide-directory.md). + + +## Development Environment + +In the Windows+Ubuntu hybrid environment for OpenHarmony development: + +- Windows: used for source code development and burning. + +- Ubuntu: used for source code building. + +This document describes how to develop OpenHarmony in the Windows+Ubuntu environment. + + +## Development Boards + +In this document, two development board models are used as examples: Hi3861 and Hi3516D V300. For details about these development boards, see [Appendix](../quick-start/quickstart-lite-board-introduction.md). You can purchase the development board as required. + + +## Development Process + +Below you can see the quick start process for the development of the mini and small systems. + + **Figure 1** Quick start process for the development of the mini and small systems + + ![en-us_image_0000001271562257](figures/en-us_image_0000001271562257.png) diff --git a/en/device-dev/quick-start/quickstart-lite-package-directory.md b/en/device-dev/quick-start/quickstart-lite-package-directory.md new file mode 100644 index 0000000000000000000000000000000000000000..96f3578b058936d5f757e3cd0fa677257f5f4b9b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-package-directory.md @@ -0,0 +1,28 @@ +## Getting Started with Mini and Small Systems (Installation Package Mode) +- [Mini and Small System Overview](quickstart-lite-overview.md) +- [Environment Preparation](quickstart-lite-env-setup.md) +- Running a Hello World Program + - Hi3861 Development Board + - [Setting Up the Hi3861 Development Board Environment](quickstart-lite-steps-hi3861-setting.md) + - [Writing a Hello World Program](quickstart-lite-steps-hi3861-application-framework.md) + - [Building](quickstart-lite-steps-hi3861-building.md) + - [Burning](quickstart-lite-steps-hi3861-burn.md) + - [Networking](quickstart-lite-steps-hi3861-netconfig.md) + - [Debugging and Verification](quickstart-lite-steps-hi3861-debug.md) + - [Running](quickstart-lite-steps-hi3816-running.md) + - Hi3516 Development Board + - [Setting Up the Hi3516 Development Board Environment](quickstart-lite-steps-hi3516-setting.md) + - [Writing a Hello World Program](quickstart-lite-steps-hi3516-application-framework.md) + - [Building](quickstart-lite-steps-hi3516-building.md) + - [Burning](quickstart-lite-steps-hi3516-burn.md) + - [Running](quickstart-lite-steps-hi3516-running.md) +- FAQs + - [Fixing hb Installation Issues](quickstart-lite-faq-hb.md) + - [Fixing Compilation Issues](quickstart-lite-faq-compose.md) + - [Fixing Burning Issues](quickstart-lite-faq-burning.md) +- Appendix + - Introduction to Development Boards + - [Introduction to the Hi3861 Development Board](quickstart-lite-introduction-hi3861.md) + - [Introduction to the Hi3516 Development Board](quickstart-lite-introduction-hi3516.md) + - [Getting Started with Mini and Small Systems (IDE Mode)](quickstart-lite-ide-directory.md) + - [Reference](quickstart-lite-reference.md) diff --git a/en/device-dev/quick-start/quickstart-lite-reference.md b/en/device-dev/quick-start/quickstart-lite-reference.md new file mode 100644 index 0000000000000000000000000000000000000000..a1bb41dcfd09fd8b5c0419a11cbd8ca6b494c06a --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-reference.md @@ -0,0 +1,69 @@ +# Reference + + +## Using the build.sh Script to Build Source Code + + +1. Go to the root directory of the source code and run the build command. + + ``` + ./build.sh --product-name name --ccache + ``` + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > _name_ indicates the product name, for example, **Hi3516D V300** and **rk3568**. + +2. Check the build result. After the build is complete, the following information is displayed in the log: + + ``` + post_process + =====build name successful. + ``` + + Files generated during the build are stored in the **out/{device_name}/** directory, and the generated image is stored in the **out/{device_name}/packages/phone/images/** directory. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > For details about other modular compilation operations, see [Building a Standard System](../subsystems/subsys-build-standard-large.md). + + +## Configuring the Proxy + + +### Setting Up the Python Proxy + +1. Create a proxy configuration file. + + ``` + mkdir ~/.pipvim ~/.pip/pip.conf + ``` + +2. Add the following proxy information to the file, save the file, and exit: + + ``` + [global] + index-url = http:// Proxy URL + trusted-host = Trusted image path + timeout = 120 + ``` + + +### Setting Up the npm Proxy + +1. Create a proxy configuration file. + + ``` + vim ~/.npmrc + ``` + +2. Add the following proxy information to the file, save the file, and exit: + + ``` + Registry=http:// Proxy URL + strict-ssl=false + ``` + +3. Add the following content to the **.bashrc** file, save the file, and exit: + + ``` + export NPM_REGISTRY=http:// Proxy URL + source .bashrc + ``` diff --git a/en/device-dev/quick-start/quickstart-lite-sourcecode-acquire.md b/en/device-dev/quick-start/quickstart-lite-sourcecode-acquire.md new file mode 100644 index 0000000000000000000000000000000000000000..3e1f2ec05f12a3b1d1e51d162a6ecd98167b1f0c --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-sourcecode-acquire.md @@ -0,0 +1,50 @@ +# Obtaining Source Code + + +## Prerequisites + +1. Register your account with Gitee. +2. Register an SSH public key for access to Gitee. +3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +4. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +## How to Obtain + +>![](../public_sys-resources/icon-note.gif) **NOTE**
+>Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../get-code/../../release-notes/Readme.md). diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-application-framework.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-application-framework.md new file mode 100644 index 0000000000000000000000000000000000000000..798e092f3b6f5d0476c0adb12147d2f215f16e1c --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-application-framework.md @@ -0,0 +1,139 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + +The complete code directory is as follows: + + + +``` +applications/sample/hello +│── BUILD.gn +└── src + └── helloworld.c +``` + + +## How to Develop + +Perform the steps below in the source code directory: + +1. Create a directory and the program source code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program. + + + ``` + #include + + int main(int argc, char **argv) + { + printf("\n\n"); + printf("\n\t\tHello OHOS!\n"); + printf("\n\n\n"); + + return 0; + } + ``` + +2. Create a build file. + + Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + + ``` + import("//build/lite/config/component/lite_component.gni") + lite_component("hello-OHOS") { + features = [ ":helloworld" ] + } + executable("helloworld") { + output_name = "helloworld" + sources = [ "src/helloworld.c" ] + } + ``` + +3. Add a component. + + Modify the **build/lite/components/applications.json** file and add the configuration of **hello_world_app**. The following code snippet is a snippet of the **applications.json** file: The configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "components": [ + { + "component": "camera_sample_communication", + "description": "Communication related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/communication" + ], + "targets": [ + "//applications/sample/camera/communication:sample" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##start## + { + "component": "hello_world_app", + "description": "hello world samples.", + "optional": "true", + "dirs": [ + "applications/sample/hello" + ], + "targets": [ + "//applications/sample/hello:hello-OHOS" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##end## + { + "component": "camera_sample_app", + "description": "Camera related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/launcher", + "applications/sample/camera/cameraApp", + "applications/sample/camera/setting", + "applications/sample/camera/gallery", + "applications/sample/camera/media" + ], + ``` + +4. Modify the board configuration file. + + Modify the **vendor/hisilicon/hispark_taurus/config.json** file and add an entry of the **hello_world_app** component. The following code snippet is the configuration of the **applications** subsystem, the configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "subsystem": "applications", + "components": [ + { "component": "camera_sample_app", "features":[] }, + { "component": "camera_sample_ai", "features":[] }, + ##start## + { "component": "hello_world_app", "features":[] }, + ##end## + { "component": "camera_screensaver_app", "features":[] } + ] + }, + ``` diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-building.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-building.md new file mode 100644 index 0000000000000000000000000000000000000000..8e04ea7f63a0410f8b240c18efaebb7b7e6ac3bc --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-building.md @@ -0,0 +1,51 @@ +# Building + + +You can build source code with hb or the **build.sh** script. This section exemplifies how to build source code with hb. For details about how to build with the **build.sh** script, see [Building Source Code Using the build.sh Script](../quick-start/quickstart-lite-reference.md). + + +Go to the root directory of the source code and run the build command. + + +1. Set the build path. + + ``` + hb set + ``` + +2. Select the current path. + + ``` + . + ``` + +3. Select **ipcamera_hispark_taurus** under **hisilicon** and press **Enter**. + +4. Start building. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - To build a component (for example, **hello**), run the **hb build -T _ Target name _** command. + > + > - To build a product incrementally, run the **hb build** command. + > + > - To build a product from the scratch, run the **hb build -f** command. + > + > This example builds a product from the scratch. + + + ``` + hb build -f + ``` + + + **Figure 1** Hi3516 build settings + + ![en-us_image_0000001271594749](figures/en-us_image_0000001271594749.png) + +5. Check the build result. If "build success" is displayed, the building is successful. + > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** + > Paths to burning-related files: + > + > - Build result and log files: **out/hispark_taurus/ipcamera_hispark_taurus** + > + > - U-Boot file: **device/board/hisilicon/hispark_taurus/uboot/out/boot/u-boot-hi3516dv300.bin** diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-burn.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-burn.md new file mode 100644 index 0000000000000000000000000000000000000000..a8065841e5ffd0d3b72d2d6a52929118b7b13ffe --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-burn.md @@ -0,0 +1,104 @@ +# Burning + + +Hi3516D V300 supports burning through the USB port, network port, and serial port. This document describes how to burn source code through the USB port. The operations are performed in Windows. + + +### Importing Source Code + +After the building is complete, ensure that you can [remotely access the Ubuntu environment from Windows](../quick-start/quickstart-lite-env-setup.md). Then, perform the following steps to import the source code before burning: + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the target directory (in the Ubuntu environment) and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001271791385](figures/en-us_image_0000001271791385.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. Select **ipcamera_hispark_taurus**. + + ![en-us_image_0000001227711014](figures/en-us_image_0000001227711014.png) + +6. Click **Open** to open the project or source code. + + +### Burning + +After the source code is imported, perform the following steps: + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3516D V300 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216516128](figures/en-us_image_0000001216516128.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/documentation/guide/hi3516_hi3518-drivers-0000001050743695). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198566364](figures/en-us_image_0000001198566364.png) + +5. On the **hi3516dv300** tab page, set the burning options. + + - **upload_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time. + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-usb**. + + ![en-us_image_0000001223190441](figures/en-us_image_0000001223190441.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **fastboot**, **kernel**, **rootfs**, and **userfs**. + + 1. On the **hi3516dv300_fastboot** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001198889702](figures/en-us_image_0000001198889702.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001243290907](figures/en-us_image_0000001243290907.png) + + 3. Follow the same procedure to modify the information about the **kernel**, **rootfs**, and **userfs** files. + +7. When you finish modifying, click **Save** on the top. + +8. Go to **hi3516dv300** > **Upload** to start burning. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If this is the first time you burn source code to the Hi3516D V300 or Hi3518E V300 board, the message "not find the Devices" may be displayed. In this case, follow the steps in [Installing the USB Port Driver on the Hi3516D V300 or Hi3518E V300 Development Board](https://device.harmonyos.com/en/docs/documentation/guide/usb_driver-0000001058690393) and start burning again. + + ![en-us_image_0000001267231481](figures/en-us_image_0000001267231481.png) + +9. When the following information is displayed in the Terminal window, press and hold the reset button, remove and insert the USB cable, and release the reset button to start burning. + + ![en-us_image_0000001114129426](figures/en-us_image_0000001114129426.png) + + If the following message is displayed, it indicates that the burning is successful. + + ![en-us_image_0000001160649343](figures/en-us_image_0000001160649343.png) + +10. When the burning is successful, perform the operations in Running an Image to start the system. diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md index 75be0b182b2fcccf4c90bc17a46f041f5b437005..d6b25f08df948e01b76ffe7ffd9fca92a820f124 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md @@ -1,227 +1,51 @@ -# Running a Hello OHOS Program - -This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board. - -## Creating a Program - -1. Create a directory and the program source code. - - Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program. - - ``` - #include - - int main(int argc, char **argv) - { - printf("\n************************************************\n"); - printf("\n\t\tHello OHOS!\n"); - printf("\n************************************************\n\n"); - - return 0; - } - ``` - -2. Create a build file. - - Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows: - - ``` - import("//build/lite/config/component/lite_component.gni") - lite_component("hello-OHOS") { - features = [ ":helloworld" ] - } - executable("helloworld") { - output_name = "helloworld" - sources = [ "src/helloworld.c" ] - include_dirs = [] - defines = [] - cflags_c = [] - ldflags = [] - } - ``` - -3. Add a new component. - - Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\) - - ``` - { - "components": [ - { - "component": "camera_sample_communication", - "description": "Communication related samples.", - "optional": "true", - "dirs": [ - "applications/sample/camera/communication" - ], - "targets": [ - "//applications/sample/camera/communication:sample" - ], - "rom": "", - "ram": "", - "output": [], - "adapted_kernel": [ "liteos_a" ], - "features": [], - "deps": { - "components": [], - "third_party": [] - } - }, - ##start## - { - "component": "hello_world_app", - "description": "Communication related samples.", - "optional": "true", - "dirs": [ - "applications/sample/camera/apps" - ], - "targets": [ - "//applications/sample/camera/apps:hello-OHOS" - ], - "rom": "", - "ram": "", - "output": [], - "adapted_kernel": [ "liteos_a" ], - "features": [], - "deps": { - "components": [], - "third_party": [] - } - }, - ##end## - { - "component": "camera_sample_app", - "description": "Camera related samples.", - "optional": "true", - "dirs": [ - "applications/sample/camera/launcher", - "applications/sample/camera/cameraApp", - "applications/sample/camera/setting", - "applications/sample/camera/gallery", - "applications/sample/camera/media" - ], - ``` - -4. Modify the board configuration file. - - Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_taurus/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\) - - ``` - { - "subsystem": "applications", - "components": [ - { "component": "camera_sample_app", "features":[] }, - { "component": "camera_sample_ai", "features":[] }, - ##start## - { "component": "hello_world_app", "features":[] }, - ##end## - { "component": "camera_screensaver_app", "features":[] } - ] - }, - ``` - - -## Building - -If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/gettools-acquire.md#section107932281315). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation: - -``` -hb set (Set the building path.) -. (Select the current path.) -Select ipcamera_hispark_taurus@hisilicon and press Enter. -hb build -f (Start building.) -``` - -**Figure 1** Hi3516 settings -![](figures/hi3516-settings.png "hi3516-settings") - -The result files are generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory. - ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->The U-Boot file of the Hi3516D V300 development board can be obtained from the following path: device/hisilicon/hispark\_taurus/sdk\_liteos/uboot/out/boot/u-boot-hi3516dv300.bin - -## Burning - -The Hi3516 development board allows you to burn flash memory over the USB port, serial port, or network port. The following uses the network port burning as an example. - -### Burning Through the Network Port - -To burn Hi3516D V300 through the network port in the Windows or Linux environment: - -1. Connect the PC and the target development board through the serial port, network port, and power port. For details, see [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3516-0000001152041033). -2. Open Device Manager, then check and record the serial port number corresponding to the development board. - - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695). - - ![](figures/hi3516-record-the-serial-port-number.png) - -3. Open DevEco Device Tool, choose **QUICK ACCESS** \> **DevEco Home** \> **Projects**, and then click **Settings**. +# Running - ![](figures/hi3516-deveco-device-tool-setting.png) -4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings. -5. On the **hi3516dv300** tab page, configure the burning options. +## Starting the System - - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li142386399535). - - **upload\_protocol**: Select the burning protocol **hiburn-net**. - - **upload\_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time. - - ![](figures/hi3516-upload-options.png) - -6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Burning to Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075). -7. Set the IP address of the network port for burning: - - - **upload\_net\_server\_ip**: Select the IP address set in step [6](#en-us_topic_0000001056443961_li1558813168234), such as 192.168.1.2. - - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. - - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. - - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. - - ![](figures/ip-address-information.png) - -8. When you finish modifying, click **Save** in the upper right corner. -9. Open the project file and go to ![](figures/hi3516-deveco-device-tool-logo.png) \> **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start burning. - - ![](figures/hi3516-upload-start-burning.png) - -10. When the following message is displayed, power off the development board and then power it on. - - ![](figures/hi3516-restart-the-development-board.png) +After burning is completed, you need to configure the bootloader to run the OpenHarmony system. -11. If the following message is displayed, it indicates that the burning is successful. +1. In the Hi3516D V300 task, click **Configure bootloader (Boot OS)** to configure the bootloader. - ![](figures/hi3516-burning-succeeded-net.png) + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > The bootloader configuration in DevEco Device Tool has been adapted to Hi3516D V300. Therefore, no manual modification is needed. -12. When the burning is successful, perform the operations in Running an Image to start the system. + ![en-us_image_0000001209906547](figures/en-us_image_0000001209906547.png) -### Running an Image +2. When the message shown below is displayed, restart the development board. If "SUCCESS" is displayed, it indicates that the configuration is successful. -After burning is completed, you need to configure the bootloader to run the OpenHarmony system. + ![en-us_image_0000001210385161](figures/en-us_image_0000001210385161.png) -1. In the Hi3516D V300 task, click **Configure bootloader \(Boot OS\)** to configure the bootloader. +3. Click **Monitor** on the taskbar to start the serial port tool. - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >The bootloader configuration in DevEco Device Tool has been adapted to Hi3516D V300. Therefore, no manual modification is needed. + ![en-us_image_0000001164506870](figures/en-us_image_0000001164506870.png) - ![](figures/bootloader.png) +4. When the command output is displayed, press **Enter** until **OHOS #** is displayed, indicating that the system is started successfully. -2. When the message shown below is displayed, restart the development board. If **SUCCESS** is displayed, it indicates that the configuration is successful. + ![en-us_image_0000001198626874](figures/en-us_image_0000001198626874.png) - ![](figures/reset_success.png) -3. Click **Monitor** on the taskbar to start the serial port tool. +## Running a Hello World Program - ![](figures/monitor.png) +After the system is started, copy the executable file **helloworld** in the **out** directory of the source code to the **bin** directory, and run the Hello World program as follows: -4. Follow the onscreen instructions until **OHOS \#** is displayed, indicating that the system is started successfully. +1. Go to the **bin** directory on the startup page. + + ``` + cd bin + ``` - ![](figures/reboot_success.png) +2. Run the following command to run the **helloworld** program: + + ``` + ./helloworld + ``` + If the message "Hello World!" is displayed, the program runs successfully. -## Running a Program + ![en-us_image_0000001271234769](figures/en-us_image_0000001271234769.png) -In the root directory, run the **./bin/helloworld** command to operate the demo program. The compilation result is shown in the following example. -**Figure 2** Successful system startup and program execution -![](figures/successful-system-startup-and-program-execution.png "successful-system-startup-and-program-execution") +## Next +Congratulations! You have finished all steps! Proceed to [develop a sample camera with a screen](https://gitee.com/openharmony/docs/blob/master/en/device-dev/guide/device-camera.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md index 1569ed12128a4d642bc7c2717659cb61fc11419e..a53a2e0c900e633b3bba43c3163fcba0fc7da92d 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516-setting.md @@ -1,110 +1,30 @@ -# Setting Up the Environment +# Setting Up the Hi3516 Development Board Environment -## Environment Requirements -### Hardware +## Environment Requirements -- Hi3516D V300 IoT camera development board -- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3516D V300 development board through the USB-to-serial cable and network cable.\) -The following figure shows the hardware connections. +### Hardware -**Figure 1** Hi3516 hardware connections -![](figures/hi3516-hardware-connections.png "hi3516-hardware-connections") +- Hi3516D V300 IoT camera development board -### Software +- USB-to-serial cable and network cable (The Linux workstation is connected to the Hi3516D V300 development board through the USB-to-serial cable and network cable.) ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section182916865219). -The following table describes the tools required for setting up the general environment for a Linux server of the Hi3516 development board and how to obtain these tools. +### Software -**Table 1** Development tools and obtaining methods +The following table describes the tools required for setting up the general environment for a Linux server of the Hi3516D V300 development board. - - - - - - - - - - - - - - - - - - - - - - - -

Development Tool

-

Description

-

How to Obtain

-

bash

-

Processes CLI commands.

-

System configuration

-

Basic software package for compilation and building (required only for Ubuntu 20+)

-

Provides a basic software package for compilation and building.

-

Internet

-

dosfstools, mtools, and mtd-utils

-

Pack files.

-

apt-get install

-

Java virtual machine (JVM)

-

Compiles, debugs, and runs Java programs.

-

apt-get install

-
+ **Table 1** Linux server development tools and functions -## Installing Linux Build Tools +| Development Tool| Description| +| -------- | -------- | +| dosfstools, mtools, and mtd-utils| Pack files.| +| Java virtual machine (JVM)| Compiles, debugs, and runs Java programs.| ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **hc-gen**. ->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique. -### Changing Linux Shell to Bash - -Check whether bash is used as the shell. - -``` -ls -l /bin/sh -``` - -If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash. - -**Method 1:** Run the following command on the device and then click **No**. - -``` -sudo dpkg-reconfigure dash -``` - -**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link. - -``` -sudo rm -rf /bin/sh -sudo ln -s /bin/bash /bin/sh -``` - -### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\) - -Install the software. - -``` -sudo apt-get install build-essential gcc g++ make zlib* libffi-dev -``` - -### Installing File Packing Tools and JVM - -1. Start a Linux server. -2. Install the dosfstools, mtools, mtd-utils, Java Runtime Environment \(JRE\), and Java SDK. - - ``` - sudo apt-get install dosfstools mtools mtd-utils default-jre default-jdk - ``` +## Installing Linux Build Tools +Hi3516D V300 depends on the following tools: dosfstools, mtools, mtd-utils, Java Runtime Environment (JRE), and Java SDK. +These tools have been installed in [Installing Necessary Libraries and Tools](../quick-start/quickstart-lite-env-setup.md#installing-necessary-libraries-and-tools). diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3516.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3516.md index 182823260b644009a75d7b1391f51ea9a7635923..0f6d8e0c88d63e24187add3cc4478b673179c174 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-hi3516.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3516.md @@ -1,11 +1,13 @@ -# Hi3516 +# Hi3516 Development Board -- **[Setting Up the Environment](quickstart-lite-steps-hi3516-setting.md)** -- **[Running a Hello OHOS Program](quickstart-lite-steps-hi3516-running.md)** -- **[Developing a Driver](quickstart-lite-steps-hi3516-program.md)** +- **[Setting Up the Hi3516 Development Board Environment](quickstart-lite-steps-hi3516-setting.md)** -- **[FAQs](quickstart-lite-steps-hi3516-faqs.md)** +- **[Writing a Hello World Program](quickstart-lite-steps-hi3516-application-framework.md)** +- **[Building](quickstart-lite-steps-hi3516-building.md)** +- **[Burning](quickstart-lite-steps-hi3516-burn.md)** + +- **[Running](quickstart-lite-steps-hi3516-running.md)** diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3816-running.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3816-running.md new file mode 100644 index 0000000000000000000000000000000000000000..4628c9d700b307c2f9013f587688a1f288cf1a40 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3816-running.md @@ -0,0 +1,19 @@ +# Running + + +## Viewing Execution Result + +After the sample code is compiled, burnt, run, and debugged, restart the development board. If the following messages are displayed, the image is running correctly: + + +``` +ready to OS start +FileSystem mount ok. +wifi init success! +[DEMO] Hello world. +``` + + +## Next + +Congratulations! You have finished all steps! Proceed to [develop a sample WLAN product](https://gitee.com/openharmony/docs/blob/master/en/device-dev/guide/device-wlan.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-application-framework.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-application-framework.md new file mode 100644 index 0000000000000000000000000000000000000000..f3de1522e47257bf0b3f0a644b945c5cc629d87f --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-application-framework.md @@ -0,0 +1,141 @@ +# Writing a Hello World Program + + +The following exemplifies how to create a program by modifying the source code. The created program outputs the message "Hello world." Perform the steps below in the source code directory. + + +1. Determine the directory structure. + + Before compiling a service, you must create a directory (or a directory structure) in **./applications/sample/wifi-iot/app** to store source code files. + + For example, add the **my_first_app** service to the **app** directory, where **hello_world.c** is the service code and **BUILD.gn** is the compilation script. The directory structure is shown as follows: + + + ``` + . + └── applications + └── sample + └── wifi-iot + └── app + └── my_first_app + │── hello_world.c + └── BUILD.gn + ``` + +2. Write the service code. + + Create the **hello_world.c** file in **./applications/sample/wifi-iot/app/my_first_app**. Then, create the service entry function **HelloWorld** in **hello_world.c** and implement service logic. Call **SYS_RUN()** of OpenHarmony to start the service. (**SYS_RUN** is defined in the **ohos_init.h** file.) + + ``` + #include + #include "ohos_init.h" + #include "ohos_types.h" + + void HelloWorld(void) + { + printf("[DEMO] Hello world.\n"); + } + SYS_RUN(HelloWorld); + ``` + +3. Compile the **BUILD.gn** file for building services into a static library. + + Create the **BUILD.gn** file in **./applications/sample/wifi-iot/app/my_first_app** and configure the file as follows: + + The **BUILD.gn** file consists of three parts, including target, source file, and header file path. You need to fill in all of these parts. + + + ``` + static_library("myapp") { + sources = [ + "hello_world.c" + ] + include_dirs = [ + "//utils/native/lite/include" + ] + } + ``` + + - Specify the compilation result named **libmyapp.a** in **static_library**. You can fill in this part based on your need. + - Specify the .c file on which a file depends and its path in **sources**. The path that contains **//** represents an absolute path (the code root path). The path that does not contain **//** is a relative path. + - Specify the path of .h file on which **sources** depends in **include_dirs**. + +4. Add a component. + + Modify the **build/lite/components/applications.json** file and add the configuration of **hello_world_app**. The following code snippet is a snippet of the **applications.json** file: The configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "components": [ + { + "component": "camera_sample_communication", + "description": "Communication related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/communication" + ], + "targets": [ + "//applications/sample/camera/communication:sample" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_a" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##start## + { + "component": "hello_world_app", + "description": "hello world samples.", + "optional": "true", + "dirs": [ + "applications/sample/wifi-iot/app/my_first_app" + ], + "targets": [ + "//applications/sample/wifi-iot/app/my_first_app:myapp" + ], + "rom": "", + "ram": "", + "output": [], + "adapted_kernel": [ "liteos_m" ], + "features": [], + "deps": { + "components": [], + "third_party": [] + } + }, + ##end## + { + "component": "camera_sample_app", + "description": "Camera related samples.", + "optional": "true", + "dirs": [ + "applications/sample/camera/launcher", + "applications/sample/camera/cameraApp", + "applications/sample/camera/setting", + "applications/sample/camera/gallery", + "applications/sample/camera/media" + ], + ``` + +5. Modify the board configuration file. + + Modify the **vendor/hisilicon/hispark_pegasus/config.json** file and add an entry of the **hello_world_app** component. The following code snippet is the configuration of the **applications** subsystem, the configuration between \#\#start\#\# and \#\#end\#\# is new. (\#\#start\#\# and \#\#end\#\# are only used to identify the location. After the configuration is complete, delete these lines.) + + + ``` + { + "subsystem": "applications", + "components": [ + ##start## + { "component": "hello_world_app", "features":[] }, + ##end## + { "component": "wifi_iot_sample_app", "features":[] } + ] + }, + ``` diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-building.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-building.md new file mode 100644 index 0000000000000000000000000000000000000000..211c63049209ec389bba8eac45a875eaa3e6f355 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-building.md @@ -0,0 +1,47 @@ +# Building + + +You can build source code with hb or the **build.sh** script. This section exemplifies how to build source code with hb. For details about how to build with the **build.sh** script, see [Building Source Code Using the build.sh Script](../quick-start/quickstart-lite-reference.md). + + +Go to the root directory of the source code in the Ubuntu environment and perform the following steps: + + +1. Set the build path. + + ``` + hb set + ``` + +2. Select the current path. + + ``` + . + ``` + +3. Select **wifiiot_hispark_pegasus** under **hisilicon** and press **Enter**. + +4. Start building. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - To build a component (for example, **hello**), run the **hb build -T _ Target name _** command. + > + > - To build a product incrementally, run the **hb build** command. + > + > - To build a product from the scratch, run the **hb build -f** command. + > + > This example builds a product from the scratch. + + + ``` + hb build -f + ``` + + **Figure 1** Hi3861 build settings + + ![en-us_image_0000001226634716](figures/en-us_image_0000001226634716.png) + +5. Check the build result. If "build success" is displayed, the building is successful. + + > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** + > The build result and log files are stored in **out/hispark_pegasus/wifiiot_hispark_pegasus**. diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-burn.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-burn.md new file mode 100644 index 0000000000000000000000000000000000000000..41c5b7ae4154042585c3dc5cb075ecaf315dc935 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-burn.md @@ -0,0 +1,90 @@ +# Burning + + +Burn the source code to Hi3861 through the serial port in Windows. + + +### Importing Source Code + +After the building is complete, ensure that you can [remotely access the Ubuntu environment from Windows](../quick-start/quickstart-lite-env-setup.md). Then, perform the following steps to import the source code before burning: + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the target directory (in the Ubuntu environment) and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001227549226](figures/en-us_image_0000001227549226.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. Select **wifiiot_hispark_pegasus**. + + ![en-us_image_0000001272109325](figures/en-us_image_0000001272109325.png) + +6. Click **Open** to open the project or source code. + + +### Burning + +After the source code is imported, perform the following steps: + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3861 V100 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216274840](figures/en-us_image_0000001216274840.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on Hi3861 V100](https://device.harmonyos.com/en/docs/documentation/guide/hi3861-drivers-0000001058153433). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198943768](figures/en-us_image_0000001198943768.png) + +5. On the **hi3861** tab page, set the burning options. + + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-serial**. + - **upload_partitions**: Select the files to be burnt. **hi3861_app** is selected by default. + + ![en-us_image_0000001243704061](figures/en-us_image_0000001243704061.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. + + On the **hi3861_app** tab page, select **partition_bin** from **New Option**, and set the path of the file to be burnt. + + ![en-us_image_0000001260919759](figures/en-us_image_0000001260919759.png) + +7. When you finish modifying, click **Save** on the top. + +8. Click **Open** to open the project file. Then, choose **PROJECT TASKS** > **hi3861** > **Upload** to start burning. + + ![en-us_image_0000001216440138](figures/en-us_image_0000001216440138.png) + +9. When the following information is displayed, press the RST button on the development board to restart it. + + ![en-us_image_0000001198466090](figures/en-us_image_0000001198466090.png) + +10. Wait until the burning is complete. When the following message is displayed, the burning is successful. + + ![en-us_image_0000001216761476](figures/en-us_image_0000001216761476.png) diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-debug.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-debug.md new file mode 100644 index 0000000000000000000000000000000000000000..91dca25c30cb92ee499566bfe562b73c89987c48 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-debug.md @@ -0,0 +1,65 @@ +# Debugging and Verification + + +When the burning and networking are complete, you can use either of the following methods to debug and verify whether the source code has been burnt correctly: + + +1. Using printf to print logs + +2. Using ASM files to locate panic issues + + +As the example used here is simple, we use the printf method. The following describes the two methods in detail. + + +## printf + +Add the printf function to the code, which helps print data to the serial port. You can add log printing in key service paths or service exception locations, as shown in the following figure. + + +``` +void HelloWorld(void) +{ + printf("[DEMO] Hello world.\n"); +} +``` + + +## Using ASM Files to Locate Issues + + When the system exits abnormally, the call stack information about the abnormal exit is displayed on the serial port. Analyze the displayed information to troubleshoot and pinpoint issues. + +``` +=======KERNEL PANIC======= +**Call Stack* +Call Stack 0 -- 4860d8 addr:f784c +Call Stack 1 -- 47b2b2 addr:f788c +Call Stack 2 -- 3e562c addr:f789c +Call Stack 3 -- 4101de addr:f78ac +Call Stack 4 -- 3e5f32 addr:f78cc +Call Stack 5 -- 3f78c0 addr:f78ec +Call Stack 6 -- 3f5e24 addr:f78fc +Call Stack end*** +``` + +To analyze the call stack information, the **Hi3861_wifiiot_app.asm** file is required. This file records the symbol addresses of the functions in the code in the flash memory and the disassembly information. The ASM file is built and output together with the version software package and is stored in the **./out/wifiiot/** directory. + +1. (Optional) Save the call stack information to a TXT file for editing. + +2. Open the asm file, search for the addresses in CallStack, and list the corresponding function names. Generally, you only need to find the functions matching the first several stacks to locate issues. + + ``` + Call Stack 0 -- 4860d8 addr:f784c -- WadRecvCB + Call Stack 1 -- 47b2b2 addr:f788c -- wal_sdp_process_rx_data + Call Stack 2 -- 3e562c addr:f789c + Call Stack 3 -- 4101de addr:f78ac + Call Stack 4 -- 3e5f32 addr:f78cc + Call Stack 5 -- 3f78c0 addr:f78ec + Call Stack 6 -- 3f5e24 addr:f78fc + ``` + +3. Based on the call stack information, we can conclude that an exception occurs in the **WadRecvCB** function. + + ![en-us_image_0000001271354733](figures/en-us_image_0000001271354733.png) + +4. Check and modify the code. diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-netconfig.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-netconfig.md new file mode 100644 index 0000000000000000000000000000000000000000..690eb4c1726e7fdb3238013e51ca5119031c760b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-netconfig.md @@ -0,0 +1,44 @@ +# Networking + + +After completing compilation and burning, perform the following to connect the Hi3861 WLAN module to the Internet using AT commands. + + +1. Click the icon of **DevEco: Serial Monitor** at the bottom of DevEco Device Tool to keep the connection between the Windows workstation and the WLAN module. + + **Figure 1** Opening the DevEco Device Tool serial port + + ![en-us_image_0000001227114644](figures/en-us_image_0000001227114644.png) + +2. Reset the Hi3861 WLAN module. The message **ready to OS start** is displayed on the **TERMINAL** panel, indicating that the WLAN module is started successfully. + + **Figure 2** Successful resetting of the Hi3861 WLAN module + + ![en-us_image_0000001226794704](figures/en-us_image_0000001226794704.png) + +3. Run the following AT commands in sequence via the serial terminal to start the STA mode, connect to the specified AP, and enable Dynamic Host Configuration Protocol (DHCP). + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > After the development board is started, the serial port prints the test case information. Run the AT command after the test case information is printed. Otherwise, the AT command will be overwritten by the test case information. + + + + ``` + AT+STARTSTA # Start the STA mode. + AT+SCAN # Scan for available APs. + AT+SCANRESULT # Display the scanning result. + AT+CONN="SSID",,2,"PASSWORD" # Connect to the specified AP. (SSID and PASSWORD represent the name and password of the hotspot to be connected, respectively.) + AT+STASTAT # View the connection result. + AT+DHCP=wlan0,1 # Request the IP address of wlan0 from the AP using DHCP. + ``` + +4. Check whether the Hi3861 WLAN module is properly connected to the gateway, as shown in the following figure. + + ``` + AT+IFCFG # View the IP address assigned to an interface of the module. + AT+PING=X.X.X.X # Check the connectivity between the module and the gateway. Replace X.X.X.X with the actual gateway address. + ``` + + **Figure 3** Successful networking of the Hi3861 WLAN module + + ![en-us_image_0000001226954648](figures/en-us_image_0000001226954648.png) diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md index e1a6adeb73abd9b3c478696aabc6cef3632041f0..898cd84486258dd73cd18646c9e327fe8ba3c423 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861-setting.md @@ -1,346 +1,263 @@ -# Setting Up the Environment - -## Environment Requirements - -### Hardware - -- Linux compile server -- Windows workstation \(host computer\) -- Hi3861 WLAN module -- USB Type-C cable used to connect the Windows workstation to Hi3861 WLAN module - -The following figure shows the hardware connections. - -**Figure 1** Hi3861 hardware connections -![](figures/hi3861-hardware-connections.png "hi3861-hardware-connections") - -### Software - ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->The following part describes how to install tools using installation packages. If you use Docker to set up the build environment, you only need to install the Windows workstation described in [Table 1](#table6299192712513). - -The following table lists the tools required for the Hi3861 development board. - -**Table 1** Required tools - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Platform

-

Development Tool

-

Description

-

How to Obtain

-

Linux server

-

Basic software package for compilation and building (required only for Ubuntu 20+)

-

Provides a basic software package for compilation and building.

-

Internet

-

Linux server

-

SCons 3.0.4+

-

Executes script compilation.

-

Internet

-

Linux server

-

Python modules: setuptools, Kconfiglib, PyCryptodome, six, and ecdsa

-

Executes script compilation.

-

Internet

-

Linux server

-

gcc riscv32

-

Executes script compilation.

-

Internet

-

Windows workstation

-

CH341SER.EXE

-

USB-to-Serial adapter driver

-

http://www.wch-ic.com/search?t=downloads&q=ch340g

-
- -## Installing Linux Build Tools - ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **gcc\_riscv32**. ->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **gcc\_riscv32**. When installing the compilation tool, ensure that its environment variable path is unique. - -### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\) - -Install the software. - -``` -sudo apt-get install build-essential gcc g++ make zlib* libffi-dev -``` - -### Installing Scons - -1. Start a Linux server. -2. Install the SCons installation package. +# Setting Up the Hi3861 Development Board Environment - ``` - python3 -m pip install scons - ``` -3. Check whether the installation is successful. +## Environment Requirements - ``` - scons -v - ``` - **Figure 2** Successful installation \(SCons version requirement: 3.0.4 or later\) - ![](figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png "successful-installation-(scons-version-requirement-3-0-4-or-later)") +### Hardware +- Linux workstation -### Installing Python Modules +- Hi3861 WLAN module -1. Install setuptools. +- USB Type-C cable used to connect the Linux workstation to Hi3861 development board - ``` - pip3 install setuptools - ``` -2. Install the GUI menuconfig tool \(Kconfiglib\). You are advised to install Kconfiglib 13.2.0 or later. - - **Command line:** +### Software - ``` - sudo pip3 install kconfiglib - ``` - - **Installation package:** - 1. Download the **.whl** file \(for example, **kconfiglib-13.2.0-py2.py3-none-any.whl**\). +The following table lists the tools required by the Hi3861 WLAN module. - Download path: [https://pypi.org/project/kconfiglib\#files](https://pypi.org/project/kconfiglib#files) - 1. Install the **.whl** file. + **Table 1 Tools required by the Hi3861 WLAN module - ``` - sudo pip3 install kconfiglib-13.2.0-py2.py3-none-any.whl - ``` +| Development Tool| Description| +| -------- | -------- | +| SCons3.0.4+ | Executes script compilation.| +| Python modules: setuptools, Kconfiglib, PyCryptodome, six, and ecdsa| Executes script compilation.| +| gcc riscv32 | Executes script compilation.| -3. Install **PyCryptodome** using either of the following methods: +## Installing the Compilation Tools - Install the Python component packages on which the file signature depends, including PyCryptodome, six, and ecdsa. As the installation of **ecdsa** depends on that of **six**, install **six** first. +Perform the following steps to install the necessary tools: - - **Command line:** - ``` - sudo pip3 install pycryptodome - ``` +### Installing Scons - - **Installation package:** - 1. Download the **.whl** file \(for example, **pycryptodome-3.9.9-cp38-cp38-manylinux1\_x86\_64.whl**\). +1. Run the following command to install the SCons installation package: + + ``` + python3 -m pip install scons + ``` - Download path: [https://pypi.org/project/pycryptodome/\#files](https://pypi.org/project/pycryptodome/#files) +2. Run the following command to check whether SCons is successfully installed. If the installation is successful, the query result as shown in Figure 1 is displayed. + + ``` + scons -v + ``` - 1. Install the **.whl** file. + **Figure 1** Successful SCons installation (the version must be 3.0.4 or later) - ``` - sudo pip3 install pycryptodome-3.9.9-cp38-cp38-manylinux1_x86_64.whl - ``` + ![en-us_image_0000001271234749](figures/en-us_image_0000001271234749.png) -4. Install **six** using either of the following methods: - - **Command line:** +### Installing Python Modules - ``` - sudo pip3 install six --upgrade --ignore-installed six - ``` +1. Install setuptools. + + ``` + pip3 install setuptools + ``` - - **Installation package:** - 1. Download the **.whl** file, for example, **six-1.12.0-py2.py3-none-any.whl**. +2. Install the GUI menuconfig tool (Kconfiglib). You are advised to install Kconfiglib 13.2.0 or later. - Download path: [https://pypi.org/project/six/\#files](https://pypi.org/project/six/#files) + - Command line: + + ``` + sudo pip3 install kconfiglib + ``` - 1. Install the **.whl** file. + - Installation package: - ``` - sudo pip3 install six-1.12.0-py2.py3-none-any.whl - ``` + 1. Download the .whl file, for example, **kconfiglib-13.2.0-py2.py3-none-any.whl**. + Download path: [https://pypi.org/project/kconfiglib#files](https://pypi.org/project/kconfiglib#files) -5. Install **ecdsa** using either of the following methods: - - **Command line:** + 2. Install the .whl file. + + ``` + sudo pip3 install kconfiglib-13.2.0-py2.py3-none-any.whl + ``` - ``` - sudo pip3 install ecdsa - ``` +3. Install PyCryptodome using either of the following methods: - - **Installation package:** - 1. Download the **.whl** file, for example, **ecdsa-0.14.1-py2.py3-none-any.whl**. + Install the Python component packages on which the file signature depends, including **PyCryptodome**, **six**, and **ecdsa**. As the installation of **ecdsa** depends on that of **six**, install **six** first. - Download path: [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files) + - Command line: + + ``` + sudo pip3 install pycryptodome + ``` + + - Installation package: - 1. Install the **.whl** file. + 1. Download the .whl file , for example, **pycryptodome-3.9.9-cp38-cp38-manylinux1_x86_64.whl**. - ``` - sudo pip3 install ecdsa-0.14.1-py2.py3-none-any.whl - ``` + Download path: [https://pypi.org/project/pycryptodome/#files](https://pypi.org/project/pycryptodome/#files) + 2. Install the .whl file. + + ``` + sudo pip3 install pycryptodome-3.9.9-cp38-cp38-manylinux1_x86_64.whl + ``` +4. Install **six** using either of the following methods: + - Command line: + + ``` + sudo pip3 install six --upgrade --ignore-installed six + ``` -### Installing gcc\_riscv32 \(Compiler Toolchain for WLAN Module\) + - Installation package: ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->- The Hi3861 platform supports only the static link of the libgcc library. The dynamic link is not recommended because version 3 of the GNU General Public License \(GPLv3\) will be polluted during commercial distribution. ->- Steps 2 to 15 of the following procedure are used to build the **gcc\_riscv32** image. You can and skip these steps and directly [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz). + 1. Download the .whl file, for example, **six-1.12.0-py2.py3-none-any.whl**. -1. Start a Linux server. -2. Install the **GCC**, **G++**, **Bison**, **Flex**, **Makeinfo** tools to ensure that the toolchain can be correctly compiled. + Download path: [https://pypi.org/project/six/#files](https://pypi.org/project/six/#files) - ``` - sudo apt-get install gcc g++ flex bison texinfo - ``` + 2. Install the .whl file. + + ``` + sudo pip3 install six-1.12.0-py2.py3-none-any.whl + ``` -3. Download the RISC-V GNU toolchain. +5. Install **ecdsa** using either of the following methods: - ``` - git clone --recursive https://gitee.com/mirrors/riscv-gnu-toolchain.git - ``` + - Command line: + + ``` + sudo pip3 install ecdsa + ``` -4. Open the **riscv-gnu-toolchain** folder and delete empty folders to prevent conflicts during the download of **Newlib**, **Binutils**, and **GCC**. + - Installation package: - ``` - cd riscv-gnu-toolchain && rm -rf riscv-newlib && rm -rf riscv-binutils && rm -rf riscv-gcc - ``` + 1. Download the .whl file, for example, **ecdsa-0.14.1-py2.py3-none-any.whl**. -5. Download RISC-V Newlib 3.0.0. + Download path: [https://pypi.org/project/ecdsa/#files](https://pypi.org/project/ecdsa/#files) - ``` - git clone -b riscv-newlib-3.0.0 https://github.com/riscv/riscv-newlib.git - ``` + 2. Install the .whl file. + + ``` + sudo pip3 install ecdsa-0.14.1-py2.py3-none-any.whl + ``` -6. Download RISC-V Binutils 2.31.1. - ``` - git clone -b riscv-binutils-2.31.1 https://github.com/riscv/riscv-binutils-gdb.git - ``` +### Installing gcc_riscv32 (Compilation Toolchain for the WLAN Module) -7. Download RISC-V GCC 7.3.0. +> ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** +> - The Hi3861 platform supports only the static link of the libgcc library. The dynamic link is not recommended because version 3 of the GNU General Public License (GPLv3) will be polluted during commercial distribution. +> +> - Steps 2 to 14 of the following procedure are used to build the **gcc_riscv32** image. You can simply [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz) and skip these steps. - ``` - git clone -b riscv-gcc-7.3.0 https://github.com/riscv/riscv-gcc - ``` +1. Start a Linux server. -8. Add the RISC-V GCC 7.3.0 patch. +2. Download the **RISC-V GNU** toolchain. + + ``` + git clone --recursive https://gitee.com/mirrors/riscv-gnu-toolchain.git + ``` - Visit the GCC official patch links [89411](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=026216a753ef0a757a9e368a59fa667ea422cf09;hp=2a23a1c39fb33df0277abd4486a3da64ae5e62c2) and [86724](https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/graphite.h;h=be0a22b38942850d88feb159603bb846a8607539;hp=4e0e58c60ab83f1b8acf576e83330466775fac17;hb=b1761565882ed6a171136c2c89e597bc4dd5b6bf;hpb=fbd5f023a03f9f60c6ae36133703af5a711842a3), and manually add the changes to the .c and .h files based on the requirements in the patch links. Note that the number of rows may not match because of different versions of the patch and GCC. You need to search for the keyword in the patch to locate the corresponding row. +3. Open the **riscv-gnu-toolchain** folder and delete empty folders to prevent conflicts during the download of **Newlib**, **Binutils**, and **GCC**. + + ``` + cd riscv-gnu-toolchain && rm -rf riscv-newlib && rm -rf riscv-binutils && rm -rf riscv-gcc + ``` -9. Download, decompress, and install [GMP 6.1.2](https://gmplib.org/download/gmp/gmp-6.1.2.tar.bz2). +4. Download RISC-V Newlib 3.0.0. + + ``` + git clone -b riscv-newlib-3.0.0 https://github.com/riscv/riscv-newlib.git + ``` - ``` - tar -xvf gmp-6.1.2.tar.bz2 && mkdir build_gmp && cd build_gmp && ../gmp-6.1.2/configure --prefix=/usr/local/gmp-6.1.2 --disable-shared --enable-cxx && make && make install - ``` +5. Download RISC-V Binutils 2.31.1. + + ``` + git clone -b riscv-binutils-2.31.1 https://github.com/riscv/riscv-binutils-gdb.git + ``` -10. Download, decompress, and install [mpfr-4.0.2](https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz). +6. Download RISC-V GCC 7.3.0. + + ``` + git clone -b riscv-gcc-7.3.0 https://github.com/riscv/riscv-gcc + ``` - ``` - tar -xvf mpfr-4.0.2.tar.gz && mkdir build_mpfr && cd build_mpfr && ../mpfr-4.0.2/configure --prefix=/usr/local/mpfr-4.0.2 --with-gmp=/usr/local/gmp-6.1.2 --disable-shared && make && make install - ``` +7. Add the RISC-V GCC 7.3.0 patch. + + Visit the GCC official patch links [89411](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=026216a753ef0a757a9e368a59fa667ea422cf09;hp=2a23a1c39fb33df0277abd4486a3da64ae5e62c2) and [86724](https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/graphite.h;h=be0a22b38942850d88feb159603bb846a8607539;hp=4e0e58c60ab83f1b8acf576e83330466775fac17;hb=b1761565882ed6a171136c2c89e597bc4dd5b6bf;hpb=fbd5f023a03f9f60c6ae36133703af5a711842a3), and manually add the changes to the .c and .h files based on the requirements in the patch links. Note that the number of rows may not match because of different versions of the patch and GCC. You need to search for the keyword in the patch to locate the corresponding row. + +8. Download, decompress, and install [GMP 6.1.2](https://gmplib.org/download/gmp/gmp-6.1.2.tar.bz2). + + ``` + tar -xvf gmp-6.1.2.tar.bz2 && mkdir build_gmp && cd build_gmp && ../gmp-6.1.2/configure --prefix=/usr/local/gmp-6.1.2 --disable-shared --enable-cxx && make && make install + ``` -11. Download, decompress, and install [mpc-1.1.0](https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz). +9. Download, decompress, and install [mpfr-4.0.2 ](https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz). + + ``` + tar -xvf mpfr-4.0.2.tar.gz && mkdir build_mpfr && cd build_mpfr && ../mpfr-4.0.2/configure --prefix=/usr/local/mpfr-4.0.2 --with-gmp=/usr/local/gmp-6.1.2 --disable-shared && make && make install + ``` +10. Download, decompress, and install [mpc-1.1.0](https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz). + ``` tar -xvf mpc-1.1.0.tar.gz && mkdir build_mpc && cd build_mpc && ../mpc-1.1.0/configure --prefix=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 --disable-shared && make && make install ``` -12. Open the **riscv-gnu-toolchain** folder and create a directory for toolchain output. - +11. Open the **riscv-gnu-toolchain** folder and create a directory for toolchain output. + ``` cd /opt && mkdir gcc_riscv32 ``` -13. Compile **binutils**. - +12. Compile binutils. + ``` mkdir build_binutils && cd build_binutils && ../riscv-binutils-gdb/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32/riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd .. ``` -14. Build **Newlib**. - +13. Build Newlib. + ``` mkdir build_newlib && cd build_newlib && ../riscv-newlib/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" \CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd .. ``` -15. Build **GCC**. - +14. Build GCC. + ``` mkdir build_gcc && cd build_gcc && ../riscv-gcc/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" LDFLAGS="-Wl,-z,relro,-z,now,-z,noexecstack" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --with-headers="/opt/gcc-riscv32/riscv32-unknown-elf/include" --with-mpc=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 && make -j16 && make install ``` -16. Set an environment variable. - - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >If you use the compiled **riscv32 gcc** package, perform the following steps to set environment variables: - >1. Decompress the package to the root directory. - > ``` - > tar -xvf gcc_riscv32-linux-7.3.0.tar.gz -C ~ - > ``` - >2. Set an environment variable. - > ``` - > vim ~/.bashrc - > ``` - >3. Copy the following command to the last line of the **.bashrc** file, save the file, and exit. - > ``` - > export PATH=~/gcc_riscv32/bin:$PATH - > ``` +15. Set the environment variable. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If you are using the riscv32 gcc package, run the following command to decompress the package to the root directory: + > + > ``` + > tar -xvf gcc_riscv32-linux-7.3.0.tar.gz -C ~ + > ``` + + ``` vim ~/.bashrc ``` - Copy the following command to the last line of the **.bashrc** file, save the file, and exit. + Copy the following command to the last line of the .bashrc file, save the file, and exit. + ``` export PATH=~/gcc_riscv32/bin:$PATH ``` -17. Validate the environment variable. - +16. Validate the environment variable. + ``` source ~/.bashrc ``` -18. Check whether the compiler is successfully installed. If the compiler version number is correctly displayed, the installation is successful. - +17. Check whether the compiler is successfully installed. If the compiler version number is correctly displayed, the installation is successful. + ``` riscv32-unknown-elf-gcc -v ``` - - -## Installing the USB-to-Serial Driver - -Perform the following operations on the Windows station. - -1. Download the USB-to-serial driver: [CH341SER USB-to-serial driver](http://www.hihope.org/en/download/download.aspx). -2. Install the driver. -3. After the driver is installed, remove and then insert the USB cable. The serial port entry should be displayed as shown in the following figure. - - ![](figures/serial-port-entry.png) - - diff --git a/en/device-dev/quick-start/quickstart-lite-steps-hi3861.md b/en/device-dev/quick-start/quickstart-lite-steps-hi3861.md index 4dce36a33177b40ad4044a9ddd9c26a3ba191540..d91f35a59f47a33ca413733901908cbd221964f6 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-hi3861.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-hi3861.md @@ -1,11 +1,17 @@ -# Hi3861 +# Hi3861 Development Board -- **[Setting Up the Environment](quickstart-lite-steps-hi3861-setting.md)** -- **[Setting Up WLAN Connection](quickstart-lite-steps-hi3861-connection.md)** -- **[Running a Hello World Program](quickstart-lite-steps-hi3861-running.md)** +- **[Setting Up the Hi3861 Development Board Environment](quickstart-lite-steps-hi3861-setting.md)** -- **[FAQs](quickstart-lite-steps-hi3861-faqs.md)** +- **[Writing a Hello World Program](quickstart-lite-steps-hi3861-application-framework.md)** +- **[Building](quickstart-lite-steps-hi3861-building.md)** +- **[Burning](quickstart-lite-steps-hi3861-burn.md)** + +- **[Networking](quickstart-lite-steps-hi3861-netconfig.md)** + +- **[Debugging and Verification](quickstart-lite-steps-hi3861-debug.md)** + +- **[Running](quickstart-lite-steps-hi3816-running.md)** diff --git a/en/device-dev/quick-start/quickstart-lite-steps.md b/en/device-dev/quick-start/quickstart-lite-steps.md index fa3a822aa53c64b4fcab0d9402ca496aeff8c63d..06ff9266b6e141eba935c90c690fc0405f4dae28 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps.md +++ b/en/device-dev/quick-start/quickstart-lite-steps.md @@ -1,9 +1,7 @@ -# How to Develop +# Running a Hello World Program -- **[Hi3861](quickstart-lite-steps-hi3861.md)** -- **[Hi3516](quickstart-lite-steps-hi3516.md)** - -- **[Hi3518](quickstart-lite-steps-hi3518.md)** +- **[Hi3861 Development Board](quickstart-lite-steps-hi3861.md)** +- **[Hi3516 Development Board](quickstart-lite-steps-hi3516.md)** diff --git a/en/device-dev/quick-start/quickstart-lite.md b/en/device-dev/quick-start/quickstart-lite.md index b542082aab89383edabe2e4481816e07a83dd61e..95674ead0e58a3a495d5968aa2994655bf33a639 100644 --- a/en/device-dev/quick-start/quickstart-lite.md +++ b/en/device-dev/quick-start/quickstart-lite.md @@ -1,11 +1,6 @@ -# Mini and Small Systems +# Getting Started with Mini and Small Systems -- **[Overview](quickstart-lite-overview.md)** - -- **[Introduction](quickstart-lite-introduction.md)** - -- **[Environment Setup](quickstart-lite-env-setup.md)** - -- **[How to Develop](quickstart-lite-steps.md)** +- **[Getting Started with Mini and Small Systems (IDE Mode)](quickstart-lite-ide-directory.md)** +- **[Getting Started with Mini and Small Systems (Installation Package Mode)](quickstart-lite-package-directory.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-appendix.md b/en/device-dev/quick-start/quickstart-standard-appendix.md new file mode 100644 index 0000000000000000000000000000000000000000..12642666b4a8b2a5000900fe078ad57805e8bc07 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-appendix.md @@ -0,0 +1,7 @@ +# Appendix + + + +- **[Introduction to Development Boards](quickstart-standard-board-introduction.md)** + +- **[Reference](quickstart-standard-reference.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-board-introduction-hi3516.md b/en/device-dev/quick-start/quickstart-standard-board-introduction-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..e6b35313ae2931708770588480edbe9119426731 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-board-introduction-hi3516.md @@ -0,0 +1,20 @@ +# Introduction to the Hi3516 Development Board + + +## Overview + +Hi3516D V300 is a next-generation system on chip (SoC) designed for industry-dedicated smart HD IP cameras. It introduces a next-generation image signal processor (ISP), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. + + **Figure 1** Hi3516 front view + + ![en-us_image_0000001226922318](figures/en-us_image_0000001226922318.png) + + +## Development Board Specifications + + **Table 1** Hi3516 specifications + +| Item| Description| +| -------- | -------- | +| Processor and internal memory| - Hi3516D V300 chip
- DDR3 1 GB
- eMMC 4.5, 8 GB capacity| +| External components| - Ethernet port
- Audio and video
  - 1 voice input
  - 1 mono channel (AC_L) output, connected to a 3 W power amplifier (LM4871)
  - MicroHDMI (1-channel HDMI 1.4)
- Camera
  - Sensor IMX335
  - M12 lens, 4 mm focal length, and 1.8 aperture
- Display
  - LCD connector (2.35-inch)
  - LCD connector (5.5-inch)
- External components and ports
  - Memory card port
  - JTAG/I2S port
  - ADC port
  - Steering gear port
  - Grove connector
  - USB 2.0 (Type-C)
  - Three function keys, two user-defined keys, and one upgrade key
  - LED indicator, green or red| diff --git a/en/device-dev/quick-start/quickstart-standard-board-introduction-rk3568.md b/en/device-dev/quick-start/quickstart-standard-board-introduction-rk3568.md new file mode 100644 index 0000000000000000000000000000000000000000..1a8619a5fa54ffcde656d1346db87660de08f961 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-board-introduction-rk3568.md @@ -0,0 +1,41 @@ +# Introduction to the RK3568 Development Board + + +## Overview + +Bolstered by the Rockchip RK3568 chip, the RK3568 development board integrates a dual-core GPU and high-efficiency NPU. Its quad-core 64-bit Cortex-A55 processor uses the advanced 22 nm manufacturing process and is clocked at up to 2.0 GHz. The development board is packed with Bluetooth, Wi-Fi, audio, video, and camera features, with a wide range of expansion ports as well as video input and output ports. It comes with dual GE auto-sensing RJ45 ports, so it can be used in multi-connectivity products, such as NVRs and industrial gateways. + + **Figure 1** Front view of the RK3568 development board + + ![en-us_image_0000001271442261](figures/en-us_image_0000001271442261.png) + + **Figure 2** RK3568 rear view + + ![en-us_image_0000001226602394](figures/en-us_image_0000001226602394.png) + + +## Development Board Specifications + + **Table 1** RK3568 specifications + +| Item| Description| +| -------- | -------- | +| Display| - 1 x HDMI 2.0 (Type-A) port, supporting 4K/60 fps output
- 2 x MIPI, supporting 1920 x 1080\@60 fps output
-  1 x eDP, supporting 2K@60 fps output| +| Audio port| - 1 x 8ch I2S/TDM/PDM
- 1 x HDMI
- 1 x speaker output
- 1 x headset output
- 1 x microphone for onboard audio input| +| Ethernet port| 2 x GMAC (10/100/1000M)| +| Wireless connectivity| SDIO port, supporting Wi-Fi 6 5G/2.5 GHz and Bluetooth 4.2| +| Camera port| MIPI-CSI2, 1 x 4-lane/2x2-lane\@2.5 Gbps/lane| +| USB port| - 2 x USB 2.0 Host, Type-A
- 1 x USB 3.0 Host, Type-A
- 1 x USB3.0 OTG| +| PCIe | 1 x 2-lane PCIe 3.0 Connector (RC mode)| +| SATA | 1×SATA3.0 Connector | +| SDMMC port| 1 x microSD card 3.0 | +| Keys| - 1 x Vol+/Recovery
- 1 x Reset
- 1 x Power
- 1 x Vol-
- 1 x Mute| +| Debugging port| 1 x Debugging serial port| +| RTC | 1 x RTC| +| IR | 1 x IR| +| Tri-color indicator| 3 x LED| +| G-sensor | 1 x G-sensor| +| Fan| 1 x Fan| +| Expansion port| The 20-pin expansion ports include:
- 2 x ADC
-  2 x I2C
- 7 x GPIO (or 3 x GPIO + 4 x UART)
- 3 x VCC power (12 V, 3.3 V, and 5 V)| +| Mother board dimensions| 180 mm x 130 mm| +| PCB| 4-laminate| diff --git a/en/device-dev/quick-start/quickstart-standard-board-introduction.md b/en/device-dev/quick-start/quickstart-standard-board-introduction.md new file mode 100644 index 0000000000000000000000000000000000000000..c339e4d8b9ad0f5df373b6a9a0d12099f1df9dcf --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-board-introduction.md @@ -0,0 +1,7 @@ +# Introduction to Development Boards + + + +- **[Introduction to the Hi3516 Development Board](quickstart-standard-board-introduction-hi3516.md)** + +- **[Introduction to the RK3568 Development Board](quickstart-standard-board-introduction-rk3568.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-docker.md b/en/device-dev/quick-start/quickstart-standard-docker.md new file mode 100644 index 0000000000000000000000000000000000000000..9c3eee01247037c1b019d260d7e09068045f0013 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-docker.md @@ -0,0 +1,13 @@ +# Getting Started with Standard System (Using the Installation Package) + + + +- **[Standard System Overview](quickstart-standard-overview.md)** + +- **[Setting Up Environments for Standard System](quickstart-standard-env-setup.md)** + +- **[Running a Hello World Project](quickstart-standard-running.md)** + +- **[FAQs](quickstart-standard-faqs.md)** + +- **[Appendix](quickstart-standard-appendix.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-env-setup.md b/en/device-dev/quick-start/quickstart-standard-env-setup.md new file mode 100644 index 0000000000000000000000000000000000000000..945ab49e468f7100490472343ec41146a5322be9 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-env-setup.md @@ -0,0 +1,367 @@ +# Setting Up Environments for Standard System + + +## System Requirements + +- Windows: Windows 10 (64-bit) + +- Ubuntu: Ubuntu 18.04 or later; recommended memory: 16 GB or higher. + +- User name: cannot contain Chinese characters + +- DevEco Device Tool: 3.0 Release + + +## Installing Necessary Libraries and Tools + +To install the necessary libraries and tools, perform the following steps. + +In Ubuntu: + +1. Run the following **apt-get** command: + + ``` + sudo apt-get update && sudo apt-get install binutils binutils-dev git git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib gcc-arm-linux-gnueabi libc6-dev-i386 libc6-dev-amd64 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gnutls-bin python3.8 python3-pip ruby genext2fs device-tree-compiler make libffi-dev e2fsprogs pkg-config perl openssl libssl-dev libelf-dev libdwarf-dev u-boot-tools mtd-utils cpio doxygen liblz4-tool openjdk-8-jre gcc g++ texinfo dosfstools mtools default-jre default-jdk libncurses5 apt-utils wget scons python3.8-distutils tar rsync git-core libxml2-dev lib32z-dev grsync xxd libglib2.0-dev libpixman-1-dev kmod jfsutils reiserfsprogs xfsprogs squashfs-tools pcmciautils quota ppp libtinfo-dev libtinfo5 libncurses5-dev libncursesw5 libstdc++6 gcc-arm-none-eabi vim ssh locales + ``` + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, modify the preceding installation command based on the installation package name. Specifically: + > + > - Python 3.8 or a later version is required. This section uses Python 3.8 as an example. + > + > - Java 8 or later is required. This section uses Java 8 as an example. + +2. Set Python 3.8 as the default Python version. + Check the location of Python 3.8: + + + ``` + which python3.8 + ``` + + Change python and python3 to python3.8. + + ``` + sudo update-alternatives --install /usr/bin/python python {python3.8 path} 1 #{Python3.8 path} is the location of Python 3.8 obtained in the previous step. + sudo update-alternatives --install /usr/bin/python3 python3 {python3.8 path} 1 #{Python3.8 path} is the location of Python 3.8 obtained in the previous step. + ``` + + +## Installing DevEco Device Tool + +To remotely access the Ubuntu environment through Windows to perform operations such as burning, you need to install DevEco Device Tool on both Windows and Ubuntu. + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> DevEco Device Tool is a one-stop integrated development environment (IDE) provided for developers of OpenHarmony-powered smart devices. It allows code editing, compiling, burning, and debugging. This document describes how to use DevEco Device Tool to remotely connect to the Ubuntu environment for burning and running. + + +### Installing DevEco Device Tool for Windows + +1. Download the [DevEco Device Tool 3.0 Release](https://device.harmonyos.com/cn/ide#download) Windows edition. + +2. Decompress the DevEco Device Tool package, double-click the installer, and then click **Next**. + +3. Set the installation path of DevEco Device Tool and click **Next**. You are advised to install DevEco Device Tool in a non-system drive. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If you have installed DevEco Device Tool 3.0 Beta2 or earlier, the earlier version will be uninstalled before you install a new version. If the following error message is displayed during the uninstallation, click **Ignore** to continue the installation. This error does not affect the installation of the new version. + > + > ![en-us_image_0000001239275843](figures/en-us_image_0000001239275843.png) + + ![en-us_image_0000001270076961](figures/en-us_image_0000001270076961.png) + +4. When prompted, select the tools to be automatically installed. + 1. On the **VSCode installation confirm** page, select **Install VScode 1.62.2 automatically** and click **Next**. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Visual Studio Code 1.62 or later has been installed, this step will be skipped. + + ![en-us_image_0000001237801283](figures/en-us_image_0000001237801283.png) + 2. On the displayed **Python select page**, select **Download from Huawei mirror** and click **Next**. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If Python 3.8 or 3.9 has been installed, select **Use one of compatible on your PC**. + + ![en-us_image_0000001193983334](figures/en-us_image_0000001193983334.png) + +5. In the dialog box shown below, click **Next** to download and install the tools.. + + ![en-us_image_0000001239634067](figures/en-us_image_0000001239634067.png) + +6. Wait for the DevEco Device Tool setup wizard to automatically install DevEco Device Tool. After the installation is complete, click **Finish** to close the setup wizard. + + ![en-us_image_0000001239650137](figures/en-us_image_0000001239650137.png) + +7. From Visual Studio Code, access the DevEco Device Tool page. Now you can conduct your development in DevEco Device Tool. + + ![en-us_image_0000001225760456](figures/en-us_image_0000001225760456.png) + + +### Installing DevEco Device Tool for Ubuntu + +1. Make sure the Ubuntu shell environment is **bash**. + 1. Run the following command and check whether the command output is **bash**. If the command output is not **bash**, go to step 2. + + ``` + ls -l /bin/sh + ``` + + ![en-us_image_0000001226764302](figures/en-us_image_0000001226764302.png) + 2. Start the command-line tool, run the following command, enter your password, and select **No** to set **Ubuntu shell** to **bash**. + + ``` + sudo dpkg-reconfigure dash + ``` + + ![en-us_image_0000001243641075](figures/en-us_image_0000001243641075.png) + +2. Download the [DevEco Device Tool 3.0 Release Linux version](https://device.harmonyos.com/cn/ide#download). + +3. Decompress the DevEco Device Tool software package and assign permission on the folder obtained from the decompression. + 1. Go to the directory where the DevEco Device Tool software package is stored and run the following command to decompress the software package. In the command, change **devicetool-linux-tool-3.0.0.400.zip** to the actual software package name. + + ``` + unzip devicetool-linux-tool-3.0.0.400.zip + ``` + 2. Open the folder of the decompressed software package and run the following command to grant the execute permission on the installation file. In the command, change **devicetool-linux-tool-3.0.0.400.sh** to the actual installation file name. + + ``` + chmod u+x devicetool-linux-tool-3.0.0.400.sh + ``` + +4. Run the following command to install DevEco Device Tool, where **devicetool-linux-tool-3.0.0.400.sh** indicates the installation file name. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > During the installation, the setup wizard automatically checks whether Python 3.8 or 3.9 is installed. If Python 3.8 or 3.9 is not installed, the setup wizard displays the "Do you want to continue?" message; enter **Y** to allow the setup wizard to automatically install Python. + + + ``` + sudo ./devicetool-linux-tool-3.0.0.400.sh + ``` + + Wait until the "Deveco Device Tool successfully installed." message is displayed. + + ![en-us_image_0000001198722374](figures/en-us_image_0000001198722374.png) + + +## Configuring Windows to Remotely Access the Ubuntu Build Environment + + +### Installing the SSH Service and Obtaining the IP Address for Remote Access + +1. In Ubuntu, open the Terminal tool and run the following command to install the SSH service: + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the command fails to be executed and the system displays a message indicating that the openssh-server and openssh-client depend on different versions, install the openssh-client of the required version (for example, **sudo apt-get install openssh-client=1:8.2p1-4**) as prompted on the command-line interface (CLI) and run the command again to install the openssh-server. + + + ``` + sudo apt-get install openssh-server + ``` + +2. Run the following command to start the SSH service: + + ``` + sudo systemctl start ssh + ``` + +3. Run the following command to obtain the IP address of the current user for remote access to the Ubuntu environment from Windows: + + ``` + ifconfig + ``` + + ![en-us_image_0000001215737140](figures/en-us_image_0000001215737140.png) + + +### Installing Remote SSH + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001239080359](figures/en-us-cn_image_0000001239080359.png), and search for **remote-ssh** in the Extension Marketplace. + + ![en-us_image_0000001193920448](figures/en-us_image_0000001193920448.png) + +2. Click **Install** to install Remote-SSH. After the installation is successful, **Remote-SSH** is displayed on the **INSTALLED** list. + + ![en-us_image_0000001238880335](figures/en-us_image_0000001238880335.png) + + +### Remotely Connecting to the Ubuntu Environment + +1. Open Visual Studio Code in Windows, click ![en-us_image_0000001238760373](figures/en-us_image_0000001238760373.png), and click + on the **REMOTE EXOPLORER** page. + + ![en-us_image_0000001215878922](figures/en-us_image_0000001215878922.png) + +2. In the **Enter SSH Connection Command** text box, enter **ssh *username@ip_address***, where *ip_address* indicates the IP address of the remote computer to be connected and *username* indicates the account name used for logging in to the remote computer. + + ![en-us_image_0000001215879750](figures/en-us_image_0000001215879750.png) + +3. In the displayed dialog box, select the default first option as the SSH configuration file. + + ![en-us_image_0000001260519729](figures/en-us_image_0000001260519729.png) + +4. Under **SSH TARGETS**, find the remote computer and click ![en-us_image_0000001194080414](figures/en-us_image_0000001194080414.png) to start it. + + ![en-us_image_0000001215720398](figures/en-us_image_0000001215720398.png) + +5. In the displayed dialog box, select **Linux**, select **Continue**, and enter the password for logging in to the remote computer. + + ![en-us_image_0000001215897530](figures/en-us_image_0000001215897530.png) + + After the connection is successful, the plug-in is automatically installed in the .vscode-server folder on the remote computer. After the installation is complete, reload Visual Studio Code in Windows as prompted. Then you can develop, compile, and burn source code in DevEco Device Tool on Windows. + + +### Registering the Public Key for Accessing the Ubuntu Environment + +After the preceding operations are complete, you can remotely connect to the Ubuntu environment through Windows for development. However, you need to frequently enter the remote connection password. To eliminate this need, you can use the SSH public key. + +1. Open the Git bash CLI and run the following command to generate an SSH public key. During command execution, perform operations as prompted. Set **username** and **ip** to the user name and IP address you use for connecting to the Ubuntu system. + + ``` + ssh-keygen -t rsa + ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip + ``` + + ![en-us_image_0000001271532317](figures/en-us_image_0000001271532317.png) + +2. In Visual Studio Code, click the remote connection setting button and open the **config** file. + ![en-us_image_0000001226034634](figures/en-us_image_0000001226034634.png) + +3. In the **config** file, add the SSK key file information, as shown below. Then save the file. + ![en-us_image_0000001270356233](figures/en-us_image_0000001270356233.png) + + +## Obtaining Source Code + +In the Ubuntu environment, perform the following steps to obtain the OpenHarmony source code: + + +### Preparations + +1. Register your account with Gitee. + +2. Register an SSH public key for access to Gitee. + +3. Install the git client and git-lfs. (Skip this step if these tools have been installed in Installing Required Libraries and Tools. ) + + Update the software source: + + ``` + sudo apt-get update + ``` + + Run the following command to install the tools: + + ``` + sudo apt-get install git git-lfs + ``` + +4. Configure user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +5. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +### Obtaining Source Code + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../../release-notes/Readme.md). + + +### Running prebuilts + + Go to the root directory of the source code and run the following script to install the compiler and binary tool: + +``` +bash build/prebuilts_download.sh +``` + + +## Installing the Compilation Tool + +hb is a compilation tool of OpenHarmony. To install hb in Ubuntu, perform the following steps: For details about the functions of the OpenHarmony compilation and building module, see [Compilation and Building Guidelines](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-build.md). + + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> To install a proxy, see [Configuring a Proxy](../quick-start/quickstart-standard-reference.md#configuring-a-proxy). + + +1. Run the following command to install hb and update it to the latest version: + + ``` + pip3 install --user build/lite + ``` + +2. Set the environment variable. + + ``` + vim ~/.bashrc + ``` + + Copy the following command to the last line of the .bashrc file, save the file, and exit. + + ``` + export PATH=~/.local/bin:$PATH + ``` + + Update the environment variable. + + ``` + source ~/.bashrc + ``` + +3. Run the **hb -h** command in the source code directory. If the following information is displayed, the installation is successful: + + ``` + usage: hb + + OHOS build system + + positional arguments: + {build,set,env,clean} + build Build source code + set OHOS build settings + env Show OHOS build env + clean Clean output + + optional arguments: + -h, --help show this help message and exit + ``` + + +> ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** +> - Run the following command to uninstall hb: +> +> ``` +> pip3 uninstall ohos-build +> ``` +> +> - If any issue occurs during the hb installation, see [FAQs](../quick-start/quickstart-standard-faq-hb.md) to troubleshoot. diff --git a/en/device-dev/quick-start/quickstart-standard-faq-burning.md b/en/device-dev/quick-start/quickstart-standard-faq-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..0c1e2e64a3a2694f02da35059e27976de77e2157 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-faq-burning.md @@ -0,0 +1,96 @@ +# Fixing Burning Issues + + +## What should I do if Error: Opening COMxx: Access denied is displayed when I start burning + +- **Symptom** + + Error: Opening COMxx: Access denied is displayed after clicking Burn and selecting a serial port. + + **Figure 1** Failed to open the serial port + + ![en-us_image_0000001271202461](figures/en-us_image_0000001271202461.png) + +- **Possible Causes** + + The serial port is in use. + +- **Solution** + +1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel. + + **Figure 2** Checking whether the serial port is in use + + ![en-us_image_0000001271202473](figures/en-us_image_0000001271202473.png) + +2. Click the dustbin icon as shown below to disable the terminal using the serial port. + + **Figure 3** Disabling the terminal using the serial port + + ![en-us_image_0000001271202469](figures/en-us_image_0000001271202469.png) + +3. Click **Burn**, select the serial port, and start burning images again. + + **Figure 4** Restarting the burning task + + ![en-us_image_0000001271562449](figures/en-us_image_0000001271562449.png) + + +## What should I do when Windows-based PC failed to be connected to the board? + +- **Symptom** + + The file image cannot be obtained after clicking Burn and selecting a serial port. + + **Figure 5** Failed to obtain the file image due to network disconnection + + ![en-us_image_0000001226922306](figures/en-us_image_0000001226922306.png) + +- **Possible Causes** + + The board is disconnected from the Windows-based PC. + + Windows Firewall does not allow Visual Studio Code to access the network. + +- **Solution** + +1. Check whether the network cable is properly connected. + +2. Click **Windows Firewall**. + + **Figure 6** Network and firewall settings + + ![en-us_image_0000001226634732](figures/en-us_image_0000001226634732.png) + +3. Click **Firewall & network protection**, and on the displayed page, click **Allow an app through the firewall**. + + **Figure 7** Firewall & network protection + + ![en-us_image_0000001271202457](figures/en-us_image_0000001271202457.png) + +4. Select Visual Studio Code. + + **Figure 8** Selecting Visual Studio Code + + ![en-us_image_0000001271234765](figures/en-us_image_0000001271234765.png) + +5. Select the **Private** and **Public** network access rights for Visual Studio Code. + + **Figure 9** Allowing Visual Studio Code to access the network + + ![en-us_image_0000001271474585](figures/en-us_image_0000001271474585.png) + + +## What should I do when the image failed to be burnt? + +- **Symptom** + + The burning status is not displayed after clicking Burn and selecting a serial port. + +- **Possible Causes** + + The IDE is not restarted after the DevEco plug-in is installed. + +- **Solution** + + Restart the IDE. diff --git a/en/device-dev/quick-start/quickstart-standard-faq-compose.md b/en/device-dev/quick-start/quickstart-standard-faq-compose.md new file mode 100644 index 0000000000000000000000000000000000000000..9b07513c002e34048c5db3391d478546729f9e94 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-faq-compose.md @@ -0,0 +1,182 @@ +# Fixing Compilation Issues + + +## What should I do if the message "ImportError: No module named apt_pkg" is displayed during the execution of an unidentifiable command? + +- **Symptom** + + The message "ImportError: No module named apt_pkg" is displayed when an unidentifiable command is executed on the Linux server. + +- **Possible Causes** + + There is a compatibility issue of python3-apt. + +- **Solution** + + Reinstall python3-apt. + + + ``` + sudo apt-get remove python3-apt + sudo apt-get install python3-apt + ``` + + +## What should I do if the message indicating Python cannot be found is displayed during compilation and building? + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + -bash: /usr/bin/python: No such file or directory + ``` + +- **Possible Cause 1** + + Python is not installed. + +- **Solution** + + Run the following command to install Python. The following uses Python 3.8 as an example. + + + ``` + sudo apt-get install python3.8 + ``` + +- **Possible Cause 2** + + The soft link that points to the Python does not exist in the **usr/bin** directory. + + ![en-us_image_0000001226922322](figures/en-us_image_0000001226922322.png) + +- **Solution** + + Run the following commands to add a soft link: + + + ``` + # cd /usr/bin/ + # which python3 + # ln -s /usr/local/bin/python3 python + # python --version + ``` + + Example: + + ![en-us_image_0000001271562453](figures/en-us_image_0000001271562453.png) + + +## What should I do if the message indicating Python 3 cannot be found is displayed during the build process? + +- **Symptom** + + ![en-us_image_0000001226602414](figures/en-us_image_0000001226602414.png) + +- **Possible Causes** + + Python 3 is not installed. + +- **Solution** + + Run the following command to install Python 3: + + + ``` + sudo apt-get install python3.8 + ``` + + +## What should I do if the message "configure: error: no acceptable C compiler found in $PATH" is displayed during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + configure: error: no acceptable C compiler found in $PATH. See 'config.log' for more details + ``` + +- **Possible Causes** + + **gcc** is not installed. + +- **Solution** + + 1. Run the **apt-get install gcc** command to install **gcc** online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "-bash: make: command not found" is displayed during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + -bash: make: command not found + ``` + +- **Possible Causes** + + Make is not installed. + +- **Solution** + + 1. Run the **apt-get install make** command to install Make online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "No module named '_ctypes'" is displayed during Python 3 installation? + +- **Symptom** + + The following error occurs during Python 3 installation: + + + ``` + ModuleNotFoundError: No module named '_ctypes' + ``` + +- **Possible Causes** + + **libffi** and **libffi-devel** are not installed. + +- **Solution** + + 1. Run the **apt-get install libffi* -y** command to install **libffi** and **libffi-devel** online. + 2. After the installation, reinstall Python 3. + + +## What should I do if the message "No module named 'Crypto'" is displayed during the build process? + +- **Symptom** + + The following error occurs during compilation and building: + + + ``` + ModuleNotFoundError: No module named 'Crypto' + ``` + +- **Possible Causes** + + **Crypto** is not installed. + +- **Solution** + + Solution 1: Run the **pip3 install Crypto** command to install **Crypto** online. + + Method 2: Offline installation + + Download the source code from [PyPI](https://pypi.org/project/pycrypto/#files). + + ![en-us_image_0000001227082334](figures/en-us_image_0000001227082334.png) + + Save the source package to the Linux server, decompress the package, and run the **python3 setup.py install** command to install Crypto. + + After the preceding installation is complete, rebuild an environment. diff --git a/en/device-dev/quick-start/quickstart-standard-faq-hb.md b/en/device-dev/quick-start/quickstart-standard-faq-hb.md new file mode 100644 index 0000000000000000000000000000000000000000..f70d8caa2fcad74a10961a3b4612ba5b82e390f4 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-faq-hb.md @@ -0,0 +1,71 @@ +# Fixing hb Installation Issues + + +## What should I do if garbled characters and segmentation faults occur during hb installation? + +- **Symptom** + Garbled characters and segmentation faults occur during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + pip is of an early version. + +- **Solution** + Upgrade pip. + + + ``` + python3 -m pip install -U pip + ``` + + +## What should I do if the message "cannot import 'sysconfig' from 'distutils'" is displayed during hb installation? + +- **Symptom** + The message "cannot import 'sysconfig' from 'distutils'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + The **distutils** module is unavailable. + +- **Solution** + Install distutils. + + + ``` + sudo apt-get install python3.8-distutils + ``` + + +## What should I do if the message "module 'platform' has no attribute 'linux_distribution'" is displayed during hb installation? + +- **Symptom** + The message "module 'platform' has no attribute 'linux_distribution'" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + There is a compatibility issue of python3-pip. + +- **Solution** + Reinstall pip. + + + ``` + sudo apt remove python3-pip + curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py + python get-pip.py + ``` + + +## What should I do if the message "Could not find a version that satisfies the requirement ohos-build" is displayed during hb installation? + +- **Symptom** + The message "Could not find a version that satisfies the requirement ohos-build" is displayed during the execution of the **python3 -m pip install --user ohos-build** command. + +- **Possible Causes** + The installation fails due to poor network connectivity. + +- **Solution** + 1. Ensure that your computer has a good network connection. If the network connection is unstable, rectify the network fault and reinstall hb. + 2. If the network is functional, run the following commands to install hb by specifying a temporary PyPI source: + + ``` + python3 -m pip install -i https://pypi.tuna.tsinghua.edu.cn/simple ohos-build + ``` diff --git a/en/device-dev/quick-start/quickstart-standard-faqs.md b/en/device-dev/quick-start/quickstart-standard-faqs.md index 49caf70c244c84eb4f5fd773a5db72ca84f26377..e4c33d7f1f467dbf995cfab823281b0791a45c64 100644 --- a/en/device-dev/quick-start/quickstart-standard-faqs.md +++ b/en/device-dev/quick-start/quickstart-standard-faqs.md @@ -1,22 +1,10 @@ -# FAQs +# FAQs -## What Should I Do If "ImportError: No module named apt\_pkg" Is Displayed During Compilation and Building? -- **Symptom** - The message "ImportError: No module named apt\_pkg" is displayed when an unidentifiable command is executed on the Linux server. +- **[Fixing hb Installation Issues](quickstart-standard-faq-hb.md)** -- **Possible Causes** - - There is a compatibility issue of python3-apt. - -- **Solution** - - Reinstall python3-apt. - - ``` - sudo apt-get remove python3-apt - sudo apt-get install python3-apt - ``` +- **[Fixing Compilation Issues](quickstart-standard-faq-compose.md)** +- **[Fixing Burning Issues](quickstart-standard-faq-burning.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-ide-directory.md b/en/device-dev/quick-start/quickstart-standard-ide-directory.md new file mode 100644 index 0000000000000000000000000000000000000000..297424cb26da0d60a9500e2a78623eb232e523a9 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-ide-directory.md @@ -0,0 +1,22 @@ +## Getting Started with Standard System (IDE Mode) +- [Standard System Overview](quickstart-ide-standard-overview.md) + - Environment Preparation + - [Setting Up the Windows+Ubuntu Hybrid Build Environment](quickstart-ide-standard-env-setup-win-ubuntu.md) + - [Obtaining Source Code](quickstart-ide-standard-sourcecode-acquire.md) + - [Creating a Source Code Project](quickstart-ide-standard-create-project.md) + - Running a Hello World Program + - Hi3516 Development Board + - [Writing a Hello World Program](quickstart-ide-standard-running-hi3516-create.md) + - [Building](quickstart-ide-standard-running-hi3516-build.md) + - [Burning](quickstart-ide-standard-running-hi3516-burning.md) + - [Running](quickstart-ide-standard-running-hi3516-running.md) + - RK3568 Development Board + - [Writing a Hello World Program](quickstart-ide-standard-running-rk3568-create.md) + - [Building](quickstart-ide-standard-running-rk3568-build.md) + - [Burning](quickstart-ide-standard-running-rk3568-burning.md) + - [Running](quickstart-ide-standard-running-rk3568-running.md) + - Appendix + - Introduction to Development Boards + - [Introduction to the Hi3516 Development Board](quickstart-ide-standard-board-introduction-hi3516.md) + - [Introduction to the RK3568 Development Board](quickstart-ide-standard-board-introduction-rk3568.md) + - [Getting Started with Mini and Small Systems (Installation Package Mode)](quickstart-lite-package-directory.md) diff --git a/en/device-dev/quick-start/quickstart-standard-ide.md b/en/device-dev/quick-start/quickstart-standard-ide.md new file mode 100644 index 0000000000000000000000000000000000000000..034c53890ad98ed1bbad80cfadc6a8a971d5f397 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-ide.md @@ -0,0 +1,13 @@ +# Getting Started with Standard System (IDE Mode) + + + +- **[Standard System Overview](quickstart-ide-standard-overview.md)** + +- **[Environment Preparation](quickstart-ide-standard-env-setup.md)** + +- **[Creating a Source Code Project](quickstart-ide-standard-create-project.md)** + +- **[Running a Hello World Program](quickstart-ide-standard-running.md)** + +- **[Appendix](quickstart-ide-standard-appendix.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-overview.md b/en/device-dev/quick-start/quickstart-standard-overview.md index 27796a8b9bba8a8aa1356533d7c24c57b153f664..8b2dfb427ff73c4b4247cec57a079f9e790f6f8d 100644 --- a/en/device-dev/quick-start/quickstart-standard-overview.md +++ b/en/device-dev/quick-start/quickstart-standard-overview.md @@ -1,48 +1,40 @@ -# Introduction +# Standard System Overview -This document helps you quickly understand how to set up a standard OpenHarmony system, and how to build, burn, and start the system. You can develop the standard system in Windows and build source code in Linux. -This document uses the recommended Hi3516D V300 development board as an example. +## Introduction -## Quick Start Process +The OpenHarmony standard system applies to devices with a reference memory greater than or equal to 128 MiB. This document helps you quickly get started for development of the OpenHarmony standard system, from environment setup to building, burning, and startup. -The following figure shows the process of getting started for the standard system, during which, you can set up the Ubuntu development environment in Docker mode or by using the installation package. +To accommodate different developer habits, OpenHarmony provides two modes for getting started with the standard system: -**Figure 1** Getting started for the standard system -![](figures/getting-started-for-the-standard-system.png "getting-started-for-the-standard-system") +- IDE mode: DevEco Device Tool is used for one-stop development, covering dependency installation, building, burning, and running. -## Introduction to the Development Board +- Installation package mode: Dependency download and installation as well as building operations are performed using commands. Burning and running are performed in DevEco Device Tool. + OpenHarmony also provides the [Docker environment](../get-code/gettools-acquire.md), which can significantly simplify the environment configuration before compilation. You can build your source code in the Docker environment if you are more accustomed to using the installation package mode. -Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption. +This document exemplifies how to use the installation package mode. For details about the IDE mode, see [Getting Started with Standard System (IDE Mode)](../quick-start/quickstart-standard-ide-directory.md). -**Figure 2** Hi3516D V300 front view -![](figures/hi3516d-v300-front-view-1.png "hi3516d-v300-front-view-1") -## Development Board Specifications +## Development Environment -**Table 1** Specifications of the Hi3516 development board +In the Windows+Ubuntu hybrid environment for OpenHarmony development: - - - - - - - - - - - - -

Item

-

Description

-

Processor and internal memory

-
  • Hi3516D V300
  • 1 GB DDR3
  • 8 GB eMMC4.5
-

External components

-
  • Ethernet port
  • Audio and video
    • One voice input
    • One mono output (AC_L), connected to a 3 W power amplifier (LM4871)
    • Micro-HDMI (one HDMI 1.4)
    -
  • Cameras
    • Sensor IMX335
    • M12 lens with a focal length of 4 mm and an aperture of 1.8
    -
  • Display
    • 2.35-inch LCD connector
    • 5.5-inch LCD connector
    -
  • External components and interfaces
    • microSD card interface
    • JTAG/I2S interface
    • ADC interface
    • Steer gear interface
    • Grove connector
    • USB 2.0 (Type C)
    • Three function keys: two custom keys and one update key
    • LED indicator (including green and red)
    -
-
+- Windows: used for source code development and burning. +- Ubuntu: used for source code building. + +This document describes how to develop OpenHarmony in the Windows+Ubuntu environment. + + +## Development Boards + +In this document, two development board models are used as examples: Hi3516D V300 and RK3516. For details about these development boards, see [Appendix](../quick-start/quickstart-standard-board-introduction.md). You can purchase the development board as required. + + +## Development Process + +Below you can see the quick start process for the development of the standard system. + + **Figure 1** Quick start process for the development of the standard system + + ![en-us_image_0000001226634676](figures/en-us_image_0000001226634676.png) diff --git a/en/device-dev/quick-start/quickstart-standard-package-directory.md b/en/device-dev/quick-start/quickstart-standard-package-directory.md new file mode 100644 index 0000000000000000000000000000000000000000..8912028e042d94cf2fea39d1e0033ccfc456d611 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-package-directory.md @@ -0,0 +1,24 @@ +## Getting Started with Standard System (Installation Package Mode) +- [Standard System Overview](quickstart-standard-overview.md) +- [Setting Up Environments for Standard System](quickstart-standard-env-setup.md) +- Running a Hello World Program + - Hi3516 Development Board + - [Writing a Hello World Program](quickstart-standard-running-hi3516-create.md) + - [Building](quickstart-standard-running-hi3516-build.md) + - [Burning](quickstart-standard-running-hi3516-burning.md) + - [Running](quickstart-standard-running-hi3516-running.md) + - RK3568 Development Board + - [Writing a Hello World Program](quickstart-standard-running-rk3568-create.md) + - [Building](quickstart-standard-running-rk3568-build.md) + - [Burning](quickstart-standard-running-rk3568-burning.md) + - [Running](quickstart-standard-running-rk3568-running.md) +- FAQs + - [Fixing hb Installation Issues](quickstart-standard-faq-hb.md) + - [Fixing Compilation Issues](quickstart-standard-faq-compose.md) + - [Fixing Burning Issues](quickstart-standard-faq-burning.md) +- Appendix + - Introduction to Development Boards + - [Introduction to the Hi3516 Development Board](quickstart-standard-board-introduction-hi3516.md) + - [Introduction to the RK3568 Development Board](quickstart-standard-board-introduction-rk3568.md) + - [Getting Started with Standard System (IDE Mode)](quickstart-standard-ide-directory.md) + - [Reference](quickstart-standard-reference.md) diff --git a/en/device-dev/quick-start/quickstart-standard-reference.md b/en/device-dev/quick-start/quickstart-standard-reference.md new file mode 100644 index 0000000000000000000000000000000000000000..a1bb41dcfd09fd8b5c0419a11cbd8ca6b494c06a --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-reference.md @@ -0,0 +1,69 @@ +# Reference + + +## Using the build.sh Script to Build Source Code + + +1. Go to the root directory of the source code and run the build command. + + ``` + ./build.sh --product-name name --ccache + ``` + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > _name_ indicates the product name, for example, **Hi3516D V300** and **rk3568**. + +2. Check the build result. After the build is complete, the following information is displayed in the log: + + ``` + post_process + =====build name successful. + ``` + + Files generated during the build are stored in the **out/{device_name}/** directory, and the generated image is stored in the **out/{device_name}/packages/phone/images/** directory. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > For details about other modular compilation operations, see [Building a Standard System](../subsystems/subsys-build-standard-large.md). + + +## Configuring the Proxy + + +### Setting Up the Python Proxy + +1. Create a proxy configuration file. + + ``` + mkdir ~/.pipvim ~/.pip/pip.conf + ``` + +2. Add the following proxy information to the file, save the file, and exit: + + ``` + [global] + index-url = http:// Proxy URL + trusted-host = Trusted image path + timeout = 120 + ``` + + +### Setting Up the npm Proxy + +1. Create a proxy configuration file. + + ``` + vim ~/.npmrc + ``` + +2. Add the following proxy information to the file, save the file, and exit: + + ``` + Registry=http:// Proxy URL + strict-ssl=false + ``` + +3. Add the following content to the **.bashrc** file, save the file, and exit: + + ``` + export NPM_REGISTRY=http:// Proxy URL + source .bashrc + ``` diff --git a/en/device-dev/quick-start/quickstart-standard-running-hi3516-build.md b/en/device-dev/quick-start/quickstart-standard-running-hi3516-build.md new file mode 100644 index 0000000000000000000000000000000000000000..f40fa3b05b2f3cd16f86a2f9f8c11bf20945188b --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-hi3516-build.md @@ -0,0 +1,48 @@ +# Building + + +You can build source code with hb or the **build.sh** script. This section exemplifies how to build source code with hb. For details about how to build with the **build.sh** script, see [Building Source Code Using the build.sh Script](../quick-start/quickstart-standard-reference.md). + + +Go to the root directory of the source code in the Ubuntu environment and perform the following steps: + + +1. Set the build path. + + ``` + hb set + ``` + +2. Select the current path. + + ``` + . + ``` + +3. Select **Hi3516D V300** under **built-in** and press **Enter**. + +4. Start building. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - To build a component (for example, **hello**), run the **hb build -T _ Target name _** command. + > + > - To build a product incrementally, run the **hb build** command. + > + > - To build a product from the scratch, run the **hb build -f** command. + > + > This example builds a product from the scratch. + + + ``` + hb build -f + ``` + + + **Figure 1** Hi3516 build settings + + ![en-us_image_0000001271562433](figures/en-us_image_0000001271562433.png) + +5. Check the build result. If "build success" is displayed, the building is successful. + + > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** + > The build result and log files are stored in **out/hi3516dv300**. diff --git a/en/device-dev/quick-start/quickstart-standard-running-hi3516-burning.md b/en/device-dev/quick-start/quickstart-standard-running-hi3516-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..231e6fea28ebeed249fc93799efe21e891232f61 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-hi3516-burning.md @@ -0,0 +1,104 @@ +# Burning + + +To burn source code to Hi3516D V300 through the USB port in Windows, perform the following steps. + + +### Importing Source Code + +After the building is complete, ensure that you can [remotely access the Ubuntu environment from Windows](../quick-start/quickstart-standard-env-setup.md). Then, perform the following steps to import the source code before burning: + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the target directory (in the Ubuntu environment) and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001227711882](figures/en-us_image_0000001227711882.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. In the figure below, **Hi3516DV300** is used as an example. + + ![en-us_image_0000001271912277](figures/en-us_image_0000001271912277.png) + +6. Click **Open** to open the project or source code. + + +### Burning + +After the source code is imported, perform the following steps: + +1. Connect the computer and the target development board through the serial port and USB port. For details, see [Introduction to the Hi3516D V300 Development Board](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md). + +2. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. In this case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +3. Check the serial port number in **QUICK ACCESS** > **DevEco Home** > **Device** in DevEco Device Tool. + + ![en-us_image_0000001216516128](figures/en-us_image_0000001216516128.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/documentation/guide/hi3516_hi3518-drivers-0000001050743695). + +4. Choose **QUICK ACCESS** > **DevEco Home** > **Projects**, and then click **Settings**. + + ![en-us_image_0000001198566364](figures/en-us_image_0000001198566364.png) + +5. On the **hi3516dv300** tab page, set the burning options. + + - **upload_partitions**: Select the file to be burnt. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are burnt at the same time. + - **upload_port**: Select the serial port number obtained. + - **upload_protocol**: Select the burning protocol **hiburn-usb**. + + ![en-us_image_0000001223190441](figures/en-us_image_0000001223190441.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **fastboot**, **kernel**, **rootfs**, and **userfs**. + + 1. On the **hi3516dv300_fastboot** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001198889702](figures/en-us_image_0000001198889702.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001243290907](figures/en-us_image_0000001243290907.png) + + 3. Follow the same procedure to modify the information about the **kernel**, **rootfs**, and **userfs** files. + +7. When you finish modifying, click **Save** on the top. + +8. Go to **hi3516dv300** > **Upload** to start burning. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If this is the first time you burn source code to the Hi3516D V300 or Hi3518E V300 board, the message "not find the Devices" may be displayed. In this case, follow the steps in [Installing the USB Port Driver on the Hi3516D V300 or Hi3518E V300 Development Board](https://device.harmonyos.com/en/docs/documentation/guide/usb_driver-0000001058690393) and start burning again. + + ![en-us_image_0000001267231481](figures/en-us_image_0000001267231481.png) + +9. When the following information is displayed in the Terminal window, press and hold the reset button, remove and insert the USB cable, and release the reset button to start burning. + + ![en-us_image_0000001114129426](figures/en-us_image_0000001114129426.png) + + If the following message is displayed, it indicates that the burning is successful. + + ![en-us_image_0000001160649343](figures/en-us_image_0000001160649343.png) + +10. When the burning is successful, perform the operations in Running an Image to start the system. diff --git a/en/device-dev/quick-start/quickstart-standard-running-hi3516-create.md b/en/device-dev/quick-start/quickstart-standard-running-hi3516-create.md new file mode 100644 index 0000000000000000000000000000000000000000..e0ffea9670c0285a8731fd220e2d7173a1093bf0 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-hi3516-create.md @@ -0,0 +1,162 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + +The complete code directory is as follows: + + +``` +applications/sample/hello +│ │── BUILD.gn +│ │── include +│ │ └── helloworld.h +│ │── src +│ │ └── helloworld.c +│ └── bundle.json +build +└── subsystem_config.json +productdefine/common +└── products + └── Hi3568DV300.json +``` + + +## How to Develop + +Perform the steps below in the source code directory: + + +1. Create a directory and write the service code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **World** to **OH**. Declare the string printing function **HelloPrint** in the **helloworld.h** file. You can use either C or C++ to develop a program. + + + ``` + #include + #include "helloworld.h" + + int main(int argc, char **argv) + { + HelloPrint(); + return 0; + } + + void HelloPrint() + { + printf("\n\n"); + printf("\n\t\tHello World!\n"); + printf("\n\n"); + } + ``` + + Add the header file **applications/sample/hello/include/helloworld.h**. The sample code is as follows: + + + ``` + #ifndef HELLOWORLD_H + #define HELLOWORLD_H + #ifdef __cplusplus + #if __cplusplus + extern "C" { + #endif + #endif + + void HelloPrint(); + + #ifdef __cplusplus + #if __cplusplus + } + #endif + #endif + #endif // HELLOWORLD_H + ``` + +2. Create a build file. + + 1. Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + ``` + import("//build/ohos.gni") # Import the build template. + ohos_executable("helloworld") {# Executable module. + sources = [ # Source code of the module. + "src/helloworld.c" + ] + include_dirs = [ # Directory of header file on which the module depends. + "include" + ] + cflags = [] + cflags_c = [] + cflags_cc = [] + ldflags = [] + configs = [] + deps =[] # Internal dependencies of a component. + part_name = "hello" # Component name. This parameter is mandatory. + install_enable = true # Whether to install the software by default. This parameter is optional. By default, the software is not installed. + } + ``` + 2. Create the **applications/sample/hello/bundle.json** file and add the description of the **sample** component. The content is as follows: + + ``` + { + "name": "@ohos/hello", + "description": "Hello world example.", + "version": "3.1", + "license": "Apache License 2.0", + "publishAs": "code-segment", + "segment": { + "destPath": "applications/sample/hello" + }, + "dirs": {}, + "scripts": {}, + "component": { + "name": "hello", + "subsystem": "sample", + "syscap": [], + "features": [], + "adapted_system_type": [ "mini", "small", "standard" ], + "rom": "10KB", + "ram": "10KB", + "deps": { + "components": [], + "third_party": [] + }, + "build": { + "sub_component": [ + "//applications/sample/hello:helloworld" + ], + "inner_kits": [], + "test": [] + } + } + } + ``` + + The **bundle.json** file consists of two parts. The first part describes the information about the subsystem to which the component belongs, and the second part defines the component building configuration. When adding a part, you need to specify the **sub_component** contained in the part. If there are interfaces provided for other components, describe them in **inner_kits**. If there are test cases, describe them in **test**. + +3. Modify the subsystem configuration file. + + Add the configuration of the new subsystem to the **build/subsystem_config.json** file. + + + ``` + "sample": { + "path": "applications/sample/hello", + "name": "sample" + }, + ``` + +4. Modify the product configuration file. + + In the **productdefine/common/products/Hi3516DV300.json** file, add the **hello** part after the existing part. + + + ``` + "usb:usb_manager_native":{}, + "applications:prebuilt_hap":{}, + "sample:hello":{}, + "wpa_supplicant-2.9:wpa_supplicant-2.9":{}, + ``` diff --git a/en/device-dev/quick-start/quickstart-standard-running-hi3516-running.md b/en/device-dev/quick-start/quickstart-standard-running-hi3516-running.md new file mode 100644 index 0000000000000000000000000000000000000000..0250be6bc66f78463cd207038e2f98e29369f7b7 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-hi3516-running.md @@ -0,0 +1,58 @@ +# Running + + +## Starting the System + +After the burning is complete, perform the following steps to start the system in Windows: + +> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** +> This operation procedure is required only if this is the first time you burn an image for the standard system. + +1. In DevEco Device Tool, click **Monitor** to open the serial port tool. + + ![en-us_image_0000001226762374](figures/en-us_image_0000001226762374.png) + +2. Restart the development board. Before the autoboot countdown ends, press any key to enter the system. + + ![en-us_image_0000001271442265](figures/en-us_image_0000001271442265.gif) + +3. Run the following commands to set system boot parameters: + + ``` + setenv bootargs 'mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused rootdelay=10 hardware=Hi3516DV300 init=/init root=/dev/ram0 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),2M(misc),3307M(system),256M(vendor),-(userdata)'; + ``` + + + ``` + setenv bootcmd 'mmc read 0x0 0x82000000 0x800 0x4800; bootm 0x82000000' + ``` + + ![en-us_image_0000001271322437](figures/en-us_image_0000001271322437.png) + +4. Save the parameter settings. + + ``` + save + ``` + + ![en-us_image_0000001271562437](figures/en-us_image_0000001271562437.png) + +5. Restart the development board to start the system. + + ``` + reset + ``` + + ![en-us_image_0000001226762378](figures/en-us_image_0000001226762378.png) + + +## Running a Hello World Program + +After the system is started, start the serial port tool, run the **helloworld** command in any directory, and press **Enter**. If the message "Hello World!" is displayed, the program runs successfully. + +![en-us_image_0000001226602398](figures/en-us_image_0000001226602398.png) + + +## Next + +Congratulations! You have finished all steps! Proceed to [develop a sample](../guide/device-clock-guide.md) to better familiarize yourself with OpenHarmony development. diff --git a/en/device-dev/quick-start/quickstart-standard-running-hi3516.md b/en/device-dev/quick-start/quickstart-standard-running-hi3516.md new file mode 100644 index 0000000000000000000000000000000000000000..e85603a4bcf66366ee435fe6ffc744c2f4385691 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-hi3516.md @@ -0,0 +1,11 @@ +# Hi3516 Development Board + + + +- **[Writing a Hello World Program](quickstart-standard-running-hi3516-create.md)** + +- **[Building](quickstart-standard-running-hi3516-build.md)** + +- **[Burning](quickstart-standard-running-hi3516-burning.md)** + +- **[Running](quickstart-standard-running-hi3516-running.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-running-rk3568-build.md b/en/device-dev/quick-start/quickstart-standard-running-rk3568-build.md new file mode 100644 index 0000000000000000000000000000000000000000..7d1ad531ba40dec89afb7181ba192c4617d62bd4 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-rk3568-build.md @@ -0,0 +1,48 @@ +# Building + + +You can build source code with hb or the **build.sh** script. This section exemplifies how to build source code with hb. For details about how to build with the **build.sh** script, see [Building Source Code Using the build.sh Script](../quick-start/quickstart-standard-reference.md). + + +Go to the root directory of the source code in the Ubuntu environment and perform the following steps: + + +1. Set the build path. + + ``` + hb set + ``` + +2. Select the current path. + + ``` + . + ``` + +3. Select **rk3568** under **built-in** and press **Enter**. + +4. Start building. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > - To build a component (for example, **hello**), run the **hb build -T _ Target name _** command. + > + > - To build a product incrementally, run the **hb build** command. + > + > - To build a product from the scratch, run the **hb build -f** command. + > + > This example builds a product from the scratch. + + + ``` + hb build -f + ``` + + + **Figure 1** RK3568 build settings + + ![en-us_image_0000001226922302](figures/en-us_image_0000001226922302.png) + +5. Check the build result. If "rk3568 build success" is displayed, the building is successful. + + > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **NOTICE** + > The build result and log files are stored in **out/rk3568**. diff --git a/en/device-dev/quick-start/quickstart-standard-running-rk3568-burning.md b/en/device-dev/quick-start/quickstart-standard-running-rk3568-burning.md new file mode 100644 index 0000000000000000000000000000000000000000..c1df3e3dcb43bb071ca833fb5cc9f3ee0da62f61 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-rk3568-burning.md @@ -0,0 +1,91 @@ +# Burning + + +To burn source code to RK3568 on Windows, perform the following steps: + + +### Importing Source Code + +After the building is complete, ensure that you can [remotely access the Ubuntu environment from Windows](../quick-start/quickstart-standard-env-setup.md). Then, perform the following steps to import the source code before burning: + +1. Open DevEco Device Tool, go to the home page, and click **Import Project** to open your project or source code. + + ![en-us_image_0000001171426014](figures/en-us_image_0000001171426014.png) + +2. Select the target directory (in the Ubuntu environment) and click **Import**. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Make sure the selected directory does not contain Chinese characters or spaces. Otherwise, the building may fail. + + ![en-us_image_0000001272032361](figures/en-us_image_0000001272032361.png) + +3. If you select to open the OpenHarmony source code, a message will be displayed indicating that the project is not a DevEco Device Tool project. Click **Import** to continue. + + ![en-us_image_0000001135394334](figures/en-us_image_0000001135394334.png) + +4. On the **Select Project type** page, select **Import from OpenHarmony Source**. + + ![en-us_image_0000001215743910](figures/en-us_image_0000001215743910.png) + +5. On the **Import Project** page, select a product, and the MCU, board, company, and kernel fields will be automatically populated. Then, select the OpenHarmony source code version for **ohosVersion**. Select **rk3568**. + + ![en-us_image_0000001227712350](figures/en-us_image_0000001227712350.png) + +6. Click **Open** to open the project or source code. + + +### Burning + +After the source code is imported, perform the following steps: + +1. [Download](https://gitee.com/hihope_iot/docs/blob/master/HiHope_DAYU200/%E7%83%A7%E5%86%99%E5%B7%A5%E5%85%B7%E5%8F%8A%E6%8C%87%E5%8D%97/windows/DriverAssitant_v5.1.1.zip) **DriverInstall.exe**. Double-click **DriverInstall.exe** to open the installer. Then click the install button to install the USB driver as prompted. + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > If the burning tool of an earlier version has been installed, uninstall it first. + +2. Connect the computer to the target development board through the USB port. + +3. In DevEco Device Tool, choose **REMOTE DEVELOPMENT** > **Local PC** to check the connection status between the remote computer (Ubuntu build environment) and the local computer (Windows build environment). + + - If ![en-us_image_0000001261315939](figures/en-us_image_0000001261315939.png) is displayed on the right of **Local PC**, the remote computer is connected to the local computer. Inthis case, no further action is required. + - If ![en-us_image_0000001261515989](figures/en-us_image_0000001261515989.png) is displayed, click the connect icon. + + ![en-us_image_0000001261395999](figures/en-us_image_0000001261395999.png) + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > This operation is required only in remote access mode (in the Windows+Ubuntu hybrid build environment). If the local access mode (Windows or Ubuntu build environment) is used, skip this step. + +4. In DevEco Device Tool, choose QUICK ACCESS > DevEco Home > Projects, and then click Settings. + + ![en-us_image_0000001239661509](figures/en-us_image_0000001239661509.png) + +5. On the **hh_scdy200** tab page, set the burning options. + + - **upload_partitions**: Select the files to be burnt. + - **upload_protocol**: Select the burning protocol **upgrade**. + + ![en-us_image_0000001194504874](figures/en-us_image_0000001194504874.png) + +6. Check the preset information of the files to be burnt and modify them when necessary. The files to be burnt include **loader**, **parameter**, **uboot**, **boot_linux**, **system**, **vendor**, and **userdata**. + + 1. On the **hh_scdy200_loader** tab, select the items to be modified in **New Option**, such as **partition_bin**, **partition_addr**, and **partition_length**. + + ![en-us_image_0000001224173270](figures/en-us_image_0000001224173270.png) + + 2. In **Partition Options**, modify the items selected in the preceding step. + + > ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** + > Set the start address and length of the partition based on the size of the files to be burnt. Make sure the size of the partition is greater than that of the files to be burnt and the partition addresses of the files to be burnt do not overlap. + + ![en-us_image_0000001268653461](figures/en-us_image_0000001268653461.png) + + 3. Follow the same procedure to modify the information about the **parameter**, **uboot**, **boot_linuxv, **system**, **vendor**, and **userdata** files. + +7. When you finish modifying, click **Save** on the top. + +8. Click **Open** to open the project file. Click ![en-us_image_0000001239221905](figures/en-us_image_0000001239221905.png) to open DevEco Device Tool. Then, choose **PROJECT TASKS** > **hh_scdy200** > **Upload** to start burning. + + ![en-us_image_0000001194821710](figures/en-us_image_0000001194821710.png) + +9. Wait until the burning is complete. If the following message is displayed, the burning is successful. + + ![en-us_image_0000001194984912](figures/en-us_image_0000001194984912.png) diff --git a/en/device-dev/quick-start/quickstart-standard-running-rk3568-create.md b/en/device-dev/quick-start/quickstart-standard-running-rk3568-create.md new file mode 100644 index 0000000000000000000000000000000000000000..523e9f334d4269af91a3244470d4d8438f14fe06 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-rk3568-create.md @@ -0,0 +1,159 @@ +# Writing a Hello World Program + + +The following exemplifies how to run the first program on the development board. The created program outputs the message "Hello World!" . + + +## Example Directory + + The complete code directory is as follows: + +``` +applications/sample/hello +│ │── BUILD.gn +│ │── include +│ │ └── helloworld.h +│ │── src +│ │ └── helloworld.c +│ └── bundle.json +build +└── subsystem_config.json +productdefine/common +└── products + └── rk3568.json +``` + + +## How to Develop + +Perform the steps below in the source code directory: + +1. Create a directory and write the service code. + + Create the **applications/sample/hello/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **World** to **OH**. Declare the string printing function **HelloPrint** in the **helloworld.h** file. You can use either C or C++ to develop a program. + + + ``` + #include + #include "helloworld.h" + + int main(int argc, char **argv) + { + HelloPrint(); + return 0; + } + + void HelloPrint() + { + printf("\n\n"); + printf("\n\t\tHello World!\n"); + printf("\n\n"); + } + ``` + + Add the header file **applications/sample/hello/include/helloworld.h**. The sample code is as follows: + + + ``` + #ifndef HELLOWORLD_H + #define HELLOWORLD_H + #ifdef __cplusplus + #if __cplusplus + extern "C" { + #endif + #endif + + void HelloPrint(); + + #ifdef __cplusplus + #if __cplusplus + } + #endif + #endif + #endif // HELLOWORLD_H + ``` + +2. Create a build file. + + 1. Create the **applications/sample/hello/BUILD.gn** file. The file content is as follows: + + ``` + import("//build/ohos.gni") # Import the build template. + ohos_executable("helloworld") {# Executable module. + sources = [ # Source code of the module. + "src/helloworld.c" + ] + include_dirs = [ # Directory of header file on which the module depends. + "include" + ] + cflags = [] + cflags_c = [] + cflags_cc = [] + ldflags = [] + configs = [] + deps =[] # Internal dependencies of a component. + part_name = "hello" # Component name. This parameter is mandatory. + install_enable = true # Whether to install the software by default. This parameter is optional. By default, the software is not installed. + } + ``` + 2. Create the **applications/sample/hello/bundle.json** file and add the description of the **sample** component. The content is as follows: + + ``` + { + "name": "@ohos/hello", + "description": "Hello world example.", + "version": "3.1", + "license": "Apache License 2.0", + "publishAs": "code-segment", + "segment": { + "destPath": "applications/sample/hello" + }, + "dirs": {}, + "scripts": {}, + "component": { + "name": "hello", + "subsystem": "sample", + "syscap": [], + "features": [], + "adapted_system_type": [ "mini", "small", "standard" ], + "rom": "10KB", + "ram": "10KB", + "deps": { + "components": [], + "third_party": [] + }, + "build": { + "sub_component": [ + "//applications/sample/hello:helloworld" + ], + "inner_kits": [], + "test": [] + } + } + } + ``` + + The **bundle.json** file consists of two parts. The first part describes the information about the subsystem to which the component belongs, and the second part defines the component building configuration. When adding a part, you need to specify the **sub_component** contained in the part. If there are interfaces provided for other components, describe them in **inner_kits**. If there are test cases, describe them in **test**. + +3. Modify the subsystem configuration file. + + Add the configuration of the new subsystem to the **build/subsystem_config.json** file. + + + ``` + "sample": { + "path": "applications/sample/hello", + "name": "sample" + }, + ``` + +4. Modify the product configuration file. + + In the **productdefine/common/products/rk3568.json** file, add the **hello** part after the existing part. + + ``` + "usb:usb_manager_native":{}, + "applications:prebuilt_hap":{}, + "sample:hello":{}, + "wpa_supplicant-2.9:wpa_supplicant-2.9":{}, + ``` diff --git a/en/device-dev/quick-start/quickstart-standard-running-rk3568-running.md b/en/device-dev/quick-start/quickstart-standard-running-rk3568-running.md new file mode 100644 index 0000000000000000000000000000000000000000..2bfc15ab545abff3b0dab5d3ba164919fbc2cd18 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-rk3568-running.md @@ -0,0 +1,21 @@ +# Running + + +## Starting the System + +After the image is burnt and the development board is restarted, the system automatically starts. If the following page is displayed on the screen of the development board, the system is running properly. + + **Figure 1** System startup effect + + ![en-us_image_0000001226602406](figures/en-us_image_0000001226602406.jpg) + + +## Running a Hello World Program + +1. When the system is running, start the serial port tool (for example, PuTTY), set the baud rate to **1500000**, and connect to the device. + + ![en-us_image_0000001226922310](figures/en-us_image_0000001226922310.png) + +2. Enable the serial port, enter the **helloworld** command in any directory (for example, the root directory of the device) and press **Enter**. If the message "Hello World!" is displayed, the program runs successfully. + + ![en-us_image_0000001271202465](figures/en-us_image_0000001271202465.png) diff --git a/en/device-dev/quick-start/quickstart-standard-running-rk3568.md b/en/device-dev/quick-start/quickstart-standard-running-rk3568.md new file mode 100644 index 0000000000000000000000000000000000000000..c13877b26bb7cd3b50ec6e9970d3238db6c59bc1 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-running-rk3568.md @@ -0,0 +1,11 @@ +# RK3568 Development Board + + + +- **[Writing a Hello World Program](quickstart-standard-running-rk3568-create.md)** + +- **[Building](quickstart-standard-running-rk3568-build.md)** + +- **[Burning](quickstart-standard-running-rk3568-burning.md)** + +- **[Running](quickstart-standard-running-rk3568-running.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-running.md b/en/device-dev/quick-start/quickstart-standard-running.md index c806e674a835704a177404e55aae180209284c87..7bde76093cd3c045e32170c48de635388bcd7e0d 100644 --- a/en/device-dev/quick-start/quickstart-standard-running.md +++ b/en/device-dev/quick-start/quickstart-standard-running.md @@ -1,50 +1,7 @@ -# Running an Image +# Running a Hello World Program -## Running an Image -After the image burning is complete, perform the following steps to run the system: ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->This operation procedure is required only if this is the first time you burn an image for the standard system. - -1. In DevEco Device Tool, click **Monitor** to open the serial port tool. - - ![](figures/open-the-serial-port-tool.png) - -2. Restart the development board. Before the autoboot countdown ends, press any key to enter the system. - - ![](figures/press-any-key-to-enter-the-system.gif) - -3. Run the following commands to set system boot parameters: - - ``` - setenv bootargs 'mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused rootdelay=10 hardware=Hi3516DV300 init=/init root=/dev/ram0 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),2M(misc),3307M(system),256M(vendor),-(userdata)'; - ``` - - ``` - setenv bootcmd 'mmc read 0x0 0x82000000 0x800 0x4800; bootm 0x82000000' - ``` - - ![](figures/setenv-bootargs.png) - -4. Save the parameter settings. - - ``` - save - ``` - - ![](figures/save-the-parameter-settings.png) - -5. Restart the development board to start the system. - - ``` - reset - ``` - - ![](figures/start-the-system.png) - - -## Next - -Congratulations! You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Clock App](../guide/device-clock-guide.md). +- **[Hi3516 Development Board](quickstart-standard-running-hi3516.md)** +- **[RK3568 Development Board](quickstart-standard-running-rk3568.md)** diff --git a/en/device-dev/quick-start/quickstart-standard-sourcecode-acquire.md b/en/device-dev/quick-start/quickstart-standard-sourcecode-acquire.md new file mode 100644 index 0000000000000000000000000000000000000000..53b2301eb0f43b72bd7d94404135633e7a6a5e66 --- /dev/null +++ b/en/device-dev/quick-start/quickstart-standard-sourcecode-acquire.md @@ -0,0 +1,49 @@ +# Obtaining Source Code + +### Prerequisites + +1. Register your account with Gitee. +2. Register an SSH public key for access to Gitee. +3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. + + ``` + git config --global user.name "yourname" + git config --global user.email "your-email-address" + git config --global credential.helper store + ``` + +4. Run the following commands to install the **repo** tool: + + ``` + curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 -o /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable. + chmod a+x /usr/local/bin/repo + pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests + ``` + + +### How to Obtain + +>![](../public_sys-resources/icon-note.gif) **NOTE**
+>Download the master code if you want to get quick access to the latest features for your development. Download the release code, which is more stable, if you want to develop commercial functionalities. + +- **Obtaining OpenHarmony master code** + + Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\) + + ``` + repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + + Method 2: Use the **repo** tool to download the source code over HTTPS. + + ``` + repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo sync -c + repo forall -c 'git lfs pull' + ``` + +- **Obtaining OpenHarmony release code** + + For details about how to obtain the source code of an OpenHarmony release, see the [Release-Notes](../get-code/../../release-notes/Readme.md). diff --git a/en/device-dev/quick-start/quickstart-standard.md b/en/device-dev/quick-start/quickstart-standard.md index e939227a4b3f8d152ec892f06ee37bc1b816e45b..b66899afd7e5b3c0e5acd1600115bc9c12ce2e14 100644 --- a/en/device-dev/quick-start/quickstart-standard.md +++ b/en/device-dev/quick-start/quickstart-standard.md @@ -1,17 +1,6 @@ -# Standard System +# Getting Started with Standard System -- **[Introduction](quickstart-standard-overview.md)** - -- **[Setting Up a Windows Development Environment](quickstart-standard-windows-environment.md)** - -- **[Setting Up a Ubuntu Development Environment in Docker Mode](quickstart-standard-docker-environment.md)** - -- **[Setting Up a Ubuntu Development Environment Using the Installation Package](quickstart-standard-package-environment.md)** - -- **[Burning Images](quickstart-standard-burn.md)** - -- **[Running an Image](quickstart-standard-running.md)** - -- **[FAQs](quickstart-standard-faqs.md)** +- **[Getting Started with Standard System (IDE Mode)](quickstart-standard-ide-directory.md)** +- **[Getting Started with Standard System (Installation Package Mode)](quickstart-standard-package-directory.md)** diff --git a/en/device-dev/quick-start/quickstart.md b/en/device-dev/quick-start/quickstart.md index 3f82098be9f28557fc6a223f770197f21ee07c31..13fe6384e1491db3a347b4ef5784e37a75fd37a9 100644 --- a/en/device-dev/quick-start/quickstart.md +++ b/en/device-dev/quick-start/quickstart.md @@ -1,7 +1,7 @@ -# Getting Started +# Getting Started -- **[Mini and Small Systems](quickstart-lite.md)** -- **[Standard System](quickstart-standard.md)** +- **[Getting Started with Mini and Small Systems](quickstart-lite.md)** +- **[Getting Started with Standard System](quickstart-standard.md)** diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md index d684a73e18b78c3d474465598398e051d8911a3e..9d104caf788042687399bc711b8d4de72d27f074 100644 --- a/en/device-dev/subsystems/Readme-EN.md +++ b/en/device-dev/subsystems/Readme-EN.md @@ -67,9 +67,10 @@ - [Development Guidelines](development-guidelines.md) - [Security](subsys-security.md) - [Overview](subsys-security-overview.md) - - [Development Guidelines on Application Signature Verification](subsys-security-sigverify.md) - - [Development Guidelines on Application Permission Management](subsys-security-rightmanagement.md) - - [Development Guidelines on IPC Authentication](subsys-security-communicationverify.md) + - [Development on Application Signature Verification](subsys-security-sigverify.md) + - [Development on Application Permission Management](subsys-security-rightmanagement.md) + - [Development on IPC Authentication](subsys-security-communicationverify.md) + - [Development on Device Security Level Management](subsys-security-devicesecuritylevel.md) - [Startup](subsys-boot.md) - [Startup](subsys-boot-overview.md) - [init Module](subsys-boot-init.md) @@ -95,5 +96,4 @@ - [R&D Tools](subsys-toolchain.md) - [bytrace Usage Guidelines](subsys-toolchain-bytrace-guide.md) - [hdc\_std Usage Guidelines](subsys-toolchain-hdc-guide.md) - - [hiperf Usage Guidelines](subsys-toolchain-hiperf.md) - [XTS](subsys-xts-guide.md) \ No newline at end of file diff --git a/en/device-dev/subsystems/subsys-application-framework-envbuild.md b/en/device-dev/subsystems/subsys-application-framework-envbuild.md index 54a1a61ee4dc397549fe03d2337111b792586ca4..9f3d03aeee99e9067dada2cf09c2969157e9fe68 100644 --- a/en/device-dev/subsystems/subsys-application-framework-envbuild.md +++ b/en/device-dev/subsystems/subsys-application-framework-envbuild.md @@ -2,7 +2,6 @@ - Development board: Hi3516D V300 -- Download the source code - -- Build the application framework +- [Obtain source code](../get-code/sourcecode-acquire.md). +- [Build the application framework](../../readme/bundle-management.md). diff --git a/en/device-dev/subsystems/subsys-boot-appspawn-standard.md b/en/device-dev/subsystems/subsys-boot-appspawn-standard.md index 06019edbb3695df60f5a9d3c0aa8022d6f6e569e..1defe3cf035c92647a870b72f6c73c5cf3e7418c 100644 --- a/en/device-dev/subsystems/subsys-boot-appspawn-standard.md +++ b/en/device-dev/subsystems/subsys-boot-appspawn-standard.md @@ -62,7 +62,7 @@ After being started by the init process, the appspawn process waits for inter-pr

gidTable

Information about the application process group to be started. Its length is specified by **gidCount**. A maximum of 64 process groups are supported. The value must be a positive number.

+

Information about the application process group to be started. Its length is specified by gidCount. A maximum of 64 process groups are supported. The value must be a positive number.

gidCount

@@ -89,8 +89,8 @@ After being started by the init process, the appspawn process waits for inter-pr ### Available APIs -**Table 2** Available APIs -

Field

+**Table 2** API description + diff --git a/en/device-dev/subsystems/subsys-dfx-hilog-rich.md b/en/device-dev/subsystems/subsys-dfx-hilog-rich.md index 79ad099abc4c457820e28c8929622135930728a9..e9d31ea25c72e2b253f00f8e0aaa1db95050cb2a 100644 --- a/en/device-dev/subsystems/subsys-dfx-hilog-rich.md +++ b/en/device-dev/subsystems/subsys-dfx-hilog-rich.md @@ -4,11 +4,11 @@ HiLog is the log system of OpenHarmony that provides logging for the system framework, services, and applications to record information on user operations and system running status. -This development guide is applicable to Standard-System Devices \(reference memory ≥ 128 MB\). +This development guide is applicable to standard-system devices \(reference memory ≥ 128 MB\). ## Available APIs -**Table 1** Description of C++ and C APIs +**Table 1** List of C++ and C APIs

API

Description

C++

diff --git a/en/device-dev/subsystems/subsys-security-overview.md b/en/device-dev/subsystems/subsys-security-overview.md index 52a022fdfc2d138c84b46aca02648d7e9f8c6039..7746a8d2680e3621551e3619ff6225dd58640518 100644 --- a/en/device-dev/subsystems/subsys-security-overview.md +++ b/en/device-dev/subsystems/subsys-security-overview.md @@ -1,60 +1,57 @@ -# Overview +# Overview The OpenHarmony security subsystem provides security capabilities that make your applications and devices more secure and help you manage permissions. This subsystem has the following modules: -- Application signature verification - To ensure the content integrity of applications, the system controls sources of the applications through application signatures and profiles. For a debugging application, the system uses the signature verification API to check whether the Unique Device Identifier (UDID) of the application matches that of the device, so as to ensure that the application is installed on the right device. +- Application signature verification -- Application permission management + To ensure the content integrity of applications, the system controls sources of the applications through application signatures and profiles. For a debugging application, the system uses the signature verification API to check whether the Unique Device Identifier (UDID) of the application matches that of the device, so as to ensure that the application is installed on the right device. - Application permissions determine what system resources and capabilities an application can access. During application development, you need to declare the permissions that the application may require in the **profile.json** file. Static permissions need to be registered during application installation, while dynamic permissions usually involve sensitive information and need users' dynamic authorization. +- Application permission management -- Trusted device group management + Application permissions determine what system resources and capabilities an application can access. During application development, you need to declare the permissions that the application may require in the profile.json file. Static permissions need to be registered during application installation, while dynamic permissions usually involve sensitive information and need users' dynamic authorization. - You can create and query a group of trusted devices that use the same HUAWEI ID or a peer-to-peer group created by scanning a QR code or using OneHop. With this capability, distributed applications can perform trusted authentication between devices and request from the distributed virtual bus for secure sessions between devices. +- Inter-process communication (IPC) authentication -- DSLM + The caller that attempts to invoke the APIs provided by system services through IPC must be authenticated. The system services registered with Samgr can expose APIs to other processes through IPC, with access policies configured. When other processes attempt to call these APIs, the IPC authentication mechanism will be triggered. If the processes do not have the access permission, the access request will be rejected. - The OpenHarmony Device Security Level Management (DSLM) module manages the security levels of OpenHarmony devices. When different types of user data are hopped or processed in OpenHarmony distributed services, the DSLM APIs can be called to obtain the security levels of related devices for subsequent processing. +- DSLM + The Device Security Level Management (DSLM) module is introduced to manage the security levels of OpenHarmony devices. When different types of user data are hopped or processed in OpenHarmony distributed services, the DSLM APIs can be called to obtain the security levels of related devices for subsequent processing. -## Basic Concepts -Before developing an application that depends on the signature verification component, you should understand the following basic concepts: - -- Samgr - - System Ability Manager (Samgr) is a module of OpenHarmony for managing system capabilities. For details, see the Application Framework development guidelines. +## Basic Concepts +Before developing an application that depends on the signature verification component, you should understand the following basic concepts: -- BMS - - Bundle Manager Service (BMS) manages application installation, uninstallation, and data on OpenHarmony. +- Samgr + System Ability Manager (Samgr) is a module of OpenHarmony for managing system capabilities. For details, see the Application Framework development guidelines. -- Profile +- BMS - The profile in this document refers to HarmonyAppProvision (profile for short). HarmonyAppProvision is in JSON format. + Bundle Manager Service (BMS) manages application installation, uninstallation, and data on OpenHarmony. +- Profile -- Debugging application + The profile in this document refers to HarmonyAppProvision, which is in JSON format. - A debugging application is a HarmonyOS Ability Package (HAP) that is signed with a debugging certificate and profile obtained from the application market. +- Debug application + A debug application is an OpenHarmony Ability Package (HAP) that is signed with a debug certificate and profile obtained from the application store. -- Released application +- Release application - This application refers to a HAP that is signed with a distribution certificate and profile obtained from the application market, but has been released in the application market. + A release application is a HAP that is signed with a release certificate and profile obtained from the application store, and formally released in the application store. +- OpenHarmony self-signed application -- OpenHarmony self-signed application + A self-signed application is an application that is signed with the signing certificate and profile issued by OpenHarmony's open-source root CA, which is composed of a certificate and a key. - A self-signed application is one that has been signed with the signing certificate and profile issued by OpenHarmony's open-source root CA, which consists of a certificate and a key. +## Constraints -## Constraints +- Only signatures of the debug, release, and OpenHarmony self-signed applications can be verified. -- Only signatures of debugging, released, and OpenHarmony self-signed applications can be verified. -- To verify the signature of a debugging application, the UDID of the device on which the debugging application is installed must be in the UDID list contained in the profile. +- To verify the signature of a debug application, the UDID of the device on which the debug application is installed must be in the UDID list contained in the profile. diff --git a/en/device-dev/subsystems/subsys-security.md b/en/device-dev/subsystems/subsys-security.md index 0a63d0bb54fa3734ee51d1b2a7c0e2744085d1c7..1ea65be900fc2a6f2bbaa97c697d6c22a33e3230 100644 --- a/en/device-dev/subsystems/subsys-security.md +++ b/en/device-dev/subsystems/subsys-security.md @@ -2,7 +2,7 @@ - **[Overview](subsys-security-overview.md)** -- **[Development on Application Signature Verification] (subsys-security-sigverify.md)** +- **[Development on Application Signature Verification](subsys-security-sigverify.md)** - **[Development on Application Permission Management](subsys-security-rightmanagement.md)** diff --git a/en/device-dev/subsystems/subsys-toolchain-hiperf.md b/en/device-dev/subsystems/subsys-toolchain-hiperf.md deleted file mode 100644 index 213f606ba2163da611bd074e5aba5c89cb5b3718..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/subsys-toolchain-hiperf.md +++ /dev/null @@ -1,535 +0,0 @@ -# hiperf - -- [list](#section121805449461) - - [Parameters](#section42124492494) - - [Example](#section122129443486) - -- [stat](#section12940163061016) - - [Parameters](#section36541920145018) - - [Example](#section1132495515502) - - [Field Description](#section1958985055118) - -- [record](#section168751927524) - - [Parameters](#section113617912522) - - [Example](#section15998181516549) - -- [report](#section16327635174818) -- [Example](#section1197655116513) - -hiperf is a performance sampling and analysis tool provided for developers. It extends the user-mode capabilities based on the kernel perf mechanism and can conduct performance sampling of the specified application or the entire system. - -You can run the **hiperf -h** command to display the commands supported by hiperf. - -The following describes the common commands \(**list**, **stat**, **record**, and **report**\) supported by hiperf. - -## list - -### Parameters - -The **list** command lists all the perf events supported by the device. The event names are used for the **-e** and **-g** parameters of the **stat** and **record** commands. - -``` -hiperf list [event type] -``` - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

hw

-

Lists the hardware events supported by the performance monitoring unit (PMU).

-

sw

-

Lists the software events supported.

-

tp

-

Lists the tracepotint events supported.

-

cache

-

Lists the cache events supported by the PMU.

-

raw

-

Lists the raw PMU events supported.

-
- -### Example - -List the hardware events supported by the PMU. The command also lists the events that are not supported by the PMU. - -``` -hiperf list hw -event not support hw-stalled-cycles-backend -event not support hw-stalled-cycles-frontend -event not support hw-ref-cpu-cycles - -Supported events for hardware: - hw-cpu-cycles - hw-instructions - hw-cache-references - hw-cache-misses - hw-branch-instructions - hw-branch-misses - hw-bus-cycles -``` - -## stat - -### Parameters - -The **stat** command monitors the specified application and periodically prints the values of performance counters. - -``` -hiperf stat [options] - Collect performance counter information. -``` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-a

-

Collects the values of all threads and default performance counters of the system.

-

-c

-

Specifies the IDs of the CPUs to monitor. Use commas (,) to separate multiple CPU IDs, for example 0,1,2.

-

-d <sec>

-

Specifies the monitoring period, in seconds.

-

-i <ms>

-

Specifies the interval for printing the monitored events, in milliseconds.

-

-e

-

Specifies the events to monitor. You can run the list command to list all the events supported. event:u indicates an event in the user space, and event:k indicates an event in the kernel space.

-

-g

-

Specifies a group of events to monitor. The events in the same group are monitored by the same PMU.

-

--no-inherit

-

Leaves the sub-threads of the target thread or process not monitored.

-

-p

-

Specifies the process IDs (PIDs) to monitor.

-

-t

-

Specifies the thread IDs (TIDs) to monitor.

-

--verbose

-

Displays detailed report, including raw time data.

-
- -### Example - -Monitor the entire system for 3 seconds. - -``` -hiperf stat -d 3 -a -this is root mode, perfEventParanoid assume as -1 -Start Profiling... -Timeout exit (total 3009 ms) - count name | comment | coverage - 132523 hw-branch-instructions | 15.750 M/sec | (100%) - 62554 hw-branch-misses | 47.202372% miss rate | (100%) - 6994768 hw-cpu-cycles | 0.832068 GHz | (100%) - 1237627 hw-instructions | 5.651758 cycles per instruction | (100%) - 248 sw-context-switches | 29.959 K/sec | (100%) - 0 sw-page-faults | 0.000 /sec | (100%) - 9402580 sw-task-clock | 0.002758 cpus used | (100%) -``` - -### Field Description - - - - - - - - - - - - - - - - - - - -

Field

-

Description

-

count

-

Indicates the times that an event occurred.

-

name

-

Indicates the event name. You can run the list command to list all the supported events. hw stands for hardware, and sw stands for software.

-

comment

-

Provides values calculated from those in the Count column for easy understanding. For example, the CPU frequency (hw-cpu-cycles) is converted to 0.832068 GHz from 6994768.

-

coverage

-

Indicates the percentage of PMU resources occupied by the event. The number of events to be monitored by a PMU varies depending on the number of PMUs.

-
- -## record - -### Parameters - -The **record** command samples the specified application and saves the sampling data to a file \(**perf.data** by default\). - -``` -hiperf record [options] - Collect performance sampling information. -``` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-a

-

Samples all processes and threads in the system.

-

--exclude-hiperf

-

Leaves the hiperf process not sampled.

-

-c

-

Specifies the IDs of the CPUs to sample.

-

--cpu-limit <percent>

-

Specifies the maximum percentage of CPU resources occupied by the sampling.

-

-d <sec>

-

Specifies the sampling duration, in seconds.

-

-f <freq>

-

Specifies how often a sampling event is triggered. The default value is 4000 times/second.

-

Note: A higher value indicates heavier CPU load but more sampling data.

-

--period <num>

-

Specifies the number of occurrence times of an event that triggers a sampling. That is, a sampling is performed once when the event occurs the specified number of times.

-

-e

-

Specifies the events to monitor. You can run the list command to list all the events supported. event:u indicates an event in the user space, and event:k indicates an event in the kernel space.

-

-g

-

Specifies a group of events to monitor. The events in the same group are monitored by the same PMU.

-

--no-inherit

-

Leaves the sub-threads of the target thread or process not monitored.

-

-p

-

Specifies the processes to monitor.

-

-t

-

Specifies the threads to monitor.

-

--offcpu

-

Monitors the CPU scheduling event, which is equivalent to the --period 1 -e sched:sched_switch event.

-

-j <branch_filter1>[,branch_filter2]...

-

Monitors the branch prediction events. Branch prediction tries to predict the next instruction to be executed if there are multiple if else conditions.

-

-s / --call-stack <fp \| dwarf[,size]>

-

Sets the user stack unwinding mode, which can be fp or dwarf. If dwarf is used, you can specify the size of the user stack to be sampled. The default value is 65528.

-

--delay-unwind

-

Delays the stack unwinding till the sampling is complete.

-

--disable-unwind

-

Disables stack unwinding. The user register and stack data is stored in perf.data for offline stack unwinding.

-

--disable-callstack-expend

-

Disables the unwound call stack information from being combined or extended.

-

--clockid <clock type>

-

Sets the clock source for the sampling data. The options are monotonic, boottime, and realtime.

-

--symbol-dir <dir>

-

Specifies the directory of the symbol table. The specified symbol table will be preferentially used in stack unwinding.

-

-m <mmap pages>

-

Specifies the cache size, in pages. The default value is 1024. The parameter value must be a power of 2. The value range is [2 - 1024].

-

Note: A higher value indicates a lower event loss rate but higher memory usage.

-

--app <package name>

-

Specifies the bundle name of the target application to be sampled. The default timeout interval is 10 seconds. If the specified application does not exist, the hiperf process exits after 10 seconds.

-

--data-limit <SIZE[K|M|G]>

-

Specifies the maximum size of the sampling result, in KB, MB, or GB. By default, there is no limit on the size.

-

-o <output file name>

-

Specifies the name of the sampling result file. It is /data/local/tmp/perf.data by default.

-

-z

-

Saves the output file in .gzip format.

-

--verbose

-

Displays detailed log information during sampling.

-
- -### Example - -- Sample all processes in the system for 3 seconds and display detailed log information during the sampling process. - - ``` - hiperf record -d 3 -a --verbose - ``` - - -- Enable stack unwinding in fp mode. - - ``` - hiperf record -s fp -d 3 -a - ``` - -- Enable stack unwinding in dwarf mode. - - ``` - hiperf record -s dwarf -d 3 -a - ``` - -- Sample offcpu events. - - ``` - hiperf record --offcpu -s dwarf -d 3 -a - ``` - -- Delay stack unwinding. - - ``` - hiperf record -d 3 -s dwarf --delay-unwind -a - ``` - -- Disable stack unwinding. In this case, the stack data is saved to the **perf.data** file. - - ``` - hiperf record -d 3 -s dwarf --disable-unwind -a - ``` - -- Monitor the **com.ohos.launch** application. The hiperf process exits after 10 seconds if the process corresponding to the specified bundle name does not exist. - - ``` - hiperf record -d 3 -s dwarf --app com.ohos.launch - ``` - -- Compress the sampling results. - - ``` - hiperf record -z -s dwarf -d 3 -a - ``` - - -## report - -The **report** command displays the sampling data that is captured by using **record**. - -``` -hiperf report [option] - Report sampling information from perf.data. -``` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

--symbol-dir <dir>

-

Specifies the directory of the symbol table.

-

--limit-percent <number>

-

Specifies the minimum percentage of the result to display. The result that is lower than the minimum percentage is not displayed.

-

-s / --call-stack

-

Displays detailed call stack information.

-

--call-stack-limit-percent <number>

-

Specifies the minimum percentage of the call stack to display. The call stack that is lower than the minimum percentage is not displayed.

-

--proto

-

Converts the perf.data file into the proto format. The default file name is perf.proto.

-

--json

-

Converts the perf.data file into the JSON format. The default file name is perf.json.

-

--branch

-

Displays the report based on the branch prediction result address instead of the IP address of the call stack.

-

--<keys> <keyname1>[,keyname2][,...]

-

Filters and displays reports based on the given keywords. keys can be comms, pids, and tids. For example, --comms hiperf,hilog displays only the records whose process or thread name is hiperf or hilog.

-

--sort <key1>[,key2][,...]

-

Sorts and displays information based on specified keywords, such as pid, tid, and comm. Multiple keywords can be specified.

-

-i <filename>

-

Specifies the sampling data (perf.data by default).

-

-o <filename>

-

Specifies the name of the report to output.

-
- -## Example - -- Output the report of the sampling data \(**perf.data** by default\). - - ``` - hiperf report - ``` - - Output \(example\): - - ``` - Heating count comm pid tid dso func - 5.68% 15073949 hiperf_example_ 1085 1091 /system/lib/ld-musl-arm.so.1 malloc - 2.57% 6834119 hiperf_example_ 1085 1091 [kernel.kallsyms] vector_swi - 2.27% 6013910 hiperf_example_ 1085 1087 /system/lib/ld-musl-arm.so.1 malloc - 2.19% 5805738 hiperf_example_ 1085 1091 /system/lib/ld-musl-arm.so.1 vfprintf - 2.09% 5543362 hiperf_example_ 1085 1091 [kernel.kallsyms] ktime_get_ts64 - report done - ``` - -- Output the call stack report of the sampling data. - - ``` - hiperf report -s - ``` - -- Set the symbol table directory. - - ``` - hiperf report -s --symbol-dir /data/local/tmp - ``` - -- Display only the information containing **libutils.z.so**. - - ``` - hiperf report --dsos libuitls.z.so - ``` - -- Sort the result by **dso**. - - ``` - hiperf report --sort dso - ``` - - diff --git a/en/device-dev/subsystems/subsys-usbservice-demo.md b/en/device-dev/subsystems/subsys-usbservice-demo.md index decf0dad73249125e04804a2674ddb41fa002995..80506e955cea844f4cca1b3552f0f1828fcc77f8 100644 --- a/en/device-dev/subsystems/subsys-usbservice-demo.md +++ b/en/device-dev/subsystems/subsys-usbservice-demo.md @@ -1,4 +1,4 @@ -# USB Usage Example +# USB Usage Demo ``` @@ -183,5 +183,3 @@ int main(int argc, char **argv) return 0; } ``` - - diff --git a/en/device-dev/subsystems/subsys-usbservice-guide.md b/en/device-dev/subsystems/subsys-usbservice-guide.md index aef72208f914db636a4827ea0ff0a06c164c242c..6ccfc2594dafaab234dac597c3aee24b1d60ccb5 100644 --- a/en/device-dev/subsystems/subsys-usbservice-guide.md +++ b/en/device-dev/subsystems/subsys-usbservice-guide.md @@ -1,5 +1,6 @@ # USB Usage Guidelines + The following procedure uses bulk transfer as an example. ## Procedure @@ -42,7 +43,10 @@ ret = g_usbClient.ClaimInterface(pip, interface, true); ``` srvClient.BulkTransfer(pipe, endpoint, vdata, timeout); ``` -**pipe** indicates the pipe for data transfer after the USB device is opened. **endpoint** indicates the endpoint for data transfer on the USB device. **vdata** indicates the binary data block to be transferred or read. **timeout** indicates the timeout duration of data transfer. +- **pipe** indicates the pipe for data transfer of the USB device opened. +- **endpoint** indicates the endpoint for data transfer on the USB device. +- **vdata** indicates the binary data block to be transferred or read. +- **timeout** indicates the timeout duration of data transfer. 7. Close the USB device. diff --git a/en/device-dev/subsystems/subsys-xts-guide.md b/en/device-dev/subsystems/subsys-xts-guide.md index 70951c0d1e3ef8da140f58bdb67831901ce48793..8edb14f97ee25a560587fbe9b875e5b9aaf5d50e 100644 --- a/en/device-dev/subsystems/subsys-xts-guide.md +++ b/en/device-dev/subsystems/subsys-xts-guide.md @@ -2,7 +2,7 @@ ## Introduction -The X test suite \(XTS\) subsystem contains a set of OpenHarmony certification test suites, including the currently supported application compatibility test suite \(ACTS\) and the device compatibility test suite \(DCTS\) that will be supported in the future. +The X test suite \(XTS\) subsystem contains a set of OpenHarmony compatibility test suites, including the currently supported application compatibility test suite \(ACTS\) and the device compatibility test suite \(DCTS\) that will be supported in the future. This subsystem contains the ACTS and **tools** software package. @@ -690,7 +690,7 @@ Install Python 3.7 or a later version on a Windows environment and ensure that t Wait until the test case is complete. -1. View test reports. +3. View test reports. Go to **acts\\reports\\**, obtain the current execution record, and open **summary\_report.html** to view the test report. diff --git a/en/device-dev/website.md b/en/device-dev/website.md index 1ca0f668d0b4033c7c2bc4c6e3eddc27171c80ab..6fd7fe16d41c26589bfa34f443aa860ac976ecde 100644 --- a/en/device-dev/website.md +++ b/en/device-dev/website.md @@ -384,10 +384,10 @@ - [HiSysEvent Query](subsystems/subsys-dfx-hisysevent-query.md) - [HiSysEvent Tool Usage](subsystems/subsys-dfx-hisysevent-tool.md) - Featured Topics - - HPM Bundle - - [HPM Part Overview](bundles/hpm-part-about.md) - - [HPM Part Development](bundles/hpm-part-development.md) - - [HPM Part Reference](bundles/hpm-part-reference.md) + - HPM Part + - [HPM Part Overview](hpm-part/hpm-part-about.md) + - [HPM Part Development](hpm-part/hpm-part-development.md) + - [HPM Part Reference](hpm-part/hpm-part-reference.md) - Device Development Examples - [Mini- and Small-System Devices](guide/device-lite.md) - [WLAN-connected Products](guide/device-wlan.md)