尋找實時嵌入式軟件開發解決方案

2022-06-21

尋找實時嵌入式軟件開發解決方案

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

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

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

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

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

耗時的RTOS挑戰

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

軟件和模塊更新

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

跨平臺移植

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

此類問題的原因可能是：

不同的內存布局

硬件地址的變化

不同的硬件功能

不同的驅動接口

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

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

狀態和錯誤記錄

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

常見的RTOS解決方案

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

自由實時操作系統

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

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

Azure 實時操作系統

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

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

和風操作系統

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

圖 2. Zephyr OS 結構框圖。 

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

示例解決方案——Zephyr 項目

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

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

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

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

Zephyr包管理器

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

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

供應商HAL

文件系統實現

公共庫（如OpenAMP和OpenThread）

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

借用 Linux

Zephyr SDK借鑒了Linux的一些概念，其中兩個是Kconfig和設備樹。

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

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

此描述保持靜態，在運行時不會更改。 

Zephyr的示例用例

讓我們仔細看看兩個示例用例——每個用例都利用MCU的GPIO來控制某些引腳的狀態——以說明這些功能是如何從實際在該領域工作的設計人員的角度結合在一起的。

跨MCU平臺移植

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

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

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

跨不同封裝和引腳的移植

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

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

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

將RTOS推向新的高度

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

安全問題和潛在漏洞幾乎困擾著所有大型軟件系統，實時操作系統也不例外。即使是已建立的協議和產品，即使經過多年的可靠運行，也可能會受到損害。然而，閉源和專有軟件產品面臨更大的風險，因為更少的開發人員可以檢查代碼并測試可能的安全缺陷。

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