1 傳統(tǒng)編程結(jié)構(gòu)的局限性

當(dāng)不使用RTOS時(shí)，嵌入式軟件通常采用兩種傳統(tǒng)的編程結(jié)構(gòu)進(jìn)行編程，一種叫“前后臺(tái)廳式”或者叫“超級(jí)循環(huán)結(jié)構(gòu)”，本質(zhì)上是事件觸發(fā)的編程方式；另一種叫時(shí)間觸發(fā)編程模式，Michael J．Pont的“基于時(shí)間觸發(fā)的編程模式”即屬于此。

在實(shí)際工作中，當(dāng)系統(tǒng)稍微復(fù)雜時(shí)，會(huì)發(fā)現(xiàn)這兩種方式都有一定局限性，下面以一個(gè)實(shí)際產(chǎn)品設(shè)計(jì)中遇到的問題為例來說明。在設(shè)計(jì)一個(gè)用于配電柜的壁裝式智能配電儀表時(shí)，CPU的程序設(shè)計(jì)需完成以下任務(wù)：

①每半秒對(duì)前顯示屏的顯示數(shù)據(jù)進(jìn)行一次刷新。
②每0．1 s對(duì)DI／DO進(jìn)行一次刷新。
③每0．2 s對(duì)鍵盤進(jìn)行一次掃描。
④每半秒對(duì)測量數(shù)據(jù)進(jìn)行一次重新采集和計(jì)算。
⑤異步串行口與上位機(jī)使用Modhus通信，速率最高1 9 200 bps。
⑥CPU通過I2C總線與時(shí)鐘芯片和EEPROM通信。
⑦CPU通過SPI總線與LED數(shù)碼管及采集芯片通信。
⑧CPU要對(duì)所采集的6路信號(hào)進(jìn)行FFT變換。
⑨當(dāng)系統(tǒng)掉電時(shí)，CPU要能快速響應(yīng)，把當(dāng)前的電度底數(shù)寫入EEPROM中。

上述任務(wù)中，任務(wù)⑤和任務(wù)⑨是強(qiáng)實(shí)時(shí)性的，如果對(duì)串口的收發(fā)事件得不到及時(shí)響應(yīng)，接收時(shí)會(huì)導(dǎo)致字節(jié)丟失，發(fā)送時(shí)會(huì)導(dǎo)致字節(jié)間時(shí)間間隔太大，造成接收方的Modbus幀定界錯(cuò)誤，對(duì)系統(tǒng)掉電事件如果不能及時(shí)響應(yīng)會(huì)造成EEPROM的寫入失敗。其他任務(wù)只要在指定的周期內(nèi)能得到執(zhí)行就行，但是任務(wù)⑧比較特殊，使用通常的8位CPU進(jìn)行6種信號(hào)的FFT變換，哪怕每種信號(hào)只做128點(diǎn)的FFT，運(yùn)算一次也要好幾秒。下面來看用傳統(tǒng)編程結(jié)構(gòu)實(shí)現(xiàn)上述設(shè)計(jì)時(shí)遇到的困擾。

1．1 使用“前后臺(tái)方式”進(jìn)行編程

使用“前后臺(tái)方式”進(jìn)行編程時(shí)，為保證任務(wù)⑤的及時(shí)性，使用了UART中斷，當(dāng)UART完成一個(gè)字節(jié)的收發(fā)后產(chǎn)生中斷，在中斷程序中將接收到的字符保存在接收緩沖區(qū)或從發(fā)送緩沖區(qū)取下一個(gè)待發(fā)字符裝入U(xiǎn)ART進(jìn)行發(fā)送，對(duì)Modbus協(xié)議的處理可以單獨(dú)用一個(gè)任務(wù)在中斷外處理，這保證了巾斷程序的簡短。為保證任務(wù)⑨響應(yīng)的及時(shí)性，也必須為它安排一個(gè)中斷。因?yàn)楫?dāng)系統(tǒng)掉電時(shí)，系統(tǒng)只有不到10 ms的過渡時(shí)間，系統(tǒng)如果不能在這個(gè)時(shí)間內(nèi)完成相關(guān)的操作，系統(tǒng)電壓將跌落至有效電壓以下而喪失工作能力。

安排好了后臺(tái)的中斷任務(wù)后再來看看前臺(tái)的任務(wù)如何完成。這里遇到的最大的挑戰(zhàn)是對(duì)任務(wù)⑧的處理，因?yàn)槿蝿?wù)⑧需要的執(zhí)行時(shí)間太長了，簡單的把它當(dāng)成一個(gè)任務(wù)處理將影響系統(tǒng)對(duì)其他任務(wù)的響應(yīng)，在超級(jí)循環(huán)中的代碼結(jié)構(gòu)如下：

while(1){
任務(wù)①；
任務(wù)②；
……
任務(wù)⑧；
}

由于任務(wù)⑧執(zhí)行一次要幾秒鐘的時(shí)間，整個(gè)超級(jí)循環(huán)執(zhí)行一次至少大于任務(wù)⑧需要的時(shí)間，也就是說這個(gè)超級(jí)循環(huán)循環(huán)一次要幾秒鐘時(shí)間，將滿足不了各任務(wù)響應(yīng)時(shí)間的要求。

要解決這個(gè)問題，只有把任務(wù)⑧拆分成很多個(gè)子任務(wù)，將每個(gè)子任務(wù)的耗時(shí)壓縮到10 ms左右，并定義好各個(gè)子任務(wù)完成后的狀態(tài)，在超級(jí)大循環(huán)中每次根據(jù)狀態(tài)只執(zhí)行一個(gè)子任務(wù)，程序結(jié)構(gòu)如下：

while(1){
任務(wù)①；
任務(wù)②；
……
switch(子任務(wù)狀態(tài)){
case 子任務(wù)狀態(tài)①：
子任務(wù)①；
break；
……
case 子任務(wù)狀態(tài)②：
子任務(wù)②；
break；
……
case 子任務(wù)狀態(tài)：
子任務(wù)；
break；
}
}

這樣，就需要把一個(gè)耗時(shí)幾秒的FFT運(yùn)算任務(wù)拆分成幾百個(gè)耗時(shí)10 ms左有的子任務(wù)，這顯然是不可接受的。除此之外，超級(jí)大循環(huán)結(jié)構(gòu)隱含的一個(gè)缺點(diǎn)就是隨著任務(wù)的增加，循環(huán)體的執(zhí)行時(shí)間是線性增加的，在實(shí)際設(shè)計(jì)中即使沒有像任務(wù)⑧那樣的高耗時(shí)任務(wù)，當(dāng)系統(tǒng)功能增加時(shí)要保證系統(tǒng)響應(yīng)的及時(shí)性也是一個(gè)不小的挑戰(zhàn)。