尋找實(shí)時(shí)嵌入式軟件開(kāi)發(fā)解決方案

2022-06-21

尋找實(shí)時(shí)嵌入式軟件開(kāi)發(fā)解決方案

了解典型嵌入式實(shí)時(shí)操作系統(RTOS)應用程序的常見(jiàn)問(wèn)題和潛在解決方案，以及標準化和可重用性問(wèn)題以及在應用程序中移植RTOS代碼的示例。

嵌入式處理器已經(jīng)發(fā)展成為復雜而強大的設備，通?？梢栽谝粋€(gè)小的物理封裝中滿(mǎn)足各種要求。隨著(zhù)應用程序變得越來(lái)越復雜，工程師必須跟上步伐，以應對由此導致的軟件復雜性增加。在工業(yè)應用中，該軟件通常運行多年（如果不是幾十年的話(huà)），并且在其整個(gè)生命周期內管理嵌入式應用并非易事。

在實(shí)踐中，一些重要的問(wèn)題會(huì )影響所有重要的軟件項目，無(wú)論它們是否依賴(lài)于RTOS。此類(lèi)問(wèn)題的示例包括在應用程序的整個(gè)生命周期內管理構建系統、可移植性注意事項、日志記錄和shell機制。在下面的圖1中，您可以看到一個(gè)帶有可定制組件集的示例RTOS。

圖 1.示例RTOS中的可定制組件集。 

本文介紹了RTOS的常見(jiàn)問(wèn)題和任務(wù)。然后，在檢查Zephyr OS在示例應用程序中的作用之前，它分析了嵌入式軟件開(kāi)發(fā)系統對標準化和可重用性的需求。 

耗時(shí)的RTOS挑戰

幾乎每個(gè)重要的軟件項目都需要一個(gè)可靠的構建系統，無(wú)論項目是否包含實(shí)時(shí)組件。在應用程序的整個(gè)生命周期（可能跨越多年）中維護這樣的構建系統并不是一項簡(jiǎn)單的任務(wù)。包含的組件和外部庫中看似微小的更新和更改會(huì )很快導致耗時(shí)的錯誤搜尋，從而占用開(kāi)發(fā)人員的時(shí)間。 

軟件和模塊更新

如果沒(méi)有存儲庫管理工具，開(kāi)發(fā)人員不僅必須檢查主RTOS內核的更新，而且還必須追蹤項目中使用的每個(gè)外部模塊的每一個(gè)變化。但是，必須記住，某些模塊依賴(lài)（或基于）外部庫和模塊，開(kāi)發(fā)人員隨后也必須對其進(jìn)行跟蹤。這些子模塊中缺少更新可能會(huì )破壞構建在模塊之上的組件，從而導致耗時(shí)的錯誤搜索。管理這些依賴(lài)鏈并非易事，存儲庫或依賴(lài)管理工具為工程師節省了大量時(shí)間，他們可以專(zhuān)注于實(shí)現嵌入式應用程序。  

跨平臺移植

將項目從一個(gè)設備移植到另一個(gè)設備會(huì )很快成為一個(gè)復雜而冗長(cháng)的過(guò)程。即使工程師決定使用來(lái)自同一制造商的不同設備，該過(guò)程也可能涉及許多耗時(shí)的重新配置任務(wù)。一些修復和實(shí)現可能在一個(gè)系統上工作，而在使用其他硬件時(shí)它們不能按預期運行。

此類(lèi)問(wèn)題的原因可能是：

不同的內存布局

硬件地址的變化

不同的硬件功能

不同的驅動(dòng)接口

以將值寫(xiě)入系統中的閃存的程序為例。在他們最初的設計中，工程師使用了一個(gè)包含片上閃存和閃存控制器的微控制器單元(MCU)。然而，由于供應短缺，設計團隊將設計切換到另一個(gè)沒(méi)有內置閃存和外部閃存模塊的MCU。由于該軟件包含用于訪(fǎng)問(wèn)片上閃存的硬件特定代碼，因此團隊無(wú)法在不重新設計代碼庫的重要部分的情況下輕松地將應用程序移植到新的 MCU平臺。 

