51單片機(jī)內(nèi)核軟件延時(shí)和串口的巧妙使用方法資料下載

不知道大家學(xué)習(xí)51是怎么過來的，反正我是一路忽悠過來的?，F(xiàn)在用51來開發(fā)產(chǎn)品必須要充分用到它的內(nèi)部資源，本來主頻、資源就比不上32，不充分的利用怎么才能開發(fā)好的產(chǎn)品，那么今天我又學(xué)習(xí)到兩個(gè)小技能：延時(shí)和串口的發(fā)送中斷。 情況是這樣的，在產(chǎn)品的開發(fā)中，遇到了74HC595控制數(shù)碼管，這個(gè)數(shù)字邏輯芯片用過的都知道，一位數(shù)碼管還好，要是有多位那就得不斷的刷新，為快不破，進(jìn)而達(dá)到不同位顯示不同斷碼(數(shù)字)的效果。這個(gè)刷新頻率還有講究，我不知道我的理論對(duì)不對(duì)，反正我知道民用電50Hz接在燈泡上，人眼是看不出燈泡在不斷的閃爍的。那么就根據(jù)這個(gè)原理我只要保證在50Hz以上的頻率(20ms以內(nèi))及時(shí)的刷新一次顯示就行了。不過實(shí)際效果是我延時(shí)個(gè)5ms刷新一次才差不多看不到頻閃，延時(shí)是軟件的for循環(huán)延時(shí)，不太準(zhǔn)，但是也差不多把。我也不明白為什么要到5ms才能把頻閃給消除掉。反正就按照實(shí)際效果來咯。問題來了，5ms的周期性刷新，難道MCU就單純的給這個(gè)數(shù)碼管刷新不干別的活了，這往往是不太可能的。那在調(diào)試的過程中我實(shí)現(xiàn)的方法是這樣的： 程序沒有操作系統(tǒng)，就是普通的while循環(huán)，一個(gè)循環(huán)里面有很多任務(wù)，跑一趟下來時(shí)間可能比較長，那我就多copy幾個(gè)刷新函數(shù)唄，根據(jù)任務(wù)大概的耗時(shí)放置在不同的位置。這樣下來結(jié)果還是比較明顯的，最起碼效果好很多。接著就是新問題了，當(dāng)一個(gè)任務(wù)函數(shù)執(zhí)行的時(shí)間比較長的情況下，還是會(huì)出現(xiàn)頻閃，有朋友可能會(huì)想到，那就在任務(wù)函數(shù)里面放刷新顯示函數(shù)唄，的確這是一個(gè)好方法。在程序中我也用到了?？墒怯行┤蝿?wù)函數(shù)對(duì)時(shí)間要求比較嚴(yán)格，還就真的不能放在里面干擾它的底層驅(qū)動(dòng)程序。重點(diǎn)來了，我就來記錄下我使用的兩個(gè)方法; 1、 巧妙的使用任務(wù)函數(shù)本身的延時(shí)函數(shù) 例如我在工程里面用到了DHT11溫濕度傳感器，這個(gè)傳感器(包括DS18B20)是單總線協(xié)議，對(duì)時(shí)間要求相當(dāng)嚴(yán)格，我就看著底層驅(qū)動(dòng)去找，找到了一個(gè)時(shí)間相對(duì)來說比較長的地方： 上圖是DHT11的時(shí)序圖，紅線標(biāo)注的地方是MCU給傳感器的其實(shí)信號(hào)，這里手冊(cè)上說的是至少拉低18ms，那就在這個(gè)地方做文章，以下是我修改的代碼： 只是讓這個(gè)20ms的時(shí)間去干點(diǎn)別的事情，就是刷新數(shù)碼管。當(dāng)然了，如果有操作系統(tǒng)的話，操作系統(tǒng)延時(shí)的調(diào)用機(jī)制會(huì)把效率進(jìn)一步提高。在這里只要保證紅色方框內(nèi)的執(zhí)行時(shí)間和需要延時(shí)的時(shí)間差不多，保證能正常讀取到傳感器數(shù)據(jù)就行了，我也就估算出來的沒有實(shí)際測試時(shí)間，畢竟不方便仿真，不在公司手邊也沒有示波器。 2、串口發(fā)送中斷的使用 除了這里的延時(shí)時(shí)間修改之外還有一個(gè)地方比較棘手，那就是串口發(fā)送一幀數(shù)據(jù)，一幀數(shù)據(jù)比較長，用一個(gè)個(gè)字節(jié)等待發(fā)送完成的方式太費(fèi)時(shí)間了，其中又不好加上刷新函數(shù)，怎么辦，突然想到了之前用過32的串口發(fā)送中斷。于是就查了下寄存器試用了下，還真可以。表示之前幾乎沒有用過串口的發(fā)送中斷，最多用過接收中斷。修改前和修改后的代碼如下： 注釋的就是一個(gè)個(gè)字節(jié)數(shù)序發(fā)送了，發(fā)送一個(gè)字節(jié)的函數(shù)原型如下： 修改后的串口中斷函數(shù)： 從代碼的結(jié)構(gòu)來看，大致的原理就是在沒有數(shù)據(jù)需要發(fā)送的時(shí)候串口中斷處于關(guān)閉狀態(tài)，當(dāng)有數(shù)據(jù)需要發(fā)送的時(shí)候，先把數(shù)據(jù)先準(zhǔn)備好存儲(chǔ)在一個(gè)數(shù)組里面，然后調(diào)用發(fā)送函數(shù)。發(fā)送函數(shù)的內(nèi)容先是把串口的中斷打開(ES=1)，清零發(fā)送完成標(biāo)志位(TI = 0),把需要發(fā)送的第一個(gè)數(shù)據(jù)放進(jìn)以為寄存器(SBUF = dat[0])，把模擬的發(fā)送數(shù)據(jù)地址指向發(fā)送的第二個(gè)字節(jié)(因?yàn)榈谝粋€(gè)已經(jīng)發(fā)送了)，然后就等著中斷吧。每發(fā)送完成一個(gè)字節(jié)串口就會(huì)進(jìn)入中斷函數(shù)，在中斷函數(shù)里面先判斷是不是發(fā)送中斷(51內(nèi)核串口的發(fā)送中斷和接收中斷使用的是同一個(gè)中斷向量)，確保是發(fā)送中斷后先清除中斷標(biāo)志，然后繼續(xù)放入需要發(fā)送的下一個(gè)數(shù)據(jù)(SBUF = WIFI_TX_DATA[TX_CNT ];)同時(shí)需要發(fā)送的數(shù)據(jù)地址后移。判斷需要發(fā)送的數(shù)據(jù)是不是全部發(fā)送完成了，發(fā)送完了那就關(guān)閉串口中斷。這樣一幀數(shù)據(jù)就完美的發(fā)送完成而且效率有所提升! 上述方法只是一個(gè)簡單的處理，偵長度是定長14個(gè)字節(jié)，如果是不定長度的偵也是可以根據(jù)實(shí)際情況修改的。還有一個(gè)問題我在這里沒有處理但是需要注意，那就是有一種情況需要考慮到，當(dāng)一幀數(shù)據(jù)還沒有發(fā)送完成，新的一幀數(shù)據(jù)又需要發(fā)送。那么這種情況就需要修改下存儲(chǔ)的方法了。這里記上一筆，解決方式是把需要發(fā)送的數(shù)據(jù)存進(jìn)一個(gè)相對(duì)大一點(diǎn)的數(shù)組里面，然后給這個(gè)數(shù)組分配兩個(gè)指針，分別是頭指針(p)和尾指針(q)，每次發(fā)送的時(shí)候先判斷是不是(p=q)如果是的話就證明之前的數(shù)據(jù)都發(fā)送完了，現(xiàn)在可以暢通無阻;如果不相等，那就繼續(xù)存儲(chǔ)并同時(shí)后移尾指針q的位置(如果溢出了那就重新回頭唄—循環(huán)數(shù)組的方法)。 本文轉(zhuǎn)載自： 聲明：本文為轉(zhuǎn)載文章，轉(zhuǎn)載此文目的在于傳遞更多信息，版權(quán)歸原作者所有，如涉及侵權(quán)，請(qǐng)聯(lián)系小編郵箱： 進(jìn)行處理。 (mbbeetchina)