基于OpenHarmony的嵌入式開發

第一章OpenHarmony的系統構成安全邊距1.1OpenHarmony系統特點[1.1.1]什么是OpenHarmony系統

由開放原子開源基金會孵化及運營的一個開源項目，目標是面向全場景、全連接、全智能時代，基于開源的方式搭建智能終端設備操作系統的框架和平臺，促進萬物互聯產業的繁榮發展。基于OpenHarmony的嵌入式開發2開放原子開源基金會是致力于推動全球開源事業發展的非營利機構，于2020年6月在北京成立，由阿里巴巴、百度、華為、浪潮、360、騰訊、招商銀行等多家龍頭科技企業聯合發起。2020年9月，開放原子開源基金會接受了華為公司捐贈的智能終端操作系統基礎能力的相關代碼，隨后進行了開源，命名為OpenAtomOpenHarmony（一般簡稱為OpenHarmony）。隨后，基金會成立了OpenHarmony項目群工作委員會，簽署了OpenHarmony項目群管理制度。1.1OpenHarmony系統特點[1.1.1]

OpenHarmony與HarmonyOS

OpenHarmony是以華為捐贈的智能終端操作系統為基礎的，目前其中也融合了其他參與者的貢獻，是開源項目。適用于嵌入式和物聯網等智能設備。

HarmonyOS包含了OpenHarmony所不具備的諸多商用功能，如多端設備協同認證等，而ASOP的實現也使得HarmonyOS手機和平板等設備能夠運行Android應用程序，是商用系統。適用于手機、平板電腦和智能汽車等移動終端。基于OpenHarmony的嵌入式開發3鴻蒙軟件體系HarmonyOSOpenHarmonyASOP……OpenHarmony第三方庫其他HarmonyOS=OpenHarmony+ASOP+…安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點

可裝卸性、實時性、穩定性-嵌入式操作系統必備的特性特性1/3：統一系統，彈性部署滿足不同類型設備的需求：血壓計、體重計、游戲機、音視頻播放機、打印機和掃地機器人等，不同設備使用同一語言無縫溝通。滿足不同性能設備的需求：不同類型的處理器、不同級別的存儲能力、不同功能的外部設備和器件。基于OpenHarmony的嵌入式開發4智能穿戴設備大小家電設備機器人設備健康醫療設備安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性2/3：一次開發，多端部署

OpenHarmony則基于分布式技術，在不同的硬件設備之間隨意調用、互助共享，寫一次邏輯代碼，就可以部署在多種終端上。基于OpenHarmony的嵌入式開發5解決多種終端設備開發過程中，不同設備間的屏幕尺寸、色彩風格等方面的適配問題安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性3/3：硬件互助，資源共享

-（1/4）分布式軟總線基于OpenHarmony的嵌入式開發6傳統意義的總線：一種內部結構，它是CPU、內存、輸入、輸出設備傳遞信息的公用通道，主機的各個部件通過總線相連接，外部設備通過相應的接口電路再與總線相連接，從而形成了計算機硬件系統。分布式軟總線：為設備間的無縫互聯提供了統一的分布式通信能力，能夠快速發現并連接設備，高效地傳輸任務和數據。由WLAN服務能力、藍牙服務能力、軟總線和進程間通信RPC共同組成，提供相關的功能。安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性3/3：硬件互助，資源共享

-（1/4）分布式軟總線基于OpenHarmony的嵌入式開發7WLAN服務為用戶提供WLAN基礎功能、P2P（Peer-to-Peer）功能和WLAN消息通知的相應服務，應用可以通過WLAN和其他設備互聯互通。藍牙服務為應用提供傳統藍牙以及低功耗藍牙相關功能和服務。軟總線為應用和系統提供近場設備間分布式通信的能力，提供不區分通信方式的設備發現、連接、組網和傳輸功能。進程間通信RPC（RemoteProcedureCall）提供了不區分設備內或設備間的進程間通信能力。安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性3/3：硬件互助，資源共享

-（2/4）分布式數據管理基于OpenHarmony的嵌入式開發8分布式數據管理實現了應用程序數據和用戶數據在多終端設備上的分布式管理功能。用戶的數據不再與單一物理設備綁定，業務邏輯與數據存儲分離，應用跨設備運行時能夠實現數據的無縫銜接。持久化存儲引擎支持數據跨設備相互同步安全邊距1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性3/3：硬件互助，資源共享

-（3/4）分布式任務調度基于OpenHarmony的嵌入式開發9智慧屏設備智能穿戴設備分布式任務調度基于分布式軟總線、分布式數據管理的分布式Profile等技術特性，構建統一的發現、同步、注冊和調用的分布式服務管理機制，支持對跨設備的應用進行遠程啟動、遠程調用、綁定和解綁、以及遷移等操作。

安全邊距①智慧屏上在喜歡的節目菜單中，點擊“開播后提醒我”按鈕；②在節目開播時，智慧屏會拉起運動手表上的節目開播提醒FA；③通過運動手表上的該FA，用戶可以快速獲知喜歡的節目已經開始；④實現上述協同互助的作用。1.1OpenHarmony系統特點[1.1.2]OpenHarmony的技術特點特性3/3：硬件互助，資源共享

-（4/4）設備虛擬化功能基于OpenHarmony的嵌入式開發10安全邊距將多臺設備的各種硬件資源，如屏幕、相機、擴音器、鍵盤、傳感器及存儲器等予以抽象，形成“超級虛擬終端”內的統一硬件資源池，并支持硬件資源的按需分配和重新組合，真正實現了硬件資源的全局調用。硬件資源池化框架將各類設備的硬件資源進行抽象，為北向應用提供各種分布式服務，比如分布式相機、分布式屏幕、分布式音頻和分布式輸入等，同時提供統一的設備管理和分布式硬件框架，對硬件資源進行管理。1.1OpenHarmony系統特點[1.1.3]OpenHarmony的設備分類嵌入式系統分類方法之一：按照硬件平臺的性能進行分類基于OpenHarmony的嵌入式開發11安全邊距Mini

System/輕量系統L0類型：LiteOS-M內核CPU：Cortex-M/RISC-V32MEM：128KB~1MB功能：輕量級網絡協議、輕量級的圖形框架、IoT總線讀寫部件等；場景：智能家居領域的連接類模組、傳感器設備和穿戴類設備等；硬件：Hi3861、TLSR9x、GR5515、BES2600、RK2206和ESP32等。Small

