ABC discussion of RTOS

I have been studying and applying RTOS for many years. There are some superficial ideas on the development and application of RTOS. After learning about the author of raw OS (a new RTOS), we will have more ideas. Let's write it here.

I have been worried about these issues.

1. What industries should RTOS be used in?
2. What problems can RTOS solve? What problems cannot be solved?

RTOS, people who know a little about the technology know that it is a real-time operating system, meaning a real-time operating system, but the word "real-time" is not easy to understand. There are hard real-time and soft real-time points. Hard Real-time computing depends not only on the correctness of the computing results, but also on the return time of the results. The operating system can ensure the correctness of this time. Soft Real-time, this time is not very guaranteed, occasionally will exceed, only statistical significance. This is not strictly stated.

Because real-time scheduling is required, common scheduling algorithms cannot be used for scheduling algorithms. There are many scheduling algorithms. RTOS uses the monotonic rate scheduling algorithm (RMS, rate-monotonic scheduling ). Of course, there are other types of scheduling algorithms, such as the earliest cutoff time priority algorithm (EDF) and the shortest idle time priority algorithm (LLF), but these algorithms are laboratory algorithms. This is the case now. I'm afraid it will be the case in the future. Or RMS, which is the only RTOS. RMS has some assumptions. Under this assumption, the task execution time cannot exceed 70%. Otherwise, the processor cannot schedule these tasks. However, this assumption is strict. After appropriate relaxation, it can reach 80% or even 85%. If you are interested, you can read related papers.

[1] Scheduling Algorithms for multiprogramming in a hard-real-time environment, C. L. Liu
[2] scheduling hard real-time systems: a review, A. Burns
[3] The Rate Monotonic Scheduling Algorithm: exact characterization and average case behavior, John lehoczky, Lui Sha, ye ding

After reading these questions, I can't help but admire them. I have already read these questions so thoroughly. We only need to apply it.

There are many RTOS operating systems on the market, threadx, freertos, uC/OS-II, RTEMS, QNX, lynxos, VxWorks, raw OS, ECOs, nuttx ...... Too many. We used the real-time operating system to think that our application was loaded into the safe. However, Liu told us in 1973 that the RMS algorithm was a static scheduling algorithm, that is, before the application was running, the application must be properly analyzed. This allows RMS to schedule the task set so that it can be ensured to be real-time. In other words, it is necessary to analyze whether or not the task we write can schedule the CPU and assign the priority reasonably. RTOS is just a cornerstone for us. To build our applications on this cornerstone, we need further detailed design to ensure the normal operation of RMS.

What industry should RTOS be used? This problem has plagued me for a long time. The reason why I entered the RTOS field is that the RTOS operating system is often hooked with the embedded three characters. I work with MCU, And I am familiar with RTOS after a long time. Around the world, RTOS is generally used for some microcontroller applications. Because RTOS has been transplanted, you don't have to bother writing the driver, you don't have to spend the effort to compile the script, and you don't have to bother debugging the underlying layer. It is easy to put applications on the top. Most companies around me are like this. They apply RTOS and even do not know the differences between hard time and soft real time, I do not even know that hard real-time has requirements on the scheduling time of the task set (cannot exceed 70% ). Such applications are convenient, cost-effective, and free of charge.

Then there is a system used by the Military Department. I have a friend who works on a high-speed parallel computing platform in the Chinese Emy of sciences and uses VxWorks. Through analysis, most of the time, such applications only need performance, not real-time. Because it is enough fast. How fast is enough? First, the microkernel is needed, and then the kernel is denied. It can be said that the by-product performance of the RMS algorithm is probably what they really need.

Our chang'e, God 9 has gone to heaven. I heard that RTEMS is used only for "cores. One of my friends in this field told me that, because you are not familiar with it, things in the sky are not as advanced as you think. In fact, things are very old, and they are all 40 MHz, 50 MHz star-mounted processors (in fact, we use the PowerPC, CPU and other CPU anti-radiation enhanced version ). Reliability is required. I thought about it. It's just a day. If it breaks down, I can't try another ship to repair it. It would be better to create a new heaven. Reliability and stability of RTOS; one of the biggest advantages of hard real-time is predictable behavior, coupled with the simplicity of RTOS implementation, a large number of tests. The reliability and stability of RTOS are comparable to those of non-Linux and Windows desktop operating systems. (PS. The new Linux kernel is also working on the RTOS part. Please pay attention to it)

