https://gitee.com/walker2048/hmos_iot

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

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

2，第二步配置編譯環(huán)境及組件

根據(jù)以前的閱讀makefile和嵌入式開(kāi)發(fā)經(jīng)驗(yàn)，應(yīng)該先確定編譯工具鏈。不同的硬件架構(gòu)，需要的編譯工具鏈并不一樣，哪怕是一個(gè)最簡(jiǎn)單的helloworld，也沒(méi)辦法實(shí)現(xiàn)同一個(gè)bin文件，能在不同架構(gòu)的硬件上直接運(yùn)行。目前鴻蒙2.0配置好的兩套編譯工具（主要是gcc），并不能完成stm32的編譯工作。

打開(kāi)build / lite / toolchain /目錄，復(fù)制gcc.gni文件的內(nèi)容到arm_none_eabi_gcc.gni，進(jìn)入第14行的ohos_kernel_type（內(nèi)核類(lèi)型）修改成liteos_m，進(jìn)入15行的ohos_build_compiler_

prefix設(shè)置為正確的gcc工具設(shè)置為arm-none-eabi。其他內(nèi)容暫時(shí)沒(méi)動(dòng)，然后根據(jù)其他開(kāi)發(fā)板的設(shè)置，又復(fù)制了幾遍配置，例如

構(gòu)建/精簡(jiǎn)版/配置/板/ stm32l476rg_nucleo.gni

等等配置先抄一遍hi3861的，期間各種嘗試使用編譯命令蟒蛇build.py stm32l476rg_nucleo，直到不再提示找不到stm32l476rg_nucleo目標(biāo)板，進(jìn)入下一個(gè)確認(rèn)工具鏈環(huán)節(jié)為止。這一環(huán)節(jié)中，比較重要的應(yīng)該是build / lite / product / stm32l476rg_nucleo.json文件，該文件定義了目標(biāo)板名稱(chēng)，編譯工具鏈，內(nèi)核等重要信息。

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

隨后測(cè)試編譯時(shí)，又發(fā)現(xiàn)編譯腳本會(huì)針對(duì)ohos_kernel_type進(jìn)行各種優(yōu)化和設(shè)置。沒(méi)辦法，就只能搜索ohos_kernel_type ==“ liteos_riscv”，指向文件一一修改。涉及到的文件也很多，詳細(xì)請(qǐng)看gitee上的變更記錄。

最終各組件的配置判斷語(yǔ)句沒(méi)問(wèn)題了，能順利進(jìn)入到編譯狀態(tài)，出現(xiàn)類(lèi)似以下信息了

===開(kāi)始構(gòu)建===

做完了648毫秒內(nèi)從41個(gè)文件中取得39個(gè)目標(biāo)

忍者：進(jìn)入目錄`/ mnt / out / stm32l476rg_nucleo'

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

[2/112] AR libs / libdemolink.a

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

3，調(diào)整頭文件配置
為了減少以后找文件找目錄頭疼，我在二進(jìn)制目錄新建了一個(gè)包括文件夾，鏈接疑似應(yīng)該從廠(chǎng)商目錄中提取出來(lái)的頭文件放在該目錄的hal目錄下，從而難以解決的頭文件錯(cuò)誤組件去掉，不編譯對(duì)應(yīng)組件。最終編譯命令都順利通過(guò)了，只差最后一步生成小精靈和箱文件了。

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

多次嘗試修改后，最終調(diào)整為以下內(nèi)容

template（“ gcc_toolchain”）{

工具鏈（target_name）{

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

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

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

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

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

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

ar = invoker.ar

as =調(diào)用者

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” +

＃在供應(yīng)商路徑中設(shè)置ld文件補(bǔ)丁

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

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

if（need_strip）{

命令+ =“ && $ cp -O二進(jìn)制-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類(lèi)型nul> ” {{輸出}} “”

}其他{

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

}

description =“ STAMP {{output}}”

}

工具（“復(fù)制”）{

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

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

}

}

同時(shí)在stm32l4xx / Src / BUILD.gn文件中添加ldflags，實(shí)現(xiàn)ld文件在廠(chǎng)商文件內(nèi)部設(shè)置。

ldflags = [

“ -T”，

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

]

最終，順利生成了一個(gè)elf文件，bin文件以及hex文件。其實(shí)gn配置相對(duì)來(lái)說(shuō)，命令行的提示，以及配置的定位性都是相當(dāng)不錯(cuò)的。還是建議大家多動(dòng)手，多看，多想。

責(zé)任編輯：xj

原文標(biāo)題：移植鴻蒙系統(tǒng)到STM32L476RG_NUCLEO開(kāi)發(fā)板的一點(diǎn)小經(jīng)驗(yàn)

文章出處：【微信公眾號(hào)：HarmonyOS社區(qū)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。