?

正文

作者?|?Alicedodo

狀態(tài)機是一種思想，事件驅(qū)動也是一種思想。

事件驅(qū)動的概念

生活中有很多事件驅(qū)動的例子，上自習瞞著老師偷睡覺就是很生動的一個。

我們都是從高中時代走過來的，高中的學生苦啊，覺得睡覺是世界上最奢侈的東西， 有時候站著都能睡著??！老師看的嚴，上課睡覺不允許啊，要挨批??！有木有！相比而言，晚自習是比較寬松的，老師只是不定時來巡視，還是有機會偷偷睡一會兒的。

現(xiàn)在的問題是，怎么睡才能既睡得好又不會讓老師發(fā)現(xiàn)呢？?晚自習是比較寬松的，老師只是不定時來巡視，還是有機會偷偷睡一會兒的。現(xiàn)在的問題是，怎么睡才能既睡得好又不會讓老師發(fā)現(xiàn)呢？

我們現(xiàn)在有三種睡覺方案：

方案 A：倒頭就睡，管你三七二十一，睡夠了再說，要知道有時候老師可能一整晚上都不來的。

方案 B：間歇著睡，先定上鬧鐘， 5 分鐘響一次，響了就醒，看看老師來沒來，沒來的話定上鬧鐘再睡，如此往復。

方案 C：睡之前讓同桌給放哨，然后自己睡覺，什么也不用管，什么時候老師來了，就讓同桌戳醒你。

不管你們選擇的是哪種方案，我高中那會兒用的可是方案 C，安全又舒服。

方案 C 是很有特點的：本來自習課偷睡覺是你自己的事兒， 有沒有被老師抓著也是你自己的事兒，這些和同桌是毫無利害關系的，但是同桌這個環(huán)節(jié)對方案 C 的重要性是不言而喻的，他肩負著監(jiān)控老師巡視和叫醒睡覺者兩項重要任務，是事件驅(qū)動機制實現(xiàn)的重要組成部分 。

在事件驅(qū)動機制中，對象對于外部事件總是處于“休眠” 狀態(tài)的，而把對外部事件的檢測和監(jiān)控交給了第三方組件。

一旦第三方檢測到外部事件發(fā)生， 它就會啟動某種機制， 將對象從“休眠” 狀態(tài)中喚醒， 并將事件告知對象。對象接到通知后， 做出一系列動作， 完成對本次事件響應，然后再次進入“休眠” 狀態(tài)，如此周而復始。

有沒有發(fā)現(xiàn)，事件驅(qū)動機制和單片機的中斷原理上很相似 。

事件驅(qū)動與單片機編程

在我們再回到單片機系統(tǒng)中來，看看事件驅(qū)動思想在單片機程序設計中的應用。當我還是一個單片機菜鳥的時候(當然，我至今也沒有成為單片機高手)，網(wǎng)絡上的大蝦們就諄諄教導：一個好的單片機程序是要分層的。曾經(jīng)很長一段時間， 我對分層這個概念完全沒有感覺。

什么是程序分層？

程序為什么要分層？

應該怎么給程序分層？

隨著手里的代碼量越來越多，實現(xiàn)的功能也越來越多，軟件分層這個概念在我腦子里逐漸地清晰起來，我越來越佩服大蝦們的高瞻遠矚。

單片機的軟件確實要分層的，最起碼要分兩層：驅(qū)動層和應用層。應用是單片機系統(tǒng)的核心，與應用相關的代碼擔負著系統(tǒng)關鍵的邏輯和運算功能，是單片機程序的靈魂。

硬件是程序感知外界并與外界打交道的物質(zhì)基礎，硬件的種類是多種多樣的，各類硬件的操作方式也各不相同，這些操作要求嚴格、精確、瑣細、繁雜。

與硬件打交道的代碼只鐘情于時序和寄存器，我們可以稱之為驅(qū)動相關代碼；與應用相關的代碼卻只專注于邏輯和運算， 我們可稱之為應用相關代碼。

這種客觀存在的情況是單片機軟件分層最直接的依據(jù)，所以說，將軟件劃分為驅(qū)動層和應用層是程序功能分工的結果。那么驅(qū)動層和應用層之間是如何銜接的呢？

在單片機系統(tǒng)中，信息的流動是雙向的，由內(nèi)向外是應用層代碼主動發(fā)起的，實現(xiàn)信息向外流動很簡單， 應用層代碼只需要調(diào)用驅(qū)動層代碼提供的 API 接口函數(shù)即可， 而由外向內(nèi)則是外界主動發(fā)起的， 這時候應用層代碼對于外界輸入需要被動的接收， 這里就涉及到一個接收機制的問題，事件驅(qū)動機制足可勝任這個接收機制。

外界輸入可以理解為發(fā)生了事件，在單片機內(nèi)部直接的表現(xiàn)就是硬件生成了新的數(shù)據(jù)，這些數(shù)據(jù)包含了事件的全部信息， 事件驅(qū)動機制的任務就是將這些數(shù)據(jù)初步處理(也可能不處理)，然后告知應用層代碼， 應用代碼接到通知后把這些數(shù)據(jù)取走， 做最終的處理， 這樣一次事件的響應就完成了。

說到這里，可能很多人突然會發(fā)現(xiàn)，這種處理方法自己編程的時候早就用過了，只不過沒有使用“事件驅(qū)動” 這個文縐縐的名詞罷了。其實事件驅(qū)動機制本來就不神秘， 生活中數(shù)不勝數(shù)的例子足以說明它應用的普遍性。下面的這個小例子是事件驅(qū)動機制在單片機程序中最常見的實現(xiàn)方法，假設某單片機系統(tǒng)用到了以下資源：

一個串口外設 Uart0，用來接收串口數(shù)據(jù)；

一個定時器外設 Tmr0，用來提供周期性定時中斷；

一個外部中斷管腳 Exi0，用來檢測某種外部突發(fā)事件；

一個 I/O 端口 Port0，連接獨立式鍵盤，管理方式為定時掃描法，掛載到 Tmr0 的 ISR；

