Analysis of embedded real-time operating system uCOS II

fish001

Analysis of embedded real-time operating system uCOS II [Copy link]

As early as the 1960s, people had begun to research and develop embedded operating systems. But it was not until recently that it was mentioned more and more in China. Its increasing importance in fields that require real-time processing, such as communications, electronics, and automation, has attracted more and more attention. However, what people talk about are often some well-known commercial kernels, such as VxWorks and PSOS. These commercial kernels have superior performance, but are expensive and are mainly used in 16-bit and 32-bit processors. For the 51 series 8-bit microcontrollers used by most domestic users, you can choose the free uCOS II.

Features of uCOS II
1. uCOS II is an open kernel written by Mr. Labrosse, and its main feature is that the source code is open. This has both advantages and disadvantages for users. The advantage is that it is free, and users can modify it according to their needs. The disadvantage is that it lacks the necessary support and has no powerful software package. Users usually need to write their own drivers, especially if they use less commonly used microcontrollers, they must also write their own porting programs.

2. uCOS II is a preemptive kernel, that is, a high-priority task that is ready can deprive the running low-priority task of the CPU usage right. This feature makes its real-time performance better than that of a non-preemptive kernel. Usually, we make the high-priority task enter the ready state (such as sending a signal) in the interrupt service program. In this way, after exiting the interrupt service program, the task will be switched and the high-priority task will be executed. Take the 51 single-chip microcomputer as an example, and you can find the benefits of doing so by comparison. If you need to collect a batch of data and process it in an interrupt mode, you cannot perform complex data processing in the interrupt service program in the traditional programming method, because this will make the interruption time too long. Therefore, the method often used is to set a flag bit and then exit the interrupt. Since the main program is executed in a loop, it always has the opportunity to detect this flag and go to the data processing program. However, because it is impossible to determine where the program is executed when an interrupt occurs, it is impossible to determine how long it will take for the data processing program to execute, the interrupt response time cannot be determined, and the real-time performance of the system is not strong. If μC/OS-II is used, as long as the priority of the data processing program is set higher and it is put into the ready state in the interrupt service program, the data processing program will be executed immediately after the interrupt ends. This can limit the interrupt response time to a certain range. This is essential for some systems that have strict requirements on the interrupt response time. However, it should be pointed out that if the data processing program is simple, this may not be appropriate. Because μCOS II requires the use of the OSINTEXIT function at the end of the interrupt service program to determine whether to switch tasks, which takes a certain amount of time.

3. uCOS II is different from the well-known time-sharing operating systems such as Linux. It does not support the time slice rotation method. uCOS II is a priority-based real-time operating system. The priority of each task must be different. Analyzing its source code, it is found that uCOS II uses the priority of the task as the identification of the task. If the priority is the same, the tasks will not be distinguished. The task with the highest priority that enters the ready state will first get the right to use the CPU. Only after it surrenders the right to use the CPU can other tasks be executed. So it can only be said to be multi-tasking, not multi-process, at least not the kind of multi-process we are familiar with. Obviously, if only real-time performance is considered, it is certainly better than the time-sharing system. It can ensure that important tasks always have priority in occupying the CPU. However, in the system, important tasks are limited after all, which makes the priority of dividing other tasks a troublesome problem. In addition, some tasks are more beneficial to users when they are executed alternately. For example, when using a single-chip microcomputer to control two small display screens, both the programmer and the user must want them to work at the same time, rather than displaying the information of one display screen before displaying the information of another display screen. At this time, it would be more appropriate if uCOS II supported both the priority method and the time slice rotation method.

