關鍵詞：VxWorks 嵌入式系統 實時性 數據通信
引言
隨著信息技術的不斷發展和更新，嵌入式操作系統以其速率高、穩定、可配置內核的優勢正得到越來越廣泛的應用，包括醫學、圖像處理、軍事、工業控制、電信等許多領域。嵌入式系統必須采用特殊有效的實時操作系統，VxWorks正是一個具有高性能的實時操作系統，成為嵌入式系統操作內核的最佳選擇之一。隨著嵌入式系統在網絡當中的應用不斷加強，具有多種數據通道的復合通信模式顯得列為必要。本文根據基于VxWorks的嵌入式系統對于數據通信的不同要求，提出一個嵌入式系統復合通信模型，研究幾種具有代表性的數據通信方式，并論述在VxWorks下的實現方法及其一些關鍵技術。
1 嵌入式系統復合通信模型的設計
嵌入式系統在控制領域應用十分廣泛，例如在工業控制當中常常利用嵌入式系統作為中央控制機，完成信息采集、分系統監管、系統決策等等重要功能。硬件往往離不開軟件的支持。VxWorks操作系統是目前功能最全的、獨立于處理器的嵌入式實時操作系統之一？紤]如何基于VxWorks實現嵌入式系統的復合通信方式是有意義的。由于此時嵌放式系統已經不再是孤立系統，而是處于某種拓撲網絡結構當中，因此，有必采取復合通信模式以適應系統擴展、集中控制和遠程信息傳輸的需要？刂茩C應當具備優良的系統總線、可靠的控制網絡、高速傳輸通道接口以及遠程數據管道。綜合以上考慮，圖1給出了一個控制機的復合通信模型。
控制機本身采用VME總線標準，可以嵌入多塊單板機，具有良好的系統擴展性。為了適應不同的通信要求，外圍有三種通信接口。其中光纖通信傳輸速率很高，適合作為大流量數據通道，例如信號處理機數據傳輸管道。串口通信設備簡單、成本較低，傳輸速率適中且安全性高，可以作為遠程數據通道。以太網則由于其極佳的增容性、穩定性，適合于局域網絡控制體系。
2 復合通信模式特點分析
為了對以上復合通信模型加以說明，下面對片幾種通信模式的特點進行分析。
（1）總線標準
目前常用的總線標準有多種，基中VME總線支持多處理器系統，最多可以容納21塊插件。地址總線32位，數據總線32位，數據傳輸速率可以達到80Mb/s。VME總線能處理7級中斷，具備高速的實時響應能力。VME總線采用主-從結構，主功能模塊傳輸數據之間必須先使用中央仲裁器，也稱為系統控制器，具有總線仲裁功能。VME數據傳輸總線是高速異步并行的，模塊間數據傳輸是通過連鎖的握手信號實現的。具有高可靠性，同時其模板結構具有良好的抗震性，適應較為惡劣的工作環境[1]。
（2）控制網絡
控制網絡一般采用局域網。由于TCP/IP協議是一個標準的企業網絡協議，是比較完善的、公認的最有效的互聯協議，因此目前流行的操作系統都支持TCP/IP協議，TCP/IP協議還是個穩定的、對稱的、支持交叉平臺的Client/Server方式的結構，并為應用程序提供了標準接口，對于集中控制的嵌入式系統采用基于TCP/IP的網絡通信無疑是方便而且有效的。
（3）高速數據接口
目前來看，光纖通道作為高速數據通信是最為有利的。它是一種利用光纖（苦口婆心銅纜）作為物理鏈路的高性能串行數據接口，支持SCSI、IP等上層數據傳輸協議，具有可靠性高、速度快和傳輸距離的特點，可用來連接大型機、服務器和存儲設備以實現高速大容量的信息傳輸。對于分離的嵌入式硬件系統而言，采用光纖通道作為高速I/O數據接口無疑是一種很好的選擇。
（4）遠程數據通道
由于控制機的遠程數據傳輸需要較高的安全性，同時一般只需單路傳輸，如果使用光纖電纜顯示成本高而且不需要那么高傳輸的帶寬，因此可以考慮使用串行口通信。串行口在嵌入式系統當中是一類重要的數據通信接口。由于RS-422標準串行口通信采用了雙線傳輸，大大增加了抗共模干擾的能力，最大數據傳輸速度可以達到10Mb/s，這對于遠程數據交換具有極大的優勢，因此可用于遠程信息交換。
3 復合通信方式的實現與關鍵技術
由于本文的討論與單板機生產商所提供的板級支持包有關，而不同類型的單板機所提供的板級支持包（BSP、ESP）也會略有不同，為了不失一般性同時具有一定先進性，本文采用英國Radstone公司生產的PPCx系列單板機作示例。PPCx系列單板機功能集成度高、擴展性強、性能穩定，可以添加多種外圍存儲設備、支持高分辨顯示，是一種理想的單板機系統。
3.1 基于VME總線的DMA通信方式
在VME總線上，每個單板機如果要訪問其它單板機的RAM，必須通信VME總線地址映射。因此，每塊板上有兩個地址譯碼器，一個用于VME總線地址→本地地址譯碼，而另一個用于本地地址→VME總線地址譯碼，這樣就會存在多個不同的存儲器地址映射。如果想要訪問某個單板機的RAM，需要知道該單板機的RAM本地址所映射成的VME總線地址，然后通過訪問VME總線地址映射到自身的本地地址而訪問到系統控制器，甚至可以將其看成自身的RAM地址。多處理器地址映射關系如圖2所示。
綜上所述，對于某一VME總線中的任務一塊板而言，只要獲得了它的本地地址到VME總線地址的映射關系，就可以從板外來訪問該板的RAM。VxWorks標準函數庫sysLib當中提供了函數sysLocaltoBusAddr()，可以直接獲得本地地址的VME總線地址。這樣，當前主機只需調用該函數獲得自身RAM地址到VME地址映射，其它的主機就可以根據該映射得到的VME總線地址訪問該主機。因此，當需要對于外板的某些控制寄存器進行位元操作的進修，這種方法就顯得尤其重要：因為往往沒有函數能夠僅僅對于外板RAM的某個字節進行操作，更無法定位到位操作。
為了進一步提高數據傳輸速率，可使用PPC4A上的VME控制芯片Tundra中集成的DMA控制器。它支持基于VME總線的DMA數據傳輸方式，而DMA是外存數據傳輸最有效的一種方式。具體步驟如下：
①安裝DMA驅動程序，調用函數dmaDrv（）；
②建立DMA設備，調用函數dmaDevCreate()；
③打開DMA進行讀寫，調用函數open()、write（）、read()。
DMA設備句柄就是一個類似于文件指針的數據類型，所以可以像一個標準數據操作來對待。開啟設備后即可調用文件讀寫標準函數進行讀寫操作。通過較為嚴格的測試，DMA數據傳輸速率可以達到40Mb/s以上，并且不發生數據傳輸錯誤。
為了保證主機對于其它主機DMA傳輸數據的實時響應，應當產生VME總線中斷信號通知該主機。當某個主機發送數據完畢后，須調用VxWorks提供的函數sysBusIntGen （）t向VME總線產生一個級別為intLevel、中斷號為intNum的中斷信號。
接收端主機事先建立一個與該級別中斷信號對應的客戶中斷服務程序，并將該客戶中斷服務程序鏈接到所要求級別的中斷號上，從而實現對其進行實時響應。當主機接收到屬于自己的中斷信號后，會立刻自動調用該中斷服務程序。這時可利用中斷服務程序釋放一個信號燈，通過該信號燈驅動相應的數據處理模塊，從而實現實時操作。如下面的全程：
/*客戶中斷服務程序*/
void intHdlr(SEM_ID semId)
void intHdlr(SEM_ID semId)
{
/*釋放信號燈*/
semGive(semId);
}
/*等待信號燈的處理模塊*/
void processsModle(void)
{
/*等待信號燈*/
semTake(semld)；
/*處理模塊代碼*/
…
}
VME總線共有7個中斷級別，排除系統使用的中斷號，客戶自定義中斷號可從18設置到32。這樣能夠為足夠多的主機設置中斷服務程序，從而實現VxWorks操作系統下的多主機VME總線實時高速通信。
3.2 串行口通信
在VxWorks中，將I/O系統設計成為任何類型的設備提供一個簡單、統一、獨立于設備的接口，所以串行口通信軟件的設計和VME通信具有相似之處。在VxWorks中，任何對于串行口的操作仍然可以視為對一個文件的操作，而不必了解關于設備或程序驅動實現的細節。在串行口通信軟件的設計不中，利用RRCx的增強軟件包ESP可對驅動成功后的串行口設備進行操作。系統首先調用ESP軟件提供的esccDrv()安裝串行驅動程序，隨后調用esccDevCreate（）將指定的串口設備添加到系統中，當串口初始化完成后，與DMA操作方式類似，在使用之前利用open()打開相應串口，依據串口打開時的讀寫標志，調用函數write()、read()對串口進行只讀操作、只寫操作或同時進行讀寫操作。
對于串口通信，仍然要關心數據接收的實時性。可采用中斷方式，利用VxWorks提供的select函數的事件觸發機制，將讀串口的任務阻塞使其一直等待數據，當有數據來到的時候該任務會立刻自動響應，提高系統的實時性。
3.3 基于TCP/IP協議的網絡通信
網絡通信一般可通過套接口（socket）實現。VxWorks提供了標準的BSD socket調用，具有兩種類型：Stream socket（全雙工流類型）、Datagram sockets（數據攝類型）。前者支持TCP協議，后者支持UDP協議。任何一個任務都可以打開一或多個socket，其它任務的socket可與之連接？蛻舳顺绦蚴紫日{用socket()個函數產生用于與各分系統連接的套接口，并為每個套接口返回一個ID號，然后初始化一個套接口結構體，為其賦上該ID號以及服務端的IP地址和端口號，并將具作為函數connect（）的參數，調用connect()函數主動去連接客戶端。服務端則需調用bind（）函數將自身IP和端口號綁定，以保證客戶端正確識別。為了確保服務器能夠實時接收客戶端的數據，當服務端與客戶端建立連接之后，必須嵌入循環，利用read()語句不斷等待客戶數據。同時客戶端每次發送數據之后也應等待服務端回復，建立握手機制。一個完整的socket網絡應該可以用圖3來描述。值得指出的是，read調用具有一個PEEK選項，即向接收緩沖區探測是否有數據而并不真正取出數據，根據它的返回值可以判斷出網絡的狀態。這個功能適用于網絡查錯。
3.4 光纖通道
由于光纖通道（fibre channel）接口并非VxWorks自身具備的組件，因此，VxWorks內核上實現光纖通信也需要加載相關的驅動程序；同時，主機也需安裝光纖通信適配器，然后通過光纖電纜連接。下面仍以PPCx系列單板機為例來說明。
這里采用QLA2200作為光纖通道適栩器。QLA2200/66是Qlogic公司生產的、目前應用最為廣泛的光纖通道適配器。它主要包括四個功能模塊：高速RISC處理器，包括千兆位收發模塊、通道控制、幀緩存等的FC接口，有三個通道PCI總線DMA控制器以及ISP2200A的外存儲器。RRCx的ESP為該適配器QLA2200提供了驅動程序，支持基于交換機、仲裁環以及點對點等三種拓撲結構的SCSI、IP和低開銷訪問（LLA）協議，其固件協議層結構如圖4所示。
當VxWorks啟動之后，需要調用QLA2200的初始化函數ql22Init()，該函數的功能是驅動PPCx主板上QLA2200的PCI板卡，包括SCSI、IP固件協議初始化。此時，可在光纖通道上建立基于SCSI或IP協議的數據通信模式；而LLA實際上一種不具備協議管理的點對點通信模式，可節約大量系統開銷，故稱之為低開銷方式。它可以建立一種類似于服務器/客戶機的通信機制，即服務端可以實時響應客戶端的數據請求，但它同樣缺乏握手安全機制。因此，如果客戶端連續發送兩次大批量數據，將會由于服務器來不及接收導致該兩批數據首尾發生沖突，故需加以改進。LLA的服務器/客戶機通信機制是通過調用函數ql22laHookAttach（）在服務端設備一個掛鉤函數來實現的。每當客戶端向服務端發送數據，該掛鉤函數將會立刻自動響應，因此，可以在掛鉤函數當設置VxWorks消息隊列，將接收幀緩存區中的數據取出。如下面的程序：
BOOL ql22LlaClientInputHook（）
{…
/*將緩存區數據發送到服務端本地消息隊列當中去*/
msgQsend(ServerQueue,ClientData,Length,NO_WAIT,0)；
}
采用消息隊列接收數據則是由于它具有消息自動追加功能，可以保證數據在高速拷貝時不被覆蓋。當傳輸完畢后，服務端就可以將消息隊列當中的數據取出來進一步處理？蛻舳藙t應當在每次發送數據完畢之后等待服務端的回答，首到得到確認之后才可以進行下一步發送。因此，客戶端必須設備回復等待，這可以利用信號燈來實現。LLA具有很高的傳輸速率。根據測試，在實施了握手通信機制后，傳輸速率可達50Mb/s以上，而且實現，系統開銷很小，適應于點對點的主機高速通信。
4 結論
本嵌入式系統復合通信模式具有多種通信接口，可適應不同的數據通信需要。同時，由于VxWorks高效的實時性以及強大的兼容性，使得復合通信的實現變得更加容易并且具有良好的實時性和安全性。通過實際運行，系統內部各個模塊運行穩定，軟件的模塊實時調度表示良好，經長時間的運行未發現通信阻塞。該復合通信模式可適用于工業控制、醫療等多方面，具有廣泛的適應性。
來源：[http://www.jdzj.com]機電之家·機電行業電子商務平臺！
]]>Mimer Information Technology announced the availability of its Mimer SQL Embedded database management system (DBMS) for Wind River’s VxWorks real-time operating system. Mimer SQL Embedded for VxWorks combines a full function enterprise class DBMS with a hard real-time data management extension with predictable and deterministic response times. This makes it possible to develop advanced hard real-time applications for process industry, automotive and consumer devices with access to the full SQL feature set.
Mimer Information Technology is a new member of Wind River’s partner program, and is now ready to launch the Mimer SQL Embedded product for Wind River’s VxWorks real-time operating system. Mimer SQL Embedded is a small footprint relational DBMS for embedded devices and appliances. Despite its small footprint, Mimer SQL Embedded is multi-user with full standard SQL support including features like stored procedures and triggers. Mimer SQL Embedded’s well-proven, efficient and self-tuning DBMS kernel gives a zero maintenance run-time environment, reduces the time-to-market for embedded solutions and enables software component reuse.
Mimer SQL Embedded for VxWorks is extended with Mimer SQL Real-Time that combines predictable hard real-time and non-real-time database access. Mimer SQL Real-Time allows data management in embedded real-time applications to be taken to a higher level while still maintaining real-time predictability and fine-grained control.
Mimer SQL Embedded highlights:
- Full SQL support
- Stored procedures and triggers
- Full concurrency control (non-locking)
- Small footprint (down to 30 KB RAM for full server)
- Zero maintenance (no ‘vacuum’ needed)
- Hard real-time support with deterministic response times (Mimer SQL Real-Time)
“We see Wind River’s VxWorks as an important platform for Mimer with many new business opportunities for us, since this is a platform widely used by the automotive, process-control and robotic industry with a growing need for enterprise class DBMS functionality with hard real-time data access”, says Stefan Eck, Marketing Director, Mimer Information Technology. “We’re also looking forward to establish a close relationship with Wind River and its partners”, concludes Stefan Eck.
Mimer SQL Embedded and Mimer SQL Real-Time are available for VxWorks 5 and 6.
“We welcome Mimer as a Wind River partner and are very pleased with that they now make their Mimer SQL database technology available for VxWorks”, says Warren Kurisu, senior director of product management, Wind River. “Mimer’s small, real-time attributes nicely complement those of VxWorks, and will meet the needs of many of our customers.
icepeak 發表于 2006-5-29 8:33:00
好多天沒更新blog了,中間忙著整另外一個blog,所以無暇顧及.現在,把前幾天學習筆記送上來!
在講述BSP的移植之前,先討論一下Vxworks的啟動過程:
在ARM系統中,系統上電后會自動加載并運行位于0地址的指令,通常在這個地方會放置一條跳轉指令,使它跳轉到_romInit()(初始化的入口)
romInit()進行處理器模式的設置,關閉中斷,初始化內存以及一些必要的硬件配置.
romInit()執行完上述工作以后,跳轉到romStart(),它負責將ROM映像copy到RAM中,如果ROM映像中不含Vxworks內核,那么啟動代碼要負責將
Vxworks內核加載到RAM中去.接下來要開始運行Vxworks內核的入口程序sysInit(),它主要實現一些與romInit()類似的功能,然后還是調用
Vxworks內核的第一個例程usrInit(),usrInit()會根據BSP的設置,最終完成整個內核的前期初始化工作.在usrInit最后,由kernelInit()激
活多任務環境,并創建一個任務來安裝設備驅動程序.同時啟動設備,初始化Vxworks系統庫,調用應用程序.
VxWorks_BSP移植_2
icepeak 發表于 2006-5-29 8:49:00
弄清楚VxWorks啟動的順序后,我們來討論BSP的移植,VxWorks的BSP在先前的日志中已經有說明,大家可以查閱了解它和bootloader的區別和
聯系.
不同的Target的BSP都不同,同種CPU的不同板子也會不同,所以移植修改是不可避免的,我們可以參考$(WIND_BASE)\target\config下的BSP
文件,找一個比較接近的來修改!關于這個目錄的組織結構,網上有很多介紹,這里不贅述.
首先要重點修改的就是Makefilie文件和config.h文件,這兩個文件跟目標板的硬件配置有很大的關系,主要是CPU類型,內存的大小和目標板
的外圍設備的配置情況.關于這兩個文件的修改下次會詳細注釋!
VxWorks操作系統是美國WindRiver公司于1983年設計開發的一種嵌入式實時操作系統（RTOS），是嵌入式開發環境的關鍵組成部分。良好的持續發展能力、高性能的內核以及友好的用戶開發環境，在嵌入式實時操作系統領域占據一席之地。它以其良好的可靠性和卓越的實時性被廣泛地應用在通信、軍事、航空、航天等高精尖技術及實時性要求極高的領域中，如衛星通訊、軍事演習、彈道制導、飛機導航等。
1 嵌入式系統
嵌入式系統是以嵌入式計算機為技術核心，面向用戶、面向產品、面向應用，軟硬件可裁減的，適用于對功能、可靠性、成本、體積、功耗等綜合性嚴格要求的專用計算機系統。和通用計算機不同，嵌入式系統是針對具體應用的專用系統，目的就是要把一切變得更簡單、更方便、更普遍、更適用；它的硬件和軟件都必須高效率地設計，量體裁衣、去除冗余，力爭在同樣的硅片面積上實現更高的性能。
嵌入式系統主要由嵌入式處理器、外圍硬件設備、嵌入式操作系統以及特定的應用程序等四部分組成，是集軟硬件于一體的可獨立工作的“器件”；用于實現對其它設備的控制、監視或管理等功能。
嵌入式系統應具有的特點是：要求高可靠性；在惡劣的環境或突然斷電的情況下，要求系統仍然能夠正常工作；許多嵌入式應用要求實時處理能力，這就要求嵌入式操作系統(EOS)具有實時處理能力；嵌入式系統中的軟件代碼要求高質量、高可靠性，一般都固化在只讀存儲器中或閃存中，也就是說軟件要求固態化存儲，而不是存儲在磁盤等載體中。
2 設備驅動程序
Vxworks5.4中驅動程序主要分為三種：字符、塊以及網絡驅動程序。本文所介紹的網卡驅動程序則屬于網絡設備驅動程序。
2.1 網絡設備驅動程序設計
網絡的各功能部件圖1所示，網絡設備驅動程序實際上是處理硬件和上層協議之間的接口程序。網絡傳輸協議層分發數據在應用程序接口和網絡接口之間。網絡化網絡協議（如IP協議）發送數據在網絡主機之間。連接/接口層使能主機隸屬于硬件到相同物理媒質的通信。
在Vxworks5.4中，網卡驅動程序又分為END（Enhanced Network Driver）和BSD兩種。它們分別處于如圖2所示結構中。
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">2.1.1 BSD驅動程序設計
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">在Vxworks5.4中，網絡驅動程序都是基于BSD UNIX版本4.3基礎上的，這些驅動程序都定義在一個全局例程中，那就是attach子程序，xxattach( )子程序中包含5個函數指針，它們都被映射到ifnet結構中，這5個函數可見表1，它們在IP協議層任何地方被調用。
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">表1 網絡接口處理
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
|
驅動程序指定函數 |
函數指針 |
功能 |
|
xxInit( ) |
if_init |
初始化接口 |
|
xxOutput( ) |
if_output |
對要傳輸的輸出分組進行排隊 |
|
xxIoctl( ) |
if_ioctl |
處理I/O控制命令 |
|
xxReset( ) |
if_reset |
復位接口設備 |
|
xxWatchdog( ) |
if_watchdog (optional) |
周期性接口例程 |
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">驅動程序入口xxattach( )調用ether_attach( )來把上述5個函數映射到ifnet結構中，ether_attach( )調用如下：
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">ether_attach(
(IFNET *) & pDrvCtrl->idr,
unit,
"xx",
(FUNCPTR) NULL,
(FUNCPTR) xxIoctl,
(FUNCPTR) ether_output( ), /* generic ether_output */
(FUNCPTR) xxReset
);
pDrvCtrl->idr.ac_if.if_start = (FUNCPTR)xxTxStartup;
上述參數中，需要一個接口數據記錄（INTERFACE Data Record (idr)），unit號和設備名，下面四個參數就是相關驅動程序的函數指針。第一個函數指針指的是init( )例程，這個例程可要可不要，第二個函數指針指的是ioctl( )接口，它允許上層來控制設備狀態；第三個函數指針指的是把數據包送到物理層；最后一個函數指針指的是如果TCP/IP堆棧決定需要復位的話，它就復位這個設備。
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">接著下面那一句代碼表示添加數據傳輸例程到IDR，ether_output( )例程被調用后，傳輸開始例程就被TCP/IP協議堆棧調用。
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">在這個入口驅動程序中還包括設備的初始化、發送和接收描述符的初始化等。
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">2.1.2 END驅動程序設計
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">END驅動程序是基于MUX模式，網絡驅動程序被劃分為協議組件和硬件組件。MUX數據鏈路層和網絡層之間的接口，它管理網絡協議接口和低層硬件接口之間的交互；將硬件從網絡協議的細節中隔離出來；刪除使用輸入鉤例程來過濾接收從協議來的數據包，和刪除了使用輸出鉤例程來過濾協議包的發送；并且鏈路層上的驅動程序需要訪問網絡層（IP或其他協議）時，也會調用相關的MUX例程。值得注意的是，網絡層協議和數據鏈路層驅動程序不能直接通訊，它們必須通過MUX。如圖3所示：
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
CHAR-indent-count: 2.0; mso-CHAR-indent-size: 10.5pt">
2.3將驅動程序加載到Vxworks系統中
要對所設計的驅動程序進行測試，首先就必須把驅動程序加載到Vxworks IMAGE中，并且給設備分配一個IP，這樣才能有利于網間測試。
首先，修改configNet.h文件，添加如下代碼：
#ifdef INCLUDE_DM_9102_END
#define DM_9102_BUFF_LOAN_0 1
#define DM_9102_LOAD_FUNC sysDm9102EndLoad
#define DM_9102_LOAD_STR_0 ""
IMPORT END_OBJ * DM_9102_LOAD_FUNC (CHAR *, void *);
和END_TBL_ENTRY endDevTbl [] 中添加
#ifdef INCLUDE_DM_9102_END
{0, DM_9102_LOAD_FUNC, DM_9102_LOAD_STR_0, TRUE, NULL, FALSE},
#endif /* INCLUDE_DM_9102_END */
其次，編輯config.h文件，添加如下代碼：
#define INCLUDE_DM_9102_END /* DAVICOM 9102 FAST ETHERNET CONTROLLER */
最后，編輯sysLib.c文件，添加如下代碼：
/* include dm9102 End driver SUPPORT routines */
#ifdef INCLUDE_DM_9102_END
IMPORT STATUS sysDm9102PciInit (void);
#endif /* INCLUDE_DM_9102_END */
/* include dm9102End driver SUPPORT routines */
#ifdef INCLUDE_DM_9102_END
#include "sysDm9102End.c"
#endif /* INCLUDE_DM_9102_END */
#ifdef INCLUDE_DM_9102_END
sysDm9102PciInit ();
#endif /* INCLUDE_DM_9102_END */
通過上述過程相應的添加程序，然后重新編譯Vxworks，這樣就將所設計的網卡驅動程序添加到Vxworks內核中了。
2.4 PCI設備檢測
如果所設計的網卡是基于PCI總線的，那么在程序開始就需要對PCI設備進行檢測，在Vxworks5.4中有專門的PCI函數來檢測設備的總線號、設備號和功能號。首先利用pciFindDevice( )函數對給定VendorID和DeviceID的設備進行檢測，檢測完后同時給出了設備的總線號、設備號和功能號；接下來就是獲得該設備的中斷號、基地址（包括IO和內存）。Vxworks中pciConfigLib.h文件中定義PCI總線的常量。如中斷號：PCI_CFG_BRG_INT_LINE，IO基地址：PCI_CFG_BASE_ADDRESS_0，內存基地址：PCI_CFG_BASE_ADDRESS_1等等。所以利用函數pciConfigInByte和pciConfigInLong就可以很容易地獲得設備的中斷號和基地址。
2.5 調試方法
為了方便調試網卡驅動程序，推薦利用串口對程序進行下載并將Vxworks image拷貝到軟盤中以從軟盤來加載它。調試的時候首先應該給網卡分配一個IP（利用usrNetIfConfig函數），然后利用ping來對網卡進行測試。
3 結語
利用上述方法所設計的網卡后，不久可以利用它來進行程序下載，而且能滿足網卡所有的功能，包括對TCP/IP和UDP/IP（組播、廣播和單播）進行了測試。
]]>
? MPC8541E嵌入計算機板
? MPC8560嵌入計算機板
? PowerPC開發板系列
- PowerPC405EP開發板
- PowerPC8245開發板
- PowerPC8247開發板
- PowerPC8280開發板
- PowerPC8349開發板
? 定制的PowerPC嵌入計算機板卡 如下：
- PowerPC405EP嵌入計算機板
- PowerPC405GPr嵌入計算機板
- PowerPC440GX嵌入計算機板
- MPC8260嵌入計算機板
- MPC8349嵌入計算機板
- MPC8536嵌入計算機板
- MPC8641D嵌入計算機板
- MPC7448嵌入式計算機板
- 1394接口協議棧for VxWorks
- USB2.0接口協議棧for VxWorks
- PATA接口硬盤存儲協議棧for VxWorks
- SATA接口硬盤存儲協議棧for VxWorks
- 高性能網絡協議棧for VxWorks
- 聲卡設備驅動for VxWorks
- PowerPC在線配置FPGA方案for VxWorks
- 集成數據I/O與FPGA的PowerPC嵌入式系統for VxWorks
? 應用于汽車電子的PowerPC嵌入式系統技術開發
- 汽車電子OSEK/VDX嵌入式系統產品
- MPC5500 MPC5534 MPC5561等MPC55xx系列嵌入式電控板
- 打開一個控制臺窗口，運行批處理程序：$(WIND_BASE)\host\x86-win32\bin\ torVars.bat;
- 重新定位到$(WIND_BASE)\target\src\drv\end目錄，運行：
- 重新定位到$(WIND_BASE)\target\lib\pentium\PENTIUM\common目錄，并將上一步生成的文件ln97xend.o復制到此目錄下。備份此目錄下的文件libdrv.a；
- 運行命令arpentium -d libdrv.a ln97xEnd.o，刪除libdrv.a中原有的ln97xEnd模塊，然后再運行命令：
- 定位目錄到$(WIND_BASE)\target\config\pcPentium并打開該目錄下Config.h文件；
- 我們首先要修改VxWorks的啟動參數。先查找到定義DEFAULT_BOOT_LINE宏的地方，修改預處理條件CPU == PENTIUM分支下的定義如下：
- lnPci(0,0)指定了使用第0個網卡和第0個處理器，lnPci這個標識會因為使用的驅動程序不同而有所不同，但這里用lnPci就可以了；
- your_host_name指定您的主機的名字，使用Windows系統的主機名就可以；
- d:\\vxWorks指定了VxWorks映象下載的完整路徑；
- h=192.168.80.169是主機的IP地址，就是您當前正在使用的系統的IP地址；
- e=192.168.80.254是目標機的IP地址，也就是未來VxWorks操作系統的IP地址，您只要任意指定一個不沖突的IP地址即可，這里我們假設您的目標機IP地址和主機IP地址在同一個網段內；
- u=target指定了FTP服務器的用戶名，這個FTP就是用來下載VxWorks映象的，后面還會提到；
- pw=vxwroks是用戶名對應的口令；
- tn=target指定目標機的名字，任意指定即可；
- 下面我們要指定使用什么樣的網卡驅動程序。首先查找“Network driver options”這段文字，之后您可以看到在該注釋后面定義了一系列的有關網卡驅動的宏定義。注意保證INCLUDE_END和INCLUDE_LN_97X_END這兩個宏處于定義狀態（define），其他的宏都處于未定義狀態（undef）；
- 缺省情況下，VxWorks系統是不接受外部輸入設備（如鍵盤）的輸入，也不向外部輸出設備（如顯示器）輸出數據。為了便于調試，我們必須改變它的這種缺省狀態。我們查找定位宏INCLUDE_PC_CONSOLE，然后保證其處于定義狀態（define）即可；
- 到此為止，對config.h文件的修改就完成了，保存修改，然后再打開同一目錄下的sysLn97xEnd.c文件；
- 這一步修改的目的是要使網卡正常工作。我們先定位到“memory-mapped IO base”這段文字，然后將其前面的參數由pciRsrc[endUnit].bar[1]修改為NONE，這樣就可以了。最后別忘了保存。
- 打開您的Tornado開發工具，在Build菜單下選擇Build Boot ROM，彈出如下對話框：
- 編譯生成bootrom后，還要創建一個VxWorks映象（image），也就是VxWorks操作系統本身的代碼。
- 創建一個“bootable VxWorks image”的工程；
- 選擇您需要的VxWorks組件。這一步是可選的，如果您只想使用缺省的配置，那根本就不需要這一步；但如果您想使用額外的組件，例如，您可能想通過telnet連接VxWorks系統，這時就需要在Workspace窗口的VxWorks選項卡中選擇telnet sever對應的組件，如下圖：
- 完成選擇后，即可開始編譯程序；
- 到此我們已經生成了VxWorks的系統引導程序和運行時的代碼映象。這里還要提醒讀者，在您每次修改完系統的配置信息（如：config.h）后，都要重新創建一個工程來編譯VxWorks映象，以免出現代碼不一致的問題。
- 將生成的名為“vxworks”的文件復制到D盤根目錄下。這個路徑是由上面我們所設置的DEFAULT_BOOT_LINE宏中的路徑參數決定的，必須保持二者一致。
- 打開Tornado FTP Server，選擇“Security”菜單下的“Users/Rights”子菜單，彈出如下對話框：
- 為了便于調試，我們還要打開FTP Server的日志功能。選擇“Logging”菜單下的“Logging Options”子菜單，彈出如下對話框，其中除了“Winsock Calls”外，讓其他選項全都處于開啟狀態。
- 保持FTP Server窗口處于打開狀態（這樣FTP服務器就處于運行狀態）。
- 打開您的VMWare Workstation，在File->New菜單下選擇創建一個新的虛擬機（Virtual Machine），按照其向導幫助，完成虛擬機的配置。在選擇操作系統類型時，選擇“Other”,其余選項均使用缺省值就可以了。
- 完成以上配置后，點擊右側窗口中的“Start this virtual machine”，系統即開始引導運行，如下圖所示：
IEC60870-5-104規定控制站（即配電主站）作為客戶機，而被控站（即配電子站）作為服務器。
基于網絡的IEC60870-5-104規約通信報文格式：I格式-可計數的信息傳輸功能；S格式-可計數的確認功能；U格式-啟動，停止，測試功能。
通信流程圖如圖2所示。
圖2 IEC60870-5-104規約通信流程圖
3.4 BSP開發
BSP是針對具體的硬件平臺，用戶所編寫的啟動代碼和部分設備驅動程序的集合。BSP所實現的功能包括初始化和驅動部分設備。BSP需要支持處理器復位、初始化、驅動串口和必要的時鐘處理等。
3.5 功能實現
從配電終端讀取數據：配電終端裝置通過CAN2.0B規約將YC、YX量等數據傳送至配電子站，并將數據填入已開辟的緩沖區。使用緩沖區操作使得系統對底層驅動程序的調用機會大大減少，將大量的數據實時的保存下來，以便于查詢和轉發。
轉發緩沖區數據：配電子站需要將從配電終端裝置獲取的數據有選擇地轉發到配電主站上去，或者接受配電主站有選擇的查詢。遙測改變，配電子站具有上送功能。
發送數據到配電主站：配電子站通過以太網將從配電終端讀取的數據傳送到配電主站，遵循基于網絡的IEC60870-5-104遠動傳輸規約。
4 系統測試和實驗
4.1 系統測試平臺
系統硬件測試平臺主要用于測試配電子站與配電終端之間的CAN通信以及配電子站與配電主站之間的以太網通信。測試中配電終端裝置采用國電南瑞的DAT-1000系列產品，主要與DAT-1L和DAT-1LA裝置進行通信。而主站則采用在PC機上通過與模擬主站進行通信來測試以太網通信。
4.2 測試與實驗結果
經過嚴格的測試和苛刻的實驗，基于嵌入式硬件平臺的配電子站能夠按照要求完成與配電主站和配電終端之間的通信。采用CAN總線通信方式與多個FTU進行通信，通信抗干擾力強，通信速度快，不丟失遙測量及SOE等。采用以太網通過基于網絡的IEC60870-5-104遠動傳輸規約與配電主站進行通信，系統可靠性高，通信速度快，完全符合配電自動化系統通信要求。
嵌入式系統主要由嵌入式處理器、外圍硬件設備、嵌入式操作系統以及特定的應用程序等四部分組成，是集軟硬件于一體的可獨立工作的“器件”;用于實現對其它設備的控制、監視或管理等功能。
嵌入式系統應具有的特點是：要求高可靠性;在惡劣的環境或突然斷電的情況下，要求系統仍然能夠正常工作;許多嵌入式應用要求實時處理能力，這就要求嵌入式操作系統(EOS)具有實時處理能力;嵌入式系統中的軟件代碼要求高質量、高可靠性，一般都固化在只讀存儲器中或閃存中，也就是說軟件要求固態化存儲，而不是存儲在磁盤等載體中。
2.設備驅動程序
Vxworks5.4中驅動程序主要分為三種：字符、塊以及網絡驅動程序。本文所介紹的網卡驅動程序則屬于網絡設備驅動程序。
·網絡設備驅動程序設計
網絡的各功能部件圖1所示，網絡設備驅動程序實際上是處理硬件和上層協議之間的接口程序。網絡傳輸協議層分發數據在應用程序接口和網絡接口之間。網絡化網絡協議(如IP協議)發送數據在網絡主機之間。連接/接口層使能主機隸屬于硬件到相同物理媒質的通信。
在Vxworks5.4中，網卡驅動程序又分為END(Enhanced Network Driver)和BSD兩種。
·BSD驅動程序設計
在Vxworks5.4中，網絡驅動程序都是基于BSD UNIX版本4.3基礎上的，這些驅動程序都定義在一個全局例程中，那就是attach子程序，xxattach( )子程序中包含5個函數指針，它們都被映射到ifnet結構中，它們在IP協議層任何地方被調用。
需要一個接口數據記錄(Interface Data Record (idr))，unit號和設備名，下面四個參數就是相關驅動程序的函數指針。第一個函數指針指的是init( )例程，這個例程可要可不要，第二個函數指針指的是ioctl( )接口，它允許上層來控制設備狀態;第三個函數指針指的是把數據包送到物理層;最后一個函數指針指的是如果TCP/IP堆棧決定需要復位的話，它就復位這個設備。
接著下面那一句代碼表示添加數據傳輸例程到IDR，ether_output( )例程被調用后，傳輸開始例程就被TCP/IP協議堆棧調用。
在這個入口驅動程序中還包括設備的初始化、發送和接收描述符的初始化等。
·END驅動程序設計
END驅動程序是基于MUX模式，網絡驅動程序被劃分為協議組件和硬件組件。MUX數據鏈路層和網絡層之間的接口，它管理網絡協議接口和低層硬件接口之間的交互;將硬件從網絡協議的細節中隔離出來;刪除使用輸入鉤例程來過濾接收從協議來的數據包，和刪除了使用輸出鉤例程來過濾協議包的發送;并且鏈路層上的驅動程序需要訪問網絡層(IP或其他協議)時，也會調用相關的MUX例程。值得注意的是，網絡層協議和數據鏈路層驅動程序不能直接通訊，它們必須通過 MUX。如圖3所示：
]]>具有雙冗余網卡的節點雖然有2塊網卡，2條通道，但對于高層應用系統來說，仍呈現單網卡的特征。具體來講，2塊網卡共有1個物理地址，1個IP地址。根據TCP/IP參考模型，TCP/IP協議族可以分為應用層、傳輸層、網絡層和鏈路層4層，冗余網卡技術可以在其中各個層面中實現。
VxWorks、MUX與網卡驅動程序
嵌入式實時操作系統VxWorks的網絡協議棧與網絡設備驅動的接口有2種：一種是標準的BSD4.4Driver，它將Driver和協議緊密關聯在一起，不利于多協議的支持；另一種標準是VxWorks特有的，它將Driver和協議棧隔離開，使二者通過一個稱為MUX的薄層相連，使得網絡服務免受特定的網絡接口驅動程序的影響，達到Driver獨立于具體協議的目的，從而實現多協議的支持，三者間的關系如圖2所示。
目前版本的MUX支持2種網絡驅動程序接口模式：增強型網絡驅動程序接口( END)和網絡協議工具包(NPT)驅動程序接口，F以END型網卡驅動為例介紹如何在VxWorks5.4下的NE2000兼容網卡驅動程序中實現雙網卡冗余設計。正常情況下，協議驅動程序通過MUX層提供的NIC的句柄來提交請求，這個句柄是調用EndLoaD()獲得的；然后MUX層調用網卡驅動程序中的接口函數，實現高層協議驅動程序的請求。
在應用層實現雙冗余網卡技術的分析
在系統中對網卡進行雙冗余備份，即1塊網卡在正常工作時使用，另1塊網卡作為備份。備份用的網卡處于激活狀態。在正常通信的網卡出現故障或系統需要時，備份用的網卡能實時地、自動地切換到繼續工作。顯然，這就要求2塊網卡只能使用同1個物理地址和同1個IP地址。從應用程序的角度看，只會看見1塊網卡在工作，不關心是哪塊網卡在工作及如何切換。
理論上講，冗余網卡技術可以在OSI各層中實現，而且越在底層實現，檢測和切換的速度越快，效果應該越好。其他利用應用層實現雙冗余網卡的主要方法是在程序中發起任務，以查詢的方式不斷對當前工作網卡的工作狀態進行判斷，當判斷出當前使用的網卡處于非正常狀態的時候，將刪除當前網卡的路由，在主機列表中刪除當前主機名，并解除網卡與協議的綁定；然后進行備份網卡的配置：為備份網卡綁定協議，設置子網掩碼和IP地址。用此種方法實際測試，測試中使裝有雙網卡的主機不斷向外發送廣播報文，同時用網絡分析軟件接收。測得2個網口的切換時間平均為120ms，在切換期間有很多廣播報文丟失？梢娫趹脤訉崿F雙網卡冗余備份技術，網卡切換速度慢，不利于網絡的可靠性和實時性。
在驅動程序中的實現
在VxWorks系統中，相同類型的網卡使用同一個驅動程序，網卡之間由驅動程序提供的句柄來區別。MUX調用NIC驅動程序的接口函數時，都會把網卡的句柄傳入函數中。這就為在驅動程序中實現雙網卡冗余備份提供了基礎。因此要實現網卡的雙冗余備份，最理想的辦法是在NIC驅動程序中實現。
數據結構
網卡驅動程序中最關鍵的數據結構是有關網卡特性的數據結構。每種網卡都有它自己的特性，包括它的單元號、中斷向量、I/O基址、物理地址等。
系統啟動時，在網卡驅動的裝載函數中ne2000EndLoad( )中，會為設備初始化1個數據結構，并分配一個指針指向這個結構。這時定義2個全局指針：
NE2000END-DEVICE * pDrvCtrl-0；
NE2000END-DEVICE * pDrvCtrl-1；
在網卡初始化時把這2個指針分別指向2塊網卡的數據結構，通過這2個指針的定義，在MUX調用NIC驅動程序的接口函數時，可以根據網卡的好壞或系統的需要來選擇pDrvCtrl-0或pDrvCtrl-1，以調整工作網卡。
發送和接收處理
在上層驅動程序通過MUX調用NIC驅動程序的發送函數時，會傳入網卡的句柄，指定要使用的網卡。通常情況下，驅動程序會根據該句柄向相應網卡發出指令，把報文發出去。在雙網卡冗余備份驅動程序中，根據需要來指定發送數據要使用的網卡，而不一定使用MUX指定的網卡。如先讀2塊網卡的Link信號寄存器，判斷網絡連線的通斷，再決定使用哪一塊網卡來發送數據。
在接收報文的時候，通常是在中斷中進行處理。因為以太網在物理層上的特點，2塊網卡都能收到報文，不同的是只有與高層協議綁定的網卡收到的數據才能向上傳遞。在雙網卡冗余備份驅動程序中，不是由MUX指定的網卡句柄來向上傳送數據，而是根據當前網卡的工作狀態向上層傳送數據，即使數據是從另一塊網卡上接收來的或另一塊網卡沒有和高層協議綁定。
單物理地址的處理
通常每塊網卡有1個全世界范圍內唯一的物理地址，它保存在網卡的PROM中。網卡初始化時，要從PROM中讀出物理地址，把它存放在適當的寄存器和數據結構中。
要使2塊網卡能相互備份，它們必須有相同的物理地址和IP地址。在雙網卡冗余備份驅動程序中，可以用其中1塊網卡的物理地址。方法有2種：在驅動程序初始化時只讀1塊網卡的PROM中的物理地址；或者在網卡驅動程序中的ne2000EnetAddrGet()函數中作修改，完全可以給網卡設定任意的物理地址(只要避免了同一網絡中的沖突)。
單IP地址處理
至于2塊網卡采用相同的IP地址，可以這樣實現：在安裝2塊網卡時，只讓1塊網卡有IP地址，另1塊網卡沒有IP地址。因為給網卡綁定IP地址是在IP協議所在的網絡層實現的，所以在網絡層以下切換網卡對上層來說是完全透明的。應用程序自始自終只看見1塊網卡在工作。圖3是從應用程序的角度看雙網卡備份的示意圖。
效果分析
通過對比實驗，在應用層實現雙網卡冗余備份的平均網卡切換時間是120ms，在驅動層實現雙網卡冗余備份的平均網卡切換時間是5ms，相對于在應用層或其他高層中實現，效率較高，大大縮短雙網卡的切換時間，從而降低切換時網絡通信丟包的機率。
關鍵字：實時操作系統 簡單網絡管理協議 代理
1. 引言
簡單網絡管理協議（SNMP）已經成為目前網絡管理方面事實上的標準。同命名一樣，它的操作非常簡單易行，所以引起了越來越多的商家的注意，在計算機、通信和自動化等各個領域都發揮了很大的作用。同時，VxWorks嵌入式操作系統又由于其出色的實時性和穩定性受到業界的廣泛的好評，所以如何實現在VxWorks系統上通過SNMP協議對設備進行管理是我們面臨的一個很重要的課題。
2. SNMP及系統簡介
VxWorks操作系統是美國WindRiver公司設計開發的一種嵌入式實時操作系統，具有以下特點：
1.高效的代碼和良好的可裁剪性采用微內核結構，內核可裁減至幾十B 字節，對于資源相對緊張的嵌入式系統具有非常好的適應性。
2.豐富的接口資源和大量的第三方產品為VxWorks的廣泛應用奠定了堅實的基礎
3.良好的移植性，可以移植到不同的處理器平臺，包括PPC、ARM和X86等不同的處理器。
4.良好的開發環境，非常好的開發環境Tornado并在不斷升級
WindNet SNMP代理將工業標準網絡管理引入實時嵌入系統中，實現了對嵌入式設備管理的接口。應用上只需配置其初始化過程和應用系統提供的部分接口就可以方便實現對嵌入式設備的管理，同時支持多種SNMP版本的支持，現在已經可以支持SNMPv3最高版本。SNMP的工作過程可以如圖1所示：
圖 1 SNMP 基本框架
3. 處理流程
3.1 初始化過程
Vxworks是通過調用usrSnmpInit（ ）函數來啟動SNMP服務的，所以對于VxWorks微內核，一定要包含usrSnmpInit（ ）函數。它然后創建任務名為tSnmpd的任務，這個任務的函數入口點為snmpIoMain（ ）。在庫snmpIoLib.c中提供了該函數的部分源代碼，用戶可以加入自己的代碼，比如讀某些配置文件和私有的配置信息等。snmpIoMain（ ）然后調用snmpdInitFinish（ ）函數來完成整個代理的初始化過程。然后snmpInitFinish（ ）通過snmpIoTrapSend（ ）函數發送coldStart的trap，表示整個初始化過程完畢。這里需要注意的是所有其他的初始化和配置工作一定要在snmpInitFinish（ ）調用之前，然后系統回到snmpIoMain（ ）函數體，開始和管理站之間的收發包過程。
3.2 數據包處理
數據包的處理過程是通過snmpIoBody（ ）的這個守護進程開始的，它的主要工作是監視 UDP 161端口，如果管理站有請求發送過來，它把請求發給snmpdPktProcess（ ）來處理，通過snmpIoCommunityValidate（ ）檢查共同體的名稱是否正確。然后調用用戶自己的程序完成請求，對于SET操作，還要調用snmpIoWrite（ ）來完成整個操作。這里要注意的是用戶要提供自己的代碼完成請求，比如說對某一個變量的讀取，一定要給出對應的具體位置，這部分可以通過修改snmpdLib.c中的函數來完成。
對于trap的處理有單獨的一套流程，首先如果一件意外事件發生，比如冷啟動，調用snmpdTrapSend（ ）函數來處理。對于trap，可以通過用戶自定義的方式來實現系統需要的trap。一般來講，它通過snmpIoWrite（ ）函數把信息傳遞給管理站。
3.3 退出代理
如果用戶想中止代理，可以調用函數snmpdExit（ ）來完成，同時會釋放各種資源。
以上部分流程圖如圖2所示：
圖 2 基本流程
4. 擴展MIB模塊
對默認的SNMP配置，代理已經包含了包括MIB-II和其他的基本MIB庫，但對于有些環境不需要部分庫，同時需要加入基于本設備和本廠家的私有MIB，所以很有必要對MIB進行擴展和裁減，也利于對嵌入式設備的標準化管理。以下介紹整個過程。
1. 定義管理信息
這步主要用來定義SNMP需要管理的信息，其中部分信息已經通過標準MIB實現，實際只要加入就可以了。
2. 創建MIB定義
根據ASN.1標準語法創建MIB。
一般有以下形式：
DEFINITIONS ::= BEGIN
—— Title: EXAMPLE
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE
FROM SNMPv2-SMI
……
windDemo MODULE-IDENTITY
LAST-UPDATED "2004-9-26"
ORGANIZATION
CONTACT-INFO
Phone：……
Email：……
DESCRIPTION
"This is a example"
::= ｛ demos 1 ｝
windObjects OBJECT IDENTIFIER ::= ｛ windDemo 1 ｝
sysState OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"EXAMPLE"
::= ｛ sysconfig 1 ｝
END
3. 檢查正確性，轉換成.h和.c文件
可以應用mibcomp –check工具來檢驗MIB文件的正確性，利于mibcomp –o生成相應的.h和.c文件。
4. 編譯MIB文件
將MIB文件加入到已經存MIB模塊中。通常有靜態和動態兩種方式。
靜態類似于通常的編譯文件的全過程。這里主要介紹動態方式，因為這種方式可以實現在原始模塊照常工作的情況下加入或卸載新模塊。首先通過mibcomp –l命令將新的MIB文件編譯成模塊。然后用命令ld在shell下實現MIB的動態加載。
5. 總結
VxWorks將SNMP應用到整個系統，實現了對嵌入式設備的標準化管理，利于對同不同的管理站進行接口。SNMP不僅實現了對嵌入式設備的管理還提供了監視整個系統正常運行的基本功能，同時還可以通過對CPU的檢查實現發現軟件方面的漏洞。總之，將SNMP應用到微內核，會在嵌入式這個自動化領域發揮出越來越大的作用。
#undef INCLUDE_ENV_VARS /* unix compatable environment variables */
#undef INCLUDE_TIMEX /* timexLib for exec timing */
#undef INCLUDE_HW_FP
#undef INCLUDE_TFTP_CLIENT /* used by autoboot from ftp server*/
#define INCLUDE_SW_FP
#define INCLUDE_ELF
#define INCLUDE_NET_SHOW
#define INCLUDE_PING
#undef INCLUDE_DEMO /* only for vxWorks bsp test */
#define ETHERNET_ADR_SET /* only for bootrom used */
#define INCLUDE_USER_APPL /* Startup the user''s application in dos makefile project */
#undef PCIDEBUG
#ifdef INCLUDE_USER_APPL
#define USER_APPL_INIT _appEntry()
#endif
#endif /* INCconfigh */
#if defined(PRJ_BUILD)
#include "prjParams.h"
#endif
Makefile文件配置
# Makefile - make rules for board
#
#*/
CPU = PPC40x
TOOL = gnu
TGT_DIR=$(WIND_BASE)/target
include $(TGT_DIR)/h/make/defs.bsp
include $(TGT_DIR)/h/make/make.$(CPU)$(TOOL)
include $(TGT_DIR)/h/make/defs.$(WIND_HOST_TYPE)
## Only redefine make definitions below this point, or your definitions will
## be overwritten by the makefile stubs above.
TARGET_DIR = xxx
VENDOR = IBM
BOARD = xxx
RELEASE = vxWorks vxWorks.st bootrom_uncmp.hex
USR_ENTRY = usrInit
# ROM_TEXT_ADRS, ROM_SIZE, RAM_HIGH_ADRS, 和RAM_LOW_ADRS 在config.h,Makefile和Makefile.*文件中 # 都要定義,且必須要保持一致,
ROM_TEXT_ADRS = fff80100 # ROM 起始地址
ROM_SIZE = 0007f000 # ROM 空間大小
RAM_LOW_ADRS = 00010000 # RAM 低地址 vxWorks */
RAM_HIGH_ADRS = 00C00000 # RAM 高地址存儲 bootrom */
HEX_FLAGS = -a 100
#ADDED_CFLAGS = -gdwarf -O0 # for debug
MACH_EXTRA = appentry.o # 注意:這里加載用戶的程序模塊,程序調用在usrRoot()
BOOTCONFIG = bootconfig.c # bsp bootconfig.c for bootrom
## Only redefine make definitions above this point, or the expansion of
## makefile target dependencies may be incorrect.
include $(TGT_DIR)/h/make/rules.bsp
include $(TGT_DIR)/h/make/rules.$(WIND_HOST_TYPE)
Tornado for x86下BSP的生成,下載和Target Server的配置實例，Pentium主機，3Com網卡，軟盤引導，ftp下載VxWorks映像。
1.在C:\Tornado\target\config\pcPentium目錄下修改BSP文件config.h。
]]>#elif (CPU_VARIANT == PENTIUM)
#define DEFAULT_BOOT_LINE
"elt(0,0)HOST:c:\\Tornado\\target\\config\\pcPentium\\vxWorks
h=90.0.0.3 e=90.0.0.50 u=target pw=target tn=target"
#define INCLUDE_ELT //3Com網卡
#define INCLUDE_END //END驅動2.打開Tornado選擇新建一個bootable vxworks image，選擇建 A BSP，選擇
pcPentium，建完后編譯就可以在相應的目錄下生成vxworks的映像文件。
3.制作bootrom；選擇Build Boot Rom，選擇pcPentium,再選擇bootrom_uncmp，
生成 bootrom_uncmp？截 bootrom_uncmp到host\x86-win32\bin下，插入空白
盤到軟區，在dos界面進入目錄host\x86-win32\bin下，用命令"mkboot a:
bootrom_uncmp "生成引導盤
4. 在Start > Programs > Tornado2 > FTP Server，點開Security下的
user/rights菜單，新建用戶User Name:target，Password:target，Home
Directory為VxWorks映像所在目錄如 C:\Tornado\target\config\pcPentium\。
注意這些配置要和config.h中的一致。
5.將bootrom的啟動盤插入目標機的軟驅，啟動目標機，系統從軟驅啟動，隨后登
陸FTP，從主機下載vxworks文件，目標機提示7秒內按任意鍵選擇Boot方式（手工
，自動），手工方式可對FTP用戶，口令，IP等參數進行修改。
通常是等待7秒后系統autoboot。
屏幕顯示：
Attached TCP/IP interface to elt0.
Attaching network interface lo0... done. //TCP/IP網絡連接成功
Loading... 602128 //通過ftp下載VxWorks映像
Starting at 0x01080000 //下載成功，從RAM_LOW_ADRS 0x01080000
開始執行VxWorks系統
Attached TCP/IP interface to elt unit 0
Attaching interface lo0...done //TCP/IP網絡連接成功
(注意這里網絡初始化成功和上邊的不同，上邊是Bootrom映像網絡初始化來下載VxWorks,這里VxWorks系統初始化網絡。)
VxWorks
Copyright 1984-1998 Wind River Systems, Inc.
CPU: xxxx --- Intel x82
VxWorks: 5.4
BSP version: 1.2/4
Creation date: Jan xx 2001
WDB: Ready.至此目標機系統啟動完成。
6.配置Target Server下載應用程序.打開Tornado，在Tools菜單下選擇Target Sever再選擇configure進行配置(Tools
> Target Server > Configure > New)給出Target Server名字描述如net00.在
(Target Server Properties > Back End)選擇WdbRpc. Target Name/IP Address
框內輸入Target的IP: 90.0.0.50.
Core File and Symbols選項(Target Server Properties > Core File and
Symbols)： C:\Tornado\target\config\pcPentium\vxWorks等等。
配置的內容根據系統的具體情況定。點擊Launch啟動Target Sever，隨后在主界
面下選擇已啟動的Target Sever就可以下載 *.o或*.out程序。
在計算的早期開發的操作系統的最原始的結構形式是一個統一的實體(monolithic)
。在這樣的系統中，提供的不同功能的模塊，如處理器管理、內存管理、輸入輸出等，
通常是獨立的。然而他們在執行過程中并不考慮其他正在使用中的模塊，各個模塊都以
相同的時間粒度運行。
由于現代實時環境需要許多不同的功能，以及在這樣的環境中存在的并發活動所引
起的異步性和非確定性，操作系統變得更加復雜。所以早期操作系統的統一結構的組織
已經被更加精確的內部結構所淘汰。
層次結構的起點----內核
操作系統的最好的內部結構模型是一個層次性的結構，最低層是內核。這些層次可
以看成為一個倒置的金字塔，每一層都建立在較低層的功能之上。 內核僅包含一個操作
系統執行的最重要的低層功能。正象一個統一結構的操作系統，內核提供了在高層軟件
與下層硬件之間的抽象層。然而，內核僅提供了構造操作系統其他部分所需的最小操作
集。
對一個實時內核的要求
一個實時操作系統內核需滿足許多特定的實時環境所提出的基本要求，這些包括：
多任務：由于真實世界的事件的異步性，能夠運行許多并發進程或任務是很重要的。多
任務提供了一個較好的對真實世界的匹配，因為它允許對應于許多外部事件的多線程執
行。系統內核分配CPU給這些任務來獲得并發性。
搶占調度：真實世界的事件具有繼承的優先級，在分配CPU的時候要注意到這些優先
級。基于優先級的搶占調度，任務都被指定了優先級， 在能夠執行的任務（沒有被掛起
或正在等待資源）中，優先級最高的任務被分配CPU資源。換句話說，當一個高優先級的
任務變為可執行態，它會立即搶占當前正在運行的較低優先級的任務。
快速靈活的任務間的通信與同步：在一個實時系統中，可能有許多任務作為一個應
用的一部分執行。系統必須提供這些任務間的快速且功能強大的通信機制。內核也要提
供為了有效地共享不可搶占的資源或臨界區所需的同步機制。
方便的任務與中斷之間的通信：盡管真實世界的事件通常作為中斷方式到來，但為
了提供有效的排隊、優先化和減少中斷延時，我們通常希望在任務級處理相應的工作。
所以需要雜任務級和中斷級之間存在通信。
性能邊界：一個實時內核必須提供最壞情況的性能優化，而非針對吞吐量的性能優
化。我們更期望一個系統能夠始終以50微妙執行一個函數，而不期望系統平均以10微妙
執行該函數，但偶爾會以75微妙執行它。
特殊考慮：由于對實時內核的要求的增加，必須考慮對內核支持不斷增加的復雜功
能的要求。這包括多進程處理，Ada和對更新的、功能更強的處理器結構如RISC的支持。
擁有其它名字的內核
許多商用化的內核支持的功能遠強于上面所列的要求。在這方面，他們不是真正的
內核，而更象一個小的統一結構的操作系統。因為他們包含簡單的內存分配、時鐘管理
、甚至一些輸入輸出系統調用的功能。
這種分類不僅僅是在語義上的爭論，在這篇文章的后面章節將說明限制內核功能和
油畫這些功能的重要性。
2． VxWorks內核：Wind
VxWorks操作系統是一種功能最全的現在可以獲得的獨立于處理器的實時系統。然而
，VxWorks是帶有一個相當小的真正微內核的層次結構。內核僅提供多任務環境、進程間
通信和同步功能。這些功能模塊足夠支持VxWorks在較高層次所提供的豐富的性能的要求
。 通常內核操作對于用戶是不可見的。應用程序為了實現需要內核參與的任務管理和同
步使用一些系統調用，但這些調用的處理對于調用任務是不可見的。應用程序僅鏈接恰
當的VxWorks例程（通常使用VxWorks的動態鏈接功能），就象調用子程序一樣發出系統
調用。這種接口不象有些系統需要一個笨拙的跳轉表接口，用戶需要通過一個整數來指
定一個內核功能調用。
多任務
內核的基本功能是提供一個多任務環境。多任務使得許多程序在表面上表現為并發
執行，而事實上內核是根據基本的調度算法使他們分段執行。每個明顯獨立的程序被成
為一個任務。每個任務擁有自己的上下文，其中包含在內核調度使該任務執行的時候它
所看到的CPU環境和系統資源。
任務狀態
內核維護系統中的每個任務的當前狀態。狀態遷移發生在應用程序調用內核功能服
務的時候。下面定義了wind內核狀態：
就緒態----一個任務當前除了CPU不等待任何資源
阻塞態----一個任務由于某些資源不可獲得而被阻塞
延遲態----一個任務睡眠一段時間
掛起態----主要用于調試的一個輔助狀態，掛起禁止任務的執行
任務被創建以后進入掛起態，需要通過特定的操作使被創建的任務進入就緒態，這
一操作執行速度很快，使應用程序能夠提前創建任務，并以一種快捷的方式激活該任務
。
調度控制
多任務需要一個調度算法分配CPU給就緒的任務。在VxWorks中默認的調度算法是基
于優先級的搶占調度，但應用程序也可以選擇使用時間片輪轉調度。
基于優先級搶占調度：基于優先級的搶占調度，每個任務被指定一個優先級，內核
分配CPU給處于就緒態的優先級最高的任務。調度采用搶占的方式，是因為當一個優先級
高于當前任務的任務變為就緒態時，內核將立即保存當前任務的上文，并切換到高優先
級任務的上文。VxWorks有從0到255共256個優先級。在創建的時候任務被指定一個優先
級，在任務運行的過程中可以動態地修改優先級以便跟蹤真實世界的事件優先級。外部
中斷被指定優先于任何任務的優先級，這樣能夠在任何時候搶占一個任務。
時間片輪轉：基于優先級搶占調度可以擴充時間片輪轉調度。時間片輪轉調度允許
在相同優先級的處于就緒態的任務公平地共享CPU。沒有時間片輪轉調度，當有多個任務
在同一優先級共享處理器時，一個任務可能獨占CPU，不會被阻塞直到被一個更高優先級
的任務搶占，而不給同一優先級的其他任務運行的機會。如果時間片輪轉被使能，執行
任務的時間計數器在每個時鐘滴答遞增。當指定的時間片耗盡，計數器會被清零，該任
務被放在同一優先級任務隊列的隊尾。加入特定優先級組的新任務被放在該組任務的隊
尾，并將運行計數器初始化為零。
基本的任務函數
用于狀態控制的基本任務函數包括一個任務的創建、刪除、掛起和喚醒。一個
任務也可以使自己睡眠一個特定的時間間隔不去運行。
許多其他任務例程提供由任務上下文獲得的狀態信息。這些例程包括訪問一個任務當前
處理器寄存器控制。
任務刪除問題
wind內核提供防止任務被意外刪除的機制。通常，一個執行在臨界區或訪問臨界資
源的任務要被特別保護。我們設想下面的情況：一個任務獲得一些數據結構的互斥訪問
權，當它正在臨界區內執行時被另一個任務刪除。由于任務無法完成對臨界區的操作，
該數據結構可能還處于被破壞或不一致的狀態。而且，假想任務沒有機會釋放該資源，
那麼現在其他任何任務現在就不能獲得該資源，資源被凍結了。
任何要刪除或終止一個設定了刪除保護的任務的任務將被阻塞。當被保護的任
務完成臨界區操作以后，它將取消刪除保護以使自己可以被刪除，從而解阻塞刪除任務
。
正如上面所展示的，任務刪除保護通常伴有互斥操作。
這樣，為了方便性和效率，互斥信號量包含了刪除保護選項。（參見"互斥信號量"
）
任務間通信
為了提供完整的多任務系統的功能，wind內核提供了一套豐富的任務間通信與同步
的機制。這些通信功能使一個應用中各個獨立的任務協調他們的活動。
共享地址空間
wind內核的任務間通信機制的基礎是所有任務所在的共享地址空間。通過共享地址
空間，任務能夠使用共享數據結構的指針自由地通信。管道不需要映射一塊內存區到兩
個互相通信任務的尋址空間。
不幸的是，共享地址空間具有上述優點的同時，帶來了未被保護內存的重入訪
問的危險。UNIX操作系統通過隔離進程提供這樣的保護，但同時帶來了對于實時操作系
統來說巨大的性能損失。
互斥操作
當一個共享地址空間簡化了數據交換，通過互斥訪問避免資源競爭就變為必要的了
。用來獲得一個資源的互斥訪問的許多機制僅在這些互斥所作用的范圍上存在差別。實
現互斥的方法包括禁止中斷、禁止任務搶占和通過信號量進行資源鎖定。
中斷禁止：最強的互斥方法是屏蔽中斷。這樣的鎖定保證了對CPU的互斥訪問。這種
方法當然能夠解決互斥的問題，但它對于實時是不恰當的，因為它在鎖定期間阻止系統
響應外部事件。長的中斷延時對于要求有確定的響應時間的應用來說是不可接受的。
搶占禁止：禁止搶占提供了強制性較弱的互斥方式。 當前任務運行的過程中不允許
其他任務搶占，而中斷服務程序可以執行。這也可能引起較差的實時響應，就象被禁止
中斷一樣，被阻塞的任務會有相當長時間的搶占延時，就緒態的高優先級的任務可能會
在能夠執行前被強制等待一段不可接受的時間。為避免這種情況，在可能的情況下盡量
使用信號量實現互斥。
互斥信號量：信號量是用于鎖定共享資源訪問的基本方式。不象禁止中斷或搶占，
信號量限制了互斥操作僅作用于相關的資源。一個信號量被創建來保護資源。VxWorks的
信號量遵循Dijkstra的P()和V()操作模式。
當一個任務請求信號量，P()， 根據在發出調用時信號量的置位或清零的狀態， 會
發生兩種情況。如果信號量處于置位態， 信號量會被清零，并且任務立即繼續執行。如
果信號量處于清零態，任務會被阻塞來等待信號量。
當一個任務釋放信號量，V()，會發生幾種情況。如果信號量已經處于置位態，釋放
信號量不會產生任何影響。如果信號量處于清零態且沒有任務等待該信號量，信號量只
是被簡單地置位。如果信號量處于清零態且有一個或多個任務等待該信號量，最高優先
級的任務被解阻塞，信號量仍為清零態。
通過將一些資源與信號量關聯，能夠實現互斥操作。當一個任務要操作資源，它必
須首先獲得信號量。只要任務擁有信號量，所有其他的任務由于請求該信號量而被阻塞
。當一個任務使用完該資源，它釋放信號量，允許等待該信號量的另一個任務訪問該資
源。
Wind內核提供了二值信號量來解決互斥操作所引起的問題。 這些問題包括資源擁有
者的刪除保護，由資源競爭引起的優先級逆轉。
刪除保護----互斥引起的一個問題會涉及到任務刪除。在由信號量保護的臨界區中
，需要防止執行任務被意外地刪除。刪除一個在臨界區執行的任務是災難性的。資源會
被破壞，保護資源的信號量會變為不可獲得，從而該資源不可被訪問。通常刪除保護是
與互斥操作共同提供的。由于這個原因，互斥信號量通常提供選項來隱含地提供前面提
到的任務刪除保護的機制。
優先級逆轉/優先級繼承----優先級逆轉發生在一個高優先級的任務被強制等待一段
不確定的時間以便一個較低優先級的任務完成執行？紤]下面的假設：
T1，T2和T3分別是高、中、低優先級的任務。T3通過擁有信號量而獲得相關的資源
。當T1搶占T3，為競爭使用該資源而請求相同的信號量的時候，它被阻塞。如果我們假
設T1僅被阻塞到T3使用完該資源為止，情況并不是很糟。畢竟資源是不可被搶占的。然
而，低優先級的任務并不能避免被中優先級的任務搶占，一個搶占的任務如T2將阻止T3
完成對資源的操作。這種情況可能會持續阻塞T1等待一段不可確定的時間。這種情況成
為優先級逆轉，因為盡管系統是基于優先級的調度，但卻使一個高優先級的任務等待一
個低優先級的任務完成執行。
互斥信號量有一個選項允許實現優先級繼承的算法。優先級繼承通過在T1被阻塞期
間提升T3的優先級到T1解決了優先級逆轉引起的問題。這防止了T3，間接地防止T1，被
T2搶占。通俗地說，優先級繼承協議使一個擁有資源的任務以等待該資源的任務中優先
級最高的任務的優先級執行。當執行完成，任務釋放該資源并返回到它正常的或標準的
優先級。因此，繼承優先級的任務避免了被任何中間優先級的任務搶占。
同步
信號量另一種通常的用法是用于任務間的同步機制。在這種情況下，信號量代表一
個任務所等待的條件或事件。最初，信號量是在清零態。一個任務或中斷通過置位該信
號量來指示一個事件的發生。等待該信號量的任務將被阻塞直到事件發生、該信號量被
置位。一旦被解阻塞，任務就執行恰當的事件處理程序。信號量在任務同步中的應用對
于將中斷服務程序從冗長的事件處理中解放出來以縮短中斷響應時間是很有用的。
消息隊列
消息隊列提供了在任務與中斷服務程序或其他任務間交換變長消息的一種較低層的
機制。這種機制在功能上類似于管道，但有較少的開銷。
管道、套接字、遠程過程調用和更多
許多高層的VxWorks機制提供任務間通信的更高層的抽象，包括管道、TCP/IP套接字
、遠程過程調用和更多。為了保持裁減內核為僅包含足夠支持高層功能的一個最小函數
集的設計目標，這些特性都是基于上面描述的內核同步方式的。
3． 內核設計的優點
wind內核的一個重要的設計特性是最小的搶占延時。其他的主要設計的優點包括史
無前例的可配置性，對不可預見的應用需求的可擴展性，在各種微處理器應用開發中的
移植性。
最小的搶占延時
正如前面所討論的，禁止搶占是獲得代碼臨界資源互斥操作的通常手段。這種技巧
的不期望的負面影響是高的搶占延時，這可以通過盡量使用信號量實現互斥和保持臨界
區盡量緊湊被減小。但即使廣泛地使用信號量也不能解決所有的可能導致搶占延時的根
源。內核本身就是一個導致搶占延時的根源。為了理解其原因，我們必須更好地理解內
核所需的互斥操作。
內核級和任務級
在任何多任務系統中，大量的應用是發生在一個或多個任務的上下文。然而，有些
CPU時間片不在任何任務的上下文。這些時間片發生在內核改變內部隊列或決定任務調度
。在這些時間片中，CPU在內核級執行，而非任務級。
為了內核安全地操作它的內部的數據結構，必須有互斥操作。內核級沒有相關的任
務上下文，內核不能使用信號量保護內部鏈表。內核使用工作延期作為實現互斥的方式
。當有內核參與時，中斷服務程序調用的函數不是被直接激活，而是被放在內核的工作
隊列中。內核完成這些請求的執行而清空內核工作隊列。
當內核正在執行已經被請求服務時系統將不響應到達內核的函數調用。可以簡單地
認為內核狀態類似于禁止搶占。如前面所討論的，搶占延時在實時系統中是不期望有的
，因為它增加了對于會引起應用任務重新調度的事件的響應時間.
管操作系統在內核級（此時禁止搶占）完全避免消耗時間是不可能的，但減少這些
時間是很重要的。這是減少由內核執行的函數的數量的主要原因， 也是不采用統一結構
的系統設計方式的原因。例如，有一種流行的實時操作系統的每個函數都是在內核級執
行。這意味著當一個低優先級的任務在執行分配內存、獲得任務信息的函數時所有高優
先級的任務被禁止搶占。
一個最小的內核
已經說明了一個最小內核的優點和構造高層操作系統功能的必要功能，我們使用這
些操作原語來執行一個傳統的內核級功能，而在VxWorks中作為任務級功能執行，內存管
理。 在這個例子中，考慮用戶可調用的子例程malloc， 用于分配所請求大小的內存區
并返回一個指向該內存區的指針。假定空閑內存區是通過搜索一個空閑內存塊的隊列找
到的，一個信號量必須被用來保護這個非搶占多用戶資源。分配內存的操作如下：
獲得互斥信號量
搜索空閑內存塊鏈表
釋放互斥信號量
值得注意的是搜索一個足夠大的空閑內存塊的可能的冗長的時間是發生在調用任務
的上下文中。這是可以被高優先級的任務搶占的（除了信號量調用的這段執行時間）。
在一個標準的統一結構的實時內核中，內存分配例程操作如下：
進入內核
]]>
基于VxWorks實現OpenGL三維顯示vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真( \' P% j9 ?) v, B. R" S0 N
中國最活躍的虛擬現實技術交流社區: g! L* q( V8 z6 h
當前,實時嵌入式系統的發展非常迅猛,在工業控制、軍事、航空航天、手持設備等各個方面都得到了廣泛的應用.其中,為實時嵌入式系統提供友好的圖形用戶界面(GUI)成為了重要的發展方向.本論文根據實時嵌入式系統的特殊要求,針對VxWorks操作系統現有GUI部件——WindML在所支持的顯示硬件設備和圖形繪制方面的不足,對它做了功能上的擴充,并將它更名為E-UGL,意為擴展的通用圖形庫.顯示設備驅動程序是GUI的基礎.課題首先設計了針對AGP顯示設備——Intel82815顯示引擎的核心數據結構,實現了對幀緩存(Frame Buffer)機制和圖形地址重映射表(GART)機制的支持,解決了在VxWorks下AGP顯示設備的初始化問題;第二,驅動實現了對多種顯示模式的支持,最高可以達到1280×1024顯示分辨率、16位顏色、75Hz刷新頻率,解決了嵌入式系統中顯示模式單一、落后的問題;第三,用ELFA算法實現了直線段繪制函數,用中點法實現了橢圓繪制函數,使系統的圖形繪制性能有了一定程度的提高.用正負法實現了圓繪制函數,提高了繪制的精度.第四,將mesa3d的三維函數庫移植到VxWorks中,使驅動可以支持OpenGL應用;第五,在驅動中實現了雙緩存機制,提高了系統的三維圖形繪制速度;第六,在驅動中實現了可編程鍵盤,即可以對四線電阻式觸摸屏設備提供支持,使得驅動能夠適應無鼠標和鍵盤條件下的嵌入式系統.驅動不僅支持高分辨率的顯示模式和圖形繪制,而且支持無鼠標和鍵盤的應用環境.另外,代碼是自主設計和實現的,避免了封閉模塊的黑盒效應.因此,在工業控制、軍事等領域的嵌入式系統中將得到廣泛的應用. & U$ W# ~$ x7 `: x% X1 x
雖然硬件上解決此問題已經在國外實現,但基于軟件解決基于VxWorks實現OpenGL三維顯示,仍然需要高手加盟研究關鍵技術突破點.vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真5 W( w5 I, c* d5 w, N1 m
北航VXWORK實驗的高博士組已經宣布失敗,停止研究.北理工仿真室李老師仍然在邀請高手參與此塊,并將成果共享參與人員.謝謝.
9 Y v# K% m: \9 v% t 如果有興趣者,XMVINI@163.COM,謝謝.bbs.vrchina.net: \5 }! n1 y) W, \! b6 d
VINI虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl( u' A* @$ b: }6 J; m7 I
全文目錄
$ I2 N; G* {+ J5 O2 Sbbs.vrchina.net文摘
. [* x+ A' U/ k9 k0 l% y虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl英文文摘
! ]( D2 w* D) W u kvrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真論文說明
# x/ C R8 }4 |! a6 D3 C8 \* I虛擬現實中國社區本人聲明
7 m& n! ^$ l: e- jvrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真第一章引言虛擬現實中國社區8 r0 Z, R" } Q1 g( _3 F8 t* I1 _
1.1論文的背景和研究的意義
' K9 ]! _* Z% N- B5 Z- @中國最活躍的虛擬現實技術交流社區1.2嵌入式實時操作系統概況
0 Y6 O1 Q N6 y) s. T6 u8 `$ J虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl1.3典型的嵌入式實時操作系統及其圖形用戶界面
, e, R/ Y% p' Q. A' J# q; z3 d( Sbbs.vrchina.net1.4現有系統分析虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl, f& ^* `0 S; L" ^
1.4論文的研究內容
0 h1 i* T7 Q( Z( x8 S6 jbbs.vrchina.net1.5論文的組織安排
8 c% ^$ W+ |4 i, s9 |bbs.vrchina.net第二章計算機圖形學、GUI和顯示驅動虛擬現實中國社區0 c5 p* I+ d+ }6 b! {
2.1計算機圖形學的發展及其應用vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真: J/ U* @7 [# {( z9 {- B6 ~
2.1.1計算機圖形學硬件的發展虛擬現實中國社區/ t0 F2 G" Y0 B! f( b4 o
2.1.2計算機圖形學軟件及算法的發展
8 h; P; s# K/ m0 h; T" B& P中國最活躍的虛擬現實技術交流社區2.1.3計算機圖形學的應用虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl9 @, J! ^3 p/ |6 i, E7 d" w& W
2.2圖形用戶界面GUI簡述中國最活躍的虛擬現實技術交流社區$ {$ |1 I' K: |: Y9 V9 w
2.2.1用戶界面的發展虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl& {! g2 f0 V! a7 `
2.2.2 GUI系統的結構模型虛擬現實中國社區/ e3 ]# m- I. `/ e6 H
2.3嵌入式實時系統對GUI的特殊要求
& Q) l3 ~$ j. b Q( T [' N% \bbs.vrchina.net2.4嵌入式實時系統VxWorks的GUI系統--WindML虛擬現實中國社區8 ? ^1 W( f( `
2.4.1 WindML的體系結構
6 F; f+ d( N$ R3 kbbs.vrchina.net2.4.2 WindML提供的顯示驅動程序
. _; y: t/ p" R5 B9 [( F& `: u/ w虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl2.5小結
& y( ?2 V- {9 p! s4 p. L: bvrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真第三章顯示驅動的體系結構虛擬現實中國社區4 N. [) E% v. _, J, {
3.1功能和性能要求虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl% r2 D' o5 Z" L$ K# z8 s$ Y8 n' B
3.1.1功能要求
- [9 V0 M% r+ ?8 a: q+ l虛擬現實中國社區3.1.2性能要求
+ J: _; y3 H& L; A# U: F5 e6 Svrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真3.2解決方案bbs.vrchina.net3 M3 W H, ]5 |" h' l
3.3驅動體系結構vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真" S$ U$ Q! B1 L% o4 N7 L
3.3.1從驅動性能的角度劃分bbs.vrchina.net% W4 ]% V4 u4 Z6 \6 H3 G- ]
3.3.2從可移植性的角度劃分bbs.vrchina.net9 Y: g+ N' _; S. \" I# z* I: } K; A
3.3.3折中的體系結構劃分
' B3 C1 K5 p3 Y9 Mbbs.vrchina.net3.4系統功能分解vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真5 s" ]$ }5 S0 W8 m; t* {
3.4.1驅動程序入口函數vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真, S6 Q# e+ ~+ ~' B/ \. R+ v( L# R
3.4.2核心數據結構
' h) N# a* ]1 J- q; vvrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真3.4.3功能模塊之間的連接關系
! z& m6 b% O7 ?& Q- ^ f" A虛擬現實中國社區3.4.4顯示驅動的接口函數
/ k, h0 p! c- y4 x$ B& z3.5小結vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真' _; B2 \7 X: ^
第四章顯示驅動的系統實現虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl8 j6 ~2 a$ S5 Y' X: @% U( B( c; T
4.1.PCI模塊的實現
6 j- j# t% F3 j! r虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl4.2 GTT功能模塊的實現中國最活躍的虛擬現實技術交流社區$ A7 K5 N. [ e( ?/ ]
4.3硬件相關功能模塊的實現虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl1 \1 c" h+ z8 O& e& v- ?% h
4.4二維繪圖功能模塊的實現
% \7 U' ]$ f8 R/ w' {7 Y中國最活躍的虛擬現實技術交流社區4.5 OpenGL功能模塊的實現 P# v" c" X! X3 T5 p- B
4.6可編程鍵盤功能模塊的實現
, [( y3 C/ U! w" Fvrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真4.7小結3 y9 F) q1 c A4 B2 Q9 u6 H
第五章系統的技術實現
( k% C2 c5 j+ M% y6 a& s虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl5.1直線繪制函數的改進vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真5 |& |( S# Y+ F8 ]# ?/ _9 X# ~
5.1.1通用的Bresenham算法虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl u6 X$ Q& _* L8 d- V
5.1.2對稱的Bresenham算法3 R: B$ a: i, y4 n
5.1.3 ELFA算法虛擬現實中國社區: S3 {- g9 ^( `* f* j5 n
5.2圓繪制函數的優化虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl/ t% n' E" v. N7 m! x9 c
5.3橢圓繪制函數的優化
- _% [: `. P* Hbbs.vrchina.net5.4雙緩存技術的實現6 n. s& }% \) R: d2 S; x) a# X6 Y7 x
5.5系統實現的特點3 x, \3 ~4 B+ j! u2 q
5.6小結中國最活躍的虛擬現實技術交流社區, o ?5 T) b. o4 O; v ~3 h
第六章系統的實現效果vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真0 W/ W" N) j: m/ X) n( v
6.1性能測試虛擬現實中國社區) K# `8 p4 Z! V8 ?8 R6 ]
6.1.1直線繪制算法
8 u" p8 m, p" E" L, @6.1.2圓繪制算法bbs.vrchina.net/ ~) |5 }+ \3 D& x
6.1.3橢圓繪制算法bbs.vrchina.net+ C7 i5 ?; V# d- Q
6.2功能測試
% ?4 l9 P9 Z9 \. l! P中國最活躍的虛擬現實技術交流社區6.2.1 WindML窗口系統應用
: {' Q4 g: W+ S5 f% ?* \/ Avrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真6.2.2 OpenGL應用
" U. U3 `9 E0 Z5 E4 |4 q6.2.3觸摸屏應用
7 H. v/ O" _/ r* u( c: _6 z& P2 K6 X虛擬現實,vrchina,bbs,社區,虛擬現實,vr,multigen,creator,vega,vp,virtools,ogre,osg,eon,opengl6.3小結vrchina 虛擬現實(Virtual Reality) 三維圖形 CG GIS 游戲仿真6 w: N# V- a+ r ]
]]>隨著以太網的穩定性、抗干擾性和帶寬問題的逐步改善，以太網正在大規模進入工業控制領域。用于工業過程控制、通信、航天器和導航系統中的網絡對可靠性及其響應故障的快速性要求極高。當前，冗余設計作為一種提高設備可靠性的有效方法，已經得到了廣泛的應用。對于網絡系統中的單個節點，常常需要對網卡進行雙冗余備份，即每個節點都采用2塊網卡(或2個網口)，中間用集線器或交換機互連，當正常通信的網卡或線路出現故障時，該節點能自動地切換到備份網卡進行通信。圖1為冗余網絡的一種典型聯接形式。
具有雙冗余網卡的節點雖然有2塊網卡，2條通道，但對于高層應用系統來說，仍呈現單網卡的特征。具體來講，2塊網卡共有1個物理地址，1個IP地址。根據TCP/IP參考模型，TCP/IP協議族可以分為應用層、傳輸層、網絡層和鏈路層4層，冗余網卡技術可以在其中各個層面中實現。
VxWorks、MUX與網卡驅動程序
嵌入式實時操作系統VxWorks的網絡協議棧與網絡設備驅動的接口有2種：一種是標準的BSD4.4Driver，它將Driver和協議緊密關聯在一起，不利于多協議的支持；另一種標準是VxWorks特有的，它將Driver和協議棧隔離開，使二者通過一個稱為MUX的薄層相連，使得網絡服務免受特定的網絡接口驅動程序的影響，達到Driver獨立于具體協議的目的，從而實現多協議的支持，三者間的關系如圖2所示。
目前版本的MUX支持2種網絡驅動程序接口模式：增強型網絡驅動程序接口( END)和網絡協議工具包(NPT)驅動程序接口，F以END型網卡驅動為例介紹如何在VxWorks5.4下的NE2000兼容網卡驅動程序中實現雙網卡冗余設計。正常情況下，協議驅動程序通過MUX層提供的NIC的句柄來提交請求，這個句柄是調用EndLoaD()獲得的；然后MUX層調用網卡驅動程序中的接口函數，實現高層協議驅動程序的請求。
在應用層實現雙冗余網卡技術的分析
在系統中對網卡進行雙冗余備份，即1塊網卡在正常工作時使用，另1塊網卡作為備份。備份用的網卡處于激活狀態。在正常通信的網卡出現故障或系統需要時，備份用的網卡能實時地、自動地切換到繼續工作。顯然，這就要求2塊網卡只能使用同1個物理地址和同1個IP地址。從應用程序的角度看，只會看見1塊網卡在工作，不關心是哪塊網卡在工作及如何切換。
理論上講，冗余網卡技術可以在OSI各層中實現，而且越在底層實現，檢測和切換的速度越快，效果應該越好。其他利用應用層實現雙冗余網卡的主要方法是在程序中發起任務，以查詢的方式不斷對當前工作網卡的工作狀態進行判斷，當判斷出當前使用的網卡處于非正常狀態的時候，將刪除當前網卡的路由，在主機列表中刪除當前主機名，并解除網卡與協議的綁定；然后進行備份網卡的配置：為備份網卡綁定協議，設置子網掩碼和IP地址。用此種方法實際測試，測試中使裝有雙網卡的主機不斷向外發送廣播報文，同時用網絡分析軟件接收。測得2個網口的切換時間平均為120ms，在切換期間有很多廣播報文丟失。可見在應用層實現雙網卡冗余備份技術，網卡切換速度慢，不利于網絡的可靠性和實時性。
在驅動程序中的實現
在VxWorks系統中，相同類型的網卡使用同一個驅動程序，網卡之間由驅動程序提供的句柄來區別。MUX調用NIC驅動程序的接口函數時，都會把網卡的句柄傳入函數中。這就為在驅動程序中實現雙網卡冗余備份提供了基礎。因此要實現網卡的雙冗余備份，最理想的辦法是在NIC驅動程序中實現。
數據結構
網卡驅動程序中最關鍵的數據結構是有關網卡特性的數據結構。每種網卡都有它自己的特性，包括它的單元號、中斷向量、I/O基址、物理地址等。
系統啟動時，在網卡驅動的裝載函數中ne2000EndLoad( )中，會為設備初始化1個數據結構，并分配一個指針指向這個結構。這時定義2個全局指針：
NE2000END-DEVICE * pDrvCtrl-0；
NE2000END-DEVICE * pDrvCtrl-1；
在網卡初始化時把這2個指針分別指向2塊網卡的數據結構，通過這2個指針的定義，在MUX調用NIC驅動程序的接口函數時，可以根據網卡的好壞或系統的需要來選擇pDrvCtrl-0或pDrvCtrl-1，以調整工作網卡。
發送和接收處理
在上層驅動程序通過MUX調用NIC驅動程序的發送函數時，會傳入網卡的句柄，指定要使用的網卡。通常情況下，驅動程序會根據該句柄向相應網卡發出指令，把報文發出去。在雙網卡冗余備份驅動程序中，根據需要來指定發送數據要使用的網卡，而不一定使用MUX指定的網卡。如先讀2塊網卡的Link信號寄存器，判斷網絡連線的通斷，再決定使用哪一塊網卡來發送數據。
在接收報文的時候，通常是在中斷中進行處理。因為以太網在物理層上的特點，2塊網卡都能收到報文，不同的是只有與高層協議綁定的網卡收到的數據才能向上傳遞。在雙網卡冗余備份驅動程序中，不是由MUX指定的網卡句柄來向上傳送數據，而是根據當前網卡的工作狀態向上層傳送數據，即使數據是從另一塊網卡上接收來的或另一塊網卡沒有和高層協議綁定。
單物理地址的處理
通常每塊網卡有1個全世界范圍內唯一的物理地址，它保存在網卡的PROM中。網卡初始化時，要從PROM中讀出物理地址，把它存放在適當的寄存器和數據結構中。
要使2塊網卡能相互備份，它們必須有相同的物理地址和IP地址。在雙網卡冗余備份驅動程序中，可以用其中1塊網卡的物理地址。方法有2種：在驅動程序初始化時只讀1塊網卡的PROM中的物理地址；或者在網卡驅動程序中的ne2000EnetAddrGet()函數中作修改，完全可以給網卡設定任意的物理地址(只要避免了同一網絡中的沖突)。
單IP地址處理
至于2塊網卡采用相同的IP地址，可以這樣實現：在安裝2塊網卡時，只讓1塊網卡有IP地址，另1塊網卡沒有IP地址。因為給網卡綁定IP地址是在IP協議所在的網絡層實現的，所以在網絡層以下切換網卡對上層來說是完全透明的。應用程序自始自終只看見1塊網卡在工作。圖3是從應用程序的角度看雙網卡備份的示意圖。
效果分析
通過對比實驗，在應用層實現雙網卡冗余備份的平均網卡切換時間是120ms，在驅動層實現雙網卡冗余備份的平均網卡切換時間是5ms，相對于在應用層或其他高層中實現，效率較高，大大縮短雙網卡的切換時間，從而降低切換時網絡通信丟包的機率。
結束語
分析了VxWorks系統的網絡結構模型，提出了在系統底層驅動中實現雙網卡冗余備份功能的設想，并進行了設計實現，同時對在驅動程序中實現與在應用層中實現2種方法進行了對比，證明了在驅動程序中不但能夠很好地實現雙網卡冗余備份功能，而且提高了以太網的實時性和可靠性，在工業以太網蓬勃發展的今天，具有一定的實用意義。
]]>
a．USB class driver初始化入口點；
b．USB class driver調用usbdlnitialize()；
Hot-Swap code調用：
c．Hot-Swap 鑒別USB主控制器的連接或斷開；
d．Usbdlnitialize()；
e．UsbdPciConfigHeaderGet()：讀USB主控制器配置頭；
f．UsbdHedAttaeh()：連接HCD，將其作為特定的主控制器。
因為熱插拔可以在任何時刻發生，所以USBD和其Client都必須被寫成可以動態識別USB設備被插入還是被拔出。當主控制器連接到系統時，USBD 自動地鑒別與其相連的設備，并通知相關的client；同樣，拔出設備時，也要通知相關設備。重要的是，USBD 的client，比如USB class driver，在client初始化時，從不設想特定的設備已經出現；而在其他時候，這些驅動隨時檢查設備是否已經連接到系統上。
4.4 總線任務
對每一個連接到USBD 的主控制器，例如插入或拔出設備，USBD都會產生一個總線任務，來監控總線事件。一般情況下，這些任務是休眠的(不消耗CPU)，只有當USB hub報告它的一個端口有變化時，它們才被喚醒。每一個USBD總線任務有VxWorks任務名：UsbdBus。
雖然HCD委托USBD來管理，但有可能HCD 親自監視主控制器事件。例如WindRiver提供了UHCI和OHCI的HCD來創造這樣的任務。對于WindRiver的UHCI模塊(usbHcdUheiLib)，后臺任務只是被周期地喚醒，目的是為了檢查超時IRP(用一個中斷來通知OHCI根hub發生改變)。
用以在USBD和USB之問進行通信的client模塊，除了調用usbdlnitialize()外，必須調用usbClientRegister()使其在USBD注冊。當一個client注冊到USBD時，USBD把每一個以后將要用到的client的數據結構定位，并跟蹤那個client的請求。
對于每一個client，在client注冊過程中，USBD還創建了一個callback任務。在成功注冊client后，USBD返回一個句柄USBD_CLIENT_HANDLE。以下對USBD的調用，將會用到這個句柄。當所有句柄都不需要時，可以調用usbdClientUnregister()來釋放每一個client的數據結構和callback任務。注意：此時所有client要求的任務都會被取消。
例如：注冊一個叫USBD_TEST的client，再注銷。
注冊：usbdClientRegister("USBD_TEST'，&usbdClientHandle)；
注銷：usbdClientUnregister(usbdClientHandle)；
4.5 client回調(callback)任務
USB操作是嚴格遵守時序的。例如為使中斷傳輸和同步傳輸正確工作．需要依靠時鐘中斷。在一個有幾個不同client出現的主系統中．總是有可能出現一個client打斷其它client傳輸事件的發生。WindRiver USBD建議用client callback任務來解決這個問題。許多USB事件可以導致一個USB client的callback任務。例如， 每當USBD 完成USB IRP后，client的IRP callback函數被激活。同樣，當USBD識別出一個動態連接事件后，會激活一個或更多的動態attach callback操作。但不是馬上激活這些回調操作， 而是安排合適的相應的USBD client的回調任務來執行callback。
一般的情況下，每一個client的callback任務處于“休眠”態(阻塞態)。每一個client的callback，繼承了usbdClientRegister()產生的VxWorks任務優先級。這確保了每一個callback按其client的任務優先級來執行，而且可以利用優先級來寫client，保證對時間要求嚴格的USB傳輸。由于每一個client有它自己的callback任務，因此在callback期間，它們有很大的靈活性決定可以做什么。例如，允許在不破壞USBD或其它USBD client性能的條件下，使callback執行代碼運行至阻塞態。
Client callback task有VxWorks任務名：tUsbdCln。
4.6 USBD內部Client
當第一次初始化USBD時，由USBD產生并注冊一個內部client，以跟蹤USB請求。
USBD 可以產生什么類型的USB請求呢? 所有USBD與USB設備的傳輸，均利用調用USBD client的形式來完成。例如， 當一個設備第一次連接到系統時．USBD用一個控制管道(control pipe) 自動地創建設備需要的所有的control pipe，即USBD client要用usbdPipeCreate()來創建一個與USB endpoint0通話的通道，然后所有USBD 內部、外部client通過這個管道來發送諸如usbdDescriptorGet()或usbdFeatureGet()等的函數，進行操作。
所以，USBD 的一個機制就是USBD 循環利用它自己的entry point，而內部chent跟蹤這些請求。
4.7 動態連接的注冊
每當一個特定類型的設備插入或拔出時，USBD client都通知上一層。利用調用usbdDynamicAttachRegister()操作，client可以指定一個callback操作，以便可以獲取這樣的通知。
USB設備類型用class，subclass，protocol來區別。標準的USB 類在usb．h 中定義為USB_CLASS_XXXX。Subclass和protocol根據class來定義， 因此這些常數根據特定的class在頭文件中定義。
有時， 一個client當利用usbdDynamicAttachRegister()進行注冊時，只對特定的class，subclass，protocol感興趣。例如，USB鍵盤類驅動usbkeyboardLib， 注冊了Human Device Interface (HID) 類，subclass 是USB_SUBCLASS_HID_ BOOT，protocol是USB_PROTOCOL_HID_BOOT _KEYBOARD。通過callback機制的響應，每當一個設備完全符合這樣的標準， 從設備上插入或拔出時，SBD便通知給keyboard class driver。而在其它情況下，client關注的范圍更廣泛了。常量USBD_NOTIFY(定義在usbdLib.h)可以替代任意的class，subclass，protocol。例如，USB打印機USB驅動，usbPrinterLib， 其class等于USB_CLASS_PRINTER，subclass 等于USB_SUBCLASS_PRINTER (usbPrinter.h)，protocol等于USBD_ NOTIFY_ ALL。典型的，當一個client只調用一次usbdDynamicAttachRegister()時，對一個client能擁有的并發通知請求數目沒有限制。
4.8 Node ID
USB設備一般用USBD_NODE_ID來區別。從其作用來看，USBD_ NODE_ ID 是USBD 用來跟蹤一個設備的句柄。它與USB設備真正的USB地址無關。這表明client并不真正關心想要了解設備是物理上與哪一個USB主控制器相連。應用為每個設備抽象定義的Node ID， 使client可以不用考慮物理設備的連接細節以及USB地址分配， 并允許USBD 在其內部對這些進行詳細的管理。
當一個client通知有一個設備連接或斷開時，USBD經常通過USBD_NODE_ID來定位設備。同樣，當一個client想通過USBD與一個特定的設備通信時，它必須向USBD傳遞那個設備的USBD_NODE_ID。
4.9 總線編號(bus enumeration)操作
usbdLib模塊提供了usbdBusCountGet()，usbdRootNodeldGet()，usbdHubPortCountGet()，usbdNodldGet()操作。它們被一起稱作總線編號操作。它們使USBD Client對連接到每一個主控制器上的設備進行編號。
這些操作對于診斷程序和測試工具很有用，例如usbTool(WindRiver提供的一個測試工具)。但是，利用它們編號之后，調用者無法知道USB的拓撲結構是否變化。因此， 建議USB class driver的開發者不要用這些操作。
4.10 數據傳輸
一旦client配置完成一個設備，就開始利用USBD提供的管道和傳輸功能與設備進行數據交換。傳輸種類(分為控制、塊、中斷和同步傳輸)用一個USB_IRP數據結構來描述。 USB_IRP 的具體描述請參見HCD_FUNC_IRP_SUBM1T。USB數據傳輸被定位于每一個設備的特定endpoint。在USBD client和特定的設備endpoint之間的通道被稱作管道(pipe)。每一個管道有以下若干特性：
USBD_NODE_ID；
設備的endpoim 數目；
數據傳輸方向；
帶寬需求；
延時需求。
為了和設備交換數據，client必須先創建管道。作為結果，USBD得到了一個USBD_PIPE_HANDLE，它被用于隨后對這個管道的所有client操作。
當client企圖創建一個管道時，USBD會檢查是否有足夠的可用帶寬。對于中斷和同步傳輸，帶寬限制是必需的。USBD不允許把90％ 以上的可用帶寬分配給中斷和同步管道；而對于控制和塊傳輸，則沒有帶寬的限制。同時，保證至少10％ 的帶寬用于控制傳輸，對塊傳輸則不保證會提供任何可用帶寬。
數據傳輸的具體過程：
(1)創建pipe ：usbdPipeCreate(usbdClient Handle，nodeld，endpoint，configvalue，interface，USB_XFRTYPE_BULK，USB_ DIR_OUT，maxPacketSize，0，0，&outPipeHandle)；
(2)定義callback：ourlrpCallback(pvoid P)；
(3)初始化IRP的數據結構；
(4)發送IRP：usbdTransfer(usbdChentHandle，outPipeHandle，＆irp)。
5 、小結
USB在VxWroks下的從下至上驅動棧分為HC、UCD、USBD和Client Module四層，每一層都相對獨立，并為上一層提供了屏蔽該層次具體特征的接口。作者所說的USB驅動，實際上主要在USBD這一層次上完成。具體分為Chent注冊，注銷，創建pipe ，配置，數據發送，以及各回調函數。當正確地依次調用時， 會根據回調函數的狀態和返回值，按正確的時序進行完整的數據傳輸。
上述設計思想構成了VxWorks下USB設備應用的基礎。作者的研究詳細地分析了VxWorks的USB協議棧，證明了該方案的可行性，同時又給出了合理的實現方法。作為實踐成果，作者已在VPN網關證書讀取系統中，利用該思想編寫的驅動，順利讀出存儲在USB設備中的設備證書和管理員證書，且運行情況良好。作者認為，文中提到的模型完全可以勝任解決USB設備在VxWorks下的應用所面臨的技術難題
]]>通用串行總線(USB)作為一種中高速的數據方式，已經很普遍地應用于外設與主機的通信中。VxWorks是當今十分流行的實時操作系統，在通信、國防、工業控制、醫療設備等嵌入式實時應用領域。很多VxWorks系統中都有USB設備，可是關于USB的驅動實現并沒有相關的資料可以參考，給實際工作帶來了難題。本文通過詳細地分析VxWorks下的USB驅動棧，具體提出了其實際應用的方法，為USB在應用VxWorks的嵌入式系統的開發掃清了技術障礙。
2、VxWorks簡介
VxWorks是WindRiver公司開發的具有工業領導地位的高性能實時操作系統(Real Tim Operation System，RTOS)內核，具有先進的網絡功能。VxWorks的開放式結構和對工業標準的支持，使得開發人員易于設計高效的嵌入式系統，并可以很小的工作量移植到其它不同的處理器上。
作為一種先進的實時操作系統，它具有以下特點：
可裁剪微內核結構。
高效的任務管理：
① 多任務，具有256個優先級。
② 具有優先級排隊和循環調度。
③ 快速的、確定性的上下文切換。
靈活的任務間通訊：
① 三種信號燈：二進制、計數、有優先級繼承特性的互斥信號燈。
② 消息隊列。
③ 套接字(Socket)。
④ 共享內存。
⑤ 信號(Signals)
微秒級的中斷處理。
支持POSIX 1003.1b實時擴展標準。
支持多種物理介質及標準的、完整的TCPIP網絡協議。
靈活的引導方式。支持從ROM、flash、本地盤(軟盤或硬盤)或網絡引導。
支持多處理器并行處理。
快速靈活的l／O系統。
支持MS-DOS和RT-11文件系統。
支持本地盤，flash，CD-ROM 的使用。
完全符合ANSI C標準。
多個系統調用。
3、 USB驅動程序的結構概述
圖1提供了一個USB主驅動棧結構的簡單概括。圖2顯示了USB主驅動棧的各模塊之間的功能聯系。
圖1 USB主驅動棧結構簡單模型
圖2 USB主驅動棧各模塊之間的功能聯系
在棧的最底部是USB主控制器(USB HC， 即USB Host Controller)， 這是主系統中控制每一個USB設備的硬件部分。
目前，市場上主要有兩大類USB主控制器，一種是支持由ime1公司最先提出的通用主控制器接口(Universal Host Controller Interface，簡稱UHCI)，另一種是支持由微軟、康柏和國家半導體公司聯合設計提出的開放主控制器接口(Open Host Controller Interface，簡稱OHCI)。硬件廠商一般根據這兩個規范設計他們的USB主控制器。
對于每一類型的主控制器都有一個與硬件獨立的USB主控制器驅動(Host Controller Driver，簡稱HCD)。WindRiver提供了兩個驅動：usbHcdUhciLib (UHCI 主控制器庫)和usbHedOheiLib (OHCI主控制器庫)。USB主驅動(USB host driver，簡稱USBD)和HCD之間的接口允許一個或超過一個的底層主控制器。而且，WindRiver的USBD能夠同時連接多個USB HCD。這樣的設計特點可以使開發者建立復雜的USB系統。
USBD是在HCD之上的與硬件獨立的模塊。USBD管理每一個與主機相連的USB設備， 向更高層次提供了可與USB設備通信的路徑。它還負責自動處理USB電力管理以及USB帶寬管理。而且，USBD還管理USB hub，Hub功能是一個驅動能否對USB正確操作的評價之一。因此WindRiver的USBD設計者要使USBD透明地處理hub的功能。這意味著，USBD 還能處理USB hub和設備的動態插拔。
USB Client模塊在USB主驅動棧的頂端。USB類驅動(USB Class Driver)是Client模塊的典型例子。USB類驅動負責管理連接到USB上的不同類型的設備； 它們依靠USBD來提供與每個設備的通信路徑。USB client模塊的其他例子就是那些利用USBD與USB設備通信的應用程序。
4、 USBD驅動詳解
這一部分將要描述USBD(USB Host Driver)的典型應用。例如初始化，client注冊，動態連接注冊，設備配置，數據傳輸，同時還探討了USBD內部設計的關鍵特性。這部分是VxWorks下USB驅動的核心。
4.1 初始化USBD：分為兩步
(1)必須至少調用一次函數usbdInitialize()。在一個給定的系統中，usbdlnifialize()初始化內部USBD數據結構，并依次調用其它USB驅動棧模塊的入口。usbdinitialize()可以在啟動時調用一次，也可以對每一個設備各調用一次。USBD 自己記錄了調用usbdInitialize()(‘+’)和usbdShutDown()(‘-’)的次數。只有大于等于1時才是真正初始化了，而等于0是關閉了。
(2)用USBD 的lisbdHedAttaeh()函數來把至少一個HCD連接到USBD上。這一過程既可以在VxWorks啟動時，也可以在運行時把HCD 連接到USBD 上去。后一種機制可以支持“熱插拔”，而不用象前一種那樣需要重新啟動。
4.2 HCD的連接(attaching)與斷開(detaching)
當HCD連接到USBD 時，調用者為usbdHedattaeh函數傳遞HCD執行入口(表HCD_EXEC_FUNC)和HCD連接參數(HCD attach parameter)。USBD用HCD FNC ATYACH 服務請求依次激活HCD的執行入口，傳遞同樣的HCD attach參數。
需要強調雖然可以改變用HCD定義的參數，但是最好不應該有所改變。對于WindRiver提供的UHCI和OHCI的HCD，HCI attach參數是一個指向結構PCI_CFG_HEADER (定義在pciConstants.h) 的指針。
該結構用UHCI和OHCI主控制器的PCI配置頭來初始化，而HCD用這個結構中的信息來定位，管理特定的主控制器。典型的，調用者用usbPeiClassFind ()和usbPciConfigHeaderGet()來得到想要的主控制器的PCI配置頭- 這兩個函數定義在usbPciLib 中(stubUsbarchPciLib.h中)。如果有UHCI或OHCI要連接到USBD，就要調用這些函數來獲得每一個主控制器的PCI_CFG_HEADER。然后利用usbdHedAttaeh來激活已鑒別出的每一個主控制器。
注意：底層BSP可能不支持USB的HCD斷開，因為當中斷向量表重新使能時，如果還應用的是過期的向量表，會導致錯誤。
4.3 啟動順序
必須在所有USBD函數前執行函數usbdInitialize()。存在以下兩種調用方式：
(1)傳統的“啟動”初始化。執行順序與其意義如下：
a．usbdInitialize()；
b．usbdPciClassFind()：定位一個USB主控制器；
c．usbdPeiConfigHeaderGet()：讀USB主控制器配置頭；
d．usbdHedAttaeh()：連接HCD，將其作為特定的主控制器：
e．調用USB class driver初始化入口點；
f．USB class driver調用usbdlnitialize()。
]]>
關鍵詞：實時操作系統VxWorks；網絡控制器；雙冗余備份
1引言
隨著網絡技術的成熟，以太網已成為各種控制系統接口互連的主要媒介。在某些特殊的應用場合，為了提高系統的可靠性和抗毀性，需采用雙冗余網絡技術。在雙冗余網絡中，每個節點都采用兩塊網卡(或單板雙卡)，中間用兩個HUB或交換機互連。當某個節點一塊網卡故障，或網線損壞，或其中一個HUB或交換機故障時，網絡仍能正常運作。
雙冗余網絡雖有兩塊網卡，兩條通道，但對于高層應用系統來說，仍呈現單網卡的特征。具體來講，每個節點的兩塊網卡只能有一個物理地址，一個IP地址，否則網絡就不能進行正常通信。
現在大多數操作系統(如Windows、Unix、Linux等)均支持多網卡，但均非冗余設計，每塊網卡都有獨立的物理地址和IP地址，以獨立的形式讓應用系統使用。根據目前海軍對高性能實時系統的要求，我們對VxWorks環境下的雙網卡的切換以及冗余備份的設計方法及要點進行介紹。
2VxWorks介紹［１］［２］［３］
VxWorks操作系統是一種具有工業領導地位的高性能嵌入式實時操作系統，是嵌入式開發環境Tornado的關鍵組成部分，它為程序員提供了良好的可靠性和卓越的實時性，因此被廣泛地應用在通信、軍事、航空、航天等高精尖技術及實時性要求極高的領域中。
就廣泛使用的Unix和Windows操作系統來說，它們都是很好的應用開發和交互式應用的操作系統平臺，然而他們并不適合于實時應用。而從另一方面考慮，以前出現的實時操作系統都沒有為應用開發和應用的非實時組件(譬如向GUI)提供很好的運行環境。而Wind River的哲學是利用兩個相互協作的操作系統來互相補充對方的不足(譬如VxWorks和Windows)，讓他們各盡所長。VxWorks為應用提供實時性，而主機被用來進行應用開發和運行非實時的應用程序。
3冗余切換
在系統的運行中設備由于硬件或軟件原因出現故障是時有發生的事。采用有效的防錯容錯機制對一個需要穩定運行的系統是必需的。冗余備份技術是對容易出錯的硬件設備進行冗余備份。當其中一個設備由于某種原因不能正常工作時，另一個設備馬上就可以代替這個設備完成相同的功能。本文只是針對網絡因素導致系統故障的情況分析對網絡適配器的一種可行的錯誤保護機制。
通常如果在某一系統中安裝兩塊網卡，它們分別有不同的物理和IP地址。當其中一塊網卡出現故障時，另一塊網卡不能實時地代替它繼續工作，這是因為它們的物理地址不同，所以它不能接受到發向前一塊網卡的數據。但在對網絡通信可靠性要求高的系統中，需要對網卡進行雙冗余備份，一塊網卡在正常工作時使用，另一塊網卡作為備份。備份用的網卡不發送或接收數據，但已經處于激活狀態。在正常通信的網卡出現故障時，備份用的網卡能實時地、自動地切換過來繼續工作。顯然，這就要求兩塊網卡只能使用同一個物理地址和同一個IP地址。從應用程序的角度看，只會看見一塊網卡在工作。應用程序不關心是哪塊網卡在工作，也不關心網卡之間是如何切換的。
在VxWorks系統中，相同類型的網卡使用同一個驅動程序，網卡之間由NDIS提供的句柄來區別。NDIS調用NIC驅動程序的接口函數時，都會把網卡的句柄傳入函數中。這就為在驅動程序中實現冗余備份提供了基礎。雙網卡驅動程序實現后與高層協議驅動程序綁定在一起，對應用程序完全透明。因此要實現網卡的雙冗余備份，最理想的辦法是在NIC驅動程序中實現。但是如果采取這樣的方式我們必須要有VxWorks下的所用網卡的驅動程序，而對于一般的用戶而言，開發這樣一個驅動程序的難度是很大的。目前也有一些研究單位完成了這些工作，但是它們要求的價格過高，軟硬件共需要15000元左右，這對于一般小型用戶是比較高的。所以我們選擇在基本不影響冗余備份效果的基礎上，在高層的用戶程序中實現這一目標。
在早期的VxWorks5．1．x中，系統是不支持多網卡的。通常，VxWorks在啟動時僅僅對引導它啟動的那塊網卡進行初始化。如果需要在某一特定的目標機上從一塊網卡換到另一塊網卡(例如從ene型換到ENP型的網卡)，我們可以通過系統提供的函數以及來實現網卡間的切換。我們所需要做的是連接所需要的網卡并刪除前一個網卡的路由。我們可以調用特定網卡的連接函數：enpattach()，enettach()等等。例如enpattach()函數為網卡連接中斷并建立enpsoftc，系統將為該網卡作相應的初始化。
enpattach (0，0xffde0000，192，3)；
／*參數依次為：網卡在系統中的單元號，enp's的共享內存地址，要連接的中斷向量，中斷級*／
需要說明的是，在VxWorks 5．1下雖然這些連接函數都有一個unitNum參數，似乎可以支持多個網卡。但其實并非這樣，在后面的敘述中我們可以看到它沒有IP MAX UNITS這個宏的定義，所以并不支持多網卡，unitNum的值一直是0，讀者們可以在源代碼中查看一下。
因為當VxWorks啟動時它將一個缺省的網絡接口加載到網絡接口表中，所以在連接到需要的網卡后需要再調用ifRouteDelete()函數以刪除連接到某一指定網卡上的路由。
這樣就完成了VxWorks5．1下多網卡之間的的切換。
就VxWorks 5．4來說，它本身是支持多網卡的。以下我們描述SBS PC104系統如何在VxWorks下支持多個網絡適配器的軟件冗余切換(以ne2000型為例)。
首先我們需要通過網卡配置程序對硬件環境中的所有網絡適配器進行IO基址和IO中斷的配置。本文假設系統中只有兩個網絡適配器，其IO基址和IO中斷號如下所述。實際系統中可能會有多個網絡適配器，其配置方法可依法類推，只要網卡的IO基址和IO中斷不會和系統中的其他設備沖突即可。
4.2 VxWorks BSP 的特點在眾多的商用嵌入式實時操作系統中，VxWorks 是使用極為廣泛的一種操作系統，它
實時性強，占用空間小，提供豐富的網絡協議，有眾多的調試手段。VxWorks 的BSP 可以按功能分為兩大部分。
1）目標系統的系統引導部分：主要是目標系統啟動時的硬件初始化，在目標系統上電后開始執行，主要是配置處理器的工作狀態，初始化系統的內存等，這部分的程序一般只在系統引導時執行，為操作系統運行提供硬件環境。
2）目標系統的設備驅動程序：主要是驅動目標系統配置的各種設備，包括字符型設備、塊存儲設備、網絡設備等，這些設備驅動程序完成對硬件的配置，操作系統通過設備驅動程序來訪問硬件，從而完成讀取數據和外界的交互等。在實際應用中，為了獲得更好的穩定性和執行效率，許多設備驅動程序會直接和應用程序捆綁在一起，而不是由操作系統來管理。
4.3 BSP 的設計與修改
WRS 提供了大量預制的，支持許多商業主版或評估板的BSP，減少了開發時間。
宏觀來看，BSP 包括兩部分：
初始化部分：CPU 初始化；目標板初始化；操作系統的初始化。
驅動程序部分：一般要包括時鐘、中斷、串口驅動。
具體來看，BSP 包括源文件、頭文件、派生文件。主要需要修改VxWorks 源碼中的以
下目錄中：
/target/config/all
幾個重要文件的功用如下：
1)bootConfig.c：引導ROM 映像的主要初始化和控制文件。
2)bootInit.c：引導ROM 映像的第二階段的初始化代碼。實現romStart 函數--romInit.s
中的romInit()函數執行完后跳轉到romStart()，執行解壓縮，代碼/數據段從rom 拷到ram。
3)usrConfig.c：VxWorks 映像的主要初始化代碼。
/target/config/comps/vxworks：實時內核基本模塊描述（cdf）文件。
/target/config/comps/src：實時內核模塊配置文件。供usrconfig.c 使用。
/target/config/bspname 該目錄下的文件就是要編寫的BSP 文件。
由于 BSP 系統開發的硬件相關性和處理器系列的多樣性，不可能有一種通用的程序或方法來解決每一種處理器的BSP 問題，所以必須具體問題具體分析，不斷實踐，才能使程序運行達到比較高的效率。
5、其它
另外，VxWorks 的多任務任務調度策略的實施也是實現嵌入式PLC 的一個關鍵點，確保高優先級任務在確定的時間內能被執行，并對外部的異步事件作出及時響應。多任務環境允許一個實時應用作為一系列獨立任務來運行，各任務有各自的線程和系統資源。VxWorks系統提供了多處理器間和任務間高效的信號燈、消息隊列、管道、網絡透明的套接字。并具有實時系統的另一關鍵特性是硬件中斷處理。為了獲得快速可靠的中斷響應，VxWorks 系統的中斷服務程序（ISR）有自己的上下文。鑒于篇幅關系，在本文不做詳細討論。
6、總結與展望
嵌入式系統已經成為歷史發展的必然，其極佳的可擴展性，對多種硬件的支持，同時能夠提高PLC 的運行速度和可靠性，并且支持多任務的控制策略，對PLC 的性能有了很大的提高。通過現場運行調試，對現場I/O 設備進行監控，達到了預期的實時性要求，實現了通過現場總線或TCP/IP 通信協議與硬件層(I/O)高速的響應目標。新型的基于VxWorks 的嵌入式實時PLC 具有很高的性能價格比，具有市場競爭優勢，有助于我國PLC 企業發展本國市場，發展自主產業的PLC。]]>
圖2 引入中級調度的進程調度的調度隊列模型
4 VxWorks 實時內核Wind 調度分析Wind 內核缺省調度機制為基于優先級的搶占式調度。采用這種機制時,系統把處理機分配給優先級最高的進程,使之執行。一旦出現了另一個優先級更高的進程時,進程調度程序剝奪當前任務的執行,將處理機分配給高優先級任務。而在相同優先級的多個任務之間,采用時間片輪
轉調度機制。采用這種機制時,當一個任務到達時,它被排在輪轉隊列的后面,等待分配給自己的間片的到來,如果在時間片內沒有結束,則再等待屬于自己的時間片的到來,直到任務完成。
4. 1 基于優先級的搶占式調度
采用基于優先級的搶占式調度,系統中每個任務都有一個介于最高0 到最低255 之間的優先級。任一時刻,系統內核一旦發現一個優先級更高的任務轉變為就緒態,內核就保存當前任務的上下文并把當前任務狀態轉換為阻塞態,同時切換到這個高優先級任務的上下文執行。如圖3 ,低優先級的task1 被中優先級的task2 搶占,task2又被高優先級的task3 搶占。
點擊看原圖
圖3 基于優先級的搶占式調度
4. 2 輪轉調度算法
采用輪轉調度算法,系統讓處于就緒態的優先級相同的一組任務依次輪流執行預先確定長度的時間片。這是一種處理機平均分配的方法。如果不使用輪轉調度算法,優先級相同的一組任務中第一個獲得處理機的任務將不會被阻塞而獨占處理機,如果沒有阻塞或其他情況發生,它不會放棄處理機的使用權。如圖4 , 相同優先級的task1 、task2 和task3 平均分配預先確定的處理機時間片。
點擊看原圖
圖4 優先級相同輪轉調度
4. 3 基于優先級的搶占式調度與輪轉調度相結合有時,基于優先級的搶占式調度可與輪轉調度相結合。當優先級相同的一組任務依次輪流平均分配處理機時,若有高優先級的任務轉變為就緒態則可搶占該組任務。直到再一次符合執行條件時,該組任務才可再次共享處理機。如圖5 ,相同優先級的task1 、task2 和task3 輪流占有處理機時,高于該組優先級的task4 搶占處理機,等task4執行結束,該組任務再次共享處理機。
]]>