通過上一章的學習，我想你已經掌握了如何在程序中釋放CPU了。希望能夠繼續堅持下去。一個良好的開始是成功的一半。我們今天所做的一切都是為了在單片機編程上做的更好。
在談論今天的主題之前，先說下我以前的一些經歷。在剛開始接觸到C語言程序的時候，由于學習內容所限，寫的程序都不是很大，一般也就幾百行而矣。所以所有的程序都完成在一個源文件里面。記得那時候大一參加學校里的一個電子設計大賽，調試了一個多星期，所有程序加起來大概將近1000行，長長的一個文件，從上瀏覽下來都要好半天。出了錯誤簡單的語法錯誤還好定位，其它一些錯誤，往往找半天才找的到。那個時候開始知道了模塊化編程這個東西，也嘗試著開始把程序分模塊編寫。最開始是把相同功能的一些函數(譬如1602液晶的驅動)全部寫在一個頭文件(.h)文件里面，然后需要調用的地方包含進去，但是很快發現這種方法有其局限性，很容易犯重復包含的錯誤。
而且調用起來也很不方便。很快暑假的電子設計大賽來臨了，學校對我們的單片機軟件編程進行了一些培訓。由于學校歷年來參加國賽和省賽，因此積累了一定數量的驅動模塊，那些日子，老師每天都會布置一定量的任務，讓我們用這些模塊組合起來，完成一定功能。而正是那些日子模塊化編程的培訓，使我對于模塊化編程有了更進一步的認識。并且程序規范也開始慢慢注意起來。此后的日子，無論程序的大小，均采用模塊化編程的方式去編寫。很長一段時間以來，一直有單片機愛好者在QQ上和我一起交流。有時候，他們會發過來一些有問題的程序源文件，讓我幫忙修改一下。同樣是長長的一個文件，而且命名極不規范，從頭看下來，著實是痛苦，說實話，還真不如我重新給他們寫一個更快一些，此話到不假，因為手頭積累了一定量的模塊，在完成一個新的系統時候，只需要根據上層功能需求，在底層模塊的支持下，可以很快方便的完成。而不需要從頭到尾再一磚一瓦的重新編寫。藉此，也可以看出模塊化編程的一個好處，就是可重復利用率高。下面讓我們揭開模塊化神秘面紗，一窺其真面目。
    C語言源文件 *.c
        提到C語言源文件，大家都不會陌生。因為我們平常寫的程序代碼幾乎都在這個XX.C文件里面。編譯器也是以此文件來進行編譯并生成相應的目標文件。作為模塊化編程的組成基礎，我們所要實現的所有功能的源代碼均在這個文件里。理想的模塊化應該可以看成是一個黑盒子。即我們只關心模塊提供的功能，而不管模塊內部的實現細節。好比我們買了一部手機，我們只需要會用手機提供的功能即可，不需要知曉它是如何把短信發出去的，如何響應我們按鍵的輸入，這些過程對我們用戶而言，就是是一個黑盒子。
在大規模程序開發中，一個程序由很多個模塊組成，很可能，這些模塊的編寫任務被分配到不同的人。而你在編寫這個模塊的時候很可能就需要利用到別人寫好的模塊的借口，這個時候我們關心的是，它的模塊實現了什么樣的接口，我該如何去調用，至于模塊內部是如何組織的，對于我而言，無需過多關注。而追求接口的單一性，把不需要的細節盡可能對外部屏蔽起來，正是我們所需要注意的地方。
    C語言頭文件 *.h
        談及到模塊化編程，必然會涉及到多文件編譯，也就是工程編譯。在這樣的一個系統中，往往會有多個C文件，而且每個C文件的作用不盡相同。在我們的C文件中，由于需要對外提供接口，因此必須有一些函數或者是變量提供給外部其它文件進行調用。
假設我們有一個LCD.C文件，其提供最基本的LCD的驅動函數
    LcdPutChar(char cNewValue) ; //在當前位置輸出一個字符
而在我們的另外一個文件中需要調用此函數，那么我們該如何做呢？
    頭文件的作用正是在此�？梢苑Q其為一份接口描述文件。其文件內部不應該包含任何實質性的函數代碼。我們可以把這個頭文件理解成為一份說明書，說明的內容就是我們的模塊對外提供的接口函數或者是接口變量。同時該文件也包含了一些很重要的宏定義以及一些結構體的信息，離開了這些信息，很可能就無法正常使用接口函數或者是接口變量。但是總的原則是：不該讓外界知道的信息就不應該出現在頭文件里，而外界調用模塊內接口函數或者是接口變量所必須的信息就一定要出現在頭文件里，否則，外界就無法正確的調用我們提供的接口功能。因而為了讓外部函數或者文件調用我們提供的接口功能，就必須包含我們提供的這個接口描述文件----即頭文件。同時，我們自身模塊也需要包含這份模塊頭文件(因為其包含了模塊源文件中所需要的宏定義或者是結構體)，好比我們平常所用的文件都是一式三份一樣，模塊本身也需要包含這個頭文件。