System/小型系統L1類型：LiteOS-A內核CPU：Cortex-AMEM：1MB～128MB功能：較高的安全能力、標準的圖形框架、視頻編解碼的多媒體能力等；場景：智能攝像機、電子貓眼、路由器以及智慧出行領域的行車記錄儀等；硬件：Hi3516DV300和STM32MP157A等。StandardSystem/標準系統L2類型：Linux內核CPU：Cortex-AMEM：128MB～功能：增強的交互能力、3DGPU、豐富的圖形能力、完整的應用框架等；場景：高端的冰箱控制系統、汽車娛樂系統、智能家居控制系統等；硬件：RK3568、RK3399、RK3566、Hi3751V351、i.MX8M和T507等。不同類型系統的硬件不同，和內核軟件功能存在差異，課程將分別介紹1.1OpenHarmony系統特點[1.1.4]OpenHarmony的技術架構系統的設計原則：按照功能進行分層設計基于OpenHarmony的嵌入式開發12安全邊距1.2內核層[1.2.1]輕量系統的內核子系統內核類型：

LiteOS-M特性：MCU

AIoT領域設備

MPU、<1MB基于OpenHarmony的嵌入式開發13安全邊距硬件相關層，提供HAL接口(HardwareAbstractionLayer)硬件無關層，提供KAL接口(KernelAbstractionLayer)基礎內核模塊提供基礎能力，可選組建提供網絡個文件系統等組件能力，以及調測工具。1.2內核層[1.2.2]小型系統的內核子系統內核類型：

LiteOS-A特性：CPU

AIoT領域設備

MMU、<128MB基于OpenHarmony的嵌入式開發14安全邊距基礎內核包括內核的基礎機制，如調度和內存管理等；擴展組件包括文件系統、網絡協議和安全等擴展功能；HDF框架是外設驅動的統一標準框架；兼容POSIX標準的應用可以方便移植到OpenHarmony。1.2內核層[1.2.2]小型系統的內核子系統基于OpenHarmony的嵌入式開發15安全邊距①內核機制功能豐富：支持虛擬內存、系統調用、多核、輕量級IPC（Inter-ProcessCommunication，進程間通信）、DAC（DiscretionaryAccessControl，自主訪問控制）等機制，支持多進程，應用之間內存隔離、相互不影響，提升系統的健壯性；②引入統一驅動框架HDF（HardwareDriverFoundation）：統一驅動標準，提供了統一的接入方式，驅動更加容易移植，力求做到一次開發，多系統部署；③支持1200+標準POSIX接口：更全面的支持POSIX標準接口，使得應用軟件易于開發和移植，為應用開發者提供友好的開發體驗；④內核和硬件高解耦：內核與硬件高度解耦，新增單板，內核代碼不用修改。1.2內核層基于OpenHarmony的嵌入式開發16安全邊距[1.2.3]標準系統的內核內核類型：Linux特性：CPU、高性能應用、MMU、>128MBLinux內核版本分為穩定版本以及長期支持LTS版本。

穩定版本大約每三個月發布一個新版本，包含最新硬件支持、性能改進以及bug修復等；長期支持版本LTS對該版本內核的長期維護，一般維護周期達6年。OpenHarmony中的Linux內核從LTS版本中選擇合適的版本作為內核的基礎版本。完成對Linux-4.19及Linux-5.10的適配及支持（～2023年5月）。1.3驅動程序層基于OpenHarmony的嵌入式開發17安全邊距[1.3]驅動程序框架HDF（HardwareDriverFoundation）HDI硬件設備統一接口：為系統提供統一、穩定的硬件設備操作接口。HDF驅動框架：提供統一的硬件資源管理等模塊。統一的配置界面：硬件資源的抽象描述，屏蔽硬件差異，提升開發遷移效率。操作系統抽象層OSAL：提供統一封裝的操作相關接口，屏蔽系統操作差異。平臺驅動：為外設驅動提供Board硬件操作統一接口和適配接口抽象。外設驅動模型：提供標準化的器件驅動，提供驅動模型抽象。1.3驅動程序層基于OpenHarmony的嵌入式開發18安全邊距[1.3]驅動程序框架HDF（HardwareDriverFoundation）（1）彈性化的框架能力：在傳統的驅動框架能力的基礎上，OpenHarmony驅動子系統通過構建彈性化的框架能力，可支持在百KB級別到百兆級容量的終端產品形態部署；（2）規范化的驅動接口：定義了常見驅動接口，為驅動開發者和使用者提供豐富、穩定接口，并和未來開放的面向手機、平板、智慧屏等設備驅動接口保持API兼容性；（3）組件化的驅動模型：支持組件化的驅動模型，為開發者提供更精細化的驅動管理，開發者可以對驅動進行組件化拆分，使得驅動開發者可以更多關注驅動與硬件交互部分。同時系統也預置了部分模板化的驅動模型組件，如網絡設備模型等；（4）歸一化的配置界面：提供統一的配置界面，構建跨平臺的配置轉換和生成工具，實現跨平臺的無縫切換。1.4系統服務層基于OpenHarmony的嵌入式開發19安全邊距[1.4]系統服務層（1）系統基本能力子系統集：為分布式應用在多設備上的運行、調度、遷移等操作提供了基礎能力，由分布式軟總線、分布式數據管理、分布式任務調度、公共基礎庫、多模輸入、圖形、安全和AI等子系統組成。（2）基礎軟件服務子系統集：提供公共的、通用的軟件服務，由事件通知、電話、多媒體和DFX（DesignForX）等子系統組成。（3）增強軟件服務子系統集：提供針對不同設備的、差異化的能力增強型軟件服務，由智慧屏專有業務、穿戴專有業務和IoT專有業務等子系統組成。（4）硬件服務子系統集：提供硬件服務，由位置服務、用戶IAM、穿戴專有硬件服務和IoT專有硬件服務等子系統組成。1.5框架層基于OpenHarmony的嵌入式開發20安全邊距[1.5]框架層

