RTOs column-Table of Contents

Use an actual project case to elicit the need for an RTOS, then summarize the core content of Μcos and the prerequisite knowledge needed to understand the content, and make a detailed chapter directory of the column. Why RTOS???

A real understanding of the benefits of using an RTOS is to go through the actual project and say the first project I've been exposed to after work. The project is an embedded controller, the need to do is: read A/D data, according to the reading of a/D data calculation results, and the host computer communication, display, user keys. A detailed technical requirements, a high demand for real-time task is to read A/D data, the need for accurate 10ms-level interval reading. Such a system intuitively, there are many tasks to do, and the task between the importance, the urgency of comparison can not be treated equally. If the RTOs is not used, the classic approach is to use the front and rear system design method, the backend system as a large loop detection of various events, the foreground is a variety of external event interruption, such as reading A/D data, detected external keys and so on. This system requires a lot of extra work to achieve real-time response to specific events and emergency management of different events. In fact, the straightforward point is that a small embedded system core controller is generally a combination of CPU and peripherals on-chip system. This core controller is typically a single-core CPU, providing only one execution stream, plus interrupt, which can say that there are two manageable execution flows, and that the execution flow priority of the interrupt is greater than the execution stream provided by the CPU. This is the natural nature of the design of the front and rear system, the hardware provides two execution flow, I use these two execution flow design the front and rear system. Front desk is a variety of interrupt events, the background using CPU-provided computing resources to do logic processing.

By using software Management to manage the execution flow on the CPU, the overall throughput and real-time responsiveness can be speeded up. Because the CPU execution flow from the macro point of view of the CPU to calculate the time is the interval, this is also very good understanding, because the CPU is very strong, but a task generally involves waiting for external events, external events before the logical processing or numerical operations. The overall utilization of the CPU is high when waiting for an external event that is much slower than the CPU operation, if the CPU can be used for other tasks. That's a really good idea. An embedded product can not interact with the outside, after all, technology products are human services.

With the RTOs, you can easily manage tasks by designing the project above, and you can easily differentiate between tasks based on their urgency and real-time performance. In this way, to reduce the design complexity of embedded software is very helpful, later debugging, maintenance is relatively easy. This is also more natural, originally different tasks are divided out is based on this task to do the work has high cohesion characteristics, and other task interaction has a low coupling characteristics, a task as a management unit is indeed more natural. After using the RTOs, each task considers itself to be exclusive to a whole CPU, which is actually a CPU resource for each task time-sharing. Since each task is divided, it inevitably involves the communication between the various tasks, the RTOS also provides a variety of IPC communication methods. This design of embedded software does conform to the "high cohesion, low coupling" design principles.

The core of the RTOs is to manage the CPU, which means to abstract multiple execution streams (task/thread). Other services provided by the RTOs are related to external IO, such as FS (File System), Device manegement, and so on.

The RTOS provides an abstract computer that is better for programmers, an abstract computer that masks the underlying hardware details and provides a number of basic services. This is the reason to use the RTOs, I believe that you have used the RTOs design products, you will not use the front and back system design products. several basic concepts that need to be understood

What is the operating system. What is the real-time operating system.

Hardware platform agnostic Code and hardware platform-related code in RTOS

Since all have high-level languages, why assembly language still exists. What is the main function of the assembly language in the RTOs source code.

Programmers write programs from the source code to the actual operation of what has gone through. (Source code-target image-actual run)

Re-recognize the stack [stack]. (The relationship between stack and C language, stack and thread run environment) Catalogue thanks to Μcos's author Jean J.labrosse

Thanks to Μcos's author Jean J.labrosse Hardware Runtime environment and ΜCOS release notes

Hardware runtime environment and Μcos version Description dependent knowledge Point operating system && real-time operating system hardware platform about && platform-Independent assembly language existence significance The birth and death of programs

(Source code-target image-actual run) re-understanding the stack [stack]

(The relationship between stack and C language, stack and thread run environment) STM32 hardware knowledge required for managing CPUs in Μcos