這個(gè)問(wèn)題會(huì )很快導致不同設備的多個(gè)相似代碼庫，從而導致更嚴重的問(wèn)題，例如，在實(shí)施影響所有代碼庫的錯誤修復時(shí)。圖書(shū)館組織和配置管理進(jìn)一步增加了這種重新配置任務(wù)的復雜性。 

狀態(tài)和錯誤記錄

通常，更復雜的項目需要一些日志機制來(lái)輸出調試和狀態(tài)消息，或者需要一個(gè)外殼來(lái)讓開(kāi)發(fā)人員和外部系統與實(shí)現的軟件進(jìn)行交互。然而，這些設施并不總是RTOS的一部分，開(kāi)發(fā)人員必須實(shí)施它們或將以前實(shí)施的解決方案移植到他們當前的項目中。自定義實(shí)現還必須確保線(xiàn)程安全，因此必須在將它們包含在軟件的生產(chǎn)版本中之前進(jìn)行廣泛的評估和測試。

常見(jiàn)的RTOS解決方案

鑒于上述問(wèn)題和任務(wù)，許多傳統RTOS提供實(shí)時(shí)調度程序、同步支持和內存管理功能。下面，我們將檢查幾個(gè)流行的選項（FreeRTOS、Azure RTOS和Zephyr OS）及其潛在的優(yōu)缺點(diǎn)。

自由實(shí)時(shí)操作系統

FreeRTOS 最初是一個(gè)簡(jiǎn)單的實(shí)時(shí)內核，提供線(xiàn)程、同步和內存分配機制。該項目的輕量級特性使其對各種嵌入式應用程序具有吸引力。截至本文發(fā)表時(shí)，該項目由亞馬遜維護。開(kāi)發(fā)人員專(zhuān)注于添加額外的云服務(wù)集成，例如對 Amazon IoT 核心和其他 AWS 服務(wù)的支持。MIT 許可證確保 FreeRTOS 保持免費。 

此外，輕量級核心調度程序易于集成到項目中，并且該操作系統仍然是當今最流行的 RTOS 之一。但是，與ThreadX不同，FreeRTOS 并非設計用于安全關(guān)鍵系統。對于此類(lèi)系統，工程師將不得不依賴(lài)使用名為SafeRTOS的商業(yè)許可產(chǎn)品。

Azure 實(shí)時(shí)操作系統

Microsoft Azure RTOS，以前稱(chēng)為ThreadX，是FreeRTOS的替代品?？傮w而言，Azure RTOS 提供了比FreeRTOS更好的硬實(shí)時(shí)功能，并且還符合各種安全相關(guān)標準。但是，這些選項都無(wú)法有效解決一些首要問(wèn)題。

一個(gè)問(wèn)題是FreeRTOS和Azure OS是如何被塑造未來(lái)的大公司收購的。由于亞馬遜和微軟提供專(zhuān)有的云服務(wù)，它們可能會(huì )讓開(kāi)發(fā)人員輕松連接到他們的特定云服務(wù)。但是，這些公司可以嘗試讓開(kāi)發(fā)人員更麻煩地集成不同的云服務(wù)。  

和風(fēng)操作系統

相比之下，Zephyr OS 是 RTOS 領(lǐng)域中一個(gè)相對較新的項目，旨在解決上述問(wèn)題。它引入了標準化部件，開(kāi)發(fā)人員可以在跨各種受支持平臺的多個(gè)項目中使用這些部件，而無(wú)需重新配置工作。Zephyr OS 是一個(gè)社區管理的開(kāi)源項目，提供獨立于供應商的解決方案，工程師無(wú)需支付許可費即可使用。由于該項目的這種獨立于供應商和開(kāi)源的性質(zhì)，單個(gè)公司不太可能顯著(zhù)決定 Zephyr OS 與其他產(chǎn)品和服務(wù)的集成程度。圖 2 顯示了 Zephyr OS 的框圖。

