1、Introduction
本章主要介紹與VxBus和VxBus驅動程序相關的一些概念，主要包括VxBus, Instances（實例）等。
2、About VxBus
VxBus對很多朋友來說是一個全新的概念，也包括我，下面介紹一下VxBus。
術語VxBus通常情況下指的是VxWorks中對支持設備驅動程序的一些具體的基礎設施，它包括：
（1）允許設備驅動程序自動與設備匹配
（2）爲其他軟件環境（設備驅動程序之外）訪問設備功能提供機制
（3）爲VxWorks系統中的設備驅動程序的多樣性提供一些必須的支持
（4）另外VxBus有時候也指VxWorks系統的的組件集合，包括WorkBench開發平臺vxprj命令行工具，VxWorks鏡像項目等
VxBus最核心的功能是組件功能，它把每個設備驅動程序和VxBus支持的模塊都抽象成一個組件，所有的這些組件都可以單獨在Workbench中進行配置（添加和刪除）。在VxWorks6.2以前，設備驅動程序並沒有集成vxWorks項目配置中，程序員爲了添加和刪除對特定設備的支持必須具備足夠的BSP、驅動程序開發知識，當設備驅動程序被添加或者刪除時，它同樣也要求額外的功夫去管理VxWorks工程。作爲組件的集合，VxBus通過允許在workBench中選擇非常多的驅動程序和支持模塊來減少上面提到的大部分工作量，而且它並不要求程序員具備良好的BSP和驅動程序知識，也不要求增刪設備驅動時對工程的附加管理等。
VxBus在大多數發行版的BSP中是必須的組件，如果你在去掉Vxbus組件的BSP基礎上建立工程，工程一般都不會編譯通過。
3、VxBus Device Driver
對於很好的理解VxBus 設備驅動程序，有三個概念非常重要：設備，驅動程序，實例。設備概念大家都很清楚，一般就是指硬件；驅動程序是指使硬件設備能夠被操作系統訪問的可執行代碼和必須的配置信息；每一個驅動程序可以和0或者多個設備相關聯，術語實例指的是這種關聯的其中一個。這和藍牙設備配對過程是一樣的，驅動程序也要和設備進行配對，系統可以同時存在多個這樣的實例。以下是VxBus實例的示意圖：
如上圖所見，一個設備驅動程序和一個設備配對後形成一個實例。設備驅動程序中的方法構成了一種機制，它爲軟件其他部分訪問硬件設備功能提供支持。當使用驅動程序的一個方法時，發起請求的模塊能夠詢問一個或者多個實例。這種詢問可以查詢一些如何完成一個動作的信息，也可以請求驅動程序去完成某一個動作。對於上層來說，這些查詢主要包括指定實例能否支持這樣一個動作，哪些實例能夠支持這樣一個動作。下圖演示了vxworks系統中的一個子系統的device/driver/OS的通信過程。
上圖主要包括網絡棧和輔助始終兩個中間模塊，它們都嘗試與系統中的硬件進行通信。注意到，實際的系統中，一般會有多個實例和很多中間模塊，上圖只是實際系統的一個子集而已。
一個實例通過廣播它支持的驅動方法使得這些方法都能夠被整個VxWorks系統訪問。在上圖中，網絡棧使用vxbDevMethodGet( )方法來查詢系統中的每一個實例，在這個例子中，網絡棧尋找支持{muxDevConnect}( )設備方法的實例，如果該實例支持該驅動方法，則會返回驅動中實現該方法的函數的指針，如果不支持，則返回NULL。此例中，網絡棧找到一個支持該方法的網絡接口（Yukon II Network Interface）。上圖同樣演示了輔助時鐘的詢問過程，輔助時鐘尋找支持{vxbTimerFuncGet}( )驅動方法的實例，並且得知系統中的OpenPic timer instance支持該方法。上圖中的虛線表示查詢系統中的實例，實現表示得到了一個positive結果（支持）。
上圖的OpenPic Timer實例直接詢問Interrupt Controller是否支持vxbIntCtlrEnable方法，中斷控制器支持該方法，它就會對該詢問做出響應。
4 VxBus的設計目標
VxWorks系統是針對實時和嵌入式應用而設計的操作系統，這就會對設備驅動程序的設計施加了一些限制。總的來說，大部分VxWorks設備驅動程序的主要目標是滿足目標系統的實時性能要求。一般說來，如果一個設備驅動程序不允許目標系統上的應用運行在實時環境下，那麼在VxWorks系統中使用該驅動程序是個錯誤的選擇，必須考慮更換設備驅動程序，取決於具體的應用，這可能是一個硬性要求，也可能是較爲重要的考慮性因素。
對於VxWorks設備驅動程序，內存空間是另外一個限制。很多嵌入式應用的可用內存有限，再者由於請求頁面調度到磁盤並不符合實時操作的特性，內存限制就顯得非常重要。
在VxWorks環境中，標準的軟件需求同樣重要，這些需求包括驅動程序的靈活性，代碼的可維護性，代碼的可讀性以及設備驅動程序的可配置性。
4.1 性能
設備驅動程序必須以優異的性能運行以匹配實時內核的能力。以性能爲目標的設計意味着以下幾點：
（1）通常要求以合適的方式使用DMA和中斷，這要求你的routine必須嵌套在一個最優的層次（效率和可維護性），過多嵌套會導致效率低下，過少嵌套導致代碼維護性低
儘管如此，爲了保持小的代碼尺寸和使得你的驅動程序易於理解，必須在性能需求和合適使用routine之間做出權衡。
（2）讓中斷延時更小，爲了做到這點，我們必須着重關注中斷服務程序。系統的整體性能與設備驅動程序的性能同等重要。
對於一些特殊應用，犧牲上面的某些性能目標來編寫VxWorks設備驅動程序，是可以接受的。例如，爲非實時應用的系統編寫設備驅動程序，你可能在你的設備驅動程序設計中傾向於犧牲實時系統性能。但是，由於某些比如代碼重用的問題，風河公司強烈建議不要採用這種做法。實時性能和內存空間對所有的VxWorks設備驅動程序來講都是一個重要的關注點。
4.2 可維護性和可讀性
軟件工程中涉及到的大部分勞動非維護莫屬，所以任何爲了降低維護負擔的努力都是值得的。通過堅持編碼標準和撰寫描述文檔，都可以使得你的代碼容易被人理解和維護。低質量的文檔對於維護過程來講就像是沒有文檔一樣。任何新開發的設備驅動程序的文檔被除了作者之外至少一個人閱讀過。
4.3 方便配置
你的設備驅動程序不應該限制最終用戶的選擇和需求，不要對可支持的設備數量或者其他特性強加某些限制，在你的原始設備驅動程序中，也許不能夠支持所有的硬件特性或者操作模式，但是你的設計不能夠排除以後對設備某些特性的支持。
4.4 性能測試
所有的設備驅動程序都必須被測試達到預期的行爲，同樣所有的設備驅動程序也都必須被測試達到預期的性能。除了編寫設備驅動程序的功能，還要編寫測試設備驅動程序功能的例程，這主要包括在你的代碼中插入調試信息和支持基準測試，如果基準測試不可用，你必須考慮編寫一個。在不考慮設備類型的情況下，你可以考慮測試性能和預期的行爲。通常情況下，高層次的調試代碼，例如性能測試期間使用的調試代碼，必須很好的編寫，最好能被#ifdef/#endif語句包含，並留在源碼中以減少將來的調試負擔。
4.5 代碼尺寸
在嵌入式實時操作系統市場，代碼尺寸非常重要。通過結構性的設計可以減小代碼尺寸，但是與此同時，減小代碼尺寸可能會帶來性能損失。作爲一個開發人員，必須權衡你的設計以提供足夠的性能，並且不會導致過大的代碼尺寸。
作者：8度空間
來源：CSDN
原文：https://blog.csdn.net/htyang725/article/details/8535820
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！