本文簡單介紹如何編寫第一個hello world程序，以及程序是如何被執行的

適合群體：適用于Hi3861開發板，啟動流程分析

1、編寫第一個程序

編寫一個hello world程序比較簡單，可以參考官網。

本文在這里做下總結：

（1）確定目錄結構

開發者編寫業務時，務必先在./applications/sample/wifi-iot/app路徑下新建一個目錄（或一套目錄結構），用于存放業務源碼文件。

例如：在app下新增業務my_first_app，其中hello_world.c為業務代碼，BUILD.gn為編譯腳本，具體規劃目錄結構如下：

└── applications

└── sample

└── wifi-iot

└── app

│── my_first_app

│ │── hello_world.c

│ └── BUILD.gn

└── BUILD.gn

（2）編寫業務代碼

在hello_world.c中新建業務入口函數HelloWorld，并實現業務邏輯。并在代碼最下方，使用 HarmonyOS啟動恢復模塊接口SYS_RUN()啟動業務。（SYS_RUN定義在ohos_init.h文件中）

#include #include "ohos_init.h"#include "ohos_types.h"
void HelloWorld(void){  printf("[DEMO] Hello world.
");}
SYS_RUN(HelloWorld);

（3）編寫用于將業務構建成靜態庫的BUILD.gn文件

如步驟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 = [
    "http://utils/native/liteos/include"
  ]

static_library中指定業務模塊的編譯結果，為靜態庫文件libmyapp.a，開發者根據實際情況完成填寫。

sources中指定靜態庫.a所依賴的.c文件及其路徑，若路徑中包含"http://"則表示絕對路徑（此處為代碼根路徑），若不包含"http://"則表示相對路徑。

include_dirs中指定source所需要依賴的.h文件路徑。

（4）編寫模塊BUILD.gn文件，指定需參與構建的特性模塊

配置./applications/sample/wifi-iot/app/BUILD.gn文件，在features字段中增加索引，使目標模塊參與編譯。features字段指定業務模塊的路徑和目標，以my_first_app舉例，features字段配置如下。

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")。

2、Hi3861相關代碼結構

目前hi3861用的是liteos-m內核，但是目前hi3681的liteos-m被芯片rom化了，固化在芯片內部了。所以在harmonyOS代碼是找不到hi3861的內核部分。

但是這樣不妨礙我們去理清hi3861的其他代碼結構。

hi3861平臺配置文件位于：vendorhisiliconhispark_pegasusconfig.json

可以看到該配置文件有很多內容，第一段這里指定了產品名稱、版本、使用的內核類型

下面這里都是子系統：

其中我們重點關注這幾個模塊：

（1）applications：應用子系統

路徑：applications/sample/wifi-iot/app

作用：這個路徑下存放了hi3681編寫的應用程序代碼，例如我們剛剛寫得hello world 代碼就放在這個路徑下。

（2）iot_hardware：硬件驅動子系統

頭文件路徑：baseiot_hardwareperipheralinterfaceskits

具體代碼路徑，由deviceoardhisiliconhispark_pegasusliteos_mconfig.gni文件中指定：

config.gni文件內容較多，后續會一一解讀，作用：存放了 hi3681 芯片相關的驅動、例如spi、gpio、uart等。

（3）xts：xts測試子系統

這里我們先不要xts子系統，不然每次開機后，系統都要跑xts認證程序，影響我們后面測試，我們先注刪除，如下：

3、Hi3861啟動流程

由于hi3681的liteos-m被芯片rom化了，固化在芯片內部了。所以我們主要看內核啟動后的第一個入口函數。

代碼路徑：

devicesochisiliconhi3861v100sdk_liteosappwifiiot_appsrcapp_main.c
hi_void app_main(hi_void){#ifdef CONFIG_FACTORY_TEST_MODE    printf("factory test mode!
");#endif
  const hi_char* sdk_ver = hi_get_sdk_version();  printf("sdk ver:%s
", sdk_ver);
  hi_flash_partition_table *ptable = HI_NULL;
  peripheral_init();  peripheral_init_no_sleep();
#ifndef CONFIG_FACTORY_TEST_MODE  hi_lpc_register_wakeup_entry(peripheral_init);#endif
  hi_u32 ret = hi_factory_nv_init(HI_FNV_DEFAULT_ADDR, HI_NV_DEFAULT_TOTAL_SIZE, HI_NV_DEFAULT_BLOCK_SIZE);  if (ret != HI_ERR_SUCCESS) {    printf("factory nv init fail
");  }
  /* partion table should init after factory nv init. */  ret = hi_flash_partition_init();  if (ret != HI_ERR_SUCCESS) {    printf("flash partition table init fail:0x%x 
", ret);  }  ptable = hi_get_partition_table();
  ret = hi_nv_init(ptable->table[HI_FLASH_PARTITON_NORMAL_NV].addr, ptable->table[HI_FLASH_PARTITON_NORMAL_NV].size,    HI_NV_DEFAULT_BLOCK_SIZE);  if (ret != HI_ERR_SUCCESS) {    printf("nv init fail
");  }
#ifndef CONFIG_FACTORY_TEST_MODE  hi_upg_init();#endif
  /* if not use file system, there is no need init it */  hi_fs_init();
  (hi_void)hi_event_init(APP_INIT_EVENT_NUM, HI_NULL);  hi_sal_init();  /* 此處設為TRUE后中斷中看門狗復位會顯示復位時PC值，但有復位不完全風險，量產版本請務必設為FALSE */  hi_syserr_watchdog_debug(HI_FALSE);  /* 默認記錄宕機信息到FLASH，根據應用場景，可不記錄，避免頻繁異常宕機情況損耗FLASH壽命 */  hi_syserr_record_crash_info(HI_TRUE);
  hi_lpc_init();  hi_lpc_register_hw_handler(config_before_sleep, config_after_sleep);
#if defined(CONFIG_AT_COMMAND) || defined(CONFIG_FACTORY_TEST_MODE)  ret = hi_at_init();  if (ret == HI_ERR_SUCCESS) {    hi_at_sys_cmd_register();  }#endif
  /* 如果不需要使用Histudio查看WIFI驅動運行日志等，無需初始化diag */  /* if not use histudio for diagnostic, diag initialization is unnecessary */  /* Shell and Diag use the same uart port, only one of them can be selected */#ifndef CONFIG_FACTORY_TEST_MODE
#ifndef ENABLE_SHELL_DEBUG#ifdef CONFIG_DIAG_SUPPORT  (hi_void)hi_diag_init();#endif#else  (hi_void)hi_shell_init();#endif
  tcpip_init(NULL, NULL);#endif
  ret = hi_wifi_init(APP_INIT_VAP_NUM, APP_INIT_USR_NUM);  if (ret != HISI_OK) {    printf("wifi init failed!
");  } else {    printf("wifi init success!
");  }  app_demo_task_release_mem(); /* 釋放系統棧內存所使用任務 */
#ifndef CONFIG_FACTORY_TEST_MODE  app_demo_upg_init();#ifdef CONFIG_HILINK  ret = hilink_main();  if (ret != HISI_OK) {    printf("hilink init failed!
");  } else {    printf("hilink init success!
");  }#endif#endif  OHOS_Main();}

向右滑動查看全部代碼

app_main一開始打印了 SDK版本號，中間還會有一些初始化動作，最后一行會調用OHOS_Main();

該函數原型如下：

void OHOS_Main(){#if defined(CONFIG_AT_COMMAND) || defined(CONFIG_FACTORY_TEST_MODE)  hi_u32 ret;  ret = hi_at_init();  if (ret == HI_ERR_SUCCESS) {    hi_u32 ret2 = hi_at_register_cmd(G_OHOS_AT_FUNC_TBL, OHOS_AT_FUNC_NUM);    if (ret2 != HI_ERR_SUCCESS) {      printf("Register ohos failed!
");    }  }#endif  OHOS_SystemInit();}

向右滑動查看全部代碼

最后，OHOS_SystemInit函數進行鴻蒙系統的初始化。我們進去看下初始化做了哪些動作。

路徑：basestartupootstrap_liteservicessourcesystem_init.c

void OHOS_SystemInit(void){  MODULE_INIT(bsp);  MODULE_INIT(device);  MODULE_INIT(core);  SYS_INIT(service);  SYS_INIT(feature);  MODULE_INIT(run);  SAMGR_Bootstrap();}

向右滑動查看全部代碼

我們可以看到主要是初始化了 一些相關模塊、系統，包括有bsp、device（設備）。其中最終的是MODULE_INIT(run);

它負責調用了，所有run段的代碼，那么run段的代碼是哪些呢？

事實上就是我們前面application中使用SYS_RUN() 宏設置的函數名。

還記得我們前面寫的hello world應用程序嗎？

#include "ohos_init.h"
#include "ohos_types.h"
void HelloWorld(void){  printf("[DEMO] Hello world.
");}
SYS_RUN(HelloWorld);

也就是說所有用SYS_RUN() 宏設置的函數都會在使用MODULE_INIT(run); 的時候被調用。

為了驗證這一點，我們可以加一些打印信息，如下：

我們重新編譯后燒錄。打開串口查看打印信息，如下：

可以看到在27行之后，就打印 hello world的信息，符合預期。

原文標題：OpenHarmony輕量系統開發【4】編寫第一個程序、啟動流程分析

文章出處：【微信公眾號：HarmonyOS官方合作社區】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