vxWorks的驱动架构

    这里想随便谈一谈vxWorks的驱动设计问题。刚接触vxworks驱动设计时，可能会想直接针对某个驱动写个驱动文件就可以直接调用读写操作了，为什么要这么麻烦搞个驱动框架vxBus。这涉及软件复用的一个思想。要说明一个问题，先从SOC设计上谈起。

    目前软件界一直在谈复用，没有人从零开始搞一整套软件。SOC设计上，也不是所有的IP，都是自己厂商设计的。比方说ALTERA CLYCLONE V这个SOC，内部的ARM采用的arm cortex a9，该IP来自于arm公司。而qspi 接口则来自于cadence公司。那么如果我们写一个QSPI的驱动，我们会这样这样写：

#define ALTERA_QSPI_BASE   0xff2xxxxx

int qspi_tranx()

{}

以上是一个简单的模型，意思是我们需要定义我们在该平台的基地址，然后写成这个文件。那个当我们写完个驱动后，是可以在该平台工作的。当某天，我们在别一SOC也遇到CADENCE这个QSPI IP时，我则需要修改基地址，再定义一个驱动文件。这样其实不是复用，N个平台要定义N个驱动文件。这种驱动与硬件平台的耦合性太大。那么如何降低耦合呢。那就是平台相关的东西不要放在驱动文件中，而是放在硬件定义的文件中，比如说设备树。可以定义硬件相关的信息，驱动做定义自己的方法。那么问题来了，驱动怎么知道它能驱动谁，而硬件又如何知道它是谁驱动的呢。这就是vxBus要解决的问题。

上面就是对硬件进行建模。目前，vxworks 6.9是放在hwconf.c文件中的，在7.0后使用设备树。

驱动也把信息告诉系统。

vxBus就是把他们结合的东西。这样当我们换个平台时候，我们就不再需要改支驱动文件，只需要改动设备描述文件就可以了。

实现如上面所以m:1:n的关系。vxbus就是上面的1。

总结一上vxbus的好处：

驱动高度可移植。

驱动格式好。

设备可动态发现。

vxbus驱动有下面几个术语要理解：

device：一个硬件可见设备，在hwconf.c中对部分设备进行建模，还有一部分是动态发现的，比如pci下面的设备。是由vxbus动态建议的设备模型。

driver:操作硬件的软件模块，需要提供vxbus接口，让vxbus为它寻找配对的设备。

instance：vxbus关联在一块的一对驱动与设备。

bus：设备与处理器间及设备与设备间通信的机制。

child：依附与bus的设备。

parent：设备依附的bus。

driver method：驱动提供的方法。vxbus驱动需要向外提供指定的方法，在hwif/methods文件夹中定义。

orphan device：没有找到驱动的设备。

驱动通过读写硬件寄存器实现对设备的操作。当一个vxbus驱动连接到一个设备后，vxbus可以将设备建模信息提供给驱动来定位寄存器空间位置。