一,硬件抽象層的理解c++
硬件抽象層(Hardware Abstraction Layer),簡稱爲HAL,是在具體的硬件平臺上抽象出來的一個硬件接口層,這個接口層負責實現具體硬件平臺的功能和控制,同時又爲其它軟件模塊提供統一的API接口。HAL其產生就是爲了將硬件操做和控制的共性抽象出來,向上層軟件提供統一操控接口,以實現其它軟件模塊與底層硬件隔離。有了HAL後,系統在新硬件平臺上的移植就變得異常簡單,只需提供新硬件的抽象層,就能夠將整個eCos系統包括基於eCos的應用移植到新的硬件平臺上。編程
下面咱們舉個簡單的例子來講明一些硬件抽象層(HAL)給嵌入式軟件設計帶來的好處,下面是arm體系結構裏實現的HAL_ENABLE_INTERRUPTS()宏定義的代碼:緩存
#define HAL_ENABLE_INTERRUPTS() \架構
asm volatile ( \函數
"mrs r3,cpsr;" \佈局
"bic r3,r3,#0xC0;" \學習
"msr cpsr,r3" \ui
: \lua
: \spa
: "r3" \
);
而以下是Powerpc體系結構下實現的HAL_ENABLE_INTERRUPTS()宏定義的代碼:
#define HAL_ENABLE_INTERRUPTS() \
CYG_MACRO_START \
cyg_uint32 tmp1, tmp2; \
asm volatile ( \
"mfmsr %0;" \
"ori %1,%1,0x8000;" \
"rlwimi %0,%1,0,16,16;" \
"mtmsr %0;" \
: "=r" (tmp1), "=r" (tmp2)); \
CYG_MACRO_END
顯然,以上宏的調用接口是統一的,但實際的實現方法卻因兩個體系結構的不一樣而差異很大,這就是爲何咱們要提出硬件抽象層(HAL)的緣由.由於它隔離了硬件相關的特性,給其它模塊提供硬件無關的統一的結構。
2、硬件抽象層的層次結構
HAL層可細分爲:common HAL(通用抽象層)、architecture HAL(體系結構抽象層)、variant HAL(變體抽象層)和platform HAL(平臺抽象層)。
體系結構抽象層:eCos所支持的不一樣處理器系列具備不一樣的體系結構,如ARM系列、PowerPC系列、MIPS系列等,體系結構抽象層對CPU的基本結構進行抽象和定義,此外它還包括中斷的交付處理、上下文切換、CPU啓動以及該類處理器結構的指令系統等。
變體抽象層指的是處理器在該處理器系列中所具備的特殊性,這些特殊性包括Cache、MMU、FPU等,eCos的變體抽象層就是對這些特殊性進行抽象和封裝。
平臺抽象層是對當前系統的硬件平臺進行抽象,包括平臺的啓動、芯片選擇和配置、定時設備、I/O寄存器訪問以及中斷寄存器等。
硬件抽象層的這三個子模塊之間沒有明顯的界線。對於不一樣的目標平臺,這種區分具備必定的模糊性。例如,MMU和Cache可能在某個平臺上屬於體系結構抽象層,而在另外一個平臺上則可能屬於變體抽象層的範圍;再好比,內存和中斷控制器多是一種片內設備而屬於變體抽象層,也多是片外設備而屬於平臺抽象層。
eCos的移植經過這三個子模塊來完成,即平臺抽象層的移植、變體抽象層的移植和體系結構抽象層的移植。對一個新的體系結構來講,其體系統結構抽象層的創建相對來講比較困難,須要編寫新的體系結構抽象層。eCos支持大部分當前普遍使用的嵌入式CPU,已具備了支持各類體系結構的硬件抽象層。所以,eCos的移植不多須要進行體系結構抽象層的編寫。
通常來講,進行eCos開發時,移植的主要工做在於變種抽象層和平臺抽象層,這是因爲eCos已實現了絕大多數流行嵌入式CPU的體系結構抽象層。其中,平臺抽象層主要完成的工做包括:內存的佈局、平臺早期初始化、中斷控制器以及簡單串口驅動程序等。
下圖是ecos HAL層的架構圖:
最上層除了common文件夾是全部體系結構公用的外,其它每個文件夾對於ecos所支持的體系結構中的一種。Common文件夾裏包含的內容就是咱們所說的通用抽象層的實現。而各個體系結構文件夾下的arch文件夾中的內容就是咱們所說的體系結構抽象層的實現。至於變種抽象層通常在命名爲/var的文件夾中。而平臺抽象層就位於具體開發板命令的文件夾下。
下面咱們用一個實際例子來分析一下一個功能在HAL各子層之間的調用關係以及代碼在各層中的分配原則,下面的復位過程調用實例採用MIPS Atlas評估板作爲目標平臺:
1,__reset()過程是爲全部體系結構定義的一個通用的reset過程,其定義在/hal/common文件夾下的hal_stub.c文件中,是屬於通用抽象層。
2,hal_atlas_reset()過程,其定義在/hal/mips/atlas文件夾下的hal_misc.c文件中,是屬於平臺抽象層部分。
3,平臺復位過程利用/hal/mips/atlas文件夾下的plf_io.h文件中的宏HAL_REG()對復位寄存器進行寫操做,這是屬於變體抽象層部分。
以上覆位調用過程能夠看出,整個復位過程的實現是如何被分開在各個子抽象層中實現的。
3、HAL在系統啓動過程當中的體現
要很好的理解HAL功能,就必須瞭解HAL在啓動過程所起的做用,下圖是系統啓動流程圖:
1. 當有開機上電事件發生後,硬件開始復位處理。
2. 硬件復位後,處理器跳轉到它的復位向量reset_vector,復位向量被定義在arch文件夾下的vector.S中,這個文件包含了同一體系結構下全部HAL包的程序入口點。復位向量完成最少的處理器寄存器的初始化。
3. 復位向量跳轉到_start,它在vector.S中實現,是HAL初始化過程的開始點。
4. 過程hal_cpu_init被調用,這個過程的定義根據不一樣的體系結構在不一樣的文件中實現,有的在variant.inc文件中,有的在arch.inc中。這個過程對處理器的某些寄存器作初始化,好比關指令和數據緩存。
5. 過程hal_hardware_init被調用,由於這個過程實現的功能與具體平臺相關,因此在平臺相關的彙編程序文件中實現,一般是platform name.S文件。這個過程實現的功能包含緩存設置,關看門狗,適時時鐘和片選設置等。
6. 接下來設置中斷的棧空間,爲保存中斷時處理器的運行現場預留存儲空間,至於要爲棧預留多大的空間,放在通用初始化部分實現。啓動過程臨時利用中斷棧空間來完成它的初始化。由於這個時候中斷使能未開,因此不會出現棧空間的衝突。
7. 過程hal_mon_init被調用,它的實現放在variant.inc或者platform.inc中。看成爲ROM monitor或者ROM應用時,主要是保證對處理器支持的各類異常條件安裝默認處理。
8. 接下來是清楚BSS段爲0,這個段包含了全部未初始化的靜態存儲變量,包括局部變量和全局變量。
9. 堆棧被設置,以便vectors.S中的彙編代碼能調用C語音代碼。
10. 過程hal_platform_init被調用,過程在hal_aux.c文件中實現。這個過程又相繼調用了hal_if_init,這個函數在hal_if.c文件中實現,這個過程初始化虛擬向量表。
11. 過程hal_MMU_init被調用來初始化MMU,實現邏輯地址向物理地址的轉換,同時實現保護和緩存機制。這個過程在hal_misc.c文件中實現,而hal_misc.c文件位於arch文件夾下。
12. 經過調用hal_enable_caches來使能指令和數據cache,這個過程在hal_misc.c文件中實現,而hal_misc.c文件位於arch文件夾下。
13. 調用hal_IRQ_init來設置CPM,這個過程在arch文件夾下的hal_intr.c文件中實現。
14. 全局的c++構造函數被cyg_hal_invoke_constructors調用,這個過程在hal_misc.c文件中實現,而hal_misc.c文件位於arch文件夾下。Linker處理全局構造函數列表的生成。Infra文件夾下的cyg_type.h中定義了相關的宏。
15. 若是這是爲了搭建一個調試環境,而ROM monitor又沒有提供調試支持,則initialize_stub過程將被調用。這個過程在HAL common文件夾下的generic_stub.c文件裏實現。這個過程安裝標準的trap處理過程,同時將硬件初始化到調試狀態。
16.調用cyg_start,將控制交給kernet。
4、硬件抽象層(HAL)的可配置組件
1.HAL中通用的可配置組件
CYGPKG_HAL_COMMON:組件包含異常處理、MMU表的安裝和診斷信息重定向等功能;
CYGPKG_HAL_COMMON_INTERRUPTS:組件包含中斷相關的全部配置功能,包括用HAL維護的棧空間、中斷嵌套是否使能和中斷棧的大小設置。
CYGPKG_HAL_COMMON_CONTEXT:此組件使能特定體系結構相關的上下文切換方式以節省上下文切換的開銷。
CYGPKG_HAL_CACHE_CONTROL:此組件運行在系統啓動過程當中使能指令和數據緩存,若是有其它的平臺相關的緩存配置要求,則此選項必須disable.
CYGPKG_HAL_DEBUG:能夠選擇是否在HAL中包含GDB調試功能。
CYGPKG_HAL_ROM_MONITOR:組件定義了應用和ROM monitor直接的交互接口。
2.HAL中體系結構相關的可配置組件,好比
PowerPC Architecture (CYGPKG_HAL_POWERPC)
PowerPC MPC8xx Variant HAL (CYGPKG_HAL_POWERPC_MPC8xx)
Motorola MBX PowerPC Evaluation Board (CYGPKG_HAL_POWERPC_MBX)
Motorola MBX PowerQUICC Support (CYGPKG_HAL_QUICC)
ARM Architecture (CYGPKG_HAL_ARM)
ARM PID Evaluation Board (CYGPKG_HAL_ARM_PID)
出處註明:本博文的部份內容來源於西安電子科技大學柳林寫的一篇論文,名稱叫:基於EP9315ARM9開發平臺下的redboot移植及串口通訊,另外也參考了《embedded software development with ecos》這邊英文書。
因爲本人也是接觸ECOS的新手,可能博文中有表述不許的地方,請你們批評指正,只求達到相互學習共同進步的目的。