為應用開發提供C/C++/JS等多語言的用戶程序框架和Ability框架、適用于JS語言的ArkUI框架，以及各種軟硬件服務對外開放的多語言框架API。（1）Ability框架實現了對Ability運行及生命周期的統一調度和管理，使應用進程能夠支撐多個Ability，Ability具有跨應用進程間和同一進程內調用的能力。Ability是系統調度應用的最小單元，是能夠完成一個獨立功能的組件，一個應用可以包含一個或多個Ability；（2）JSArkUI框架采用類HTML和CSSWeb編程語言作為頁面布局和頁面樣式的開發語言，頁面業務邏輯則支持ECMAScript規范的JavaScript語言。框架提供的類Web編程范式，可以讓開發者避免編寫UI狀態切換的代碼，視圖配置信息更加直觀。1.6OpenHarmony

Shell基于OpenHarmony的嵌入式開發21安全邊距[1.6.1]

OpenHarmonyShell的基本功能和特點

Shell的基本功能：

DOS

Shell：DOS

中帶有基本圖形用戶界面（GUI）的文件管理程序；

PowerShell：PowerShell是Windows系統中的新式命令Shell，包括了其他常用Shell功能，PowerShell還能接受并返回.NET對象；

Linux

Shell：用戶與Linux的交互橋梁。Shell既是命令語言，又是程序設計語言。Shell是一種應用程序，指這個應用程序提供了用戶訪問操作系統內核的服務；程序設計語言指可以構建腳本執行編程功能。

Shell是系統的用戶界面，提供用戶與內核進行交互操作的接口，接收用戶輸入的命令并將其送入內核執行，實現操作系統的文件管理、進程管理和內存管理等服務，并輸出內核信息。常規意義上，Shell是基于純文本（命令行模式）進行交互的。1.6OpenHarmony

Shell基于OpenHarmony的嵌入式開發22安全邊距[1.6.1]

OpenHarmonyShell的基本功能和特點

OpenHarmony

Shell的特點：

支持使用exec命令來運行可執行文件；

默認為英文輸入，輸入的中文字符需要通過回退三次才能刪除；

支持Shell命令、文件名及目錄名的Tab鍵聯想補全；

Shell端工作目錄與系統工作目錄是分開的，即通過Shell端cd和pwd等命令是對Shell端工作目錄進行操作，通過chdir和getcwd等命令是對系統工作目錄進行操作，兩個工作目錄相互之間沒有聯系；

在使用網絡Shell指令前，需要先調用tcpip_init函數并完成telnet連接；

Shell功能不符合POSIX標準，僅供調試使用；

不建議使用Shell命令對/dev目錄下的設備文件進行操作。1.6OpenHarmony

Shell基于OpenHarmony的嵌入式開發23安全邊距[1.6.2]

OpenHarmonyShell命令類別1：系統命令

cpup、date、dmesg、exec、free、help、hwi、kill、log、memcheck、reset、sem、stack、su、swtmr、systeminfo、task、uname、watch、reboot、top、……類別2：文件命令

cat、cd、chgrp、chmod、chown、cp、format、ls、lsfd、mkdir、mount、pwd、rm、statfs、sync、touch、writeproc、umount、du、mv、……類別3：網絡命令

arp、dhclient、ifconfig、netstat、ntpdate、ping、ping6、telnet、tftp、……與LinuxShell命令大部分名字相同，但OpenHarmony有裁剪和調整，參閱教材等資料

1.7系統編譯與構建基于OpenHarmony的嵌入式開發24安全邊距[1.7.1]

OpenHarmony開發環境配置方式1：安裝包方式通過命令行模式下載、安裝和編譯，通過IDE燒錄，有Docker環境。方式2：IDE方式通過IDE進行開發工具的安裝及系統的編譯、燒錄和運行控制等操作。

IDE：DevEcoDeviceTool

支持代碼查找、代碼高亮、代碼自動補齊、代碼輸入提示、代碼檢查等；

支持豐富的芯片和開發板，包括Hi3861V100和BearPi-HMNano等；

自動檢測各芯片/開發板依賴的工具鏈是否完備，一鍵下載和自動安裝；

支持多人共享開發模式，多人共享遠程開發，單臺服務器的編譯燒錄；

源碼級調試，支持查看內存、變量、調用棧、寄存器和反匯編等功能。1.7系統編譯與構建基于OpenHarmony的嵌入式開發25安全邊距[1.7.1]

OpenHarmony開發環境配置

IDE方式：（1/4）DevEcoDeviceTool安裝提供編輯、開發和調試的圖形環境Windows1064，與Ubuntu系統上的IDE的版本號必須相同。①下載并解壓縮DevEcoDeviceTool軟件包；②卸載早期安裝的其他版本的軟件；③選擇自動安裝VSCode軟件（）；④下載安裝相關Python和其他插件。提供OpenHarmony系統的編譯環境Ubuntu18.04～21.10，推薦20.04，建議內存不小于16GB，用戶名不能包含中文字符，與Windows系統上IDE版本號相同。①設置Ubuntu的默認Shell為bash；②下載DevEcoDeviceTool的Linux版本安裝包并安裝；③安裝過程中可能需要更新系統的Python版本。DevEco

Device

Tool支持C/C++語言，以插件的形式部署在Windows和Ubunut的VisualStudioCode（簡稱VSCode）上。1.7系統編譯與構建基于OpenHarmony的嵌入式開發26安全邊距[1.7.1]

OpenHarmony開發環境配置

IDE方式：（2/4）遠程訪問Ubuntu系統Ubuntu端：主要的系統編譯環境，被Windows連接控制①安裝并啟動SSH服務（openssh-server）;②查看Ubuntu系統的IP地址（ifconfig）。Windows端：連接Ubuntu端、控制編譯過程①啟動VSCode，點擊插件（Extensions）按鈕；②在插件市場搜索并安裝Remote-SSH；③在RemoteExplorer中增加配置。輸入Ubuntu的IP地址和用戶名，其他使用默認項即可；④首次連接需要等待VSCode在Ubuntu系統的.vscode-server文件夾下自動安裝插件；

⑤使用時，點擊對應地址輸入密碼即可連接；⑥還可以在VSCode中使用SSH公鑰替代密碼。202304起，Hi3861開發僅需Windows環境1.7系統編譯與構建基于OpenHarmony的嵌入式開發27安全邊距[1.7.1]

OpenHarmony開發環境配置

IDE方式：（3/4）獲取OpenHarmony源碼