這樣，系統(tǒng)中可以提取出 4 類事件，分別是 UART、 TMR、 EXI、 KEY ，其中 UART 和KEY 事件發(fā)生后必須開辟緩存存儲事件相關的數(shù)據(jù)。所有事件的檢測都在各自的 ISR 中完成，然后 ISR 再通過事件驅(qū)動機制通知主函數(shù)處理。

為了實現(xiàn) ISR 和主函數(shù)通信， 我們定義一個數(shù)據(jù)類型為INT8U的全局變量 g_u8EvntFlgGrp，稱為事件標志組，里面的每一個 bit 位代表一類事件，如果該 bit 值為 0，表示此類事件沒有發(fā)生，如果該 bit 值為 1，則表示發(fā)生了此類事件，主函數(shù)必須及時地處理該事件。圖 5 所示為g_u8EvntFlgGrp 各個 bit 位的作用 。

程序清單 List9 所示就是按上面的規(guī)劃寫成的示例性代碼 。

程序清單List9：

?

#define?FLG_UART?0x01
#define?FLG_TMR?0x02
#define?FLG_EXI?0x04
#define?FLG_KEY?0x08
volatile?INT8U?g_u8EvntFlgGrp?=?0;?/*事件標志組*/
INT8U?read_envt_flg_grp(void);
/***************************************
*FuncName?:?main
*Description?:?主函數(shù)
*Arguments?:?void
*Return?:?void
*****************************************/
void?main(void)
{
?INT8U?u8FlgTmp?=?0;
?sys_init();
?while(1)
?{
??u8FlgTmp?=?read_envt_flg_grp();?/*讀取事件標志組*/
??if(u8FlgTmp?)?/*是否有事件發(fā)生？?*/
??{
???if(u8FlgTmp?&?FLG_UART)
???{
????action_uart();?/*處理串口事件*/
???}
???if(u8FlgTmp?&?FLG_TMR)
???{
????action_tmr();?/*處理定時中斷事件*/
???}
???if(u8FlgTmp?&?FLG_EXI)
???{
????action_exi();?/*處理外部中斷事件*/
???}
???if(u8FlgTmp?&?FLG_KEY)
???{
????action_key();?/*處理擊鍵事件*/
???}
??}
??else
??{
???;/*idle?code*/
??}
?}
}
/*********************************************
*FuncName?:?read_envt_flg_grp
*Description?:?讀取事件標志組?g_u8EvntFlgGrp?，
*?讀取完畢后將其清零。
*Arguments?:?void
*Return?:?void
*********************************************/
INT8U?read_envt_flg_grp(void)
{
?INT8U?u8FlgTmp?=?0;
?gbl_int_disable();
?u8FlgTmp?=?g_u8EvntFlgGrp;?/*讀取標志組*/
?g_u8EvntFlgGrp?=?0;?/*清零標志組*/
?gbl_int_enable();
?return?u8FlgTmp;
}
/*********************************************
*FuncName?:?uart0_isr
*Description?:?uart0?中斷服務函數(shù)
*Arguments?:?void
*Return?:?void
*********************************************/
void?uart0_isr(void)
{
?......
?push_uart_rcv_buf(new_rcvd_byte);?/*新接收的字節(jié)存入緩沖區(qū)*/
?gbl_int_disable();
?g_u8EvntFlgGrp?|=?FLG_UART;?/*設置?UART?事件標志*/
?gbl_int_enable();
?......
}
/*********************************************
*FuncName?:?tmr0_isr
*Description?:?timer0?中斷服務函數(shù)
*Arguments?:?void
*Return?:?void
*********************************************/
void?tmr0_isr(void)
{
?INT8U?u8KeyCode?=?0;
?......
?gbl_int_disable();
?g_u8EvntFlgGrp?|=?FLG_TMR;?/*設置?TMR?事件標志*/
?gbl_int_enable();
?......
?u8KeyCode?=?read_key();?/*讀鍵盤*/
?if(u8KeyCode)?/*有擊鍵操作？?*/
?{
??push_key_buf(u8KeyCode);?/*新鍵值存入緩沖區(qū)*/
??gbl_int_disable();
??g_u8EvntFlgGrp?|=?FLG_KEY;?/*設置?TMR?事件標志*/
??gbl_int_enable();
?}
?......
}
/*********************************************
*FuncName?:?exit0_isr
*Description?:?exit0?中斷服務函數(shù)
*Arguments?:?void
*Return?:?void
*********************************************/
void?exit0_isr(void)
{
?......
?gbl_int_disable();
?g_u8EvntFlgGrp?|=?FLG_EXI;?/*設置?EXI?事件標志*/
?gbl_int_enable();
?......
}

?

看一下程序清單 List9 這樣的程序結構，是不是和自己寫過的某些程序相似？對于事件驅(qū)動機制的這種實現(xiàn)方式， 我們還可以做得更絕一些， 形成一個標準的代碼模板，做一個包含位段和函數(shù)指針數(shù)組的結構體，位段里的每一個元素作為圖 5 那樣的事件標志位，然后在函數(shù)指針數(shù)組中放置各個事件處理函數(shù)的函數(shù)地址， 每個處理函數(shù)對應位段里的每個標志位。

這樣， main()函數(shù)中的事件處理代碼就可以做成標準的框架代碼。應該說，這樣的實現(xiàn)方式是很好的，足以輕松地應對實際應用中絕大多數(shù)的情況。但是，事件驅(qū)動機制用這樣的方式實現(xiàn)真的是完美的么？在我看來，這種實現(xiàn)方式至少存在兩個問題：

不同事件集中爆發(fā)時，無法記錄事件發(fā)生的前后順序。

同一事件集中爆發(fā)時，容易遺漏后面發(fā)生的那次事件。

圖 6 所示為某一時段單片機程序的執(zhí)行情況，某些特殊情況下，會出現(xiàn)上面提到的兩個問題。

