簡單介紹eCos的體系結構，詳細論述eCos的可配置機制的實現原理，重點介紹eCos在以AT91M55800為核心的ARM7硬件平臺上的移植步驟，結合本系統簡要介紹內核的配置方法。最后給出了基于eCos應用軟件的編寫方法。

關鍵詞 eCos 可配置機制 ARM7 移植 硬件平臺

　　eCos(Embedded Configurable Operating System)最初是由Cygnus Solutions公司為面向嵌入式領域而開發的源碼公開、具有很強的可移植性和可配置性的，適合于深度嵌入式開發的實時操作系統。現在eCos主要由eCosCentric公司和eCos開源社區共同開發維護。eCos的特性，特別是它的可配置性，能有效縮短嵌入式產品的開發周期并降低成本。

1? eCos的體系結構及可配置性

1.1? eCos體系結構

　　eCos采用模塊化設計，將不同功能的軟件分成不同的組件，使其分別位于系統的不同層次。這種層次結構實現了eCos的可配置性、可移植性、兼容性和可擴展性。圖1是eCos系統的層次結構框圖。硬件抽象層（HAL）使其上層次結構不必關心具體的硬件結構，因此只需對HAL進行修改就可以使整個eCos的應用移植到新的硬件平臺上。

圖1? eCos的層次結構框圖

　　內核是eCos的一個核心組件，也是系統的一個可選組件，一些較為復雜的應用需要內核的支持。內核提供了多個可供選擇的調度算法，可以很好地支持多任務處理。eCos內核提供了一組豐富的同步源語，完全能滿足各種嵌入式應用的需求。內核還負責對中斷和例外進行處理，它的中斷滯后處理機制保證了系統的實時性。此外，內核還具有內存分配機制和定時機制，并提供多線程GDB調試支持。內核為上層軟件和應用軟件提供了豐富的API接口函數。

　　RedBoot是一個無內核的系統引導程序，是eCos的一個特殊應用。RedBoot可以加載eCos應用程序，并提供Debug支持，是開發eCos系統時非常有用的工具。設備驅動程序負責對硬件設備進行控制和管理，并完成設備數據的讀/寫操作。設備驅動程序自身也采用層次結構，上層驅動程序（相當于一個虛設備）可以調用下層驅動程序（物理設備）。驅動程序為上層軟件提供標準的API函數，應用程序可以使用這些API函數對設備進行訪問。

　　eCos包含的網絡支持包支持完整的TCP/IP網絡協議棧。eCos還提供了標準庫（ANSI C庫和數學庫）、兼容層（POSIX兼容和uITRON兼容）、文件系統等。作為一種開放軟件，eCos還可以很方便地容納第三方軟件。

1.2? 可配置性原理

　　eCos的一個主要特性就是其可配置特性。可配置性最終是靠代碼中的條件編譯來完成的，條件編譯是編程語言的特點，并不是eCos的原創。當一個軟件工程中的條件編譯項的數目和復雜性達到一定程度時，其中有一些條件編譯項就會因為存在邏輯上的依賴關系而使條件編譯產生沖突。而如何發現并有效解決這種沖突才是eCos可配置性的特點，如圖2所示，其可配置特性的實現主要由組件定義語言CDL(Component Definition Language)、組件倉庫ecos.db、圖形配置工具configtool三者共同完成。

圖2? 可配置機制

（1）??組件定義語言CDL
　　CDL是eCos組件框架中的一個關鍵部分，eCos所有模塊的程序包中都包含一個CDL腳本對該包進行描述并提供配置選項。以本系統中的串口驅動程序包為例，在該包對應的CDL中定義了一個名為CYGPKG_IO_SERIAL_ARM_AT91的cdl_package。在這個cdl_package中詳細列出了該包的一些屬性，如該包必須在工程已經包含了硬件抽象層包CYGPKG_HAL_ARM_AT91和上層串口I/O包CYGPKG_IO_SERIAL的情況下才會被使能。另外，串口的一些常用特性，如波特率、設備名、緩沖區大小等配置選項也是必不可少的。在一些復雜的CDL中還會包含對該包中的源程序進行編譯時的一些編譯選項。在進行配置的時候，該包還會產生一個包含了各個可配置參數數值的頭文件。當其他包使用由CYGPKG_IO_SERIAL_ARM_AT91包提供的可配置參數時，這個新產生的頭文件就會被相關的源文件通過#include語法包含。

