目錄
硬件抽象層（Hardware Abstract Layer）
功能模塊層（Functional Module Layer）
前言
該內容是工作一年來通過上網或其他方式不斷搜索、實踐、總結出來的嵌入式軟件開發經驗（本文僅適用於單片機的裸機開發），希望能幫到正在學習這方面的朋友，如有不好的地方，請多多見諒。
在嵌入式軟件開發過程中，在程序架構的搭建完成之後，爲了提高項目代碼的可讀性和可維護性等，應對程序代碼分層。
分層介紹
硬件抽象層（Hardware Abstract Layer）
嵌入式開發的核心就是芯片，它提供固定的片內資源（常用的有I/O，ISR，TIMER等，稍微好點的還有ADC，SPI等硬件資源，不需要芯片外圍ADC採集芯片或模擬SPI）共開發者使用。而且它具有一個很重要的特點就是，不隨項目的新增需求變動而變動。所以應將其作爲最底層，爲上層提供基礎支持。
大部分情況下該層都會有芯片廠商提供相應的庫函數包或者配置工具生成對應API函數，基本只要知道如何配置和使用就行，當然，也有可能存在芯片廠商提供的庫函數包或配置工具配置/使用自由度不高，需要自己查看芯片寄存器手冊增加自己需要的API函數。
硬件驅動層（Hardware Driver Layer）
嵌入式開發基本都會使用片外資源，如AT24C02，W25Q128等常見的外圍EEPROM芯片，需要SPI通信（硬件SPI或I/O模擬的SPI）發送相應指令驅動該芯片，實現該芯片能正常工作。因此驅動這部分的API函數實現程序即爲硬件驅動層。即使換了CPU，也只需將調用過硬件抽象層的API函數替換即可。
功能模塊層（Functional Module Layer）
硬件抽象層和驅動層主要就是爲功能模塊層提供的，實現該項目需要的功能，比如KEY、LED和EEPROM等功能，其中LEY、LED基本調用硬件抽象層的API函數（更復雜的可能通過片外芯片獲取/控制等，因此可能也需要使用硬件驅動層），EEPROM調用硬件驅動層的API函數，即使EEPROM芯片更換（AT24C02或W25Q128等），也不影響EEPROM之前編寫含的功能代碼程序（前提是AT24C02，W25Q128提供的API函數提供的是統一標準）。
應用程序層（Application Layer）
負責的就是功能模塊的使用和之間的邏輯關係處理等等，比如用戶交互界面應用程序可能需要KEY、LED、LCD等。
總結
硬件抽象層和硬件驅動層的主要區別
硬件抽象層使用的芯片內本身的資源（芯片手冊都有介紹），而硬件驅動層使用的是芯片本身不存在的資源，而且需要編寫相應代碼才能實現的資源。
比如正點原子STM32中CAN使用的TJA1050芯片，CAN屬於STM32的片內資源，TJA1050屬於片外資源，但由於TJA1050不需要額外的代碼就能通過STM32中CAN本身提供API函數正常 工作；因此可以認爲TJA1050不屬於硬件驅動層，而若使用TJA1041，則需要編寫額外代碼才能使正常工作才能使STM32中CAN本身提供API函數正常工作，因此可以將TJA1041歸爲硬件驅動層。
若不要分這麼細，可以將硬件抽象層和硬件驅動層統一歸爲硬件抽象層。
功能模塊層和硬件抽象層、硬件驅動層的主要區別
功能模塊層是按照項目需求提取出來的功能，需要硬件抽象層和硬件驅動層的硬件支持才能實現，功能模塊層根據項目的功能需求改變而改變，而硬件抽象層和硬件驅動層則是項目需求書中的功耗等硬件相關的需求變動而改變，當然，若子功能的增加而硬件不支持，則也需更換硬件驅動。
比如項目中的數據儲存功能，硬件支持有AT24C02、W25Q128和芯片本身的FLASH，都可以支持數據儲存功能，即使後期因爲功耗或節約成本等問題，硬件的更換也不影響數據儲存功能的實現（前提規劃好標準規範的API函數定義）且避免了重寫該功能代碼所帶來的各種問題，保證了該功能的穩定性。
分層結構示意圖
