1 前言

在嵌入式MCU軟體開發過程中，程式分層設計也是重中之重，關係到整個軟體開發過程中的協同開發，降低系統軟體的複雜度（複雜問題分解）和依賴關係、同時有利於標準化，便於管理各層的程式，提高各層邏輯的復用等。

2 分層介紹

2.1 硬體抽象層（HAL）  

嵌入式開發的核心就是晶元，它提供固定的片內資源（常用的有I/O，ISR，TIMER等，稍微好點的還有ADC，SPI等硬體資源，不需要晶元外圍ADC採集晶元或模擬SPI）共開發者使用。而且它具有一個很重要的特點就是，不隨項目的新增需求變動而變動。所以應將其作為最底層，為上層提供基礎支持。

大部分情況下該層都會有晶元廠商提供相應的庫函數包或者配置工具生成對應API函數，基本只要知道如何配置和使用就行，當然，也有可能存在晶元廠商提供的庫函數包或配置工具配置/使用自由度不高，需要自己查看晶元寄存器手冊增加自己需要的API函數。

2.2 硬體驅動層（HDL）     

嵌入式開發通常都會使用片外資源，用來彌補硬體抽象層實現不了的功能或者需要擴展的功能。

如AT24C02，W25Q128等常見的外圍EEPROM晶元，需要SPI通信（硬體SPI或I/O模擬的SPI）發送相應指令驅動該晶元，實現該晶元能正常工作。因此驅動這部分的API函數實現程式即為硬體驅動層。即使換了MCU，也只需將調用過硬體抽象層的API函數替換即可。

2.3 功能模塊層（FML）

硬體抽象層和驅動層主要就是為功能模塊層提供的，實現該項目需要的基本功能。而這一層又為上層提供最基本的功能，各功能模塊之前沒有太多聯繫。

比如KEY、LED和EEPROM等功能，其中LEY、LED基本調用硬體抽象層的API函數（更複雜的可能通過片外晶元獲取/控制等，因此可能也需要使用硬體驅動層），EEPROM調用硬體驅動層的API函數，即使EEPROM晶元更換（AT24C02或W25Q128等），也不影響EEPROM之前編寫含的功能代碼程式（前提是AT24C02，W25Q128提供的API函數提供的是統一標準）。

2.4 應用程式層（APL）

應用程式層主要負責的就是功能模塊的使用和之間的邏輯關係處理等等，比如用戶交互界面應用程式可能需要按鍵（KEY）、指示燈（LED）、顯示屏（LCD）等，實現一系列的人機交互功能，通常應用程式層相對於功能模塊層而言獨立性較低。

一般情況下也可細分出應用業務層，但是對於單片機產品來說，這一層的必要性反而不高，分層太多，反而顯得臃腫。

3 總結

3.1 硬體抽象層和硬體驅動層的主要區別

硬體抽象層使用的晶元內本身的資源（晶元手冊都有介紹），而硬體驅動層使用的是晶元本身不存在的資源，而且需要編寫相應代碼才能實現的資源。

比如正點原子STM32中CAN使用的TJA1050晶元，CAN屬於STM32的片內資源，TJA1050屬於片外資源，但由於TJA1050不需要額外的代碼就能通過STM32中CAN本身提供API函數正常 工作；因此可以認為TJA1050不屬於硬體驅動層，而若使用TJA1041，則需要編寫額外代碼才能使正常工作才能使STM32中CAN本身提供API函數正常工作，因此可以將TJA1041歸為硬體驅動層。

3.2 功能模塊層和硬體抽象層、硬體驅動層的主要區別

功能模塊層是按照項目需求提取出來的功能，需要硬體抽象層和硬體驅動層的硬體支持才能實現，功能模塊層根據項目的功能需求改變而改變，而硬體抽象層和硬體驅動層則是項目需求書中的功耗等硬體相關的需求變動而改變，當然，若子功能的增加而硬體不支持，則也需更換硬體驅動。

比如項目中的數據儲存功能，硬體支持有AT24C02、W25Q128和晶元本身的FLASH，都可以支持數據儲存功能，即使後期因為功耗或節約成本等問題，硬體的更換也不影響數據儲存功能的實現（前提規劃好標準規範的API函數定義）且避免了重寫該功能代碼所帶來的各種問題，保證了該功能的穩定性。

4 分層結構示意圖

本文來自博客園，作者：大橙子瘋，轉載請註明原文鏈接：https://www.cnblogs.com/const-zpc/p/16364443.html