Advantages and disadvantages of embedding an operating system in a Single Chip Microcomputer

Advantages and disadvantages of embedding an operating system in a Single Chip Microcomputer As early as 1960s, some people began to study and develop embedded operating systems. However, it has not been mentioned more recently in China. The increasing importance of it in areas requiring real-time processing, such as communication, electronics, and automation attracts more and more attention. However, people often talk about some famous commercial kernels, such as VxWorks and PSOs. These commercial kernels provide superior performance, but are expensive. They are mainly used in 16-bit and 32-bit processors and are applicable to the 51 Series 8-Bit Single-Chip Microcomputer used by most users in China, you can choose free uC/OS-II.

Characteristics of uC/OS-II

1. uC/OS-II is an open kernel written by Mr labrosse, the main feature is open source code. This is advantageous for users. On the one hand, it is free, and users can modify it as needed. The disadvantage is that it lacks the necessary support and does not have powerful software packages. users usually need to write their own drivers.ProgramEspecially if the user is using a less commonly used microcontroller, you must also write your own transplant program.

2.uc/ OS-II is a preemptible kernel, that is, a ready high-priority task can deprive the CPU of a running low-priority task. This feature makes it more real-time than non-preemptible kernels. Generally, the high-priority task enters the ready state (for example, sending a signal) in the interrupt service program. After exiting the interrupt service program, the task will be switched and the high-priority task will be executed. Taking 51 single-chip microcomputer as an example, we can compare it to find the benefits of doing so. If a batch of data needs to be collected and processed using the interrupt method, complicated data processing cannot be performed in the interrupt service program in the traditional programming method, because this will lead to a long disconnection time. Therefore, the common method is to set a flag and exit the interrupt. Because the main program executes cyclically, it always has the opportunity to detect this sign and transfer it to the data processing program. However, because it is unable to determine where the program is executed in the event of an interruption, it cannot determine how long the data processing program will be executed, the interrupt response time cannot be determined, and the system's real-time performance is not strong. If uC/OS-II is used, as long as the priority of the data processing program is set higher and it enters the ready state in the interrupt service program, the data processing program will be executed immediately after the interruption ends. In this way, the interrupt response time can be limited to a certain range. This is essential for 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 uC/OS-II requires the use of the osintexit function at the end of the interrupt service to determine whether task switching is performed, which takes some time.

3.uc/ OS-II is different from Linux, which does not support time slice rotation. UC/OS-II is a priority-based real-time operating system, the priority of each task must be different, analysis of its source code will find that uC/OS-II the priority of the task as the task identification to use, if the priorities are the same, tasks cannot be differentiated. The task with the highest priority in the ready state first obtains the CPU usage right. Other tasks can be executed only after it has handed over the CPU usage right. Therefore, it can only be said to be a multi-task, not a multi-process, at least not the kind of multi-process we are familiar. Obviously, if you only consider real-time performance, it is certainly better than the time-sharing system, it can ensure that important tasks always occupy the CPU preferentially. However, in the system, important tasks are limited after all, which makes the priority of dividing other tasks a daunting problem. In addition, it is more advantageous for users to execute tasks in turn. For example, when using a single-chip microcomputer to control two small display screens, both programmers and users certainly want them to work at the same time, rather than displaying the information of another display screen after the display is complete. At this time, if uC/OS-II that supports priority method and time slice rotation method is more suitable.

4.uc/ OS-II protects shared resources. As mentioned above, uC/OS-II is an operating system that supports multitasking. A complete program can be divided into several tasks, and different tasks execute different functions. In this way, a task is equivalent to a submodule in the modular design. When you add Code to a task, you do not have to worry about mutual impact as long as the resources are not shared. For shared resources (such as serial port), uC/OS-II also provides a good solution. Generally, the semaphore method is used. To put it simply, create a semaphore and initialize it. When a task needs to use a shared resource, it must first obtain the semaphore. Once this semaphore is obtained, the semaphore will be released only after the resource is used up. In this process, even if a task with a higher priority enters the ready state, the resource cannot be used because the semaphore cannot be obtained. The benefits of this feature are obvious. For example, when the display screen is displaying information, an external interruption occurs, and other information needs to be displayed in the interrupted service program. In this way, the original information may be damaged after the service is terminated. In the uC/OS-II Using semaphore method, only the display of the original information can display new information, so as to avoid this phenomenon. However, this method is at the cost of 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 fatal if no information is displayed. In uC/OS-II, this is called a priority reversal, that is, a high-priority task must wait for the completion of a low-priority task. In the above circumstances, priority inversion between two tasks is unavoidable. So in the use of uC/OS-II, you must have a clear understanding of the development of the system, in order to determine whether to use a shared resource semaphore.