（2）? 組件倉庫ecos.db
　　ecos.db是一個包含了所有可用程序包和配置模版的文本文件。在該文件中，需要注冊所有的CDL包。在注冊時以package關鍵字提供相應包的名稱、CDL腳本文件的文件路徑以及對該包的一個簡單描述。在ecos.db中還會以target關鍵字生成配置模版，從而提供目標平臺的一些基本組成結構，使目標平臺包括所需要的已經注冊了的CDL配置包。

（3） 圖形配置工具configtool
　　configtool是利用MFC編寫的Windows程序，是eCos可配置性的執行者，也可以理解成是CDL腳本的解釋器。一方面它讀取ecos.db文件中的目標平臺和已注冊的配置包信息，根據配置包的路徑找到相應的CDL腳本，然后根據腳本中給出的屬性向程序員提供圖形化的配置信息；另一方面，它還可以接受用戶的輸入，包括單選按鈕、復選框、下拉列表、文本輸入等。當用戶保存一個配置時，configtool會根據CDL語言的提示生成相應的頭文件，也會將指定的頭文件從配置包中復制到配置文件所在的工作目錄。無論是生成的頭文件還是拷貝的頭文件，都會在編譯時被源程序所引用。對于內核源程序，configtool又可以理解成編譯器。當用戶的配置選項被保存并且對工程進行編譯時，configtool會在后臺調用真正的編譯器GCC，根據配置包CDL中的編譯選項控制GCC對所有需要的內核源文件進行編譯并生成庫文件和對應的鏈接腳本。當然configtool只是對eCos內核進行編譯，用戶的應用程序只需在編譯時和由configtool編譯生成的庫文件進行鏈接就可以得到最終的可執行映像文件。

2? 系統硬件框架

　　本系統是一個以ARM7為核心構成的測控系統，通過對傳感器的脈沖信號進行處理而得到待測物料的流量，并通過控制給料器的給料速度達到流量控制的目的。對于一個有實用價值的測控系統，必須具有人機交互、閉環控制、數據通信和存儲等功能。本課題所研制的流量測控系統的硬件框圖如圖3所示。

圖3? 流量測控系統硬件框圖

　　圖3中，處理器為ARM7內核的工業級芯片AT91M55800，其強大的功能保證了系統的實時性和穩定性的要求。2 MB的Flash SST39VF160用來保存程序代碼、測量所需的一些參數以及測量結果的簡單統計信息。在工業生產中,經常需要對一次測量中的數據進行歷史再現，以便對一些事故或故障進行排查。本系統通過采用1 MB的大容量RAM來實現這一功能：除了用來作為程序運行時的內存外，RAM還用來實時保存每一時刻的測量數據。USB總線的通信口用來和現場計算機進行通信，以實現一些更加完善的處理，如數據打印、結果分析、實時數據的硬盤保存等。分辨率為320×240的LCD用來作為系統的顯示終端配合4×5的鍵盤來完成系統的人機交互操作。對變頻器的控制和對溫度信號的采集通過485總線完成。6路脈沖信號是本系統測量功能的核心，通過對這6路脈沖進行處理可以得到流量相關的所有信息。4~20 mA電流信號用來控制給料系統，以實現閉環控制。由于在工業環境中使用，對于一些長線連接必須采取隔離措施。本系統對測量脈沖、485通信信號和4~20 mA電流信號都采取了光電隔離措施。

3? eCos在系統上的移植與應用軟件編寫

3.1? eCos內核的移植

　　由于eCos內核采用了可配置的模塊化設計思想，因此只要修改硬件抽象層HAL的代碼和CDL腳本并且在ecos.db中注冊就可以應用于新的目標系統。HAL又可以細分為3個層次： ①? 體系結構抽象層。eCos是可以應用于多種體系結構平臺上的操作系統，如ARM、MIPS、POWERPC等，在eCos發布時已經將這些體系結構層的移植包一同發布了出來。本系統的體系結構抽象層是ARM7體系結構抽象層。②? 變體抽象層。對于同一種體系結構的處理器，各生產廠家會有不同的系列和型號（如Atmel的AT91系列、Philips的LPC系列等)，雖然它們都采用ARM7體系結構,但是不同的寄存器配置模式和中斷處理方法也會影響到eCos的移植。本系統所使用的處理器AT91M55800使用較為普遍，在eCos開源社區已經有移植好的AT91M55800變體抽象層的代碼和CDL腳本，只需作系統啟動后對I/O口的賦值情況等少許的改動即可完成對變體抽象層的移植。③? 平臺抽象層。平臺抽象層是對目標系統的整個硬件平臺進行抽象，包括平臺的啟動、芯片配置、定時、I/O寄存器及中斷寄存等等。

