最激動入門級選手的心的時刻來了,本示例將演示如何編寫簡單業務,輸出「Hello World」。git
修改源碼
bugfix和新增業務兩種狀況,涉及源碼修改。下面以新增業務舉例,向開發者介紹如何進行源碼修改。app
-
肯定目錄結構。函數
開發者編寫業務時,務必先在./applications/sample/wifi-iot/app路徑下新建一個目錄(或一套目錄結構),用於存放業務源碼文件。ui
例如:在app下新增業務my_first_app,其中hello_world.c爲業務代碼,BUILD.gn爲編譯腳本,具體規劃目錄結構以下:spa
. └── applications └── sample └── wifi-iot └── app │── my_first_app │ │── hello_world.c │ └── BUILD.gn └── BUILD.gn
-
編寫業務代碼。調試
在hello_world.c中新建業務入口函數HelloWorld,並實現業務邏輯。並在代碼最下方,使用OpenHarmony啓動恢復模塊接口SYS_RUN()啓動業務。(SYS_RUN定義在ohos_init.h文件中)日誌
#include "ohos_init.h" #include "ohos_types.h" void HelloWorld(void) { printf("[DEMO] Hello world.\n"); } SYS_RUN(HelloWorld);
-
編寫用於將業務構建成靜態庫的BUILD.gn文件。component
如步驟1所述,BUILD.gn文件由三部份內容(目標、源文件、頭文件路徑)構成,需由開發者完成填寫。以my_first_app爲例,須要建立./applications/sample/wifi-iot/app/my_first_app/BUILD.gn,並完以下配置。索引
static_library("myapp") { sources = [ "hello_world.c" ] include_dirs = [ "//utils/native/liteos/include" ] }
- static_library中指定業務模塊的編譯結果,爲靜態庫文件libmyapp.a,開發者根據實際狀況完成填寫。
- sources中指定靜態庫.a所依賴的.c文件及其路徑,若路徑中包含"//"則表示絕對路徑(此處爲代碼根路徑),若不包含"//"則表示相對路徑。
- include_dirs中指定source所須要依賴的.h文件路徑。
-
編寫模塊BUILD.gn文件,指定需參與構建的特性模塊。接口
配置./applications/sample/wifi-iot/app/BUILD.gn文件,在features字段中增長索引,使目標模塊參與編譯。features字段指定業務模塊的路徑和目標,以my_first_app舉例,features字段配置以下。
import("//build/lite/config/component/lite_component.gni") lite_component("app") { features = [ "my_first_app:myapp", ] }
- my_first_app是相對路徑,指向./applications/sample/wifi-iot/app/my_first_app/BUILD.gn。
- myapp是目標,指向./applications/sample/wifi-iot/app/my_first_app/BUILD.gn中的static_library("myapp")。
調測驗證
目前調試驗證的方法有兩種,分別爲經過printf打印日誌、經過asm文件定位panic問題,開發者能夠根據具體業務狀況選擇。
因爲本示例業務簡單,採用printf打印日誌的調試方式便可。下面開始介紹這兩種調試手段的使用方法。
printf打印
代碼中增長printf維測,信息會直接打印到串口上。開發者可在業務關鍵路徑或業務異常位置增長日誌打印,以下所示。
void HelloWorld(void) { printf("[DEMO] Hello world.\n"); }
根據asm文件進行問題定位
系統異常退出時,會在串口上打印異常退出緣由調用棧信息,以下文所示。經過解析異常棧信息能夠定位異常位置。
=======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*******************
爲解析上述調用棧信息,須要使用到Hi3861_wifiiot_app.asm文件,該文件記錄了代碼中函數在Flash上的符號地址以及反彙編信息。asm文件會隨版本大包一同構建輸出,存放在./out/wifiiot/路徑下。
-
將調用棧CallStack信息保存到txt文檔中,以便於編輯。(可選)
-
打開asm文件,並搜索CallStack中的地址,列出對應的函數名 信息。一般只需找出前幾個棧信息對應的函數,就可明確異常代碼方向。
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
-
根據以上調用棧信息,能夠定位WadRecvCB函數中出現了異常。
-
完成代碼排查及修改。
運行結果
示例代碼編譯、燒錄、運行、調測後,會顯示以下結果:
ready to OS start FileSystem mount ok. wifi init success! [DEMO] Hello world.