圖中， f1 為某事件的處理函數(shù)， f2 為另一事件的處理函數(shù)， I1、 I2、 I3 為 3 個不同事件觸發(fā)的 ISR，假定 I1、 I2、 I3 分別對應事件 E1、 E2、 E3。從圖中可以看出，主函數(shù)在調(diào)用事件處理函數(shù) f1 的時候，發(fā)生了 2 次事件，主函數(shù)被 I1和 I2 中斷了 2 次， I1 和 I2 執(zhí)行的時候各自置位了相應的事件標志位。

函數(shù) f1 返回后， 主函數(shù)又調(diào)用了另一個事件處理函數(shù) f2， f2 執(zhí)行期間先后發(fā)生了 2 次同樣的事件， f2 被 I3 中斷了 2次，對應的事件標志位被連續(xù)置位了 2 次。

在圖 6 中我們當然可以看出 I1 先于 I2 執(zhí)行，即事件 E1 發(fā)生在事件 E2 之前，但是主函數(shù)再次讀取事件標志組 g_u8EvntFlgGrp 的時候， 看到的是兩個“同時” 被置位的標志位， 無法判斷出事件 E1 和 E2 發(fā)生的先后順序， 也就是說有關事件發(fā)生先后順序的信息丟失了， 這就是前面說的第 1 個問題：不同事件集中爆發(fā)時，無法記錄事件發(fā)生的前后順序。

在程序清單 List9 中， 主函數(shù)在處理事件時， 按照程序預先設定好的順序， 一個一個地處理發(fā)生的事件， 如果不同事件某時段集中爆發(fā)， 可能會出現(xiàn)事件的發(fā)生順序和事件的處理順序不一致的情況。倘若系統(tǒng)功能對事件的發(fā)生順序敏感，那么程序清單 List9 中的程序就不能滿足要求了。

同樣的道理，如果 I3 對應的事件 E3 是程序清單 List9 中 EXI 那樣的事件(這種事件沒有緩沖機制)， 事件 E3 第 2 次的發(fā)生就被遺漏了， 這就是前面所說的第 2 個問題：同一事件集中爆發(fā)時，容易遺漏后后面發(fā)生的事件。

如果系統(tǒng)功能對事件 E3 的發(fā)生次數(shù)敏感，程序清單 List9 中的程序也是不能滿足要求的。既然事件驅(qū)動機制這樣的實現(xiàn)方式存在缺陷， 那么有沒有一種更好的實現(xiàn)方式呢？當然有！把事件轉(zhuǎn)換成消息存入消息隊列就能完美解決這個問題， 只不過大家不要對我這種自導自演的行文方式產(chǎn)生反感就好 ?。

事件驅(qū)動與消息

什么是消息？消息是數(shù)據(jù)信息的一種存儲形式。從程序的角度看，消息就是一段存儲著特定數(shù)據(jù)的內(nèi)存塊， 數(shù)據(jù)的存儲格式是設計者預先約定好的， 只要按照約定的格式讀取這段內(nèi)存， 就能獲得消息所承載的有用信息。

消息是有時效性的。任何一個消息實體都是有生命周期的，它從誕生到消亡先后經(jīng)歷了生成、 存儲、 派發(fā)、 消費共 4 個階段：消息實體由生產(chǎn)者生成， 由管理者負責存儲和派發(fā)， 最后由消費者消費。

被消費者消費之后， 這個消息就算消亡了， 雖然存儲消息實體的內(nèi)存中可能還殘留著原來的數(shù)據(jù)， 但是這些數(shù)據(jù)對于系統(tǒng)來講已經(jīng)沒有任何意義了， 這也就是消息的時效性。說到這里，大家有沒有發(fā)現(xiàn)，這里的“消息” 和前面一直在說的“事件” 是不是很相似？把“消息” 的這些特點套用在“事件” 身上是非常合適的， 在我看來， 消息無非是事件的一個馬甲而已。

我們在設計單片機程序的時候，都懷著一個夢想，即讓程序?qū)κ录捻憫M可能的快，理想的情況下，程序?qū)κ录⒓错憫?，不能有任何延遲。這當然是不可能的，當事件發(fā)生時，程序總會因為這樣那樣的原因不能立即響應事件。

為了不至于丟失事件，我們可以先在事件相關的 ISR 中把事件加工成消息并把它存儲在消息緩沖區(qū)里， ISR 做完這些后立即退出。主程序忙完了別的事情之后，去查看消息緩沖區(qū)，把剛才 ISR 存儲的消息讀出來， 分析出事件的有關信息， 再轉(zhuǎn)去執(zhí)行相應的響應代碼， 最終完成對本次事件的響應。

只要整個過程的時間延遲在系統(tǒng)功能容許的范圍之內(nèi)， 這樣處理就沒有問題。將事件轉(zhuǎn)化為消息，體現(xiàn)了以空間換時間的思想。再插一句，雖然事件發(fā)生后對應的 ISR 立即被觸發(fā)，但是這不是嚴格意義上的“響應”， 頂多算是對事件的“記錄”， “記錄” 和“響應” 是不一樣的。事件是一種客觀的存在，而消息則是對這種客觀存在的記錄。

對于系統(tǒng)輸入而言，事件是其在時間維度上的描述；消息是其在空間維度上的描述，所以，在描述系統(tǒng)輸入這一功能上，事件和消息是等價的。對比一下程序清單 List9 中的實現(xiàn)方式， 那里是用全局標志位的方式記錄事件， 對于某些特殊的事件還配備了專門的緩沖區(qū)， 用來存儲事件的額外信息， 而這些額外信息單靠全局標志位是無法記錄的。

現(xiàn)在我們用消息+消息緩沖區(qū)的方式來記錄事件，消息緩沖區(qū)就成了所有事件共用的緩沖區(qū)，無論發(fā)生的事件有沒有額外的信息，一律以消息的形式存入緩沖區(qū) ?。

為了記錄事件發(fā)生的先后順序，消息緩沖區(qū)應該做成以“先入先出” 的方式管理的環(huán)形緩沖隊列。事件生成的消息總是從隊尾入隊，管理程序讀取消息的時候總是從隊頭讀取，這樣，消息在緩沖區(qū)中存儲的順序就是事件在時間上發(fā)生的順序，先發(fā)生的事件總是能先得到響應。

