visionCLICK datasheet，看看这个网友能不能用上？

 1

 2

       在系统开发中，X86体系使用较多。X86体系中经常遇到的问题就是如何把PCI总线上设备的资源映射到系统中，准确的说是：把PCI总线上的物理资源映射成CPU的本地资源。有两种处理方式：动态寻找和静态指定。静态指定适合硬件完全可以确定的情况，动态寻找主要用在系统中硬件不能确定的情况。静态指定。系统中使用卡的数目已知，卡上的IO地址和内存地址固定已知，可以直接在syslib．C文件中修改。比如卡上IO空间的基地址为0x3000，大小为Oxl00， 内存空间基地址为0xee000000， 大小为0xl00000， 在syslib．C文件中找到PHYS_MEM_DESC结构，在其中加上对卡IO空间和内存空间的说明如下：
#define INIT_STATE_MASK (|VM_STATE_MASK_ WRITABLE | VM_STATE_MASK_CACHEABLE)
#define INIT_STATE (VM_STATE_VALID | VM_STATE_WRITABLE |VM_SlTATE_CACHABLE_NOT)
PHYS_MEM_DESC sysPhysMemDesc={
.....
{
(void )0xee000000， //映射到cpu端的基地址
(void )0xee000000， //卡上内存的基地址
0x1000， //卡上内存的大小为4k
INIT_STATE_MASK//卡上内存初始化状态的掩码
INIT_STATE //卡上内存的状态
}，
...
}
     这样系统在每次启动后都会把该结构中指定的IO空间和内存空间放到内存映射表中，驱动程序可以直接使用这些地址读写。
     动态寻找。系统中使用的卡的数量不确定，需要在系统启动时才可确认，这样的情况下使用动态寻找 动态寻找要确定资源的类型(IO或内存)，大小和基地址。一般把这段代码放到一个文件里，然后在syslib．c(位于$(HOME)arget/conilg/bsp_type/下)中把这段代码包含进去。在该文件中的硬件初始化函数void sysHwInit(void)调用该代码映射PCI资源的一般过程大概如下：扫描PCI总线，找到总线上的感兴趣的硬件，然后查询该硬件上的资源信息，最后培植该硬件的资源信息让VxWorks系统知道.
如何支持SELECT()
   在驱动程序中支持sdect()机制可以让任务同时等待从多个设备来的输入并设置等待某个设备输入的超时时间。在驱动程序中添加select机制很容易，selectLib库提供了这方面的支持。驱动程序要做的工作如下：首先，在设备描述结构里声明一个SEL_WAKEUP_UST结构并在设备创建函数里调用唤醒表初始化函数selWakeupListInit()来初始化该结构；当函数ioctl()被调用时(参数为FIOSELECT)，应该用节点增加函数selNodeAdd0把函数ioctl()中的参数SEL_WAKEUP_LIST加到链表SEL_WAKEUP_LIST中；然后用唤醒类型函数selWakeupType检查任务是读设备还是写设备；最后当设备准备好以后，调用唤醒函数sel_Wakeup来确定调用任务目前是否阻塞，这样可避免设备准备好而调用任务由于其它原因而挂起，或者调用selWakeupAIl()函数来唤醒所有等待该设备的任务。

    中断服务程序用来处理来自硬件的中断，是设备驱动程序的重要组成部分。为及时响应外部中断，防止中断丢失．中断服务程序应该尽量的小，只把最必要的任务放在中断服务程序里面执行。一般在系统启动，硬件设备成功初始化之后将ISR与中断向量挂上：也可以在系统启动后的任何时刻挂中断向量。调试中经常采用后一种方式。在VxWorks中有两个不同的函数可提供挂中断：intConnect和pciIntConnect。两者的区别是intConnect使用的中断向量是独占的，pcilntConnect则可在各个不同的ISR之间共享中断向量。实际上pcilntConnect内部调用了intConnect函数，在内部使用一个链表来管理多个不同的ISR。pcilntConnect要求每次进入ISR都要检查硬件的寄存器，证实中断的确是由ISR服务的硬件产生。如果硬件的寄存器表明该硬件并未产生中断，则ISR立即退出，以让挂在同一个中断向量上的其它ISR有机会检查是否有中断产生。pcilntLib．c中的代码清楚的说明了这个问题：
void pciInt (int irq ){
PCLlNT RTN *pRtn；
for (pRm = (PCI_INT_RTN*)DLL_FIRST(&pcilntList[irq])；
pRtn!=NULL；
pRtn =(PCI_INT_RTN*)DLL_NEXT(&pRtn->node))
(*pRtn->routine)(pRtn->parameter)；
}
   当PCI总线上有中断发生时，系统调用void pcilnt(int irq)函数，再由pciInt使用内部的链表来依次调用挂在该中断上的ISR。如果某个ISR不能正常退出，就会影响到其它ISR的运行。在调试时为了检查中断向量是否已经和ISR可靠的连接上，可以在命令行上或程序中直接调用pciInt来查看ISR是否被触发。在硬件确定的情况下，可以小心设计保证各个硬件使用不同的中断，这样对PCI上的设备也可直接使用intConnect来挂中断。
        需要说明的是ISR挂上中断向量的过程不是简单的在向量表中设置中断向量值。VxWorks除了设置中断向量值以外，还在与中断向量相连的ISR加上了一层薄薄的包装，包括IsR执行前保存寄存器值．设置堆栈以及IsR执行后恢复寄存器和堆栈。在中断频繁的场合，系统中中断堆栈有可能被耗尽而溢出。为了避免上述情况发生，必须修改系统的中断堆栈大小，即在config.h中加入以下代码：
