圖1

　　平臺抽象層是對當前系統的硬件平臺進行抽象，包括平臺的啟動、芯片選擇和配置、定時設備、I/O寄存器訪問以及中斷寄存器等。
　　硬件抽象層的這三個子模塊之間沒有明顯的界線。對于不同的目標平臺，這種區分具有一定的模糊性。例如，MMU和Cache可能在某個平臺上屬于體系結構抽象層，而在另一個平臺上則可能屬于變體抽象層的范圍；再比如，內存和中斷控制器可能是一種片內設備而屬于變體抽象層，也可能是片外設備而屬于平臺抽象層。
　　eCos的移植通過這三個子模塊來完成，即平臺抽象層的移植、變體抽象層的移植和體系結構抽象層的移植。對一個新的體系結構來說，其系統結構抽象層的建立相對來說比較困難。eCos支持大部分當前廣泛使用的嵌入式CPU，已具有了支持各種體系結構的硬件抽象層。因此，eCos的移植很少需要進行體系結構抽象層的編寫。
4 平臺抽象層的移植
　　一般來說，進行eCos開發時，移植的主要工作在于平臺抽象層，這是由于eCos已實現了絕大多數流行嵌入式CPU的體系結構抽象層和變體抽象層。平臺抽象層主要完成的工作包括：內存的布局、平臺早期初始化、中斷控制器以及簡單串口驅動程序等。
　　構建一個新的平臺系統，最簡單的方法是利用eCos源碼提供的具有相同體系結構和CPU型號的參考平臺硬件抽象層，將其作為模板，復制并修改所有與新平臺相關的文件。若eCos沒有這樣的平臺，則可用另一種體系結構或CPU型號的類似硬件抽象層作為模板。比如，eCos提供了以三星公司ARM CPU S3C4510b為核心的平臺SNDS4110，當需要移植eCos到ARM CPU S3C44B0上時，這將是一個很好的起點。
　　 移植工作最好是從RedBoot開始，實現的第一個目標是使RedBoot運行在新平臺上。RedBoot是eCos自帶的啟動代碼，它比eCos要簡單，沒有使用中斷和線程機制，但包含了大部分最基本的功能。
　　 建立目標平臺的RedBoot通常按以下步驟進行（以構建S3C44b0的新平臺為例）。
　　 ① 復制eCos源碼中選定的參考平臺，根據需要對目錄及文件更名。更名的主要內容有：新平臺的目錄名、組件定義文件（CDL）、內存布局文件（MLT）、平臺初始化的源文件和頭文件
　　 ② 調整組件定義文件（CDL）選項。包括選項的名字、實時時鐘/計數器、CYGHWR_MEMORY_LAYOUT 變量、串口參數以及其他的一些選項。
　　 ③ 在頂層ecos.db文件中加入所需要的包，并增加對目標平臺的描述。在最初，該目標平臺的入口可以只包含硬件抽象層包，其他硬件支持包以后再加入。經過修改后，就可在eCos配置程序中選擇新的平臺進行配置。
　　 ④ 修改include/pkgconf中的內存布局（MLT）文件。按照新的硬件平臺內存布局修改MLT文件。MLT文件對應每種啟動類型有三個不同后綴的文件：.h文件以及.ldi文件和mlt文件。手工修改時只需修改.h文件和.ldi文件，并保證兩個文件同步修改。修改的主要內容有ROM的起始地址、ROM的大小、RAM的起始地址和RAM的大小。
　　 ⑤ 修改平臺的io宏定義。在include/plt_io.h文件中完成對平臺的各種IO宏定義，包括各種CPU的系統配置寄存器、內存配置寄存器、串口配置寄存器、LCD配置寄存器、以太網配置寄存器等的I/O地址。
　　 ⑥ 修改平臺的Cache代碼。在include/hal_cache.h文件中修改有關Cache的宏定義。在開發初期，最好先將Cache關閉，等移植穩定后再打開。
　　 ⑦ 實現簡單的串口驅動程序。串口的初始化、接收和發送在src/hal_diag.c文件完成。主要的函數如下：
　　cyg_hal_plf_serial_init_channel()，完成對某個串口的具體初始化工作；
　　cyg_hal_plf_serial_putc()，從串口發送一個字符；
　　cyg_hal_plf_serial_getc()，從串口接收一個字符；
　　cyg_hal_plf_serial_getc_nonblock()，以無阻塞的方式接收一個字符，即緩沖區中無數據時立即返回；
　　cyg_hal_plf_serial_isr()，串口中斷服務程序；
　　cyg_hal_plf_serial_init()，調用cyg_hal_plf_serial_init_channel()函數初始化各串口，并向內核注冊串口中斷服務程序、串口的讀寫例程和配置例程。
　　 ⑧ 修改或增加平臺初始化程序。平臺初始化在3個文件文件中完成：src/s3c44b0_misc.c、include/hal_platform_setup.h和include/hal_platform_ints.h。
　　hal_platform_ints.h完成系統的中斷宏定義。在不同的平臺中設備數量和類型不同，中斷的譯碼方式也不一致，需要根據具體情況作出調整。
　　hal_platform_setup.h主要完成系統硬件的初步配置，這里一般要在看門狗和中斷關閉后，配置系統時鐘頻率、ROM和RAM的初始化參數。
　　s3c44b0_misc.c文件完成目標板的進一步初始化、中斷處理、延時例程和操作系統時鐘設置。
　　經過以上修改，底層的平臺抽象層就基本完成了，這時可用eCos的配置工具生成RedBoot進行測試。
　　RedBoot測試成功后，說明平臺已經能正確完成初始化操作，且串口驅動也能正常工作，接著要完成中斷和Cache等測試工作?？衫靡恍┒嗑€程的小程序測試，檢測時鐘配置是否正確，同時也檢測了中斷能否正常工作。
5 驅動程序設計
　　平臺抽象層完成后，接著要完成系統的設備驅動程序。eCos設備驅動程序的中斷模塊分為三個層次：中斷服務程序ISR、中斷滯后服務程序DSR和中斷線程。ISR在響應中斷時立即調用，DSR由ISR發出調用請求后調用，而中斷線程為驅動程序的客戶程序。
　　硬件中斷在最短的時間內交付給ISR處理。硬件抽象層對硬件中斷源進行譯碼并調用對應的中斷ISR。ISR可以對硬件進行簡單的操作，應使ISR的處理時間盡量短。當ISR返回時，它可將自己的中斷滯后服務程序DSR放入操作系統的任務調度中，DSR可以在不妨礙調度器正常工作時安全運行。大多數情況下，DSR將在ISR執行完成后立即運行。
　　eCos設備驅動程序一般可分為三個部分，如圖2所示。