一條消息被讀取之后， 管理程序回收存儲這個消息的內(nèi)存， 將其作為空閑節(jié)點再插入緩沖隊列的隊尾，用以存儲將來新生成的消息。圖 7 所示為使用了消息功能的事件驅(qū)動機制示意圖。不知道有沒有人對圖中的“消費者”有疑問， 這個“消費者” 在程序中指的是什么呢？

既然這個事件/消息驅(qū)動機制是為系統(tǒng)應用服務的， 消費者當然就是指應用層的代碼了， 更明確一點兒的話， 消費者就是應用代碼中的狀態(tài)機 ?。

用消息的方法來實現(xiàn)事件驅(qū)動機制完全解決了前面提到的那兩個問題，即不同事件集中爆發(fā)時，無法記錄事件發(fā)生的前后順序。同一事件集中爆發(fā)時，容易遺漏后面發(fā)生的那次事件。對于第一種情況，消息(事件)在緩沖隊列中是以“先入先出” 的方式存儲的，存儲順序就代表了事件發(fā)生的先后順序。

對于第二種情況， 任何被 ISR 捕捉到的事件都會以一個獨立的消息實體存入緩沖隊列， 即使前后兩個是同一個事件， 只要 ISR 反應夠快就不會遺漏事件。實際上， ISR 的主要工作就是填寫消息實體， 然后將其存入緩沖隊列， 做這些工作只占用 CPU 很短的時間。

接下來再說一說這個消息機制在程序中如何實現(xiàn)。在程序中，消息機制可以看做是一個獨立的功能模塊，一個功能模塊的實現(xiàn)無非就是數(shù)據(jù)結構+算法。先來看消息機制的數(shù)據(jù)結構。這里的數(shù)據(jù)結構是指和消息機制有關的數(shù)據(jù)組織形式，包含 2 個部分：

消息節(jié)點自身的數(shù)據(jù)組織形式

消息緩沖區(qū)的數(shù)據(jù)組織形式

程序清單 List10 所示就是消息機制的數(shù)據(jù)結構 。

「程序清單List10：」

?

typedef?union?msg_arg?/*消息參數(shù)共用體*/
{
?INT8U?u8Arg;?/*成員：8 位無符號*/
?INT8U?s8Arg;?/*成員：8 位有符號*/
?#if?CFG_MSG_ARG_INT16_EN>0
?INT16U?u16Arg;?/*可選成員：16 位無符號*/
?INT16S?s16Arg;?/*可選成員：16 位有符號*/
?#endif
?#if?CFG_MSG_ARG_INT32_EN>0
?INT32U?u32Arg;?/*可選成員：32 位無符號*/
?INT32S?s32Arg;?/*可選成員：32 位有符號*/
?#endif
?#if?CFG_MSG_ARG_FP32_EN>0
?FP32?f32Arg;?/*可選成員：32 位單精度浮點*/
?#endif
?#if?CFG_MSG_ARG_PTR_EN>0
?void*?pArg;?/*可選成員：void 指針*/
?#endif
}MSG_ARG;

typedef?struct?_msg?/*消息結構體*/
{
?INT8U?u8MsgID;?/*消息?ID*/
?#if?CFG_MSG_USR_SUM?>?1
?INT8U?u8UsrID;?/*消費者?ID*/
?#endif
?MSG_ARG?uMsgArg;?/*應用消息參數(shù)*/
}?MSG;

typedef?struct?msg_box?/*消息緩沖區(qū)結構體*/
{
?INT8U?u8MBLock;?/*隊列上鎖標識*/
?INT8U?u8MsgSum;?/*隊列長度*/
?INT8U?u8MQHead;?/*隊列頭結點位置*/
?INT8U?u8MQTail;?/*隊列尾節(jié)點位置*/
?MSG?arMsgBox[CFG_MSG_SUM_MAX];?/*存放隊列的數(shù)組*/
}?MB;
static?MB?g_stMsgUnit;?/*消息管理單元全局變量*/

?

消息的數(shù)據(jù)結構包含 2 部分：消息頭和消息參數(shù)，在消息結構體 MSG 中， u8MsgID 和u8UsrID 就是消息頭，共用體 MSG_ARG 就是消息參數(shù)。

u8MsgID 是消息的類型標志，也就是生成此消息的事件的事件類型標志，程序根據(jù)這個成員選擇對應的事件處理函數(shù)；u8UsrID 是消息的消費者代號， 如果應用代碼中只有一個消費者，則成員 u8UsrID 可以忽略。MSG_ARG 就是消息附帶的參數(shù)，也就是事件的內(nèi)容信息。

系統(tǒng)中的事件是多種多樣的，有的事件只需要類型標志即可， 有的事件可能還需要整型變量存儲事件內(nèi)容， 還有的事件可能需要大塊的內(nèi)存來存儲一些附帶的數(shù)據(jù)。為了將各種類型的事件生成的消息納入統(tǒng)一管理， 要求 MSG_ARG 必須能存儲各種類型的數(shù)據(jù)，因此 MSG_ARG 被定義成了共用體。

從程序清單 List10 中可以看出， MSG_ARG 既可以存儲 8 位~32 位有符號無符號整型數(shù)據(jù)，又可以存儲單精度浮點， 還可以存儲 void* 型的指針變量， 而 void*的指針又可以強制轉(zhuǎn)換成任意類型的指針，所以 MSG_ARG 可以存儲指向任意類型的指針。

對于MSG_ARG中的某些成員， 還配備了預編譯常量 CFG_MSG_ARG_XXX_EN加以控制，如果實際應用中不需要這些耗費內(nèi)存較大的數(shù)據(jù)類型， 可以設置CFG_MSG_ARG_XXX_EN 去掉它們。全開的情況下， 每個消息節(jié)點占用 6 個字節(jié)的內(nèi)存， 最精簡的情況下， 每個消息節(jié)點只占用 2 個字節(jié)。

