|
/******************************************************************** * Filename:一線研發之聲：嵌入式C編程經驗 之 請寫可移植性高的模塊 * Author：SedateFire E-mail:SedateFire@126.com * Version：1.000 Time: 2012-01-05 * key: 嵌入式 可移植性 模塊化 依賴 ********************************************************************/ 我想你或許有這樣的經驗，你要實現的一個模塊同事已經實現了。老板發話說：你復用他的代碼啊，半天給我搞定。于是你拷過來編譯一下，幾乎是必然的，會有error有warning，一看，哇，原來依賴了這么多外部的東東。于是你開始著手修改它，如果模塊小，自然三兩下搞定。如果是個大的模塊要復用，一下彈出幾百個編譯錯誤報警，我想你邊修改心里也邊罵娘。 我靠，這個蜂鳴器控制函數為何要去判斷當前在作什么應用？！ 我靠，這么多缺失的include文件，沒有拷過來嗎？ 我靠，這個函數是什么東東，注釋明顯對不上，還判斷賦值了一堆全局變量。 我靠，這個if處理了，那else呢，哪里去了？這是什么跟什么啊。 我靠，通通刪掉干掉，自己加班偷偷重寫好了。 什么！老板在催了，我靠靠靠啊… 想必你有共鳴了...... 那么如何實現可移植性高的代碼呢，我就先寫幾點吧，有些晚了，準備睡覺了 1.擅用define。請把“裸露”的常量，用短小又信息準確的宏定義起來，務必全大寫。常量的宏定義要大寫，我會在后期關于代碼規范的主題文章分析。請把設備驅動的io，用define定義分離出來。當然，還有許多妙用，宏定義簡直是移植旅行必備佳品。待我后期再整理下思路吧。 2.抽像出平臺依賴嚴重的代碼。比如訪問一個特定mcu寄存器，開關中斷，清狗指令，中斷寫法等等。 3.如果可以，我希望你的.c檔中包含的.h檔盡可能的少。這樣在移植的時候，你只要看包含了那些.h檔，你就知道該模塊大概依賴了其他哪些模塊。我知道，大多數的程序員都喜歡在.c檔的文件頭僅有一個 #include "includes.h" 而在includes.h 中包羅萬象，這是原罪！當然，要一個蘿卜一個坑地梳理清楚.c與.h檔的關系，需要長期的工作經驗，尤其在編譯條件錯綜復雜時，操作起來的確痛苦且容易出錯，但其實這已經預示了你系統架構的某種不合理。 如果沒有足夠的經驗，那么我建議你，先在設備層的.c檔盡量包含盡可能少的.h檔。然后把設備層的.h檔放在includes.h中，給應用層使用。 3. 打造自定義庫，這個準備設專題講解。 4. 通信數據統一是大端的，內部應用代碼統一用數值說話，和大小端無關，不要亂糟糟的一片胡寫蠻纏。少用union，發送數據時統一用單字節移位發出去，接收時用移位收進來。犧牲了效率，但提高了可移植性。在51中也許不大現實，但在未來M3的大趨勢下，效率是可以犧牲的。 5.欲知后事如何，請聽下回分解.... |
