Download Cse vii embedded computing systems [10cs72] notes and more Study notes Embedded Control Systems in PDF only on Docsity!
EMBEDDED COMPUTING SYSTEMS Sub Code: 10CS72 IA Marks : Hrs/Week: 04 Exam Hours : Total Hrs: 52 Exam Marks :
PART- A
UNIT – 1 6 Hours Embedded Computing: Introduction, Complex Systems and Microprocessors, Embedded Systems Design Process, Formalism for System design Design Example: Model Train Controller.
UNIT – 2 7 Hours Instruction Sets, CPUs: Preliminaries, ARM Processor, Programming Input and Output, Supervisor mode, Exceptions, Traps, Coprocessors, Memory Systems Mechanisms, CPU Performance, CPU Power Consumption. Design Example: Data Compressor.
UNIT – 3 6 Hours Bus-Based Computer Systems: CPU Bus, Memory Devices, I/O devices, Component Interfacing, Designing with Microprocessor, Development and Debugging, System-Level Performance Analysis Design Example: Alarm Clock.
UNIT – 4 7 Hours Program Design and Analysis: Components for embedded programs, Models of programs, Assembly, Linking and Loading, Basic Compilation Techniques, Program optimization, Program-Level performance analysis, Software performance optimization, Program-Level energy and power analysis, Analysis and optimization of program size, Program validation and testing. Design Example: Software modem.
PART- B
UNIT – 5 6 Hours Real Time Operating System (RTOS) Based Design – 1: Basics of OS, Kernel, types of OSs, tasks, processes, Threads, Multitasking and Multiprocessing, Context switching, Scheduling Policies, Task Communication, Task Synchronization.
UNIT – 6 6 Hours RTOS-Based Design - 2: Inter process Communication mechanisms, Evaluating OS performance, Choice of RTOS, Power Optimization. Design Example: Telephone Answering machine
UNIT – 7 7 Hours Distributed Embedded Systems: Distributed Network Architectures, Networks for Embedded Systems: I2C Bus, CAN Bus, SHARC Link Ports, Ethernet, Myrinet, Internet, Network Based Design. Design Example: Elevator Controller.
UNIT – 8 7 Hours Embedded Systems Development Environment: The Integrated Development Environment, Types of File generated on Cross Compilation, Dis-assembler /Decompiler, Simulators, Emulators, and Debugging, Target Hardware Debugging.
Text Books:
- Wayne Wolf: Computers as Components, Principles of Embedded Computing Systems Design, 2nd Edition, Elsevier, 2008.
- Shibu K V: Introduction to Embedded Systems, Tata McGraw Hill, 2009 (Chapters 10, 13) Reference Books:
- James K. Peckol: Embedded Systems, A contemporary Design Tool, Wiley India, 2008
- Tammy Neorgaard: Embedded Systems Architecture, Elsevier, 2005.
Table of Contents
Sl.No Unit Page No
1 Embedded Computing 4 - 34 2 Instruction Sets, CPUs 35 - 112 3 Bus-Based Computer Systems^113 - 142
4 Program Design and Analysis 143 - 198 5 PART B Real Time Operating System (RTOS) Based Design – 1
6 RTOS-Based Design - 2 312 - 320 7 Distributed Embedded Systems 321 - 330 8 Embedded Systems Development Environment
■ User interface: Microprocessors are frequently used to control complex user interfaces that may include multiple menus and many options. The moving maps in Global Positioning System (GPS) navigation are good examples of sophisticated user interf aces.
■ Real time: Many embedded computing systems have to perform in real time— if the data is not ready by a certain deadline, the system breaks. In some cases, failure to meet a deadline is unsafe and can even endanger lives. In other cases, missing a deadline does not create safety problems but does create unhapp y customers—missed deadlines in printers, for example, can result in scrambled pages.
■ Multirate: Not only must operations be completed by deadlines, but man y embedded computing systems have several real-time activities going on at the same time. They may simultaneously control some operations that r un at slow rates and others that run at high rates. Multimedia applications ar e prime examples of multirate behavior. The audio and video portions of a multimedia stream run at very different rates, but they must remain closely synchronized. Failure to meet a deadline on either the audio or video por tions spoils the perception of the entire p resentation.
■ Manufacturing cost: The total cost of building the system is very important in many cases. Manufacturing cost is determined by many factors, including the type of microprocessor used, the amount of memory required, and the types of I/O devices.
■ Powe r and energ y : Power consumption directly affects the cost of the hardware, since a larger power supply may be necessary. Energy con- sumption affects battery life, which is important in many applications, as well as heat consumption, which can be important even in desktop applications.
1.1.3 Why Use Microprocessors?
There are many ways to design a digital system: custom logic, field- pr ogr amma b l e gate arrays (FPGAs), and so on. Why use microprocessors? There are two answer s :
■ Microprocessors are a very efficient way to implement digital systems.
■ Microprocessors make it easier to design families of products that can be built to provide various feature sets at different price points and can be extended to provide new features to keep up with rapidly changing mar kets.
1.1.4 The Physics of Software
Computing is a physical act. Although PCs have trained us to think about computer s as purveyors of abstract information, those computers in fact do their work b y moving electrons and doing work. This is the fundamental reason why pr o gr ams take time to finish, why they consume energy, etc.
A prime subject of this book is what we might think of as the physics of software. Software performance and energy consumption are very important pr op- erties when we are connecting our embedded computers to the real world. We need to understand the sources of performance and power consumption if we are to b e able to design programs that meet our application’s goals. Luckily, we don’t have to optimize our programs by pushing around electrons. In many cases, we can make very high-level decisions about the structure of our programs to greatly impr o ve their real- time performance and power consumption. As much as possib le, we want to make computing abstractions work for us as we work on the physics of our software systems.
1.1.5 Challenges in Embedded Computing System Design
External constraints are one important source of difficulty in embedded system design. Let’s consider some important problems that must be taken into account in embedded system design.
How much hardware do we need?
We have a great deal of control over the amount of computing power we apply to our problem. We cannot only select the type of microprocessor used, but also select the amount of memor y, the peripheral devices, and more. Since we often must meet both performance deadlines and manufacturing cost constraints, the choice of hardware is important—too little hardware and the system fails to meet its deadlines, too much hardware and it becomes too expensiv e.
How do we meet deadlines?
The brute force way of meeting a deadline is to speed up the hardware so that the program runs faster. Of cour se, that makes the system more expensive.
■ Limited observability and controllability: Embedded computing systems usually do not come with keyboards and screens.This makes it more difficult to see what is going on and to affect the system’s operation. We may be forced to watch the values of electrical signals on the microprocessor bus, for example, to know what is going on inside the system. Moreover, in real-time applica- tions we may not be able to easily stop the system to see what is going on inside.
■ Restricted development environments: The development environments for embedded systems (the tools used to develop software and hardware) ar e often much more limited than those available for PCs and workstations. We generally compile code on one type of machine, such as a PC, and do wnload it onto the embedded system. To debug the code, we must usually rely on pr o - grams that run on the PC or workstation and then look inside the embedded system.
1.1.6 Performance in Embedded Computing
Embedded system designers, in contrast, have a very clear performance goal in mind—their program must meet its deadline. At the heart of embedded computing is r eal-time computing , which is the science and art of programming to deadlines. The program receives its input data; the deadline is the time at which a computation must be finished. If the program does not produce the required output by the deadline, then the program does not work, even if the output that it eventually produces is functionally cor r ect.
■ CPU: The CPU clearly influences the behavior of the program, particularly when the CPU is a pipelined processor with a cache.
■ Platform: The platform includes the bus and I/O devices. The platform com- ponents that surround the CPU are responsible for feeding the CPU and can dramatically affect its perfor mance.
■ Program: Programs are very large and the CPU sees only a small window of the program at a time. We must consider the structure of the entire pr o gr am to determine its overall behavior.
■ Task: We generally run several programs simultaneously on a CPU, creating a multitasking system. The tasks interact with each other in ways that have profound implications for perfor mance.
■ Multiprocessor: Many embedded systems have more than one pr ocessor— they may include multiple programmable CPUs as well as accelerators. Once again, the interaction between these processors adds yet
more complexity to the analysis of overall system perfor mance.
1.2 THE EMBEDDED SYSTEM DESIGN PROCESS
A design methodology is important for three reasons. First, it allows us to keep a scorecard on a design to ensure that we have done everything we need to do, such as optimizing performance or perfor m- ing functional tests. Second, it allows us to develop computer-aided design tools. Developing a single program that takes in a concept for an embedded system and emits a completed design would be a daunting task, but by first breaking the process into manageable steps, we can work on automating (or at least semiautomating) the steps one at a time. Third, a design methodology makes it much easier for member s of a design team to communicate. By defining the overall process, team member s can more easily understand what they are supposed to do, what they should receive from other team members at certain times, and what they are to hand off when they complete their assigned steps. Since most embedded systems are designed by teams, coordination is perhaps the most important role of a well-defined design methodolog y.
specification , we create a more detailed description of what we want. But the specification states only how the system behaves, not how it is built. The details of the system’s internals begin to take shape when we develop the arc hitecture, which gives the system structure in terms of large components. Once we know the components we need, we can design those components, including both softwar e modules and any specialized hardware we need. Based on those components, we can finally build a complete system.
In this section we will consider design from the top–down —we will begin with the most abstract description of the system and conclude with concrete details. The alternative is a bottom–up view in which we start with components to build a system. Bottom–up design steps are shown in the figure as dashed-line arrows. We need bottom–up design because we do not have perfect insight into how later sta ge s of the design process will turn out. Decisions at one stage of design are based upon estimates of what will happen later: How fast can we make a particular function r un? How much memory will we need? How much system bus capacity do we need? If our estimates are inadequate, we may have to backtrack and amend our or iginal decisions to take the new facts into account. In general, the less experience we have with the design of similar systems, the more we will have to rely on bottom-up design information to help us refine the system
But the steps in the design process are only one axis along which we can view embedded system design. We also need to consider the major goals of the design:
■ manufacturing cost;
■ Physical size and weight: The physical aspects of the final system can var y greatly depending upon the application. An industrial control system for an assembly line may be designed to fit into a standard-size rack with no str ict limitations on weight. A handheld device typically has tight requirements on both size and weight that can ripple through the entire system design.
■ Powe r consumption: Power, of course, is important in batter y- po wer ed systems and is often important in other applications as well. Power can be specified in the requirements stage in terms of battery life—the customer is unlikely to be able to describe the allowable watta ge.
Validating a set of requirements is ultimately a psychological task since it requires understanding both what people want and how they communicate those needs. One good way to refine at least the user interface portion of a system’s requirements is to build a mock-up. The mock-up may use canned data to simulate functionality in a restricted demonstration, and it may be executed on a PC or a workstation. But it should give the customer a good idea of how the system will be used and how the user can react to it. Physical, nonfunctional models of devices can also giv e customers a better idea of characteristics such as size and weight.
shows a sample requirements form that can be filled out at the start of the project. We can use the form as a checklist in considering the basic characteristics of the system. Let’s consider the entries in the for m :
■ Name: This is simple but helpful. Giving a name to the project not only sim- plifies talking about it to other people but can also crystallize the purpose of the machine.
■ Purpose: This should be a brief one- or two-line description of what the system is supposed to do. If you can’t describe the essence of your system in one or two lines, chances are that you don’t understand it well enough.
■ Inputs and outputs: These two entries are more complex than they seem. The inputs and outputs to the system encompass a wealth of detail:
— Types of data: Analog electronic signals? Digital data? Mechanical inputs?
— Data characteristics: Periodically arriving data, such as digital audio samples? Occasional user inputs? How many bits per data element?
— Types of I/O devices: Buttons? Analog/digital converters? Video displays?
■ Functions: This is a more detailed description of what the system does. A good way to approach this is to work from the inputs to the outputs: When the system receives an input, what does it do? How do user interface inputs affect these functions? How do different functions interact?
■ Performance: Many embedded computing systems spend at least some time controlling physical devices or processing data coming from the physical world. In most of these cases, the computations must be performed within a cer tain time frame. It is essential that the performance requirements be identified early since they must be carefully measured during implementation to ensure that the system works pr operly.
■ Manufacturing cost: This includes primarily the cost of the hardware compo- nents. Even if you don’t know exactly how much you can afford to spend on system components, you should have some idea of the eventual cost range. Cost has a substantial influence on architecture: A machine that is meant to sell at $10 most likely has a very different internal structure than a $100 system.
■ Powe r : Similarly, you may have only a rough idea of how much power the system can consume, but a little information can go a long way. Typically, the most important decision is whether the machine will be battery powered or plugged into the wall. Battery-powered machines must be much more car eful about how they spend energy.
■ Physical size and weight: You should give some indication of the physical size of the system to help guide certain architectural decisions. A desktop machine has much more flexibility in the components used than, for example, a lapel- mounted voice recorder.
■ Cost: The selling cost (street price) of the unit should be no more than $100.
■ Physical size and weight: The device should fit comfortably in the palm of the hand.
■ Power consumption: The device should run for at least eight hours on four AA
batteries.
1.2.2 Specification
The specification is more precise—it serves as the contract between the customer and the architects. As such, the specification must be carefully written so that it accurately reflects the customer’s requirements and does so in a way that can be clearly followed during design.
Specification is probably the least familiar phase of this methodology for neo- phyte designers, but it is essential to creating working systems with a minimum of designer effort. Designers who lack a clear idea of what they want to build when they begin typically make faulty assumptions early in the process that aren’t ob vi- ous until they have a working system. At that point, the only solution is to take the machine apart, throw away some of it, and start again. Not only does this take a lot of extra time, the resulting system is also very likely to be inelegant, kludgey, and bug-r idden.
The specification should be understandable enough so that someone can verify that it meets system requirements and overall expectations of the customer. It should also be unambiguous enough that designers know what they need to build. Designers
1.2.3 Architecture Design
The specification does not say how the system does things, only what the system does. Describing how the system implements those functions is the purpose of the architecture. The architecture is a plan for the overall structure of the system that will be used later to design the components that make up the architecture. The creation of the architecture is the first phase of what many designers think of as design.
To understand what an architectural description is, let’s look at a sample archi- tecture for the moving map of Example 1.1. Figure 1.3 shows a sample system architecture in the form of a block diagram that shows major operations and data flows among them.
This block diagram is still quite abstract—we have not yet specified which oper- ations will be performed by software running on a CPU, what will be done b y special-purpose hardware, and so on. The diagram does, however, go a long way toward describing how to implement the functions described in the specification. We clearly see, for example, that we need to search the topographic database and to render (i.e., draw) the results for the display. We have chosen to separate those functions so that we can potentially do them in parallel—performing rendering separately from searching the database may help us update the screen more fluidly.
1.2.4 Designing Hardware and Software Components
The architectural description tells us what components we need. The component design effort builds those components in conformance to the architecture and spec- ification. The components will in general include both hardware—FPGAs, boards, and so on—and software modules.
Some of the components will be ready-made. The CPU, for example, will be a standard component in almost all cases, as will memory chips and many other com- ponents. In the moving map, the GPS receiver is a good example of a specialized component that will nonetheless be a predesigned, standard component. We can also make use of standard software modules. One good example is the topogr aphic database. Standard topographic databases exist, and you probably want to use stan- dard routines to access the database—not only is the data in a predefined format, but it is highly compressed to save storage. Using standard software for these access functions not only saves us design time, but it may give us a faster implementation for specialized functions such as the data decompression phase.
1.2.5 System Integration
System integration is difficult because it usually uncovers problems. It is often hard to observe the system in sufficient detail to determine exactly what is wrong— the debugging facilities for embedded systems are usually much more limited than what you would find on desktop systems. As a result, determining why things do not stet work correctly and how they can be fixed is a challenge in itself.
1.3 FORMALISMS FOR SYSTEM DESIGN
As mentioned in the last section, we perform a number of different design tasks at different levels of abstraction throughout this book: creating requirements and specifications,architecting the system,designing code,and designing tests. It is often helpful to conceptualize these tasks in diagrams. Luckily, there is a visual language that can be used to capture all these design
Unified Modeling Language (UML) —the acronym is the name is a large lan- guage, and covering all of it is beyond the scope of this book. In this section, we introduce only a few basic concepts. In later chapters, as we need a few mor e UML concepts, we introduce them to the basic modeling elements introduced here. Because UML is so rich, there are many graphical elements in a UML diagram. It is important to be careful to use the correct drawing to describe something—for instance, UML distinguishes between arrows with open and filled-in arr o wheads, and solid and broken lines. As you become more familiar with the language, uses of the graphical primitives will become more natural to you.
1.3.1 Structural Description
By structural description , we mean the basic components of the system; we will learn how to describe how these components act in the next section. The pr incipal component of an object-oriented design is, naturally enough, the object. An object includes a set of attributes that define its internal state. When implemented in a programming language, these attributes usually become variables or constants held in a data structure. In some cases, we will add the type of the attribute after A class is a form of type definition—all objects derived from the same class have the same character istics, although their attributes may have different values. A class defines the attributes that an object may have. It also defines the operations that determine how the object interacts with the rest of the world. In a pr o gramming language, the operations would become pieces of code used to manipulate the object. The UML description of the Display class is shown in Figure 1.6. The class has the name that we saw used in the d 1 object since d 1 is an instance of class Display. The Display class defines the pixels attribute seen in the object; remember that when we instantiate the class an object, that object will have its own memor y so that different objects of the same class have their own values for the attr ibutes. Other classes can examine and modify class attributes; if we have to do something more complex than use the attribute directly, we define a behavior to perform that function.
A class defines both the interface for a particular type of object and that object’s implementation. When we use an object, we do not directly manipulate its attributes—we can only read or modify the object’s state through the opera- tions that define the interface to the object. (The implementation includes both the attributes and whatever code is used to implement the operations.) As long as we do not change the behavior of the object seen at the interface, we can change the implementation as much as we want. This lets us improve the system by, for example, speeding up an operation or reducing the amount of memory required without requiring changes to anything else that uses the object.
There are several types of relationships that can exist between objects and classes:
■ Association occurs between objects that communicate with each other but have no ownership relationship between them.
■ Aggregation describes a complex object made of smaller objects.
■ Composition is a type of aggregation in which the owner does not allo w access to the component objects.
■ Generalization allows us to define one class in terms of another.
Unified Modeling Language , like most object-oriented languages, allows us to define one class in terms of another. An example is shown in Figure 1.7, where we derive two particular types of displays. The first, BW_display , describes a b lac k- and-white display. This does not require us to add new attributes or operations, but we can specialize both to work on one-bit pixels. The second, Color_map_display , uses a graphic device known as a color map to allow the user to select from a behaviors—for example, large number of available colors even with a small number of bits per pixel. This class defines a color_map attribute that determines how pixel values are mapped onto display colors. A derived class inherits all the attributes and operations fr om its base class. In this class, Display is the base class for the two derived classes. A derived class is defined to include all the attributes of its base class. This relation is transitive—if Display were derived from another class, both BW_display and Color_map_display would inherit all the attributes and operations of Display’s base class as well. Inheritance has two purposes. It of course allows us to succinctly describe one class that shares some characteristics with another class. Even mor e important, it captures those relationships between classes and documents them. If we ever need to change any of the classes, knowledge of the class structure helps us determine the reach of changes—for example, should the change affect only Color_map_display objects or should it change all Display objects?
Unified Modeling Language considers inheritance to be one form of general- ization. A generalization relationship is shown in a UML diagram as an arrow with an open (unfilled) arrowhead. Both BW_display and Color
versions of Display , so Display generalizes both of them. UML also allows us to define multiple inheritance , in which a class is derived from more than one base class. (Most object-oriented programming languages support multiple inher itance as well.) An example of multiple inheritance is shown in Figure 1.8; we have omit- ted the details of the classes’ attributes and operations for simplicity. In this case, we have created a Multimedia_display class by combining the Display class with a Speaker class for sound. The derived class inherits all the attributes and oper ations of both its base classes, Display and Speaker. Because multiple inheritance causes the sizes of the attribute set and operations to expand so quickly, it should be used with care.
Let’s consider a simple state machine specification to understand the semantics of UML state machines. A state machine for an operation of the display is sho wn in Figure 1.12. The start and stop states are special states that help us to organize the flow of the state machine. The states in the state machine represent dif fe r ent conceptual operations. In some cases, we take conditional transitions out of states based on inputs or the results of some computation done in the state. In other cases, we make an unconditional transition to the next state. Both the unconditional and conditional transitions make use of the call event. Splitting a complex operation into several states helps document the required steps, much as subroutines can be used to structure code.
It is sometimes useful to show the sequence of operations over time, particularly when several objects are involved. In this case, we can create a sequence diagram, like the one for a mouse click scenario shown in Figure 1.13. A sequence diagram is somewhat similar to a hardware timing diagram, although the time flows ver ti- cally in a sequence diagram, whereas time typically flows horizontally in a timing diagram. The sequence diagram is designed to show a particular scenario or choice of events—it is not convenient for showing a number of mutually exclusive possibil- ities. In this case, the sequence shows what happens when a mouse click is on the menu region. Processing includes three objects shown at the top of the diagram. Extending below each object is its lifeline , a dashed line that shows how long the object is alive. In this case, all the objects remain alive for the entire sequence, but in other cases objects may be created or destroyed during processing. The bo xes along the lifelines show the focus of control in the sequence,
that is, when the object is actively processing. In this case, the mouse object is active only long enough to create the mouse_click event. The display object remains in play longer; it in tur n uses call events to invoke the menu object twice: once to determine which menu item was selected and again to actually execute the menu call. The find_region( ) call is internal to the display object, so it does not appear as an event in the diagram.
1.4 MODEL TRAIN CONTROLLER
In order to learn how to use UML to model systems, we will specify a simple system, a model train controller, which is illustrated in Figure 1.14. The user sends messa ge s to the train with a control box attached to the tracks. The control box may hav e familiar controls such as a throttle, emergency stop button, and so on. Since the train receives its electrical power from the two rails of the track, the control bo x can send signals to the train over the tracks by modulating the power supply volta ge. As shown in the figure,the control panel sends packets over the tracks to the r eceiver on the train. The train includes analog electronics to sense the bits being transmitted and a control system to set the train motor’s speed and direction based on those commands. Each packet includes an address so that the console can control several trains on the
same track; the packet also includes an error correction code (ECC) to guard against transmission errors. This is a one-way communication system—the model train cannot send commands back to the user.
1.4.1 Requirements
Before we can create a system specification, we have to understand the require- ments. Here is a basic set of requirements for the system:
■ The console shall be able to control up to eight trains on a single tr ack.
■ The speed of each train shall be controllable by a throttle to at least 63 dif fer ent levels in each direction (forward and r e ver se).
There shall be an inertia control that shall allow the user to adjust the respon- siveness of the train to commanded changes in speed. Higher inertia means that the train responds more slowly to a change in the throttle, simulating the inertia of a large train. The inertia control will provide at least eight dif fe r ent levels.
■ There shall be an emergency stop button.
■ An error detection scheme will be used to transmit messa ges.
Name Model train controller
Purpose Control speed of up to eight model trains
Inputs Throttle, inertia setting, emergency stop, train number
Outputs Train control signals
Set engine speed based upon inertia settings; r espond to emergency stop
Performance Can update train speed at least 10 times per second
Manufacturing cost $
Power 10 W (plugs into wall)
size and weight Console should be comfortable for two hands, appr o x - imate size of standard keyboard; weight 2 pounds
We will develop our system using a widely used standard for model train control. We could develop our own train control system from scratch, but
