--------單片機模塊化編程再探

又有幾天沒有跟大家見面啦，真真是有點極為想念呢。在上一帖中，我向大家簡單的講解了使用單片機模塊化編程給我們帶來的好處。而在現(xiàn)實工作場合，不論是“攻城獅”們還是“程序猿”們，也不論是軟件設計還是硬件設計，模塊化的概念也是大家經(jīng)?；蛘哒f是必須使用的思維了。下面針對大家的51單片機課程的學習，詳細給大家講講如何將模塊化編程這一概念運用到單片機實戰(zhàn)當中去。還是以大家非常之熟悉的流水燈為例進行講解吧。（版主下文中開啟嚴肅教學模式，上課大家不要講話，上廁所和有問題的請先舉手示意。）

（一）怎樣使用模塊化編程建立工程

下面以實現(xiàn)一個簡單的LED流水燈作為實例進行詳細講解。我們都知道，要想實現(xiàn)簡單的LED流水燈（這里使用延時函數(shù)，而不使用定時器中斷法），我們必須要有以下函數(shù)：延時函數(shù)、LED初始化函數(shù)、和LED流水燈實現(xiàn)函數(shù)，這三大類函數(shù)。那么，我們怎樣以模塊的形式來使用這些函數(shù)呢。下文中作者采用了圖文并茂的形式進行分析，這真真是極好的~

（二）LED流水燈例程

1、首先使用Keil uVision新建工程，這里我采用的是Keil uVision4。（這個軟件相信大家一定不會陌生）

2、保存創(chuàng)建的工程

3、選擇所使用的芯片

4、點擊ok后，在彈出的對話框中選擇“否”

5、新建文件，用以編輯函數(shù)和頭文件

6、將新建的這些文件分別重命名并保存

      7、將xxx.C的文件添加到工作組中。

8、當完成以上步奏之后，我們就可以進行具體的函數(shù)編寫了。對于如何編寫一個.C的C語言文件和一個.h的頭文件，下面我來具體說明。首先以主函數(shù)main.c為例。如下圖：

我們可以看到，這個流水燈的主函數(shù)main.c如果用模塊化編程的方法來實現(xiàn)的話，干凈整潔了很多。少了我們常見的相關的延時函數(shù)delay();以及對uint和uchar的宏定義。且在主函數(shù)中，直接使用了LED_init();和LED_display();這兩個函數(shù)。而我們知道，要想在主函數(shù)中使用一個子函數(shù)，必須得在主函數(shù)的前面對這幾個子函數(shù)進行聲明，可是本段代碼中并沒有出現(xiàn)相關的語句。取而代之的是，在程序段第二行，多了一句#include “LED.h”，這一句話又有什么樣的特殊功能呢？下面讓我們來研究一下LED.c和LED.h的廬山真面目。

9、LED.c和LED.h的編寫

       從LED.c這個C文件中，我們可以看出具體對LED_init();和LED_display();函數(shù)如何實現(xiàn)，在這個文件中有著具體的描述。那么問題來了~~LED.c和main.c之間是怎樣產(chǎn)生聯(lián)系的呢？換句話說，當我們在另外一個文件中需要調(diào)用其他文件當中的某個函數(shù)的時候，那么我們該如何做呢？要想搞清楚這個問題，是時候請出LED.h這位大神了。一般來講xxx.h格式的文件為頭文件，頭文件提供了程序內(nèi)函數(shù)被其他函數(shù)所調(diào)用的接口。我們也可以把他稱為一份“接口描述文件”。

