About the choice of RTOS (top)

(Original article, welcome reprint, please specify the source)

Many friends and colleagues have asked me how to choose an RTOS in practice. This question is very difficult to answer ah, very complex. There are at least three cases in practice:

1. Some places do not need an rtos at all, perhaps the system designer is the person who likes RTOs,:-), the RTOs;
2. RTOs is required in some places, but no RTOs is used for various reasons;
3. The worst case scenario is that the wrong RTOS of choice is developed to the life of the development team ...

Before you choose, you can ask the following questions:

1. Is there a requirement for the response delay time of some events? The time limit is at the microsecond level.
2. The system has time-bound requirements for the processing of some events. The timeframe is close to the CPU's time to process the event at full speed, but not at the millisecond level.
3. Is the processing code for these events complex in the system (averaging no more than 100 lines of standard C code and no function calls per event). More than 5 of these events.
4. The system has RAM, ROM restrictions, so that most operating systems such as Linux, UClinux, WinCE do not work properly.
5. The system has a certain scale, more than 2W line standard C + + code. There are multiple logical transactions in the system, and there is synchronization or data exchange between the logical transactions.
6. Does the product or system have a long life cycle and is there a requirement for subsequent upgrades and development?
7. The team understands the chosen RTOS. Do you have an expert on RTOS implementation?

If there are more than 2 questions answered Yes, friends, you probably need an RTOS to develop your system. If more than 4 questions answered Yes friends, you must use an RTOS.

When you decide to use an RTOS, the following question is what RTOs to choose. There are too many RTOs in the market, all kinds of things, when we choose an rtos, we may weigh the following factors:

1. Cost
2. Reliability
3. Real-time sex
4. Tool Chain
5. Module Rich
6.RTOS kernel RAM, ROM footprint
7. Support

The cost is mainly the version of the RTOS, the cost of learning. This difference can be big, some operating systems, such as commercial VxWorks, QNX, Lynx, Uc/os, expensive Ah, but the silver, people will certainly teach you to get started. But many operating systems such as FreeRTOS, RTEMS, Ecos, Rt-thread, commercial use are almost no cost, and there is no copyright issue. Aside from the RTOs of these commercial charges, the cost of these open-source, free RTOs, is mainly learning costs. such as Rtems this operating system is not very studious, less data, its own complexity is also high, such as FreeRTOS, small, the study of many people, its own code is not complex, the learning curve is not steep, it is easy to climb up.

Reliability is settled by time. There are some rising stars in the market, such as rt-thread, compared to Rtems, the originator of the RTOs, but also slightly immature. This does not mean that we choose everything rtems, that rt-thread how to develop. For small projects, you can try. For large projects, it is prudent to be cautious in order to reduce technical risks.

Real-time, this should be the rtos of the housekeeping skills, I was a novice rtos, I like to see the cow people make the RTOs comparison table. Context switch time Ah, interrupt response delay AH ... Always like to pick the system with the smallest time ... But then I learned that, in fact, not a few comparison tables can be a clear question. These questions are discussed in detail below.

Toolchain, it often determines the efficiency of our development, and the quality of the final product delivery. Some RTOS are not so fortunate, there is no right to choose the tool chain, even if there is a great price to pay. If RTEMS uses the GNU toolchain, the GNU tool chain is not good enough, I have tried to move the RTEMS to the IAR ewarm. Later, half of the time, have to give up, the effort has been more than I have to bear the scope. But FreeRTOS, Uc/os this kind of small RTOS, as long as the compiler supports the compilation can be re-entered code, this is only the old compiler does not work. So basically a C compiler can do free RTOS, Uc/os compilation.

Module is rich, there is no TCP/IP protocol stack, file system, can protocol stack, graphical interface and so on. Of course this is not necessary, for simple products, may not be used in these modules. For complex systems, these well-integrated modules can greatly save development time. You can also transplant the relevant modules, there may be a few practical problems can not be solved: the module because it does not conform to the design of the RTOs, the overall real-time damage, it may be because the module uses the library, and the RTOs used by the library conflict ...

The kernel RAM, ROM footprint actually requires the Rtos to be highly clipped. Not all kernels are clipped to the end, the RTOS has a minimum of RAM, ROM requirements, and only some of the most basic services left. Each additional feature adds some resources that can be consulted to obtain this information and to determine that system resources can be used to ensure smooth use of the RTOS.

Support, if it is a business system, do not worry, since the payment of money, people will certainly ensure the smooth implementation process. If it is an open source system, the development team will not have a decent RTOs expert. Although RTOs systems are interlinked, it is not always true to know the other RTOs quickly. RTEMS so complex RTOS to understand, to get FreeRTOS, Uc/os, rt-thread small Sparrow, naturally no problem, if you get QNX, VxWorks, Lynx, still need a little effort. RTOS in the development process will encounter a lot of problems, such as stack estimation, task priority design, memory design, real-time design, etc., are very difficult to get the problem. The best team with the relevant RTOS experts, if the study does not matter, research and development products and systems, that is the big problem.

(To be Continued ...)

http://blog.csdn.net/coolbacon/article/details/6398170