摘要：不知道大家有沒有這樣一種感覺，就是感覺自己玩單片機還可以，各個功能模塊也都會驅動，但是如果讓你完整的寫一套代碼，卻無邏輯與框架可言，上來就是開始寫！東抄抄寫抄抄。說明編程還處于比較低的水平，那么如何才能提高自己的編程水平呢？學會一種好的編程框架或者一種編程思想，可能會受用終生！比如模塊化編程，框架式編程，狀態機編程等等，都是一種好的框架。
今天說的就是狀態機編程，由于篇幅較長，大家慢慢欣賞。那么狀態機是一個這樣的東東？狀態機(state machine)有5個要素，分別是狀態(state)、遷移(transition)、事件(event)、動作(action)、條件(guard)。
狀態機是一個這樣的東東：狀態機(state machine)有 5 個要素，分別是狀態(state)、遷移(transition)、事件(event)、動作(action)、條件(guard)。
狀態：一個系統在某一時刻所存在的穩定的工作情況，系統在整個工作周期中可能有多個狀態。例如一部電動機共有正轉、反轉、停轉這 3 種狀態。
一個狀態機需要在狀態集合中選取一個狀態作為初始狀態。
遷移：系統從一個狀態轉移到另一個狀態的過程稱作遷移，遷移不是自動發生的，需要外界對系統施加影響。停轉的電動機自己不會轉起來，讓它轉起來必須上電。
事件：某一時刻發生的對系統有意義的事情，狀態機之所以發生狀態遷移，就是因為出現了事件。對電動機來講，加正電壓、加負電壓、斷電就是事件。
動作：在狀態機的遷移過程中，狀態機會做出一些其它的行為，這些行為就是動作，動作是狀態機對事件的響應。給停轉的電動機加正電壓，電動機由停轉狀態遷移到正轉狀態，同時會啟動電機，這個啟動過程可以看做是動作，也就是對上電事件的響應。
條件：狀態機對事件并不是有求必應的，有了事件，狀態機還要滿足一定的條件才能發生狀態遷移。還是以停轉狀態的電動機為例，雖然合閘上電了，但是如果供電線路有問題的話，電動機還是不能轉起來。
只談概念太空洞了，上一個小例子：一單片機、一按鍵、倆 LED 燈(記為L1和L2)、一人， 足矣！
規則描述：
1、L1L2狀態轉換順序OFF/OFF--->ON/OFF--->ON/ON--->OFF/ON--->OFF/OFF
2、通過按鍵控制L1L2的狀態,每次狀態轉換需連續按鍵5次
3、L1L2的初始狀態OFF/OFF
下面這段程序是根據功能要求寫成的代碼。
程序清單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; /*狀態遷移*/
break;
case LS_ONOFF:
led_on(LED2); /*輸出動作*/
g_stFSM.u8KeyCnt = 0;
g_stFSM.u8LedStat = LS_ONON; /*狀態遷移*/
break;
case LS_ONON:
led_off(LED1); /*輸出動作*/
g_stFSM.u8KeyCnt = 0;
g_stFSM.u8LedStat = LS_OFFON; /*狀態遷移*/
break;
case LS_OFFON:
led_off(LED2); /*輸出動作*/
g_stFSM.u8KeyCnt = 0;
g_stFSM.u8LedStat = LS_OFFOFF; /*狀態遷移*/
break;
default: /*非法狀態*/
led_off(LED1);
led_off(LED2);
g_stFSM.u8KeyCnt = 0;
g_stFSM.u8LedStat = LS_OFFOFF; /*恢復初始狀態*/
break;
}
}
else
{
g_stFSM.u8KeyCnt++; /*狀態不遷移，僅記錄擊鍵次數*/
}
}
實際上在狀態機編程中，正確的順序應該是先有狀態轉換圖，后有程序，程序應該是根據設計好的狀態圖寫出來的。不過考慮到有些童鞋會覺得代碼要比轉換圖來得親切，我就先把程序放在前頭了。
這張狀態轉換圖是用UML(統一建模語言)的語法元素畫出來的，語法不是很標準，但拿來解釋問題足夠了。
圓角矩形代表狀態機的各個狀態，里面標注著狀態的名稱。
帶箭頭的直線或弧線代表狀態遷移，起于初態，止于次態。
圖中的文字內容是對遷移的說明，格式是：事件[條件]/動作列表(后兩項可選)。
“事件[條件]/動作列表”要說明的意思是：如果在某個狀態下發生了“事件”，并且狀態機
滿足“[條件]”，那么就要執行此次狀態轉移，同時要產生一系列“動作”，以響應事件。在這個例子里，我用“KEY”表示擊鍵事件。
圖中有一個黑色實心圓點，表示狀態機在工作之前所處的一種不可知的狀態，在運行之前狀態機必須強制地由這個狀態遷移到初始狀態，這個遷移可以有動作列表(如圖1所示)，但不需要事件觸發。
圖中還有一個包含黑色實心圓點的圓圈，表示狀態機生命周期的結束，這個例子中的狀態機生生不息，所以沒有狀態指向該圓圈。
關于這個狀態轉換圖就不多說了，相信大家結合著上面的代碼能很容易看明白。現在我們再聊一聊程序清單List1。
先看一下fsm_active()這個函數，g_stFSM.u8KeyCnt = 0;這個語句在switch—case里共出現了 5 次，前 4 次是作為各個狀態遷移的動作出現的。從代碼簡化提高效率的角度來看，我們完全可以把這 5 次合并為 1 次放在 switch—case 語句之前，兩者的效果是完全一樣的，代碼里之所以這樣啰嗦，是為了清晰地表明每次狀態遷移中所有的動作細節，這種方式和圖2的狀態轉換圖所要表達的意圖是完全一致的。
再看一下g_stFSM這個狀態機結構體變量，它有兩個成員：u8LedStat和 u8KeyCnt。用這個結構體來做狀態機好像有點兒啰嗦，我們能不能只用一個像 u8LedStat 這樣的整型變量來做狀態機呢？
當然可以！我們把圖 2中的這 4 個狀態各自拆分成 5 個小狀態，這樣用 20 個狀態同樣能實現這個狀態機，而且只需要一個 unsigned char 型的變量就足夠了，每次擊鍵都會引發狀態遷移， 每遷移 5 次就能改變一次 LED 燈的狀態，從外面看兩種方法的效果完全一樣。
假設我把功能要求改一下，把連續擊鍵5次改變L1L2的狀態改為連續擊鍵100次才能改變L1L2的狀態。這樣的話第二種方法需要4X100=400個狀態！而且函數fsm_active()中的switch—case語句里要有400個case，這樣的程序還有法兒寫么？！
同樣的功能改動，如果用g_stFSM這個結構體來實現狀態機的話，函數fsm_active()只需要將if(g_stFSM.u8KeyCnt>3)改為if(g_stFSM.u8KeyCnt > 98)就可以了！
g_stFSM結構體的兩個成員中，u8LedStat可以看作是質變因子，相當于主變量；u8KeyCnt可以看作是量變因子，相當于輔助變量。量變因子的逐步積累會引發質變因子的變化。
像g_stFSM這樣的狀態機被稱作Extended State Machine，我不知道業內正規的中文術語怎么講，只好把英文詞組搬過來了。
說了這么多，大家大概明白狀態機到底是個什么東西了，也知道狀態機化的程序大體怎么寫了，那么單片機的程序用狀態機的方法來寫有什么好處呢？
話說我只要見到滿篇都是delay_ms()的程序就會蛋疼，動輒十幾個ms幾十個ms的軟件延時是對CPU資源的巨大浪費，寶貴的CPU機時都浪費在了NOP指令上。那種為了等待一個管腳電平跳變或者一個串口數據而巋然不動的程序也讓我非常糾結，如果事件一直不發生，你要等到世界末日么？
把程序狀態機化，這種情況就會明顯改觀，程序只需要用全局變量記錄下工作狀態，就可以轉頭去干別的工作了，當然忙完那些活兒之后要再看看工作狀態有沒有變化。只要目標事件(定時未到、電平沒跳變、串口數據沒收完)還沒發生，工作狀態就不會改變，程序就一直重復著“查詢—干別的—查詢—干別的”這樣的循環，這樣CPU就閑不下來了。在程序清單 List3 中，if{}else{}語句里else下的內容(代碼中沒有添加，只是加了一條/*idle code*/的注釋示意)就是上文所說的“別的工作” 。
這種處理方法的實質就是在程序等待事件的過程中間隔性地插入一些有意義的工作，好讓CPU不是一直無謂地等待。
我覺得邏輯完備性是狀態機編程最大的優點。
不知道大家有沒有用C語言寫過計算器的小程序，我很早以前寫過，寫出來一測試，那個慘不忍睹??！當我規規矩矩的輸入算式的時候，程序可以得到正確的計算結果，但要是故意輸入數字和運算符號的隨意組合，程序總是得出莫名其妙的結果。
后來我試著思維模擬一下程序的工作過程，正確的算式思路清晰，流程順暢，可要碰上了不規矩的式子，走著走著我就暈菜了，那么多的標志位，那么多的變量，變來變去，最后直接分析不下去了。
很久之后我認識了狀態機，才恍然明白，當時的程序是有邏輯漏洞的。如果把這個計算器程序當做是一個反應式系統，那么一個數字或者運算符就可以看做一個事件，一個算式就是一組事件組合。對于一個邏輯完備的反應式系統，不管什么樣的事件組合，系統都能正確處理事件，而且系統自身的工作狀態也一直處在可知可控的狀態中。反過來，如果一個系統的邏輯功能不完備，在某些特定事件組合的驅動下，系統就會進入一個不可知不可控的狀態，與設計者的意圖相悖。
狀態機就能解決邏輯完備性的問題。
狀態機是一種以系統狀態為中心，以事件為變量的設計方法，它專注于各個狀態的特點以及狀態之間相互轉換的關系。狀態的轉換恰恰是事件引起的，那么在研究某個具體狀態的時候，我們自然而然地會考慮任何一個事件對這個狀態有什么樣的影響。這樣，每一個狀態中發生的每一個事件都會在我們的考慮之中，也就不會留下邏輯漏洞。
這樣說也許大家會覺得太空洞，實踐出真知，某天如果你真的要設計一個邏輯復雜的程序，
我保證你會說：哇！狀態機真的很好用哎！
用狀態機寫出來的程序的結構是非常清晰的。
程序員最痛苦的事兒莫過于讀別人寫的代碼。如果代碼不是很規范，而且手里還沒有流程圖，讀代碼會讓人暈了又暈，只有順著程序一遍又一遍的看，很多遍之后才能隱約地明白程序大體的工作過程。有流程圖會好一點，但是如果程序比較大，流程圖也不會畫得多詳細，很多細節上的過程還是要從代碼中理解。
相比之下，用狀態機寫的程序要好很多，拿一張標準的UML狀態轉換圖，再配上一些簡明的文字說明，程序中的各個要素一覽無余。程序中有哪些狀態，會發生哪些事件，狀態機如何響應，響應之后跳轉到哪個狀態，這些都十分明朗，甚至許多動作細節都能從狀態轉換圖中找到?？梢院敛豢鋸埖恼f，有了UML狀態轉換圖，程序流程圖寫都不用寫。
套用一句廣告詞：誰用誰知道！
說明：文章轉載自一篇pdf文檔，作者Alicedodo，旨在分享技術知識，如有侵權請聯系刪除！
非常輕松地談談dB，dB， dBm， dBi
關于JTAG口，你了解多少？
58個硬件面試題整理
【視頻】硬核自制，我把自行車做成了自動駕駛！
一文看懂差分線
內容合作 | 視頻、課程合作 | 開發板合作| 轉載開白
請聯系小助手微信：15889572951（微信同號）
點擊閱讀原文，下載《嵌入式硬件設計》
