Tell you a simple example of how to use RTOS
Time: 2018-03-01 Source: Internet Author: Tags: MCU RTOS
To engage in SCM especially with 8051 engineers, the MCU RTOS comes, many will ask: "Why use this resource on the MCU RTOS, RTOS can guarantee the efficiency of the use of it??"
For that matter, I would ask: "What is the purpose of your MCU for the C programming microcontroller, assembly programming the microcontroller even with the binary instructions programmed microcontroller??" The 1980s, engineers to use binary instruction Z80 programming, now who else is using? anyone still clinging tightly compilation, but more and more people are using the C programming engineer (I also use initially compiled). Why? because our purpose is limited time and even the quality and quantity of projects completed within insufficient time! What is the use of tools and methods is secondary (if your project cost in the first place, is a different matter, then, is to consider development time). Time is money, ah, a little product on the microcontroller to increase the cost is acceptable. Moreover, the use of 8051, single-chip resources are often surplus, CPU generally just idling, which RTOS to use it to create the conditions.
So, the benefits of using an RTOS? I give an example of it. Suppose we compiled a serial communication program, communication protocol as follows:
Nbyte packet length, the initial byte STARTBYTE1, STARTBYTE2, and finally a checksum byte, an intermediate byte impossible consecutive STARTBYTE1, STARTBYTE2.
The first method, the interrupt handling protocol:
unsigned char Buf[NBYTE-2];bit GetRight=0;
void comm (void) interrupt 4 // "serial port interrupt" {
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;
}
}}
The second method, using a queue
Interrupt function:
void comm (void) interrupt 4 // "serial port interrupt" {
if(RI==1)
{
RI = 0;
SBUF into the team;
}}
The main program continues to function call:
unsigned char Buf[NBYTE-2];
unsigned char ReadSerial(unsigned char *cp){
unsigned char i;
unsigned char temp,Sum;
temp = the number of the data queue;
if(temp<(NBYTE)) return 0;
The team temp;
if(temp!=STARTBYTE1) return 0;
temp = first byte queue;
if(temp!=STARTBYTE2) return 0;
The team temp;
sum + = STARTBYTE1 STARTBYTE2;
for(i=0;i
{
temp = first byte queue;
if(temp==STARTBYTE1)
{
temp = queue of the first byte;
if(temp==STARTBYTE2) return 0;
}
The team temp;
*cp++=temp;
Sum+=temp;
}
temp = first byte queue;
Sum+=temp;
if(Sum!=0) return 0;
The team temp;
return 1;}
The third method, using the RTOS
Interrupt function:
void comm (void) interrupt 4 // "serial port interrupt" {
OS_INT_ENTER();
if(RI==1)
{
RI = 0;
OSIntSendSignal(RECIVE_TASK_ID);
}
OSIntExit ();}
RECIVE_TASK_ID ID for the task
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 (command interpreter task ID);
}}
The following is a comparison of these methods
Readability and ease of programming, the third bell best way (if allowed to use the goto statement, the program easier to read), followed by the second (due to the formation column program), the first one is the worst. If the protocol is more complex, it has become more obvious. Simple and readable, natural small chance of error.
RAM occupied aspect, less the third method, the second up (because the queue take up a lot of space), a first minimum.
Aspects interrupt execution time, the longest third method, the second shortest, the first longer.
From the functional aspect, the strongest third method, it can be time-out processing (although no example program), other methods are not.
If the data is too fast, too late command handler processing, three methods of treatment are not the same, the first and third methods similar to: discarding the previous data, the second is to discard data. Further, the second method must wait for the next command processing is completed before processing a packet, the first and the third party can simply command handler can process the next packet after the data collected. That is, the first and third command processor parallel processing, serial processing of the second method.
Now, under normal circumstances, first, the efficiency of the implementation of the efficiency of development (including execution time and resource consumption) second. In this case, a little lower exchange efficiency greatly improved the efficiency of development, why not? Moreover, the efficient implementation of a single module is not equal to a high overall efficiency of program execution. For example, if a program needs to wait a period of time, typically program or delay timer delay. Regardless of the method, CPU no longer handle other work efficiency is very low. But with the RTOS, while waiting for the CPU to process other work efficiency is improved.
The following excerpt from "uC / OS-II-- open source real-time embedded operating system."
"Also known as real-time kernel real-time operating system or RTOS. It allows designers to use real-time applications and extensions can be easily No major changes can add new features. Divided into several independent tasks application, RTOS makes application design process can greatly simplify the use of the core deprived of all time-critical events have been as fast, efficient processing through effective service;.. such as semaphores, mailboxes, queue, delay, timeout; the RTOS so that better use of resources.
"If the demand for additional application projects can afford, you should consider using a real-time kernel these additional requirements are: Core prices, additional ROM / RAM overhead, CPU load additional 2-4 percentage points.
"There are a factor not mentioned is the use of real-time kernel to increase the cost price. In some applications, the price is everything, so that the use of RTOS even unthinkable."
All in all, applicable is the best, not to reject RTOS, in case it applies, it works very well.