干貨?|?嵌入式之狀態(tài)機(jī)編程
[導(dǎo)讀]關(guān)注「嵌入式大雜燴」，選擇「星標(biāo)公眾號(hào)」一起進(jìn)步！來源：果果小師弟摘要：不知道大家有沒有這樣一種感覺，就是感覺自己玩單片機(jī)還可以，各個(gè)功能模塊也都會(huì)驅(qū)動(dòng)，但是如果讓你完整的寫一套代碼，卻無邏輯與框架可言，上來就是開始寫！東抄抄寫抄抄。說明編程還處于比較低的水平，那么如何才能提高自...
關(guān)注「嵌入式大雜燴」，選擇「星標(biāo)公眾號(hào)」一起進(jìn)步！
圖1 圖2按鍵控制流水燈狀態(tài)轉(zhuǎn)換圖 果子哥制作
來源：果果小師弟摘要：不知道大家有沒有這樣一種感覺，就是感覺自己玩單片機(jī)還可以，各個(gè)功能模塊也都會(huì)驅(qū)動(dòng)，但是如果讓你完整的寫一套代碼，卻無邏輯與框架可言，上來就是開始寫！東抄抄寫抄抄。說明編程還處于比較低的水平，那么如何才能提高自己的編程水平呢？學(xué)會(huì)一種好的編程框架或者一種編程思想，可能會(huì)受用終生！比如模塊化編程，框架式編程，狀態(tài)機(jī)編程等等，都是一種好的框架。
什么是狀態(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)的過程稱作遷移，遷移不是自動(dòng)發(fā)生的，需要外界對系統(tǒng)施加影響。停轉(zhuǎn)的電動(dòng)機(jī)自己不會(huì)轉(zhuǎn)起來，讓它轉(zhuǎn)起來必須上電。事件：某一時(shí)刻發(fā)生的對系統(tǒng)有意義的事情，狀態(tài)機(jī)之所以發(fā)生狀態(tài)遷移，就是因?yàn)槌霈F(xiàn)了事件。對電動(dòng)機(jī)來講，加正電壓、加負(fù)電壓、斷電就是事件。動(dòng)作：在狀態(tài)機(jī)的遷移過程中，狀態(tài)機(jī)會(huì)做出一些其它的行為，這些行為就是動(dòng)作，動(dòng)作是狀態(tài)機(jī)對事件的響應(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)過程可以看做是動(dòng)作，也就是對上電事件的響應(yīng)。條件：狀態(tài)機(jī)對事件并不是有求必應(yīng)的，有了事件，狀態(tài)機(jī)還要滿足一定的條件才能發(fā)生狀態(tài)遷移。還是以停轉(zhuǎn)狀態(tài)的電動(dòng)機(jī)為例，雖然合閘上電了，但是如果供電線路有問題的話，電動(dòng)機(jī)還是不能轉(zhuǎn)起來。只談概念太空洞了，上一個(gè)小例子：一單片機(jī)、一按鍵、倆 LED 燈(記為L1和L2)、一人， 足矣！規(guī)則描述：1、L1L2狀態(tài)轉(zhuǎn)換順序OFF/OFF--->ON/OFF--->ON/ON--->OFF/ON--->OFF/OFF2、通過按鍵控制L1L2的狀態(tài),每次狀態(tài)轉(zhuǎn)換需連續(xù)按鍵5次3、L1L2的初始狀態(tài)OFF/OFFvoid?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);?/*輸出動(dòng)作*/
????g_stFSM.u8KeyCnt?=?0;
????g_stFSM.u8LedStat?=?LS_ONOFF;?/*狀態(tài)遷移*/
????break;
???case?LS_ONOFF:
????led_on(LED2);?/*輸出動(dòng)作*/
????g_stFSM.u8KeyCnt?=?0;
????g_stFSM.u8LedStat?=?LS_ONON;?/*狀態(tài)遷移*/
????break;
???case?LS_ONON:
????led_off(LED1);?/*輸出動(dòng)作*/
????g_stFSM.u8KeyCnt?=?0;
????g_stFSM.u8LedStat?=?LS_OFFON;?/*狀態(tài)遷移*/
????break;
???case?LS_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)圖寫出來的。不過考慮到有些童鞋會(huì)覺得代碼要比轉(zhuǎn)換圖來得親切，我就先把程序放在前頭了。這張狀態(tài)轉(zhuǎn)換圖是用UML(統(tǒng)一建模語言)的語法元素畫出來的，語法不是很標(biāo)準(zhǔn)，但拿來解釋問題足夠了。fsm_active()這個(gè)函數(shù)，g_stFSM.u8KeyCnt = 0;這個(gè)語句在switch—case里共出現(xiàn)了 5 次，前 4 次是作為各個(gè)狀態(tài)遷移的動(dòng)作出現(xiàn)的。從代碼簡化提高效率的角度來看，我們完全可以把這 5 次合并為 1 次放在 switch—case 語句之前，兩者的效果是完全一樣的，代碼里之所以這樣啰嗦，是為了清晰地表明每次狀態(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)體來做狀態(tài)機(jī)好像有點(diǎn)兒啰嗦，我們能不能只用一個(gè)像 u8LedStat 這樣的整型變量來做狀態(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)，從外面看兩種方法的效果完全一樣。L1L2的狀態(tài)改為連續(xù)擊鍵100次才能改變L1L2的狀態(tài)。這樣的話第二種方法需要4X100=400個(gè)狀態(tài)！而且函數(shù)fsm_active()中的switch—case語句里要有400個(gè)case，這樣的程序還有法兒寫么？！同樣的功能改動(dòng)，如果用g_stFSM這個(gè)結(jié)構(gòu)體來實(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ù)語怎么講，只好把英文詞組搬過來了。2、狀態(tài)機(jī)編程的優(yōu)點(diǎn)
說了這么多，大家大概明白狀態(tài)機(jī)到底是個(gè)什么東西了，也知道狀態(tài)機(jī)化的程序大體怎么寫了，那么單片機(jī)的程序用狀態(tài)機(jī)的方法來寫有什么好處呢？(1)提高CPU使用效率
delay_ms()的程序就會(huì)蛋疼，動(dòng)輒十幾個(gè)ms幾十個(gè)ms的軟件延時(shí)是對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)有沒有變化。只要目標(biāo)事件(定時(shí)未到、電平?jīng)]跳變、串口數(shù)據(jù)沒收完)還沒發(fā)生，工作狀態(tài)就不會(huì)改變，程序就一直重復(fù)著“查詢—干別的—查詢—干別的”這樣的循環(huán)，這樣CPU就閑不下來了。在程序清單 List3 中，if{}else{}語句里else下的內(nèi)容(代碼中沒有添加，只是加了一條/*idle code*/的注釋示意)就是上文所說的“別的工作” 。這種處理方法的實(shí)質(zhì)就是在程序等待事件的過程中間隔性地插入一些有意義的工作，好讓CPU不是一直無謂地等待。(2) 邏輯完備性
我覺得邏輯完備性是狀態(tài)機(jī)編程最大的優(yōu)點(diǎn)。(3)程序結(jié)構(gòu)清晰
用狀態(tài)機(jī)寫出來的程序的結(jié)構(gòu)是非常清晰的。UML狀態(tài)轉(zhuǎn)換圖，再配上一些簡明的文字說明，程序中的各個(gè)要素一覽無余。程序中有哪些狀態(tài)，會(huì)發(fā)生哪些事件，狀態(tài)機(jī)如何響應(yīng)，響應(yīng)之后跳轉(zhuǎn)到哪個(gè)狀態(tài)，這些都十分明朗，甚至許多動(dòng)作細(xì)節(jié)都能從狀態(tài)轉(zhuǎn)換圖中找到?？梢院敛豢鋸埖恼f，有了UML狀態(tài)轉(zhuǎn)換圖，程序流程圖寫都不用寫。套用一句廣告詞：誰用誰知道！
下載文檔