從碼云Gitee網站獲取OpenHarmony系統的源碼，相關準備工作包括注冊Gitee賬號、注冊Gitee的SSH公鑰、安裝git客戶端和git-lfs、配置用戶信息和安裝Gitee的repo工具等；本書使用的版本為OpenHarmony3.1.1Release；

還可以DevEcoMarketplace、華為云等或者GitHub鏡像倉庫獲取。

IDE方式：（4/4）安裝編譯工具

OpenHarmony的編譯工具主要是命令行工具hb；

hb的主要安裝步驟包括安裝、設置并更新環境變量和測試過程。獲取源碼和安裝編譯工具的詳細步驟請參閱教材完成。1.7系統編譯與構建基于OpenHarmony的嵌入式開發28安全邊距[1.7.1]

OpenHarmony開發環境配置

OpenHarmony源碼存儲結構存儲位置內容功能applications應用程序樣例，包括camera等base基礎軟件服務子系統集&硬件服務子系統集build組件化編譯、構建和配置腳本docs說明文檔domains增強軟件服務子系統集drivers驅動子系統foundation系統基礎能力子系統集存儲位置內容功能kernel內核子系統prebuilts編譯器及工具鏈子系統test測試子系統third_party開源第三方組件utils常用的工具集vendor廠商提供的軟件build.py編譯腳本文件1.7系統編譯與構建基于OpenHarmony的嵌入式開發29安全邊距[1.7.2]系統編譯構建過程

OpenHarmony編譯構建系統編譯子系統的構建：主要是基于GN和Ninja搭建；

Ninja是一個注重速度的小型編譯系統，其輸入文件是由高級別的編譯系統生成而來的，使編譯盡可能快速完成。Ninja的默認文件名是build.ninja，其它文件也以.ninja為后綴，編譯時使用ninja命令。

GN（GenerateNinja）是一種元構建系統，是ninja的前端，用于生成Ninja構建文件，目前支持Chromium，Fuchsia和OpenHarmony系統。支持功能：①以部件為最小粒度拼裝產品和獨立編譯；②支持輕量、小型、標準三種系統構建，支持SDK開發套件的構建；③支持芯片解決方案廠商的靈活定制和獨立編譯。

OpenHarmony3.1仍有部分組件需make構建，因此還需要Python、CMake、Makefile和Menuconfig，以及Bash等軟件和工具支撐。1.7系統編譯與構建基于OpenHarmony的嵌入式開發30安全邊距[1.7.2]系統編譯構建過程

OpenHarmony系統的包含關系產品A產品B子系統1部件(1)部件(2)子系統2部件(3)部件(7)子系統3部件(4)部件(5)部件(6)模塊①模塊②模塊③模塊④模塊⑤模塊⑥模塊⑦模塊⑧模塊⑨①平臺：開發板和內核的組合，不同的平臺支持的子系統和部件不同；②產品：產品是包含一系列部件的集合，編譯后產品的鏡像包可以運行在不同的開發板上；③子系統：系統功能按照“系統>子系統>部件”逐級展開，子系統是一個邏輯概念，具體由對應的部件構成；④部件：對子系統的進一步拆分，包括可復用的軟件單元。能獨立構建，以二進制方式集成，具備獨立驗證能力的二進制單元。⑤模塊：模塊就是編譯子系統的一個編譯目標，部件也可以是編譯目標。1.7系統編譯與構建基于OpenHarmony的嵌入式開發31安全邊距[1.7.2]系統編譯構建過程

OpenHarmony系統的包含關系產品B子系統1部件(1)部件(2)子系統3部件(4)部件(5)部件(6)模塊①模塊②模塊③模塊④模塊⑤模塊⑥模塊⑦模塊⑧模塊⑨子系統是某個路徑下所有部件的集合，一個部件只能屬于一個子系統。部件是模塊的集合，一個模塊只能歸屬于一個部件。模塊就是編譯子系統的一個編譯目標，部件也可以是編譯目標。產品A子系統2部件(3)部件(6)部件可以在不同的產品中實現有差異，通過變體或者特性feature實現。特性，部件用于體現不同產品之間的差異。編譯構建能編譯什么？不能編譯什么？1.7系統編譯與構建基于OpenHarmony的嵌入式開發32安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯構建流程否是開始選擇產品類型是開發板目錄編譯芯片解決方案選擇編譯類型編譯產品編譯部件編譯模塊結束hb

set用于設置要編譯的產品hb

build①讀取編譯配置：根據產品選擇的開發板，讀取開發板config.gni文件內容；②調用GN：調用gngen，讀取產品配置生成產品解決方案out目錄和Ninja文件；③調用Ninja：調用ninja-Cout/board/product編譯；④系統鏡像打包：將部件編譯產物打包，設置文件屬性和權限，制作文件系統鏡像。1.7系統編譯與構建基于OpenHarmony的嵌入式開發33安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（1/7）產品配置規則

OpenHarmony的源碼存儲結構產品編譯腳本產品配置文件文件系統打包的配置產品解決方案的OS適配HDF層的適配配置/驅動init進程啟動配置系統服務啟動配置產品解決方案廠商：華為海思產品名稱1.7系統編譯與構建基于OpenHarmony的嵌入式開發34安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（1/7）產品配置規則①vendor/company/product/init_configs/etc/Linux系統必備。包含rcS腳本，Sxxx腳本和fstab腳本。Sxxx腳本中的內容與開發板和產品需要有關，主要包括設備節點的創建、創建目錄、掃描設備節點、修改文件權限等。相關文件在產品編譯的BUILD.gn中按需拷貝到產品out目錄中，最終打包到rootfs鏡像中。②vendor/company/product/init_configs/hals/解決方案廠商對OS的適配，需要實現的接口需要查閱各個部件的readme說明文檔。③vendor/company/product/init_configs/init.cfginit進程啟動服務的配置文件，僅支持start（啟動某個服務）、mkdir（創建文件夾）、chmod（修改指定路徑/文件的權限）、chown（修改指定路徑/文件的屬組）和mount（掛載命令）。1.7系統編譯與構建基于OpenHarmony的嵌入式開發35安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（1/7）產品配置規則