Talking to the author of raw OS, he said RTOS is used for general control. With my little experience in the industry, RTOS applications include some industrial controls and some medical, Aerospace Electronics, and a very small part of consumer electronics. For most projects that require real-time processing, real-time tasks are only a few (generally no more than three ). Not every task needs to be real-time, which is impractical.

Most RTOS use a flat memory structure for the sake of the so-called speed, giving up the chance to use MMU. That is, the real and virtual addresses are the same. Loading applications from external storage cannot implement the concept of processes and threads in the sense of modern operating systems. Is this feature important? In fact, I think it is very important because it can expand the RTOS application field, so as to make RTOS more vigorous. However, I do not advocate that any application uses MMU, and the cost saved by the microkernel is sometimes immediate. However, consumer electronics is a huge and broad market because they need high system scalability, that is, loading applications from external storage. Most RTOS must be bound to and integrated with applications. To add an application, you must re-compile and then upgrade the firmware. This is unimaginable for consumer electronics. Supports mmu rtos to load applications from external storage. Some friends are worried that MMU will slow down the whole system. In my opinion, we can compile the RT task together with the kernel, or all the tasks that require rt are directly aggregated into a special memory address, which is specially processed by the operating system. Or, use appropriate algorithms to reduce unnecessary scheduling and page switching. This makes the entire system more efficient.

The interruption Delay Time That RTOS is proud of has the maximum and minimum values. In general, even if the fastest CPU is replaced with the most efficient processing system, the accuracy of the software control time can only be within milliseconds. (There are some disputes. Please refer to the comments on the 4th floor. It does not mean the delay of RTOS interruption. It refers to the full time that a service is interrupted, and a semaphore is sent to the task, and the task is interrupted .) In other words, when the software receives an interruption, makes a judgment, and ends the control, the time can only be accurate to the MS level. For example, the maximum error cannot exceed 2 milliseconds, or within 5 milliseconds. Of course, there are also exceptions. If the calculation process is too simple, if there is no operating system, it is only the front and back-end systems. In case of Guanzhong disconnection, the control time can be accurate to microseconds. In this case, special applications can be used, and general applications have no significance. Therefore, PLD and FPGA are available in industrial control and high-speed applications. Therefore, if you want to delay the microseconds in RTOs, you can only use the busy mode. If you use the task switching mode, the delay time is uncontrollable. Don't think about how long the delay will take, and RTOS is also software. We really need a latency of less than 1 ms. The udelay in the Linux kernel has given us the answer.

Most RTOS are exceptionally concise. This is a good sentence. In particular, there is no unified driver structure and development model. Such as uC/OS-II, freertos, such an operating system. It is not so much a scheduling algorithm as an operating system. Without a unified driving structure or development model, many of the existing results may be decommissioned due to the upgrade of the system core; the existing results between the project and the project cannot be used. Migrating from one system to another may make it difficult to reuse the results because of the high level of problems on the site of the designers. This is often overlooked by many RTOS designers. Something with a pattern can develop brilliantly. RTEMS, in my opinion, is one of the pattern RTOS in all open-source RTOS. It is concise and not simple, and provides a complete development model. In fact, this is also an important reason to limit its extensive use in consumer electronics. Most consumer electronics have a strong continuity and a large number of software projects, requiring the software to be able to continue on different hardware at the minimum cost. Look around, only Linux has done it, and he is not RTOS, but the good news is that Linux will be integrated into more and more RTOS design concepts.

In the future of RTOS, I am still optimistic about it in the MCU field. However, in the MCU field, RTOS is still a stage of competition. Well-developed development is poor, mainly because of commercial cooperation and promotion models, which have little to do with technology. In other fields, if MMU can be integrated, applications supporting load separation and supporting SMP (RTOS generally uses the amp method) will also play a huge role in promoting the development of RTOS, especially in the consumer electronics field. After all, when there are too many users, they will be willing to develop. For more information, please click here.