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。注意这一点也许对读源码和规范的编程有所帮助。