大家好，今天分享一篇嵌入式軟件架構設計相關的文章。

軟件架構這東西，眾說紛紜，各有觀點。在我看來，軟件架構是軟件系統的基本結構，包含其組件、組件之間的關系、組件設計與演進的規則，以及體現這些規則的基礎設施。

軟件架構，從來不是一件容易事，它貫穿在產品的整個生命周期，需要所有團隊成員遵守并自律，才能將架構思想在軟件中體現。新手工程師，由于經歷的項目太少，看不到項目全貌，很難從全局理解軟件架構。但軟件架構真的只是資深工程師的專利嗎？這個也不見得。

古人作文，講究立意為先。今天工程師做項目和產品，也應該先立意。這個意，就是指要有高度。工程師入門能從軟件架構的高度出發，看待軟件問題，相信對軟件的理解，會更加深刻一些。因此，我總結了軟件架構的六個步驟，供嵌入式工程師參考。

上次談到了嵌入式軟件架構的第一個步驟，抽象層。建立抽象層（HAL或者DAL）的目的，是為了隔離硬件，讓代碼與硬件無關。即使整個項目的代碼，由某工程師一個人完成，抽象層仍是是有必要的。

但這次我們要聊的是，統一的基礎設施，這是針對多人合作一個項目，或者多個項目共享同一個系統架構的情況。

如果說，你手頭的項目，沒有與他人合作，也不會有后續的相關項目，軟件基礎設施這一步，可以直接跳過。

基礎設施，分為硬件基礎設施和軟件基礎設施。硬件基礎設施，包含常用器件庫、封裝庫、原理圖庫和硬件參考設計等等；而今天我們討論的重點，主要在于軟件基礎設施。軟件基礎設施包含以下內容：

• ?基礎數據結構。

• ?底層庫。比如C標準庫、加密庫、校驗庫、工具庫等等。

• ?操作系統/調度機制。包含操作系統以及調度相關服務。

• ?中間件。比如文件系統、協議棧、數據庫等。

• ?框架與機制。比如消息通信機制、事件驅動機制、狀態機框架、行為樹框架。

• ?工具支持。

• ?統一的編程工具鏈。

• ?統一的代碼風格和編程規范。

在一些小公司粗放的開發模式中，并不規定工程師所依賴的軟件平臺、硬件平臺和工具，而是由工程師自己決定。很多工程師，也喜歡這種自由奔放的開發模式，認為只有在這種環境中，才能發揮自身創造力。這種認知是有偏差的，這個我們后續找機會詳細討論。

隨著小公司研發能力的提升，對軟件基礎設施進行約束和規定，幾乎是注定的事情。因為軟件區別于其他技術的本質，是在于其復用性。

復用程度越高的軟件，質量越高，對開發效率和開發質量的提升，就越大。無論從公司的降本增效還是科學管理的角度，都有著強大的動機，去統一軟件基礎設施。當軟件的基礎設施統一之后，會產生如下優點：

• ?軟件質量提升，風格的高度一致性
• ?軟件復用性，會提升至一個新的水平
• ?將可復用的功能，盡量抽象到基礎設施層，減少軟件冗余，提升開發效率。
• ?為高層模塊提供約束和紀律
• ?有利于團隊的技術積累和技術傳承
• ?有利于團隊的技術培訓

• ?是團隊進行單元測試和測試驅動開發，以及跨平臺開發的前提。

因此，是否統一，根本不是一個有爭議的問題；如何統一，才是今天我們的重點。

一、基礎類型與宏定義

統一的軟件基礎設施的前提，就是聲明統一的基礎數據類型和宏，以克服不同的硬件平臺和編譯器的差異性。

比如下面是我從開源項目EventOS中摘錄出來的代碼，不見得很完整，只能代表在我在項目里需求。

#include

typedefunsignedinteos_u32_t;
typedefsignedinteos_s32_t;
typedefunsignedshorteos_u16_t;
typedefsignedshorteos_s16_t;
typedefunsignedchareos_u8_t;
typedefsignedchareos_s8_t;
typedefbooleos_bool_t;

