摘要：不知道大家有沒(méi)有這樣一種感覺(jué)，就是感覺(jué)自己玩單片機(jī)還可以，各個(gè)功能模塊也都會(huì)驅(qū)動(dòng)，但是如果讓你完整的寫(xiě)一套代碼，卻無(wú)邏輯與框架可言，上來(lái)就是開(kāi)始寫(xiě)！東抄抄寫(xiě)抄抄。說(shuō)明編程還處于比較低的水平，那么如何才能提高自己的編程水平呢？學(xué)會(huì)一種好的編程框架或者一種編程思想，可能會(huì)受用終生！比如模塊化編程，框架式編程，狀態(tài)機(jī)編程等等，都是一種好的框架。

今天說(shuō)的就是狀態(tài)機(jī)編程，由于篇幅較長(zhǎng)，大家慢慢欣賞。那么狀態(tài)機(jī)是一個(gè)這樣的東東？狀態(tài)機(jī)(state machine)有5個(gè)要素，分別是狀態(tài)(state)、遷移(transition)、事件(event)、動(dòng)作(action)、條件(guard)。

什么是狀態(tài)機(jī)？

狀態(tài)機(jī)是一個(gè)這樣的東東：狀態(tài)機(jī)(state machine)有 5 個(gè)要素，分別是狀態(tài)(state)、遷移(transition)、事件(event)、動(dòng)作(action)、條件(guard)。

狀態(tài)：一個(gè)系統(tǒng)在某一時(shí)刻所存在的穩(wěn)定的工作情況，系統(tǒng)在整個(gè)工作周期中可能有多個(gè)狀態(tài)。例如一部電動(dòng)機(jī)共有正轉(zhuǎn)、反轉(zhuǎn)、停轉(zhuǎn)這 3 種狀態(tài)。

一個(gè)狀態(tài)機(jī)需要在狀態(tài)集合中選取一個(gè)狀態(tài)作為初始狀態(tài)。

遷移：系統(tǒng)從一個(gè)狀態(tài)轉(zhuǎn)移到另一個(gè)狀態(tài)的過(guò)程稱作遷移，遷移不是自動(dòng)發(fā)生的，需要外界對(duì)系統(tǒng)施加影響。停轉(zhuǎn)的電動(dòng)機(jī)自己不會(huì)轉(zhuǎn)起來(lái)，讓它轉(zhuǎn)起來(lái)必須上電。

事件：某一時(shí)刻發(fā)生的對(duì)系統(tǒng)有意義的事情，狀態(tài)機(jī)之所以發(fā)生狀態(tài)遷移，就是因?yàn)槌霈F(xiàn)了事件。對(duì)電動(dòng)機(jī)來(lái)講，加正電壓、加負(fù)電壓、斷電就是事件。

動(dòng)作：在狀態(tài)機(jī)的遷移過(guò)程中，狀態(tài)機(jī)會(huì)做出一些其它的行為，這些行為就是動(dòng)作，動(dòng)作是狀態(tài)機(jī)對(duì)事件的響應(yīng)。給停轉(zhuǎn)的電動(dòng)機(jī)加正電壓，電動(dòng)機(jī)由停轉(zhuǎn)狀態(tài)遷移到正轉(zhuǎn)狀態(tài)，同時(shí)會(huì)啟動(dòng)電機(jī)，這個(gè)啟動(dòng)過(guò)程可以看做是動(dòng)作，也就是對(duì)上電事件的響應(yīng)。

條件：狀態(tài)機(jī)對(duì)事件并不是有求必應(yīng)的，有了事件，狀態(tài)機(jī)還要滿足一定的條件才能發(fā)生狀態(tài)遷移。還是以停轉(zhuǎn)狀態(tài)的電動(dòng)機(jī)為例，雖然合閘上電了，但是如果供電線路有問(wèn)題的話，電動(dòng)機(jī)還是不能轉(zhuǎn)起來(lái)。

只談概念太空洞了，上一個(gè)小例子：一單片機(jī)、一按鍵、倆 LED 燈(記為L(zhǎng)1和L2)、一人， 足矣！

規(guī)則描述：

1、L1L2狀態(tài)轉(zhuǎn)換順序OFF/OFF--->ON/OFF--->ON/ON--->OFF/ON--->OFF/OFF

2、通過(guò)按鍵控制L1L2的狀態(tài),每次狀態(tài)轉(zhuǎn)換需連續(xù)按鍵5次

3、L1L2的初始狀態(tài)OFF/OFF

圖1

下面這段程序是根據(jù)功能要求寫(xiě)成的代碼。

程序清單List1：

