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
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/498975.html
標籤:架構設計
下一篇:設計原則之DRY原則