全局結構體變量 g_stMsgUnit 是消息緩沖區(qū)的數(shù)據(jù)結構。消息緩沖區(qū)是一個環(huán)形緩沖隊列，這里將環(huán)形隊列放在了一個一維數(shù)組中，也就是g_stMsgUnit 的成員 arMsgBox[]，數(shù)組元素的數(shù)據(jù)類型就是消息結構體 MSG ，數(shù)組的大小由預編譯常量 CFG_MSG_SUM_MAX 控制，該常量是環(huán)形緩沖隊列的最大容量。

理論上， CFG_MSG_SUM_MAX 值的選取越大越好，但考慮到單片機的 RAM 資源有CFG_MSG_SUM_MAX 值的選取要在資源消耗和實際最大需求之間折中， 只要能保證在最壞情況下環(huán)形緩沖隊列仍有裕量即可。用數(shù)組實現(xiàn)環(huán)形隊列還需要一些輔助變量，也就是 g_stMsgUnit 剩余的成員。

u8MBLock 是隊列的控制變量， u8MBLock>0 表示隊列處于鎖定/保護狀態(tài)，不能寫也不能讀， u8MBLock=0 表示隊列處于正常狀態(tài)，可寫可讀；u8MsgSum 是隊列長度計數(shù)器，記錄著當前隊列中存有多少條消息，存入一條消息u8MsgSum++，讀出一條消息 u8MsgSum--；

u8MQHead 記錄著當前隊頭消息節(jié)點在數(shù)組 arMsgBox[]中的位置，其值就是數(shù)組元素的下標，消息讀取的時候所讀出的就是 u8MQHead 所指向的節(jié)點，讀完之后 u8MQHead 向隊尾方向移動一個位置，指向新的隊頭節(jié)點；u8MQTail 記錄著當前隊尾消息節(jié)點在數(shù)組 arMsgBox[]中的位置，其值是數(shù)組元素的下標，新消息寫入之前， u8MQTail 向隊尾方向后移一個位置， 然后新寫入的消息存入 u8MQTail 所指向的空閑節(jié)點；

圖 8 所示為消息緩沖區(qū)結構體變量 g_stMsgUnit 的示意圖 。

有了數(shù)據(jù)結構，還要有對應的算法實現(xiàn)，消息機制的數(shù)據(jù)主體就是一個數(shù)組化了的環(huán)形隊列，環(huán)形隊列的算法就是我們所要的算法。消息機制是一個獨立的功能模塊，應該對外屏蔽其內(nèi)部實現(xiàn)細節(jié)，而僅對外界開放一定數(shù)量的接口函數(shù)，外界通過調(diào)用這些接口來使用消息功能，這也就是我在聲明 g_stMsgUnit 變量的時候使用了 static 關鍵詞的原因。

消息模塊的接口函數(shù)一共有 9 個：

void mq_init(void)?消息隊列初始化，負責初始化 g_stMsgUnit 。

void mq_clear(void)清空消息隊列，效果同 mq_init()，可有可無。

void mq_lock(void)消息隊列鎖定，鎖定的消息隊列不可讀不可寫。

void mq_unlock(void)消息隊列解鎖，解鎖后消息隊列恢復正常功能。

BOOL mq_is_empty(void)消息隊列判空，返回 TRUE 表示消息隊列當前為空，返回 FALSE 表示有消息存儲。

INT8U mq_get_msg_cur_sum(void)查詢消息隊列中當前存儲的消息總數(shù)，函數(shù)返回值為查詢結果

INT8U mq_get_msg_sum_max(void)查詢消息隊列的最大容量，函數(shù)返回值為查詢結果。

INT8U mq_msg_post_fifo(MSG* pMsg)向消息隊列中寄送消息，方式為先入先出，形參 pMsg 指向消息的備份內(nèi)存，函數(shù)返回操作結果。該函數(shù)多被 ISR 調(diào)用，所以必須為可重入函數(shù)。

INT8U mq_msg_req_fifo(MSG* pMsg)從消息隊列中讀取消息， 方式為先入先出， 函數(shù)將讀出的消息存入形參 pMsg 指向的內(nèi)存，函數(shù)返回操作結果。該函數(shù)被主程序調(diào)用， 可以不是可重入函數(shù)， 但要對共享數(shù)據(jù)進行臨界保護 ?。

事件/消息驅(qū)動機制是一個標準的通用的框架，配合 ISR，對任何系統(tǒng)輸入都能應對自如。事件/消息驅(qū)動機制屏蔽了應用層程序獲取各種系統(tǒng)輸入的工作細節(jié)，將系統(tǒng)輸入抽象整合， 以一種標準統(tǒng)一的格式提交應用代碼處理， 極大地減輕了應用層代碼獲取系統(tǒng)輸入的負擔， 應用層只需要專注于高級功能的實現(xiàn)就可以了。

從軟件分層的角度來看， 事件/消息驅(qū)動機制相當于驅(qū)動層和應用層之間的中間層， 這樣的層次結構如圖 9 。

圖9 中之所以驅(qū)動層和應用層之間還有接觸，是因為系統(tǒng)輸出響應的時候，應用層可能還需要直接調(diào)用驅(qū)動層提供的函數(shù)接口。如果一個單片機的軟件是圖 9 這樣的結構，并且應用層的程序使用狀態(tài)機來實現(xiàn)，在消息的驅(qū)動下使應用層的狀態(tài)機運轉(zhuǎn)起來， 那么這個軟件的設計思想就是整篇文章的主題：基于事件/消息驅(qū)動+狀態(tài)機結構的裸奔通用框架 。

程序框架：狀態(tài)機+事件/消息驅(qū)動

事件/消息驅(qū)動和狀態(tài)機是天生的搭檔，這對黃金組合是分析問題解決問題的利器 ?。

1、牛刀小試

規(guī)則描述：

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

通過按鍵控制 L1L2 的狀態(tài),每次狀態(tài)轉(zhuǎn)換只需按鍵 1 次