voidmain(void)
{
sys_init();
led_off(LED1);
led_off(LED2);
g_stFSM.u8LedStat=LS_OFFOFF;
g_stFSM.u8KeyCnt=0;
while(1)
{
if(test_key()==TRUE)
{
fsm_active();
}
else
{
;/*idlecode*/
}
}
}
voidfsm_active(void)
{
if(g_stFSM.u8KeyCnt>3)/*擊鍵是否滿5次*/
{
switch(g_stFSM.u8LedStat)
{
caseLS_OFFOFF:
led_on(LED1);/*輸出動(dòng)作*/
g_stFSM.u8KeyCnt=0;
g_stFSM.u8LedStat=LS_ONOFF;/*狀態(tài)遷移*/
break;
caseLS_ONOFF:
led_on(LED2);/*輸出動(dòng)作*/
g_stFSM.u8KeyCnt=0;
g_stFSM.u8LedStat=LS_ONON;/*狀態(tài)遷移*/
break;
caseLS_ONON:
led_off(LED1);/*輸出動(dòng)作*/
g_stFSM.u8KeyCnt=0;
g_stFSM.u8LedStat=LS_OFFON;/*狀態(tài)遷移*/
break;
caseLS_OFFON:
led_off(LED2);/*輸出動(dòng)作*/
g_stFSM.u8KeyCnt=0;
g_stFSM.u8LedStat=LS_OFFOFF;/*狀態(tài)遷移*/
break;
default:/*非法狀態(tài)*/
led_off(LED1);
led_off(LED2);
g_stFSM.u8KeyCnt=0;
g_stFSM.u8LedStat=LS_OFFOFF;/*恢復(fù)初始狀態(tài)*/
break;
}
}
else
{
g_stFSM.u8KeyCnt++;/*狀態(tài)不遷移，僅記錄擊鍵次數(shù)*/
}
}

實(shí)際上在狀態(tài)機(jī)編程中，正確的順序應(yīng)該是先有狀態(tài)轉(zhuǎn)換圖，后有程序，程序應(yīng)該是根據(jù)設(shè)計(jì)好的狀態(tài)圖寫(xiě)出來(lái)的。不過(guò)考慮到有些童鞋會(huì)覺(jué)得代碼要比轉(zhuǎn)換圖來(lái)得親切，我就先把程序放在前頭了。

這張狀態(tài)轉(zhuǎn)換圖是用UML(統(tǒng)一建模語(yǔ)言)的語(yǔ)法元素畫(huà)出來(lái)的，語(yǔ)法不是很標(biāo)準(zhǔn)，但拿來(lái)解釋問(wèn)題足夠了。

圖2按鍵控制流水燈狀態(tài)轉(zhuǎn)換圖

圓角矩形代表狀態(tài)機(jī)的各個(gè)狀態(tài)，里面標(biāo)注著狀態(tài)的名稱。

帶箭頭的直線或弧線代表狀態(tài)遷移，起于初態(tài)，止于次態(tài)。

圖中的文字內(nèi)容是對(duì)遷移的說(shuō)明，格式是：事件[條件]/動(dòng)作列表(后兩項(xiàng)可選)。

“事件[條件]/動(dòng)作列表”要說(shuō)明的意思是：如果在某個(gè)狀態(tài)下發(fā)生了“事件”，并且狀態(tài)機(jī)

滿足“[條件]”，那么就要執(zhí)行此次狀態(tài)轉(zhuǎn)移，同時(shí)要產(chǎn)生一系列“動(dòng)作”，以響應(yīng)事件。在這個(gè)例子里，我用“KEY”表示擊鍵事件。

圖中有一個(gè)黑色實(shí)心圓點(diǎn)，表示狀態(tài)機(jī)在工作之前所處的一種不可知的狀態(tài)，在運(yùn)行之前狀態(tài)機(jī)必須強(qiáng)制地由這個(gè)狀態(tài)遷移到初始狀態(tài)，這個(gè)遷移可以有動(dòng)作列表(如圖1所示)，但不需要事件觸發(fā)。

圖中還有一個(gè)包含黑色實(shí)心圓點(diǎn)的圓圈，表示狀態(tài)機(jī)生命周期的結(jié)束，這個(gè)例子中的狀態(tài)機(jī)生生不息，所以沒(méi)有狀態(tài)指向該圓圈。

關(guān)于這個(gè)狀態(tài)轉(zhuǎn)換圖就不多說(shuō)了，相信大家結(jié)合著上面的代碼能很容易看明白。現(xiàn)在我們?cè)倭囊涣某绦蚯鍐蜭ist1。

先看一下fsm_active()這個(gè)函數(shù)，g_stFSM.u8KeyCnt = 0;這個(gè)語(yǔ)句在switch—case里共出現(xiàn)了 5 次，前 4 次是作為各個(gè)狀態(tài)遷移的動(dòng)作出現(xiàn)的。從代碼簡(jiǎn)化提高效率的角度來(lái)看，我們完全可以把這 5 次合并為 1 次放在 switch—case 語(yǔ)句之前，兩者的效果是完全一樣的，代碼里之所以這樣啰嗦，是為了清晰地表明每次狀態(tài)遷移中所有的動(dòng)作細(xì)節(jié)，這種方式和圖2的狀態(tài)轉(zhuǎn)換圖所要表達(dá)的意圖是完全一致的。

