庫，這可是大殺器!!!

一個的設(shè)備程序如果完美庫化，它意味著

1.所有工程師在移植或創(chuàng)建該設(shè)備驅(qū)動時，花費的代價超小。

2.隨著使用者的增多，它飽經(jīng)考驗，不斷趨于穩(wěn)定，變?yōu)楫斨疅o愧的公共代碼。

3.庫對外的接口(函數(shù)名及其參數(shù)聲明)是不變的，當所有常用設(shè)備都實現(xiàn)庫化時，它帶來另外一個好處，應(yīng)用層的移植、創(chuàng)建、修改維護的時間耗費也會劇烈減少。應(yīng)用層的跨平臺無縫移植不是傳說，當它所依賴的所有外圍設(shè)備通通在不同平臺庫化的時候，應(yīng)用層的實現(xiàn)，就像在寫java代碼一樣。

4.庫意味這公司核心代碼的安全，庫代碼只掌握在核心工程師手里，應(yīng)用層的程序即使丟失也是無礙。

5.新人對于這些基于庫案子更快上手，一來有庫幫助文檔的說明，二來不必也無法關(guān)心底層細節(jié)，專注于應(yīng)用開發(fā)。

6.提供給客戶二次開發(fā)，你可以把硬件和外設(shè)驅(qū)動的庫交給客戶，讓其二次開發(fā)。

7.通信協(xié)議的庫化，將使通信系統(tǒng)類的產(chǎn)品更加安全，至少不會被離職的工程師破壞，比如RFID的扣款充值。

8. ......

怎么樣，它使老板心動，工程師百味雜陳。

當然，有些工程師會想到，庫可以使他脫離繁瑣的底層驅(qū)動工作，進行更高層次的工作。

?

庫的創(chuàng)建要想搞得好，有以下幾個條件

1.提供給客戶的只有.h檔和.lib檔

2.所有.h檔中沒有define，編譯條件對于.lib檔來說只是一個笑話。

3.所有.h檔中沒有extern變量，如果有，這意味著系統(tǒng)只能創(chuàng)建一個這種設(shè)備。比如蜂鳴器驅(qū)動，如果extern變量，就意味著整個系統(tǒng)只允許一個蜂鳴器。

4.完善而詳細的使用幫助文檔?？蓞⒖糼eil的hlp文檔格式。

5.簡單的使用該.h檔的demo程序讓人參考。

6.“動態(tài)鏈接”庫代碼，簡言之，沒用到的接口函數(shù)代碼不會被鏈接器搞到最終的二進制檔中。

7.還有一點，盡量的平臺無關(guān)性，它不依賴于任何寄存器或者其他和平臺相關(guān)的東西。

?

要達到上述的目的，通常會使庫有如下特點。

1.結(jié)構(gòu)體指針

2.大量的回調(diào)函數(shù)指針。

3.豐富的接口。

4.庫源碼的.c檔將按接口函數(shù)拆分成更多的.c檔，這為了實現(xiàn)鏈接時代碼空間最小化。

?

庫的缺點也是有的

1.它會使設(shè)備速度變慢一些，多了幾層間接取址的消耗。但對于32位機，對于它帶來的便利，還是可接受的。

2.它會使code空間消耗相對更大一些，但請相信我，對于一整個中大型系統(tǒng)而言，它會使代碼量不升反降，因為大系統(tǒng)中有非常多的重復冗余代碼。這方面我個人的經(jīng)驗，降的不是一般的多，簡直到了一個難以置信的程度。

?

早期的8位機，51平臺上其實不能很好地實現(xiàn)完美的庫，至少是不能實現(xiàn)一個跨機型的底層設(shè)備驅(qū)動庫。近年來隨著32位機的興起，庫漸漸地受到越來越多工程師的青睞。這里面最本質(zhì)的原因在于，51架構(gòu)的棧是靜態(tài)編譯的，局部變量和傳參的棧也是靜態(tài)的，函數(shù)無法重入。而多數(shù)的32位機都是壓棧傳參的方式。當然，51速度慢也是重要的原因之一。

?

如果有熟悉面向?qū)ο笳Z言或者linux驅(qū)動的朋友，你大概就明白一個好的庫是什么樣子的了。庫就像似面向?qū)ο笾械念悾劣趌inux底層驅(qū)動的代碼，那就是函數(shù)指針和結(jié)構(gòu)體指針的世界。C的精華在指針，在里面得到完美的詮釋。

?

當然，庫的代價也是有的

1.它會使設(shè)備速度變慢一些，多了幾層取地址的消耗。但對于32位機，對于它帶來的便利，還是可接受的。

2.它會使code消耗便大一些，但請相信我，對于一個中大型系統(tǒng)而言，它會使代碼不升反降，因為大系統(tǒng)中有非常多的重復冗余代碼。