Some features of uC/OS-II in Single Chip Microcomputer
1. Embedded uC/OS-II in the single chip microcomputer system will enhance the reliability of the system and make the debugging program easy. In the past, traditional single-chip microcomputer development often encountered programs flying or in an endless loop. The watchdog can be used to solve the problem of program running and flying. In the latter case, especially when complicated mathematical computation is involved, only breakpoint setting takes a lot of time to analyze. It would be much easier to embed uC/OS-II in the system. The entire program can be divided into many tasks, each task is relatively independent, and then set a timeout function in each task. After the time is used up, the task must hand over the CPU usage right. Even if a task has a problem, it does not affect the running of other tasks. This not only improves the system reliability, but also makes debugging programs easy.

2. Embedded uC/OS-II in single chip microcomputer system will increase the overhead of the system. Currently, the 51 single-chip microcomputer generally refers to 87c51 or 89C51, which carries a certain amount of Ram and Rom. For some simple programs, if the traditional programming method is used, there is no need for extended memory. If you embed a UC/OS-II in it, and you only need to use the task scheduling, task switching, semaphore processing, latency or timeout services, do not need to expand the Rom, however, Ram extension is required. Since uC/OS-II is a customizable operating system, the size of Ram required depends on how much operating system functionality is available. For example, the uC/OS-II allows the user to define the maximum number of tasks. Every time a task is created, a corresponding data structure TCB is generated, which occupies a large part of the memory space. Therefore, when defining the maximum number of tasks, you must consider the actual needs. If it is set to be too large, it will inevitably lead to unnecessary waste. After the uC/OS-II is embedded, the overall Ram needs can be derived from the following expressions:

Ram total demand = Application Ram requirements + kernel data zone Ram requirements + (Task Stack requirements + maximum interrupt nested stack requirements) · number of tasks
Fortunately, the uC/OS-II can define the size of the stack space for each task separately, developers can according to the actual needs of the task to stack space allocation. However, when the ram capacity is limited, you should pay attention to the use of large arrays, data structures, and functions. Do not forget that the function parameters should also be pushed into the stack.

3. The transplantation of uC/OS-II is also worth noting. If you do not have a ready-made transplant instance, you must write your own transplant code. Although you only need to modify two files, you still need to be familiar with the corresponding microprocessor. It is best to refer to the existing transplantation instance. In addition, even if there is a porting instance, you 'd better read it before programming, because it involves stack operations. When writing interrupt service programs, the order in which registers are pushed into the stack must correspond to the order in the porting code.

4. different from some other well-known embedded operating systems, uC/OS-II in the single chip microcomputer system startup process is relatively simple, unlike some operating systems, need to compile the kernel into an image file written into the Rom, after power-on and reset, load the file from the Rom to ram, and then run the application. The uC/OS-II kernel is compiled together with the application into a file, the user only needs to convert this file into hex format, write ROM can be, after power-on, it runs like a common single-chip microcomputer program.

Conclusion
From the above introduction, we can see that uC/OS-II has the advantages of free, simple use, high reliability, good real-time performance, but also has the disadvantages of difficult transplantation, lack of necessary technical support, etc, in particular, it is not as widely used and continuously researched and updated as in commercial embedded systems. However, openness allows developers to cut down and add required functions on their own, playing a unique role in many application fields. Of course, whether to embed uC/OS-II in the single chip microcomputer system depends on the development of the project, for some simple, low-cost projects, there is no need to use the embedded operating system.