#define INCLUDE_KERNEL
#define ISR_STACK_SIZE 0xl000 //表示系统中中断堆栈的大小为4k
由于中断处理程序的特殊性，中断处理程序中不能使用可能导致阻塞的函数，如printf，semTake等，具体不可使用的函数列表可以在<<VxWoks Programmer Guide>>中查到。有时候为了调试方便，希望在ISR中打印一些信息，系统提供了一个与prinf等价的函数sysLog，该函数可接受7个参数。它是非阻塞的。比较而言，prinf函数要在打印任务完成后才返回，sysLog只把打印任务放到系统的打印队列中就返回。在ISR中虽然不可以使用semTake，但可以使用semGive(互斥类型的除外)。一般使用semTake和semGive在ISR和普通程序间通信：当一个中断产生，ISR 完成必要的任务后，调用semGive通知另外一个使用semTake等待ISR信号的任务，该任务收到semGive释放的信号后，继续完成ISR中不便处理的任务。

      驱动程序的结构包括三个部分：初始化部分，函数功能部分和中断服务程序ISR。初始化部分初始化硬件，分配设备所需的资源，完成所有与系统相关的设置。如果是字符设备，首先调用iosDrvlnstall()来安装驱动程序，把中断向量和ISR挂上，然后调用iosDevAdd()来把驱动程序加到IO系统中：如果是块设备，首先把中断向量和ISR挂上，在内存中分配一个设备结构，然后初始化该结构。用户要使用该设备时，先调用设备初始化部分myInit()(一般放在sysLib．C中)，再调用设备创建函数myDevCreate()返回一个BLK_DEV结构的指针，供文件系统初始化函数如
dosFsDevInit()使用。以下为块设备的初始化示例代码：
struct MyDevice{ //自定义的设备结构
BLK_DEV dev； 必须在结构的开始
Int interrupt；设备使用的中断号
....
}
int mylnit(){ //初始化函数
MyDevicelnit()；//硬件初始化函数
MyDevice* Device =(MyDevice*)malloc(sizeof(MyDevice))；
//为设备结构分配内存
Device->dev．bd_blkRd = Read；//初始化设备结构
Device->dev_blkWrt= Write；
intConnect(imToVec(9)，my_ISR)；//连接中断向量和中断服务程序ISR
)
  ISR处理硬件中断，管理具体的硬件输入输出，同时和驱动程序的其它部分通信。ISR中第一条指令用来读APIC的中断服务寄存器，以通知CPU已经接到中断请求。
my_ISR(int va1)//中断断服务函数
sysOutByte(0xa0，0x02)；//中断响应
.....
semGive(my_sem)；//通知其它程序中断处理完毕
}
   函数功能部分完成系统指定的功能，对于字符设备，这些函数就是指定的7个标准函数；对于块设备，则是在BLK_DEV或SEQ_DEV结构中指定的功能函数。应当注意的是，系统在调用块标准函数时，传递的设备结构指针是设备结构中BLK_DEV结构的指针，由于BLK_DEV定义在设备结构的开始处，该指针实际上也就是设备结构的指针。
STATUS Read (MyDevice* pDev，int startBlk，int numBlk，char*pBuf)
{
........
SemTake(my sem，WAI1 OREVER)；//等待设备IO执行完成
)

  vxWorks中，驱动函数仅提供几个低级的IO函数来完成简单的数据输入输出操作，而由设备无关的IO系统来处理集体的高级协议和面向块设备的协议。这种结构降低了驱动程序的复杂性，使得驱动程序的编写变得更容易。
  IO系统相当于一个交换机，用于把IO请求转发给合适的驱动程序进行处理。同时，系统也提供了几个库赖支持标准的字符设备和块设备。
  字符设备的驱动程序和IO系统直接作用。字符设备调用驱动程序安装函数iosDrvlnstall()在VxW0rks中安装驱动程序。该函数有7个参数，分别指向驱动程序提供的