4. uCOS II provides a protection mechanism for shared resources. As mentioned above, uCOS II is an operating system that supports multitasking. A complete program can be divided into several tasks, and different tasks perform different functions. In this way, a task is equivalent to a submodule in a modular design. When adding code to a task, there is no need to worry about mutual influence as long as it is not a shared resource. As for shared resources (such as serial ports), uCOS II also provides a good solution. Generally, the semaphore method is used. Simply put, a semaphore is created and initialized first. When a task needs to use a shared resource, it must first apply for the semaphore, and once the semaphore is obtained, the semaphore will not be released until the resource is used up. In this process, even if a task with a higher priority enters the ready state, it cannot use the resource because it cannot obtain the semaphore. The benefits of this feature are obvious. For example, when the display is displaying information, an interrupt is generated externally, and the display needs to display other information in the interrupt service program. In this way, after exiting the interrupt service program, the original information may be destroyed. When the semaphore method is used in μC/OS-II, new information can be displayed only after the display screen has finished displaying the original information, thus avoiding this phenomenon. However, this method is at the expense of the real-time performance of the system. If it takes a lot of time to display the original information, the system has to wait. From the result, it is equivalent to extending the interrupt response time, which is undoubtedly fatal for the situation where the undisplayed information is an alarm message. This situation is called priority inversion in μC/OS-II, that is, the high-priority task must wait for the completion of the low-priority task. In the above case, priority inversion between the two tasks is inevitable. Therefore, when using uCOS II, you must have a clear understanding of the system you are developing before you can decide whether to use semaphores for a certain shared resource.

Some features of uCOS II in the use of single-chip microcomputers
1. Embedding uCOS II in the single-chip microcomputer system will enhance the reliability of the system and make it easier to debug the program. In the past, in the development of traditional single-chip microcomputers, programs often run away or fall into an infinite loop. Watchdogs can be used to solve the problem of program running away. For the latter case, especially when it involves complex mathematical calculations, only breakpoints can be set, which takes a lot of time to analyze slowly. If uCOS II is embedded in the system, things will be much simpler. The entire program can be divided into many tasks, each of which is relatively independent, and then a timeout function can be set in each task. After the time is up, the task must hand over the right to use the CPU. Even if a task has a problem, it will not affect the operation of other tasks. This not only improves the reliability of the system, but also makes it easier to debug the program.

2. Embedding uCOS II in a single-chip microcomputer system will increase the system overhead. The 51 single-chip microcomputers currently used generally refer to 87C51 or 89C51, which have a certain amount of RAM and ROM on the chip. For some simple programs, if the traditional programming method is used, there is no need for external memory expansion. If uCOS II is embedded in it, if only task scheduling, task switching, semaphore processing, delay or timeout services are needed, there is no need for external ROM, but external RAM is necessary. Since uCOS II is a scalable operating system, the amount of RAM required depends on the number of operating system functions. For example, μC/OS-II allows users to define the maximum number of tasks. Since each task is established, a corresponding data structure TCB must be generated, and this data structure will occupy a large part of the memory space. Therefore, when defining the maximum number of tasks, it is necessary to consider the actual needs. If it is set too large, it will inevitably cause unnecessary waste. After embedding uCOS II, the total RAM requirement can be obtained by the following expression:
Total RAM requirement = RAM requirement of application + RAM requirement of kernel data area + (task stack requirement + maximum interrupt nesting stack requirement) · number of tasks

Fortunately, μC/OS-II can define the size of the stack space for each task, and developers can allocate the stack space according to the actual needs of the task. However, when the RAM capacity is limited, you should still pay attention to the use of large arrays, data structures and functions, and don't forget that the function parameters must also be pushed into the stack.

3. The porting of uCOS II is also a task that needs attention. If there is no ready-made porting example, you must write the porting code yourself. Although you only need to change two files, you still need to be familiar with the corresponding microprocessor. It is best to refer to the existing porting examples. In addition, even if there is a porting example, it is best to read it before programming, because it involves stack operations. When writing the interrupt service program, the order of pushing registers into the stack must correspond to the order in the porting code.

4. Unlike some other well-known embedded operating systems, the startup process of uCOS II in a single-chip microcomputer system is relatively simple. Unlike some operating systems, it is not necessary to compile the kernel into an image file and write it into ROM. After power-on reset, the file is loaded from ROM to RAM, and then the application is run. The kernel of uCOS II is compiled into a file together with the application. The user only needs to convert the file into HEX format and write it into ROM. After power-on, it will run like a normal single-chip microcomputer program.

Conclusion
From the above introduction, we can see that uCOS II has the advantages of free, easy to use, high reliability, good real-time performance, etc., but it also has disadvantages such as difficult transplantation and lack of necessary technical support. In particular, it is not as widely used and continuously researched and updated as commercial embedded systems. However, its openness allows developers to tailor and add the required functions by themselves, playing a unique role in many application fields. Of course, whether to embed uCOS II in the microcontroller system should depend on the project being developed. For some simple, low-cost