頭文件的文件內(nèi)部不應該包含任何實質性的函數(shù)代碼。我們可以把這個頭文件理解成為一份說明書，說明的內(nèi)容就是我們的模塊對外提供的接口函數(shù)或者是接口變量。同時該文件也包含了一些很重要的宏定義以及一些結構體的信息，離開了這些信息，很可能就無法正常使用接口函數(shù)或者是接口變量。但是總的原則是：不該讓外界知道的信息就不應該出現(xiàn)在頭文件里，而外界調(diào)用模塊內(nèi)接口函數(shù)或者是接口變量所必須的信息就一定要出現(xiàn)在頭文件里，否則，外界就無法正確的調(diào)用我們提供的接口功能。因而為了讓外部函數(shù)或者文件調(diào)用我們提供的接口功能，就必須包含我們提供的這個接口描述文件----即頭文件。同時，我們自身模塊也需要包含這份模塊頭文件(因為其包含了模塊源文件中所需要的宏定義或者是結構體)，好比我們平常所用的文件都是一式三份一樣，模塊本身也需要包含這個頭文件。
下面我們來對LED.h這個頭文件進行說明，一般來說，頭文件的名字應該與源文件的名字保持一致，這樣我們便可以清晰的知道哪個頭文件是哪個源文件的描述。
   于是便得到了LED.c的頭文件LED.h 其內(nèi)容如下。
       #ifndef __LED_H__

       #define __LED_H__

       extern void LED_init();

extern void LED_display();

       #endif    

這與我們在源文件中定義函數(shù)時有點類似。不同的是，在其前面添加了extern 修飾符表明其是一個外部函數(shù)，可以被外部其它模塊進行調(diào)用。

10、下面我們再來看delay.c和其頭文件delay.h

我們發(fā)現(xiàn)了一點一樣的地方和一點異樣的地方（這句話讀的我也是醉了）。

一樣的是，對于頭文件來講，整體的框架似乎一點也沒有發(fā)生改變，都是下列形式。

     #ifndef __DELAY_H__

           #define __DELAY_H__

           extern  ……

……    ……

           #endif 

 這是頭文件的標準編寫格式，其中__DELAY_H__這個是頭文件的名字，必須大寫，中間的橫線不能少。一般來說，頭文件的名字應該與源文件的名字保持一致，這樣我們便可以清晰的知道哪個頭文件是哪個源文件的描述。

而異樣的是，我們在delay.c這個文件中，發(fā)現(xiàn)有”mytype.h”這么個頭文件。那么這個是神馬，又能做神馬呢？下面我們來做一個簡單的探討。

11、工程中的mytype.h是個什么樣的存在

      大家可能早就注意到了，這個mytype到底是何方神圣，在分析之前我們先來仔細的“打量一下”。

通過上圖中的一段代碼，我們能夠發(fā)現(xiàn)，這好像是對字符串定義表達符號的宏定義，沒錯，你猜對了！！細心的小伙伴又發(fā)現(xiàn)了，我們通常在函數(shù)中的用法跟這并不完全一樣啊，例如我們定義uint和uchar的時候，在程序中我們是這樣寫的：

#define uint unsigned int

#define uchar unsigned char

那么非常好，這就是兩者不一樣的地方啦。在寫的時候注意一下就好啦。另外，在對unsigned int和unsigned char等進行宏定義的時候，我們分別采用了多種字符來對其進行定義，這樣做的好處是，能夠使得mytype.h這個頭文件能夠很好的適用于不同的芯片和不同編程風格的程序員，也能夠起到方便程序進行移植的這么一個目的。由此可見，如果我們將模塊化編程很好的運用在項目開發(fā)中，能夠起到避免冗余工作量和一勞永逸的良好效果。

好了，以上幾段代碼都帶著大家一一分析完畢，現(xiàn)在我們來進行一下編譯，看看能不能一切順利。

12、對編譯輸出選項進行簡單設置

按照圖中設置完成后，點擊“OK”按鈕即可。

13、點擊編譯按鈕

    14、打開工程文件夾路徑，我們可以查找到輸出的test.hex文件

好了，大功告成了，第一彈宣布結束。。。

---------單片機模塊化編程之  探之又探

大家好！由于前幾天工作太忙的緣故，擱淺了《單片機模塊化編程（三）》的創(chuàng)作，還望大家多多包涵和理解~！其實我想說的是：“碼”字不易，且“碼”且珍惜。很享受跟大家一起學習的樂趣。好了閑話不再多說，緊接著上一帖我們往下走起！

在開始之前我們先來看一下上一帖中的工程文件夾。。額。。。

上一帖中我們說到了，我是一個有著強迫癥和密集恐懼癥的雙重“病癥”的患者，當然這不是重點，重點是看到這樣的工程文件夾。。。。我也是醉的一塌糊涂了。作為一個凡事都追求分類和條理性的“完美主義攻城獅”來說，這種混亂的狀況是堅決不能出現(xiàn)在我們的世界里的。那么如何才能將這些文件進行有秩序的分門別類呢？

