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