圖 2. Zephyr OS 結構框圖。 

Zephyr OS 的公開(kāi)可用源代碼和廣泛的在線(xiàn)文檔還確保嵌入式工程師可以了解他們做出關(guān)鍵決策所需的所有有關(guān) Zephyr 的詳細信息，而無(wú)需對任何源文件進(jìn)行逆向工程。此外，與完全閉源解決方案相比，由許多開(kāi)發(fā)人員管理的開(kāi)源項目通常具有更好的安全實(shí)施。此外，幾乎任何開(kāi)發(fā)人員和公司都可以添加對新架構和硬件的支持。  

示例解決方案——Zephyr 項目

Zephyr項目（圖 3）具有多個(gè)離散塊，可用于簡(jiǎn)化構建過(guò)程并通過(guò)標準化組件鏈接不同的庫。 

圖 3. Zephyr項目的主要功能。

一般來(lái)說(shuō)，Zephyr構建系統讓工程師可以自由選擇他們想要如何實(shí)現特定選項以及他們想要使用哪些內置設施。雖然SDK包含許多有利的功能，但其中大部分是完全可選的。工程師可以自由地在他們的項目中使用它們，或者按照他們一貫的做法來(lái)實(shí)現功能。 

內置外設和驅動(dòng)程序接口是這種方法的另一個(gè)例子。標準化的應用程序編程接口(API) 允許工程師將大量代碼重新用于標準通信選項，例如I2C和串行外圍接口(SPI)。通用異步收發(fā)器(UART) 驅動(dòng)程序可確保內置日志記錄工具開(kāi)箱即用。  

Zephyr包管理器

Zephyr的內置包管理器（稱(chēng)為 West）從公共或私有存儲庫中提取外部包，并啟動(dòng)應用程序的整個(gè)構建過(guò)程。它還負責刷新MCU，并可以進(jìn)一步生成物料清單(BOM)。

此外，Zephyr將不屬于Zephyr核心的代碼保存在單獨的外部存儲庫中。這些外部存儲庫包括可重用的IoT應用程序構建塊，例如：

供應商HAL

文件系統實(shí)現

公共庫（如OpenAMP和OpenThread）

此外，West 還可以管理私有存儲庫中保存的其他外部庫和代碼。這些外部組件和第三方庫有自己的發(fā)布時(shí)間表和CI/CD工具使用，完全獨立于Zephyr。Zephyr中的這個(gè)元工具確保開(kāi)發(fā)人員不必考慮如何在項目中包含外部庫。此外，團隊可以專(zhuān)注于構建他們的嵌入式應用程序，而不是跟蹤添加到Zephyr項目的所有外部第三方和官方軟件模塊的更改和依賴(lài)關(guān)系。在后臺，West使用CMake來(lái)管理構建過(guò)程。 

借用 Linux

Zephyr SDK借鑒了Linux的一些概念，其中兩個(gè)是Kconfig和設備樹(shù)。

在Zephyr中，Kconfig 提供了一種將庫鏈接到項目的簡(jiǎn)單方法，而無(wú)需確切知道要使用哪些源文件和構建宏。Zephyr SDK 包括一個(gè)簡(jiǎn)單的Linux設備樹(shù)實(shí)現，它允許開(kāi)發(fā)人員記錄系統中存在哪些硬件。然而，與Linux中的動(dòng)態(tài)設備樹(shù)（圖 4）相比，Zephyr使用它們更像是在編譯時(shí)描述硬件的數據結構。

圖 4.此圖比較了本示例中使用的兩個(gè)評估板的設備樹(shù)。突出顯示的部分顯示了兩個(gè)文件之間的差異。標記該標簽是因為 littlefs（本示例中使用的文件系統）需要它。 

此描述保持靜態(tài)，在運行時(shí)不會(huì )更改。 

Zephyr的示例用例