标准IO函数：Create，Delete，Open，Close，Write，Read和ioCtl。如果设备功能上不支持，有些函数不一定要实现，对应的参数可为NULL。IosDrvlnstall()只是为驱动程序在驱动程序表中分配了一个位置，要使用驱动程序还要调用设备安装函数iosDevAdd()。IosDevAdd把设备名和驱动程序号写到数据结构DEV_HDR中，并把它加到系统的设备列表中。
  块设备驱动程序和文件系统作用，再由文件系统与IO系统作用。块设备驱动程序不使用iosDrvlnstall()来安装驱动程序，而是通过初始化块设备描述结构BLK_DEV或顺序设备描述结构SEQ_DEV，来实现驱动程序提供给文件系统的功能。类似的，块设备驱动程序不使用iosDevAdd()来把驱动程序装入IO系统，而是使用文件系统设备初始化函数如dosFsDevInit()等来完成 实际上，文件系统把自己作为一个驱动程序装到IO系统中，并把请求转发给实际的设备驱动程序。

那位想做BSP的朋友可以参考一下

BSP是Board Support Package的缩写，该术语通常用于嵌入式领域，主要指在开发嵌入式应用时系统开发商提供的各种驱动支持库。不过该术语即使在嵌入式领域人们对它的理解也有一些不同，有的认为它就是驱动程序，有的认为它是OS的驱动程序，也有认为它就是HAL（HardWare Abstract Layer ）。实际上这几种理解都只是侧重于某个部分，再由于每个嵌入式系统提供商都根据自己的系统而提出对BSP的不同理解，因此在涉及到BSP的具体涵义时人们往往有一种似是而非的感觉。嵌入式系统提供商的龙头老大：WindRiver公司对BSP的理解偏向于是OS的驱动程序（注：从其BSP的文档中可以看出）因为嵌入式系统中的各种设备的确名目繁多，因此将BSP定位于OS的驱动的确有一定的道理。对于认为BSP就是驱动程序的人来讲，估计他们通常是接触的嵌入式系统提供商提供的某种应用解决方案的应用系统（Total Solution）。在这种开发系统中BSP完全有理由被认为是所有驱动程序，因为开发人员没有必要自己去开发驱动程序，而只是验证驱动程序在自己的系统中是否正确了事。对于开发嵌入式OS的人来讲，似乎将BSP看成是对硬件平台的抽象层(HAL)和CPU的驱动程序更恰当。因此各种理解都有一定的道理，但由于出发点不同，对BSP的理解都有失全面甚至有错误的地方.
所有的人肯定对搭积木都有一定的了解，可以用各种简单的图形积木搭建成各种物体。在程序设计的世界中人们一直希望能够利用一些可重复使用的基本程序单元来构建自己的程序或者系统。在这方面已经有了一些比较成功的案例：各种标准共享库、标准程序组件等的广泛使用。但是这些成功的案例都有一个共同的特点：都是不基于任何硬件平台的程序。当开发某个平台的、与硬件相关的程序时，往往不得不从设置某个寄存器的某个位开始编程。在嵌入式领域，这种情况更为明显。在嵌入式领域中，几乎所有的设备控制和各种协议控制都在同一个嵌入式CPU当中，非常有利于对CPU Core和设备进行抽象。如果能对CPU Core和设备的各种控制进行抽象，人们在移植OS或者开发驱动程序时就没有必要对CPU进行非常深入的了解，不必要了解某个寄存器的某个位是控制什么的，也没有必要了解怎样初始化某个控制寄存器等等。因此BSP是一种能为程序开发人员提供对硬件进行描述性操作的开发支撑库。描述性操作是指在控制硬件时只需知道要完成什么，而不需要知道如何去完成，每个操作都是一些单一的动作。例如：对于设置一个串口的波特率，只需要知道是那个串口，波特率是多少，而不需要知道要写那一个寄存器以及如何写等。在利用BSP编写Driver时，编程人员只需要了解该Driver的初始化顺序以及初始化的内容而不需要了解初始化的具体细节就能完成驱动程序。显然可以大大的提高工作效率，并且对于硬件的具体细节设置是在驱动程序中最容易出错的地方，而利用BSP支撑库则可以大大的减少出错的可能性。在BSP支撑库中除了对硬件的描述性操作部分的代码外，还包含了对目标板的初始化部分、中断管理部分以及一些简单的驱动程序程序单元。这样的BSP可以不用依赖于任何的操作系统和驱动程序，但是可以作为操作系统和驱动程序的开发支撑库，可以非常方便的移植或者开发OS与驱动程序。在最好的情况下，OS与驱动程序的移植只需要更换相应平台下的BSP支撑库就完成了移植。 （摘录于bbs.ustc.edu.cn）

    其实感觉对操作系统着一块，应该分为硬件相关于硬件无关两部分，vxworks给的许多源码也是这样分的。BSP这一块，里面的驱动部分起始也分为以上所说的两部分。硬件相关的部分是在我们移植过程中需要特别注意的。而上层所提供的软件接口都是一样的，只是有些硬件可能有某种特殊功能需要扩展。就像对一般的外设进行操作其实都可以看作对文件操作一样。所以，在vxworks那么多源码中其实有好多代码只是一个中间层，将所有的操作都适配成所提供的API。注意这一点也许对读源码和规范的编程有所帮助。