?

　　單片機按鍵去抖動程序_單片機按鍵消抖程序匯編

　　通常按鍵所用的開關都是機械彈性開關，當機械觸點斷開、閉合時，由于機械觸點的彈性作用，一個按鍵開關在閉合時不會馬上就穩定的接通，在斷開時也不會一下子徹底斷開，而是在閉合和斷開的瞬間伴隨了一連串的抖動，如圖 8-10 所示。

　　圖 8-10 按鍵抖動狀態圖

　　按鍵穩定閉合時間長短是由操作人員決定的，通常都會在 100ms 以上，刻意快速按的話能達到 40-50ms 左右，很難再低了。抖動時間是由按鍵的機械特性決定的，一般都會在 10ms以內，為了確保程序對按鍵的一次閉合或者一次斷開只響應一次，必須進行按鍵的消抖處理。當檢測到按鍵狀態變化時，不是立即去響應動作，而是先等待閉合或斷開穩定后再進行處理。按鍵消抖可分為硬件消抖和軟件消抖。

　　硬件消抖就是在按鍵上并聯一個電容，如圖 8-11 所示，利用電容的充放電特性來對抖動過程中產生的電壓毛刺進行平滑處理，從而實現消抖。但實際應用中，這種方式的效果往往不是很好，而且還增加了成本和電路復雜度，所以實際中使用的并不多。

　　圖 8-11 硬件電容消抖

　　在絕大多數情況下，我們是用軟件即程序來實現消抖的。最簡單的消抖原理，就是當檢測到按鍵狀態變化后，先等待一個 10ms 左右的延時時間，讓抖動消失后再進行一次按鍵狀態檢測，如果與剛才檢測到的狀態相同，就可以確認按鍵已經穩定的動作了。將上一個的程序稍加改動，得到新的帶消抖功能的程序如下。

　　#include

　　sbit ADDR0 = P1^0;

　　sbit ADDR1 = P1^1;

　　sbit ADDR2 = P1^2;

　　sbit ADDR3 = P1^3;

　　sbit ENLED = P1^4;

　　sbit KEY1 = P2^4;

　　sbit KEY2 = P2^5;

　　sbit KEY3 = P2^6;

　　sbit KEY4 = P2^7;

　　unsigned char code LedChar［］ = { //數碼管顯示字符轉換表

　　0xC0， 0xF9， 0xA4， 0xB0， 0x99， 0x92， 0x82， 0xF8，

　　0x80， 0x90， 0x88， 0x83， 0xC6， 0xA1， 0x86， 0x8E

　　};

　　void delay（）;

　　void main（）{

　　bit keybuf = 1; //按鍵值暫存，臨時保存按鍵的掃描值

　　bit backup = 1; //按鍵值備份，保存前一次的掃描值

　　unsigned char cnt = 0; //按鍵計數，記錄按鍵按下的次數

　　ENLED = 0; //選擇數碼管 DS1 進行顯示

　　ADDR3 = 1;

　　ADDR2 = 0;

　　ADDR1 = 0;

　　ADDR0 = 0;

　　P2 = 0xF7; //P2.3 置 0，即 KeyOut1 輸出低電平

　　P0 = LedChar［cnt］; //顯示按鍵次數初值

　　while （1）{

　　keybuf = KEY4; //把當前掃描值暫存

　　if （keybuf ！= backup）{ //當前值與前次值不相等說明此時按鍵有動作

　　delay（）; //延時大約 10ms

　　if （keybuf == KEY4）{ //判斷掃描值有沒有發生改變，即按鍵抖動

　　if （backup == 0）{ //如果前次值為 0，則說明當前是彈起動作

　　cnt++; //按鍵次數+1

　　//只用 1 個數碼管顯示，所以加到 10 就清零重新開始

　　if （cnt 》= 10）{

　　cnt = 0;

　　}

　　P0 = LedChar［cnt］; //計數值顯示到數碼管上

　　}

　　backup = keybuf; //更新備份為當前值，以備進行下次比較

　　}

　　}

　　}

　　}

　　/* 軟件延時函數，延時約 10ms */

　　void delay（）{

　　unsigned int i = 1000;

　　while （i--）;

　　}大家把這個程序下載到板子上再進行試驗試試，按一下按鍵而數字加了多次的問題是不是就這樣解決了？把問題解決掉的感覺是不是很爽呢？

