https://gitee.com/walker2048/hmos_iot

移植鴻蒙的建議：
步驟一步來，別想一口吃成胖子，給自己定計劃。多看源碼以及編譯日志，多想，多動手。源碼既是文檔，別想著百度或者谷歌能幫你直接解決問題。修改完代碼后，完成了小部分功能的，也要及時提交GIT中。

1 ，首先肯定是創建廠商文件夾
首先按移植LiteOS教程里的說明，使用CubeMX工具生成makefile格式的項目（包含stm32l4xx標準hal庫和ll庫實現代碼及makefile），并把項目文件復制到供應商/ st / stm32l4xx目錄里。這就是2020- 11-06日 dbbaf5f這個提交所包含的內容。然后在該目錄執行命令make> build.log，這樣一是測試代碼是否能正常編譯，二是可以把stm官方提供的makefile實際執行指令信息存儲到build.log文件里，方便以后修改gn系統的編譯配置時做參考用

2，第二步配置編譯環境及組件

根據以前的閱讀makefile和嵌入式開發經驗，應該先確定編譯工具鏈。不同的硬件架構，需要的編譯工具鏈并不一樣，哪怕是一個最簡單的helloworld，也沒辦法實現同一個bin文件，能在不同架構的硬件上直接運行。目前鴻蒙2.0配置好的兩套編譯工具（主要是gcc），并不能完成stm32的編譯工作。

打開build / lite / toolchain /目錄，復制gcc.gni文件的內容到arm_none_eabi_gcc.gni，進入第14行的ohos_kernel_type（內核類型）修改成liteos_m，進入15行的ohos_build_compiler_

prefix設置為正確的gcc工具設置為arm-none-eabi。其他內容暫時沒動，然后根據其他開發板的設置，又復制了幾遍配置，例如

構建/精簡版/配置/板/ stm32l476rg_nucleo.gni

等等配置先抄一遍hi3861的，期間各種嘗試使用編譯命令蟒蛇build.py stm32l476rg_nucleo，直到不再提示找不到stm32l476rg_nucleo目標板，進入下一個確認工具鏈環節為止。這一環節中，比較重要的應該是build / lite / product / stm32l476rg_nucleo.json文件，該文件定義了目標板名稱，編譯工具鏈，內核等重要信息。

當編譯命令提示arm-none-eabi-gcc不是OHOS的編譯器時，我也沒有楞一會兒。翻了生成目錄下的各種配置也找不到對應的配置時，我就放棄找配置了。直接在VScode中插入搜索不包含OHOS編譯器的大部分文件，最終在build / lite / config中。py的124行和158行找到了對應的判斷語句，并增加了arm-none-eabi-gcc的判斷語句。

隨后測試編譯時，又發現編譯腳本會針對ohos_kernel_type進行各種優化和設置。沒辦法，就只能搜索ohos_kernel_type ==“ liteos_riscv”，指向文件一一修改。涉及到的文件也很多，詳細請看gitee上的變更記錄。

最終各組件的配置判斷語句沒問題了，能順利進入到編譯狀態，出現類似以下信息了

===開始構建===

做完了648毫秒內從41個文件中取得39個目標

