EMBEDDED SYSTEM - Full report

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.

HISTORY

  The first recognizably modern embedded system was the Apollo Guidance Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. Each flight to the moon had two. They ran the inertial guidance systems of both the command module and LEM.

At the project's inception, the apollo guidance computer was considered the riskiest item in the apollo project. The use of the then new monolithic integrated circuits, to reduce the size and weight, increased this risk.

The first mass-produced embedded system was the guidance computer for the Minuteman missile in 1961. It was the Autonetics D-17 guidance computer, built using discrete transistor logic and a hard disk for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that used integrated circuits, and was the first volume user of them. Without this program, integrated circuits might never have reached a usable price-point.

The crucial design features of the Minuteman computer were that its guidance algorithm could be reprogrammed later in the program, to make the missile more accurate, and the computer could also test the missile, saving cable and connector weight.

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.

GETTING THE EMBEDDED SOFTWARE INTO THE

TARGET SYSTEM

          The locator will build a file that describes the image of the target softaware. Let us see the issue of getting that file into the target system.

PROM programmers

The classical way to get the software from the locator file into the target system is to create a RAM or PROM .   Creating ROM is appropriate only when software development has been completed,since the toolong cost to build ROMs is quite high.

Putting the program into a PROM requires a device called a PROM programmer. This is appropriate ifvolumes are not large enough to justify  using a ROM, if plan to make changes to the software, or while we are debugging . If we plan to use PROMs and a PROM programmer for debugging purposes,it is usefulto build the version of the taaget system in which the PROM is placed in a socket on the target system rather than being soldered directly into the circuit. Then when we find a bug, we can remove the PROM containing the software with the bug from the target system and put it into the eraser or into the waste baket ,program a new  PROM with software that has the bug fixed, and put that PROm into the socket.

ROM emulator

                     Rom emulator  is a device that replaces the ROM in the target system. From the point of view of the rest of the hardware in the target system, the  emulator looks just like a  ROM. However, the ROM emulator contains a large box of electronics and a serial port or a network connection through which  it can be connected to our host. Software running on host send files created by the locator to the ROM emulator , which will act like a ROM that has been  programmed with the software we have written.

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.

CONCLUSION:

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.

REFERENCES:

1.      WWW.EN.WIKIPEDIA.COM

2.      WWW.EMBEDDED .COM

3.      TECHNICAL INFORMATION FROM INTEGRATED SYSTEMS INC.