Monday, July 1, 2013
ABSTRACT:
This
seminar helps us understand what Embedded Systems are, the components required
for the development, the development life cycle and the applications in which
they are used.
The following points are
covered in this seminar briefly.
1.
Embedded Systems Overview.
2.
Embedded Applications Development Characteristics.
3.
Real Time Operating Systems.
Ø Hard and
soft real-time systems.
Ø Difference
Between RTOS & Desktop OS.
4.
Popular Commercial RTOSs.
5.
Design Issues for Embedded Systems.
Ø Time
Constraints.
Ø Safety.
Ø Device
Drivers.
Ø Interrupt
Service Routines.
Ø Storage
Allocation.
Ø Optimizing
Performance.
Ø Debugging
Memory Problems.
6.
Future Trends in Embedded system RTOS.
Ø Application
Specific.
Ø System On a
Chip
Ø Automatic
Code Generation.
INTRODUCTION
You read about it everywhere: distributed computing is the next revolution, Perhaps relegating our desktop computers to the museum. But in fact the age of distributed computing has been around for quite a while. Every time we withdraw money from an ATM, start our car, use our cell phone, or microwave our dinner, microprocessors are at work performing dedicated functions. These are examples of just a very few of the thousands of “embedded systems.”
Until recently the vast majority of these embedded systems used 8- and 16-bit microprocessors, requiring little in the way of sophisticated software development tools, including an Operating System (OS). But the 32-bit processors are now driving an explosion in high-volume embedded applications. And a new trend towards integrating a full system-on-a-chip (SOC) promises a further dramatic expansion for 32-bit embedded applications as we head into the 21st century.
Aerospace companies were the first end-markets for embedded systems, driven by military and space applications. But this market has never developed the growth potential of the newer commercial applications. In the past five years, the major end-markets for embedded systems have been telecommunications, computer networking, and office equipment. But, now we see consumer and automotive electronics as major emerging markets. And looming on the horizon is the suspected wave of networked appliances, with Sun Microsystems, IBM, Microsoft and others targeting products and standards; envisioning billions of embedded network connections running embedded JAVA applications across a network.
EMBEDDED
APPLICATION DEVELOPMENT CHARACTERISTICS
What characterizes an embedded
system? Usually it means that there are a set of pre-defined, specific
functions to be performed, and that the resources available (e.g., memory,
power, processor speed, computational functionality) are constrained. Often,
though not always, the application will run out of ROM on a microprocessor.
This, in comparison to a desktop computer, which is a general-purpose processor
and support system designed for a wide range of applications. The range of
embedded software is much broader than desktop software, where a handful of
applications (word processors, spreadsheets, games, and so on) make up the vast
majority of applications.
Embedded tools are now catching up with Windows GUI,
object oriented programming and client/server architectures. These new tools
are stressing ease-of-use and enabling team disciplines to work on the same
project from different locations across the enterprise.
Driving this need for tools is a basic fact of the
embedded market. With increased competition, companies supplying embedded
products cannot afford schedule slippage that result in missed market
opportunities. Increasing the productivity of engineers and programmers has
become the critical factor in bringing
embedded products to market quickly and at reasonable cost.
The
most developed segment of the embedded tools market are the off-the-shelf
real-time operating systems (RTOSs), including their support programming tools:
source level debuggers, integrated development environment, and compilers.
The
commercial RTOS market is highly fragmented with offerings from dozens of
vendors, supplying products for many different microprocessors. This
fragmentation is caused by three factors. First, there are dozens of different
microprocessors optimized for different embedded applications. A different version
of the RTOS, with a corresponding set of development tools, must be written for
each microprocessor. Second, different applications offer widely variable sets
of available programming resources. Some RTOSs are optimized for more resource
constrained environments, and others are aimed at less constrained
environments. And third, different end market applications have different needs
and levels of complexity. Some RTOSs offer a wide range of available services,
while others are simpler. A single RTOS cannot provide the optimal solution for
every application.
COMPONENTS NEEDED:
The
components needed for the development of Embedded Applications are:
1.
Micro Controller.
2.
Real-time Operating System.
3.
A language for coding.
4.
Machine code generator.
5.
Debugger.
Micro
Controller:
The micro controller consists of microprocessor, ROM, RAM
and some I/O ports all on the same chip. The commonly used micro controller is
8051.
Machine
code generator:
The source code is written in a
particular language like C/C++. This has to be then used to generate the code
for the particular microprocessor. The machine specific code is then burnt into
the chip(ROM). The microprocessor takes
the instructions from the ROM and executes them to produce the desired effect.
Real-time
Operating System:
What does “real-time” mean when
used in the context of an operating system? Simply put, this means that the
embedded application can and will respond to external events in real time, as
opposed to waiting for some other task or process to complete its operation.
This is made even more confusing by the use of the terms “hard real-time” and
“soft real-time.”
Hard
real-time means an activity must be completed always by a specified deadline (which may be a particular time or time interval,
or at the arrival of some event), usually in tens of microseconds to few
milliseconds. Some examples include the processing of a video stream, the
firing of spark plugs in an automobile engine, or the processing of echoes in a
Doppler radar.
Soft
real-time applies to those systems that are not hard real-time, but some sort
of timeliness is implied. That is, missing the deadline will not compromise the
system’s integrity, but will have a deleterious effect. Examples of this type
of system are point of sale (POS) systems in retail stores, ATMs and other
credit card machines, and PDAs. When a POS system can not read the bar code
because the item was scanned too quickly, the system simply indicates an error,
and the item will be scanned again for identification.
Further
confusing the notion of “hard” and “soft” real-time is increased processor
speeds. When the processor speed increases, interrupts are processed more
quickly. More importantly, the interrupt window in which interrupts are
disabled keeps shrinking and this will improve the timeliness of response. So
“soft” real-time performance may improve just as a function of processor speed.
But countering this trend is the increasing complexity of the applications,
requiring more processing to be done at interrupts, and the blurring of the
hardware-software interface.
But
be they hard or soft, real-time (or perhaps a general term should be
“embedded”) OSs have four characteristics in common that differentiate them
from desktop or mainframe OSs.
Bounded
Interrupt Servicing:
There is a
maximum allowable time that the system can be diverted to process an interrupt.
The interrupt service routine must do the absolute minimum processing and
terminate.
Priority
Based Scheduling:
In a real-time
system, all tasks are assigned a level of priority, viz a viz each other. This
priority may be based on any number of criteria (including run time). This
implies that tasks do not execute just because they are “ready,” but rather
because they are the highest priority task that is ready.
Preemptive
Tasks:
All tasks and
routines must be constructed in such a way that they can be pre-empted by some
higher priority task or routine becoming ready.
Scalability:
The
OS services provided are not monolithic. Rather, they are provided as a set of
modules or libraries. The services needed for an application are included in
the build by simply setting flags at the time of the application build; or, in
the case of libraries, by having the linker pull in the services used by the
application; or by using conditional compilation to scale the OS.
But, besides these four, there are
other differences between real-time and desktop OSs that have more to do with
the needs of the end application, the needs of the embedded developer, and the
restrictions placed on the application by the resources available. The most
obvious is the RAM requirement. Considering the volumes and tight end user
pricing of most embedded systems, RAM is a very precious commodity. The OS must
use this memory efficiently while preventing fragmentation, recovering RAM when
tasks are terminated, requiring the minimum amount of RAM when tasks are
created, and providing for efficient stack and heap structures.
Probably
just as important are the scheduling algorithms, since these are at the heart
of system performance. There are wide varieties of algorithms that have been
developed and, depending on the end application, the developer would want to
choose the one satisfying the response requirements while being the stingiest on
resources. Some of the algorithms developed include:
Heuristic:
At
any time, the task with the earliest deadline will be executed. This algorithm
is efficient, but it may not find a feasible schedule even if one exists.
Round
Robin:
Each
task is assigned a fixed amount of processor time, and when that time is up,
the next task executes.
Simple
Priority:
The user assigns
a priority at the time of thread creation. The next thread to execute is based
on the priority of the “ready” thread. In a large system, it can be difficult
for the user to decide the priorities of each thread.
Rate
Monotonic:
The
tasks of the program are assigned priorities in descending order according to
the length of the period. The task with the shortest period has the highest
priority, and the task with the longest period has the lowest priority. In its
simplest form, it does not provide support for sporadic events. Modifications
have been proposed, such as polling, priority exchange algorithm, and
deferrable server algorithm.
Deadline
Monotonic Scheduling:
This is close to the Rate Monotonic but accommodates
sporadic tasks.
Not
as obvious, but just as important, are mechanisms that have been created to
synchronize and communicate between tasks. While also found in non-RTOSs, these
mechanisms take on a critical role in embedded systems due to the requirements
on response and the scarcity of resources. The well known synchronization
mechanisms are semaphores, mutexes, and condition variables, with message
queues and mailboxes being
among the more
common task communication devices. But just having these mechanisms is not
sufficient. These mechanisms must be designed in such a way as to take a
bounded amount of time for worst case situations. For example, if a set of
tasks have to wait for a semaphore in a wait queue, the wait queue should not
be singularly linked, since removing a task from the list will require
traversing the entire list of waiting tasks. Some more efficient algorithm,
with bounded worst case performance, must be used.
An
example of a commercial RTOS architecture is given in Figure 1 for pSOSystem
from Integrated Systems, Inc.
pSOSystem uses a
modular architecture, containing the pSOS+ real-time, multi-tasking kernel and
a collection of companion software components and libraries. These components
are delivered as “black boxes,” remaining unchanged from application to
application. This assures high reliability to the end user.
DESIGN
ISSUES FOR EMBEDDED SYSTEMS:
Embedded Systems are, if nothing else,
characterized by constraints such as response, size, performance, costs, and so
on. And it is optimizing for these constraints (or rather perhaps working within
them) that makes designing an embedded system a difficult task. Numerous
questions have to be answered before the design even begins:
Ø What are the
worst case performance requirements for each activity?
Ø What are the
number and complexity of activities to be performed?
Ø How should these
activities be distributed amongst the software tasks so that the processor load
is balanced (and thereby get the best cost/performance out of the processor
selection)?
Ø What is the
degree of coupling of these tasks (critical deadlines, type of data flow among
tasks, event interdependencies)?
Ø How much RAM and
ROM does the hardware design provide?
Ø How much RAM and
ROM will be consumed for the specific set of tasks, ISRs, queues, and so on?
Ø How much buffer
space should be allocated for stack usage?
Over the years,
the articles in Embedded Systems
Programming magazine have dealt with many, if not most, of the issues facing embedded
systems designers. A number of the more commonly faced issues are summarized
here.
Time
Constraints:
Real-time
operating systems bow to a combination of time specific constraints. Some
routines must execute at precisely fixed intervals, while other routines are
not bound to a critical time alignment. The most critical task of an embedded
programmer is to characterize each of the actions to be performed so he will
know how to assign priority and resources to that action in order that the
overall system performance objectives are met. To aid in this task, it is
helpful to break the actions in an embedded system down into the following four
task groups:
1.
Time critical task routines are those that must occur at
a fixed rate with a minimum startup latency (e.g., servicing an A/D converter).
2.
Time sensitive task routines are different from time
critical tasks in that they can tolerate a large latency before being serviced.
Like time critical task routines, they may also occur at fixed rates or they
may be initiated at random intervals, but are guaranteed to execute no more
frequently than some fixed rate by the task handler itself.
3.
Idle task routines are important background operations,
and they execute as frequently as
possible at more or less
random interval when it is convenient.
4.
Mainline tasks routines interpret the user commands,
perform non-real-time functions, and
make calls to the time sensitive and idle task service routines.
Safety:
While
the reliability of hardware has improved dramatically, when the mission of the
embedded system is critical, the embedded designer must build tests of the
processor and memory into the application. There are a variety of ways that
this can be accomplished.
Probably
the first and simplest safety technique learned by many embedded programmers
consists of filling unused program memory with either halt instructions or
illegal instructions. This technique guards against illegal jumps outside of
the program space and provides cheap insurance.
Another
common protection is to use buffers that guard against stack underflow/overflow
or the corruption of a task's stack. Many of the commercial RTOSs now contain
facilities and functions that support stack checking.
To
verify the integrity of a program or data stored in ROM, a simple ROM test
should be included as well a watchdog timer to prevent the software from
getting caught in a loop.
It is also well known that a rogue pointer, for example,
can lead to wholesale corruption of memory. So how does one protect against the
corruption of program data? One technique is the redundant storage of critical
variables, and comparison prior to being used. Another is the grouping of
critical variables together and keeping a CRC over each group.
Device
Drivers:
It is well known that writing efficient
device drivers requires knowledge of both hardware and software. The resulting device drivers become the keys to embedded system
performance since they are called
repeatedly, and therefore dictate real-time performance in terms of response time, and utilization of memory and other system resources.
Interrupt
Service Routines:
Using
interrupt processing is a powerful technique that is often more appropriate
than using software loops to continuously poll peripheral devices. However, the
compiler does not dictate interrupt-processing strategy, and most RISC
processors do very little in response to interrupts. These constraints place a
burden on the embedded developer in that he must decide which interrupt
architecture is best. Some approaches are to save the interrupted context on a
memory stack. Another is to preserve the context in a cache, be it on-chip
registers (if there are a lot of them to use) or off-chip memory. To simplify
debugging, it is best to keep ISRs short.
Storage
Allocation:
One
important feature to be considered in the selection of an RTOS or embedded
system design is storage allocation. Ill-designed dynamic storage allocation
can be wasteful for two reasons. First, allocating memory from the heap can be
both slow and non-deterministic. The time it takes for the memory manager to
search the free-list for a block of the right size may not be bounded. Second,
one may create the possibility of a memory allocation fault caused by a fragmented
heap. One typical solution is to statically declare all objects up front and
get rid of dynamic allocation. However, this can waste storage since the
objects always exist and take space. Whilst difficult, the apparently
conflicting goals of a dynamic storage allocator can be achieved.
Optimizing
Performance:
Writing
embedded code that runs efficiently brings about a whole new set of rules.
Often optimizing for speed and size opposing design goals-an improvement on one
often degrades the other. In trying to achieve this balance, the article
promotes the use of three techniques:
Ø the judicious
use of the optimization options found with most embedded cross-platform
compilers (for example, eliminating redundant code, or replacing operations
with equivalent but faster operations, or “unrolling loops,” optimizing the use
of registers, or removing code segments that the compiler knows cannot be
reached)
Ø the mix of fixed and floating-point operations
and
Ø the employment of user optimizations, making
the most out of available resources.
Debugging
Memory Problems:
Since
many RTOSs and/or embedded microprocessors do not support memory protection,
tracking down software memory bugs can become a serious debugging problem. In
attacking this problem, it is best to categorize the problem by the type of
Memory affected. In general, they fall into three categories:
Ø Global memory
bugs: those bugs that result in corruption of global memory data areas.
Ø Stack memory bugs: these often cause a complete failure
of the program execution; they are the hardest to track down as they are often
a function of external events and the current state of the stack.
Ø Dynamically allocated memory bugs: examples are, heap
memory allocated by a malloc service; or problems caused by writing past the
boundaries of an allocated memory block or using one that is no longer
allocated.
FUTURE TRENDS IN EMBEDDED SYSTEM RTOS:
There
is a flood of trends rushing through the embedded market today, many
influencing the RTOS requirements in conflicting ways. It is hard to envision
that five years from now RTOS products will bear much resemblance to what is
supplied today.
Some of these
trends are application driven while others are device driven, and it is
important to understand the influences these trends will have.
Application
Specific:
In several
markets, the end users have banded together to issue specific requirements for
RTOSs to be used in their future products. They have purposely chosen to drop
their proprietary behaviors of the past in order to get the benefits of
multiple suppliers and interoperability of software. In this manner, only the
needed software is linked into the application, preventing additional overhead
and allowing for an extremely efficient kernel implementation.
System On A
Chip (SOC):
As
mentioned earlier, SOCs are beginning to appear throughout the embedded market,
in at least three different ways. First, the semiconductor suppliers are
providing developers the ability to pick and choose from a combination of
industry standard functions integrated around a 32-bit core processor. These
functions may include memory, IO drivers, a bus interface, network protocol
support, or algorithms for special functions, such as an MPEG decoder. Second,
end product manufacturers are integrating custom ASICs with common 32-bit core
processors to provide complete solutions. Some recent examples include cable
modems and ATM switches. And third, startups are emerging that will provide
custom design services, complete with optimized RTOS, compiler, and debuggers.
SOC will be particularly well suited for a
whole range of consumer electronics and wireless communications devices where
size, cost, and low power requirements are crucial. It will also drive cost
reductions in networking and telecom equipment, where more functionality can be
added at lower costs. A subset of this SOC trend is the emergence of multi-core
devices on single silicon. The most common to date has been the combination of
standard microprocessors and Digital Signal Processors (DSPs). In some cases,
the DSPs are dedicated function processors, but emerging trends have the DSP as
a full programmable device.
Automatic
Code Generation:
Probably
the most radical notion is the idea that application code can be generated
automatically from graphical diagrams depicting the logic flow for the end
product. To a limited extent, this has already been accomplished, with products
like MATRIX, BetterStat, Statemat, and MATLAB being used for application modeling and code generation.
In the case of MATRIX, flight ready code for the international space station
has been used for some time now, and the technology is being extended into the
more restrictive automotive market. If these tools were to become reality, the
whole notion of commercial RTOS and development tools will be upset, as the
developer will only interact with the graphical tool, and will be totally
isolated from the resulting software implementation.
CONCUSION:
This seminar
helped in understanding the following concepts.
1.
Embedded systems application development.
2.
The components of
embedded systems.
3.
The design issues.
4.
The applications in which embedded systems are used.
5.
RTOS and its features.
6.
How to carry
out effective presentation.
