新聞中心

EEPW首頁 > 消費電子 > 小容量單片機系統(tǒng)的C語言程序結構

小容量單片機系統(tǒng)的C語言程序結構

——
作者:希麥特電子科技 彭光紅 時間:2007-11-08 來源:單片機及嵌入式系統(tǒng)應用 收藏

引 言:

  2002年初,筆者著手寫一個IC卡預付費電表的工作程序,該電表使用Philips公司的8位51擴展型87LPC764,要求實現(xiàn)很多功能,包括熄顯示、負荷計算與控制、指示閃爍以及電表各種參數(shù)的查詢等,總之,要使用時間的單元很多。筆者當時使用ASM51完成了這個程序的編寫,完成后的程序量是2KB多一點。后來,由于種種原因,這個程序并沒有真正使用,只是作了一些改動之后用在一個老化設備上進行計時與負荷計算。約一年后,筆者又重新改寫了這些代碼。

1 系統(tǒng)的改進

  可以說,這個用ASM51實現(xiàn)的代碼是沒有什么組織性可言的,要什么功能就加入什么功能,弄得程序的結構非常松散,其實這也是導致筆者最終決定重新改寫這些代碼的原因。

  大家知道,87LPC764有4KB的Flash ROM,而筆者的程序量只有2KB多點,因而第一個想法是改用C語言作為主要的開發(fā)語言,應該不至于導致代碼空間不夠用。其次,考慮到需要定時功能的模塊(或稱任務,以下統(tǒng)稱任務)較多,有必要對這些任務進行有序的管理。筆者考慮使用時間片輪詢方式,即給每個要求時間管理的任務以一個時間間隔,時間間隔一到,即運行其代碼,達到合理使用系統(tǒng)定時器資源的目的。就51系統(tǒng)而言,一般至少一個定時器可用來進行時間片的輪詢?;谝陨系南敕?,構造了下述數(shù)據(jù)類型。

typedef unsigned char uInt8
typedef struct {
void (*proc)(void); //處理程序
uInt8 ms_count; //時間片大小
} _op_;
數(shù)據(jù)結構定義好之后,接著就是實現(xiàn)代碼,包括三部分,即初始化數(shù)據(jù)、時間片的刷新與時間到執(zhí)行。
初始化數(shù)據(jù)。
#define proc_cnt 0x08 //定義過程或任務數(shù)量
//任務棧初始化
code _op_ Op[proc_cnt]={{ic_check,10},{disp_loop,100},
{calc_power,150},{set_led,2},…
};
//設置時間片初始值
data uInt8 time_val[proc_cnt]={10,100,150,2,…};
時間片刷新。
void time_int1(void) interrupt 3
{ uInt8 cnt;
Time_Counter:=Time_Unit;
for(cnt=0;cnt<proc_cnt;cnt++)
{ time_val[cnt]--;
}
}
任務的執(zhí)行。
void main(void){
uInt8 cnt;
init(); //程序初始化
interrupt_on(); //打開中斷
do{
for(cnt=0;cnt<proc_cnt;cnt++)
{ if(!time_val[cnt])
{ time_val[cnt]=Op[cnt].ms_count;
Op[cnt].proc();
}
}
}while(1);
}

  在上面的結構定義中,proc是不能帶參數(shù)的,各任務之間的通信可以定義一個參數(shù)內(nèi)存塊,通過一種機制進行數(shù)據(jù)信息交互,如定義一個全局變量。對于小容量系統(tǒng)而言,需要這樣做的任務并不多,總任務量也不會太多,因而這種協(xié)調(diào)并不太難處理。

  也許大家都有這樣的認識,即一個實時系統(tǒng)中,差不多所有的具體任務都是有時間屬性的,即使是不需要定時的過程或任務,也不見得要時時進行查詢與刷新。如IC卡介質檢測,保證每秒一次就足夠了。因而,這些任務也可以列入到這個結構中來。

  在以上的程序代碼中,考慮到系統(tǒng)的RAM限制,不能像一些實時OS那樣將任務棧建立在RAM中。筆者將任務棧建立在代碼空間,因而不能在程序運行時動態(tài)地加入任務,因此要求在程序編譯時,任務棧已經(jīng)確定。同時,定義一組計數(shù)值旗標time_val,記錄程序運行時的時間量,并在一個定時器中斷中對其進行刷新。改變時間片刷新中斷過程語句Time_Counter:=Time_Unit;中的Time_Unit,可以改變系統(tǒng)時間片的刷新粒度,一般這個值由系統(tǒng)的最小時間度量值確定。

  同時,由任務的執(zhí)行流程可知,此種系統(tǒng)構造并沒有改變其前/后臺系統(tǒng)的性質,只是對后臺邏輯操作序列進行了有效管理。同時,如果將任務執(zhí)行流程進行一些更改,并保證時間片小的任務前置,如下述程序。
