嵌入式軟件使用狀態(tài)機(jī)架構(gòu)，一般有什么優(yōu)點(diǎn)？

工程師進(jìn)階筆記 · 發(fā)表于 5 天前

我是老溫，一名熱愛(ài)學(xué)習(xí)的嵌入式工程師
關(guān)注我，一起變得更加優(yōu)秀！
本文總結(jié)下?tīng)顟B(tài)機(jī)編程的優(yōu)點(diǎn)。
一、提高CPU使用效率
話說(shuō)我只要見(jiàn)到滿篇都是delay_ms()的程序就會(huì)頭疼，動(dòng)輒十幾個(gè)ms幾十個(gè)ms的軟件延時(shí)是對(duì)CPU資源的巨大浪費(fèi)，寶貴的CPU時(shí)間都浪費(fèi)在了NOP指令上。
那種為了等待一個(gè)管腳電平跳變或者一個(gè)串口數(shù)據(jù)，讓整個(gè)程序都不動(dòng)的情況也讓我非常糾結(jié)，如果事件一直不發(fā)生電平跳變，你要等到世界末日么？
如果應(yīng)用狀態(tài)機(jī)編程思想，程序只需要用全局變量記錄下工作狀態(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)了。
這種處理方法的實(shí)質(zhì)就是在程序等待事件的過(guò)程中間隔性地插入一些有意義的工作，好讓CPU不是一直無(wú)謂地等待。

二、邏輯完備性
邏輯完備性是狀態(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)�，最后直接分析不下去了�?br /> 很久之后我認(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ì)覺(jué)得狀態(tài)機(jī)真香！
三、程序結(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ě)。
文章來(lái)源：牛逼的工程師網(wǎng)友