同步操作将从 OpenHarmony/docs 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
This example shows how to compile a simple service and print Hello World to help you preliminarily understand how to run OpenHarmony on Hi3861.
The source code needs to be modified when fixing bugs or compiling a new service. The following describes how to modify the source code when compiling a new service, for example, my_first_app.
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
└── BUILD.gn
Compile 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. Use the SYS_RUN() of the OpenHarmony bootstrap module to start services. (SYS_RUN is defined in the ohos_init.h file.)
#include <stdio.h>
#include "ohos_init.h"
#include "ohos_types.h"
void HelloWorld(void)
{
printf("[DEMO] Hello world.\n");
}
SYS_RUN(HelloWorld);
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 fill in three parts (target, source file, and header file path) of the BUILD.gn file.
static_library("myapp") {
sources = [
"hello_world.c"
]
include_dirs = [
"//utils/native/lite/include"
]
}
Compile the BUILD.gn file and specify the feature modules to be built.
Configure the ./applications/sample/wifi-iot/app/BUILD.gn file and add an index to the features field to enable the target to be involved in compilation. Specify the path and target of a service module in features. The following uses my_first_app as an example and the features is configured as follows:
import("//build/lite/config/component/lite_component.gni")
lite_component("app") {
features = [
"my_first_app:myapp",
]
}
Currently, there are two debugging and verification methods: using printf to print logs and using asm files to locate panic problems. You can select one of them based on your need.
As the service shown is simple, use the printf method. The following describes the two debugging methods.
Add 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");
}
When the system exits abnormally, the call stack information about the abnormal exit is displayed on the serial port. The following is an example: You can locate the exception by parsing the exception stack information.
=======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 parse 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.
(Optional) Save the CallStack information to a TXT file for editing.
Open the asm file, search for the function address in each call stack, and list the corresponding function. Generally, you only need to find the functions matching the first several stacks to locate exceptions.
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
Determine that an exception occurs in the WadRecvCB function based on the call stack information.
Check and modify the code.
After the sample code is compiled, burnt, run, and debugged, the following information is displayed on the serial port interface:
ready to OS start
FileSystem mount ok.
wifi init success!
[DEMO] Hello world.
Congratulations! You have finished all steps! You are advised to go on learning how to develop WLAN-connected products.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。