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。注意這一點也許對讀源碼和規範的編程有所幫助。