④vendor/company/product/config.json：編譯構建的主入口產品名稱config.json的版本號,固定"3.0”系統類型，mini/small/standardOH系統版本芯片廠商開發板名稱內核類型內核版本號子系統子系統部件1.7系統編譯與構建基于OpenHarmony的嵌入式開發36安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（1/7）產品配置規則⑤vendor/company/product/fs.yml用于配置文件系統鏡像制作過程。將編譯產物打包成文件系統鏡像，比如用戶態根文件系統rootfs.img和可讀寫的userfs.img文件。fs.yml文件是一個可選文件，無文件系統的設備可以不配置該文件。文件由多個列表組成，每個列表對應一個文件系統。1.7系統編譯與構建基于OpenHarmony的嵌入式開發37安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（1/7）產品配置規則⑥vendor/company/product/BUILD.gn產品編譯的入口，用于編譯解決方案廠商源碼和拷貝啟動配置文件。編譯目標產品的目錄下的BUILD.gn會被使用。與產品名稱保持一致復制init配置其他■新增產品并編譯的主要步驟①創建產品目錄，按照產品配置規則創建產品目錄；②拼裝產品，在產品文件夾下創建并編輯config.json文件；③適配OS接口，在產品目錄下創建hals目錄，放入解決方案對OS適配的源碼和編譯腳本；④配置系統服務，在產品目錄下創建init_configs目錄，在其中創建并編輯init.cfg文件；⑤Linux內核，還需在init_configs目錄下創建etc目錄、創建并編輯rcS文件、Sxxx等；⑥配置文件系統鏡像，在產品目錄下創建fs.yml文件并設定文件系統規則；⑦按需配置產品Patch，在產品目錄下創建patch.yml文件；⑧編寫編譯腳本，在產品目錄下創建BUILD.gn文件并按需設定內容；⑨編譯產品，主要主要有命令行和hb兩種方式方式1.7系統編譯與構建基于OpenHarmony的嵌入式開發38安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（2/7）子系統配置規則子系統的配置規則主要是在build/subsystem_config.json文件中指定的子系統的路徑和子系統名稱路徑子系統名1.7系統編譯與構建基于OpenHarmony的嵌入式開發39安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（3/7）部件配置規則部件的bundle.json放在部件源碼的根目錄下。以泛sensor子系統的sensor服務部件為例，部件屬性定義描述文件字段說明如圖所示。部件配置中需要配置部件的名稱、源碼路徑、功能簡介、是否必選、編譯目標、RAM、ROM、編譯輸出、已適配的內核、可配置的特性和依賴等屬性定義。新增部件時必須在對應子系統json文件中添加部件定義，產品所配置的部件必須在某個子系統中被定義過。①添加部件；②拼裝產品將部件添加到產品配置中；③編譯，命令行方式活著hb方式；④編譯輸出。1.7系統編譯與構建基于OpenHarmony的嵌入式開發40安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（4/7）模塊配置規則編譯子系統通過模塊、部件和產品三層配置實現目標系統思維編譯和打包。模塊是編譯子系統的一個目標，包括動態庫、靜態庫、配置文件和預編譯模塊等，模塊必須要確定屬于特定的部件，一個模塊只能歸屬于一個部件。OpenHarmony使用定制化的Gn模板來配置模塊規則。產品A子系統2部件(3)部件(7)模塊⑩模塊?■常用的四類模塊配置規則①C/C++模板，包括ohos_shared_library、ohos_static_library、ohos_executable和ohos_source_set，代碼在源碼倉/build/templates/cxx/cxx.gni文件中；②預編譯模板，包括ohos_prebuilt_executable、ohos_prebuilt_shared_library和ohos_prebuilt_static_library，代碼在prebuilt.gni文件中；③Hap模板，包括ohos_hap、ohos_app_scope、ohos_js_assets和ohos_resources；④其他常用模板，包括配置文件模板ohos_prebuild_etc和sa配置模板ohos_sa_profile等。1.7系統編譯與構建基于OpenHarmony的嵌入式開發41安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（4/7）模塊配置規則否是開始新建子系統并添加json文件添加部件bundle.json有芯片解決方案有子系統有部件新建模塊BUILD.gn結束添加芯片解決方案修改產品配置是否修改產品配置否是新建并編譯模塊：編譯子系統通過模塊、部件和產品三層配置實現目標系統思維編譯和打包。1.7系統編譯與構建基于OpenHarmony的嵌入式開發42安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（5/7）芯片解決方案配置規則芯片解決方案是指基于某款開發板的完整解決方案，包含驅動、設備側接口適配、開發板sdk等。kernel_type:開發板使用的內核類型；kernel_version:開發使用的內核版本；board_cpu:開發板CPU類型；board_arch:開發芯片arch；board_toolchain:開發板編譯工具鏈名稱；board_toolchain_prefix：編譯工具鏈前綴；board_toolchain_type：編譯工具鏈類型；board_cflags：開發板的c文件編譯選項；board_cxx_flags：開發板的cpp文件編譯選項；board_ld_flags：開發板配置的鏈接選項。設備文件路徑開發板路徑芯片解決方案廠商開發板名稱LiteOS-A內核開發板編譯的配置1.7系統編譯與構建基于OpenHarmony的嵌入式開發43安全邊距[1.7.2]系統編譯構建過程

OpenHarmony的編譯配置規則：（7/7）系統能力配置規則

SysCap（SystemCapability，系統能力）是部件向開發者提供的接口的集合，有部件配置系統能力和產品配置系統能力兩類。部件目錄下的bundle.json文件component下關鍵字syscap，對內部配置相應的系統能力。系統能力若無賦值默認為true，若值為true則表示該部件默認開啟此系統能力，若值為false則表明該部件默認關閉此系統能力。vender/{company}/{product}/config.json若無配置，則以部件側的配置為準。產品側的配置優先級大于部件系統能力默認配置，若部件側默認配置為false，在產品側配置為true，則最終配置為true。1.7系統編譯與構建基于OpenHarmony的嵌入式開發44安全邊距[1.7.3]

系統的編譯命令通過編譯命令編譯產品：（1/2）命令行方式在源碼根目錄下執行prebuilts腳本，預編譯、安裝編譯器及工具

在代碼根目錄下執行全量版本的編譯命令，Release版本為：

如果要編譯Debug版本，則要添加參數，構成命令：編譯結果輸出鏡像保存在如下：

bashbuild/prebuilts_download.sh

./build.sh--product-name{product_name}

