实时操作系统（Real-time operating system）_Healthy

A Soft real time system is a system where not meeting a deadline can have undesirable but not catastrophic effects, a performance degradation for example. SRTs could be described as follow:

”A soft real time system is a system where the programmed reaction to a stimulus is almost always completed within a known finite time”.

Hard Real Time systems

An Hard Real Time (HRT) system is a system where not meeting a deadline can have catastrophic effects. HRT systems require a much more strict definition and could be described as follow:

”An hard real time system is a system where the programmed reaction to a stimulus is guaranteed to be completed within a known finite time”.

As you can see speed is not the main factor, predictability and determinism are. It is also important to understand that it is not the RTOS that makes a system SRT or HRT but the system design itself, the RTOS is just a tool that you can use in the right or wrong way.

Note that both SRT and HRT processes could coexist within the same system, even non critical processes without any RT constraints could be included in a design.

Scheduling, States and Priorities

Most RTOSs, including ChibiOS/RT, implement “fixed priority preemptive” scheduling algorithm. The strategy is very simple and can be described using few rules:

Each thread has its own priority level, priorities are fixed and do not change unless the system is specifically designed to do so.
Each active thread can be in one of the following states:
- Running, currently being executed by a physical core.
- Ready, ready to be executed when a physical core will become available.
- Waiting, not ready for execution because waiting for an external event. Most RTOSs split this state in several sub-states but those are still waiting states.
Each physical core in the system always executes the highest priority thread that is ready for execution.
When a thread becomes ready and there is a lower priority thread being executed then preemption occurs and the higher priority thread is executed, the lower priority thread goes in the ready state.

If the system has N cores the above strategy ensures that the N highest priority threads are being executed in any moment. Small embedded systems usually have a single core so there is only one running thread in any moment.
An explanation of how priorities are organized in ChibiOS/RT can be found in the article ”Priority Levels”.

Interrupts handling

An important role of an embedded RTOS is handling of interrupts. Interrupts are an important events source to which a system designed around an RTOS is supposed to react. We can classify interrupt sources in two main classes:

RTOS-related interrupt sources. This class of interrupts are required to interact with the RTOS in order to wakeup threads waiting for external events.
Non RTOS-related interrupt sources. Interrupt sources that do not need to interact with the RTOS. This class of interrupts could also be able to preempt the kernel in those architectures supporting maskable priority levels (ARM Cortex-M3) or separate interrupt lines (ARM7).

A carefully designed RTOS should implement mechanisms efficiently handling the synchronization between threads and interrupt sources. Flexibility is important at this level, the capability to wake up single or multiple threads, synchronously or asynchronously is very valuable. On the other side threads should be able to wait for a single or multiple events.
Usually interrupt events are abstracted in a RTOS using mechanism like semaphores, event flags, queues or others, there is much variability in how this is implemented by the various RTOSs.

What makes for a good RTOS?

Assuming that all the candidates can be classified as RTOSs having the mentioned minimum requirements, then are all the other features that make the difference. Usually some specific features or measurable parameters are highly regarded in RTOSs.

Response Time

An important parameter when evaluating an RTOS is its response time. An efficient RTOS only adds a small overhead to the system theoretical minimal response time. Typical parameters falling in this category are:

Interrupt latency, the time from an interrupt request and the interrupt servicing. An RTOS can add some overhead in interrupt servicing. The overhead can be caused by extra code inserted by the RTOS into the interrupt handlers code paths or by RTOS-related critical zones.
Threads fly-back time, the time from an hardware event, usually an interrupt, and the restart of the thread supposed to handle it.
Context switch time, the time required to synchronously switch from the context of one thread to the context of another thread.

Of course an RTOS capable to react within 2µS is better than a system that reacts within 10µS. Note that what is really meaningful is the worst case value, if a system reacts in average in 5µS but, because jitter, can have spikes up to 20µS then the value to be considered is 20µS.

Jitter

A good RTOS is also characterized by low intrinsic jitter in response time. Intrinsic because jitter is also determined by the overall system design. Some factors that determine the system behavior regarding jitter are:

Thread priorities assignment.
Interrupt priorities assignment.
Length and number of critical zones.
Interactions between threads through shared resources protected by mutual exclusion.
Use of priority inheritance or other jitter-reducing algorithms/strategies.

See the article ”Response Time and Jitter”.

Size

In an embedded system the RTOS is an important overhead in terms of occupied memory, a more compact RTOS is preferable being all the other parameters equal because memory cost.

Reliability

There are design choices that make some systems intrinsically more reliable that others. Dynamic allocation is a good example of a poor design choice because both unreliability and response time unpredictability of some allocation schemes. Fully static designs do not have those intrinsic limitations.

Synchronization Primitives

Variety in available primitives is also an important factor to be considered. Having the correct tool for the job can reduce development time and often also helps when integrating external code with the RTOS.

A good example is the lwIP TCP/IP stack, it assumes an RTOS offering semaphores with timeouts, if your RTOS does not support semaphores and timeouts then you have a problem and will have to find a workaround.

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests. It must be able to process data as it comes in, typically without buffering delays. Processing time requirements (including any OS delay) are measured in tenths of seconds or shorter.

Design philosophies

The most common designs are:

Event-driven which switches tasks only when an event of higher priority needs servicing, called preemptive priority, or priority scheduling.
Time-sharing designs switch tasks on a regular clocked interrupt, and on events, called round robin.

Time sharing designs switch tasks more often than strictly needed, but give smoother multitasking, giving the illusion that a process or user has sole use of a machine.

Early CPU designs needed many cycles to switch tasks, during which the CPU could do nothing else useful. For example, with a 20 MHz 68000 processor (typical of late 1980s), task switch times are roughly 20 microseconds. (In contrast, a 100 MHz ARM CPU (from 2008) switches in less than 3 microseconds.)^[4]^[5] Because of this, early OSes tried to minimize wasting CPU time by avoiding unnecessary task switching.

Algorithms

Some commonly used RTOS scheduling algorithms are:

Cooperative scheduling

Preemptive scheduling
- Rate-monotonic scheduling
- Round-robin scheduling
- Fixed priority pre-emptive scheduling, an implementation of preemptive time slicing
- Fixed-Priority Scheduling with Deferred Preemption
- Fixed-Priority Non-preemptive Scheduling
- Critical section preemptive scheduling
- Static time scheduling
Earliest Deadline First approach
Stochastic digraphs with multi-threaded graph traversal

Examples

common example of an RTOS is an HDTV receiver and display. It needs to read a digital signal, decode it and display it as the data comes in. Any delay would be noticeable as jerky or pixelated video and/or garbled audio.

Some of the best known, most widely deployed, real-time operating systems are

Reference:

http://en.wikipedia.org/wiki/Real-time_operating_system

http://en.wikipedia.org/wiki/List_of_real-time_operating_systems

http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:rtos_concepts

阅读┊ 收藏 ┊ 喜欢 ▼ ┊打印┊举报/Report

前一篇：再观：摩尔定律(Moore's law)

后一篇：时间单位

新浪BLOG意见反馈留言板　欢迎批评指正