單片機就那點資源,為啥還要用RTOS?
對於搞單片機的特別用8051系列工程師來說,談到單片機的RTOS,很多時候會問一句:「為什麼要用RTOS?單片機就這一點資源,使用RTOS能保證效率嗎?」
對於這個問題,我會反問:「你用單片機的目的是什麼?是為了用單片機的C編程,單片機的彙編編程甚至於用單片機的二進位指令編程?」上個世紀80年代,工程師用二進位指令給Z80編程,現在還有誰在用?現在還有人死抱著彙編不放,但越來越多的人工程師使用C編程(我起初也是使用彙編的),為什麼?因為我們的目的是在有限的時間甚至是不充足的時間內把項目保質保量的完成!使用什麼工具和方法是次要的(如果你的項目以成本放在第一位,則另當別論,這時,也是要考慮開發時間的)。時間就是金錢啊,一個產品在單片機上增加些許成本是可以接受的。況且,使用8051系列單片機時,單片機資源也常有富餘,CPU一般情況也只是空轉,這就為它使用RTOS創造了條件。
那麼,使用RTOS的好處呢?我舉一個例子吧。假設我們編一個串列通訊程序,通訊協議如下:
數據包長度為NBYTE,起始位元組為STARTBYTE1,STARTBYTE2,最後一個位元組為檢驗和,中間位元組不可能出現連續出現STARTBYTE1,STARTBYTE2。
第一種方法,在中斷中處理協議:
unsigned char Buf[NBYTE-2];bit GetRight=0;
void comm(void) interrupt 4//"串列口中斷"{
static unsigned char Sum,Flag=0,i;
unsigned char temp;
if(RI==1)
{
RI=0;
temp=SBUF;
switch(Flag)
{
case 0:
if(temp==STARTBYTE1)
{
Flag=1;
}
break;
case 1:
if(temp==STARTBYTE2)
{
Sum=STARTBYTE1+STARTBYTE2;
i=0;
Flag=2;
break;
}
if(temp==STARTBYTE1) break;
Flag=0;
break;
case 2:
if(temp==STARTBYTE1)
{
Flag=3;
break;
}
Sum+=temp;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=temp;
break;
case 3:
if(temp==STARTBYTE2)
{
Sum=STARTBYTE1+STARTBYTE2;
Flag=2;
i=0;
break;
}
Sum+=STARTBYTE1;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=STARTBYTE1;
if(temp==STARTBYTE1)
{
break;
}
Sum+=temp;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=temp;
Flag=2;
break;
}
}}
第二種方法,使用隊列中斷函數:
void comm(void) interrupt 4//"串列口中斷"{
if(RI==1)
{
RI=0;
SBUF 入隊;
}}
主程序不斷調用的函數:
unsigned char Buf[NBYTE-2];
unsigned char ReadSerial(unsigned char *cp){
unsigned char i;
unsigned char temp,Sum;
temp=隊列中數據個數;
if(temp
出隊 temp;
if(temp!=STARTBYTE1) return 0;
temp=隊列首位元組;
if(temp!=STARTBYTE2) return 0;
出隊 temp;
sum=STARTBYTE1+STARTBYTE2;
for(i=0;i
{
temp=隊列首位元組;
if(temp==STARTBYTE1)
{
temp=隊列次首位元組;
if(temp==STARTBYTE2) return 0;
}
出隊 temp;
*cp++=temp;
Sum+=temp;
}
temp=隊列首位元組;
Sum+=temp;
if(Sum!=0) return 0;
出隊 temp;
return 1;}
第三種方法,使用RTOS中斷函數:
void comm(void) interrupt 4//"串列口中斷"{
OS_INT_ENTER();
if(RI==1)
{
RI=0;
OSIntSendSignal(RECIVE_TASK_ID);
}
OSIntExit();}
ID為RECIVE_TASK_ID的任務
void Recuve(void){
unsigned char temp,temp1,Sum,i;
OSWait(K_SIG,0);
temp=SBUF;
while(1)
{
while(1)
{
OSWait(K_SIG,0);
temp1=SBUF;
if((temp==STARTBYTE1)&&(temp1==STARTBYTE2)) break;
temp=temp1;
}
Sum=STARTBYTE1+STARTBYTE2;
OSWait(K_SIG,0);
temp=SBUF;
for(i=0;i
{
OSWait(K_SIG,0);
temp1=SBUF;
if((temp==STARTBYTE1)&&(temp1==STARTBYTE2))
{
OSWait(K_SIG,0);
temp=SBUF;
i=-1;
Sum=STARTBYTE1+STARTBYTE2;
continue;
}
Buf[i]=temp;
Sum+=temp;
temp=temp1;
}
Sum+=temp1;
if(Sum==0) OSSendSignal(命令解釋任務 ID);
}}
以下為這幾種方法的比較:
可讀性和編程容易性方面,第三鍾方法最好(如果允許使用goto語句,程序更加簡單易讀),第二種次之(因為要編隊列程序),第一種最差。如果協議更加複雜,這方面更加明顯。程序簡單易讀,自然出錯機會小了。
RAM佔用方面,第三種方法較少,第二種最多(因為隊列佔用大量空間),第一種最少。
中斷執行時間方面,第三種方法最長,第二種最短,第一種較長。
從功能方面,第三種方法最強,它還可以進行超時處理(雖然例子程序沒有),其它方法均不行。
如果數據來的太快,命令處理程序來不及處理,三種方法處理方式不太一樣,第一種和第三種方法類似:丟棄以前數據,第二種則是丟棄後到的數據。而且,第二種方法必須等命令處理程序完成後才處理下一個數據包,而第一種和第三種方只需命令處理程序將數據收取後就可處理下一個數據包。也就是說,第一種和第三種與命令處理程序並行處理,第二種方法為串列處理。
現在,一般情況下,開發的效率第一,執行的效率(包括執行時間和資源佔用)第二。在這種情況下,降低些許效率換取開發的效率的較大提高,何樂而不為?何況,單個模塊的執行的效率高不等於整個程序執行效率高。例如,如果程序需要等待一段時間,一般用程序延時或定時器延時。無論何種方法,CPU不再處理其它工作,效率很低。而用RTOS,等待的時候CPU可以處理其它工作,效率得到提高。
以下摘自《uC/OS-II--源碼公開的實時嵌入式操作系統》
「實時內核也稱為實時操作系統或RTOS。使用它使得實時應用程序的設計和擴展變得容易。不需要大的改動就可以增加新的功能。通過應用程序分割為若干獨立的任務,RTOS使得應用程序的設計過程大為簡化。使用可剝奪性的內核時,所有時間要求苛刻的事件都得到了儘可能快捷、有效的處理。通過有效的服務;如信號量、郵箱、隊列、延時、超時等;RTOS使得資源得到更好的利用。
「如果應用項目對額外的需求可以承受,應該考慮使用實時內核。這些額外的需求是:內核的價格,額外ROM/RAM開銷,2至4百分點的CPU額外負擔。
「還有沒提到的一個因素是使用實時內核增加的價格成本。在一些應用中,價格就是一切,以至於對使用RTOS連想都不敢想。」
總而言之,適用的就是最好的,不要拒絕RTOS,在它適用的情況下,它工作得很好。
※如何在 Linux/Unix/Windows 中發現隱藏的進程和埠
※用python在樹莓派上編程,你可以將項目擴展到令人難以置信的規模
TAG:嵌入式資訊精選 |