　　系統需要進行的移植工作主要是平臺抽象層的移植，而平臺抽象層中最重要的是Flash驅動包和內存布局文件的移植。主要的步驟為：

①? 安裝AT91M55800變體抽象層包。從eCos開源社區下載好的變體抽象層包在一個名為eb55的文件夾中，在這個文件夾中還有cdl、include、src等子文件夾分別包含了CDL腳本、頭文件，源文件。由于eCos的軟件包有嚴格的層次結構，所以在安裝軟件包時應遵循這一結構以便于維護。AT91M55800屬于ARM7的一個變體，同AT91系列的其他CPU處于同一層次，所以變體抽象層軟件包文件夾eb55的具體路徑應為/hal/arm/at91/eb55。接下來還應在ecos.db中注冊變體抽象層包，以package關鍵字注冊名為CYGPKG_HAL_ARM_AT91_EB55的包，這個名字必須和包中CDL文件hal_arm_at91_eb55.cdl中的所定義的包名完全一致。在包名后面的花括號中登記hal_arm_at91_eb55.cdl文件的路徑及文件名，以及對該包的簡單文字說明。

②? 編寫Flash的底層驅動軟件包，以便能夠操作目標系統的Flash存儲器。由于本系統在前期調試和代碼固化時利用了RedBoot，而RedBoot通過Flash驅動程序操作目標Flash，所以必須先移植好Flash驅動程序才能進行更進一步的開發工作。

　　首先需要編寫底層驅動程序源文件。不同的Flash的塊空間大小以及寫操作一般是不一樣的。本系統所用的Flash SST39VF160是2 MB的16位NOR Flash，共有512(0x200)個塊空間，其塊大小為4K(0x1000)，寫操作的命令碼符合JEDEC標準。這些特點與Atmel公司AT49系列Flash比較類似，因此Flash驅動程序可以從eCos發布時自帶的AT49系列Flash的驅動程序修改得到。最重要的地方是修改描述Flash特性的結構體flash_dev_info_t變量中成員block_size和block_count的值，使其分別為0x1000和0x200。

　　接下來需要編寫與Flash底層驅動對應CDL腳本，使配置工具configtool能夠正確配置編譯Flash驅動程序。這個CDL文件完全可以參照AT49驅動包中的CDL文件編寫。以cdl_package關鍵字定義名為CYGPKG_DEVS_Flash_SST_39VF160的包，在命令體中給出具體的配置參數。由于底層驅動包必須結合上層驅動才能工作，所以在命令體中用active_if CYGPKG_IO_Flash命令告訴configtool,必須在上層驅動包CYGPKG_IO_Flash已經被包含的情況下底層驅動包才會使能。

　　最后，需要在ecos.db中注冊底層驅動軟件包。具體做法和變體抽象層包的注冊方法相同。

③? 修改內存布局文件，使configtool能夠正確定位程序在系統存儲器中的位置。eCos提供3種不同的運行方式,即ROM方式、RAM方式、ROMRAM方式。每種模式都有兩個相應的布局文件，如RAM方式的mlt_arm_at91_eb55_ram.ldi和mlt_arm_at91_eb55_ram.h。*.ldi和常見的ARM開發環境ADS中scattered鏈接方式下的*.scf文件的作用類似，即用來對不同段分別指定不同的鏈接地址。在*.ldi中需要修改MEMORY和SECTIONS兩部分。對于代碼在RAM中運行的內核及應用程序，需要根據系統RAM的實際情況修改內存布局文件中相關參數的值。本系統具有1? MB的RAM，但有一半用來存放測量數據，根據系統實際的硬件情況，其起始地址為0x02000000，大小為0x80000，所以這個內存塊定義為ram: ORIGIN=0x02000000, LENGTH=0x80000。處理器內部集成了8 KB SRAM，其起始地址為0，大小為0x2000，所以這個內存塊定義為sram: ORIGIN=0x00000000,LENGTH=0x2000。這樣系統的MEMORY部分就由名為ram和sram的兩個內存塊構成。系統比較重要的兩處SECTIONS部分的修改為SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA) 和SECTION_rom_vectors (ram, 0x02008000, LMA_EQ_VMA)，第一處表示fixed_vectors段分配在從0x20開始的sram中，且LMA_EQ_VMA指定其加載地址等于虛擬地址。由于RedBoot運行時需要占用從0x02000000開始的一定空間的RAM，所以第二處使程序代碼從0x02008000開始的ram中運行。*.ldi文件修改完畢后需要相應地修改*.h文件中的宏，如#define CYGMEM_REGION_ram? (0x02000000)。