do{
for(cnt=0;cnt<proc_cnt;cnt++){
if(!time_val[cnt]){
time_val[cnt]=Op[cnt].ms_count;
Op[cnt].proc();
break; //執(zhí)行完成后,重新進行優(yōu)先調(diào)度
}
}
}while(1);

  則系統(tǒng)變?yōu)橐粋€以執(zhí)行頻率為優(yōu)先級的任務調(diào)度系統(tǒng)。當然,設置此種方式得非常小心,并要注意時間片的分配,如果時間片過小,則可能導致執(zhí)行頻率較低的任務難以被執(zhí)行;而如果存在兩個同樣的時間片,則更加危險,可能導致第二個具有相同時間片的任務不被執(zhí)行,因而,時間片的分配要合理,并保證其唯一性。

2 性能分析與任務拆分

  以上兩種任務管理方式,前一種按任務棧的順序與時間片的大小依次進行調(diào)度,暫且稱其為流水作業(yè)調(diào)度;而后一種,且稱其為頻率優(yōu)先調(diào)度。兩種方式各有優(yōu)缺點。流水作業(yè)調(diào)度的各任務具有等同優(yōu)先級,時間片一到即會被按序調(diào)用,時間片大小的次序與唯一性不作要求;缺點是可能導致時間片小的,即要求執(zhí)行得較快的任務等待過長的時間。頻率優(yōu)先調(diào)度的各任務按其時間片的大小,即執(zhí)行頻率劃分優(yōu)先級,時間片小的任務,其執(zhí)行頻率高,總是具有較高的優(yōu)先權,但時間片的分配得協(xié)調(diào),否則可能會導致執(zhí)行頻率低的任務長時間等待。

  要特別注意的是,兩種方式都有可能導致一些任務長時間等待,時間片所設定的時間也因此不能作為精確時間的依據(jù),根據(jù)系統(tǒng)的要求或需要,甚至要在任務執(zhí)行過程中進行某些保護工作,如中斷屏蔽等,因而在進行任務規(guī)劃時要注意。如果一個任務較繁瑣或可能要等待很長時間,則應當考慮任務的拆分,把一個較大的任務細化為較小的任務,把一個費時長的任務劃分為多個費時小的任務,協(xié)同完成其功能。如在等待時間長的情況下,可附加一個定時任務,定時任務到則發(fā)送一個消息旗標,主過程沒有檢測到消息旗標就馬上返回,否則繼續(xù)執(zhí)行。下面是示例代碼,假定該任務將等待很長時間,現(xiàn)將其拆分為兩個任務proc1與proc2協(xié)同完成原來的工作,proc1每100個時間單位執(zhí)行一次,而proc2每200個時間單位執(zhí)行一次。

//定義兩個任務,并將其加入到任務棧中。
code _op_ Op[proc_cnt]={…,{proc1,100},{proc2,200}};
data int time1_Seg; //定義一個全局旗標
//任務實現(xiàn)
void proc1(void){
if (time1_Seg)
exit;
else
time1_Seg=const_Time1; //如果時間到了,則恢復初值并
//接著執(zhí)行下列代碼。
… //任務實際執(zhí)行代碼
}

void proc2(void){ 
if(time1_Seg) 
time1_Seg--; 
}

  由上例可以看出,任務拆分后,幾乎不占過多的CPU時間,使得任務的等待時間大減,讓CPU有足夠的時間進行任務管理與調(diào)度。同時也讓程序的結構性與可讀性大為加強。

結 語

  基于上述思路與結構對IC卡電表工作程序進行全部改寫后,系統(tǒng)的結構性能得到了很大改善。全部編寫完成后,程序代碼量約為3KB多一點,可見此種結構的程序構造并不會造成很大的系統(tǒng)開銷(大部分開銷是由于使用C的結果),卻使開發(fā)得到了簡化。這只要將系統(tǒng)細分為一系列任務,然后加入到任務棧進行編譯即可,很適合小容量單片機系統(tǒng)的開發(fā),而筆者也在多個系統(tǒng)中成功地應用了此種結構。



評論


相關推薦

技術專區(qū)

關閉