C程序的嵌入式軟件分層，看您躺槍沒?

iconwong

      計算機系畢業的人，大概都會有一門專業課，曰為《軟件工程》，當年我不僅上了一次中文版的，后來學校搞什么中英教學，又上了一個學期的英文版的。盡管上了兩遍，但我回憶起來當年的教學內容。第一個閃念，卻是“大錘測試”，純屬是因為名字讓人印象深刻而已。
       當年的我，學習也算認真的，上了兩遍的同一門課程，也是隱隱約約找到感覺了。什么需求分析啦、瀑布開發模型啦、項目管理啦、小組成員激勵啦。當時正處大三下學期，正開始憧憬著未來的就業生活。當時那個信心爆棚啊，只想著出社會后，在軟件公司即使領著一幫牛鬼蛇神，也能夠如何如何叱咤風云來著。卻不曾想，畢業后的第一年，只是查bug查得狗跳雞飛而已。總而言之，在這樣美好的愿景下，我對這門專業課還是比較上心的。
       如今工作多年后，獨立完成的案子也不少，卻發現軟件工程里面講的這些東西，恐怕對于90%的國內公司而言，基本形同虛設。哎呀呀，偏題啦偏題啦。今日此篇，說說軟件分層的事兒。這只是軟件工程里面一個小小的分支，而它的理念也基本普及到每個軟件工程師的心中。但老實說，做得好的人還不多。(哎，這話該不該講我還猶豫挺久，說不定是自己公司太弱了，沒見世面呢，但不管怎樣，語不驚人死不休的目的是達到了）。
        老外的東西，直譯過來，說什么高內聚、低耦合，對于沒有一定構建系統經驗的大學生來說，無亦于催眠良藥。哎，再贊一個加拿大，先工作再上學，再工作再上學，隨時可進修的教育制度。
        我先用一個比喻來闡述一下軟件分層的概念，然后再來講述常見的錯誤，看看您躺槍了沒？
        好吧，直接一點，先說嵌入式軟件模塊吧，它就是一個插座，接口就是插孔。
       什么是軟件模塊呢？ 說白了，你可以理解成一個獨立的xxxx.c檔和相應的xxxx.h檔。.c檔里面的東西是經過精挑細選的，主題明確的幾個函數和一些變量等等匯集而成。.h檔呢，里面放的也是精挑細選的函數聲明，供別人調用。這個別人，軟件模塊叫做“上層”，它還說如果你是第n層，那么調用者就是第n+1層，你就是它的下層。下層不可依賴上層噢。這些函數，就是傳說中的接口。
      在這里我急不可耐的要發第一槍： 許多工程師習慣把全局變量extern出來放到.h里面，這里我要很明確的不怕得罪人地表達: 我鄙視這種不成熟的做法。這種感覺如同把插座里面的導線裸露在機殼外一般。也許有人說，為了壓縮代碼空間，為了提高執行時間。但，我還是表示更加強烈的鄙視：時空效率的提高可不是這么干的。用這種做法壓縮時空只是戰術上的，小道爾，整個框架的修改調整方為正道。還有些工程師，習慣把只有a.c檔會用到的define常量，結構體，IO定義，enum等，放到a.h里面。最郁悶的是，所有的x.c   xx.c    xxx.c都包含有一個all_include.h文檔，而a.h就包含在在這個無所不包的all_include.h里面。這感覺，這感覺，就像所有的隱私都泄露在外，家丑，還有各種卡密碼...
      回過頭來再說插座吧，插孔(接口)許多人還是整理得不錯的�？墒遣遄�還有一個非常重要的組成部分------插頭,如果是一個轉換插座的話。更常見的是一個一米五左右的220V連接線，接往另外一個“插座”。在軟件上說白了，就是你這個module.c檔里面的代碼調用了哪些外部函數，所以包含了哪些.h檔，沒有了它們，你這個module.c就無法編譯過了。我們通常關心對上層提供了什么接口，卻常常忽略自己依賴了哪些外部接口。這部分，只有在軟件移植，特別是重大的平臺移植時，才能體現出來它的重要性。
      平臺的移植，我們無法做到拔營即走，攻城略地。在51時代，我們無可奈何(源于靜態棧)，只能放任它們。但如今m3的時代來臨，我們可以將所有的這些對下一層的依賴打包起來，整一整，對下層的依賴，可以整得像插頭一般爽利。
      針對插頭這件事，我要發一個組合槍，裝的是霰彈，您可接好了。
      第二槍：你的設備驅動嵌入式程序移植起來是不是巨艱難，因為它的插頭不利索。舉例說明如下：
       1.裸露的寄存器名到處都是，比如p1^x = 0,  tcnt = xxx, 這一部分最好用define打包在一起放在文件頭。
       2.違法依賴了“上一層”的模塊內容。
        在設備初始化函數中，你是否會直接訪問系統參數，不管是用全局變量也好還是函數調用。以lcd初始化為例。
                     lcd_init(void)
                    {
                             lcd_contrast_set (sys_para.lcd_contrast);    /* 我最鄙視的全局變量風 */
                             or
                             lcd_contrast_set ( get_sys_para_lcd_contrast() ); /* 我次鄙視的層次不分明的風格 */
                     }
                     這個事兒，比較恰當的做法是。
                     lcd_init (uint_fast8_t contast)
                     {
                             /* 接下來你懂的  */
                     }
       3.沒有保持設備驅動的純潔性，這個同樣屬于層次不分明的做法。以buzzer為例。
        /*
          input:   0，長嗶~~     1，嗶      2，嗶嗶       3，嗶嗶嗶      
         */
         void  buzzer_ctrl (uint_fast8_t    para)     
          {
                  if  (“應用層”狀態 == xxx)
                  {
                            return;     
                   }
                   if (其他不相干的設備狀態  ==  xxx)
                  {
                            return;
                  }
          }                 
          這就他媽的坑爹，明明按合約說好了，我傳入參數1，就叫一聲。你說，你說，為何不叫，為何....
          為了獲取其他模塊的狀態，你不得不在buzzer.c包含無關的.h檔在里面。這就是污染，玷污了設備的純潔。
         這事兒也簡單，就是把if拉到外面判斷。你可能要說，那我要寫好多的if語句啊，浪費程序空間。哈哈，你就等著再中槍吧，希望你像紅軍一樣可以中槍不倒，繼續沖鋒，或者發表一大段的臨死表白。


存個草稿，未完待續

插孔         -----  對上層接口函數,放.h檔，基本的要有，init, read/recv,  write/send，其他的可以盡量的豐富多彩。放心，不調用就不鏈接(得懂鏈接器原理和操作方式噢)，不浪費空間。
插座座體  -----  主題明確的軟件模塊，
插頭         -----  對下層的依賴，常常被忽略的地方，導致移植困難。m3/m0時代的到來，這一切終將改變，但對于函數指針的使用得有一定的造詣。

第一槍： 許多工程師習慣把全局變量extern出來放到.h里面，這里我要很明確的不怕得罪人地表達: 我鄙視這種不成熟的做法。
第二槍： 你的設備驅動程序移植起來是不是巨艱難，因為它的插頭不利索。詳見上述的舉例說明。