④? 在組件倉庫ecos.db中為以關鍵字target添加名為Flow55的新目標平臺。在這個目標平臺中還必須用關鍵字packages包括ARM7體系結構層包和AT91M55800變體抽象層包，同時為了實現調試還必須包括串口驅動包和Flash驅動包及其上層驅動包。除了這些被包含的軟件包外，根據不同的選擇configtool還會為目標平臺包添加一些默認的包，如內核包、數學庫包等。另外，還應加入一些對該平臺的簡單描述。

3.2? 內核的配置

　　移植完成以后，一個最基本的目標平臺就產生了。在configtool中可以看到Templates菜單的硬件平臺列表中新增了Flow55目標平臺模版，以default方式打開這個模版。各個軟件包的CDL腳本中都給出了默認的配置值，有些值需要根據具體的應用要求重新配置。本系統一些重要的配置情況如下：

①? 由于系統線程數量較少（小于10），所以選擇效率更高的位圖調度器Bitmap scheduler，并將線程數numbers of priority levels限定為16，以提高任務切換的速度。當點擊位圖調度器的單選按鈕時，configtool會檢測到一個配置沖突。由于時間片輪轉是默認使能的，而時間片輪轉僅僅對應于多級隊列調度器，所以出現配置沖突。Configtool會給出一個推薦的解決沖突的方法,即禁止時間片輪轉，按照這個推薦的解決方法可以安全地解決這個沖突。這個地方可以充分體現出eCos強大的可配置性。

②? 由于配合RedBoot一起使用，所以內核配置為RAM啟動方式。這樣，系統上電后程序將由RedBoot復制到RAM中運行，以提高速度。

③? 系統的晶振頻率為16 MHz，經PLL倍頻后為32 MHz，所以需將Clock speed配置為32000000；RTC是系統的時鐘節拍發生器，本系統的時鐘節拍時間選為20 ms，所以也需要對RTC相關項進行配置。具體參數為Real?time clock numerator配置為2000000000，Real?time clock denominator配置為100，Real?time clock period配置為20000。

　　其余的配置選項使用默認的配置值即可。完成配置工作后，對內核進行編譯可以產生內核庫文件和鏈接腳本以及相關頭文件。這些生成的文件再同應用程序一起編譯、鏈接，生成最終的可執行映像文件。

圖4? 應用軟件結構

3.3? 基于eCos操作系統的應用軟件的編寫

　　eCos是一個單進程多線程的操作系統，多個線程在宏觀上可以認為是并發運行的，而且各線程之間耦合低，便于軟件的編寫和維護。針對這一特點，本系統的軟件結構如圖4所示。

　　本系統主要有兩種程序運行方式，分別稱為方式A和方式B。方式A中，硬件中斷產生后，相應的ISR(Interrupt Service Routine)程序運行，由于ISR中是禁止中斷的，所以在ISR中只進行最簡單的操作，ISR退出后內核調用相應的DSR(Deferred Service Routine)。DSR中中斷是使能的，所以可以進行一些稍復雜的處理，如簡單的數據運算、內核調用（發送信號量和郵箱等）。在得到相應的信號量或消息郵箱后，相應的線程進入就緒態被內核調度運行。本系統中對鍵盤的處理就是基于這種方式——按鍵產生硬件中斷、ISR執行，接著在DSR中進行相應的運算得到具體的鍵值后以消息郵箱的方式通知并喚醒鍵盤處理線程，鍵盤處理線程在完成任務后進入休眠直到再次有按鍵發生而被喚醒。方式B中，各線程只是周期性地被內核調度運行，如測量數據顯示線程，在顯示一次數據后調用延時函數進入休眠，直到延時完畢后再次進入就緒態被內核調用。

　　根據測控系統的實際情況，具體的線程編寫如下： 方式A為流量計算線程、溫度測量線程、鍵盤處理線程、USB通信處理線程。方式B為測量數據顯示和曲線繪制線程、流量控制線程、初始標定線程。

4? 結論

　　經過實踐，本系統運行穩定，實時性能良好。由于eCos的強大可配置性使得系統的軟硬件可維護性強，在進行硬件改動或應用要求改動后可方便地進行升級。