VxBus And VxBus Device Driver
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 代码尺寸
在嵌入式实时操作系统市场，代码尺寸非常重要。通过结构性的设计可以减小代码尺寸，但是与此同时，减小代码尺寸可能会带来性能损失。作为一个开发人员，必须权衡你的设计以提供足够的性能，并且不会导致过大的代码尺寸。