【文章內容簡介】 器1 用作波特率產生器。其他控制部分在主函數中進行或附加在定時器的中斷服務中，但中斷服務不能處理太多操作，否則程序執(zhí)行效率很低。 程序的流程圖根據單片機的特點和系統(tǒng)各部分的運行時序，經過多次試驗，最后確定系統(tǒng)高效穩(wěn)定工作的執(zhí)行順序為：開始→初始化并啟動兩個定時器→掃描按鍵→判斷按鍵值→執(zhí)行相應功能→完畢返回至按鍵掃描，其中定時器0 中斷服務→掃描數碼管→每隔1 秒獲取傳感器數據，定時器1 中斷服務→報警判斷（低溫，高溫，低濕，高濕），重復進行此過程，即可實現(xiàn)系統(tǒng)循環(huán)工作。詳細流程圖如下圖所示：圖 31 系統(tǒng)程序流程圖 編程語言和工具的選擇以及程序文件的分配 編程語言的選擇從程序的流程圖可以看出，系統(tǒng)的程序較為復雜，如果選用執(zhí)行效率相對較高的匯編來書寫，代碼會很長，閱讀不便，并且調試也很困難。為了提高程序的可讀性和調試的便利性，選用C 語言來編寫。C 語言功能豐富，表達能力強，使用靈活方便，應用面廣，目標程序效率高，可執(zhí)行性好，而且C 語言既有高級語言的特點，也有匯編語言的特點，能直接對單片機硬件進行操作，因此使用起來十分方便。當然，C 語言和MCS51 單片機結合之后產生的C51 語言，與標準的C 語言還有一定的差別，編程的時候應該注意這些問題。除此之外，C51 的強大功能及其高效率的重要體現(xiàn)之一在于其豐富的可直接調用的庫函數，這使得程序代碼簡單，結構清晰，易于調試和維護。特別是本征庫的9 個函數，雖然少，但都非常有用，主要功能為按位循環(huán)左移或右移，位測試等。 編程工具的選擇由于單片機種類繁多，各大公司都紛紛開發(fā)了自己的編程軟件，而KEIL C51軟件是眾多單片機應用開發(fā)的優(yōu)秀軟件之一，它集編輯、編譯、仿真于一體，支持匯編、PLM 語言和C 語言的程序設計，界面友好，易學易用。此外，Keil 還支持自動添加多款單片機的編譯預處理文件，包含各類單片機的頭文件，如51 。 程序文件的分配經過上述分析，程序可用五個C 文件來存放五個功能獨立的程序模塊，另外有一個公共調用的延時函數文件和主函數文件，此外，各部分還有相應的調用頭文件來進行連接,從而實現(xiàn)了程序和硬件對應，設計模塊化，調試更為方便。具體文件分配如表：表 系統(tǒng)程序文件分配 傳感器通信程序設計由于DHT11 為單總線通信器件，為了確保單片機成功與其通信，編寫的程序必須嚴格遵守它獨特的通信協(xié)議。DHT11 的通信由兩部分組成——握手確認和數據傳送。 握手確認先來看說明書中的時序圖：圖 32 傳感器與單片機握手確認時序從圖中可以看出，傳感器和主機相互確認的過程為：未通信時，通信線保持高電平；通信開始后，主機先拉低電平至少18 毫秒，用以確保傳感器可以檢測到主機信號，之后主機再拉高電平20～40 微妙等待傳感器響應；傳感器響應后，先拉低電平40～50 微妙，予以通知主機，再拉高電平同樣的時間之后就轉入數據傳輸時序，握手通信也就結束。部分程序如下（DHT 為通信端口）：//主機與DHT11 通信開始DHT=0。//主機先拉低總線電平//調用延時函數，延時18 毫秒DHT=1。//再拉高總線電平//調用延時函數，延時40 微妙DHT=1。//拉高電平，設置總線為輸入狀態(tài)if(!DHT)//如果DHT11 輸出低電平響應，就開始接收數據{while(!DHT)。//先等待DHT 響應的低電平結束40～50 微秒while(DHT)。//再等待DHT 響應的高電平結束40～50 微妙//下面開始接收數據} 數據傳送還是先來看說明書中的時序圖。圖 33 傳感器發(fā)送數據0 時序圖 34 傳感器發(fā)送數據1 時序從圖中可以看出，在數據傳輸時，單片機只要按照時序檢測傳感器輸出的電平信號即可得到一位數據，具體要求為：無論數據是0 還是1，都以12～14 微妙的低電平開始，之后，若數據是0，則傳感器拉高電平并保持26～28 微妙；若數據是1，則傳感器拉高電平并保持116～118 微妙，如此連續(xù)進行，送出40位的數據。由于電平變化時間是以微妙計算，非常小，因此寫程序時必須要嚴格精確的控制時間，這在設計時有兩個探索過程。 （1）初期構想——定時器精確計時法晶振為12MHz 時，定時器最小定時為1 微妙，先聲明一個大小為40 的無符號字符型數組，用來存儲定時器獲得的40 個微妙數，單片機計時過程如下：圖 35 定時器計時接收數據流程 那么這樣就得到了40 個微秒時間數，再對這40 個時間數進行判斷，得到數據0 或1，從而得到溫濕度數據。 經過分析和試驗發(fā)現(xiàn)，這樣處理，單片機的數據量會比較大，而且定時器的啟動和關閉、數組的操作會額外花費很多時間，這就導致雖然定時器計得很精確，但是總的來說，并不是很精確，而且傳感器的輸出也會有一定的誤差，因此這種處理數據的方式不可取，必須尋求新的解決方案。 （2）合理方案——超時修改判斷法經過后期的不斷實驗分析，采用以下方案較為合理：圖 36 超時修改數據流程 這種方案正是利用了數據0 和1 高電平的時間不同來判斷數據，先認為是數據0 的時間（26～28 微妙），延時30 微秒越過這個時間已經足夠了，再檢測數據線是否仍然為高電平，如果是高電平就修改數據為1，并且等待數據1 剩下的高電平結束，分字節(jié)接收，因此程序簡要如下： while(!DHT)。//先出現(xiàn)低電平約1214 微秒，等待結束 //延時30 微秒，越過數據0 的高電平時間26～28 微秒 Temp_Data=0x00。//先判定數據為0 if(DHT)Temp_Data=0x01。 //如果數據0 高電平超時，則修改為數據1 while(DHT)。//等待數據1 剩下的高電平時間結束，大約11830=88 微秒//以下為接收數據處理程序 相關問題解決方案 （1）精確延時函數 毫秒延時： // 一次for 循環(huán)大約8 個機器周期,加上while 判斷和函數調用、返回，大約共1208+40= 1000us=1ms void Delay_ms(unsigned int ms ) { unsigned char Temp。 while(ms) for(Temp=0。Temp120。Temp++)。 } 10 微秒延時： //nop 一次1 個機器周期，加上函數調用和返回各2 個周期，共6+22=10us void Delay_10us() { _nop_()。 _nop_()。 _nop_()。 _nop_()。 _nop_()。 _nop_()。 } （2）采樣傳感器數據的時序安排 前期設計時，定義了兩個溫濕度全局變量，中斷使用這兩個變量來顯示數據；而主函數則采樣傳感器，修改這兩個全局變量，這種看似沒有問題的設計，在實驗時卻始終得到的是亂碼數據。結合相關資料和分析實驗結果后發(fā)現(xiàn)，這種設計的問題就在于中斷和主函數可能同時訪問了這兩個變量，并且主函數在修改全局變量時可能被中斷打斷，導致溫度或濕度數據只修改了幾位，就被迫送入數碼管顯示，顯示的當然也就是亂碼了。 數據的修改和顯示應遵從程序執(zhí)行的時序，即先修改數據再顯示或先顯示再修改數據。考慮到傳感器通信并不復雜，且最壞情況也為25 毫秒左右，因此可在中斷掃描數碼管之前或之后，定時1s 來讀取傳感器，這樣安排程序位置后，經調試，系統(tǒng)顯示數據正常。 數碼管掃描程序設計 根據硬件電路的設計，數碼管采用動態(tài)掃描方式驅動，而動態(tài)掃描方式較多，在這里選用switchcase 結構完成。 在設計硬件時，為了方便在單面板上布線，共陽極數碼管采用了變碼編碼方式，即數碼管的a～Dp 段和單片機的P00～P07 并不對應，實際安排為：表 數碼管段選信號線安排因此，10 個數字和報警設定顯示符號的編碼定義為下表方式： 數碼管顯示符號編碼 注：編碼為十六進制，其中“┣”和“┫”代表溫度和濕度，“L”和“H”代表低和高，如數碼管前兩位顯示“┣L”時，代表正在進行低溫報警值設定。 當數碼管顯示實時溫濕度數據時，前兩位顯示溫度，后兩位顯示濕度；當數碼管處于報警設定時，前兩位顯示當前設定的內容，后兩位顯示設定的值，如┫H、60，表示當前設定的為濕度上限，值為60%RH。以下為顯示實時溫濕度數據的部分程序： switch(Seg_Order) { case 0:Bit4=0。P0=Seg[Temperature /10]。break。//顯示溫度高位 case 1:Bit3=0。P0=Seg[Temperature %10]。break。//顯示溫度低位 case 2:Bit2=0。P0=Seg[Humidity /10]。break。//顯示濕度高位 case 3:Bit1=0。P0=Seg[Humidity %10]。break。//顯示濕度低位 } 顯示完畢后修改Seg_Order 的程序為： Seg_Order++。 Seg_Orderamp。=0x03。//超過四位后就返回第一位,從而顯示下一位數碼管。 報警及設置程序設計報警程序包括兩個部分，一為報警驅動信號，另為報警值調整。 報警驅動 這部分的程序較為簡單，主要是作溫濕度超限的簡單判斷并為蜂鳴器和LED引腳送出電平信號即可 如，蜂鳴器閃爍報警時信號為Buzzer=～Buzzer；紅色LED 熄滅為LED_R=1。 報警值調整 程序設計思路為，進入某個限值設定狀態(tài)時，先修改數碼管顯示狀態(tài)全局變量，使其顯示調整結果；再進入一個死循環(huán)，在循環(huán)中掃描按鍵，根據不同的按鍵執(zhí)行相應操作：結束本次調整、調整值加一或調整值減一，流程如圖。圖 37 報警值調整流程 如此進行四次，設定四個報警點，最后再把四個子函數放入一個主調函數中，即可實現(xiàn)一次完整的報警調整操作。 按鍵掃描程序設計由于系統(tǒng)只有三個按鍵，個數少，可采用ifelse 結構逐個掃描，采用經濟型的延時去抖動法，為了保證按鍵可靠被按下，實驗表明，按鍵短按一次總的時間大約為300 毫秒，因此按鍵按下抖動時間、按下時間和按鍵釋放抖動時間的延時共300 毫秒為宜，而鍵KEY1 為多功能鍵，有長按和短按之分，具體安排如下： 按鍵與鍵值分配注：多功能鍵 KEY1 可靠短按總時間定為500 毫秒，只要超過此值即認為0 是長按，依舊采用超時檢測法程序簡要如下。 if(Key1==0)//先掃描1號按鍵 { Delay_ms(500)。//延時500毫秒越過短按時長 if(Key1) { While(!Key1)。//等待按鍵釋放 Delay_ms(100)。//長按釋放去抖 return Key_M。//返回鍵值 } else { return Key_R } } else { //剩下程序為掃描2,3號鍵 } 串口發(fā)送數據程序設計由于串口發(fā)送數據時，需要用定時器1發(fā)生波特率，而且用較高的波特率發(fā)送數據時，定時器0也不能正常工作，因此在發(fā)送數據時，兩個定時器的中斷服務函數都被禁止訪問，因此需要關閉數碼管，關閉喇叭，而且還要重新初始化定時器為產生波特率，返回時再初始化為之前狀態(tài)，恢復顯示與報警。因此，串口數據發(fā)送有三個問題：波特率設置，發(fā)送格式，發(fā)送方式。 波特率設置為保證單片機和PC之間通信的實時性，再考慮定時器1的本身可以設置的大小，采用BR=2400bps的波特率比較合適。定時器采用自動重裝方式2，初值計算為：由此對單片機的串口相關內部資源設定如下：TMOD=0x20。//定時器1 工作于方式2，八位自動重裝計數SCON=0x50。//設置串口工作于方式1，10 位為一幀的異步串行通信方式PCON=0x00。//波特率不加倍TH1=0xf3。//為定時器1 寫入計數初值TL1=0xf3。TR1=1。 //啟動定時器，開始產生波特率 數據發(fā)送格式在發(fā)送數據之前，先發(fā)送數據格式為“NUM T(℃) H(%RH)”，即數據編號、溫度數據、濕度數據；再開始只發(fā)送數據，格式如“005 30 52”。為使發(fā)送的數據可以在PC 端的接收軟件“串口調試助手”上清楚明了地顯示，需要對發(fā)送的數據進行轉碼，由十六進制碼轉換為ASCII 碼，比如，為使大小為25 的溫度正常顯示，需要進行如下轉換：String2[12]=Temperature/10+0x30。//轉化為32H 的ASCII 碼，對應顯示為“2”String2[13]=Temperature%10+0x30。 發(fā)送方式由于傳感器采樣時間規(guī)定為至少1s，發(fā)送數據的間隔應大于1s，為使數據可靠轉換完成和成功發(fā)送，定為每2 秒鐘發(fā)送一次，即用定時方式發(fā)送。此外，為表征數據成功發(fā)送，在每次數據發(fā)送完成之后，單片機為黃色LED 送出一個脈沖信號，閃燈一次。串口發(fā)送數據部分程序為：//按照說明書，只要向串口緩沖器SBUF 送入數據，就啟動一次數據發(fā)送SBUF=Temp_Data。//等待發(fā)送完成，即標志位TI 為1while(!TI)。//清零標志位，為下一幀發(fā)送做準備TI=0。除了這些操作之外，在每次發(fā)送數據之前先掃描按鍵，確定是否停止發(fā)送。最后，需要說明的是，主函數的工作很簡單——