./build.sh--product-name{product_name}--gn-argsis_debug=true

out/{device_name}/packages/phone/images/

1.7系統編譯與構建基于OpenHarmony的嵌入式開發45安全邊距[1.7.3]

系統的編譯命令通過編譯命令編譯產品：（2/2）hb方式

設置要編譯的產品使用如下命令：

查看當前設置信息使用如下命令：

編譯產品、部件、模塊或芯片解決方案使用如下命令：

清除out目錄對應產品的編譯產物使用如下命令：

hb

set

hb

env

hb

build

hb

clean1.7系統編譯與構建基于OpenHarmony的嵌入式開發46安全邊距[1.7.4]

Docker編譯環境

Docker環境鏡像極大程度的簡化了配置環境的工作，開發者只需要從HuaweiCloudSWR下載鏡像、通過Docker加載鏡像即可。輕量系統、小型系統和標準系統的下載鏈接不同，請查閱官網。

HPM（HarmonyPackageManager，鴻蒙包管理器）系統中提供了docker_dist模板組建幫助開發者快速初始化HPM工程，利用Docker鏡像快速編譯OpenHarmony系統，很大程度上簡化了編譯前的環境配置工作。開發者只需要配置好Ubuntu和hpm-cli開發環境即可。該過程可參閱HPM相關文檔，不再介紹。1.8課程習題基于OpenHarmony的嵌入式開發47安全邊距

1.OpenHarmony作為一款嵌入式操作系統，除了具備常規的可裝卸性、實時性強、穩定性好等特點之外，還具備哪些主要的技術特點？相關內容在1.1.2小節

2.OpenHarmony能夠以分級的形式，兼容具有不同運算與處理性能的硬件平臺，主要包括哪三類？相關內容在1.1.3小節

3.OpenHarmony內核的Shell主要支持哪三類命令，請說出幾個具體命令名稱。相關內容在1.6.2小節受排版影響，本演示文稿所列代碼的規范性可能存在問題，以實際源碼為準基于OpenHarmony的嵌入式開發

第二章OpenHarmony的內核基礎大連理工大學-朱明安全邊距2.1芯片適配類型[2.1]OpenHarmony芯片類型適配問題：OpenHarmony設備分類的依據是什么？哪三種設備分類？三種分類的內核是什么？分別有哪些特性？

LiteOS面向IoT領域構建的輕量級物聯網操作系統內核面向智能家居、個人穿戴、車聯網、城市公共服務、制造業等領域；

內核輕快易用、實時性好、穩定性高、內核體積小、功耗低等特點；

具備有進程和線程調度、內存管理、IPC機制、Timer管理等功能；

支持ARM64、ARMCortex-A、ARMCortex-M0，Cortex-M3，Cortex-M4和Cortex-M7等芯片架構；

LiteOS也支持UP與SMP模式，在單核或者多核的環境上運行。基于OpenHarmony的嵌入式開發49[2.1]關于HarmonyOS的LitOS內核安全邊距2.1芯片適配類型基于OpenHarmony的嵌入式開發50①基礎內核：包括不可裁剪的極小內核和可裁剪的其他模塊。極小內核包含有任務管理、內存管理、中斷管理、異常管理和系統時鐘等。可裁剪的模塊包括信號量、互斥鎖、隊列管理、事件管理、軟件定時器等。②內核增強：在內核基礎功能之上，進一步提供增強功能，包括C++支持和調測組件等。調測組件提供了強大的問題定位及調測能力，包括shell命令、Trace事件跟蹤、獲取CPU占用率和LMS等。③文件系統：提供一套輕量級的文件系統接口以支持文件系統的基本功能，支持的文件系統類型包括vfs、ramfs、fatfs等。④系統庫接口：提供一系列系統庫接口,提升操作系統的可移植性及兼容性，包括Libc/Libm/POSIX以及CMSIS適配層等接口。安全邊距2.1芯片適配類型基于OpenHarmony的嵌入式開發51[2.1]關于HarmonyOS的LitOS內核⑤網絡協議棧：提供豐富的網絡協議棧以支持多種網絡功能。包括資源受限的Web傳輸協議（CoAP，ConstrainedApplicationProtocol）、輕量級物聯網設備管理協議（LwM2M，LightweightM2M）、消息隊列遙測傳輸協議（MQTT，MessageQueuingTelemetryTransport）、數據報傳輸層安全協議（DTLS，DatagramTransportLayerSecurity）和輕量級IP協議（LwIP，LightWeightInternetProtocol）等。⑥業務組件：構建于上述組件之上的一系列業務組件或框架，以支持更豐富的用戶場景，包括OTA、GUI、AI和傳感框架等。⑦IDE（HuaweiLiteOSStudio）：基于LiteOS操作系統定制開發的工具，提供了界面化的代碼編輯、編譯、燒錄、調試等功能。安全邊距2.2LiteOS-M內核基于OpenHarmony的嵌入式開發52[2.2]面向IoT領域的輕量級物聯網操作系統內核①內核特性上接近RTOS，對標FreeFTOS、RT-Thread和uc/OS操作系統，。②目前只能運行在Cortex-M3、Cortex-M33、Cortex-M4、Cortex-M55、Cortex-M7、RISC-V、XtensaLX6和CSKYv2芯片和架構上。③上述處理器都屬于MCU，不支持MMU。④內核空間和APP空間不能隔離，APP一旦出錯會導致整個系統就會崩潰。硬件相關層提供統一的HAL接口，提升硬件易適配性安全邊距2.3LiteOS-A內核基于OpenHarmony的嵌入式開發53[2.3]

構建小體積、低功耗、高性能的統一生態框架更豐富的內核機制，更加全面的POSIX標準接口以及統一驅動框架HDF（OpenHarmonyDriverFoundation）等特性。

①支持MMU，實現內核態和用戶態分離，支持虛擬內存等；②支持獨立進程，調度對象為進程和線程，更好的兼容軟件和開發者體驗，新增支持多進程，使得應用之間內存隔離、相互不影響，提升系統的健壯性；③支持文件系統，包括虛擬文件系統和塊設備等；④支持復雜的IPC，包括LiteIPC和VDSO（VirtualDynamically-linkedSharedObject）等；安全邊距2.3LiteOS-A內核基于OpenHarmony的嵌入式開發54[2.3]

