[[410060]]

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

[[410061]]

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

[[410062]]

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

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

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

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

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

事件：某一時刻發(fā)生的對系統(tǒng)有意義的事情，狀態(tài)機之所以發(fā)生狀態(tài)遷移，就是因為出現(xiàn)了事件。對電動機來講，加正電壓、加負電壓、斷電就是事件。

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

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

只談概念太空洞了，上一個小例子：一單片機、一按鍵、倆 LED 燈(記為L1和L2)、一人， 足矣！

規(guī)則描述：

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

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

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

圖1

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

程序清單List1： 

void main(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  
  {  
   ; /*idle code*/  
  }  
 }  
}  
void fsm_active(void)  
{  
 if(g_stFSM.u8KeyCnt > 3) /*擊鍵是否滿 5 次*/  
 {  
  switch(g_stFSM.u8LedStat)  
  {  
   case LS_OFFOFF:  
    led_on(LED1); /*輸出動作*/  
    g_stFSM.u8KeyCnt = 0;  
    g_stFSM.u8LedStat = LS_ONOFF; /*狀態(tài)遷移*/  
    break;  
   case LS_ONOFF:  
    led_on(LED2); /*輸出動作*/  
    g_stFSM.u8KeyCnt = 0;  
    g_stFSM.u8LedStat = LS_ONON; /*狀態(tài)遷移*/  
    break;  
   case LS_ONON:  
    led_off(LED1); /*輸出動作*/  
    g_stFSM.u8KeyCnt = 0;  
    g_stFSM.u8LedStat = LS_OFFON; /*狀態(tài)遷移*/  
    break;  
   case LS_OFFON:  
    led_off(LED2); /*輸出動作*/  
    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; /*恢復初始狀態(tài)*/  
    break;  
  }  
 }  
 else  
 {  
  g_stFSM.u8KeyCnt++; /*狀態(tài)不遷移，僅記錄擊鍵次數(shù)*/  
 }  
} 

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

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

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

圓角矩形代表狀態(tài)機的各個狀態(tài)，里面標注著狀態(tài)的名稱。

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

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

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

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

圖中有一個黑色實心圓點，表示狀態(tài)機在工作之前所處的一種不可知的狀態(tài)，在運行之前狀態(tài)機必須強制地由這個狀態(tài)遷移到初始狀態(tài)，這個遷移可以有動作列表(如圖1所示)，但不需要事件觸發(fā)。

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

關(guān)于這個狀態(tài)轉(zhuǎn)換圖就不多說了，相信大家結(jié)合著上面的代碼能很容易看明白?，F(xiàn)在我們再聊一聊程序清單List1。

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

再看一下g_stFSM這個狀態(tài)機結(jié)構(gòu)體變量，它有兩個成員：u8LedStat和 u8KeyCnt。用這個結(jié)構(gòu)體來做狀態(tài)機好像有點兒啰嗦，我們能不能只用一個像 u8LedStat 這樣的整型變量來做狀態(tài)機呢？

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

[[410064]]

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

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

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

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

2、狀態(tài)機編程的優(yōu)點

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

(1)提高CPU使用效率

[[410065]]

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

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

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

(2) 邏輯完備性

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

[[410066]]

不知道大家有沒有用C語言寫過計算器的小程序，我很早以前寫過，寫出來一測試，那個慘不忍睹??！當我規(guī)規(guī)矩矩的輸入算式的時候，程序可以得到正確的計算結(jié)果，但要是故意輸入數(shù)字和運算符號的隨意組合，程序總是得出莫名其妙的結(jié)果。

[[410067]]

后來我試著思維模擬一下程序的工作過程，正確的算式思路清晰，流程順暢，可要碰上了不規(guī)矩的式子，走著走著我就暈菜了，那么多的標志位，那么多的變量，變來變?nèi)?，最后直接分析不下去了?/p>

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

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

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

這樣說也許大家會覺得太空洞，實踐出真知，某天如果你真的要設(shè)計一個邏輯復雜的程序，

我保證你會說：哇！狀態(tài)機真的很好用哎！

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

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

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

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