Page 8 - DCAP608_REAL TIME SYSTEMS

Unit 1: Concept of Real-time System

of interrupt signals arising from the arrival of data at an input port, or the ticking of a hardware Notes
clock, or an error status alarm. Because real-time systems are often closely coupled with special
equipment (a situation that is termed ‘embedded’) the programmer has also to gain a reasonable
understanding of the hardware if the project is to be a thorough success. Once again, however,
the demarcation between traditional data processing and real-time systems is not easy to draw
because event-driven GUI interfaces are so widely used within all desktop applications.
Low-level programming: The C language is still most popular for writing device drivers for new
hardware. But because high-level languages, including C, do not generally have the necessary
instructions to handle interrupt processing, it has been common for programmers to drop down
to assembler level to carry out this type of coding. Because ASM and C are classified as low-level
languages by many programmers, who may be more familiar with database systems and
windowing interfaces, it has been suggested as a distinguishing characteristic of real-time
programmers that they prefer to use low-level languages. This can be seen as somewhat
misleading, when the real-time high-level languages Modula-2 and ADA are taken into
consideration.

Specialized hardware: Most real-time systems work within; or at least close beside, specialized
electronic and mechanical devices. Unfortunately, to make matters more difficult, during
development these are often only prototype models, with some doubt surrounding their
functionality and reliability. This is especially true for small embedded microcontrollers which
may even be required to perform as critical component parts within a feedback control loop.
The oven power controller illustrated below could employ an integrated microcontroller to
monitor the oven temperature and adjust the electrical power accordingly. Such applications
place a heavy responsibility on the programmer to fully understand the functional role of the
software and its contribution to the feedback delay which governs the system response. Code
may have to run synchronously with the hardware or other software systems, such as when
telephone transmissions are sequenced 8000 times a second to maintain acceptable voice quality.
Very often this leads the programmer into other disciplines: electrical theory, mechanics, acoustics,
physiology or optics. Real-time programmers rarely have a routine day.
Volatile data: I/O Another special issue for real-time software concerns ‘volatile data’. These
are variables which change their value from moment to moment, due to the action of external
devices or agents, through interrupts or DMA. This is distinguished from the situation where
input data is obtained from a disk file, or from the keyboard under program control. The most
common example encountered by real-time programmers involves input channels which operate
autonomously to bring in new values for memory variables when data arrives at an input port.
The software must then be structured to check for changes at the correct rate, so as not to miss a
data update.

Multi-tasking: Real-time systems are often expected to involve multitasking. In this situation,
several processes or tasks cooperate to carry out the overall job. When considering this
arrangement, there should be a clear distinction drawn between the static aggregation of groups
of instructions into functions for compilation, and the dynamic sequencing of tasks which takes
place at run-time. It has already been suggested that full multi-tasking is not always necessary,
but it can be positively advantageous to programmers in simplifying their work. It is also
widely accepted that many computer systems have become so complex that it has become
necessary to decompose them into components to help people to understand and build them. In
the traditional data processing field, for example, the production of invoices from monthly
accounts requires several distinct operations to be carried out. These can be sequenced, one after
the other, in separate phases of processing. With real-time systems this is rarely possible; the
only way to partition the work is to run components in parallel, or concurrently. Multi-tasking
provides one technique which can assist programmers to partition their systems into manageable
components which have delegated responsibility to carry out some part of the complete activity.

LOVELY PROFESSIONAL UNIVERSITY 3