單片機學(xué)習(xí)筆記之51內(nèi)核軟件延時和串口的巧妙方法

 不知道大家學(xué)習(xí)51是怎么過來的，反正我是一路忽悠過來的?，F(xiàn)在用51來開發(fā)產(chǎn)品必須要充分用到它的內(nèi)部資源，本來主頻、資源就比不上32，不充分的利用怎么才能開發(fā)好的產(chǎn)品，那么今天我又學(xué)習(xí)到兩個小技能：延時和串口的發(fā)送中斷

情況是這樣的，在產(chǎn)品的開發(fā)中，遇到了74HC595控制數(shù)碼管，這個數(shù)字邏輯芯片用過的都知道，一位數(shù)碼管還好，要是有多位那就得不斷的刷新，為快不破，進而達到不同位顯示不同斷碼(數(shù)字)的效果。這個刷新頻率還有講究，我不知道我的理論對不對，反正我知道民用電50Hz接在燈泡上，人眼是看不出燈泡在不斷的閃爍的。那么就根據(jù)這個原理我只要保證在50Hz以上的頻率(20ms以內(nèi))及時的刷新一次顯示就行了。不過實際效果是我延時個5ms刷新一次才差不多看不到頻閃，延時是軟件的for循環(huán)延時，不太準，但是也差不多把。我也不明白為什么要到5ms才能把頻閃給消除掉。反正就按照實際效果來咯。問題來了，5ms的周期性刷新，難道MCU就單純的給這個數(shù)碼管刷新不干別的活了，這往往是不太可能的。那在調(diào)試的過程中我實現(xiàn)的方法是這樣的：

程序沒有操作系統(tǒng)，就是普通的while循環(huán)，一個循環(huán)里面有很多任務(wù)，跑一趟下來時間可能比較長，那我就多copy幾個刷新函數(shù)唄，根據(jù)任務(wù)大概的耗時放置在不同的位置。這樣下來結(jié)果還是比較明顯的，最起碼效果好很多。接著就是新問題了，當一個任務(wù)函數(shù)執(zhí)行的時間比較長的情況下，還是會出現(xiàn)頻閃，有朋友可能會想到，那就在任務(wù)函數(shù)里面放刷新顯示函數(shù)唄，的確這是一個好方法。在程序中我也用到了?？墒怯行┤蝿?wù)函數(shù)對時間要求比較嚴格，還就真的不能放在里面干擾它的底層驅(qū)動程序。重點來了，我就來記錄下我使用的兩個方法;

1、 巧妙的使用任務(wù)函數(shù)本身的延時函數(shù)

例如我在工程里面用到了DHT11溫濕度傳感器，這個傳感器(包括DS18B20)是單總線協(xié)議，對時間要求相當嚴格，我就看著底層驅(qū)動去找，找到了一個時間相對來說比較長的地方：

上圖是DHT11的時序圖，紅線標注的地方是MCU給傳感器的其實信號，這里手冊上說的是至少拉低18ms，那就在這個地方做文章，以下是我修改的代碼：

只是讓這個20ms的時間去干點別的事情，就是刷新數(shù)碼管。當然了，如果有操作系統(tǒng)的話，操作系統(tǒng)延時的調(diào)用機制會把效率進一步提高。在這里只要保證紅色方框內(nèi)的執(zhí)行時間和需要延時的時間差不多，保證能正常讀取到傳感器數(shù)據(jù)就行了，我也就估算出來的沒有實際測試時間，畢竟不方便仿真，不在公司手邊也沒有示波器。

2、串口發(fā)送中斷的使用

除了這里的延時時間修改之外還有一個地方比較棘手，那就是串口發(fā)送一幀數(shù)據(jù)，一幀數(shù)據(jù)比較長，用一個個字節(jié)等待發(fā)送完成的方式太費時間了，其中又不好加上刷新函數(shù)，怎么辦，突然想到了之前用過32的串口發(fā)送中斷。于是就查了下寄存器試用了下，還真可以。表示之前幾乎沒有用過串口的發(fā)送中斷，最多用過接收中斷。修改前和修改后的代碼如下：

注釋的就是一個個字節(jié)數(shù)序發(fā)送了，發(fā)送一個字節(jié)的函數(shù)原型如下：

修改后的串口中斷函數(shù)：

從代碼的結(jié)構(gòu)來看，大致的原理就是在沒有數(shù)據(jù)需要發(fā)送的時候串口中斷處于關(guān)閉狀態(tài)，當有數(shù)據(jù)需要發(fā)送的時候，先把數(shù)據(jù)先準備好存儲在一個數(shù)組里面，然后調(diào)用發(fā)送函數(shù)。發(fā)送函數(shù)的內(nèi)容先是把串口的中斷打開(ES=1)，清零發(fā)送完成標志位(TI = 0),把需要發(fā)送的第一個數(shù)據(jù)放進以為寄存器(SBUF = dat[0])，把模擬的發(fā)送數(shù)據(jù)地址指向發(fā)送的第二個字節(jié)(因為第一個已經(jīng)發(fā)送了)，然后就等著中斷吧。每發(fā)送完成一個字節(jié)串口就會進入中斷函數(shù)，在中斷函數(shù)里面先判斷是不是發(fā)送中斷(51內(nèi)核串口的發(fā)送中斷和接收中斷使用的是同一個中斷向量)，確保是發(fā)送中斷后先清除中斷標志，然后繼續(xù)放入需要發(fā)送的下一個數(shù)據(jù)(SBUF = WIFI_TX_DATA[TX_CNT++];)同時需要發(fā)送的數(shù)據(jù)地址后移。判斷需要發(fā)送的數(shù)據(jù)是不是全部發(fā)送完成了，發(fā)送完了那就關(guān)閉串口中斷。這樣一幀數(shù)據(jù)就完美的發(fā)送完成而且效率有所提升!

上述方法只是一個簡單的處理，偵長度是定長14個字節(jié)，如果是不定長度的偵也是可以根據(jù)實際情況修改的。還有一個問題我在這里沒有處理但是需要注意，那就是有一種情況需要考慮到，當一幀數(shù)據(jù)還沒有發(fā)送完成，新的一幀數(shù)據(jù)又需要發(fā)送。那么這種情況就需要修改下存儲的方法了。這里記上一筆，解決方式是把需要發(fā)送的數(shù)據(jù)存進一個相對大一點的數(shù)組里面，然后給這個數(shù)組分配兩個指針，分別是頭指針(p)和尾指針(q)，每次發(fā)送的時候先判斷是不是(p=q)如果是的話就證明之前的數(shù)據(jù)都發(fā)送完了，現(xiàn)在可以暢通無阻;如果不相等，那就繼續(xù)存儲并同時后移尾指針q的位置(如果溢出了那就重新回頭唄—循環(huán)數(shù)組的方法)。