其實忽略了一個重要的問題,那就是現(xiàn)實中按鍵按下時候的電平變化有一個從不穩(wěn)定狀態(tài)到穩(wěn)定的狀態(tài)變化。
實際中,由于按鍵的彈片接觸的時候,并不是一接觸就緊緊的閉合,它還存在一定的抖動,盡管這個時間非常的短暫,但是對于我們執(zhí)行時間以us為計算單位的微控制器來說,它太漫長了。因而,實際的波形圖應(yīng)該如下面這幅示意圖一樣。
這樣便存在這樣一個問題。假設(shè)我們的系統(tǒng)有這樣功能需求:在檢測到按鍵按下的時候,將某個I/O的狀態(tài)取反。由于這種抖動的存在,使得我們的微控制器誤以為是多次按鍵的按下,從而將某個I/O的狀態(tài)不斷取反,這并不是我們想要的效果,假如該I/O控制著系統(tǒng)中某個重要的執(zhí)行的部件,那結(jié)果更不是我們所期待的。于是乎有人便提出了軟件消除抖動的思想,道理很簡單:抖動的時間長度是一定的,只要我們避開這段抖動時期,檢測穩(wěn)定的時候的電平不久可以了嗎?聽起來確實不錯,而且實際應(yīng)用起來效果也還可以。于是,各種各樣的書籍中,在提到按鍵檢測的時候,總也不忘說道軟件消抖。就像下面的偽代碼所描述的一樣。(假設(shè)按鍵按下時候,低電平有效)
If(0 == io_KeyEnter) //如果有鍵按下了
{
Delayms(20) ; //先延時20ms避開抖動時期
If(0 == io_KeyEnter) //然后再檢測,如果還是檢測到有鍵按下
{
return KeyValue ; //是真的按下了,返回鍵值
}
else
{
return KEY_NULL //是抖動,返回空的鍵值
}
while(0 == io_KeyEnter) ; //等待按鍵釋放
}
乍看上去,確實挺不錯,實際中呢?在實際的系統(tǒng)中,一般是不允許這么樣做的。為什么呢?首先,這里的Delayms(20) , 讓微控制器在這里白白等待了20 ms 的時間,啥也沒干,考慮我在《學(xué)會釋放CPU》一章中所提及的幾點,這是不可取的。其次while(0 == io_KeyEnter) 所以合理的分配好微控制的處理時間,是編寫按鍵程序的基礎(chǔ)。J;更是程序設(shè)計中的大忌(極少的特殊情況例外)。任何非極端情況下,都不要使用這樣語句來堵塞微控制器的執(zhí)行進程。原本是等待按鍵釋放,結(jié)果CPU就一直死死的盯住該按鍵,其它事情都不管了,那其它事情不干了嗎?你同意別人可不會同意
◎消除抖動有必要嗎?
的確,軟件上的消抖確實可以保證按鍵的有效檢測。但是,這種消抖確實有必要嗎?有人提出了這樣的疑問。抖動是按鍵按下的過程中產(chǎn)生的,如果按鍵沒有按下,抖動會產(chǎn)生嗎?如果沒有按鍵按下,抖動也會在I/O上出現(xiàn),我會立刻把這個微控制器錘了,永遠不用這樣一款微控制器。所以抖動的出現(xiàn)即意味著按鍵已經(jīng)按下,盡管這個電平還沒有穩(wěn)定。所以只要我們檢測到按鍵按下,即可以返回鍵值,問題的關(guān)鍵是,在你執(zhí)行完其它任務(wù)的時候,再次執(zhí)行我們的按鍵任務(wù)的時候,抖動過程還沒有結(jié)束,這樣便有可能造成重復(fù)檢測。所以,如何在返回鍵值后,避免重復(fù)檢測,或者在按鍵一按下就執(zhí)行功能函數(shù),當(dāng)功能函數(shù)的執(zhí)行時間小于抖動時間時候,如何避免再次執(zhí)行功能函數(shù),就成為我們要考慮的問題了。這是一個仁者見仁,智者見智的問題,就留給大家去思考吧。所以消除抖動的目的是:防止按鍵一次按下,多次響應(yīng)。