1 前言

在嵌入式MCU軟件開發(fā)過程中，程序分層設計也是重中之重，關系到整個軟件開發(fā)過程中的協(xié)同開發(fā)，降低系統(tǒng)軟件的復雜度（復雜問題分解）和依賴關系、同時有利于標準化，便于管理各層的程序，提高各層邏輯的復用等。

2 分層介紹

2.1 硬件抽象層（HAL）

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

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

2.2 硬件驅動層（HDL）

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

如AT24C02，W25Q128等常見的外圍EEPROM芯片，需要SPI通信（硬件SPI或I/O模擬的SPI）發(fā)送相應指令驅動該芯片，實現(xiàn)該芯片能正常工作。因此驅動這部分的API函數(shù)實現(xiàn)程序即為硬件驅動層。即使換了MCU，也只需將調用過硬件抽象層的API函數(shù)替換即可。

2.3 功能模塊層（FML）

硬件抽象層和驅動層主要就是為功能模塊層提供的，是實現(xiàn)該項目需要的基本功能。而這一層又為上層提供最基本的功能，各功能模塊之前沒有太多聯(lián)系。

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

2.4 應用程序層（APL）

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

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

3 總結

3.1 硬件抽象層和硬件驅動層的主要區(qū)別

硬件抽象層使用的芯片內本身的資源（芯片手冊都有介紹），而硬件驅動層使用的是芯片本身不存在的資源，而且需要編寫相應代碼才能實現(xiàn)的資源。

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

3.2 功能模塊層和硬件抽象層、硬件驅動層的主要區(qū)別

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

比如項目中的數(shù)據(jù)儲存功能，硬件支持有AT24C02、W25Q128和芯片本身的FLASH，都可以支持數(shù)據(jù)儲存功能，即使后期因為功耗或節(jié)約成本等問題，硬件的更換也不影響數(shù)據(jù)儲存功能的實現(xiàn)（前提規(guī)劃好標準規(guī)范的API函數(shù)定義）且避免了重寫該功能代碼所帶來的各種問題，保證了該功能的穩(wěn)定性。

4 分層結構示意圖

如果本文對你有幫助，別忘記給我個3連問 ，點贊，轉發(fā)，評論，，咱們下期見。

收藏 等于白嫖，點贊才是真情。

作者：大橙子瘋

原文鏈接：https://www.cnblogs.com/const-zpc/p/16364443.html