首先，讓我們對文件夾中的文件進行解讀。對于文件夾中的文件，想必大家最熟悉的就是上一帖中重點講述的.c和.h兩類文件了，那么我們就任性一次，不管三七二十一，新建四個文件夾將其分別放入相應的文件夾中。如下圖：

例如文件夾“delay”所展示給大家的那樣。

      這樣一來，我們能夠看到在工程文件夾中，文件是少了一些。但是問題來了，當我們再打開工程的時候，我們發(fā)現(xiàn)，工程中的.c文件成了這個樣子：

而且再編譯的話也會出現(xiàn)問題，那么怎么解決這個問題呢？我們接下來繼續(xù)探討：

在完成了以上步驟之后，我們可以發(fā)現(xiàn)工程中的三個.c文件的狀態(tài)已經(jīng)恢復了正常。但這還沒完，由于.h的頭文件也被移動到了新的位置，因此我們需要在編譯軟件中對其路徑進行配置。配置方法如下：

之后再點擊編譯按鈕進行編譯，即可收到和之前一樣的編譯效果了?？墒浅?c和.h之外，我們在文件夾里發(fā)現(xiàn)還有其他的很多文件，這些文件比.c和.h兩類文件更亂更糟心。那么他們又是些什么文件呢？又該怎么處理呢？萊斯夠昂go on！

這些文件絕大部分都是編譯的過程中，產(chǎn)生的中間文件。為了更好的區(qū)分這些文件，我們采用以下辦法。請大家讀圖：

      做完了以上步奏，我們發(fā)現(xiàn)雖然根文件夾下干凈了不少，可是還有一些.lst和.bak等后綴的文件存在，這些文件又是哪兒來的呢？我們再來繼續(xù)分析。請大家繼續(xù)讀圖：

在完成了以上兩個步奏之后，我們發(fā)現(xiàn)，我們的文件夾已經(jīng)相對干凈且有條理了。在完成了以上的步奏之后，我們也可以從中看出在編譯過程中生成的文件主要有.obj、.lst、.hex以及其他文件，其中delay.obj、LED.obj等obj類型的文件是在對工程中的C文件編譯時產(chǎn)生的二進制文件，大家可以不用理會；而delay.lst、LED.lst等lst類型的文件是在編譯過程中生成的列表文件，些文件均屬于中間文件，我們在學習過程中可以暫時將其忽略，不再做進一步的細究。我們要注意的文件是生成的 .hex格式的文件，這個文件是我們要用的著的文件，也是我們最終要往單片機內(nèi)部燒寫的文件。

而對于上面圖中的.bak文件來講，他們是在工程中所產(chǎn)生的備份文件，是可以刪除的，在這里，為了更加美觀我將其刪除，同樣不會影響再次編譯的效果。好了，現(xiàn)在我們將沒有進行處理的根文件夾與“分門別類”過的文件夾進行一下對比。下面是見證奇跡的時刻。。。。。請看下圖：

看完了之后我的強迫癥和密集恐懼癥被自己的“機智”治愈了，這真是太瘋狂啦??！原諒我的自戀，點評一下這樣的好處吧。

當我們對函數(shù)文件進行分類之后，我們發(fā)現(xiàn)，當再需要建立一個新的工程的時候，又需要用到delay.c和delay.h這兩個文件的時候，我們就能直接將這個“delay”文件夾拷貝到新的工程文件根目錄下啦！不需要重新編寫，僅僅需要按照上文的方法再次配置一下路徑就好了！這真的是一勞永逸，坐享其成的好方法！！

好啦，文章寫到這里，想必大家能夠較好的認識模塊化編程的思想了！這回第一彈真真的要結束了。我也真真的要和大家說再見了?。。≌驹诮處煹慕嵌?，還是希望大家多動手勤練習，爭取學到有用的知識早日成才；站在創(chuàng)客的角度，樓主我在此拋磚引玉獻丑啦，也希望各路大神能夠將自己寶貴的經(jīng)驗分享出來，共同照亮我們大家學習的道路！謝謝大家~第一彈宣告結束，么~么~~噠~~~?。?！