讓我們仔細看看兩個(gè)示例用例——每個(gè)用例都利用MCU的GPIO來(lái)控制某些引腳的狀態(tài)——以說(shuō)明這些功能是如何從實(shí)際在該領(lǐng)域工作的設計人員的角度結合在一起的。

跨MCU平臺移植

在第一個(gè)示例中，使用LPC55S69 MCU 的原始電路板為工業(yè) I/O 面板應用提供了足夠數量的可用GPIO引腳。然而，該設計的后續迭代采用了S32K118 MCU（來(lái)自另一個(gè)硬件系列，具有相當數量的可用 I/O引腳）。

這種新設計包含更多的外部組件，并且MCU沒(méi)有提供足夠的可訪(fǎng)問(wèn)GPIO引腳。因此，工程師添加了一個(gè)SPI-to-GPIO擴展器來(lái)彌補缺少的通道，并且他們需要在兩個(gè)項目之間共享盡可能多的源代碼。 

使用Zephyr已包含的驅動(dòng)程序（允許SPI到GPIO轉換器在系統中顯示為常規MCU GPIO引腳），開(kāi)發(fā)人員無(wú)需更改源代碼。相反，他們只需要為較新的電路板設計更新設備樹(shù)。這讓設計人員可以避免需要多個(gè)代碼庫、對源代碼進(jìn)行復雜的調整以及冗長(cháng)的回歸測試和移植過(guò)程。這個(gè)例子進(jìn)一步強調了工程師應該依靠久經(jīng)考驗的簡(jiǎn)單實(shí)現而不是快速修復和黑客來(lái)維護應用程序的可靠性和安全性。

跨不同封裝和引腳的移植

盡管Zephyr是非常特定于電路板的，但開(kāi)發(fā)人員不需要為每個(gè)系列的自定義電路板編寫(xiě)新的設備樹(shù)源文件。換句話(huà)說(shuō)，開(kāi)發(fā)人員可以利用評估套件來(lái)測試他們想要在產(chǎn)品中使用的 MCU，例如LPC55S69。對于原型，他們可以使用 制造商（在本例中為 NXP）提供的LPC55S69-EVK和DST。這可以在圖 5 中顯示。 

圖 5.工程師只需對Zephyr設備樹(shù)結構和pinmux.c文件進(jìn)行細微調整，即可將應用程序從 EVK 移植到使用不同封裝中相同芯片的定制板上。

一旦開(kāi)發(fā)人員驗證代碼在評估套件上工作，他們只需要為他們的特定定制板創(chuàng )建一個(gè)定制設備樹(shù)覆蓋(DTO)。覆蓋文件描述了定制板的特定硬件，以便Zephyr構建系統可以連接它。 

將RTOS推向新的高度

本文研究了使用傳統嵌入式RTOS所特有的幾個(gè)總體問(wèn)題。首先，在其整個(gè)生命周期內管理軟件產(chǎn)品并非易事。問(wèn)題始于維護和更新第三方和官方外部庫。開(kāi)發(fā)人員通常必須跟蹤對這些庫所做的更新。更新那些引用的庫總是有風(fēng)險的，因為這樣做可能會(huì )導致無(wú)效或損壞的依賴(lài)關(guān)系和版本不兼容。 

安全問(wèn)題和潛在漏洞幾乎困擾著(zhù)所有大型軟件系統，實(shí)時(shí)操作系統也不例外。即使是已建立的協(xié)議和產(chǎn)品，即使經(jīng)過(guò)多年的可靠運行，也可能會(huì )受到損害。然而，閉源和專(zhuān)有軟件產(chǎn)品面臨更大的風(fēng)險，因為更少的開(kāi)發(fā)人員可以檢查代碼并測試可能的安全缺陷。

Zephyr等開(kāi)源系統為開(kāi)發(fā)人員提供了一種可訪(fǎng)問(wèn)的方式，以確保他們的設計從頭開(kāi)始實(shí)現標準化和可重用性。在此處了解如何使用恩智浦 MCU充分利用您的RTOS解決方案。