#defineEOS_NULL((void*)0)

#defineEOS_U32_MAX(0xffffffffU)
#defineEOS_U32_MIN(0U)
#defineEOS_U16_MAX(0xffffU)
#defineEOS_U16_MIN(0U)
#defineEOS_U8_MAX(0xffU)
#defineEOS_U8_MIN(0U)

編譯器相關的宏定義。使用宏，屏蔽掉編譯器的差異，會

/*CompilerRelatedDefinitions*/
#ifdefined(__ARMCC_VERSION)/*ARMCompiler*/

#defineeos_section(x)__attribute__((section(x)))
#defineeos_used__attribute__((used))
#defineeos_align(n)__attribute__((aligned(n)))
#defineeos_weak__attribute__((weak))
#defineeos_inlinestatic__inline

#elifdefined(__GNUC__)/*GNUGCCCompiler*/

#defineeos_section(x)__attribute__((section(x)))
#defineeos_used__attribute__((used))
#defineeos_align(n)__attribute__((aligned(n)))
#defineeos_weak__attribute__((weak))
#defineeos_inlinestatic__inline

#elifdefined(__IAR_SYSTEMS_ICC__)/*forIARCompiler*/

#defineeos_section(x)@x
#defineeos_used__root
#defineeos_align(n)PRAGMA(data_alignment=n)
#defineeos_weak__weak
#defineeos_inlinestaticinline

#else
#error"Thecurrentcompilerisnotsupported."
#endif

一些常用的數據結構。這些數據結構，與硬件和編譯器無關，是在代碼中頻繁使用，并在多個模塊間共享的數據結構，有必要將其提升至基礎設施的層面進行支持，以避免各個模塊，對同一個數據類型，進行不同的定義帶來的數據轉換問題。

這些數據結構，與產品緊密相關，不同的產品類型之間，各自是不同的。比如下面的定義。

typedefstructeos_date
{
eos_u32_tyear:16;
eos_u32_tmonth:8;
eos_u32_tday:8;
}eos_date_t;

typedefstructeos_time
{
eos_u32_thour:8;
eos_u32_tminute:8;
eos_u32_tsecond:6;
eos_u32_tms:10;
}eos_time_t;

typedefstructeos_imu_data
{
floatacc[3];
floatgyr[3];
floatmag[3];
}eos_imu_data_t;

二、操作系統

有些芯片的資源太小，是不能運行操作系統的。這些芯片，一般而言，也沒有辦法建立嚴謹的嵌入式軟件架構，我們會在后續《小資源芯片的軟件開發平臺》中，單獨進行討論。這里只討論芯片的。

不同的芯片，所能跑的操作系統是不同的。但如果要建立軟件基礎設施，應該盡量選取同一個操作系統。

在現存的操作系統中，FreeRTOS和國產RT-Thread對各種不同的硬件架構的芯片，支持比較廣泛，可以作為RTOS的首選。

而當產品線異常豐富時，特別是使用了某些小眾芯片，或者使用芯片商提供的操作系統時，就沒有辦法建立統一的軟件基礎設施。這時，有兩個辦法解決這一問題：

• ?編寫高層模塊時，使用宏定義和條件編譯，選擇對應的RTOS API。這種一般用于所使用的操作系統較少的情況，比如說只有兩三種。

staticvoid*task_handler=NULL;

staticvoidtask_func_module_one(void*parameter);

voidmodule_one_init(void)
{
/*Newlycreatingatasktorunthemodule.*/
#if(EOS_RTOS_NAME==EOS_RTOS_NAME_FREERTOS)
xTaskCreate(task_func_module_one,
"TaskModule",2048,NULL,2,
(TaskHandle_t*)&task_handler);
#elif(EOS_RTOS_NAME==EOS_RTOS_NAME_RTTHREAD)
task_handler=rt_thread_create("led1",task_func_module_one,NULL,
2048,2,20);
#else
eos_assert(false);
#endif

eos_assert(task_handler!=NULL);
}