從上一次按鍵的時刻開始計時，如果 10 秒鐘之內(nèi)沒有按鍵事件，則不管當前 L1L2 狀態(tài)如何，一律恢復至初始狀態(tài)。

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

現(xiàn)在我們用狀態(tài)機+事件/消息驅(qū)動的思想來分析問題。系統(tǒng)中可提取出兩個事件：按鍵事件和超時事件，分別用事件標志 KEY 和 TOUT 代替。L1L2 的狀態(tài)及轉(zhuǎn)換關系可做成一個狀態(tài)機，稱為主狀態(tài)機，共 4 個狀態(tài)：LS_OFFOFF、LS_ONOFF、 LS_ONON、 LS_OFFON 。主狀態(tài)機會在事件 KEY 或 TOUT 的驅(qū)動下發(fā)生狀態(tài)遷移，各個狀態(tài)之間的轉(zhuǎn)換關系比較簡單，在此略過。

事件/消息驅(qū)動機制的任務就是檢測監(jiān)控事件 KEY 和 TOUT，并提交給主狀態(tài)機處理。檢測按鍵需要加入消抖處理，消抖時間定為 20ms， 10S 超時檢測需要一個定時器進行計時。

這里將按鍵檢測程序部分也做成一個狀態(tài)機，共有 3 個狀態(tài)：

WAIT_DOWN ：空閑狀態(tài)，等待按鍵按下

SHAKE ：初次檢測到按鍵按下，延時消抖

WAIT_UP ：消抖結束，確認按鍵已按下，等待按鍵彈起

按鍵狀態(tài)機的轉(zhuǎn)換關系可在圖 10 中找到。按鍵檢測和超時檢測共用一個定時周期為 20ms 的定時中斷，這樣就可以把按鍵檢測和超時檢測的代碼全部放在這個定時中斷的 ISR 中。我把這個中斷事件用 TICK 標記， 按鍵狀態(tài)機在 TICK 的驅(qū)動下運行， 按鍵按下且消抖完畢后觸發(fā) KEY 事件， 而超時檢測則對 TICK 進行軟時鐘計數(shù)，記滿 500 個 TICK 則超時 10S，觸發(fā) TOUT 事件。

有了上面的分析，實現(xiàn)這個功能的程序的結構就十分清晰了， 圖 10 是這個程序的結構示意圖，這張圖表述問題足夠清晰了，具體的代碼就不寫了。仔細瞅瞅，是不是有點兒那個意思了？

如果忽略定時中斷 ISR 中的細節(jié)，圖 10 中的整個程序結構就是事件/消息驅(qū)動+主狀態(tài)機的結構， ISR 是消息的生產(chǎn)者，與消息緩沖、派發(fā)相關的程序部分是管理者，而主狀態(tài)機則是消息的消費者，應用層代碼中只有這一個狀態(tài)機，是消息的唯一消費者。

這個結構就是通用框架 GF1.0 的標準結構：多個 ISR + 一個消息緩沖區(qū) + 一個應用層主狀態(tài)機。ISR 生成的消息(事件)全部提交主狀態(tài)機處理， 在消息的驅(qū)動下主狀態(tài)機不斷地遷移。

如果把應用層主狀態(tài)機看做是一臺發(fā)動機， 那么 ISR 生成的消息則是燃料， 事件不斷的發(fā)生， 消息不斷的生成，有了燃料(消息)的供給，發(fā)動機(主狀態(tài)機)就能永不停息地運轉(zhuǎn)。

接下來關注一下圖 10 中的 ISR， 這個 ISR 里面的內(nèi)容是很豐富的， 里面還套著 2 個小狀態(tài)機：按鍵狀態(tài)機和計時狀態(tài)機。按鍵狀態(tài)機自不必說， 這個計時部分也可以看做是一個狀態(tài)機，不過這個狀態(tài)機比較特殊，只有一個狀態(tài) DELAY。

既然是狀態(tài)機， 想要跑起來就需要有事件來驅(qū)動， 在這個 ISR 里， 定時器的中斷事件 TICK就是按鍵狀態(tài)機和計時狀態(tài)機的驅(qū)動，只不過這兩個事件驅(qū)動+狀態(tài)機結構沒有消息緩沖，當然也不需要消息緩沖，因為狀態(tài)機在 ISR 中，對事件是立即響應的。

從宏觀上看，圖 10 中是事件/消息驅(qū)動+狀態(tài)機，從微觀上看，圖 10 中的 ISR 也是事件驅(qū)動+狀態(tài)機。ISR 中的狀態(tài)機在遷移過程中生成消息(事件)，而這些消息(事件)對于主狀態(tài)機來講又是它自己的驅(qū)動事件。事件的級別越高， 事件自身也就越抽象， 描述的內(nèi)容也就越接近人的思維方式。我覺得這種你中有我我中有你的特點正是事件驅(qū)動+狀態(tài)機的精髓所在 ?。

2、通用框架GF1.0

前面說過， 狀態(tài)機總是被動地接受事件， 而 ISR 也只是負責將消息(事件)送入消息緩沖區(qū)，這些消息僅僅是數(shù)據(jù)，自己肯定不會主動地跑去找狀態(tài)機。那么存儲在緩沖區(qū)中的消息(事件)是怎么被發(fā)送到目標狀態(tài)機呢？

把消息從緩沖區(qū)中取出并送到對應的狀態(tài)機處理，這是狀態(tài)機調(diào)度程序的任務，我把這部分程序稱作狀態(tài)機引擎(State Machine Engine ， 簡寫作 SME)。圖 11 是 SME 的大致流程圖。

從圖 11 可以看出， SME 的主要工作就是不斷地查詢消息緩沖隊列，如果隊列中有消息，則將消息按先入先出的方式取出， 然后送入狀態(tài)機處理。SME 每次只處理一條消息， 反復循環(huán)，直到消息隊列中的消息全部處理完畢。