圖2

　　eCos的所用設備驅動程序都使用設備表入口來描述。使用宏DEVTAB_ENTRY()可生成設備表入口。其格式為：
　　DEVTAB_ENTRY(l, name, dep_name, handlers, init, lookup, priv)。
　　l：設備表入口的“C”標識符。
　　name：該設備的“C”字符串名字，在搜索設備時用到。
　　dep_name：對于一個層次設備，此參數是該設備下層設備的“C”字符串名字。
　　handlers：I/O函數句柄指針，由宏DEVIO_TABLE實現的。
　　init：當eCos處于初始化階段時被調用的函數，該函數可以進行查找設備，對硬件進行設置等操作。
　　lookup：當調用cyg_io_lookup()函數對該設備進行操作時調用的函數。
　　priv：該設備驅動程序所需的專用數據。
　　設備入口中的句柄handlers包含了一組設備驅動程序接口函數，是設備函數表DEVIO_TAB的指針，DEVIO_TAB包含了一組函數的指針。設備I/O函數表通過DEVIO_TAB宏來定義，格式如下：
　　DEVIO_TABLE(l, write, read, get_config, set_config)。
　　l：改表的“C”標識符，即在DEVTAB_ENTRY中的handlers。
　　write：實現向設備傳送數據。
　　read：實現從設備讀取數據。
　　get_config：實現讀取設備配置信息。
　　set_config：實現對設備的配置操作。
　　在eCos的初始化引導過程中，對系統中的所有設備調用其相應的init()函數（即DEVTAB_ENTRY宏注冊的初始化函數），所有對設備的I/O操作通過handlers完成。
　　設備驅動程序包含如下內容(xxx：表示某種設備)。