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 分層結構示意圖