當消息隊列中沒有消息時， CPU 處于空閑狀態(tài)， SME 轉(zhuǎn)去執(zhí)行“空閑任務”?？臻e任務指的是一些對單片機系統(tǒng)關鍵功能的實現(xiàn)無關緊要的工作，比如喂看門狗、算一算 CPU 使用率之類的工作，如果想降低功耗，甚至可以讓 CPU 在空閑任務中進入休眠狀態(tài)，只要事件一發(fā)生， CPU 就會被 ISR 喚醒，轉(zhuǎn)去執(zhí)行消息處理代碼。

實際上， 程序運行的時候 CPU 大部分時間是很“閑” 的， 所以消息隊列查詢和空閑任務這兩部分代碼是程序中執(zhí)行得最頻繁的部分，也就是圖 11 的流程圖中用粗體框和粗體線標出的部分。

如果應用層的主狀態(tài)機用壓縮表格驅(qū)動法實現(xiàn)，結合上面給出的消息模塊， 則GF1.0 的狀態(tài)機引擎代碼如程序清單 List11 所示。

「程序清單List11：」

?

void?sme_kernel(void);
/***************************************
*FuncName?:?main
*Description?:?主函數(shù)
*Arguments?:?void
*Return?:?void
*****************************************/
void?main(void)
{
?sys_init();
?sme_kernel();?/*GF1.0?狀態(tài)機引擎*/
}
/***************************************
*FuncName?:?sme_kernel
*Description?:?裸奔框架?GF1.0?的狀態(tài)機引擎函數(shù)
*Arguments?:?void
*Return?:?void
*****************************************/
void?sme_kernel(void)
{
?extern?struct?fsm_node?g_arFsmDrvTbl[];?/*狀態(tài)機壓縮驅(qū)動表格*/
?INT8U?u8Err?=?0;?/**/
?INT8U?u8CurStat?=?0;?/*狀態(tài)暫存*/
?MSG?stMsgTmp;?/*消息暫存*/
?struct?fsm_node?stNodeTmp?=?{NULL,?0};?/*狀態(tài)機節(jié)點暫存*/
?memset((void*)(&stMsgTmp),?0,?sizeof(MSG));?/*變量初始化*/
?gbl_int_disable();?/*關全局中斷*/
?mq_lock();?/*消息隊列鎖定*/
?mq_init();?/*消息隊列初始化*/
?mq_unlock();?/*消息隊列解鎖*/
?fsm_init();?/*狀態(tài)機初始化*/
?gbl_int_enable();?/*開全局中斷*/
?
?while(1)
?{
??if(mq_is_empty()?==?FALSE)
??{
???u8Err?=?mq_msg_req_fifo(&stMsgTmp);?/*讀取消息*/
???if(u8Err?==?MREQ_NOERR)
???{
????u8CurStat?=?get_cur_state();?/*讀取當前狀態(tài)*/
????stNodeTmp?=?g_arFsmDrvTbl[u8CurStat];?/*定位狀態(tài)機節(jié)點*/
????if(stNodeTmp.u8StatChk?==?u8CurStat)
????{
?????u8CurStat?=?stNodeTmp.fpAction(&stMsgTmp);?/*消息處理*/
?????set_cur_state(u8CurStat?);?/*狀態(tài)遷移*/
????}
????else
????{
?????state_crash(u8CurStat?);?/*非法狀態(tài)處理*/
????}
???}
??}
??else
??{
???idle_task();?/*空閑任務*/
??}
?}
}

?

3、狀態(tài)機與ISR在驅(qū)動程序中的應用

在驅(qū)動層的程序中使用狀態(tài)機和 ISR 能使程序的效率大幅提升。這種優(yōu)勢在通信接口中最為明顯，以串口程序為例。

單片機和外界使用串口通信時大多以數(shù)據(jù)幀的形式進行數(shù)據(jù)交換，一幀完整的數(shù)據(jù)往往包含幀頭、接收節(jié)點地址、幀長、數(shù)據(jù)正文、校驗和幀尾等內(nèi)容，圖 12 所示為這種數(shù)據(jù)幀的常見結構。

圖12 表明的結構只是數(shù)據(jù)幀的一般通用結構， 使用時可根據(jù)實際情況適當簡化， 例如如果是點對點通信， 那么接收節(jié)點地址 FRM_USR 可省略；如果通信線路沒有干擾， 可確保數(shù)據(jù)正確傳輸，那么校驗和 FRM_CHKSUM 也可省略。

假定一幀數(shù)據(jù)最長不超過 256 個字節(jié)且串口網(wǎng)絡中通信節(jié)點數(shù)量少于 256 個，那么幀頭、接收節(jié)點地址、幀長、幀尾都可以用 1 個字節(jié)的長度來表示。雖然數(shù)據(jù)的校驗方式可能不同，但校驗和使用 1~4 個字節(jié)的長度來表示足以滿足要求。

先說串口接收， 在裸奔框架 GF1.0 的結構里， 串口接收可以有 2 種實現(xiàn)方式：ISR+消息 orISR+緩沖區(qū)+消息。ISR+消息比較簡單， ISR 收到一個字節(jié)數(shù)據(jù)，就把該字節(jié)以消息的形式發(fā)給應用層程序，由應用層的代碼進行后續(xù)處理。這種處理方式使得串口接收 ISR 結構很簡單，負擔也很輕， 但是存在 2 個問題。

數(shù)據(jù)的接收控制是一個很底層的功能， 按照軟件分層結構， 應用代碼不應該負責這些工作，混淆職責會使得軟件的結構變差；用消息方式傳遞單個的字節(jié)效率太低， 占用了太多的消息緩沖資源，如果串口波特率很高并且消息緩沖區(qū)開的不夠大，會直接導致消息緩沖區(qū)溢出。

相比之下， ISR+緩沖區(qū)+消息的處理方式就好多了， ISR 收到一個字節(jié)數(shù)據(jù)之后， 將數(shù)據(jù)先放入接收緩沖區(qū)，等一幀數(shù)據(jù)全部接收完畢后(假設緩沖區(qū)足夠大)，再以消息的形式發(fā)給應用層，應用層就可以去緩沖區(qū)讀取數(shù)據(jù)。