構建小體積、低功耗、高性能的統一生態框架更豐富的內核機制，更加全面的POSIX標準接口以及統一驅動框架HDF（OpenHarmonyDriverFoundation）等特性。

⑤支持多核調度，支持雙核微處理器和雙核調度；⑥支持POSIX接口，支持超過1200個標準POSIX接口，更加全面的支持POSIX標準接口，使得應用軟件易于開發和移植；⑦引入統一驅動框架HDF，為設備廠商提供了更統一的接入方式，使驅動更加容易移植。安全邊距2.3LiteOS-A內核基于OpenHarmony的嵌入式開發55[表2.1]

LiteOS-M和LiteOS-A的對比特性LiteOS-MLiteOS-A處理器類型Cortex-M、RISC-V等，單核Cortex-A，多核RAM容量128KB～1MB1MB～128MB任務調度搶占式多任務調度搶占式多進程、多線程調度，支持輪詢調度和FIFO調度虛擬內存不支持支持內存加載bestfitbestfit和bestfit_littleIPC通信類型事件、互斥鎖、信號量、隊列事件、互斥鎖、信號量、隊列、信號、用戶態快速互斥鎖、自旋鎖、輕量級進程間通信VFS不支持支持Shell不支持支持標準庫類型不支持支持安全邊距2.4內核抽象層KAL基于OpenHarmony的嵌入式開發56[2.4]

構建小體積、低功耗、高性能的統一生態框架問題：OpenHarmony的技術架構，按照功能進行分層，有哪些層？LiteOS-M所基于的Cortex-M和RISCV等構架的微處理器提供的IPC等接口并不相同，為了屏蔽硬件差異，實現對外統一的IPC等接口。LiteOS-M內核中構建了KAL（內核抽象層），對外提供統一CMSIS和部分的POSIX接口，規范與內核的對接，如CMSIS采用的就是CMSIS-RTOSv2規范來約束的，而部分標準的POSIX接口則是基于musllibc庫以及自研接口實現的。LiteOS-M所支持的硬件設備較為簡單，集中于UART、I2C和GPIO等功能簡單的功能模塊，其驅動和功能簡單，無需復雜的初始化和驅動設定，不需要動態加載卸載驅動。Cortex-M和RISCV等構架的微處理器性能不強，也難以支持上述高級功能的實現。因此，只需要使用KAL屏蔽硬件差異即可。LiteOS-A內核則直接通過musllibc庫實現了更為完整的POSIX接口。LiteOS-A為了實現硬件設備驅動程序的動態加載和卸載功能，使用了HDF等功能替代了KAL，在性能強大的處理器的支持下，可以實現更豐富的內核功能。安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發57[2.5.1]中斷的基本概念CPU執行主程序低級中斷請求響應低級中斷請求響應高級中斷請求高級中斷請求CPU執行低級中斷服務程序CPU執行高級中斷服務程序返回低級中斷請求返回主程序解釋：