再看一下g_stFSM這個(gè)狀態(tài)機(jī)結(jié)構(gòu)體變量，它有兩個(gè)成員：u8LedStat和 u8KeyCnt。用這個(gè)結(jié)構(gòu)體來(lái)做狀態(tài)機(jī)好像有點(diǎn)兒?jiǎn)拢覀兡懿荒苤挥靡粋€(gè)像 u8LedStat 這樣的整型變量來(lái)做狀態(tài)機(jī)呢？

當(dāng)然可以！我們把圖 2中的這 4 個(gè)狀態(tài)各自拆分成 5 個(gè)小狀態(tài)，這樣用 20 個(gè)狀態(tài)同樣能實(shí)現(xiàn)這個(gè)狀態(tài)機(jī)，而且只需要一個(gè) unsigned char 型的變量就足夠了，每次擊鍵都會(huì)引發(fā)狀態(tài)遷移， 每遷移 5 次就能改變一次 LED 燈的狀態(tài)，從外面看兩種方法的效果完全一樣。

假設(shè)我把功能要求改一下，把連續(xù)擊鍵5次改變L1L2的狀態(tài)改為連續(xù)擊鍵100次才能改變L1L2的狀態(tài)。這樣的話第二種方法需要4X100=400個(gè)狀態(tài)！而且函數(shù)fsm_active()中的switch—case語(yǔ)句里要有400個(gè)case，這樣的程序還有法兒寫(xiě)么？！

同樣的功能改動(dòng)，如果用g_stFSM這個(gè)結(jié)構(gòu)體來(lái)實(shí)現(xiàn)狀態(tài)機(jī)的話，函數(shù)fsm_active()只需要將if(g_stFSM.u8KeyCnt>3)改為if(g_stFSM.u8KeyCnt > 98)就可以了！

g_stFSM結(jié)構(gòu)體的兩個(gè)成員中，u8LedStat可以看作是質(zhì)變因子，相當(dāng)于主變量；u8KeyCnt可以看作是量變因子，相當(dāng)于輔助變量。量變因子的逐步積累會(huì)引發(fā)質(zhì)變因子的變化。

像g_stFSM這樣的狀態(tài)機(jī)被稱作Extended State Machine，我不知道業(yè)內(nèi)正規(guī)的中文術(shù)語(yǔ)怎么講，只好把英文詞組搬過(guò)來(lái)了。

2、狀態(tài)機(jī)編程的優(yōu)點(diǎn)

說(shuō)了這么多，大家大概明白狀態(tài)機(jī)到底是個(gè)什么東西了，也知道狀態(tài)機(jī)化的程序大體怎么寫(xiě)了，那么單片機(jī)的程序用狀態(tài)機(jī)的方法來(lái)寫(xiě)有什么好處呢？

(1)提高CPU使用效率

話說(shuō)我只要見(jiàn)到滿篇都是delay_ms()的程序就會(huì)蛋疼，動(dòng)輒十幾個(gè)ms幾十個(gè)ms的軟件延時(shí)是對(duì)CPU資源的巨大浪費(fèi)，寶貴的CPU機(jī)時(shí)都浪費(fèi)在了NOP指令上。那種為了等待一個(gè)管腳電平跳變或者一個(gè)串口數(shù)據(jù)而巋然不動(dòng)的程序也讓我非常糾結(jié)，如果事件一直不發(fā)生，你要等到世界末日么？

把程序狀態(tài)機(jī)化，這種情況就會(huì)明顯改觀，程序只需要用全局變量記錄下工作狀態(tài)，就可以轉(zhuǎn)頭去干別的工作了，當(dāng)然忙完那些活兒之后要再看看工作狀態(tài)有沒(méi)有變化。只要目標(biāo)事件(定時(shí)未到、電平?jīng)]跳變、串口數(shù)據(jù)沒(méi)收完)還沒(méi)發(fā)生，工作狀態(tài)就不會(huì)改變，程序就一直重復(fù)著“查詢—干別的—查詢—干別的”這樣的循環(huán)，這樣CPU就閑不下來(lái)了。在程序清單 List3 中，if{}else{}語(yǔ)句里else下的內(nèi)容(代碼中沒(méi)有添加，只是加了一條/*idle code*/的注釋示意)就是上文所說(shuō)的“別的工作” 。

這種處理方法的實(shí)質(zhì)就是在程序等待事件的過(guò)程中間隔性地插入一些有意義的工作，好讓CPU不是一直無(wú)謂地等待。