忍者：進入目錄`/ mnt / out / stm32l476rg_nucleo'

[112分之1]交叉編譯OBJ / APPLICATI組件/樣品/ WiFi的IOT /應用/ demolink / helloworld.o

[2/112] AR libs / libdemolink.a

因此能出現[1/112]之類的，恭喜你，編譯配置已經完成了80％了。期間還刪除并容易出現問題的組件，例如wifi功能等等一堆組件

3，調整頭文件配置
為了減少以后找文件找目錄頭疼，我在二進制目錄新建了一個包括文件夾，鏈接疑似應該從廠商目錄中提取出來的頭文件放在該目錄的hal目錄下，從而難以解決的頭文件錯誤組件去掉，不編譯對應組件。最終編譯命令都順利通過了，只差最后一步生成小精靈和箱文件了。

4，根據原廠生成文件和修改編譯調整細節
重頭戲的英文此文件生成/精簡版/工具鏈/ arm_none_eabi_gcc.gni，查看原廠makefile的build.log文件，可以裁剪編譯過程為.c文件=>。o文件，然后.S文件=>。o文件，然后將所有的.o文件以及STM32L476RGTx_FLASH.ld文件一起鏈接成elf文件。最后再由elf文件生成bin和hex。

多次嘗試修改后，最終調整為以下內容

template（“ gcc_toolchain”）{

工具鏈（target_name）{

斷言（已定義（invoker.cc），“ gcc工具鏈必須指定一個“ cc ”值“）

斷言（已定義（invoker.cxx），“ gcc工具鏈必須指定一個“ cxx ”值“）

斷言（已定義（invoker.ld），“ gcc工具鏈必須指定一個“ ld ”值“）

斷言（已定義（invoker.ar），“ gcc工具鏈必須指定一個“ ar ”值“）

斷言（定義（invoker.as），““工具鏈必須指定一個” as “值”）

斷言（定義（invoker.cp），““工具鏈必須指定一個“ cp ”值”）

ar = invoker.ar

as =調用者

cc = invoker.cc

cxx = invoker.cxx

ld = invoker.ld

cp = invoker.cp

need_strip =否

if（defined（invoker.strip））{

剝離= invoker.strip

need_strip = true

}

如果（defined（invoker.extra_

ldflags）&&invoker.extra_ldflags！=“”）{

extra_ldflags =“”

}其他{

extra_ldflags =“”

}

工具（“ cc”）{

命令=“ $ cc -c {{cflags}} {{defines}} {{include_dirs}} {{cflags_c}}” +

＃“ -MMD -MP -MF'{{source_out_dir}} / {{source_name_part}}。d'” +

＃“ -Wa，-a，-ad，-alms = {{source_out_dir}} / {{source_name_part}}。lst” +

“ {{source}} -o {{output}}”

depsformat =“ gcc”

description =“跨編譯器{{output}}”

輸出= [

“ {{source_out_dir}} / {{source_name_part}}。o”，

]

}

工具（“ cxx”）{

depfile =“ {{output}}。d”

命令=“ $ cxx -c {{cflags}} {{defines}} {{include_dirs}} {{cflags_c}}” +

＃“ -MMD -MP -MF'{{source_out_dir}} / {{source_name_part}}。d'” +

＃“ -Wa，-a，-ad，-alms = {{source_out_dir}} / {{source_name_part}}。lst” +

“ {{source}} -o {{output}}”

depsformat =“ gcc”

description =“ CXX {{output}}”

輸出= [

“ {{source_out_dir}} / {{target_output_name}}。{{source_name_part}}。o”，

]

}

工具（“ asm”）{

depfile =“ {{output}}。d”

command =“ $ as -c {{cflags}} {{defines}} {{include_dirs}} {{asmflags}} {{source}} {{cflags_c}}” +

“ -o {{輸出}}”

depsformat =“ gcc”

description =“跨編譯器{{output}}”

輸出= [

“ {{source_out_dir}} / {{source_name_part}}。o”

]

}

工具（“鏈接”）{

outfile =“ {{output_dir}} / {{target_output_name}} {{output_extension}}”

rspfile =“ {{output}}。rsp”

rspfile_content =“ {{inputs}}”

命令=“ $ ar cr {{輸出}} @ ” $ rspfile “”

description =“ AR {{output}}”

輸出= [

超越

]

default_output_dir =“ {{root_out_dir}} / libs”

default_output_extension =“ .a”

output_prefix =“ lib”

}

工具（“鏈接”）{

outfile =“ {{output_dir}} / bin / {{target_output_name}}。elf”

rspfile =“ $ outfile.rsp”

command =“ $ ld {{inputs}} {{ldflags}} $ extra_ldflags -specs = nano.specs” +

＃在供應商路徑中設置ld文件補丁

“ -lc -lm -lnosys {{libs}} -Wl，-Map = {{target_output_name}}。map，-cref” +

“ -Wl，-gc-sections -o $ outfile”

if（need_strip）{

命令+ =“ && $ cp -O二進制-S $ outfile {{output_dir}} / bin / {{target_output_name}}。bin”

}

description =“ LINK $ outfile”

default_output_dir =“ {{root_out_dir}}”

rspfile_content =“ {{inputs}}”

輸出= [

超越

]

}

工具（“郵票”）{

如果（host_os ==“ win”）{

命令=“ cmd / c類型nul> ” {{輸出}} “”

}其他{

命令=“ / usr / bin / touch {{輸出}}”

}

description =“ STAMP {{output}}”

}

工具（“復制”）{

命令=“ $ cp -O二進制-S {{源}} {{輸出}}。bin && echo $ strip”

description =“ COPY {{源}} {{輸出}}”

}

}

同時在stm32l4xx / Src / BUILD.gn文件中添加ldflags，實現ld文件在廠商文件內部設置。

ldflags = [

“ -T”，

“ ../../vendor/st/stm32l4xx/STM32L476RGTx_FLASH.ld”

]

最終，順利生成了一個elf文件，bin文件以及hex文件。其實gn配置相對來說，命令行的提示，以及配置的定位性都是相當不錯的。還是建議大家多動手，多看，多想。

責任編輯：xj

原文標題：移植鴻蒙系統到STM32L476RG_NUCLEO開發板的一點小經驗

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