今天說的就是狀態(tài)機編程，由于篇幅較長，大家慢慢欣賞。那么狀態(tài)機是一個這樣的東東？狀態(tài)機(state machine)有5個要素，分別是狀態(tài)(state)、遷移(transition)、事件(event)、動作(action)、條件(guard)。
狀態(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
下面這段程序是根據(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ù)設計好的狀態(tài)圖寫出來的。不過考慮到有些童鞋會覺得代碼要比轉(zhuǎn)換圖來得親切，我就先把程序放在前頭了。
這張狀態(tài)轉(zhuǎn)換圖是用UML(統(tǒng)一建模語言)的語法元素畫出來的，語法不是很標準，但拿來解釋問題足夠了。
圓角矩形代表狀態(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)指向該圓圈。
關于這個狀態(tài)轉(zhuǎn)換圖就不多說了，相信大家結(jié)合著上面的代碼能很容易看明白。現(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)，從外面看兩種方法的效果完全一樣。
假設我把功能要求改一下，把連續(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ī)的中文術語怎么講，只好把英文詞組搬過來了。
說了這么多，大家大概明白狀態(tài)機到底是個什么東西了，也知道狀態(tài)機化的程序大體怎么寫了，那么單片機的程序用狀態(tài)機的方法來寫有什么好處呢？
話說我只要見到滿篇都是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不是一直無謂地等待。
我覺得邏輯完備性是狀態(tài)機編程最大的優(yōu)點。
不知道大家有沒有用C語言寫過計算器的小程序，我很早以前寫過，寫出來一測試，那個慘不忍睹啊！當我規(guī)規(guī)矩矩的輸入算式的時候，程序可以得到正確的計算結(jié)果，但要是故意輸入數(shù)字和運算符號的隨意組合，程序總是得出莫名其妙的結(jié)果。
后來我試著思維模擬一下程序的工作過程，正確的算式思路清晰，流程順暢，可要碰上了不規(guī)矩的式子，走著走著我就暈菜了，那么多的標志位，那么多的變量，變來變?nèi)ィ詈笾苯臃治霾幌氯チ恕?/span>
很久之后我認識了狀態(tài)機，才恍然明白，當時的程序是有邏輯漏洞的。如果把這個計算器程序當做是一個反應式系統(tǒng)，那么一個數(shù)字或者運算符就可以看做一個事件，一個算式就是一組事件組合。對于一個邏輯完備的反應式系統(tǒng)，不管什么樣的事件組合，系統(tǒng)都能正確處理事件，而且系統(tǒng)自身的工作狀態(tài)也一直處在可知可控的狀態(tài)中。反過來，如果一個系統(tǒng)的邏輯功能不完備，在某些特定事件組合的驅(qū)動下，系統(tǒng)就會進入一個不可知不可控的狀態(tài)，與設計者的意圖相悖。
狀態(tài)機就能解決邏輯完備性的問題。
狀態(tài)機是一種以系統(tǒng)狀態(tài)為中心，以事件為變量的設計方法，它專注于各個狀態(tài)的特點以及狀態(tài)之間相互轉(zhuǎn)換的關系。狀態(tài)的轉(zhuǎn)換恰恰是事件引起的，那么在研究某個具體狀態(tài)的時候，我們自然而然地會考慮任何一個事件對這個狀態(tài)有什么樣的影響。這樣，每一個狀態(tài)中發(fā)生的每一個事件都會在我們的考慮之中，也就不會留下邏輯漏洞。
這樣說也許大家會覺得太空洞，實踐出真知，某天如果你真的要設計一個邏輯復雜的程序，
我保證你會說：哇！狀態(tài)機真的很好用哎！
用狀態(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)換圖，程序流程圖寫都不用寫。
套用一句廣告詞：誰用誰知道！
說明：文章轉(zhuǎn)載自一篇pdf文檔，作者Alicedodo，旨在分享技術知識，如有侵權(quán)請聯(lián)系刪除！
1.嵌入式系統(tǒng)已經(jīng)進入了算力時代~
2.你在瘋狂屯貨，他在悄悄出貨，MCU市場上演孫子兵法
3.手把手教你在STM32F4上跑freeRTOS！
4.嵌入式大會演講人征集：嵌入式AI、RISC-V、物聯(lián)網(wǎng)、OS與軟件測試
5.0Ω電阻可以過多大電流？
6.電路板上的晶振不工作怎么辦？
免責聲明：本文系網(wǎng)絡轉(zhuǎn)載，版權(quán)歸原作者所有。如涉及作品版權(quán)問題，請與我們聯(lián)系，我們將根據(jù)您提供的版權(quán)證明材料確認版權(quán)并支付稿酬或者刪除內(nèi)容。