/*Thetaskfunctionofthemoduleone.*/
staticvoidtask_func_module_one(void*parameter)
{
(void)parameter;

/*Initialization.*/

while(1)
{
/*Addthetaskfunction.*/
}
}

• ?建立操作系統抽象層（OSAL，Operating System Abstraction Layer），以屏蔽操作系統的差異，使高層模塊依賴于OSAL。這種情況適合于資源豐富的情況。

• 著名的POSIX標準，就是為了建立OSAL的，FreeRTOS和RT-Thread都在不同程度上對POSIX標準進行了支持；在 v嵌入式領域，CMSIS_OS也是為了建立操作系統的統一接口；但無論是POSIX和CMSIS_OS，被各RTOS支持的力度是不同，因此如果我們產品中需要建立嚴謹的嵌入式軟件架構，還是要建立屬于自己的OSAL，以便屏蔽掉操作系統的不同帶來的差異。

三、中間件

中間件有很多類型，文件系統、各種協議棧、數據庫、日志模塊、Shell模塊，都屬于中間件的范疇。但在大部分情況下，這些也都屬于軟件基礎設施的范疇。

因為我們一旦選擇某個中間件，一般來說，是沒有必要更換的，正是由于這種穩定性，中間件也可以納入軟件基礎設施的范疇。以下是我經常使用的開源中間件：

• ?FatFS

• ?LwIP

• ?FlashDB

• ?uC/Modbus

• ?CAN Festival

• ?letter-shell

開源中間件，只占據了一小部分。實際產品中，中間件的大部分，都是產品或者項目私有的代碼。我日常所使用的主要有：日志模塊數據采集模塊通訊傳輸層協議通訊應用層協議文件傳輸協議OTA功能 * 時間同步

中間件，占據了軟件基礎設施的大部分內容。在產品開發中，之所以軟件復用性能夠做到越來越高，中間件的積累，是一個很重要的原因。

四、框架與機制

在不同的產品上，開發嵌入式軟件，除了RTOS之外，很多產品還需要一些框架的支持。常見的框架包括：外設與驅動框架設備框架消息框架狀態機框架行為樹框架事件驅動框架

這些框架的使用，與產品的特性相關，由產品和需求所決定。比如家庭服務機器人中，需要應用狀態機框架和行為樹框架，來應對復雜的應用層邏輯。而某些應用層邏輯比較簡單的產品，就不需要使用狀態機和行為樹。

軟件基礎設施與硬件的關系

嵌入式軟件有一個區別于其他軟件領域的重要特性，那就是直接依賴于硬件。軟件基礎設施，有很多也是需要硬件去體現和承載。比如文件系統，在規定某個源代碼比如FatFS作為其文件系統解決方案的同時，所伴隨的硬件驅動程序和硬件推薦設計，也往往被固化，以便在下一個項目中進行復用，并節約時間。

對于一些重要的且復雜的軟件基礎設施，如文件系統、網絡等，由于調試和測試都比較耗時，一般推薦固化硬件設計的方式。硬件工程師，應優先對這些重要且復雜的軟件基礎設置，分配硬件資源，而硬件的其他工程，比如IO、ADC等，再行分配。

結論

嵌入式軟件基礎設施，非常重要，根據項目與產品的不同，它所包含的內容也不盡相同。一般在項目啟動時，就會初步選定一些軟件基礎設施的內容，比如RTOS、協議棧、文件系統等等。

需要指出的是，軟件基礎設施，也不是不變的，而是隨著產品開發發展，不斷會有新的組件和元素，加入到軟件基礎設施中去，也有可能會剝離掉舊的組件，就像生物的新陳代謝。

軟件基礎設施的新陳代謝，要溫和，要相對穩定，添加和刪除，都要執行謹慎原則。