　　這個程序用了一個簡單的算法實現了按鍵的消抖。作為這種很簡單的演示程序，我們可以這樣來寫，但是實際做項目開發的時候，程序量往往很大，各種狀態值也很多， while（1）這個主循環要不停的掃描各種狀態值是否有發生變化，及時的進行任務調度，如果程序中間加了這種 delay 延時操作后，很可能某一事件發生了，但是我們程序還在進行 delay 延時操作中，當這個事件發生完了，程序還在 delay 操作中，當我們 delay 完事再去檢查的時候，已經晚了，已經檢測不到那個事件了。為了避免這種情況的發生，我們要盡量縮短 while（1）循環一次所用的時間，而需要進行長時間延時的操作，必須想其它的辦法來處理。

　　那么消抖操作所需要的延時該怎么處理呢？其實除了這種簡單的延時，我們還有更優異的方法來處理按鍵抖動問題。舉個例子：我們啟用一個定時中斷，每 2ms 進一次中斷，掃描一次按鍵狀態并且存儲起來，連續掃描 8 次后，看看這連續 8 次的按鍵狀態是否是一致的。8 次按鍵的時間大概是 16ms，這 16ms 內如果按鍵狀態一直保持一致，那就可以確定現在按鍵處于穩定的階段，而非處于抖動的階段，如圖 8-12。

　　圖 8-12 按鍵連續掃描判斷

　　假如左邊時間是起始 0 時刻，每經過 2ms 左移一次，每移動一次，判斷當前連續的 8 次按鍵狀態是不是全 1 或者全 0，如果是全 1 則判定為彈起，如果是全 0 則判定為按下，如果0 和 1 交錯，就認為是抖動，不做任何判定。想一下，這樣是不是比簡單的延時更加可靠？

　　利用這種方法，就可以避免通過延時消抖占用單片機執行時間，而是轉化成了一種按鍵狀態判定而非按鍵過程判定，我們只對當前按鍵的連續 16ms 的 8 次狀態進行判斷，而不再關心它在這 16ms 內都做了什么事情，那么下面就按照這種思路用程序實現出來，同樣只以K4 為例。

　　#include

　　sbit ADDR0 = P1^0;

　　sbit ADDR1 = P1^1;

　　sbit ADDR2 = P1^2;

　　sbit ADDR3 = P1^3;

　　sbit ENLED = P1^4;

　　sbit KEY1 = P2^4;

　　sbit KEY2 = P2^5;

　　sbit KEY3 = P2^6;

　　sbit KEY4 = P2^7;

　　unsigned char code LedChar［］ = { //數碼管顯示字符轉換表

　　0xC0， 0xF9， 0xA4， 0xB0， 0x99， 0x92， 0x82， 0xF8，

　　0x80， 0x90， 0x88， 0x83， 0xC6， 0xA1， 0x86， 0x8E

　　};

　　bit KeySta = 1; //當前按鍵狀態

　　void main（）{

　　bit backup = 1; //按鍵值備份，保存前一次的掃描值

　　unsigned char cnt = 0; //按鍵計數，記錄按鍵按下的次數

　　EA = 1; //使能總中斷

　　ENLED = 0; //選擇數碼管 DS1 進行顯示

　　ADDR3 = 1;

　　ADDR2 = 0;

　　ADDR1 = 0;

　　ADDR0 = 0;

　　TMOD = 0x01; //設置 T0 為模式 1

　　TH0 = 0xF8; //為 T0 賦初值 0xF8CD，定時 2ms

　　TL0 = 0xCD;

　　ET0 = 1; //使能 T0 中斷

　　TR0 = 1; //啟動 T0

　　P2 = 0xF7; //P2.3 置 0，即 KeyOut1 輸出低電平

　　P0 = LedChar［cnt］; //顯示按鍵次數初值

　　while （1）{

　　if （KeySta ！= backup）{ //當前值與前次值不相等說明此時按鍵有動作

　　if （backup == 0）{ //如果前次值為 0，則說明當前是彈起動作

　　cnt++; //按鍵次數+1

　　if （cnt 》= 10）{ //只用 1 個數碼管顯示，所以加到 10 就清零重新開始

　　cnt = 0;

　　}

　　P0 = LedChar［cnt］; //計數值顯示到數碼管上

　　}

　　//更新備份為當前值，以備進行下次比較

　　backup = KeySta;

　　}

　　}

　　}