下面我們來定義這個頭文件，一般來說，頭文件的名字應該與源文件的名字保持一致，這樣我們便可以清晰的知道哪個頭文件是哪個源文件的描述。
        于是便得到了LCD.C的頭文件LCD.h 其內容如下。
        #ifndef    _LCD_H_
         #define     _LCD_H_
         extern   LcdPutChar(char cNewValue) ;
        #endif

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

              這個幾條條件編譯和宏定義是為了防止重復包含。假如有兩個不同源文件需要調用LcdPutChar(char cNewValue)這個函數，他們分別都通過#include “Lcd.h”把這個頭文件包含了進去。在第一個源文件進行編譯時候，由于沒有定義過 _LCD_H_ 因此 #ifndef _LCD_H_ 條件成立，于是定義_LCD_H_ 并將下面的聲明包含進去。在第二個文件編譯時候，由于第一個文件包含時候，已經將_LCD_H_定義過了。因此#ifndef _LCD_H_ 不成立，整個頭文件內容就沒有被包含。假設沒有這樣的條件編譯語句，那么兩個文件都包含了extern LcdPutChar(char cNewValue) ; 就會引起重復包含的錯誤。
    不得不說的typedef
          很多朋友似乎了習慣程序中利用如下語句來對數據類型進行定義
   #define uint unsigned int
    #define uchar unsigned char
    然后在定義變量的時候 直接這樣使用
uint g_nTimeCounter = 0 ;
    不可否認，這樣確實很方便，而且對于移植起來也有一定的方便性。但是考慮下面這種情況你還會 這么認為嗎？
#define PINT unsigned int * //定義unsigned int 指針類型
PINT g_npTimeCounter, g_npTimeState ;
      那么你到底是定義了兩個unsigned int 型的指針變量，還是一個指針變量，一個整形變量呢？而你的初衷又是什么呢，想定義兩個unsigned int 型的指針變量嗎？如果是這樣，那么估計過不久就會到處抓狂找錯誤了。
    慶幸的是C語言已經為我們考慮到了這一點。typedef 正是為此而生。為了給變量起一個別名我們可以用如下的語句
    typedef unsigned int    uint16 ;    //給指向無符號整形變量起一個別名 uint16
      typedef unsigned int * puint16 ; //給指向無符號整形變量指針起一個別名 puint16
    在我們定義變量時候便可以這樣定義了：

uint16    g_nTimeCounter = 0 ; //定義一個無符號的整形變量
puint16 g_npTimeCounter ;    //定義一個無符號的整形變量的指針
在我們使用51單片機的C語言編程的時候，整形變量的范圍是16位，而在基于32的微處理下的整形變量是32位。倘若我們在8位單片機下編寫的一些代碼想要移植到32位的處理器上，那么很可能我們就需要在源文件中到處修改變量的類型定義。這是一件龐大的工作，為了考慮程序的可移植性，在一開始，我們就應該養成良好的習慣，用變量的別名進行定義。
如在8位單片機的平臺下，有如下一個變量定義
    uint16    g_nTimeCounter = 0 ;
        如果移植32單片機的平臺下，想要其的范圍依舊為16位。
    可以直接修改uint16 的定義，即
    typedef unsigned short int    uint16 ;
        這樣就可以了，而不需要到源文件處處尋找并修改。

將常用的數據類型全部采用此種方法定義，形成一個頭文件，便于我們以后編程直接調用。
文件名 MacroAndConst.h
其內容如下：
#ifndef   _MACRO_AND_CONST_H_
#define   _MACRO_AND_CONST_H_

typedef    unsigned int    uint16;
typedef    unsigned int   UINT;
typedef    unsigned int   uint;
typedef    unsigned int   UINT16;
typedef    unsigned int   WORD;
typedef    unsigned int   word;
typedef      int        int16;
typedef      int        INT16;
typedef    unsigned long uint32;

typedef    unsigned long     UINT32;
typedef    unsigned long    DWORD;
typedef    unsigned long    dword;
typedef    long            int32;
typedef    long            INT32;
typedef    signed char     int8;
typedef    signed char     INT8;
typedef    unsigned char      byte;
typedef    unsigned char     BYTE;
typedef    unsigned char     uchar;
typedef    unsigned char     UINT8;
typedef    unsigned char    uint8;
typedef    unsigned char    BOOL;

#endif

至此，似乎我們對于源文件和頭文件的分工以及模塊化編程有那么一點概念了。那么讓我們趁熱打鐵，將上一章的我們編寫的LED閃爍函數進行模塊劃分并重新組織進行編譯。

在上一章中我們主要完成的功能是P0口所驅動的LED以1Hz的頻率閃爍。其中用到了定時器，以及LED驅動模塊。因而我們可以簡單的將整個工程分成三個模塊，定時器模塊，LED模塊，以及主函數
對應的文件關系如下

main.c
Timer.c --?Timer.h
Led.c      --?Led.h
在開始重新編寫我們的程序之前，先給大家講一下如何在KEIL中建立工程模板吧，這個模板是我一直沿用至今。希望能夠給大家一點啟發。
下面的內容就主要以圖片為主了。同時輔以少量文字說明。
我們以芯片AT89S52為例。