(2) 邏輯完備性

我覺(jué)得邏輯完備性是狀態(tài)機(jī)編程最大的優(yōu)點(diǎn)。

不知道大家有沒(méi)有用C語(yǔ)言寫(xiě)過(guò)計(jì)算器的小程序，我很早以前寫(xiě)過(guò)，寫(xiě)出來(lái)一測(cè)試，那個(gè)慘不忍睹啊！當(dāng)我規(guī)規(guī)矩矩的輸入算式的時(shí)候，程序可以得到正確的計(jì)算結(jié)果，但要是故意輸入數(shù)字和運(yùn)算符號(hào)的隨意組合，程序總是得出莫名其妙的結(jié)果。

后來(lái)我試著思維模擬一下程序的工作過(guò)程，正確的算式思路清晰，流程順暢，可要碰上了不規(guī)矩的式子，走著走著我就暈菜了，那么多的標(biāo)志位，那么多的變量，變來(lái)變?nèi)ィ詈笾苯臃治霾幌氯チ恕?/p>

很久之后我認(rèn)識(shí)了狀態(tài)機(jī)，才恍然明白，當(dāng)時(shí)的程序是有邏輯漏洞的。如果把這個(gè)計(jì)算器程序當(dāng)做是一個(gè)反應(yīng)式系統(tǒng)，那么一個(gè)數(shù)字或者運(yùn)算符就可以看做一個(gè)事件，一個(gè)算式就是一組事件組合。對(duì)于一個(gè)邏輯完備的反應(yīng)式系統(tǒng)，不管什么樣的事件組合，系統(tǒng)都能正確處理事件，而且系統(tǒng)自身的工作狀態(tài)也一直處在可知可控的狀態(tài)中。反過(guò)來(lái)，如果一個(gè)系統(tǒng)的邏輯功能不完備，在某些特定事件組合的驅(qū)動(dòng)下，系統(tǒng)就會(huì)進(jìn)入一個(gè)不可知不可控的狀態(tài)，與設(shè)計(jì)者的意圖相悖。

狀態(tài)機(jī)就能解決邏輯完備性的問(wèn)題。

狀態(tài)機(jī)是一種以系統(tǒng)狀態(tài)為中心，以事件為變量的設(shè)計(jì)方法，它專注于各個(gè)狀態(tài)的特點(diǎn)以及狀態(tài)之間相互轉(zhuǎn)換的關(guān)系。狀態(tài)的轉(zhuǎn)換恰恰是事件引起的，那么在研究某個(gè)具體狀態(tài)的時(shí)候，我們自然而然地會(huì)考慮任何一個(gè)事件對(duì)這個(gè)狀態(tài)有什么樣的影響。這樣，每一個(gè)狀態(tài)中發(fā)生的每一個(gè)事件都會(huì)在我們的考慮之中，也就不會(huì)留下邏輯漏洞。

這樣說(shuō)也許大家會(huì)覺(jué)得太空洞，實(shí)踐出真知，某天如果你真的要設(shè)計(jì)一個(gè)邏輯復(fù)雜的程序，

我保證你會(huì)說(shuō)：哇！狀態(tài)機(jī)真的很好用哎！

(3)程序結(jié)構(gòu)清晰

用狀態(tài)機(jī)寫(xiě)出來(lái)的程序的結(jié)構(gòu)是非常清晰的。

程序員最痛苦的事兒莫過(guò)于讀別人寫(xiě)的代碼。如果代碼不是很規(guī)范，而且手里還沒(méi)有流程圖，讀代碼會(huì)讓人暈了又暈，只有順著程序一遍又一遍的看，很多遍之后才能隱約地明白程序大體的工作過(guò)程。有流程圖會(huì)好一點(diǎn)，但是如果程序比較大，流程圖也不會(huì)畫(huà)得多詳細(xì)，很多細(xì)節(jié)上的過(guò)程還是要從代碼中理解。

相比之下，用狀態(tài)機(jī)寫(xiě)的程序要好很多，拿一張標(biāo)準(zhǔn)的UML狀態(tài)轉(zhuǎn)換圖，再配上一些簡(jiǎn)明的文字說(shuō)明，程序中的各個(gè)要素一覽無(wú)余。程序中有哪些狀態(tài)，會(huì)發(fā)生哪些事件，狀態(tài)機(jī)如何響應(yīng)，響應(yīng)之后跳轉(zhuǎn)到哪個(gè)狀態(tài)，這些都十分明朗，甚至許多動(dòng)作細(xì)節(jié)都能從狀態(tài)轉(zhuǎn)換圖中找到。可以毫不夸張的說(shuō)，有了UML狀態(tài)轉(zhuǎn)換圖，程序流程圖寫(xiě)都不用寫(xiě)。

審核編輯：湯梓紅