　　/* T0 中斷服務函數，用于按鍵狀態的掃描并消抖 */

　　void InterruptTimer0（） interrupt 1{

　　//掃描緩沖區，保存一段時間內的掃描值

　　static unsigned char keybuf = 0xFF;

　　TH0 = 0xF8; //重新加載初值

　　TL0 = 0xCD;

　　//緩沖區左移一位，并將當前掃描值移入最低位

　　這個算法是我們在實際工程中經常使用按鍵所總結的一個比較好的方法，介紹給大家，今后都可以用這種方法消抖了。當然，按鍵消抖也還有其它的方法，程序實現更是多種多樣，大家也可以再多考慮下其它的算法，拓展下思路。

　　單片機高阻態是什么意思

　　在一個系統中或在一個整體中，我們往往定義了一些參考點，就像我們常常說的海平面，在單片中也是如此，我們無論說是高電平還是低電平都是相對來說的。

　　在51單片機，沒有連接上拉電阻的P0口相比有上拉電阻的P1口在I/O口引腳和電源之間相連是通過一對推挽狀態的FET來實現的，51具體結構如下圖。

　　51結構圖

　　組成推挽結構，從理論上講是可以通過調配管子的參數輕松實現輸出大電流，提高帶載能力，兩個管子根據通斷狀態有四種不同的組合，上下管導通相當于把電源短路了，這種情況下在實際電路中絕對不能出現，從邏輯電路上來講，上管開-下管關開時IO與VCC直接相連，IO輸出低電平0，這種結構下如果沒有外接上拉電阻，輸出0就是開漏狀態（低阻態），因為I/O引腳是通過一個管子接地的，并不是使用導線直接連接，而一般的MOS在導通狀態也會有mΩ極的導通電阻。

　　排阻

　　無論是低阻態還是高阻態都是相對來說的，把下管子置于截止狀態就可以把GND和I/O口隔離達到開路的狀態，這時候推挽一對管子是截止狀態，忽略讀取邏輯的話I/O口引腳相當于與單片機內部電路開路，考慮到實際MOS截止時會有少許漏電流，就稱作“高阻態”

　　由于管子PN節帶來的結電容的影響，有的資料也會稱作“浮空”，通過I/O口給電容充電需要一定的時間，那么IO引腳處的對地的真實電壓和水面浮標隨波飄動類似了，電壓的大小不僅與外界輸入有關還和時間有關，在高頻情況下這種現象是不能忽略的。

　　單片機程序死機，跑飛了可以從以下幾個方面查找原因：

　　1、意外中斷。是否打開了某個中斷，但是沒有響應和清除中端標志，導致程序一直進入中斷，造成死機假象;

　　2、中斷變量處理不妥。若定義某些會在中斷中修改的全局變量，這時要注意兩個問題：首先為了防止編譯器優化中斷變量，要在這些變量定義時前加volatile，其次在主循環中讀取中斷變量前應該首先關閉全局中斷，防止讀到一半被中斷給修改了，讀完之后再打開全局中斷;否則出現造成數據亂套。

　　3、地址溢出，常見錯誤為指針操作錯誤。我要著重說的是數組下標使用循環函數中循環變量，如果循環變量沒控制好則會出現數組下標越界，意外修改系統的寄存器造成死機，這種情況下如果死機說明運氣好，否則后面不知道發生什么頭疼的事。

　　4、無條件的死循環;比如使用while（x）;等待電平變化，正常情況下x都會變成0，就怕萬一，因此最好加上時間限制;

　　5、看門狗沒有關閉。有的單片機即使沒使用看門狗開機時也有可能意外自動開啟了最小周期的看門狗，導致軟件不斷復位，造成死機，這個要看芯片手冊，最好在程序復位后首先應該顯式清除看門狗再關閉看門狗;

　　6、堆棧溢出。最難查找的問題，對于容量小的單片機，盡量減少函數調用層級，減少局部變量，從而減少壓棧的時候所需的空間。當你把以上幾條都試過不能解決問題，試一試把你的被調用少函數直接內置到調用的地方并且把占用RAM大的局部變量改成全局變量，試一試說不定就可以了。