seminarsonly.com

>>

Are you interested in this topic.Then mail to us immediately to get the full report. email :- contactv2@gmail.com

Custom Search

Introduction
The industrial and military sectors require varying levels of 'real-time' computer response depending on the specific nature of each task to be performed. Consequently, three different definitions of 'real-time' can be illustrated by a battlefield scenario where soldiers in the field provide 'real-time' data which is ultimately sent to the commander's 'real-time' tactical display which provides information used to determine that a missile (using a 'real-time' computer system) should be launched.

The 'real-time' data from the troops can be compared to the now familiar 'real-time stock quote', providing information that was current within the last few seconds or perhaps minutes. This can be referred to as 'human real-time' since short delays in the tactical data provided from the field are obscured by the much longer human delays associated with sorting and correlation. The video display observed by the commander illustrates 'soft real-time', where the loss of an occasional frame will not cause any perceived video degradation, provided that the average case performance remains acceptable. Although techniques such as interpolation can be used to compensate for missing frames, the system remains a soft-real time system because the actual data was missed, and the interpolated frame represents derived, rather than actual data.

'Hard real-time' is illustrated by the control system of a high-speed missile because it relies on guaranteed and repeatable system responses of thousandths or millionths of a second. Since these control deadlines can never be missed, a hard real-time system cannot use average case performance to compensate for worst-case performance. Thus, hard real-time systems are required for the most technically challenging tasks. Since an embedded system often performs only a single task, the differences between soft and hard real-time for these applications are not as critical as one would think. However, as true multi-tasking operating systems, such as Linux, are adopted for use in increasingly complex systems, the need for hard real-time often becomes apparent. To further confuse the real-time issue, the general term "Real-Time Operating System (RTOS)" is used to refer to one that can provide either hard or soft real-time capabilities but not necessarily both. Thus all operating systems labeled as "RTOS" are not created equally.

The Real-Time Linux Solution
The real-time Linux scheduler treats the Linux operating system kernel as the idle task. Linux only executes when there are no real time tasks to run, and the real time kernel is inactive. The Linux task can never block interrupts or prevent itself from being preempted. The mechanism that makes this possible is the software emulation of interrupt control hardware. When any code in Linux tries to disable interrupts, the real time system intercepts the request, records it, and returns it to Linux. In fact, Linux is not permitted to ever really disable hardware interrupts, and hence, regardless of the state of Linux, it cannot add latency to the interrupt response time of the real time system.

When an interrupt occurs, the real time kernel intercepts the interrupt and decides what to dispatch. If there is a real time handler for the interrupt, the appropriate handler is invoked. If there is no real time interrupt handler, or if the handler indicates that it wants to share the interrupt with Linux, then the interrupt is marked as pending. If Linux has requested that interrupts be enabled, any pending interrupts are enabled, and the appropriate Linux interrupt handler invoked - with hardware interrupts re-enabled. Regardless of the state of Linux: running in kernel mode; running a user process; disabling or enabling interrupts; the real-time system is always able to respond to an interrupt. Real-time Linux decouples the mechanisms of the real time kernel from the mechanisms of the general purpose Linux kernel so that each can be optimized independently and so that the real-time kernel can be kept small and simple.