對于應用層來講，整幀數(shù)據(jù)只有數(shù)據(jù)正文才是它想要的內(nèi)容，數(shù)據(jù)幀的其余部分僅僅是數(shù)據(jù)正文的封皮， 沒有意義。從功能劃分的角度來看， 確保數(shù)據(jù)正確接收是 ISR 的職責， 所以這部分事情應該放在 ISR 中做，給串口接收 ISR 配一個狀態(tài)機，就能很容易的解決問題。圖 13為串口接收 ISR 狀態(tài)轉(zhuǎn)換圖。

圖13 中的數(shù)據(jù)幀使用 16 位校驗和，發(fā)送順序高字節(jié)在前，低字節(jié)在后。接收緩沖區(qū)屬于 ISR 和主程序的共享資源，必須實現(xiàn)互斥訪問，所以 ISR 收完一幀數(shù)據(jù)之后對緩沖區(qū)上鎖， 后面再發(fā)生的 ISR 發(fā)現(xiàn)緩沖區(qū)上鎖之后， 不接收新的數(shù)據(jù)， 也不修改緩沖區(qū)中的數(shù)據(jù)。

應用層程序收到消息， 讀取緩沖區(qū)中的數(shù)據(jù)之后再對緩沖區(qū)解鎖， 使能 ISR 接收串口數(shù)據(jù)和對緩沖區(qū)的寫入。數(shù)據(jù)接收完畢后，應該校驗數(shù)據(jù)，只有校驗結果和收到的校驗和相符，才能確信數(shù)據(jù)正確接收。

數(shù)據(jù)校驗比較耗時，不適合在 ISR 中進行，所以應該放在應用代碼中處理。這樣實現(xiàn)的串口接收 ISR 比較復雜，代碼規(guī)模比較大，看似和 ISR 代碼盡量簡短，執(zhí)行盡量迅速的原則相悖， 但是由于 ISR 里面是一個狀態(tài)機， 每次中斷的時候 ISR 僅執(zhí)行全部代碼的一小部分，之后立刻退出，所以執(zhí)行時間是很短的，不會比“ISR+消息” 的方式慢多少。

串口發(fā)送比串口接收要簡單的多，為提高效率也是用 ISR+緩沖區(qū)+消息的方式來實現(xiàn)。程序發(fā)送數(shù)據(jù)時調(diào)用串口模塊提供的接口函數(shù)， 接口函數(shù)通過形參獲取要發(fā)送的數(shù)據(jù)， 將數(shù)據(jù)打包后送入發(fā)送緩沖區(qū)， 然后啟動發(fā)送過程， 剩下的工作就在硬件和串口發(fā)送 ISR 的配合下自動完成，數(shù)據(jù)全部發(fā)送完畢后， ISR 向應用層發(fā)送消息，如果有需要，應用層可以由此獲知數(shù)據(jù)發(fā)送完畢的時刻。圖 14 為串口發(fā)送 ISR 的狀態(tài)轉(zhuǎn)換圖。

上面只是討論了串口設備的管理方法， 其實這種狀態(tài)機+ISR 的處理方式可以應用到很多的硬件設備中，一些適用的場合：

標準的或自制的單總線協(xié)議 (狀態(tài)機+定時中斷+消息)

用 I/O 模擬 I2C 時序并且通信速率要求不高 (狀態(tài)機+定時中斷+消息)

數(shù)碼管動態(tài)掃描 (狀態(tài)機+定時中斷)

鍵盤動態(tài)掃描 (狀態(tài)機+定時中斷 ?）

小結

裸奔框架 GF1.0 處處體現(xiàn)著事件驅(qū)動+狀態(tài)機的思想， 大到程序整體的組織結構， 小到某個ISR 的具體實現(xiàn)，都有這對黃金組合的身影。從宏觀上看， 裸奔框架 GF1.0 是一個 ISR+消息管理+主狀態(tài)機的結構， 如圖 15 所示。

不管主狀態(tài)機使用的是 FSM(有限狀態(tài)機)還是 HSM(層次狀態(tài)機)， GF1.0 中有且只有 1 個主狀態(tài)機。主狀態(tài)機位于軟件的應用層， 是整個系統(tǒng)絕對的核心， 承擔著邏輯和運算功能， 外界和單片機系統(tǒng)的交互其實就是外界和主狀態(tài)機之間的交互， 單片機程序的其他部分都是給主狀態(tài)機打雜的。

從微觀上看， 裸奔框架 GF1.0 中的每一個 ISR 也是事件驅(qū)動+狀態(tài)機的結構。ISR 的主要任務是減輕主狀態(tài)機獲取外界輸入的負擔， ISR 負責處理獲取輸入時硬件上繁雜瑣細的操作，將各種輸入抽象化，以一種標準統(tǒng)一的數(shù)據(jù)格式(消息)提交給主狀態(tài)機，好讓主狀態(tài)機能專注于高級功能的實現(xiàn)而不必關注具體的細節(jié)。

裸奔框架 GF1.0 應用的難點在于主狀態(tài)機的具體實現(xiàn)，對于一個實際的應用，不管功能多復雜， 都必須將這些功能整合到一個主狀態(tài)機中來實現(xiàn)。這既要求設計者對系統(tǒng)的目標功能有足夠詳細的了解， 還要求設計者對狀態(tài)機理論有足夠深的掌握程度， 如果設計出的狀態(tài)機不合理，程序的其他部分設計得再好，也不能很好的實現(xiàn)系統(tǒng)的要求。

將實際問題狀態(tài)機化，最重要的是要合理地劃分狀態(tài)，其次是要正確地提取系統(tǒng)事件，既不能遺漏， 也不能重復。有了狀態(tài)和事件， 狀態(tài)轉(zhuǎn)換圖的骨架就形成了， 接下來就是根據(jù)事件確定狀態(tài)之間的轉(zhuǎn)換關系，自頂向下，逐步細化，最終實現(xiàn)整個功能。

　　審核編輯：湯梓紅