指在程序運行過程中，出現需要由微處理器中的CPU立即處理的事務時，CPU需要暫停執行當前程序，轉而執行新程序，以及在新程序執行完，返回繼續執行原有程序的過程。目標：避免CPU把大量時間耗費在等待和查詢外設狀態的操作上，大大提高系統實時性以及執行效率，且中斷是可以有條件嵌套的。場景：通過中斷機制，外部設備在不需要CPU介入時，CPU可以執行其它任務；當外設需要CPU處理外設數據或者其他請求時，就會產生中斷信號，CPU會根據當前任務情況，響應外設的中斷請求。安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發58[2.5.1]中斷的基本概念CPU執行主程序低級中斷請求響應低級中斷請求響應高級中斷請求高級中斷請求CPU執行低級中斷服務程序CPU執行高級中斷服務程序返回低級中斷請求返回主程序中斷的請求和處理過程，主要涉及到的概念包括：①中斷號。中斷號是中斷請求信號特定的標志，CPU根據中斷號判斷才能夠判定出是哪個設備提出的中斷請求；②中斷請求。中斷請求實際上是一類特定的信號，是外設由于特定事件向CPU發送的信號。該信號將請求CPU中斷當前任務，需要CPU處理該外設事件，這一過程稱為中斷請求；③中斷優先級。當外設所產生的中斷，是可能會發生疊加的，新產生的中斷能夠打斷正在處理的中斷事件是一個重要問題。為使系統能夠及時響應并合理處理所有的中斷事件，系統需要根據中斷事件的重要性和緊迫程度，將中斷源分為若干個級別，這種中斷響應的級別稱為是中斷優先級。在微處理器內部，中斷請求并非直接發送給CPU，而是發送給中斷控制器的，由中斷控制器對中斷請求進行預處理后，再發送給CPU；安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發59[2.5.1]中斷的基本概念CPU執行主程序低級中斷請求響應低級中斷請求響應高級中斷請求高級中斷請求CPU執行低級中斷服務程序CPU執行高級中斷服務程序返回低級中斷請求返回主程序中斷的請求和處理過程，主要涉及到的概念包括：④中斷處理程序，又稱中斷服務程序。當外設發出中斷請求后，CPU暫停當前的任務，轉而去響應中斷請求。這種響應就是通過執行中斷處理程序實現的，產生中斷的每個外設都必須有唯一對應的中斷處理程序；⑤中斷觸發。中斷源向中斷控制器發送中斷信號，中斷控制器對中斷進行仲裁，確定優先級，將中斷信號發送給CPU。中斷源產生中斷信號的時候，會將中斷觸發器的對應位置位，表明該中斷源產生了中斷。CPU在響應該中斷后，會自動或在中斷處理程序中將該位復位；⑥中斷向量。中斷處理程序的入口地址；⑦中斷向量表。存儲中斷向量的內存區域，某個外設的中斷向量與其中斷號必須是一一對應的，中斷向量在中斷向量表中按照中斷號的順序進行存儲。安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發60[2.5.1]中斷的基本概念CPU執行主程序低級中斷請求響應低級中斷請求響應高級中斷請求高級中斷請求CPU執行低級中斷服務程序CPU執行高級中斷服務程序返回低級中斷請求返回主程序普適問題：從用戶角度使用需要控制中斷的哪些功能？①創建中斷（Create）；②刪除中斷（Delete）；③打開中斷（Unlock）；④關閉中斷（Lock）；⑤使能中斷（Enable）；⑥禁用中斷（Disable）；⑦設置中斷的優先級（SetPriority）；⑧觸發中斷（Trigger）；⑨清除中斷（Clear）；⑩其他相關控制功能或高階控制功能。LiteOS-M和LiteOS-A由于系統性能和硬件構架不同，中斷的執行也有所不同對硬件的初始化，必須要充分考慮初始化成功之后的后果，防止未知狀態的發生安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發61[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/打開/關閉/禁用/使能/觸發/清除中斷+設置優先級LOS_HwiCreate()ArchHwiCreate()

/arch/arm/cortex-m7/gcc/los_interrupt.c實現：LITE_OS_SEC_TEXT_INITUINT32ArchHwiCreate(HWI_HANDLE_ThwiNum,HWI_PRIOR_ThwiPrio,HWI_MODE_ThwiMode,HWI_PROC_FUNChwiHandler,HwiIrqParam*irqParam)hwiNum：硬件的中斷號；hwiPrio：硬件的中斷優先級；hwiMode：硬件的中斷模式，暫時沒有功能；hwiHandler：要注冊的中斷處理程序；irqParam：傳遞給中斷處理程序的參數。/kernel/liteos_m/arch/include/los_interrupt.h文件中：#defineLOS_HwiCreateArchHwiCreate

必要的安全檢查hwiHandler

==

NULLhwiNum>=OS_HWI_MAX_NUMhwiPrio>OS_HWI_PRIO_LOWESTg_hwiForm[hwiNum+OS_SYS_VECTOR_CNT]!=(HWI_PROC_FUNC)HalHwiDefaultHandler安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發62[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/打開/關閉/禁用/使能/觸發/清除中斷+設置優先級LOS_HwiCreate()ArchHwiCreate()

必要的安全檢查intSave=LOS_IntLock()OsSetVector()if(irqParam!=NULL){OsSetVector(hwiNum,hwiHandler,irqParam->pDevId);}else{OsSetVector(hwiNum,hwiHandler,NULL);}VOIDOsSetVector(UINT32num,HWI_PROC_FUNCvector)

{if((num+OS_SYS_VECTOR_CNT)<OS_VECTOR_CNT){

g_hwiForm[num+OS_SYS_VECTOR_CNT]=HalInterrupt;

g_hwiHandlerForm[num+OS_SYS_VECTOR_CNT]=vector;}}//CountofM-Coresysteminterruptvector.#defineOS_SYS_VECTOR_CNT16#defineOS_VECTOR_CNT

(OS_SYS_VECTOR_CNT+OS_HWI_MAX_NUM)安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發63[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/打開/關閉/禁用/使能/觸發/清除中斷+設置優先級LOS_HwiCreate()ArchHwiCreate()

必要的安全檢查intSave=LOS_IntLock()OsSetVector()①g_hwiForm，中斷向量表，定義如下：STATICHWI_PROC_FUNC…

g_hwiForm[OS_VECTOR_CNT]={0};-5和16，系統的向下減，用戶的向上增對于中斷號hwiNum，g_hwiForm[hwiNum]表示該中斷對應的中斷入口程序安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發64[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/打開/關閉/禁用/使能/觸發/清除中斷+設置優先級LOS_HwiCreate()ArchHwiCreate()

必要的安全檢查intSave=LOS_IntLock()OsSetVector()②g_hwiHandlerForm，中斷處理程序，定義如下：STATIC

…

g_hwiHandlerForm[OS_VECTOR_CNT]={{0,0}};HwiUnmask()設定中斷屏蔽觸發器HwiUnmask()

->NVIC_EnableIRQ((IRQn_Type)hwiNum)Description：EnableInterruptinNVICInterruptController.Parameter：IRQn_TypeIRQnspecifiesthepositiveinterruptnumber.Itcannotbesystemexception.

Return：NoneHwiSetPriority()HwiSetPriority((IRQn_Type)hwiNum,hwiPrio);

-> NVIC_SetPriority((IRQn_Type)hwiNum,priority);Description：SetthePriorityGroupinginNVICInterruptController.Parameter：Priority_groupingisprioritygroupingfield

Return：NoneLOS_IntRestore(intSave)保存恢復returnLOS_OK恢復到LOS_Lock之前的狀態安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發65[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/打開/關閉/禁用/使能/觸發/清除中斷+設置優先級LOS_HwiDelete()ArchHwiDelete()

/arch/arm/cortex-m7/gcc/los_interrupt.c實現：LITE_OS_SEC_TEXT_INITUINT32ArchHwiDelete(HWI_HANDLE_ThwiNum,HwiIrqParam*irqParam)hwiNum：硬件的中斷號；irqParam：傳遞給中斷處理程序的參數。/kernel/liteos_m/arch/include/los_interrupt.h文件中：#defineLOS_HwiDeleteArchHwiDelete必要的安全檢查hwiNum>=OS_HWI_MAX_NUMNVIC_DisableIRQ()NVIC_DisableIRQ((IRQn_Type)hwiNum);Description：DisableInterruptinNVICInterruptController.Parameter：IRQn_TypeIRQnisthepositivenumberoftheexternalinterrupt.Itcannotbesystemexception.

Return：Noneg_hwiForm[hwiNum+OS_SYS_VECTOR_CNT]=(HWI_PROC_FUNC)HalHwiDefaultHandler;intSave=LOS_IntLock()…恢復到默認的中斷處理程序安全邊距2.5中斷與異常處理機制基于OpenHarmony的嵌入式開發66[2.5.2]

LiteOS-M內核中斷（以Cortex-M7為例）

創建/刪除/關閉/打開/禁用/使能/觸發/清除中斷+設置優先級LOS_IntLock()ArchIntLock()

/arch/arm/cortex-m7/gcc/los_dispatch.S實現：/kernel/liteos_m/arch/include/los_interrupt.h文件中：#defineLOS_IntLockArchIntLockArchIntUnLock:.fnstart.cantunwindMRSR0,PRIMASK

CPSIDIBXLR.fnendMarksthestartofafunctionwithanunwindtableentry.Preventsunwindingthroughthecurrentfunction.讀取PRIMASK到R0，R0為返回值。PRIMASK是單一比特寄存器PRIMASK=1時屏蔽所有可屏蔽（