As early as the 1960s, someone had begun to research and develop embedded operating systems. But until recently, it has been mentioned more and more domestically, and its increasing importance in fields requiring real-time processing such as communications, electronics, and automation has attracted more and more attention. However, people are often talking about some famous commercial kernels, such as VxWorks, PSOS, etc. These commercial cores are superior in performance, but 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 free uC/OS-II. Features of uC/OS-II 1. uC/OS-II is an open kernel written by Mr. Labrosse, the most important feature is the open source code. This can be described as having both advantages and disadvantages for users. The advantage is that on the one hand, it is free, and on the other hand, users can modify it according to their needs. The disadvantage is that it lacks the necessary support and does not have a powerful software package. Users usually need to write their own drivers, especially if the user is using a less commonly used single-chip microcomputer, they must also write their own transplant programs. 2. uC/OS-II is a preemptive kernel, that is, ready high-priority tasks can deprive the running low-priority tasks of the CPU usage rights. This feature makes its real-time performance better than non-preemptive kernels. Usually we make high-priority tasks in the interrupt service routine to enter the ready state (for example, send a signal), so that after exiting the interrupt service routine, the task will be switched and the high-priority task will be executed. Take 51 single-chip microcomputer as an example, and compare it to find the advantages of doing so. If a batch of data needs to be collected and processed in an interrupt mode, complex data processing cannot be performed in the interrupt service routine in the traditional programming method, because this will make the shutdown time too long. So the method often used is to set a flag and then exit the interrupt. Since the main program is executed cyclically, it always has the opportunity to detect this mark and go to the data processing program. But because it is impossible to determine where the program is executed when the 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 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 interrupt. This can limit the interrupt response time to a certain range. For some systems that have strict requirements on interrupt response time, this is essential. But it should be pointed out that if the data processing procedure is simple, this may not be appropriate. Because uC/OS-II requires the OSINTEXIT function to be used at the end of the interrupt service routine to determine whether to switch tasks, it takes a certain amount of time. 3. uC/OS-II is different from the well-known Linux equal time-sharing operating system, it 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. If you analyze its source code, you will find that uC/OS-II uses the priority of the task as the identification of the task. At the same level, the tasks cannot be distinguished. The task with the highest priority that enters the ready state first gets the right to use the CPU, and only after it surrenders the right to use the CPU can other tasks be executed. So it can only be said to be multitasking, not multi-process, at least not the kind of multi-process we are familiar with. Obviously, if you only consider the real-time performance, it is certainly better than the time-sharing system, it can ensure that important tasks always take priority in the CPU. But in the system, important tasks are limited after all, which makes the priority of other tasks a confusing problem. In addition, some tasks are performed alternately which is more beneficial to users. For example, when using a single-chip microcomputer to control two small display screens, both the programmer and the user definitely want them to work at the same time, instead of displaying the information on one display screen after displaying the information on the other display screen. At this time, it would be more appropriate if uC/OS-II supports both the priority method and the time slice rotation method. 4. uC/OS-II provides a protection mechanism for 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 perform different functions. In this way, a task is equivalent to a sub-module in a modular design. When adding code to the task, as long as it is not a shared resource, there is no need to worry about mutual influence. For shared resources (such as serial ports), uC/OS-II also provides a good solution. In general, the semaphore method is used. Simply put, first create a semaphore and initialize it. 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 only be released when the resource is used up. In this process, even if a higher priority task 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 is displaying information, an external interrupt is generated, and the display is required to display other information in the interrupt service routine. In this way, after exiting the interrupt service program, the original information may be destroyed. When the semaphore method is adopted in uC/OS-II, the new information can be displayed only after the original information is displayed on the display screen, which can avoid this phenomenon. However, the use of this method is at the expense of the real-time nature 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 prolonging the interrupt response time, which is undoubtedly fatal to the situation where the undisplayed information is an alarm information. When this happens, it is called priority inversion in uC/OS-II, that is, high-priority tasks must wait for the completion of low-priority tasks. In the above situation, it is unavoidable that priority inversion occurs between the two tasks. Therefore, when using uC/OS-II, you must have a clear understanding of the developed system in order to decide whether to use semaphores for a certain shared resource. Some features of uC/OS-II in the use of MCU 1. Embedding uC/OS-II in the SCM system will enhance the reliability of the system and make the debugging procedure easier. In the past, the traditional MCU development work often encountered the program runaway or fell into an infinite loop. The watchdog can be used to solve the problem of program runaway. For the latter case, especially when complicated mathematical calculations are involved, only breakpoints can be set, which takes a lot of time to analyze slowly. If uC/OS-II is embedded in the system, things are much simpler. 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 runs out, the task must hand over the right to use the CPU. Even if a problem occurs in one task, 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 uC/OS-II in the microcontroller system will increase the overhead of the system. The 51 single-chip microcomputers used now generally refer to 87C51 or 89C51, which have a certain amount of RAM and ROM in the chip. For some simple programs, if traditional programming methods are used, external memory expansion is no longer needed. If uC/OS-II is embedded in it, when only task scheduling, task switching, semaphore processing, delay or timeout services are needed, there is no need for external expansion of ROM, but external expansion of RAM is necessary. Since uC/OS-II is a scalable operating system, the required RAM size depends on the number of operating system functions. For example, uC/OS-II allows users to define the maximum number of tasks. Since each task is created, a corresponding data structure TCB must be generated, which takes up a large part of the memory space. So when defining the maximum number of tasks, we must consider the needs of the actual situation. If it is set too large, it will inevitably cause unnecessary waste. After embedding uC/OS-II, the total RAM requirement can be obtained by the following expression: Total RAM requirement = RAM requirement of the application + RAM requirement of the kernel data area + (task stack requirement + maximum interrupt nesting stack requirement)·Number of tasks Fortunately, uC/OS-II can define the size of the stack space for each task separately, and developers can allocate the stack space according to the actual needs of the task. But in the case of limited RAM capacity, you should still pay attention to the use of large arrays, data structures, and functions. Don't forget that the formal parameters of functions are also pushed onto the stack. 3. The transplantation of uC/OS-II is also a work that needs attention. If there is no ready-made transplantation example, you must write the transplantation code yourself. Although only two files need to be changed, you still need to be familiar with the corresponding microprocessor. It is best to refer to the existing transplantation examples. In addition, even if there is a transplantation example, it is best to read it before programming, because it involves stack operations. When writing interrupt service routines, the order in which registers are pushed onto the stack must correspond to the order in the ported code. 4. Unlike some other well-known embedded operating systems, the startup process of uC/OS-II in the MCU system is relatively simple. Unlike some operating systems, the kernel needs to be compiled into an image file and written into the ROM, and then powered on After resetting, load the file from ROM to RAM, and then run the application. The kernel of uC/OS-II is compiled into a file together with the application program. The user only needs to convert this file into HEX format and write it into the ROM. After power on, it will look like an ordinary single-chip microcomputer program. Run the same. Conclusion As can be seen from the above introduction, uC/OS-II has the advantages of free, easy to use, high reliability, and good real-time performance, but it also has disadvantages such as difficulty in transplantation and lack of necessary technical support, especially not like commercial embedded systems. Widely used and continuous research updates. But openness allows developers to cut and add required functions by themselves, playing a unique role in many application fields. Of course, whether to embed uC/OS-II in the microcontroller system depends on the project being developed. For some simple, low-cost projects, there is no need to use an embedded operating system. Flat Wire High Current Inductor Flat Wire High Current Inductor,Small Flat Wire Common Mode Inductors,High Current Flat Wire Inductors,High Power Flat Wire Inductors Shenzhen Sichuangge Magneto-electric Co. , Ltd , https://www.scginductor.com