單片機學(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ù)組的方法)。